Zusammenfassung

  • Das Dateiprofil von RFC 10003 hält einen CMC-Gegenstand eindeutig fest, aber nicht die lokale Berechtigung, seine Folgen zu beschließen.
  • Wer eine Datei besitzt oder weitergibt, besitzt damit weder CA-Rolle noch einen Beleg für Ausstellung.

Dateien verführen zu einer besonderen Form von Gewissheit. Sie sind kopierbar, archivfähig und oft das erste Artefakt, das bei einer Untersuchung auf dem Tisch liegt. RFC 10003 beschreibt für CMC genau eine nützliche, begrenzte Rolle: Eine Datei enthält eine binäre CMC-Anfrage oder eine binäre CMC-Antwort. Diese Eindeutigkeit ist wertvoll. Sie erlaubt, den transportierten Gegenstand zu benennen, zu prüfen und über Mediengrenzen hinweg zu bewegen.

Sie beantwortet jedoch nicht die Frage, wer entscheiden durfte. Eine Datei kann beweisen, dass bestimmte Bytes zu einem bestimmten Zeitpunkt vorlagen. Sie kann nicht aus sich heraus beweisen, dass der Empfänger als Zertifizierungsstelle handelte, dass eine Registrierungsstelle eine Berechtigung bestätigte oder dass die im lokalen Regelwerk verlangten Kontrollen erfüllt waren. Auch eine vollständige Antwortdatei ist zunächst ein Ergebnis der CMC-Kommunikation, nicht automatisch ein Ausstellungsakt.

Der Vergleich mit den anderen Bindungen macht das sichtbar. Für HTTP schreibt RFC 10003 einen POST des Clients und bei erfolgreicher Transportverarbeitung eine 2XX-Antwort vor. Für TCP werden binäre Nachrichten direkt ausgetauscht; der Client wartet auf die vollständige Antwort, bevor er auf derselben Verbindung die nächste Anfrage sendet. Der Mailtransport kann denselben Gegenstand in eine passende Hülle legen. Die Medien unterscheiden sich erheblich, doch die autoritative Aussage bleibt in jedem Fall klein: So wurde der Gegenstand ausgetauscht.

Ein Archiv darf daher nicht zum Ersatz für einen Entscheidungsnachweis werden. Eine Hash-Prüfung einer CMC-Datei kann deren Unverändertheit in einer Kette belegen. Sie kann nicht entscheiden, ob der in ihr genannte Name genehmigt werden sollte, ob eine Prüfung abgebrochen wurde oder ob ein Zertifikat tatsächlich bereitgestellt wurde. Diese Fakten entstehen in einer lokalen Entscheidungsumgebung und müssen dort nachvollziehbar bleiben.

Auch die Sicherheitsgrenzen des Standards sprechen gegen eine Überdehnung. HTTP-Authentifizierung und Cookies sind für die HTTP-Bindung nicht erforderlich. Bei TLS 1.3 oder QUIC ist 0-RTT für CMC über HTTP verboten, weil POST nicht idempotent ist. Wiederholungsschutz kann je nach Umgebung nötig sein. Das sind präzise Aussagen darüber, wie eine Übergabe abgesichert werden muss. Sie sind keine universelle Aussage darüber, welche Identität die Übergabe legitimiert.

Im Mailpfad gilt entsprechend: TLS am ersten SMTP-Hop behauptet nichts über Authentisierung oder Verschlüsselung späterer Hops. CMS oder S/MIME können Inhalte schützen, doch ein geschützter Inhalt transportiert keine Zuständigkeit. Das Protokoll hält die Grenze offen, die eine Organisation selbst durch Rollen, Richtlinien und überprüfbare Freigaben schließen muss.

Für die Praxis bedeutet das: Die Datei gehört in die Beweiskette, aber sie ist nicht die ganze Kette. Neben ihr müssen Zuständigkeit, Richtlinienpfad, Prüfentscheidung und das konkrete Zertifikatsergebnis stehen. Erst diese Verbindung lässt aus einem technischen Artefakt einen belastbaren Verwaltungsnachweis werden.