Zusammenfassung

  • RFC 9810 trennt accepted – genau das Beantragte – von grantedWithMods: ein ähnliches Ergebnis, dessen Unterschiede der Antragsteller feststellen muss.
  • Nachrichtenschutz, Transaktionskennung und Nonces authentisieren den Austausch, beweisen aber nicht, dass Subjekt, SAN, Gültigkeit, Key Usage, EKU, Constraints und Richtlinie der genehmigten Absicht entsprechen.
  • Ein lokaler Zertifikatsabsichtsbeleg kann Antrag, ausgestelltes Objekt, Felddelta, Änderungsbefugnis und Annahme oder Ablehnung verbinden, ohne private Schlüssel zu speichern. Er ist Daniel Kades redaktioneller Vorschlag, kein CMP-Feld.

In vielen Verwaltungssystemen gibt es nur zwei Farben. Rot steht für Ablehnung, Grün für Erfolg. Eine gültig geschützte CMP-Antwort mit einem signierten Zertifikat wird deshalb leicht als abgeschlossene Aufgabe behandelt. RFC 9810 hält dagegen zwei positive Zustände auseinander, weil exakte Erfüllung und Erteilung mit Änderungen institutionell nicht dasselbe sind.

grantedWithMods ist kein Fehlervorwurf. Eine Zertifizierungsstelle darf ihre Richtlinie anwenden, Laufzeiten begrenzen, Namen normalisieren, Seriennummern vergeben oder Erweiterungen an ein Profil anpassen. Die CA verantwortet, was sie unterschreibt. Der Antragsteller verantwortet, was er akzeptiert und in Betrieb nimmt.

Das Template beschreibt den Wunsch, nicht den Signierbefehl

RFC 9810 erschien im Juli 2025 als IETF-Standards-Track-Dokument. Es beschreibt CMP zur Erstellung und Verwaltung von X.509-Zertifikaten zwischen Endentitäten, Registrierungsstellen und Zertifizierungsstellen. Es ersetzt RFC 4210 und gemeinsam mit RFC 9811 auch RFC 9480.

Mit CertTemplate kann der Antragsteller gewünschte Zertifikatsdaten angeben. Die Struktur entspricht der zu signierenden Zertifikatsstruktur, wobei Felder optional oder situationsabhängig sind. Öffentlicher Schlüssel, Subjekt, Gültigkeit und Erweiterungen lassen sich benennen. Vorher kann sogar ein Request Template abgefragt werden, um Erwartungen der CA zu erfahren.

Vollständigkeit bindet die CA dennoch nicht an eine Bytekopie. RFC 9810 sagt ausdrücklich, dass sie Felder im tatsächlich ausgestellten Zertifikat ändern darf. accepted bedeutet deshalb exakt erfüllt; grantedWithMods bedeutet sinngemäß erfüllt, wobei der Antragsteller die Unterschiede ermitteln muss.

Diese Antwort übergibt eine Entscheidung. Wer beide Zustände in einen booleschen Erfolg umwandelt, gibt die Annahmebefugnis unbemerkt an Softwarevorgaben weiter. Die Frage verschwindet nicht, nur ihr Entscheider wird unsichtbar.

Ein Felddelta kann ein Befugnisdelta sein

RFC 5280 definiert die zu signierende Zertifikatsstruktur mit Seriennummer, Aussteller, Gültigkeit, Subjekt, SubjectPublicKeyInfo und Erweiterungen. Einige Werte sind technische Ausstellerdaten. Andere bestimmen Identität, Zeit und erlaubte Nutzung.

Key Usage trennt digitale Signatur, Verschlüsselung, Schlüsselaustausch, Zertifikats- und CRL-Signatur. Extended Key Usage gibt Zwecke an. Basic Constraints unterscheidet Endentität und CA und kann den Zertifizierungspfad begrenzen. Subject Alternative Names können Dienstidentitäten festlegen. Certificate Policies geben Relying Parties einen Bewertungsrahmen.

Die Materialität ist verschieden. Eine durch die CA vergebene Seriennummer ist normal. Eine kürzere Gültigkeit kann Risiko senken. Eine im Profil vorgesehene Namensnormalisierung kann äquivalent sein. Ein anderer öffentlicher Schlüssel, ein unerwarteter SAN, eine breitere EKU, CA-Signierfähigkeit oder eine unbekannte kritische Erweiterung verändert dagegen die operative Befugnis.

