Zusammenfassung

  • RFC 10002 lässt den signierten Antrag der Endeinheit in einer inneren CMS-Schicht unverändert und erlaubt einer Registration Authority, Nachweiszeugen oder Änderungswünsche in einer äußeren PKIData-Schicht hinzuzufügen.
  • Gültige Signatur, Besitz des privaten Schlüssels, Identitätsnachweis, RA-Zeugnis, verarbeitete Änderung und ausgestelltes Zertifikat sind getrennte Urteile.
  • Revisionsfest wird die Kette erst mit Originalantrag, allen CMS-Hüllen, Kontrollreihenfolge, RA-Kompetenz, CA-Richtlinie und einem feldgenauen Vergleich zum ausgegebenen Zertifikat.

Ein Zertifikat kann korrekt signiert sein und trotzdem nicht dem entsprechen, was die Endeinheit beantragt hat. Auch der Antrag kann weiterhin eine gültige Signatur tragen. Der Unterschied muss deshalb weder eine beschädigte Datei noch einen kryptografischen Angriff bedeuten.

Er kann aus einer regulären Entscheidungskette stammen. Eine Registration Authority hat vielleicht die Identität geprüft, den inneren Antrag unangetastet weiterverpackt und eine Feldänderung verlangt. Eine zweite RA hat ein Zeugnis ergänzt. Die Certification Authority hat anschließend ihre eigene Richtlinie angewandt.

RFC 10002, im Juli 2026 als IETF Standards Track veröffentlicht, definiert die Strukturen und Kontrollen von Certificate Management over CMS und ersetzt RFC 5272 sowie RFC 6402. RFC 10003 regelt den Transport, RFC 10004 die Rollenanforderungen. Zusammen zeigen sie: Integrität eines Objekts und Befugnis zur Zertifikatsentscheidung sind benachbart, aber nicht identisch.

Die Signatur hat einen begrenzten Gegenstand

Nach RFC 2986 enthält ein PKCS-#10-Antrag den Subjektnamen, den öffentlichen Schlüssel, optionale Attribute, einen Algorithmus und die Signatur über die Antragsinformationen. Die Prüfung bestätigt, dass die geschützten Bytes unverändert sind und der zugehörige Signaturschlüssel eingesetzt wurde.

Sie bestätigt nicht den rechtlichen Anspruch auf einen Organisationsnamen, nicht den Besitz eines anderen, nicht signaturfähigen Schlüssels und nicht die Pflicht der CA, jede gewünschte Erweiterung zu übernehmen. Ebenso wenig ermächtigt sie eine RA zur Änderung.

Ein Simple PKI Request in CMC kann ein nackter PKCS-#10-Antrag sein. Er darf jedoch keinen Identitätsnachweis mitführen und eignet sich nicht für einen privaten Schlüssel, der nicht signieren kann. Beim Full PKI Request liegt PKIData in SignedData oder AuthenticatedData von CMS.

RFC 5652 erlaubt verschachtelte CMS-Kapselungen. Eine RA muss den signierten PKCS-#10- oder CRMF-Inhalt nicht umschreiben. Sie kann ihn erhalten und eine eigene signierte Außenschicht ergänzen. Bei mehreren RAs entstehen mehrere Schichten.

Die innere Signatur belegt, was die Endeinheit geschützt hat. Die äußere Signatur ordnet eine neue Kontrolle einem Vermittler zu. Ob dieser Vermittler für genau diese Kontrolle zuständig war, bleibt eine eigenständige Autorisierungsfrage.

Schlüsselbesitz ist keine Identität

Proof of Possession fragt, ob ein Akteur den privaten Schlüssel zum beantragten öffentlichen Schlüssel beherrscht. Bei Signaturschlüsseln kann eine Signatur genügen. Bei Verschlüsselungs- oder Key-Agreement-Schlüsseln sind Challenge, spätere Antwort oder Bestätigung möglich. RFC 4211 beschreibt diese CRMF-Verfahren und reserviert raVerified für bestimmte Fälle, in denen eine RA den POP durchgeführt hat.

Der Identitätsnachweis fragt dagegen, wer nach dem Authentisierungsverfahren mit der Transaktion verbunden ist. Identity Proof Version 2 in RFC 10002 kann mit einem Shared Secret einen MAC über Antragsmaterial bilden. RFC 10004 verlangt diese modernisierte Variante.

Wer einen Schlüssel besitzt, darf deshalb noch lange nicht einen bestimmten Firmennamen nutzen. Wer eine Personalakte geprüft hat, hat noch nicht den Schlüssel im angegebenen Hardwaremodul nachgewiesen. Ein einzelnes Feld „verified“ löscht diese Differenz.

RA POP Witness übermittelt der CA die Aussage, dass die RA den Schlüsselbesitz geprüft hat. RA Identity Proof Witness übermittelt einen Identitätsnachweis, auch wenn die CA das Shared Secret nicht kennt oder die Prüfung offline stattfand. Das Zeugnis ist eine neue Behauptung der RA, nicht der ursprüngliche Beleg. Erforderlich sind daher RA, Methode, Ziel, Geltungsbereich, Belegreferenz und Mandatsdauer.

