Zusammenfassung

  • draft-ietf-acme-pop-00 verschiebt den Zertifikatsschlüssel in newOrder und ersetzt den CSR in einem optionalen Ablauf durch eine auftragsspezifische pop-Autorisierung.
  • Der Besitznachweis bindet sich an SHA-256 der tatsächlich dekodierten Payload-Bytes. Eine erneute JSON-Serialisierung ist ausdrücklich ausgeschlossen.
  • Identifier-Kontrolle und Schlüsselbesitz bleiben getrennte Autorisierungen; beide müssen gültig sein.
  • Bei ML-KEM bestätigt ein abgeleiteter MAC den Besitz gegenüber dem Server, ist aber kein von Dritten überprüfbarer Nichtabstreitbarkeitsnachweis.
  • Revision 00 ist ein Internet-Draft des Arbeitskreises, kein RFC und kein Implementierungs- oder Einsatznachweis.

{} ist das Ergebnis früherer Festlegungen

Im gewöhnlichen RFC-8555-Ablauf bringt der Client beim Finalisieren einen PKCS-#10-CSR ein. Der neue Pfad lässt nur ein leeres JSON-Objekt zu. Ein nachgereichter csr-Wert wäre fehlerhaft.

Bis dahin muss der Server bereits einen popKey akzeptiert, dessen Besitz geprüft und alle Zertifikats-Identifier autorisiert haben. Der CA bleibt die Entscheidung über die übrigen Zertifikatsfelder. Der leere Body sagt deshalb nicht „keine Prüfung“, sondern „keine neuen Client-Behauptungen an dieser Stelle“.

Das schließt einen späten Austauschpunkt. Es macht den Auftrag zu einer vollständigeren Beschreibung dessen, was der Client erklärt hat. Der Entwurf behauptet dabei keine neue Schwachstelle im normalen Bedrohungsmodell von RFC 8555; er beschreibt eine klarere Architektur und einen Schutz für besondere Umgebungen, in denen ein nicht vertrauenswürdiger Proxy die Finalisierung beeinflussen könnte.

Der Schlüssel wird mit dem Originalauftrag verbunden

popKey enthält den DER-codierten SubjectPublicKeyInfo des gewünschten Zertifikatsschlüssels. Daneben steht genau ein pop-Identifier mit leerem Wert. Er ist kein Zertifikatsname und erscheint später weder im Subject noch im Subject Alternative Name.

Der Server bildet newOrder_hash aus den dekodierten JWS-Payload-Bytes vor der JSON-Verarbeitung. Mehrdeutige Eingaben oder doppelte Schlüssel werden abgewiesen. Der Hash einer neu aufgebauten JSON-Struktur wäre nicht derselbe Beweisgegenstand.

Im Signaturmodus signiert der Client Domain-Präfix, frischen 32-Byte-Nonce und Auftragshash. Im KEM-Modus kapselt der Server zu ML-KEM ein, veröffentlicht ein neues challenge_ciphertext und erwartet einen HMAC, dessen Schlüssel der Client erst nach Decapsulation und HKDF ableiten kann.

In beiden Fällen ist die Antwort an diesen Auftrag gebunden. Eine gültige pop-Autorisierung darf weder vorab erzeugt noch für einen anderen Auftrag wiederverwendet werden.

Eine Autorisierung ersetzt die andere nicht

Die pop-Autorisierung beantwortet nur, ob der Teilnehmer zum Abschluss des Challenges den privaten Schlüssel zu popKey besaß. DNS, E-Mail und andere Zertifikats-Identifier behalten ihre eigenen ACME-Prüfungen.

Der Auftrag wird erst ready, wenn alle Autorisierungen gültig sind. Schlüsselbesitz beweist kein Recht am Namen. Kontrolle über einen Namen beweist keinen Besitz genau dieses Zertifikatsschlüssels. Auch Device Attestation, RATS oder ein Profile dürfen diese Trennung nicht verdecken.

Das ACME-Kontokey bildet eine weitere Ebene. Es authentifiziert die Protokollnachrichten und muss laut Entwurf vom Zertifikatsschlüssel verschieden sein. Ein Kontooperator und ein Anwendungs-HSM können damit unterschiedliche Zuständigkeiten, Lebenszyklen und Wiederherstellungswege behalten.

KEM verändert Audit und Widerruf

Der KEM-MAC beweist dem Server, dass der Client decapsulieren konnte. Weil der Server das Encapsulation-Ergebnis ebenfalls kennt, kann er denselben MAC erzeugen. Das Transcript ist eine interne Entscheidungsgrundlage, keine übertragbare Client-Signatur.

Secret, PRK und abgeleitete Werte müssen kurzlebig bleiben; Ciphertexts dürfen nicht zwischen Challenges wiederverwendet werden. Ein ungültiger Nachweis invalidiert Challenge, Autorisierung und Auftrag. Ratenbegrenzung ist nötig, weil schon die Auftragserstellung eine teure KEM-Operation auslösen kann.

Noch wichtiger ist der Widerruf. RFC 8555 erlaubt Authentisierung mit Konto- oder Zertifikatskey. Ein KEM-Privatkey kann nicht signieren. Geht das Kontokey verloren, fehlt möglicherweise der ACME-interne Widerrufsweg.

Bei STAR bleibt popKey für automatische Verlängerungen bestehen. Einzelne STAR-Zertifikate werden nicht auf dem üblichen Weg widerrufen; das Kontokey beendet den Auftrag. Bei Verlust kann die Ausgabe bis zum Enddatum weiterlaufen. Kurze Laufzeiten, Provider-Recovery und separate CRL-/OCSP-Kanäle sind mögliche Gegenmaßnahmen, aber keine stillen Eigenschaften des Protokolls.

Das Zertifikat bleibt ein eigener Beleg

Die CA muss einen kryptografisch gleichwertigen öffentlichen Schlüssel ausgeben. Identifier kommen aus den gültigen Autorisierungen. Gültigkeit, Key Usage, EKU und weitere Felder bleiben Policy- oder Profile-Sache.

Anschließend müssen Zertifikat und Privatkey installiert, alle Endpunkte aktualisiert und das Ergebnis von außen beobachtet werden. Ein erfolgreicher PoP beweist weder fortdauernde Verwahrung noch Client-Akzeptanz oder Dienstverfügbarkeit.

Revision 00 erschien am 1. September 2026 und kann geändert, ersetzt oder ungültig werden. Es wird keine Unterstützung eines bestimmten Produkts oder einer CA, keine Ausstellung, Interoperabilität, Störung oder Verbreitung behauptet.