DEUTSCHE PGP ANLEITUNG

Web of Trust oder "Wie funktioniert das Netz des Vetrauens ?" 

Wenn jemand Public Keys dazu benutzen will, um verschlüsselte Kommunikation zu betreiben, muss er zwei Dinge voraussetzen können:

1. die Public Keys seiner Kommunikationspartner sind echt.
2. sein Public Key kann nicht gefälscht werden.

Deshalb fängt das Web of Trust schon bei der Schlüsselerzeugung an.

Fälschung

Bei der Keyerzeugung wird der eigene Public Key mit dem eigenen Secret Key signiert.
Wenn man unter PGPkeys nachsieht, befinden sich unter dem Keysymbol zwei weitere Einträge, dem ersten Eintrag ist ein symbolisierter Briefumschlag vorangestellt und steht für die User-ID, dem zweiten Eintrag ist eine Feder oder eine Stiftspitze vorangestellt ist und steht für die Signatur.
Sieht man sich mal die "Key Properties (Eigenschaften)" des eigenen Public Keys an, fällt eines auf:
Sowohl die "Key-ID" als auch der "Key-Fingerprint" sind bei dem Keypaar, der User-ID und der Signatur gleich.
Kontrollieren wir den Public Key eines Kommunikationspartners (was immer der Fall sein muss), muss das Ergebnis genauso aussehen, ansonsten ist der Public Key gefälscht.
PGP unterschreibt also selbst unseren eigenen Public Key, um damit auszuweisen, dass der Public Key mit dieser speziellen Key-ID und User-ID mit dem richtigen Secret Key unterschrieben wurde, der Verbreiter des Public Key mit User-ID wx und Key-ID yz im Besitz des passenden Secret Keys und der passenden Passphrase ist.
Ausserdem beinhaltet die eigene Signatur weitere Merkmale des Schlüssels wie z. B. die Gültigkeitsdauer, die im Fingerprint des Schlüssels nicht enthalten sind und bestätigt die Zugehörigkeit des Keyinhabernamens in der User-ID wx zum Schlüssel mit der Key-ID "yz".
Die ID's der Signatur sind nicht zu editieren, wie es beim Public Key möglich ist, so dass der Key durch die Eigensignatur auch vor Veränderungen (mit Ausnahme weiterer Signaturen anderer User, die ich nicht verhindern oder nochmals signieren kann) geschützt wird.

Fälschungswege

A.
Der Fälscher versieht den ursprünglichen Public Key mit seiner User-ID/E-mail Adresse und um nicht aufzufallen, entfernt er alle Signaturen.

Da die Keyserver nur einmal einen Key mit einer spezifischen Key-ID speichern können, kann der Fälscher versuchen, den Key vor dem ursprünglichen Key des Erstellers auf dem Keyserver abzulegen, so dass der Ersteller nicht mehr in der Lage ist den ursprünglichen, erzeugten Key zu hinterlegen.
Die Fälschung fällt auf, da der Key keine Signatur hat.
Denkbar ist, dass der Fälscher eine Signatur erstellt und deren Fingerprint fälscht, dann aber unterscheidet sich der gefälschte Key vom originalen, signierten Key in der Länge.

B.
Der Fälscher erstellt einen neuen Public Key, der die User-ID und die Key-ID des ursprünglichen Keys des Angegriffenen trägt und versieht den Key mit seiner Signatur und zusätzlich eventuell noch mit seiner E-mail Adresse.

Aus der Sicht des Fälschers hofft dieser, dass Personen annehmen werden, dieser Key gehoere dem originalen User und diesen Key benutzen um E-mails an den eigentlichen Empfänger verschlüsseln.
Der Fälscher kann sich nun zwischen dem gutgläubigen Absender und den eigentlichen Empfänger schalten, die Korrespondenz abfangen und entschlüsseln.
Ist die E-mail Adresse des Keys durch die Adresse des Fälschers ersetzt worden, kann er sich diesen Schritt sogar sparen und bekommt die E-mails direkt zugeschickt.
Andernfalls erhält der ursprüngliche Empfänger zwar die E-mails, kann diese aber nicht mehr entschlüsseln.
Wurde der Fingerprint nicht gefälscht, ist die Fälschung am unterschiedlichen Fingerprint von Key und Signatur zu erkennen.

