Zusammenfassung

  • Die v3-Onion-Adresse leitet sich aus dem öffentlichen Ed25519-Identitätsschlüssel ab; DNS-Erreichbarkeit und DNS-Delegation sind keine Quelle ihrer Autorität.
  • onion-csr-01 lässt den Identitätsschlüssel eine frische, an zwei Nonces gebundene Validierungs-CSR signieren, deren Schlüssel vom finalen Zertifikatsschlüssel verschieden sein muss.
  • CAA kann aus dem verschlüsselten Deskriptor oder als signierter, ablaufender In-Band-Satz kommen; der Zertifikatsausgang verrät weder die Auswahl noch die Datenschutzkosten.

Eine Architektur mit drei Schlüsseln

Die Wiederverwendung des ACME-Identifikatortyps dns ist eine Kompatibilitätsentscheidung, keine Aussage über DNS-Autorität. RFC 7686 nimmt .onion aus der normalen Namensauflösung heraus. Im Tor-v3-Format enthält die Adresse den öffentlichen Ed25519-Masterschlüssel des Dienstes, eine Prüfsumme und die Version. Wer den Namen kontrolliert, muss daher eine Aussage mit dem zugehörigen privaten Schlüssel tragen können.

Ein gültiges ACME-Konto erfüllt eine andere Funktion. Es signiert Anforderungen, besitzt Bestellungen und bindet Antworten an einen Protokollteilnehmer. Eine finale CSR erfüllt wiederum eine dritte Funktion: Sie bestimmt den öffentlichen Schlüssel des Zertifikats. Erreichbarkeit, Kontobesitz und finaler Schlüssel sind notwendige Betriebsdaten, aber kein Ersatz für den Identitätsnachweis.

RFC 9799 verbietet deshalb dns-01. http-01 und tls-alpn-01 bleiben mit Onion-spezifischer Verbindung möglich. Die CA muss selbst über Tor verbinden und darf die Beobachtung nicht an Tor2Web auslagern. Beide Methoden sind jedoch nicht für Wildcards geeignet und erzwingen keine Signatur des Onion-Identitätsschlüssels.

Der neue Challenge-Typ onion-csr-01 schließt diese Lücke. Die CA liefert einen Nonce mit mindestens 64 Bit Entropie. Wurde er vor mehr als 30 Tagen erzeugt, darf die Antwort nicht mehr akzeptiert werden. Der Antragsteller legt die Rohbytes in caSigningNonce, ergänzt einen eigenen Nonce mit mindestens 64 Bit in applicantSigningNonce und signiert die Validierungs-CSR mit dem Onion-Privatschlüssel.

Die CA prüft PKCS#10-Struktur, Zuordnung des öffentlichen Schlüssels zum Namen, Signatur, exakte Übereinstimmung ihres Nonce und Entropie des Antragsteller-Nonce. Den subject-Inhalt darf sie nicht als Identität validieren. Der öffentliche Schlüssel muss außerdem vom Schlüssel der finalen CSR abweichen.

Die Trennung ist eine Kontrollmaßnahme. Der langlebige Onion-Schlüssel beweist den Namen, ohne automatisch als TLS-Schlüssel zu dienen. Der Zertifikatsschlüssel kann unabhängig rotieren. Das Konto authentifiziert den Transport. Ein gewöhnlicher ACME-key-authorization-String ist nicht nötig, weil die Validierungs-CSR bereits in einer kontosignierten ACME-Anforderung übertragen wird.

Deskriptorzugriff ist eine vierte Berechtigung

Bei eingeschränkter Auffindbarkeit ist der innere Deskriptor nur für autorisierte Clients lesbar. Die CA kann also den Anwendungsdienst erreichen und trotzdem weder Einführungspunkte noch CAA sehen. Das optionale authKey im Challenge benennt den Ed25519-Schlüssel, mit dem die CA auf den Deskriptor zugreifen will.

Eine CA darf denselben Schlüssel nicht für mehrere Onion-Dienste verwenden. Für eine erneute Validierung desselben Dienstes ist Wiederverwendung erlaubt. So wird die Zugangskennung nicht automatisch zum Korrelationsmerkmal über mehrere Dienste.