RFC 9810 nennt ein besonders klares Beispiel. Bestimmte EKUs für PKI-Managementrollen delegieren eine Autorisierung, die ursprünglich beim CA-Zertifikat liegt. Die Ausgabe ist daher eine empfindliche Handlung, bei der nur legitime Empfänger berücksichtigt werden dürfen. Hier ist die Feldprüfung unmittelbar eine Prüfung institutioneller Macht.

Ein Hash zeigt nur Ungleichheit. Ein normalisierter Vergleich muss ausweisen, welche Laufzeit, EKU, Identität oder Constraint sich geändert hat. Lokale Regeln entscheiden dann zwischen erwarteter Transformation, benannter Genehmigung, neuem Antrag und Ablehnung.

Authentizität beantwortet nicht die Inhaltsfrage

CMP verbindet Nachrichten durch Schutz, Transaktions-ID und Nonces. Je nach Profil kommen gemeinsame Geheimnisse oder Signaturen zum Einsatz. Proof-of-Possession zeigt Kontrolle über den privaten Schlüssel. Eine RA kann einen Antrag prüfen, autorisieren, zusätzlich schützen, weiterleiten oder ändern.

Ohne diese Kontrollen wäre schon das Vergleichsobjekt fragwürdig. Doch eine Antwort der richtigen CA kann weiterhin eine Änderung enthalten, die der Dienstverantwortliche nicht freigegeben hat. Authentische Herkunft und semantische Übereinstimmung bleiben getrennte Aussagen.

Ändert eine RA den Antrag, muss der Nachweis Ursprung und Transformation trennen: Endentitätswert, RA-Änderung, von der CA signierter Wert und Regelgrundlage. „RA-geprüft“ reicht nicht, wenn unklar bleibt, wo Identität oder Verwendungszweck verändert wurden.

Bestätigung ist eine Annahmeentscheidung

Mit certConf kann der Client gelieferte Zertifikate annehmen oder ablehnen. Fehlt bei einem aufgeführten Zertifikat statusInfo, gilt es als angenommen. Fehlt die zugehörige CertStatus-Struktur, gilt es als abgelehnt; eine leere Sequenz kann alle ablehnen. Auch ein expliziter Ablehnungsstatus mit Zertifikatshash ist möglich.

Das ist mehr als höflicher Protokollabschluss. Es ist der letzte klar reversible Punkt, bevor das ausgestellte Objekt zum normalen Betriebszustand wird. Die Entscheidung muss das reale Zertifikat betreffen, nicht lediglich den Antrag oder die Tatsache einer positiven Antwort.

Das Lightweight-CMP-Profil RFC 9483 zeigt die Folge. Nach accepted oder grantedWithMods sendet die Endentität certConf, und die PKI-Instanz schließt mit pkiConf, sofern keine implizite Bestätigung vereinbart wurde. Bleibt die erwartete Bestätigung aus, ist dies wie eine Ablehnung zu behandeln.

implicitConfirm spart eine Nachrichtenrunde. Es spart keine lokale Prüfung. Bei automatischer Geräteaufnahme müssen erlaubte und verbotene Felddeltas bereits im Evaluator hinterlegt sein. Sonst wird aus einer Latenzoptimierung eine Vorabzustimmung zu unbekannten Änderungen.

Richtlinie erklärt die legitime Transformation

RFC 3647 unterscheidet Certificate Policy und Certification Practice Statement. Die Policy legt Anforderungen für eine Gemeinschaft oder Anwendungsklasse fest; das CPS beschreibt, wie die konkrete CA Verfahren und Kontrollen umsetzt. Ein CMP-Status kann diese institutionelle Begründung nicht vollständig tragen.

Beantragt ein System zwei Jahre Gültigkeit, während das Profil höchstens ein Jahr erlaubt, kann die CA korrekt handeln. Dasselbe Ergebnis kann für den lokalen Dienst trotzdem ungeeignet sein. Entscheidend ist, ob der Antragsteller genau dieses Profil in dieser Version für diese Zertifikatsklasse autorisiert hatte.

