Zusammenfassung

  • RFC 9995 setzt den Hashwert als COSE-Payload ein, verlangt payload_hash_alg im geschützten Header und erlaubt geschützte Hinweise auf Typ und optionalen Ort des Preimage.
  • Signatur oder MAC lassen sich ohne Originalobjekt prüfen. Das Ergebnis bestätigt den kryptografischen Umfang des Umschlags, nicht Verfügbarkeit, exakte Bytes, Semantik, Aktualität, Sicherheit oder Nutzungsbefugnis.
  • Der Verbraucher muss Schlüssel und Zweck zuordnen, kontrolliert abrufen, Originalbytes erhalten, neu hashen und vergleichen, parsen und bewerten, die konkrete Handlung autorisieren und ihre Wirkung beobachten.

Eine Langzeitaufbewahrung besitzt nach zehn Jahren noch eine kleine COSE_Sign1-Struktur. Der darin geschützte Ort antwortet nicht mehr. Zwei Wiederherstellungen tauchen auf verschiedenen Medien auf. Beide tragen denselben Dateinamen, aber nur eine erzeugt den geschützten Digest.

Der Umschlag löst damit eine wichtige Frage und lässt andere offen. Er identifiziert die erwarteten Bytes unter den Annahmen der Algorithmen und des Schlüssels. Er hat den Datenträger nicht verfügbar gehalten, keine Kopie transportiert und nicht entschieden, ob das alte Dokument heute noch als Nachweis genügt.

RFC 9995, im Juli 2026 auf dem IETF Standards Track veröffentlicht, definiert diese Trennung als COSE Hash Envelope. Große Preimages müssen für Remote Signing oder eine spätere Verifikation nicht mit dem kompakten Schutzobjekt reisen. Die Effizienz ist real, gerade weil das Original außerhalb bleibt.

Preimage, Digest und detached Digest

Das Preimage ist die exakte Bytefolge, die in die Hashfunktion ging. Der Digest ist ihr kurzer Output und wird in RFC 9995 zum COSE-Payload. Zusätzlich kann nach den gewöhnlichen COSE-Regeln auch dieser kleine Digest-Payload detached sein und bei der Signaturprüfung extern bereitgestellt werden.

Das Weglassen des großen Preimage ist der Zweck des Hash Envelope. Das weitere Abtrennen des Digest ist ein dritter Transportzustand. Eine Protokollzeile „detached payload supplied“ unterscheidet deshalb nicht, ob der Prüfer den kurzen Hashwert oder das eigentliche Beweisobjekt erhalten hat.

RFC 9052 definiert die COSE-Strukturen. Bei COSE_Sign1 bindet die Signatur die geschützten Header, vom Anwendungsprofil gewählte External Authenticated Data und den vollständigen Payload der Sig_structure. Ungeschützte Header sind nicht entsprechend gebunden. In einer Hash Envelope ist der gebundene Payload der Digest. Das abwesende Preimage tritt nicht durch begriffliche Nähe in die Signatur ein.

Ein Offline-Prüfer darf somit den Umschlag gültig nennen. Er darf das abwesende Objekt noch nicht als passend bezeichnen. Dafür braucht er Kandidatenbytes und eine zweite Berechnung.

Die Labels schützen Koordinaten

payload_hash_alg, Label 258, ist Pflicht. Es muss im geschützten Header stehen und darf nicht im ungeschützten Header erscheinen. Es nennt den Algorithmus des Digest-Payloads.

preimage_content_type, Label 259, ist optional und bei Vorhandensein geschützt. Es bezeichnet Media Type oder CoAP Content-Format des Preimage. Es ist nicht das normale COSE-content_type mit Label 3. Dieses würde den aktuellen Payload, also den Digest, beschreiben. RFC 9995 verbietet Label 3, um die beiden Objekte nicht zu verwechseln.