Control Processed ist allgemeiner. Es zeigt Verarbeitung hier oder später an, erklärt aber nicht zwingend, welche Identitätsmethode verwendet wurde. Wo diese Unterscheidung zählt, ist das spezifische Zeugnis die belastbarere Aussage.

Änderung mit erhaltener Herkunft

Modify Certification Request erlaubt einer RA, Felder zu ersetzen oder zu löschen. Der innere Antrag bleibt unverändert; die Änderungsanweisung befindet sich in der äußeren, ihrerseits geschützten Schicht.

Das kann sachgerecht sein: ein Name wird kanonisiert, eine unzulässige Erweiterung entfernt oder ein geprüfter Wert in die CA-Form überführt. Revisionssicher ist es nur mit Ziel-Body-Part, Alt- und Neuwert, Regel und verantwortlicher RA.

Verschachtelte Änderungen werden von innen nach außen angewandt. Für mehrere Kontrollen derselben Schicht schreibt RFC 10002 keine Reihenfolge vor. Wer sich auf die Reihenfolge eines Arrays verlässt, bindet das Ergebnis an eine Bibliothek. Relevante Vorrangregeln brauchen eine eindeutige Gesamtentscheidung oder getrennte, geordnete Schichten.

Die CA bleibt eigenständig. Sie muss nicht jede beantragte Erweiterung aufnehmen und darf Werte gemäß ihrer Richtlinie verändern. Den Sinn einer vom Client verlangten Einschränkung darf sie nicht umkehren. Das ausgestellte Zertifikat ist daher eine neue CA-Entscheidung und keine beglaubigte Kopie des Antrags.

Die Prüfung muss drei Zustände verbinden: Originalantrag, RA-Änderungskette und Zertifikat. Jede Differenz braucht einen Verantwortlichen und eine Regel. Die CA-Signatur nennt den Aussteller, nicht die Herkunft jedes einzelnen Feldes.

Transporterfolg ist kein Ausgabestatus

RFC 10003 definiert Datei-, Mail- und HTTP-Transport. HTTP-Anträge verwenden POST; HTTPS schützt den Kanal. Weder TLS noch HTTP 2XX beweisen die Verarbeitung aller CMC-Kontrollen oder eine endgültige Ausgabe.

Transaktionen können pending oder teilweise abgeschlossen sein. Query Pending setzt die Abfrage fort, Confirm Certificate Acceptance führt den Zustand nach der Lieferung weiter. Kann der Endserver eine verpflichtende Kontrolle nicht erkennen oder verarbeiten, muss das ganze PKIData scheitern. Stilles Weglassen erzeugt einen falschen Erfolg.

Die Transaction ID verbindet Nachrichten. Sender und Recipient Nonce helfen bei Zuordnung und Replay-Schutz. Sie ersetzen keine geschäftliche Idempotenz, verhindern aber, dass ein Wiederholungsversuch ohne Herkunft erscheint.

RFC 10004 verlangt von RAs Modify Certification Request, Control Processed und RA Identity Proof Witness. CAs, die mit RAs arbeiten, müssen die Gegenstellen beherrschen. Das ist ein Fähigkeitsminimum, kein Nachweis für eine konkrete Implementierung oder ein konkretes Mandat.

Nach der Ausgabe gilt RFC 5280 für das X.509-Zertifikat, das Relying Parties später validieren. Die Norm erkennt zusätzliche Fachrichtlinien an und verweist auf die CA-Policy. RFC 7030 beschreibt mit EST außerdem eine andere Enrollment-Architektur. CMC ist ein technisches Modell, keine alternativlose Autorität.

Beweise ohne Geheimnisse zu protokollieren

Ein belastbarer Datensatz beginnt mit kanonischen Bytes und Hash des Originalantrags. Er trennt Format, öffentlichen Schlüssel, Signaturprüfung, POP-Methode, Identitätsmethode, Prüfer, Ergebnis und Policy-Version.

Für jede RA-Schicht werden signierte Hülle, RA-Zertifikat, Kompetenzbereich, hinzugefügte Kontrollen, entfernte Schichten und nächster Empfänger erhalten. Änderungen brauchen Vorher/Nachher; Zeugnisse nennen die zugrunde liegende Beweisart. Private Schlüssel und rohe Shared Secrets gehören nicht ins Protokoll.

Die CA ergänzt Feldentscheidungen und Diff. Transaction ID, Nonces, Wiederholungen, Pending-Status, Annahme, Veröffentlichung und Aktivierung bleiben verbunden.

Das ist bei einer kompromittierten RA entscheidend. Der innere Antrag kann authentisch bleiben, während der Angreifer eine bösartige Außenschicht mit einem anerkannten RA-Schlüssel signiert. Keine Fälschung des Antrags bedeutet nicht keinen Missbrauch.

Running-Code Primacy verschiebt den Maßstab auf die tatsächlich laufende Prüfung von Schicht, Rolle und Ergebnis. Minimum Initial Specification hält gemeinsame Mechanismen eng, während Richtlinienentscheidungen bei verantwortlichen Betreibern bleiben. Die Unterscheidung von Realitäts- und Symbolebene verhindert, dass „signiert“, „bezeugt“ oder „ausgestellt“ zu einer universellen Sicherheitsbehauptung wird.