Weitere Informationen, welche Gefahren durch Fälschungsmöglichkeiten entstehen können, finden sich in der:

Was deutlich wird, ist, dass man nur dann ziemlich sicher von der Echtheit eines Keys ausgehen kann, wenn die Kombination aus Keylänge, die ID's, die Fingerprints und die Signatur stimmt und diese Kombination persönlich beim Keybesitzer überprüft wurde.

Somit kann zwar nicht ausgeschlossen werden, dass jemand einen Public Key fälscht, aber, dass er dies unentdeckt tun kann.

Validity

Die Echtheit ("Validity")eines Public Keys wird durch die Signatur anderer User "bezeugt".
Wir können einen anderen Public Key mit unserer eigenen Signatur versehen.
In PGP 5/6 wird dieser Key sogleich "valid", d.h. "gültig" oder "authentisch".
Solange er nicht von uns signiert ist, bleibt der Key grundsätzlich gesehen "ungültig" oder "nicht authentisch". Als Folge bleibt der Besitzer des Keys auch als "untrusted" oder "nicht vertrauenswürdig" eingestuft. Mit der Signierung bezeugen wir, dass wir uns überzeugt haben, dass dieser Public Key wirklich zum angegebenen User gehört oder anders:
Wir wissen mit 100% Sicherheit, dass der Public Key echt ist, unabhängig davon, ob unter diesem Key bereits Signaturen von Leuten stehen, denen wir vertrauen oder die uns bekannt sind.
Zu diesem Zweck überprüfen wir schon mal, wie oben angegeben, den bereits vorliegenden Public Key auf Unstimmigkeiten.
Dann überprüfen wir persönlich oder telefonisch die Angaben, die uns der Key liefert (User-ID, Key-ID, Fingerprint, Keylänge, Keytyp) anhand der Angaben, die uns der Kontaktierte auf Anfrage liefert.
Zusätzlich können auf die gleiche Weise eine oder mehrere der unter dem Key befindlichen Signaturen gegengeprüft werden.
Wenn im Idealfall, davon ausgegangen wird, dass jeder PGP-Benutzer so verfährt, wären idealerweise alle Public Keys echt.
Da wir die Realität kennen, kann sich jeder PGP-Benutzer ausrechnen, welche Kontrollen er durchführen muss und wie verantwortlich er zu handeln hat.
Neben den Signaturen anderer User spielen die Zertifikate von CA's eine weit wichtigere Rolle.

Trust

Neben der "Validity" hat PGP 5/6 auch eine weitere interne "Trust"-Skala zu bieten, die sich auf unsere Einschätzung des Keybesitzers bezieht. Der "Trust" oder "Vertrauensgrad" gibt in drei Stufen von "untrusted-nicht vertrauenswürdig" über "marginal-begrenzt vertrauenswürdig" bis zu "complete-voll vertrauenswürdig" an, inwieweit das Vertrauen in das verantwortliche Handeln und die Fähigkeit eines Keybesitzer vorhanden ist, selbst wiederum für die "Validity" eines anderen Public Keys zeugen zu können.
Bekommt man irgendwann einen Public Key, der mit der Signatur einer Person versehen ist, die man selbst eines von Dir nach "Trust" eingestuften PGP-Benutzers signiert ist, wird dieser Public Key entsprechend als gültig eingestuft, auch wenn Du diesen neuen Key selbst noch nicht signiert hast.
Beachte: Der Trustlevel eines PGP-Benutzers kann erst höher als "untrusted" eingestuft werden, wenn Du den Key dieses Benutzers selbst signiert hast. So hängt also das Vetrauen in einen User von der Gültigkeit seines Keys ab.
Oder anders formuliert: Ein Key kann zwar "gültig", der Benutzer aber "nicht vertrauenswürdig" sein.

Die Konfiguration des "Web of Trust" bei PGP 2.6.3: wird durch die Vergabe der eigenen Signatur und/oder der Vergabe eines von vier Trustlevels bestimmt.
PGP 2.6.3 kennt zur eigenen Kennzeichnung des Vertrauens in die Aufrichtigkeit der Person und in die Kompetenz einer Person, verantwortlich sowohl mit den eigenen, wie mit anderen PGP-Keys umzugehen, folgende Stufen:

  • 1 = ich weiss nicht
  • 2 = Nein
  • 3 = in der Regel
  • 4 = Ja, immer
