Zusammenfassung

  • Die IESG genehmigte draft-ietf-acme-device-attest am 30. Juli 2026 als Proposed Standard. Revision 10 liegt beim RFC Editor; eine endgültige RFC-Nummer oder Implementierung wird nicht behauptet.
  • device-attest-01 kann Order-Kennung, attestierten öffentlichen Schlüssel und CSR-Schlüssel verbinden. Die Aussage hängt von Format, Attestierungsstelle und der Abdeckung des Tokens oder der kontogebundenen Key Authorization ab.
  • Der Nachweis autorisiert eine Ausstellung. Er meldet keinen fortlaufenden Gerätezustand; bei datensparsamer Ausstellung kann jede Hardwarekennung im CSR und Zertifikat fehlen.

Was „attestiert“ verschweigt

Ein gültiges Zertifikat wird schnell zur Kurzform für eine viel größere Behauptung: genehmigtes Gerät, sichere Firmware, unveränderter Besitzer und weiterhin geschützter Schlüssel. Die neue Erweiterung macht einen Teil davon prüfbar, nicht das ganze Paket.

Sie ergänzt permanent-identifier für eine typischerweise vom Hersteller vergebene Gerätekennung, hardware-module für Typ und Seriennummer des Kryptoprozessors sowie device-attest-01. IANA zeigt die Einträge bereits mit einem RFC-to-be-Verweis. Das beweist Koordination des Namensraums, keine Produktunterstützung.

Der Server erzeugt ein frisches Token. Üblicherweise verbindet der Client es mit dem Fingerabdruck seines ACME-Kontos zur Key Authorization und lässt diese formatspezifisch attestieren. Für die Ausstellung müssen eine akzeptierte Attestierungsstelle, derselbe öffentliche Schlüssel in Attestierung und CSR sowie dieselbe Gerätekennung in Attestierung und Order zusammenkommen. Gelangt die Kennung in CSR und Zertifikat, gilt ein oktettgenauer Vergleich.

Einige externe Stellen signieren, bevor der ACME-Kontoschlüssel verfügbar ist. Ihr Format deckt nur das Token ab. Das liefert Frische, aber keine Bindung an das Konto. Ein einziges Erfolgsfeld würde diese wichtige Grenze löschen.

Angebotene und erfüllte Challenge

Eine Authorization darf device-attest-01 neben einer anderen Challenge anbieten. Eine davon zu erfüllen kann genügen. Das unterstützt gemischte Gerätebestände, verlangt aber einen dauerhaften Beleg des tatsächlich genommenen Pfads.

Die Fähigkeit des Produkts oder das Angebot des Servers beweist nicht, dass diese Order attestiert wurde. External Account Binding regelt zusätzlich, welches Unternehmenskonto Anträge stellen darf. Es ersetzt weder die Hardwarebindung des CSR-Schlüssels noch verlängert Geräteattestierung die Kontoberechtigung unbegrenzt.

Soll ein Dienst attestierten Ausstellungen mehr Rechte geben, braucht er einen authentisierten Ausstellungsbeleg mit Challenge, Format, Stelle und Bindungskonstruktion. Das gewöhnliche Zertifikat trägt diese Historie nicht automatisch.

Hardwareidentität kann intern bleiben

Revision 10 erlaubt, die beiden Kennungen aus dem CSR wegzulassen. Ein datensparsamer Server darf ihre Aufnahme sogar ablehnen. Die CA kann Hardwarebelege intern zur Genehmigung nutzen und dem Dienst nur eine logische Workload-Identität ausstellen.

Eine dauerhafte Seriennummer im Zertifikat oder Transparenzprotokoll verknüpft Erneuerungen und Präsentationen über lange Zeit. Schlüsselrotation beendet die Korrelation nicht. Die Offenlegung kann irreversibel sein und Geräteaustausch unnötig mit Identitätswechsel koppeln.

Umgekehrt darf ein Relying Party aus einem Zertifikat ohne Kennung keine Attestierung erfinden. Ohne gesonderten Ausstellungsbeleg kennt es weder Format noch Stelle, Challenge oder geprüfte Firmware.

Attestierungen können Firmware, Bootzustand, Betriebssystem und Schutzniveau enthalten. Die CA darf damit ablehnen, doch das Dokument vereinheitlicht die Prüfverfahren nicht. TPM, TEE und OS-geschützter Keystore haben unterschiedliche Eigenschaften. Jeder Wert hat zudem einen Beobachtungszeitpunkt; Zertifikatslaufzeit ist keine Messwertfrische.

Heng Lus Realitätsschichten halten deshalb Genehmigung, IANA-Eintrag, Challenge, Ausstellung, aktuellen Zustand und Zugriff auseinander. Präzision schwächt den Nachweis nicht—sie macht ihn verwendbar.

Quellen