Der Nachweis darf nicht jedes CA-eigene Feld zum Verdachtsfall machen. Er markiert ausstellerbestimmte Werte als erwartet und prüft dort streng, wo das ausgestellte Zertifikat die vom Antragsteller autorisierte Reichweite verändert. Ziel ist keine Byteidentität, sondern nachvollziehbare Zuständigkeit.

Öffentliche Sichtbarkeit ist keine Betriebsfreigabe

Certificate Transparency macht Ausstellung beobachtbar. RFC 9162 definiert überprüfbare Append-only-Logs, mit denen verdächtige Zertifikate und CA-Aktivität sichtbar werden. Die Logs verhindern Fehl-Ausstellung jedoch nicht selbst.

Ein CT-Eintrag beweist weder Annahme durch den Antragsteller noch lokale Eignung oder Einsatzfreigabe. Bei einer indirekten Proof-of-Possession-Variante verbietet RFC 9810 sogar, das endgültige Zertifikat vor Eingang des bestätigenden certConf in CT zu veröffentlichen. Ausstellung, Bestätigung und Publikation haben eine feste Reihenfolge.

Auch danach bleibt Deployment eigenständig. Ein angenommenes Zertifikat kann ungenutzt bleiben, nur in einem Dienst laufen oder von einer Relying Party abgelehnt werden. Transparenz schafft Beobachtung, keine universelle Entscheidung.

Der Zertifikatsabsichtsbeleg bewahrt die Entscheidung

Der vorgeschlagene Zertifikatsabsichtsbeleg beginnt mit kanonischen Identitäten für geschützten Antrag, CertTemplate, Profil und ausgestelltes Zertifikat. Er notiert Transaktion und Status, speichert aber weder private Schlüssel noch gemeinsame Geheimnisse, entschlüsselte zentrale Schlüsselpakete oder unnötige Identitätsbelege.

Der Feldvergleich umfasst öffentlichen Schlüssel, Subjekt, SAN, Gültigkeit, Key Usage, EKU, Basic Constraints, Policies, relevante Name Constraints, Kritikalität und anwendungsrelevante Erweiterungen. Jedes materielle Delta erhält eine Disposition: profilerwartet, kompetent genehmigt, abgelehnt oder ungeklärt. Evaluator- und Richtlinienversion bleiben erhalten.

Annahme, Veröffentlichung und Deployment werden getrennt. Der Beleg nennt explizite oder implizite Bestätigung, die zuständige Rolle, Ablauf einer Ausnahme, Rollback-Ziel sowie Widerruf oder Neuausstellung. Korrektur überschreibt den früheren Zustand nicht, sondern ergänzt eine verknüpfte Entscheidung.

Der Beleg ist lokal und zugriffsbeschränkt. Interne Namen, Gerätekennungen und Ausnahmen können selbst bei öffentlichen Zertifikaten eine sensible Infrastrukturkarte ergeben. CT erfüllt eine abgegrenzte öffentliche Aufgabe; der Beleg wahrt interne Entscheidungsherkunft.

Laufender Code muss den Unterschied erhalten

Heng Lus Trennung von Spezifikation, lokaler Entscheidung, Annahme, Ausführung und beobachtetem Ergebnis verhindert, dass Protokollerfolg zur Gesamtvollmacht wird. Der RFC definiert Zustände, die CA stellt aus, der Antragsteller nimmt an, der Dienstverantwortliche setzt ein, und Relying Parties urteilen selbst.

Running-Code Primacy bedeutet nicht, dass eine automatische Installation Legitimität erzeugt. Sie verlangt, die echte Ausführung gegen die behauptete Regel prüfen zu können. Wenn ein Client beide positiven CMP-Zustände zu Grün verdichtet, verwirft er eine Governance-Information des Protokolls.

Weder Änderungen noch Automatisierung müssen verboten werden. Ein Profil kann erwartete Transformationen erlauben, ein Evaluator unzulässige Änderungen stoppen, und eine Ausnahme kann Verantwortlichen und Ablaufdatum erhalten. Gute Automatisierung prüft die ausgestellte Befugnis, nicht die Farbe der Antwort.

Quellen