über die man der Datei config.txt in zwei Einträge den eigenen Bereich des Web of Trust regeln kann:
  1. Completes_Needed = X
    PGP sieht dann einen Public Key als echt an, wenn er X Signaturen trägt,
    deren User die Vertrauensstufe 4 besitzen
  2. Marginals_Needed = Y
    PGP sieht dann einen Public Key als echt an, wenn er Y Signaturen trägt,
    deren User die Vertrauensstufe 3 besitzen
Zur direkten Einstellung des Trustparameters bei PGP 2.6.3 für einen User:

PGP 2.6.3> pgp -ke User-ID

Daneben muss für die Sicherheit des Public Keys, Secret Keys und der Passphrase gesorgt werden.
Eine sichere Verwahrung von Pubring, Secring und Passphrase gehören dazu.
Ein zusätzlicher Sicherheitsgewinn kann die wöchentliche oder monatliche Änderung der Passphrase sein, was ein Errechnen/Erraten der Passphrase zusätzlich erschwert, wenn man davon ausgeht, dass dieser Vorgang einige Zeit und einige Rechnerkapazitäten voraussetzt.

Es ist auch sinnvoll, sofort nach der Erstellung von Public und Secret Key, die Schlüsselrückzugsurkunde ("Key Revocation") für den Public Key zu erzeugen und gesichert abzulegen. Das hat den Vorteil, dass sofort die Key Revocation an einen Keyserver gesendet und die Kommunikationspartner informiert werden können, wenn Secret Key und/oder die Passphrase in die Hände anderer gelangt ist (was immer geschehen muss, wenn dieser Fall eintreten sollte).
Was noch wichtiger ist:
Wenn der Keybesitzer aus irgendeinem Grund nicht mehr im Besitz des Secret Keys und der Passphrase ist, kann er seinen Public Key zurückziehen.
Siehe auch Key Revocation

Zertifizierungsstellen ("Certification Authorities")

Einen weiteren Ansatz stellen die sogenannten Zertifizierungsstellen ("Certification Authorities"/CA) dar, also anerkannte Institutionen, Organisationen, Firmen oder Vereine, die die Zugehörigkeit zwischen der Identität einer Person und einem Public Key nach bestimmten Prüf- und Kontrollverfahren durch ein Zertifikat zertifizieren.
Damit entfällt der doch etwas aufwendige und mit Unsicherheiten belastete Weg der Sammlung von Signaturen unter den eigenen Public Key und die Notwendigkeit der persönlichen Kontaktaufnahme mit dem Keybesitzer, wenn man einen anderen Public Key zertifizieren will.
Das bedeutet andererseits, daß mein Vertrauen in die Gültigkeit eines CA-Zertifikats an das Vertrauen in die CA selbst gekoppelt ist.
Anders ausgedrückt: Der Anwender muss sich sicher sein können, dass die CA auf verlässlichem, nachvollziehbarem und korrektem Wege Schlüssel übeprüft und zertifiziert.
Ein wichtiges Kriterium dazu bieten die Arbeitsgrundlagen einer CA.

Policys und Rechtsgrundlagen

Bei den Rechtsgrundlagen sind zwei Gesetzeswerke ausschlaggebend:

Die Richtlinie 1999/93/EG des Europäischen Parlaments und des Rates über gemeinschaftliche Rahmenbedingungen für elektronische Signaturen und die Umsetzung der Richtlinie in das deutsche Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz - SigG).
Das SigG legt f

Aber auch bei den CA's ist es meistens notwendig, persönlich mit dem Personalausweis oder gar einer notariellen Bestätigung zu erscheinen, damit diese den eigenen Public Key zertifizieren oder das Keypaar muß in einem abgesicherten Verfahren direkt in der CA vom Keybesitzer erzeugt werden.