payload_location, Label 260, kann als Text oder URI einen Fundort angeben. Der Schutz macht eine nachträgliche Änderung erkennbar. Er verspricht nicht, dass der Ort erreichbar, unverändert kontrolliert, vertraulich, sicher oder für den Prüfer zugelassen ist.

Die IANA-COSE-Registry koordiniert stabile Werte und Referenzen. RFC 8126 erklärt die Registrierungsregeln. Registrierung ist weder Implementierungsnachweis noch lokale Zulassung.

RFC 8610 stellt mit CDDL die gemeinsame Strukturgrammatik bereit. Sie kann Formfehler erkennen, aber keine Herkunft oder Befugnis. RFC 7252 liefert den CoAP-Content-Format-Namensraum. Eine Formatnummer wählt höchstens einen Parser; sie bestätigt weder dessen Erfolg noch die Aussage des Inhalts.

Eine gültige Signatur braucht eine gültige Rolle

Kryptografische Gültigkeit bestätigt eine Beziehung zwischen geschützten Bytes, akzeptierten Eingaben, Algorithmus und Schlüssel beziehungsweise Geheimnis. Sie ist notwendig, aber der Schlüssel erklärt seine Identität und Aufgabe nicht selbst.

RFC 9052 überträgt der Anwendung die Zuordnung des Verifikationsschlüssels zur richtigen Identität und die Prüfung ihrer Autorisierung. Ein Testschlüssel, ein Schlüssel für Archivquittungen und ein Schlüssel für Produktionsfreigaben können jeweils mathematisch richtige Signaturen erzeugen. Rollenwechsel, Vertragsende und Widerruf verändern die Befugnis, nicht den historischen Signaturwert.

External Authenticated Data kann Umgebung, Mandant oder Transaktion binden, wenn ein Profil die genauen Bytes festlegt. Ein leerer Kontext erhält durch Signatur keine fehlende Bedeutung.

RFC 9421 signiert ausgewählte HTTP-Komponenten und benötigt ein Anwendungsprofil. Das ist eine Abgrenzung: Hash Envelope signiert keine HTTP-Anforderung und erteilt keine Abrufberechtigung. Beide Mechanismen verlangen eine präzise Aussage über den abgedeckten Zweck.

Auditierbare Zustände trennen Struktur, Kryptoprüfung, Key-to-Identity, Rollenstatus, Zweck und Anwendungskontext.

Der signierte Ort bleibt Eingabe für eine Abrufrichtlinie

Manche Verbraucher besitzen das Preimage bereits. Andere sind offline oder dürfen nur über einen Broker laden. RFC 9995 ermöglicht einen Ortshinweis, erzwingt aber kein automatisches Dereferencing. Ohne Preimage ist die Umschlagprüfung möglich, Bytevergleich und Objektfunktion nicht.

Ein privilegierter Prüfdienst, der jede signierte URI aufruft, verleiht dem Unterzeichner Netzwerkmacht. Redirects können Origins wechseln, Credentials können weitergereicht werden, alte Domains neue Besitzer haben, Antworten Speichergrenzen überschreiten oder nach Dekompression explodieren. Auch ein normalerweise vertrauenswürdiger Schlüssel kann kompromittiert sein.

RFC 9110 trennt HTTP Resource, Representation, Content Coding, Location und Redirection. Eine Abrufrichtlinie muss Schemes, Origins, Redirects, DNS/TLS, Credential-Weitergabe, Zeit, Bytes, Expansion und Netzreichweite begrenzen sowie Endpunkt und Transformationen protokollieren.

RFC 6920 unterscheidet hashbasierte Namen von der Lokalisierung des benannten Inhalts. Mirrors dürfen wechseln, solange sie dieselben Bytes liefern. Ein stabiler Ort darf nicht über abweichende Bytes hinwegtäuschen. Der Ort findet Kandidaten; der Digest entscheidet nach dem Abruf.

Bytegleichheit beginnt mit der Definition des Preimage

