Zusammenfassung

  • RFC 9908 erlaubt feste Werte, geforderte Feldtypen und vom Client auszufüllende Lücken in einer Vorlage für einen späteren PKCS-#10-Antrag.
  • Die Antwort belegt eine Bauanweisung. CSR-Signatur, Schlüsselbesitz, Client-Authentisierung, Namensautorisierung, CA-Entscheidung, ausgestelltes Zertifikat, Installation und Nutzung bleiben eigenständige Beweise.

Ein Gerät hatte lediglich /csrattrs abgerufen, doch das Betriebsportal zeigte bereits „Identität genehmigt“. Die Antwort enthielt eine feste Organisationseinheit, einen vom Gerät einzutragenden Common Name, P-256 als Schlüsselvorgabe und eine offene Adresse in der Subject Alternative Name Extension. Beschrieben war ein gewünschter Antrag. Weder war er signiert eingereicht noch der Client für die Einschreibung authentisiert oder eine Ausstellung entschieden.

Das Beispiel ist hypothetisch. Es zeigt eine typische Verwechslung: Je strukturierter eine Anweisung ist, desto leichter wird ihr die Autorität späterer Schritte zugeschrieben. RFC 9908 beseitigt eine technische Mehrdeutigkeit. Er erklärt die Vorlage nicht zur Genehmigung.

Das Dokument aktualisiert EST aus RFC 7030 sowie EST über CoAP aus RFC 9148. Ein Client konnte bereits abfragen, welche Attribute Server oder Zertifizierungsstelle in einem Antrag erwarten. Uneinheitlich verstanden wurde, wie nicht nur OIDs, sondern konkrete Attributwerte, besonders X.509-Erweiterungswerte, übermittelt werden.

Der neue CertificationRequestInfoTemplate ähnelt dem Informationsteil eines PKCS-#10-Antrags, jedoch ohne Signaturhülle und mit bewusst optionalen Feldern. Er ist eine teilweise ausgefüllte Form für den späteren CSR, nicht der fertige Antrag und erst recht nicht das Zertifikat.

Fehlen und Vorhandensein tragen Bedeutung. Hat der Server keine Anforderungen an den Distinguished Name, fehlt subject. Fordert er einen RDN-Typ, steht dieser in der Vorlage. Typ plus Wert bedeutet, dass der Client den Wert verwenden soll; ein Typ ohne Wert fordert eine geeignete Ergänzung durch den Client. Fehlt subjectPKInfo, äußert der Server dort keine Schlüsselanforderung. Ist es vorhanden, benennt der Algorithmus den erwarteten Schlüsseltyp. Für eine RSA-Größe kann ein Platzhalter die gewünschte Moduluslänge ausdrücken.

id-aa-extensionReqTemplate überträgt diese Trennung auf Erweiterungen. Der Server nennt die Extension-ID und kann ihren Wert vollständig, gar nicht oder teilweise vorgeben. Ein SAN kann also einen festen Namen und einen vom Client einzusetzenden Wert enthalten. Der Anwendungsfall des Autonomic Control Plane in RFC 8994 benötigt gerade die Übermittlung eines bestimmten subjectAltName.

Die bestehende CsrAttrs-Struktur auf dem Draht bleibt erhalten. Die Vorlagenversion ist v1; mehrere id-aa-extensionReqTemplate-Attribute sowie die Kombination mit id-ExtensionReq sind unzulässig. Auch der CoAP-Transport erhält dieselbe Klarstellung. Das sind Syntax- und Interoperabilitätsregeln, keine Identitätsrechte.

RFC 7030 zieht die institutionelle Grenze. Die Abfrage der CSR-Attribute ist optional, und für die bloße Antwort soll der Server üblicherweise keine Client-Authentisierung oder -Autorisierung verlangen. Unabhängig vom Inhalt dürfen EST-Server und CA einen späteren Einschreibungsantrag aus jedem Grund ablehnen. Eine Bauvorschrift ist kein Anspruch auf Ausstellung.

Mit dem signierten CSR kommen andere Prüfungen hinzu. Der Server authentisiert den Client und prüft, ob er den verlangten Dienst nutzen darf. Die CSR-Signatur liefert, soweit der Mechanismus passt, einen Besitznachweis für den privaten Schlüssel. EST kann diesen Beweis zudem mit der authentisierten TLS-Sitzung verknüpfen. RFC 5272 liefert den breiteren CMC-Rahmen für Besitznachweise und Zertifikatsverwaltung.