Es gibt aber auch Zertifikate, die dann ausgestellt werden, wenn der Keyinhaber einen verschlüsselten Prüfsatz, den ihm die CA nach Antrag zusendet, entschlüsseln kann und dann wieder per E-Mail an die CA zurücksendet (E-Mail Zertifikat) oder die CA verlangt zusätzlich die Ausweisung gegenüber einer bekannten öffentlichen Stelle wie einem Postamt (Post-Ident-Zertifikat).
Es gibt also unterschiedliche "Qualitätsstufen" bei Zertifikaten, die aber auch aus der Bezeichnung eines Zertifikats ersichtlich sind.
Der Vorteil der CA-Signatur liegt trotzdem im allgemeinen Bekanntsheits- und Vertauensgrad, der es leichter macht, einem Public Key zu vertrauen, der mit einer CA-Signatur versehen ist, als einem Public Key, der zwar von einer Person signiert wurde, deren Name mir aber nicht bekannt ist.
Die Bedeutung der CA's wird deshalb mit einer steigenden Anzahl von PGP Benutzern zunehmen.

Beispiele für CA's

Trustcenter

Auch die Bundesregierung und die Europäische Union haben mit dem Deutschen Signaturgesetz und der europäischen Signaturverordnung den Weg frei gemacht für staatlich anerkannte Zertifizierungsstellen ("Trustcenter"), die in eigener Regie und durch staatliche Lizenzvergabe für die Verwaltung und Herstellung digitaler Signatur- und Verschlüsselungskeys zuständig sind.
Die mit diesen Keys erzeugten Signaturen werden zukünftig rechtlich der schriftlichen Unterschrift gleichgestellt sein.
Das betrifft nicht mit PGP erzeugte Keys und deren Signaturen, da diese nicht in staatlich anerkannten TrustCentern erzeugt werden, bzw. keine "qualifizierten" Signaturen erzeugen - in gerichtlichen Verfahren ist hier der Anwendern stärker dazu gezwungen, die Gültigkeit oder Ungültigkeit von PGP Signaturen zu beweisen.
In einigen Staaten ist diese Idee oft mit der Hinterlegung eines "Generalschlüssels" bei staatlichen Stellen oder "Trusted Third Parties" (TTP), dem sogenannten "Key Escrow" (im Falle von PGP könnte man auch sagen: Hinterlegung von Secret Key und Passphrase) verbunden, mit dessen Hilfe staatliche Organe, wie die Geheimdienste, nach einem juristischen Genehmigungsverfahren verschlüsselte Dateien oder E-Mails bei Verdacht wieder entschlüsseln können oder mit der Zulassung von Verschlüsselungsprogrammen, die es erlauben, den Verschlüsselungskey, der bei der Verschlüsselung benutzt wurde, wiederherstellen zu können, sogenanntes "Key Recovery".

Eine Zwischenform stellen Trustcenter dar, die gleichzeitig die Merkmale der TTP's besitzen, d. h. das Schlüsselpaar wird im Trustcenter erzeugt und dem Antragsteller auf einer SmartCard ausgehändigt, der Public Key wird in ein öffentliches Verzeichnis eingestellt, aber der private Schlüssel verbleibt ebenfalls in der Zertifizierungsstelle und macht sie so zur TTP.
Bei dieser Form aus Trustcenter und TTP kommt mir persönlich ein ganz anderer Verdacht...und Carl Ellison von der Firma CyberCash nennt diese Vorstellungen beim Namen: "Govermental Access to Keys (GAK)".

Bei den Trustcentern Telesec, einer Tochterfirma der Telekom und dem Trustcenter SignTrust, einer Tochterfirma der Deutschen Post AG wird die Schlüsselerzeugung auf der SmartCard in einem tresorähnlichen, TEMPEST abgeschirmten Sicherheitsraum durchgeführt, in dem der Rechner steht, auf dem mit einem Zufallszahlengenerator das Schlüsselpaar erzeugt und mit einer Codiermaschine anschliessend in den Chip der SmartCard gebrannt wird.
D. h. während der Schlüsselerzeugung bis die SmartCard aus der Codiermaschine fällt, ist auch in diesen Trustcentern der geheime, private Schlüssel präsent - auch wenn er nach der Aufbringung auf die SmartCard vernichtet wird, da das Schlüsselpaar nicht beim Anwender in dessen SmartCard(lese)gerät erzeugt wird.
Dies stellt, trotz Vernichtung des Private Keys und der räumlichen Absicherung, weiterhin ein Sicherheitsrisiko dar: Geheimdienste könnten sich theoretisch Zugriff auf den Private Key während der Schlüsselerzeugung verschaffen, andere Personen theoretisch durch Bestechung oder Erpressung von Angestellten, die Zutritt zu den Sicherheitsbereichen im Trustcenter haben.

