Zusammenfassung

  • Proof-of-Possession nach RFC 10002 weist nach, dass eine Endeinheit den privaten Schlüssel zum öffentlichen Schlüssel besitzt und verwenden kann. Der Nachweis bestätigt allein weder Identität noch Namensberechtigung oder Zertifikatsausstellung.
  • CMC führt Identitäts- und Besitznachweis getrennt und verlangt ihre substitutionssichere Verknüpfung. Eine Registrierungsstelle fügt Änderungen außerhalb des signierten Antrags hinzu; die Zertifizierungsstelle entscheidet nach eigener Richtlinie über Ausstellung, Änderung, Zurückstellung oder Ablehnung.
  • Ein belastbarer Beleg bewahrt Originalantrag, Besitzmethode, Identitätsbeleg, Verknüpfung, jede RA-Hülle, CA-Entscheidung, CMC-Antwort, exaktes Zertifikat sowie Lieferung, Installation, Pfadprüfung und Widerruf als getrennte Zustände.

PKCS #10 kann beweisen, dass die im Antrag enthaltene Signatur zum darin enthaltenen öffentlichen Schlüssel passt. Wer die Daten verändert oder den Schlüssel austauscht, verliert die gültige Signatur. Damit bleibt die Aussage des Antragstellers erkennbar.

Die Aussage kann trotzdem unberechtigt sein. Ein Antragsteller kann einen Schlüssel kontrollieren und einen fremden Dienstnamen nennen. Er kann die richtige Identität haben, aber eine nicht erlaubte Schlüsselverwendung anfordern. Eine Registrierungsstelle kann später eine Erweiterung vorschlagen. Und eine Zertifizierungsstelle kann den gesamten Antrag trotz korrekter Signatur ablehnen.

Diese Arbeitsteilung bildet Certificate Management over CMS ab. RFC 10002 beschreibt die Nachrichten, RFC 10003 den Transport über HTTP, Datei, Mail und TCP, RFC 10004 die Konformitätsanforderungen an Agentenklassen. Alle drei Dokumente erschienen im Juli 2026 mit Joseph Mandel und Sean Turner als gemeinsamen Herausgebern. Das Verfahren baut auf CMS, PKCS #10, CRMF und X.509 auf und ist kein Einzelentwurf Turners.

Sein öffentliches IETF-Profil verzeichnete am 1. September 2026 eine Teilnahme seit IETF 34, mehr als 50 RFCs als Autor oder Mitautor, die Tätigkeit als Security Area Director von 2007 bis 2014 und mehrere frühere oder aktuelle Arbeitsgruppenvorsitze. Diese Laufbahn erklärt den Standardisierungskontext, gibt Turner aber keine Entscheidungsbefugnis über eine konkrete CA, RA oder Antragstellung.

Besitz ist eine Aussage über den Schlüssel

RFC 10002 nennt den Nachweis, dass eine Endeinheit einen privaten Schlüssel besitzt und einsetzen kann, Proof-of-Possession oder POP. Signatur, direkte Challenge-Response, indirekter Nachweis, Veröffentlichung und Attestierung sind mögliche Formen; nicht jede CMC-Transaktion verwendet jede Form.

Die Methoden unterscheiden sich, ihr Gegenstand bleibt der Schlüssel. Ein gestohlener Schlüssel kann korrekt signieren. Ein ordnungsgemäßes Gerät kann einem falschen Inventareintrag zugeordnet sein. Eine Administratorin kann den Schlüssel verwalten, ohne den Organisationsnamen beantragen zu dürfen. Ein automatischer Dienst kann einen neuen Schlüssel mit einem alten Identitätsdatensatz verbinden.

RFC 2986 beschreibt deshalb die Zertifizierungsstelle nicht als Signaturprüfer allein. Sie authentifiziert die antragstellende Einheit, prüft die Signatur und stellt bei einem gültigen Antrag das Zertifikat her. Was gültig ist, hängt auch von Richtlinie, Name, Profil, Zweck und weiteren Belegen ab.

Ein Betriebssystem darf die enge Wahrheit nicht umbenennen. Schlüssel verwendbar ist nicht Identität bestätigt; Identität bestätigt ist nicht Name berechtigt; Name berechtigt ist nicht Ausstellung beschlossen. Jeder Übergang verlangt eine eigene Begründung.

Zwei richtige Belege brauchen eine richtige Verbindung

CMC definiert Proof-of-Identity getrennt. Wenn der Identitätsnachweis mitgesendet werden muss, darf keine Simple PKI Request verwendet werden. Eine Full PKI Request kann einen aus einem gemeinsamen Geheimnis abgeleiteten Witness, ein vorhandenes Zertifikat oder ein anderes bilateral vereinbartes Verfahren nutzen.

Die Trennung schafft Transparenz und eine Angriffsfläche. Die gültige Identität von Person A darf nicht mit dem gültigen POP von Person B zu einem scheinbar vollständigen Antrag verbunden werden. RFC 10002 verlangt deshalb die Gewähr, dass beide Informationen von derselben Einheit stammen. Die Zuordnung von Geheimnis und Subject-Name, der Witness oder die Bindung an ein bestehendes Zertifikat erfüllen diese Aufgabe.

Die Verbindung ist selbst ein Sicherheitsereignis. Zu protokollieren sind beide Kennungen, die abgedeckten Daten, das Verfahren gegen Substitution, die prüfende Stelle, Zeit und Ergebnis. Zwei grüne Anzeigen ohne gemeinsame Referenz belegen keine gemeinsame Herkunft.