Drei Fragen dürfen nicht zu einer verschmelzen. Beherrscht der Antragsteller den privaten Schlüssel? Welche Identität hat der Einschreibungskanal authentisiert? Darf diese Identität ein Zertifikat mit diesen Namen, Erweiterungen und Nutzungen erhalten? Schlüsselbesitz verleiht keinen DNS-Namen; ein authentisiertes Konto autorisiert nicht jeden vorgeschlagenen SAN.

Die lokale CA-Policy kontrolliert die Ausstellung. RFC 7030 erlaubt sogar eine manuelle Prüfung mit HTTP 202, solange die Entscheidung aussteht. PKCS #10 beschreibt ebenfalls, dass die CA den Antragsteller authentisiert, die Signatur prüft und bei einem gültigen Antrag das Zertifikat unter Einbeziehung eigener Entscheidungen und weiterer Informationen erzeugt. Ein formal korrekter CSR kann abgelehnt, aufgeschoben oder verändert werden.

Das signierte Zertifikat ist deshalb ein neues Artefakt. Seriennummer, Laufzeit, Aussteller, Erweiterungen und Beschränkungen sind daraus zu lesen, nicht aus der Vorlage abzuleiten. Erst der Vergleich von Vorlage, abgeschlossenem CSR, Entscheidungsprotokoll und Zertifikat zeigt, was festgelegt, ergänzt, akzeptiert, geändert oder hinzugefügt wurde.

Auch Ausstellung ist noch kein Betrieb. RFC 5280 beschreibt X.509-Profil und Pfadvalidierung bei den vertrauenden Parteien. Ein Zertifikat kann in einer Warteschlange bleiben, am falschen Endpunkt landen, neben seinem Vorgänger bestehen oder an einer Gegenstellen-Policy scheitern. Installationsbestand und beobachtete Handshakes sind spätere Nachweise.

Ein belastbarer Auditdatensatz ist daher eine Kette. Er enthält die exakten /csrattrs-Bytes, Serveridentität, Abrufzeit, Cachefrist und den Vorlagenhash. Feste Werte, Client-Lücken und fehlende Felder werden unterschieden. Der fertige CSR wird an die tatsächlich verwendete Vorlagenversion gebunden; Signaturprüfung, Besitznachweis, authentisierte Identität, Autorisierungseingaben, Policy-Version, CA-Entscheidung, Zertifikatsfingerabdruck, Installationsziel und Beobachtungsfenster folgen getrennt.

Ein fehlendes Feld beweist nur, dass der Server über dieses Feld keine Anforderung formulierte. Es beweist nicht die Zulässigkeit jedes späteren Werts. Ein fester SAN belegt die Anweisung, diesen Namen zu beantragen, nicht die Herkunft des Rechts, ihn zu autorisieren. Diese Provenienz gehört außerhalb des ASN.1 in den Entscheidungsnachweis.

Bits-on-the-wire-Kompatibilität garantiert keine Flottenkompatibilität. Ältere Clients können neue Attribute oder teilweise Werte falsch behandeln. Vor der Einführung sind Versionen zu inventarisieren, stilles Verwerfen unbekannter Vorgaben zu erkennen und die ältere Form als bewusste Policy-Option zu definieren.

Rücknahme hängt von der erreichten Schicht ab. Eine fehlerhafte Vorlage lässt sich stoppen, ein Cache leeren, ein offener CSR ablehnen. Nach Ausstellung und Installation entfernt die alte Vorlage keine Zertifikate. Sperrung, Ersatz, Offline-Geräte und das Verhalten vertrauender Stellen erfordern eigene Entscheidungen.

Heng Lus Vorrang laufenden Codes trennt Veröffentlichung von Ausführung. Minimale Anfangsspezifikation, lokalisierte spätere Entscheidung und freiwillige Übernahme verhindern, dass eine schmale gemeinsame Semantik zu stillschweigender Autorität anwächst.

Die Realitätsebenen unterscheiden Anweisung, Antrag, Besitz, Identität, Autorisierung, signiertes Artefakt und beobachteten Betrieb. Die Analyse zu technischer und praktischer Datensouveränität ergänzt: Technische Fähigkeit ist keine rechtliche oder organisatorische Befugnis. Einen Namen in einen CSR zu schreiben begründet keinen Anspruch auf ihn.

RFC 9908 verbessert EST, weil der Server genauer sagen kann, was der Client bauen soll. Eine verlässliche Architektur bewahrt diese Begrenzung. Die Vorlage weist an, der Client ergänzt und signiert, der Server authentisiert, die Policy autorisiert, die CA stellt aus, der Betreiber installiert, die Gegenstelle validiert. Vertrauen entsteht, wenn jeder Übergang belegt werden kann.

Quellen