Zusammenfassung

  • Am 2. September 2026 eröffnete die IESG den Last Call für Revision 29 von Use of Remote Attestation with Certification Signing Requests; Stellungnahmen laufen bis 16. September. Das Dokument zielt auf Proposed Standard, ist aber weiterhin ein Internet-Draft und kein Nachweis für Umsetzung.
  • Mehrere Attestierungen können gemeinsam in einem PKCS-#10- oder CRMF-Antrag reisen. CA oder RA müssen dennoch belegen, dass öffentlicher Schlüssel, HSM, Plattformeigentum, gemessener Zustand und Freshness-Kontext zu einem zurechenbaren Enrollment gehören.

Revision 29 beschreibt den entscheidenden Fehler mit drei Aussagen. Ein Schlüssel wurde in einem HSM erzeugt. Eine Plattform ist Eigentum des Unternehmens. Eine Plattform befindet sich in einem bekannten guten Zustand. Jede Aussage kann stimmen, ohne dass der HSM mit dem CSR-Schlüssel auf genau der Plattform sitzt, deren Eigentum und Zustand geprüft wurden.

Der Entwurf standardisiert dafür einen Transportbehälter. AttestationStatement verbindet eine Typ-OID mit dem eigentlichen Statement. AttestationBundle enthält mindestens ein Statement, darf mehrere aufnehmen und optional Zertifikate mitführen. Ein Top-Level-Bundle wird unter id-aa-attestation als PKCS-#10-Attribut oder CRMF-Erweiterung übertragen.

Damit kommt Evidenz beim Enrollment an; ihre Beziehung entsteht nicht automatisch. Optionale Zertifikate können beim Aufbau eines Validierungspfads helfen. Sie bestimmen weder eine verbindliche Reihenfolge noch den richtigen Trust Anchor oder die maßgebliche Ausgabepolicy. Parsen, Pfadvalidierung und Freigabe sind getrennte Handlungen.

Konkrete Attestierungsformate definiert der Entwurf nicht, auch kein neues Register. Andere Standards oder Hersteller liefern Format und OID. Die OID ist deshalb eine Routingangabe, kein Wahrheitssiegel. Dekodieren ist keine Signaturprüfung; eine gültige Signatur wählt keine Vertrauensstellung; Vertrauen in den Signierer bindet das Statement nicht an den vorliegenden öffentlichen Schlüssel.

Wenn mehrere Verifier dieselbe OID akzeptieren, kann schon das Routing mehrdeutig sein. Der Text nennt getrennte OIDs oder einen vom Format definierten Wrapper-Hinweis. Dieser Hinweis muss geschützt sein. Sonst kann eine Fehlkonfiguration oder Manipulation dieselbe Evidenz zum weniger strengen Verifier lenken.

Die Bindungskette beginnt beim öffentlichen Schlüssel im CSR. Proof of possession zeigt Kontrolle des privaten Schlüssels innerhalb des Antragsprotokolls. Sie sagt nicht, wo er erzeugt wurde, ob er exportierbar ist, wem das Gerät gehört, ob die Plattform integer ist oder ob ein Anspruch auf das Zertifikat besteht.

Ein HSM-Statement schließt nur eine Lücke. Danach braucht die CA/RA einen stabilen Beleg zwischen HSM und Plattform. Der Eigentumsnachweis muss dieselbe Plattform und den relevanten Zeitraum abdecken. Die Zustandsmessung muss ebenfalls dieses Objekt, ihre Epoche und bekannte Referenzwerte identifizieren. Ähnliche Namen oder derselbe Hersteller reichen nicht.

Freshness begrenzt Replay, erzeugt aber keine Objektidentität. Der Begleitentwurf bindet Nonce und CSR in einen gemeinsamen Vorgang: CMP kann den Transaktionskontext verwenden; EST dieselbe TLS-Sitzung oder gespeicherten HTTP-Zustand. Kann die CA/RA den CSR nicht dem früheren Nonce-Austausch zuordnen, darf sie beide nicht als verbunden behandeln.

Bei angeforderter Freshness hat die Nonce 8 bis 64 Oktette; Länge null bedeutet, dass keine Freshness verlangt wird. Ein führender Attester darf dieselbe Nonce an untergeordnete Attester weiterreichen. Damit antworten mehrere Evidence-Objekte auf dieselbe zeitliche Herausforderung, ohne zwingend denselben Schlüssel oder dieselbe Plattform zu beschreiben.

RFC 9334 zieht eine weitere Grenze: Freshness reduziert Replay-Ungewissheit, garantiert aber keinen fortdauernden Zustand. Software, Eigentum und Sicherheitslage können sich nach der Messung ändern. Evidenz hat eine Epoche; ein Zertifikat wirkt meist länger.

Die folgenreiche Entscheidung verbleibt daher bei CA oder RA. Sie wählen zugelassene Formate, Trust Anchors, Referenzwerte, Bewertungsregeln und Ausgabeprofile. Evidenz kann gegen eine von mehreren Policies geprüft oder verworfen werden, wenn sie für die anwendbare Policy ohne Bedeutung ist. Der Entwurf empfiehlt, Anforderungen in der certification practice statement zu dokumentieren.

Die Policy-Version gehört in den Entscheidungsnachweis. Reproduzierbare Protokolle bewahren CSR-Hash und Schlüssel, Statement-Bytes, Signierer, Verifier-Versionen, Referenzwerte, Nonce-Kontext, Eigentumsnachweis, Bewertung, ausgewählte Policy und Freigabeakteur auf.

Das öffentliche Zertifikat ist dafür nicht der richtige Speicherort. Hardwarekennung, Firmware, Patchstand, Eigentum und Lieferkettenzustand können sensible Betriebsdaten offenlegen. Revision 29 rät davon ab, die Attestierung in das Zertifikat zu kopieren. Enrollment-Logs, gespeicherte Bundles und Verifier-Protokolle bleiben dennoch Datenschutzflächen.

Heng Lus Trennung der Realitätsebenen verhindert die bequeme Abkürzung. Entwurfsstatus, gültige Syntax, geprüfte Signatur, positive Bewertung, Ausgabe, Einsatz und Akzeptanz durch eine Relying Party sind unterschiedliche Tatsachen. Ein Mindeststandard koordiniert den Umschlag; operative Wahrheit entsteht erst im nachweisbaren Handeln der verantwortlichen CA/RA.

Quellen