Die CA berechnet ihre CLIENT-ID und sucht die passende auth-client-Zeile. Ohne Treffer muss sie annehmen, dass keine Client-Authentisierung verlangt wird. Bei einem neuen Schlüssel muss der Betreiber ihn eintragen, den Deskriptor neu signieren und veröffentlichen. Die Verbreitung ist unbestimmt; der RFC erwartet wenige Minuten, setzt aber keine feste Dauer und empfiehlt mindestens 30 Minuten Challenge-Lebenszeit.

Die Antwort auf die Autorisierung signalisiert, dass der Schlüssel hinzugefügt worden sein sollte. Sie beweist nicht den Empfang der neuen Revision. Darum gehören CA-Schlüssel, Deskriptorrevision, Veröffentlichungszeit, berechnete Client-ID und erste erfolgreiche Entschlüsselung in denselben Nachweis.

CAA ohne DNS-Vererbungsbaum

CAA-Einträge stehen im zweiten verschlüsselten Deskriptorlayer und behalten das kanonische RFC-8659-Format. Es gibt aber keinen DNS-Baum, der aufwärts durchsucht werden könnte, und keinen .onion-TLD-Satz. Sämtliche Subdomains unter derselben Basisadresse teilen deren CAA-Politik.

Damit eine unbekannte CA nicht aus Unsichtbarkeit eine Erlaubnis ableitet, kann der erste Layer caa-critical enthalten. Dieses Flag sagt nur, dass eine Policy existiert. Es blockiert die Ausstellung, bis die CA die zweite Schicht entschlüsselt und auswertet.

Alternativ überträgt der Client onionCAA bei der Finalisierung. Der Satz enthält CAA-Text oder null, einen Unix-Ablaufzeitpunkt, der höchstens acht Stunden vorausliegen sollte, und eine Ed25519-Signatur des Onion-Schlüssels. Signiert wird exakt onion-caa|, die dezimale Zeit ohne führende Nullen, | und der CAA-Text; null wird leer dargestellt.

Eine gültige Signatur schreibt der Identität einen frischen Satz zu. Sie bestimmt nicht, welchen Pfad die CA benutzt. Die CA kann nur diesen Satz werten, ihn ignorieren und den Deskriptor lesen oder beides tun. Kann sie Deskriptor-CAA nicht abrufen und fehlt der Satz, antwortet sie onionCAARequired; inBandOnionCAARequired kann die Pflicht im Directory ankündigen.

Tor-Verzeichnisse sind keine Vertrauensanker. Bei beiden Wegen folgt die Integrität aus der Onion-Identität. Für die Revision ist deshalb der tatsächlich geprüfte Satz wichtiger als sein Transportort.

Ein korrektes Zertifikat kann eine schlechte Offenlegungsentscheidung abschließen

Die CA verbindet selbst per Tor. Auch der ACME-Client sollte Tor und, sofern vorhanden, einen Onion-Endpunkt der CA verwenden. Die direkte Verbindung zu bekannten CA-Adressen kann die Existenz eines Onion-Dienstes auf dem anfragenden Host erkennbar machen.

Ein http-01-Redirect in das öffentliche DNS kann IP-Adresse oder Infrastrukturbeziehung offenlegen. Diesen öffentlichen Zielhost darf die CA nicht über einen Tor-Exit validieren, weil sonst Exit-Hijacking die Validierung gefährdet.

Ein öffentlich vertrauenswürdiges Zertifikat veröffentlicht den Onion-Namen schließlich in Certificate Transparency. Für manche Dienste ist das gewollt, für interne Angebote können private oder selbstsignierte Zertifikate genügen. RFC 9799 empfiehlt minimale Teilnehmerdaten und verlangt separate ACME-Kontoschlüssel, wenn eine CA verschiedene Dienste nicht korrelieren soll.

Das Zertifikat ist damit ein Ergebnis, kein vollständiger Prüfbericht. Ein belastbarer Datensatz bewahrt die drei Schlüsselrollen, den dienstspezifischen Deskriptorzugriff, die gewählte CAA-Quelle und jede akzeptierte Offenlegung. Nur dann bleiben die Kontrollflächen auch nach erfolgreicher Automatisierung getrennt.

Quellen