Summary

  • RFC 10003 standardisiert HTTP, Datei, E-Mail und TCP als Transportwege für CMC. Ein Transportergebnis beschreibt die Bewegung einer Nachricht, nicht den Ausgang des darin enthaltenen PKI-Vorgangs.
  • 2XX, Mailannahme, eine vorhandene Datei oder ein abgeschlossener TCP-Schreibvorgang beweisen weder CA/RA-Genehmigung noch Ausstellung und Aktivierung des erwarteten Zertifikats.
  • Daniel Kade schlägt einen CMC-Transport-zu-Entscheidung-Beleg vor, der begrenzte Kanalbeobachtungen mit geprüfter Antwort, offenem Status, ausgestelltem Fingerabdruck und Bereitstellung verbindet, ohne Antragsgeheimnisse zu speichern.

Erfolg auf zwei verschiedenen Ebenen

In einer automatisierten Zertifikatsplattform sieht der Vorgang linear aus: Antrag senden, Antwort empfangen, Zertifikat ausrollen. Technisch und organisatorisch sind jedoch mehrere Instanzen beteiligt. Die Transportinfrastruktur bewegt Daten. RA und CA bewerten den Antrag. Ein Zielsystem installiert das Ergebnis.

RFC 10003 standardisiert die erste Aufgabe. Das Dokument definiert HTTP-, Datei-, Mail- und TCP-Transport für Certificate Management over CMS. Nach RFC 10004 müssen alle CMC-Entitäten HTTP implementieren; andere Mechanismen bleiben optional. Damit sind Hüllen, Medientypen und Abläufe interoperabel.

Die fachliche Antwort gehört zu RFC 10002. Eine Full PKI Response kann Erfolg, Fehlschlag, einen offenen oder teilweisen Vorgang, fehlende Unterstützung, eine notwendige Bestätigung oder weitere Schritte melden. Verzögerte Ausstellung kann mehrere Rundreisen erfordern. Das Ende eines HTTP-Austauschs ist deshalb nicht automatisch das Ende der Zertifikatstransaktion.

Ein 2XX spricht nur für HTTP

RFC 10003 verlangt POST für Client-Anfragen und 2XX für erfolgreiche Serverantworten. Der binäre Inhalt trägt festgelegte Medientypen. Eine Full PKI Request verwendet application/pkcs7-mime; smime-type=CMC-Request, eine Full PKI Response den Parameter CMC-Response. Einfache Formen besitzen eigene Kennzeichnungen.

Diese Daten ergeben einen brauchbaren Transportnachweis: Ziel-URI, Methode, Zeitpunkt, Statuscode, Inhaltstyp, Referenz der TLS-Richtlinie und begrenzte Hashes der ausgetauschten Objekte. Damit lässt sich zeigen, dass ein bestimmter Endpunkt eine Anfrage angenommen und eine Antwort geliefert hat.

Der Nachweis sagt noch nichts über die Genehmigung. Eine formal erfolgreiche HTTP-Antwort kann eine CMC-Antwort mit failed, pending oder partial transportieren. Der Webserver hat seine Aufgabe erfüllt, während die Zertifizierungsstelle abgelehnt, vertagt oder nur einen Teil erledigt hat.

Auch die Gegenrichtung ist wichtig: Nicht jeder Nicht-2XX-Code ist eine Ablehnung durch die CA. Ein Proxy, eine Route, HTTP-Authentifizierung oder die Prüfung des Inhaltstyps kann früher scheitern. Wenn keine CMC-Entscheidung beobachtet wurde, darf das System keine erfinden.

Offen ist ein eigenständiger Zustand

pending bedeutet nicht „fast erfolgreich“. PendInfo enthält ein Token und einen empfohlenen Zeitpunkt für die nächste Abfrage. Der Antragsteller muss erneut anfragen. partial lässt unerfüllte Bestandteile offen. Eine verwendete Transaktionskennung bleibt erhalten, bis eine Full PKI Response den Vorgang abschließt.