Auch ein gemeinsames Geheimnis hat eine Vorgeschichte. Seine Verteilung außerhalb des Protokolls liegt außerhalb von RFC 10002. Wurde es an das falsche Gerät gegeben, zwischen Anlagen kopiert oder bei Wiederholungen zu lange verwendet, beweist ein korrekter Witness nur die Kenntnis dieses Geheimnisses. Der Beleg muss die Grenze des ursprünglichen Registrierungsverfahrens nennen.

Die RA ergänzt den Antrag, ohne ihn umzuschreiben

CMC unterscheidet Endeinheit, Registrierungsstelle (RA) und Zertifizierungsstelle (CA). Eine RA kann lokale Prüfung, Schlüsselerzeugung oder -archivierung, Bündelung, Weiterleitung und Erweiterungsbearbeitung übernehmen. Sie kann gegenüber der Endeinheit Server und gegenüber der CA Client sein. Die Protokollrichtung ändert ihre Befugnisse nicht.

Eine RA darf den signierten PKCS-#10- oder CRMF-Antrag nicht bearbeiten, denn damit würden Signatur und POP ungültig. Gewünschte Änderungen an Feldern oder Erweiterungen trägt sie als äußere CMC-Steuerung ein. Mehrere RAs können mehrere verschachtelte Hüllen erzeugen.

So bleiben zwei Ursprünge sichtbar: Was die Endeinheit signiert hat und was eine Zwischenstelle später beantragt hat. Ersetzt man das Original durch die letzte Fassung, erscheint die Entscheidung der RA fälschlich als Wille des Antragstellers.

Das gilt besonders für X.509-Erweiterungen. Ein Antrag kann Namen, Schlüsselverwendungen, Richtlinien und weitere Felder wünschen. Der Server muss definierte Erweiterungen verarbeiten, aber nicht jede in das Zertifikat übernehmen. Änderungen dürfen die ursprüngliche Bedeutung nicht umkehren. Das ausgestellte Zertifikat ist das Ergebnis einer CA-Bewertung, keine Kopie des Wunschzettels.

Nur das Zertifikat zu speichern, löscht den ursprünglichen Antrag. Nur den Antrag zu speichern, löscht die autorisierte Veränderung. Der vollständige Beleg verbindet signiertes Objekt, äußere Steuerungen, Unterzeichner, Richtliniengrund, ausgewertete Vorlage, Entscheidung und Ergebnis.

Ein HTTP-Erfolg endet an der Transportgrenze

RFC 10003 erlaubt HTTP, Datei, Mail und TCP. Bei HTTP werden definierte Medientypen per POST übertragen. HTTPS kann den Kanal schützen; die Transport-RFC verlangt nicht von jedem CMC-Client eine HTTP-Authentisierung. Kanal, HTTP-Identität, CMC-Identitätsnachweis und POP bleiben verschiedene Kontrollen.

Auch der Statuscode ist lokal. 2xx bestätigt die erfolgreiche HTTP-Verarbeitung. In der CMC-Antwort können dennoch badIdentity, popRequired, popFailed, nicht unterstützte Erweiterungen oder ein wartender Zustand stehen. Die Annahme des Transports ist keine Ausstellungsentscheidung.

Bei einer erfolgreichen CMC-Antwort braucht der Beleg das zurückgegebene Zertifikat. Stimmen öffentlicher Schlüssel, Subject, alternative Namen, Verwendungen, Richtlinien und Laufzeit mit der Entscheidung überein? Wurde es der vorgesehenen Endeinheit geliefert? Ohne diese Bytes bleibt „fertig“ eine Oberfläche, kein Nachweis.

RFC 10004 betrifft wiederum Fähigkeiten einer konformen Agentenklasse. Daraus folgen weder korrekte Einführung, Marktnutzung, Zertifikatsmenge noch die Genehmigung einer konkreten Transaktion.

Nach der Ausstellung beginnt die Betriebsprüfung

RFC 5280 behandelt Vertrauensanker, Zertifizierungspfad, Namen, Richtlinien, Gültigkeit und Widerruf. Lieferung, Installation, dauerhafte Schlüsselverwahrung und lokale Dienstberechtigung kommen hinzu. Jede Stufe hat einen eigenen Zeitstand.

Ein korrekt ausgestelltes Zertifikat kann das Gerät nie erreichen. Ein installiertes Zertifikat kann zum falschen privaten Schlüssel gehören. Ein gültiger Pfad kann zu einem vom Dienst nicht akzeptierten Anker führen. Eine authentisierte Identität kann lokal keine Berechtigung besitzen. Ein späterer Widerruf beendet einen früher gültigen Zustand.

Heng Lus Running-Code Primacy verlangt reproduzierbare Evidenz für die jeweils behauptete Ebene. Für die Registrierung: Antrag, POP, Identität, Verknüpfung, RA-Hüllen, CA-Richtlinie und Antwort. Für den Betrieb: Zertifikat, Schlüsselabgleich, Installationsziel, Pfadergebnis, Statusquelle und Dienstentscheidung.

Ein belastbares Register trennt Antragsteller und Zeit; Schlüssel und beantragte Felder; POP-Methode und Ergebnis; Identitätsmethode und Grenze; Verknüpfung; RA-Änderungen und Signaturen; CA und Richtlinienversion; CMC-Status; Zertifikat; Lieferung und Installation; Widerruf, Ersatz und Korrektur.

Der Wert der von Turner mit herausgegebenen CMC-Texte liegt gerade in dieser Begrenzung. Ein guter Schlüsselnachweis bleibt gut, weil er nicht vorgibt, auch die Ausstellungsbefugnis zu liefern.

Quellen