Der Prüfer hasht den Kandidaten mit Label 258 und vergleicht mit dem COSE-Payload. Dateiname, Versionsnummer oder Storage-Key ersetzen die Berechnung nicht.

RFC 9530 unterscheidet HTTP Content Digest und Selected Representation Digest. Content Coding kann einer abstrakten Ressource unterschiedliche Bytefolgen geben. Digest-Felder liefern außerdem nicht von sich aus Authentifizierung, Autorisierung oder Datenschutz.

Das Profil muss festlegen, ob die gespeicherte komprimierte Datei, der decodierte Inhalt, eine kanonische Serialisierung oder ein anderer genauer Stream gehasht wird. JSON oder CBOR zu parsen und neu zu serialisieren kann Reihenfolge, Leerraum und Zahlen ändern. Zeilenenden oder transparente Dekompression können das Objekt austauschen.

Der verlässliche Ablauf bewahrt die empfangenen Bytes, erlaubt nur definierte Transformationen, hasht den vereinbarten Input und zeichnet das Ergebnis auf. Ein Match beweist Bytebezug zum geschützten Digest im Sicherheitsrahmen der Algorithmen. Es beweist nicht Aktualität, Vollständigkeit oder Ungefährlichkeit.

Nach dem Match folgen Parser und Urteil

Eine passende SBOM kann syntaktisch unlesbar sein. Sie kann parsebar, aber schemawidrig sein; schemakonform, aber für einen anderen Build; richtig zugeordnet, aber unvollständig; vollständig, aber nach Policy unzulässig.

Der Preimage Content Type bietet Parser-Koordination, kein Sachurteil. Alte Bytes können ihren alten Digest unbegrenzt treffen. RFC 9995 liefert keine universelle Freshness-Regel. Version, Zeit, Audience, Revocation und vorgesehene Handlung müssen aus dem Anwendungsprofil kommen.

Der Standard deckt COSE_Sign, Sign1, Mac und Mac0 ab. Encrypt und Encrypt0 liegen außerhalb. Der Hash Envelope bietet keine Vertraulichkeit und entscheidet nicht über die Reihenfolge einer späteren Verschlüsselungskombination.

Algorithmuskennungen erledigen auch keine Migration. RFC 9053 definiert COSE-Algorithmen und Parameterprüfungen. RFC 9995 verlangt eine zum Payload Hash passende Kombinationsstärke. RFC 7696 beschreibt Agility als aktiven Übergang: Produzenten emittieren Nachfolger, Verbraucher unterstützen Überlappung, Policy setzt Ablehnungsdaten und Langzeitarchive erhalten einen Plan. Parsen ist nicht gleich akzeptieren.

Ausführung liefert die Beweiskette

Heng Lus Running-Code-Prinzip verlangt die tatsächlich ausgeführten Stationen: Preimage-Bytes, Digest, Envelope, Algorithmen, Key, Identität und Zweck, Abrufentscheidung, Transfer, Neuberechnung, Vergleich, Parser, Bewertung, Handlungsfreigabe und Wirkung. Ein Support-Häkchen reicht nicht.

Sein Argument zur minimalen Anfangsspezifikation und lokalen Zukunftsentscheidung passt zur Arbeitsteilung. Gemeinsame Labels und Formen koordinieren Implementierungen. Downloadprivileg, Formate, Freshness, Rollen, Migration, Retention und Rollback bleiben lokale Entscheidungen mit benannten Eigentümern.

Die Unterscheidung der Realitätsebenen hält Parsing, Kryptogültigkeit, Identität, Beschaffung, Bytegleichheit, Bedeutung, Autorisierung und Wirkung auseinander. Eine Ebene verleiht der nächsten keine automatische Befugnis.

Die Quellen belegen Protokoll und veröffentlichte Lehre, nicht Adoption, Performance oder Produktverhalten. Das Archivbeispiel illustriert die Grenze und meldet kein reales Deployment.