Schlüssel zum DNS
PGP und S/MIME kämpfen noch immer mit dem Problem der Schlüsselverteilung. Die neuen Ansätze DNS-CERT und PKA benutzen dafür das DNS-Server-Netz und erleichtern automatisierten Verfahren die Überprüfung digitaler Signaturen.
- Christiane Rütten
Derzeit gibt es zwei etablierte Standards für vertrauenswürdige und verschlüsselte E-Mails: das hierarchisch organisierte S/MIME, welches mit SSL-Zertifikaten nach dem Standard X.509 arbeitet, und OpenPGP, dem im Wesentlichen eine Netz-Struktur, das so genannte Web-Of-Trust, zu Grunde liegt. Insbesondere PGP kämpft jedoch mit einem prinzipiellen Problem: die zuverlässige und vertrauenswürdige Verteilung der öffentlichen Schlüssel.
Zur Validierung einer Signatur benötigt man vertrauenswürdige Schlüssel, was in der Regel noch einige Handarbeit erfordert. Im Falle von PGP liest man sich sogar oft noch bei persönlichen Treffen die Fingerprints vor, um sie mit denen der vorliegenden Schlüssel zu vergleichen. Bei S/MIME stellt sich das Problem, woher man das Zertifikat einer bestimmten Person bekommt, spätestens dann, wenn man ihr eine verschlüsselte E-Mail schicken will.
Für automatisierte Prozessen, wie beispielsweise die Absenderauthentifizierung durch einen E-Mail-Server, sind solche Methoden nicht praktikabel. Neuere Ansätze wie das Sender Policy Framework (SPF) und Yahoos DomainKeys versuchen, dieses Problem mit Hilfe des Domain Name System (DNS) zu beheben. DomainKeys arbeitet anders als SPF dabei zwar auch mit SSL-Zertifikaten, allerdings nur für die Mail-Server selbst.
Blick nach vorn
GnuPG unterstützt ab Version 1.4.3 zwei neue Methoden zur leichteren Validierung von Schlüsseln und Zertifikaten von Endanwendern, die sich in ihren Kernpunkten an den DNS Security Extensions (DNSSEC) und an SPF orientieren: DNS-CERT und die wesentlich einfachere Public Key Association (PKA). Beide nutzen DNS-Erweiterungen, um Zertifikats- und Schlüsselinformationen per DNS zu verteilen.
Die Einzelheiten von DNS-CERT sind im RFC4398[1] (ehemals 2538bis) beschrieben. Im Wesentlichen sieht es die Einführung eines neuen Resource Records (RR) vor, den der Nameserver Bind seit Version 9 von Haus aus unterstützt. Er besteht aus je einem Feld für die Typbezeichnung, das so genannte Tag zur besseren Schlüssel-Identifizierung, den eingesetzten Signaturalgorithmus sowie das Zertifikat selbst.
Der Aufbau eines CERT-RR soll anhand einer Beispiels für Bind9 zur Verteilung eines S/MIME-Zertifikats erläutert werden:
cr.ct.heise.de. 86400 IN CERT PKIX 13735 RSASHA1 (
MIIFPzCCAyegAwIBAgIDAbTxMA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jv
b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
[...]
++vtnJWJ7ZcaYk+/FZwEHzVjm6auHcYOK1mjloRkrQpzLz6UfrW11RZv34wA1Jcy
dIeQ)
An erster Stelle eines RR steht der DNS-Name, auf den er sich bezieht. RFC4398 legt Richtlinien fest, wie er aus den Daten der Zertifikate und Schlüssel abzuleiten ist: Ersetzt man in der E-Mail-Adresse den Klammeraffen durch einen Punkt, erhält man den zugehörigen DNS-Namen. Bei einem realen DNS-Eintrag mit obigem RR ließe sich das Zertifikat für die E-Mail-Adresse cr@ct.heise.de folglich mit dem Befehl host -t cert cr.ct.heise.de abrufen.
Existieren für ein Zertifikat mehrer E-Mail-Adressen, können dafür weitere DNS-Aliase, so genannte CNAMEs, angelegt werden, die auf die Haupt-Domain mit den eigentlichen Daten verweisen. Für PGP-Schlüssel schlägt das RFC außerdem vor, zusätzliche Domainnamen entsprechend der Key-ID beziehungsweise des Fingerabdrucks zu wählen.
Als Time To Live (TTL) wurde im RR explizit ein hoher Wert von 86400 Sekunden angegeben. Nameserver sollen den RR demnach einen Tag lang im Cache behalten, um die zwischen den Servern übertragenen Datenmengen zu reduzieren. IN CERT legt den gewünschten RR-Typ CERT in der Klasse "Internet" fest.
Der Resource-Record CERT
Die nach dem Schlüsselwort CERT stehenden Felder sind typspezifisch. Das erste Feld ist der Typbezeichner und gibt vor, welche Art von Information im CERT-RR enthalten ist:
| Wert | Bezeichner | Zertifikatstyp |
| 0 | reserviert | |
| 1 | PKIX | X.509-Zertifikat |
| 2 | SPKI | SPKI-Zertifikat |
| 3 | PGP | OpenPGP-Schlüsselblock |
| 4 | IPKIX | URL eines X.509-Objektes |
| 5 | ISPKI | URL eines SPKI-Zertifikats |
| 6 | IPGP | Fingerprint und URL eines OpenPGP-Schlüsselblocks |
| 7 | ACPKIX | Attribut-Zertifikat |
| 8 | IACPKIX | URL eines Attribute-Zertifikats |
Der Wertebereich für den Typ beträgt 16 Bit. In diesem gibt es zwar noch eine Handvoll reservierter Typen, doch die anderen rund 65000 sind zur Vergabe durch die IANA freigegeben. Hierbei ist anzumerken, dass Bind je nach eingesetzter Version nicht alle Typbezeichner kennt. Sollte es beim Server-Start zu entsprechenden Fehlermeldungen kommen, lässt sich auch einfach der Dezimalwert angeben. Gleiches gilt übrigens auch für die auf der nächsten Seite beschriebenen Schlüsselalgorithmen.