Trotzdem werden die nach diesen gesetzlich vorgeschriebenen Verfahren erzeugten Schlüssel und Signaturen und der Einsatz auf Krypto-SmartCards größte Bedeutung im Geschäfts- und Rechtsverkehr erlangen - spätestens dann, wenn Geld/Kreditkarten- und Ausweisfunktionen damit auf einer einheitlichen SmartCard zusammengeführt werden und eventuell auch im elektronischen Kommunikationsverkehr PGP zur Bedeutungslosigkeit "verdammen".

S/MIME, PKCS und X.509

Der große Konkurrent um den Standard zur E-Mail Verschlüsselung zu OpenPGP - PGP/MIME ist das S/MIME-X.509 System nach Standard RFC 1847/1848.

S/MIME (Secure MIME) basiert auf Standards, die einerseits Vorschriften für Public-Key Verschlüsselung, andererseits die Struktur von E-Mail Nachrichten beschreiben.

MIME (Multipurpose Internet Mail Extensions)

erweitert den Standard für Nachrichten im Internet nach RFC 822 um den MIME Standard nach RFC 2045/2046/2047/2048/2049.
Nach RFC 822 besteht eine Nachricht nur aus Text, der aus 7-Bit Zeichen des US-ASCII Zeichensatzes besteht. Eine Nachricht enthält danach weder Umlaute, bzw. sprachspezifische Zeichen noch andere 8-Bit Zeichen, wie sie in multimedialen, binären Inhalten wie Audio- oder Videodaten vorkommen.
Um diese Beschränkungen aufzuheben, wurden Codierungsanweisungen für verschiedene Nachrichteninhalte festgelegt, die im Header einer E-Mail in mehreren Feldern festgehalten werden:
Ein Feld gibt die MIME-Version an, das Content-Type Feld die Art des Inhalts und das Content-Transfer-Encoding Feld das verwendete Kodierungsverfahren. Über den Content-Type: Multipart kann der Nachrichtenbody in mehrere Abschnitte verschiedenen Inhalts unterteilt werden. Es ist auch möglich, eigene Nachrichteninhaltstypen zu definieren.
Um MIME codierte Nachrichten lesen zu können, muss der Empfänger auch über einen E-Mail Reader mit MIME Implemetierung verfügen.

S/MIME führt die drei neuen Content-Type Typen application/pkcs7-mime für binär verschlüsselte/signierte Daten, multipart/signed - application/pkcs7-signatur für Klartextsignaturen und application/pkcs10 für Zertifizierungsanfragen ein.
Mit S/MIME ist es also auch möglich, in die E-Mail eingebetette Objekte zu verschlüsseln und/oder zu signieren.

Die MIME Funktionalität von S/MIME besitzt auch die PGP/MIME Erweiterung nach Standard RFC 2015 des OpenPGP Standards nach RFC 2440.

PKCS (Public Key Cryptography Standards)

