Zusammenfassung

  • RFC 9908 macht aus der EST-Antwort /csrattrs eine präzise Vorlage für den folgenden Zertifikatsantrag statt einer mehrdeutigen Liste von Attributtypen.
  • Die Klarstellung ordnet OID und Wert eindeutig zu, insbesondere bei X.509-Erweiterungen, und führt mit CertificationRequestInfoTemplate eine teilweise ausgefüllte Antragsstruktur ein.
  • Der Client erzeugt weiterhin Schlüssel und CSR; Authentisierung und CA-Richtlinie werden durch die Vorlage weder ersetzt noch vorweggenommen.

RFC 9908 ist seit Januar 2026 ein IETF Proposed Standard und aktualisiert RFC 7030 sowie RFC 9148. Im EST-Ablauf fragt der Client über /csrattrs ab, welche Angaben in seinem späteren CSR erwartet werden. Die frühere Beschreibung ließ bei Kodierung und Zuordnung von CSR-Attributen Interpretationsspielraum. RFC 9908 präzisiert nun die Kodierung von OID zusammen mit dem zugehörigen Wert und räumt besonders die Behandlung von X.509-Erweiterungswerten auf.

Der zentrale Mechanismus ist CertificationRequestInfoTemplate. Der Server darf eine CertificationRequestInfo teilweise vorbelegen. Das kann den Distinguished Name des Subjekts und weitere Anforderungen betreffen. Das Feld subject ist optional: Es ist vorhanden, wenn der Server Anforderungen an RDNs hat. Ein RDN kann den geforderten Namensbestandteil ohne Wert enthalten, wenn der Client diesen Wert liefern soll. Gibt der Server einen RDN-Wert vor, soll der Client genau diesen Wert verwenden. Er darf ihn nicht durch eine lokal passende Alternative ersetzen.

Damit sind ASN.1-Präsenz und -Absenz selbst Teil der Schnittstelle. Ein fehlendes Feld ist nicht pauschal ein Freibrief. subjectPKInfo fehlt, wenn der Server keine Anforderungen an den Schlüssel stellt. Ist es vorhanden, bezeichnet sein Algorithmus den erwarteten Schlüsselpaartyp. subjectPublicKey bleibt normalerweise abwesend. Eine besondere Ausnahme erlaubt einen Platzhalter, wenn die erforderliche Länge des RSA-Moduls ausgedrückt werden muss. Dieser Platzhalter ist nicht der endgültige öffentliche Schlüssel des Clients.

Der praktische Hintergrund liegt im Enrollment für ACP und BRSKI. Für das autonome Kontrollnetz muss der Server einen bestimmten subjectAltName über /csrattrs vermitteln können; RFC 8994 und RFC 8995 liefern dafür den Anwendungskontext. RFC 9908 beschreibt, wie der Client die gewünschte Antragsform erkennen kann. Es signiert oder genehmigt dadurch keinen CSR, ersetzt weder die EST-Authentisierung noch die Entscheidung der Zertifizierungsstelle und legt nicht deren externe Richtlinie fest.

Bytegenaue Interoperabilitätsprüfung

Eine Abnahme sollte die rohe /csrattrs-Antwort sichern und gegen die erwartete ASN.1-Kodierung prüfen: Nachrichtenlängen, Feldreihenfolge, jeden OID, Werttyp und Wertdarstellung. Anschließend wird das Template dekodiert und erneut kodiert; die resultierenden Bytes müssen für die geprüfte Darstellung stabil sein. Gesondert zu testen sind ein fehlendes subject, ein vorhandenes subject mit wertlosem RDN und ein RDN mit vom Server vorgegebenem Wert. Ebenso wichtig sind das Fehlen von subjectPKInfo, sein Algorithmus bei Vorhandensein und der RSA-Platzhalter. Der Platzhalter darf nicht als finaler Schlüssel in den CSR kopiert werden. Abschließend werden CSR, X.509-Erweiterungen und ausgestelltes Zertifikat gegen die Servervorgaben verglichen. Ein erfolgreiches ASN.1-Decoding allein reicht nicht.

Entscheidungsweg für Betreiber

Der Betreiber akzeptiert die Änderung zunächst nur in einer Prüfumgebung, wenn feste Werte byte- und semantisch korrekt weitergegeben werden, offene Felder vom Client regelkonform befüllt werden und die resultierenden Zertifikate die erwarteten Erweiterungen tragen. Bei einer Abweichung von OID, Wert oder Präsenzsemantik wird die Einführung angehalten. Danach werden EST-Authentisierung und CA-Entscheidung separat geprüft. Aus dem Quellenpaket lassen sich keine Aussagen über konkrete Produktunterstützung, Verbreitung oder gemessene Interoperabilität ableiten.

Quellen