Das Beweismodell muss diese Offenheit abbilden. Der erste Beleg kann Transporterfolg und ausstehende Entscheidung gemeinsam festhalten. Die spätere Abfrage wird über Transaktion, geschützte Tokenreferenz und eine neue Transportbeobachtung verbunden. Ein verlorenes Token oder eine ausgebliebene Abfrage darf nicht durch Zeitablauf in Erfolg umgedeutet werden.

Wiederholungen verändern zudem die Zahl der Ereignisse. POST ist nicht idempotent. Deshalb verbietet RFC 10003 0-RTT-Early-Data für CMC-Implementierungen mit TLS 1.3 oder QUIC. Nach Verlust einer Antwort kann erneutes Senden eine zweite Zustellung erzeugen. Hash, Nonce und Transaktionskennung helfen, Wiederanlauf, Replay und einen neuen autorisierten Antrag auseinanderzuhalten.

Jeder Transport verführt anders

Beim Dateiverfahren liegt pro Datei genau eine binäre Anfrage oder Antwort; empfohlene Endungen erleichtern die Zuordnung. Das Auftauchen einer Datei beweist dennoch nur, dass ein Prozess sie geschrieben hat. Eine Antwortdatei ist noch kein Beleg dafür, dass sie korrekt geprüft wurde oder eine Genehmigung enthält.

Der Mailtransport verwendet MIME-Hüllen, Dateinamen, Medientypen und Base64-Beispiele. Eine Message-Id, SMTP-Annahme oder Postfachzustellung gehört zum Mailsystem. Den CMC-Status liefert erst der Inhalt. RFC 10003 warnt zudem, dass TLS zum ersten Mail Submission Agent keine authentifizierte oder verschlüsselte Weiterleitung auf allen späteren Hops garantiert. REQUIRETLS kann Schutz über kompatible Relays anfordern, riskiert aber Nichtzustellung bei fehlender Unterstützung.

Über TCP werden binäre CMC-Nachrichten ohne zusätzliche Hülle übertragen. Für pkix-cmc ist Port 5318 registriert. Vor der nächsten Anfrage auf derselben Verbindung muss der Client die vollständige Antwort abwarten. Eine aufgebaute Verbindung oder vollständig geschriebene Bytefolge ersetzt deren Prüfung nicht.

Die Beobachtungen unterscheiden sich je Kanal. Der Kontrollsatz bleibt gleich: Transporttelemetrie darf nicht im Namen der PKI-Entscheidung sprechen.

Nachrichtenschutz und Wegschutz

CMS-Strukturen können Integrität, Authentizität und Vertraulichkeit einer Nachricht schützen. HTTPS schützt eine Verbindung; IPsec, EnvelopedData oder AuthEnvelopedData ermöglichen weitere Schichten. Keine Schicht macht die anderen Beweisfragen überflüssig.

Eine gültige TLS-Verbindung belegt nicht, dass der Antragsteller die gewünschten Namen beanspruchen durfte, dass die RA seine Identität geprüft oder die CA das Profil genehmigt hat. Eine authentische CMS-Nachricht verrät allein nicht, welcher Endpunkt sie empfing, welches Relay versagte oder zu welchem Wiederholungsversuch eine Antwort gehört.

CMC-Clients müssen laut RFC 10003 weder HTTP-Authentifizierung noch Cookies unterstützen. Server können deren Vorhandensein also nicht voraussetzen. Vertrauensaufbau und Ausstellungspolitik bleiben von der Transportmechanik getrennt.

Statt „sicher zugestellt“ sollte ein Bericht präzise Verben verwenden: TLS-Kanal geprüft, CMS-Objekt authentifiziert, CMC-Entscheidung ausstehend, Zertifikat ausgestellt, Fingerabdruck installiert, Dienst mit neuer Identität beobachtet.

Der Transport-zu-Entscheidung-Beleg

Ich schlage einen CMC-Transport-zu-Entscheidung-Beleg vor. Er ist eine Governance-Empfehlung von Daniel Kade, keine zusätzliche Forderung aus RFC 10003.