Die PKCS (mittlerweile PKCS #1 bis #13) wurden von den RSA Laboratories in Kooperation mit mehreren IT-Unternehmen, darunter Apple, Microsoft, DEC, Lotus, Sun und dem MIT, entwickelt.
Die Standards legen fest, welche kryptografischen Algorithmen wie zu implementieren sind (darunter RSA und Diffie-Hellmann) und wie die algorithmusunabhängige Syntax für digitale Signaturen, verschlüsselte Datenhüllen und Zertifikate strukturiert ist.

Algorithmen

der S/MIME Standard schreibt vor, dass bestimmte Algorithmen implemtiert sein müssen.
Darüberhinaus besitzen einzelne Anwendungen zusätzliche Implementierungen.

Beispiel anhand von Biodata's SecureDesk und Utimaco's SafeGuard Sign & Crypt:

Algorithmen
symmetrisch IDEA,DES,3DES,
RC2
DES,3DES,RC2
asymmetrisch RSA RSA
Signatur DSA/DSS  
Hashing SHA-1,MD2-MD5,
RIPEMD-160
SHA-1,MD5,RIPEMD-160
Anmerkung: SecureDesk enthält auch eine OpenPGP Engine mit ElGamal/DH, CAST-5, Safer SK128, Blowfish, Twofish, Haval, Tiger-192.

Der PKCS #7 Standard "Cryptographic Message Syntax Standard" enthält sechs verschiedene, kryptografische Inhaltstypen:

  • data (unverschlüsselte 8-Bit-Daten)
  • signedData (signierte Daten),
  • envelopedData (verschlüsselte Daten mit chiffriertem
  • Sitzungsschlüssel)
  • signedAndEnvelopedData (signierte und verschlüsselte Daten)
  • digestData (Signatur)
  • encrypted Data (verschlüsselte Daten ohne Schlüssel).

Zusammengefasst wird also festgelegt, wie kryptografische Daten in E-Mails zu codieren, zu formatieren und zu transportieren sind und wie die Daten kryptografisch erzeugt werden.

X.500/509

Der X.500 Standard beschreibt die Struktur eines globalen, verteilten und hierarchisch aufgebauten Verzeichnissystems.
Verteilt, weil an jedem beliebigen Ort, an dem Informationen zu einem bestimmten Objekt anfallen, diese dort in einem lokalen Verzeichnis abgelegt werden können.
Global, weil z. B. im Falle eines E-Mail Adressverzeichnisses die dezentral angefallenen Objektdaten durch die Verbindung der lokalen Verzeichnisse zu einem einzigen, großen Gesamtverzeichnis zusammengeführt werden.
Die Einzelinformationen zum Objekt beschreiben dabei als Attribute die Eigenschaften des Objekts.
Theoretisch kann in dem Verzeichnis jede Art von Objekt (von einer Person bis zu einem bestimmten Schriftstück) erfasst werden.
Die Methode des Eintrags wird durch eine Anweisung, die Bestandteil des Standards ist und als das Schema bezeichnet wird, festgelegt. In ihm werden die Klassen (Objekte gemeinsamen Typs) und die dazugehörigen Attribute definiert.
Die Anordnung und Nennung der Attribute und einem Objekt übergeordneter Objekte im Eintragsnamen eines Objekts spiegeln dabei die Hierarchie wieder, in der sich ein Objekt befindet.
Im Verzeichnis selbst lassen sich dazu die Objekte in einer baumartigen Struktur anordnen.

In unserem Fall wäre das einzelne Objekt der Anwender als Person, die mit einzelnen Merkmalen ausgestattet ist (Name, Adresse, E-Mail-Adresse usw.), sein Public Key und sein Zertifikat.
Der Public Key wird zusammen mit den Daten des Besitzers in das Verzeichnis nach obigem Schemata eingestellt.
Der Key wiederum ist einer Zertifizierungsinstanz (CA) untergeordnet, die als übergeordnetes Objekt die Einheit Person/Anwender-Public-Key zertifiziert hat.
Über einzelnen Zertifizierungsstellen kann im Verzeichnis wiederum eine einzelne Haupt-CA als oberste Zertifizierungsinstanz angesiedelt sein, die die untergeordneten CA's zertifiziert hat.

Ein Verzeichnis (sei es ein E-mail Adressverzeichnis oder ein Verzeichnis aus CA's, Anwendern und ihren Schlüsseln) wird heute meistens über das LDAP (Leightweight Directory Access Protocol) durchsucht und abgefragt (wie es auch bei PGP und den meisten E-mail Readern der Fall ist).

Die Zertifikate werden nach dem X.509 Standard erstellt.
X.509 spezifiziert den Authentifizierungsdienst für Verzeichnisse, die nach Standard X.500 aufgebaut sind und beruht auf kryptografischen Methoden nach PKCS. Gleichzeitig legt X.500 die Syntax eines Zertifikats fest, die der Namensstruktur eines Objekteintrages in einem X.500 Verzeichnis folgt. Zusätzlich beinhaltet der Standard die Vorschriften, wie die Syntax der Certificate Revocation Lists (CRL) aussieht, also die Listen der Keys, die als ungültig erklärt, zurückgerifen wurden.

Beides zusammengenommen bezeichnet man auch als Public-Key Infrastructure (PKI).

Zusammengefasst liegt also bei einem S/MIME-Key der Schlüssel in Form eines Zertifikats vor, der den Standards nach X.500 und 509 entspricht.
Er enthält sowohl die einzelnen Daten zur Person des Keybesitzers, den Public Key selbst und (bei Zertifizierung durch eine CA) das Zertifikat der Zertifizierungsstelle.
Auch bei einem S/MIME-Key besteht der Schlüssel aus einem Schlüsselpaar aus privatem und öffentlichen Schlüssel, beide Keys werden auch auf dem gleichen Weg der asymmetrischen Verschlüsselung angewendet (wie zu Anfang der Anleitung erwähnt).
Das Schlüsselpaar kann entweder vom Anwender selbst erzeugt werden, oder wie bei den staatlich anerkannten Trustcentern in und durch die Zertifizierungsstelle.
Bei S/MIME Keys können in einer PKI, die auf Direct-Trust beruht, die Anwender die Keys anderer Anwender zertifizieren (analog zum PGP Web-of-Trust). Bei einer PKI, die auf Trust-Chaining beruht, steht im Vordergrund die Hierarchie aus Stamm-CA und Unter-CA's, von denen eine CA die "Echtheit" eines Keys zertifiziert.
D. h. das Vertrauen des Anwenders in die Stamm-CA wird über die Unter-CA zum letztendlichen Key "durchgereicht" oder "vererbt" (analog zu den PGP CA's, die PGP-Keys zertifiziert haben).

Eine Darstellung der Unterschiede zwischen dem Modell der (Open) PGP Web-of-Trust PKI und der X.509 PKI finden sich in dem Aufsatz "Why OpenPGP’s PKI is better than an X.509 PKI" von P. Zimmermann auf der Site der OpenPGP Allianz.

Schlüsselzertifikate oder "Wie signiere ich die Public Keys anderer Personen ?"

Voraussetzung für das Signieren anderer Public Keys ist das Lesen des Kapitels "Web of Trust".

Vorgehensweise

  1. Aufruf von PGPkeys
  2. a) Menü "Keys - Sign" oder
    b) 1xMKrT auf den betreffenden Key und im Kontextmenü "Sign" wählen
  3. Button "More Choices" anklicken

    Signiermöglichkeiten (Signature Type)

    • Non-Exportable

      bei der nicht exportierbaren Signatur verbleibt die Signatur nur im eigenen Pubring, sie wird nicht mit übertragen, wenn man den Key abspeichert, in eine E-mail Nachricht einfügt oder an einen Keyserver sendet.
      Diese Signatur sollte man wählen, wenn man z.B. schon einen dauerhaften E-mailverkehr mit einer Person pflegt und sich daraufhin ziemlich sicher ist, dass der Key dem Keybesitzer gehört und deshalb im PGPkeys Window und den Bestätigungsfenstern den Key als echt ausgewiesen sehen möchte.

    • Exportable

      die exportierbare Signatur ist die eigentliche Signatur im herkömmlichen Sinne, wie wir sie auch von PGP 2.6.3 kennen.
      Sie wird beim Abspeichern eines Keys, beim Versenden des Keys per E-mail oder an einen Keyserver mit übertragen und bestätigt somit gegenüber der Öffentlichkeit, dass der Key wirklich dem Keybesitzer gehört und nicht gefälscht ist.
      Aus diesem Grund sind bei Wahl der exportierbaren Signatur die Prinzipien des "Web of Trust" unbedingt zu beachten und anzuwenden !

    • Meta-Introducer Non-Exportable und
      Trusted Introducer Exportable

      durch unsere Signatur wird der Key eines Meta-Introducers (oberster, vertrauenswürdiger Bürge) voll vertrauenswürdig (trusted) und gültig (valid).
      Public Keys, die mit dem Key des Meta-Introducers signiert sind, werden automatisch voll gültig (valid).
      Die Signatur des Meta-Introducers ist nicht exportierbar, da er eine herrausragende Stellung besitzt und seine Funktion innerhalb eines geschlossenen Rahmens (wie dem Netzwerk einer Firma oder unserem Pubring) verbleiben muss.

      Seine Auszeichnung (und damit seine Eigenschaften) durch unsere Signatur kann der Meta-Introducer quasi an weitere Personen, bzw. Keys (die Trusted-Introducer) durch dessen Signierung "vererben".
      Public Keys, die mit dem Key des Meta-Introducers als Trusted-Introducer signiert sind, werden automatisch voll gültig (valid) und vertrauenswürdig (trusted), die Signatur des Trusted-Introducer ist exportierbar.
      D. h. er kann auch ausserhalb unseres geschlossenen Rahmens für die Gültigkeit anderer Public Keys bürgen, allerdings kann man den Domainbereich einschränken, in dem er für Keys bürgen kann, in dem man unter "Domain restriction" die E-mail Domains der Keys eingibt.
      Public Keys, die mit dem Key des Trusted-Introducers signiert sind, werden also automatisch voll gültig (valid) aber nicht vertrauenswürdig (trusted), d. h. diese Keys werden als gültig anerkannt, können aber nicht weitere Public Keys als gültig oder vertrauenswürdig auszeichnen.
      Die Trusted-Introducer können diese Eigenschaft also nicht weiter vererben.
      Der Meta-Introducer und die ihn stellvertretenden Trusted-Introducer "signieren" also quasi "stellvertetend" für uns selbst.

      Im PGPkeys Fenster findet sich unter dem Key des Meta-Introducers als Ausweis unsere Signatur mit der Beschreibung: "RSA,DH/DSS meta-introducer signature", bei dem Trusted-Introducer "RSA,DH/DSS trusted-introducer signature".

      In der Desktop Security Version von PGP mit PGPadmin Funktion kann der Corporate Signing Key (der oberste Signaturschlüssel eines Unternehmens) als Meta-Introducer konfiguriert werden. Der Besitzer des Corporate Signing Keys übernimmt damit als Meta-Introducer die Funktion einer Certification Authority (CA).

  4. Expiration (Verfallsdatum)

    hier kann noch angegeben werden, ob unsere Signatur immer gültig (never) oder zu einem bestimmten Datum ungültig werden soll.

  5. Eingabe der Passphrase
Hinweise

Zu den Begriffen Vertrauen in einen Keybesitzer (Trust) und Gültigkeit des Keys des Keybesitzers (Validity) siehe Web of Trust

Es ist mit PGP 5/6 möglich, einen RSA Public Key mit einer DSS Signatur zu versehen.
Aus Gründen der Kompatibilität sollte man aber einen RSA Public Key auch mit einem RSA Key signieren.

Nach dem Signieren kann der unterschriebene Key an den Besitzer und/oder die Keyserver versendet werden, je nach Typ wie in den Erklärungen der vorhergehenden Kapitel.

Das Konzept der Hierarchie von Meta-Introducer und Trusted-Introducer zielt auf Bereiche ab, in dem grosse Mengen an Public Keys und verschiedene Bereiche (Domains), aus dem diese Keys stammen, verwaltet werden müssen.
So wäre es denkbar, dass der Personalleiter oder Prokurist einer Firma von der Geschäftsführung, die im Besitz des Corporate Signing Keys mit Meta-Introducer Merkmal ist, zum Trusted-Introducer ernannt wird, der wiederum durch die Signierung der Keys seiner ihm Untergebenen dessen Keys unternehmensweit als gültig auszeichnet.
Oder der Hauptverkaufsleiter ernennt als Meta-Introducer die Gebietsverkaufsleiter zu Trusted-Introducern, die wiederum die Keys der einzelnen Aussendienstmitarbeiter signieren, um sie im Unternehmen als gültig zu kennzeichnen.
Für einen lokalen Pubring auf einem Einzelplatz-PC ist dieses Konzept überdimensioniert, da man ja selbst quasi der Meta-Introducer ist.
Es kann aber sinnvoll sein, die Root-Keys von anerkannten oder bekannten Zertifizierungsstellen (Certification Authorities), deren Gültigkeit man nach den Prinzipien des Web of Trust überprüft hat und deren Zertifizierungstechnik man vertraut, mit einer Meta-Introducer Signatur und die Zertifizierungs-Keys der CA's ab einer bestimmten Stufe (z. B. bei TC TrustCenter ab Class 3) mit einer Trusted-Introducer Signatur auszustatten, wodurch alle aktuellen und zukünftigen Public Keys, die von diesen Stellen zertifiziert wurden, sogleich gültig sind und von uns nicht mehr überprüft werden müssen.

Signieren eines Public Keys bei PGP 2.6.3:

PGP 2.6.3> pgp -ks User-ID-des-Keys Eigene-User-ID LW:\pubring.pgp

Beispiel