Zusammenfassung

  • draft-ietf-lamps-csr-attestation-29 gestattet einer CA oder RA, zusätzliche Attestierungen anhand ihrer Ausstellungspolitik zu prüfen oder sie ohne Verarbeitung zu verwerfen.
  • Weil sensible Gerätebelege nicht in das öffentliche Zertifikat kopiert werden sollen, belegt das Zertifikat allein keine vorherige Bewertung. Ein geschützter Ausstellungsbeleg könnte den konkreten CSR, die Bewertung und das ausgestellte Zertifikat verbinden.

Das sichtbare Zertifikat ist nur das Ende des Vorgangs

Am 2. September eröffnete die IETF den Last Call für den Entwurf der LAMPS-Arbeitsgruppe; Stellungnahmen sind laut Bekanntmachung bis zum 16. September möglich. Der Datatracker führt Revision 29 weiterhin als Entwurf. Am 6. September wurde eine ARTART-Prüfung zugewiesen, der IANA-Status lautet „Review Needed“. Auch die Dokumenthistorie weist keine Genehmigung als RFC aus.

Der Entwurf ergänzt Zertifikatsanträge nach PKCS #10 und CRMF um Attestierungsinformationen. Ein AttestationBundle enthält eine oder mehrere Aussagen und optional unterstützende Zertifikate. Mindestens eine Aussage sollte eine Attestierung enthalten, die kryptografisch an den öffentlichen Schlüssel im CSR gebunden ist.

Der Transport legt jedoch nicht fest, wie der Empfänger entscheidet. Nach Revision 29 darf eine CA oder RA die Attestierungen für ihre Ausstellungspolitik verifizieren, sie aber ebenso ohne Verarbeitung verwerfen. Eine CA, die solche Angaben akzeptiert oder verlangt, sollte dies in ihrer Certification Practice Statement dokumentieren. Derselbe Container kann daher in zwei Infrastrukturen eine sehr unterschiedliche Rolle spielen.

Einzelne Wahrheiten ergeben noch keine belastbare Zuordnung

Mehrere gültige Aussagen können sich auf unterschiedliche Komponenten, Zeitpunkte oder Schlüssel beziehen. Die CA oder RA bleibt dafür verantwortlich, den Schlüssel an den Antrag zu binden sowie Plattform- und Geräteangaben korrekt zusammenzuführen. Veraltete oder unbestimmte Evidenz darf sie ignorieren. Gerade diese Verknüpfung entscheidet, ob aus mehreren korrekten Behauptungen eine tragfähige Aussage über ein Zielsystem wird.

Die Trennung folgt der RATS-Architektur aus RFC 9334, die Evidence, Appraisal Policy und Attestation Result auseinanderhält. Ein gesonderter Entwurf zur Frische von Attestierungen behandelt Nonces und Zeitbezug. Eine signierte Aussage verrät schließlich nicht automatisch, ob ihr Zustandsbild bei der Zertifikatsausstellung noch aktuell war.

Der Vergleich von Revision 28 und 29 zeigt die Änderungen vor dem Last Call. Er rechtfertigt aber nicht die Behauptung, Revision 29 habe die zentrale Wahl zwischen Prüfen und Verwerfen neu eingeführt. Diese operative Grenze ist bereits in Revision 28 angelegt.

Datenschutz und Nachvollziehbarkeit sind kein Gegensatz

Attestierungen können Hardware, Patchstand, Eigentumsverhältnisse oder andere sensible Betriebsdaten offenlegen. Der Entwurf empfiehlt deshalb nicht, sie in ein öffentliches Zertifikat zu kopieren; bei einer erneuten Veröffentlichung sollen sensible Angaben entfernt werden. Das verhindert, dass die Zertifikatsinfrastruktur nebenbei zu einem globalen Geräteverzeichnis wird.

Der Entscheidungsweg kann dennoch dokumentiert werden. Ein minimaler Ausstellungsbeleg könnte Hashes des kanonischen CSR und des bewerteten Bündels, Kennung und Version der Richtlinie, Frischeurteil, Schlüssel- und Plattformbindungen, genehmigte Ausnahmen, Zertifikatsfingerabdruck und Entscheidungszeit enthalten. Rohdaten blieben getrennt, zugriffsbeschränkt und nur so lange gespeichert, wie es der Zweck verlangt.

Ein solcher Beleg ist ein Governance-Vorschlag von Daniel Kade, keine Forderung der IETF, des CA/Browser Forum oder einer bestimmten CA beziehungsweise RA. Die Code-Signing-Anforderungen des CA/Browser Forum geben Kontext zur Zertifikatsgovernance, sind aber kein Nachweis für die Einführung dieses CSR-Mechanismus.

Quellen