Ich musste drei oder vier Mal gucken und habe es im ersten Moment nicht wirklich glauben wollen:
Das "DNS Root Key Signing Certificate" der IANA (Internet Assigned Numbers Authority) enthält einen formalen Fehler (hier verlinkt). Ausgestellt wurde das Zertifikat von der ICANN, die kommissarisch die Aufgaben der IANA wahrnimmt.
Wo ich zunächst einen Fehler in unserer Software vermutet habe, die wir zum Verarbeiten von ASN.1-Objekten einsetzen (dazu zählen eben auch X.509 Zertifikate) und mich dort auf die Suche nach einem Fehler gemacht habe, musste ich schlussendlich herausfinden, dass die Software hervorragend arbeitet und höchstens etwas streng validiert - ASN.1 hat keinen sonderlich guten Ruf und der Hauptkritikpunkt hier liegt wohl in der etwas verkopften bzw. zu abstrakten, manchmal schwer zu implementierenden Definition dieser binären Beschreibungssprache und so hätte ich mich erst einmal nicht gewundert, sollte bei uns etwas schief gelaufen sein.
Mit der Zeit konnte ich aber ziemlich genau herausfinden, an welcher Stelle im Zertifikat der IANA der "Fehler" liegt - ich gehe an dieser Stelle bewusst dazu über den "Fehler" in Anführungszeichen zu setzen, da er im Prinzip nur formaler Natur ist und eigentlich zu keinen praktischen Problemen (z.B. bei der Signierung von DNSSEC-Daten und der Validierung solcher Unterschriften) kommen sollte. Allerdings finde ich es bezeichnend, dass so ein Fehler bei der IANA bzw. ICANN auftritt. Immerhin sind diese beiden Organisationen zwei wesentliche Organe der Verwaltung des Internets. Aber was ist eigentlich mein das Problem?
Das Problem ist, dass das oben angesprochene Zertifikat von der folgenden Stelle unterschrieben wurde:
Organisation: ICANN
Allgemeiner Name: ICANN DNSSEC CA
E-Mail-Adresse: dnssec@icann.org
Das an sich stellt natürlich kein Problem dar. Jeder im Internet darf eine eigene Certificate Authority (CA) erstellen und damit andere Zertifikate ausstellen bzw. unterschreiben - auch die ICANN darf das, vielleicht sogar gerade die ICANN. Der "Name" der unterschreibenden Organisation ist in X.509-Zertifikaten recht aufwendig kodiert. Im Prinzip ist das eine Aneinanderreihung von Bezeichnungen bzw. sog. Attributen. Jedes Attribut hat hierbei eine Kennung ("Object ID") und einen damit verwandten Wert, die meistens als "Printable String", "IA5 String" oder "UTF-8 String" kodiert werden. In der Praxis ist das sicherlich etwas komplexer und primär dem oben genannten ASN.1 geschuldet, ich belasse es aber bei dieser einfachen Darstellung.
Das IANA-Zertifikat verwendet an dieser Stelle ausschließlich "Printable Strings" und genau hier liegt ein ganz banales Problem: Ein "Printable String" kennt kein "@"- oder "&"-Zeichen, der oben genannte Aussteller des Zertifikates hat jedoch seine E-Mail-Adresse vermerkt - und die kommt bekanntlich nicht ohne "@"-Zeichen aus.
Selbstverständlich habe ich meine Annahme mit OpenSSL verifiziert ("openssl asn1parse -inform pem < Kjqmt7v.crt"):
[...]
75:d=3 hl=2 l= 31 cons: SET
77:d=4 hl=2 l= 29 cons: SEQUENCE
79:d=5 hl=2 l= 9 prim: OBJECT :emailAddress
90:d=5 hl=2 l= 16 prim: PRINTABLESTRING :dnssec@icann.org
[...]
Bemerkenswert ist an dieser Stelle (wie auch im x509-Modul von OpenSSL), dass OpenSSL die Kodierung nicht als Fehlerhaft wertet oder einen entsprechenden Fehler ausgibt. Aber schon die Wikipedia sieht das anders: Dort wird schon unter der Tabelle der erlaubten Zeichen darauf hingewiesen, dass das "@"-Zeichen im Subset des "Printable String" nicht enthalten ist und dies ein typischer Fehler für einen "naiven Implementierer" ist. Formal definiert ist der "Printable String" in X.680, Kapitel 41, Absatz 4 (Seite 88) - wo sich die Tabelle der Wikipedia auch noch einmal verifizieren lässt.
Es liegt mir fern die IANA oder ICANN als "naiv" zu bezeichnen (auch wenn der Absatz über die Wikipedia dies nahe legen könnte), aber es drängt sich irgendwie die Frage auf, wie die dort ihre Zertifikate erstellen, dass sich so ein "Fehler" einschleichen kann.
Auf meine Arbeit an sich hatte das übrigens keinen Einfluss - ich war ohnehin nur am "Subject Public Key"-Teil des Zertifikates interessiert und der war intakt.
Kommentare