Abschnitt eins erfasst den Kanal. Bei HTTP sind das Endpunkt, Methode, Zeit, Code, Medientyp, TLS-Richtlinienreferenz und begrenzte Hashes. Bei Mail werden eingereichte Message-ID, Ziel, beobachteter Übergabestatus und Reichweite der Relay-Sicherung notiert. Datei und TCP erhalten Kanal, Richtung, Zeitpunkt und Objekt-Hash. Inhalte, Schlüssel, Zugangsdaten und sensible Topologie bleiben draußen.

Abschnitt zwei beschreibt das Parsing: einfache oder vollständige Anfrage und Antwort, Transaktionskennung, betroffene Body Parts sowie Ergebnis der Integritäts- und Authentizitätsprüfung. Empfangene, aber nicht interpretierbare Bytes schließen die Nachweiskette nicht.

Abschnitt drei bewahrt den CMC-Status. Bei pending verbindet er geschützte Tokenreferenz, empfohlenen Abfragezeitpunkt und die spätere Auflösung. partial trennt erledigte und offene Teile. Fehlerangaben werden auf das operative Minimum begrenzt.

Abschnitt vier entsteht nur bei tatsächlicher Ausstellung. Fingerabdruck, Aussteller, Seriennummer, Public-Key-Referenz, Namen und Gültigkeit werden mit Antrag und Entscheidung verbunden. Die Reihenfolge beigefügter Zertifikate wird nicht vorausgesetzt; ein enthaltenes selbstsigniertes Zertifikat wird nicht automatisch zum Vertrauensanker.

Abschnitt fünf behandelt die Bereitstellung. Installation, Aktivierung und Akzeptanz durch einen nutzenden Dienst sind eigene Beobachtungen. Eine korrekte CA-Ausstellung kann auf ein System treffen, das die falsche Kette lädt oder das alte Zertifikat weiter präsentiert.

Der letzte belegte Schritt zählt

Ein ehrliches Dashboard zeigt nicht nur „fertig“. Es zeigt: POST angenommen, CMC-Antwort geprüft, Antrag offen, Zertifikat ausgestellt, Fingerabdruck installiert, neue Identität im Dienst beobachtet. Jede Aussage hat einen Verantwortlichen und eine Gültigkeitsdauer.

Überwacht werden sollten gebrochene Verknüpfungen: 2XX mit nicht parsebarem Inhalt, als Erfolg gezählte CMC-Fehler, verwaiste Pending-Token, identische Anfragen unter mehreren Transaktionen, Zertifikate mit unerwarteter Schlüssel- oder Namensbindung, Ausstellung ohne Installation und Dienste mit altem Zertifikat.

Der richtige Nenner sind alle begonnenen CMC-Transaktionen. Für jede muss die Organisation den letzten bewiesenen Zustand und seinen begrenzten Beleg benennen können. Eine Quote grüner HTTP-Anfragen misst lediglich die schnellste Schicht.

RFC 10003 schafft gemeinsame Wege für CMC. Verantwortliche Governance wahrt auf diesen Wegen die Grenze zwischen Ankunft und Entscheidung.

Quellen

  1. Lu Heng — Datensouveränität: technische und praktische Realität
  2. Lu Heng — Warum BTW Media existiert
  3. Lu Heng — Vorrang laufenden Codes
  4. RFC 10003 — CMC-Transportprotokolle
  5. RFC 10002 — Certificate Management over CMS
  6. RFC 10004 — CMC-Konformitätsanforderungen
  7. RFC 5273 — Frühere CMC-Transportspezifikation
  8. RFC 5967 — Medientyp application/pkcs10
  9. RFC 8551 — S/MIME 4.0
  10. RFC 9110 — HTTP-Semantik
  11. RFC 9205 — Protokolle mit HTTP bauen
  12. RFC 9325 — Sichere Nutzung von TLS und DTLS
  13. RFC 8446 — TLS 1.3
  14. RFC 9000 — QUIC
  15. RFC 8689 — SMTP REQUIRETLS
  16. RFC 3207 — Sicheres SMTP über TLS