Offene Fragen

Label 309 v1 ist eingefroren. Das Wire-Format unter Metadaten-Label 309, die kanonische CBOR-Kodierung, die Algorithmen-Registries, der versiegelte PoE-Umschlag und die Signaturkonstruktion stehen fest: Ein konformer v1-Verifizierer liest jeden v1-Datensatz, und ein konformer v1-Erzeuger gibt Datensätze aus, die jeder v1-Verifizierer akzeptiert. Auf dieser Seite geht es nicht darum, das zu ändern. Sie ist das Verzeichnis dessen, was im Standard heute bestätigt ist und was zukunftsgerichtet bleibt: kryptografische Konstruktionen, die als Kandidaten für eine mögliche künftige Revision vorgesehen sind, und das disziplinierte Verfahren, um eine kryptografische Konstante zu ändern, sobald einer dieser Kandidaten umgesetzt wird.

Nichts hier ist eine Produkt-Roadmap. Jeder Eintrag ist eine technische Entscheidung auf Protokollebene: eine Algorithmenkennung, eine Ableitung, eine Verifizierer-Richtlinie oder eine Versionierungsregel. Wer den Standard implementiert, braucht die feststehende Hälfte, um schon heute eine v1-Implementierung zu bauen, und die zukunftsgerichtete Hälfte, um sie so zu bauen, dass ein künftiger post-quantensicherer oder rein RFC-basierter Nachfolger ein additiver Registry-Eintrag wird und niemals eine Neuentwicklung.

Feststehende Konstruktionen

Diese Punkte sind entschieden. Sie werden hier deutlich genannt, weil sie die tragenden Entscheidungen sind, die eine implementierende Person am häufigsten an einer Stelle bestätigt sehen möchte; die verlinkten Seiten enthalten die vollständige Konstruktion.

Der post-quantensichere KEM ist bereits in v1 enthalten

Der hybride KEM X-Wing (ML-KEM-768 kombiniert mit X25519) ist ab der ersten Veröffentlichung unter der Kennung mlkem768x25519 in der Registry enc.kem registriert. Er ist kein künftiger Kandidat: Er lebt in enc.scheme: 1 neben dem klassischen x25519-KEM, und das On-Wire-Feld enc.kem wählt pro Datensatz den KEM je Slot, die Slot-Form und die Ableitung des Schlüssel-Verschlüsselungs-Schlüssels (key-encryption-key) aus.

X-Wing wird als Black Box genutzt: Die Konstruktion verwendet ausschließlich seine öffentliche Schnittstelle, also Kapseln, Entkapseln und das 32-Byte-Geheimnis, und trifft keine Annahme über das interne Hashen im Kombinierer. Beide KEMs leiten den KEK je Slot unter einer einzigen Salt-Form aus markiertem Hash ab, SHA-256(label || enc.nonce || <Slot-KEM-Material> || pub_R), berechnet über die eigenen Wire-Bytes des Slots: auf dem hybriden Pfad SHA-256("cardano-poe-xwing-kek-salt-v1" || enc.nonce || kem_ct || pub_R). Auf feste 32 Bytes zu hashen, bindet den Umschlag-Nonce, den Chiffretext und den öffentlichen Empfängerschlüssel in den KEK ein und löst zugleich die Parser-Mehrdeutigkeit auf, die ein variabel langer post-quantensicherer Chiffretext bei einem bloßen Verkettungs-Salt erzeugen würde. Exponiert wird ausschließlich die hybride Variante: Reines ML-KEM wird bewusst zurückgehalten, damit der X25519-Zweig die klassische Sicherheit bewahrt, falls ML-KEM-768 jemals gebrochen werden sollte. Siehe Versiegelte PoE und Algorithmus-Register.

Das versiegelte Schlüssel-Commitment bindet den Header und den Hash-Anspruch

Beide versiegelten Pfade legen den Inhaltsverschlüsselungsschlüssel auf ein geschlossenes Transkript fest, serialisiert mit derselben kanonischen CBOR-Funktion, die der übrige Umschlag verwendet, das die Header-Felder und den Klartext-Hash-Anspruch des Elements (hashes_hash) festschreibt. Auf dem empfängeradressierten Pfad (enc.slots) steht das Commitment on-chain: slots_mac ist ein CEK-geschlüsselter HMAC über ein Transkript, das das Scheme, den Pfad, die AEAD- und KEM-Bezeichner, den Nonce, die durchmischte Slot-Menge und hashes_hash trägt – sodass ein Relay einen Chiffretext nicht an eine andere Slot-Menge oder einen anderen Hash-Anspruch anfügen kann, ohne dass die On-Chain-MAC-Prüfung fehlschlägt, noch vor jedem Chiffretext-Abruf. Der Passphrase-Pfad (enc.passphrase) trägt ein gleichwertiges Commitment in einem 32-Byte-Header innerhalb des Chiffretext-Blobs, über ein Transkript, das zusätzlich das Argon2id-Salt und dessen Parameter aufnimmt – sodass jede Manipulation an den KDF-Eingaben die Commitment-Prüfung fehlschlagen lässt. Der Inhalt selbst wird anschließend in einem segmentierten STREAM unter einem aus dem CEK abgeleiteten Inhaltsschlüssel versiegelt; die AAD pro Chunk ist leer, denn jedes Header-Feld ist bereits transitiv an diesen Schlüssel gebunden. Die vollständige Konstruktion finden Sie unter Versiegelte PoE.

Die Bestätigungstiefe ist Verifizierer-Richtlinie

Ein Datensatz ist in dem Moment verankert, in dem seine Transaktion aufgenommen wird; wer als Verifizierer jedoch entscheidet, wie viel Settlement vor der Ausgabe eines Urteils verlangt wird, wendet einen Schwellenwert für die Bestätigungstiefe an. Label 309 macht dies zu einer Verifizierer-Richtlinie, nicht zu einem normativen MUST. Der Standard definiert die maschinenlesbare Oberfläche – eine Transaktion unterhalb des Schwellenwerts wird als pending gemeldet (der typisierte Code INSUFFICIENT_CONFIRMATIONS), nie als failed, und kann sich bei einem erneuten Versuch zu valid auflösen –, während der Schwellenwert selbst (EMPFOHLEN ≥ 15 Blöcke) ein im Deployment konfigurierter Eingabewert ist und keine ins Wire-Format eingebackene Konstante. Ein Verifizierer, der für hochwertige Ansprüche tieferes Settlement verlangt, ist vollständig konform. Siehe Verifizierung.

Die Ed25519-Verifizierung ist strikt

Signaturen auf Datensatzebene MÜSSEN nach den strikten Regeln von RFC 8032 §5.1.7 verifiziert werden, nicht nach der nachsichtigeren ZIP-215-Toleranz für die Stapelverifizierung (batch verification). Die strikte Verifizierung weist nichtkanonische Kodierungen und Punkte kleiner Ordnung zurück, die ein toleranter Verifizierer akzeptieren würde, sodass zwei konforme Verifizierer bei derselben Signatur stets zum selben Urteil kommen. Implementierende müssen sicherstellen, dass ihr Ed25519-Backend im strikten Modus läuft; manche Bibliotheken verwenden standardmäßig die tolerante Variante. Siehe Signaturen.

Kanonisches CBOR ist der Determinismus-Vertrag

Jeder Datensatz wird als kanonisches CBOR gemäß RFC 8949 §4.2.1 kodiert: bevorzugte Ganzzahlformen, Arrays und Maps mit definierter Länge, byteweise sortierte Map-Schlüssel, keine doppelten Schlüssel, keine Tags. Erst der Determinismus sorgt dafür, dass eine über den Body berechnete Signatur einer Implementierung unter einer anderen verifiziert, und dass zwei Erzeuger desselben logischen Datensatzes byte-identische Bytes ausgeben. Das ist über jede konforme Implementierung hinweg nicht verhandelbar und bildet das Fundament des sprachübergreifenden Paritätsvertrags.

Zukunftsgerichtete Kandidaten

Die folgenden Punkte sind Kandidaten, keine ausgelieferten Konstruktionen. Keiner davon ist ein Defekt von v1; keiner ist verbindlich zugesagt. Sie werden festgehalten, damit eine heute gebaute Implementierung Raum für sie als additive Registry-Einträge lässt und damit eine künftige prüfende Stelle erkennen kann, welche Weiterentwicklungen das algorithmenflexible Design bereits vorwegnimmt.

Ein reserviertes alternatives Inhalts-AEAD-Profil

Die Inhaltsschicht des versiegelten PoE in v1 ist chacha20-poly1305-stream64k – RFC 8439 ChaCha20-Poly1305 im segmentierten STREAM-Layout –, die selbst durch einen RFC gedeckt ist; zum formalen Status der aktuellen Inhalts-Chiffre gibt es also keine offene Frage. Reserviert bleibt ein Pfad zu einem anderen Inhalts-AEAD, falls ein Deployment-Kontext jemals eines verlangt. Der Bezeichner aes-256-gcm (NIST SP 800-38D) ist im AEAD-Register zu diesem Zweck reserviert und ist nicht Teil von enc.scheme: 1: Ein Datensatz, der ihn benennt, folgt heute der Regel für unbekannte Umschläge.

Ihn einzuführen wäre eine künftige Konstruktion enc.scheme: 2, die die bestehenden Modelle aus slots[] + slots_mac und dem Passphrase-Commitment beibehält, aber die Inhaltsschicht austauscht und dabei die neue Chunk-Größe, die Ableitung des Inhaltsschlüssels, die Konstruktion des Nonce pro Chunk, die AAD pro Chunk und die Authentifizierung des letzten Chunks für diese Chiffre festlegt. Es ist ein Fallback-Profil, kein Ersatz: Bestehende enc.scheme: 1-Datensätze bleiben gültig, und das Profil darf nicht implementiert werden, bevor eine normative Definition von enc.scheme: 2 und deren Testvektoren existieren.

Reservierte post-quantensichere Signaturalgorithmen

Die KEM-Hälfte der post-quantensicheren Entwicklungslinie ist bereits in v1 enthalten (siehe oben). Die Signatur-Hälfte ist reserviert, aber noch nicht implementiert. Zwei Familien kommen als Kandidaten infrage, die in die bestehende Signatur-Registry eingefügt werden, sobald IETF COSE die post-quantensicheren Algorithmenkennungen stabilisiert:

Da der Signaturalgorithmus eine benannte Kennung im geschützten COSE-Header ist, ist die Registrierung eines Nachfolgers rein additiv: Bestehende Ed25519-Datensätze verifizieren weiterhin, und ein Verifizierer, der einen neuen Signaturalgorithmus nicht kennt, meldet ein Signal „nicht unterstützter Algorithmus", statt den Inhaltsanspruch zurückzuweisen. Eine unbekannte Signatur macht den zugrunde liegenden Existenznachweis niemals ungültig. Siehe Signaturen.

Ein möglicher Veröffentlichungspfad v: 2

Einzelne Ergänzungen, etwa ein neuer KEM, ein neues Inhalts-AEAD oder ein neuer Signaturalgorithmus, sind Registry-Einträge, die das Top-Level-Schema des Datensatzes nicht verändern. Insbesondere eine KEM-Ergänzung ist ein Registry-Eintrag unter enc.scheme: 1 und keine Scheme-Erhöhung; eine Erhöhung von enc.scheme ist für eine KEM-übergreifende Konstruktionsänderung vorbehalten (ein neuer slots_mac oder ein neues Inhalts-AEAD, das auf alle KEMs zugleich zutrifft).

Sammeln sich genügend schemaverändernde Kandidaten an, kann die kumulierte Änderung einen Top-Level-Datensatz v: 2 rechtfertigen, der neben v1 veröffentlicht wird. Beide Versionen blieben gültige Metadaten-Schemas unter Label 309; ein Verifizierer wählt anhand des v-Diskriminators innerhalb des Datensatzes aus. Die Schritte auf dem Weg zur Standardisierung wiederholen sich für die neue Revision. Dies ist die Weiterentwicklung mit der größten Reichweite und wird ausschließlich durch Anhäufung ausgelöst; nichts davon ist terminiert.

Optionale Auflösung der Ablösung über einen Hop

Das optionale Feld supersedes eines Datensatzes verweist über einen Transaktions-Hash auf genau einen früheren Datensatz. Die Auflösung dieses Verweises ist für einen Verifizierer optional. Ein Verifizierer, der bestätigt, dass supersedes strukturell ein 32-Byte-Hash ist, die vorherige Transaktion aber nicht abruft, ist konform, verpasst jedoch die Gelegenheit, die Ablösungskette sichtbar zu machen. Empfehlung: Ein Verifizierer DARF einen Hop auflösen, also den Transaktions-Resolver für den referenzierten Hash erneut abfragen und dessen Existenz und Blockzeit melden, ohne weiter zu rekursieren. Ein Hop genügt; eine tiefere Traversierung liegt in der Verantwortung der aufrufenden Stelle, und eine Ablösung widerruft den früheren Datensatz nie, den die Blockchain für immer eigenständig überprüfbar hält.

Migration einer kryptografischen Konstante

Jede der oben feststehenden Konstruktionen hängt von benannten Konstanten ab: Algorithmenkennungen, HKDF-Info-Zeichenketten, KDF-Salts, AEAD-Nonce-Längen, Labels zur Domänentrennung. Die Bedeutung einer dieser Konstanten zu ändern, ist ein Bruch des Wire-Formats, und der Standard schreibt dafür genau einen disziplinierten Weg vor. Die maßgebliche Regel lautet: Verwenden Sie die Änderung mit der kleinsten Reichweite, die das Problem löst, und ändern Sie niemals stillschweigend die Bedeutung einer bestehenden Konstante unter demselben Namensraum.

Das Verfahren ist additiv und abwärtskompatibel (alte Datensätze verifizieren weiterhin unter den Konstanten, mit denen sie veröffentlicht wurden) und schreitet nach Reichweite fort:

1. Versionieren Sie den Namensraum, nicht den Wert. Eine geänderte Ableitung erhöht das Suffix -vN an jeder Zeichenkette zur Domänentrennung, die sie berührt: HKDF-Info-Zeichenketten (…-v1 → …-v2), HMAC-Nachrichtenpräfixe, Salts und Labels. Eine neue Konstante lebt unter dem neuen Suffix; die alte Konstante bleibt unter dem alten Suffix gültig. Ältere Verifizierer weisen neuere Datensätze am Diskriminator sauber zurück, anstatt sie falsch zu interpretieren.

2. Erhöhen Sie den Diskriminator, der zur Reichweite passt. Eine Änderung, die auf eine einzige Slot-Familie beschränkt ist, wird über enc.kem ausgewählt; eine KEM-übergreifende Änderung der Inhaltsschicht oder der Festlegung auf die Slot-Menge ist eine Erhöhung von enc.scheme; eine Änderung am Schema des Datensatzes selbst ist eine Erhöhung des Top-Level-v. Jeder Diskriminator begrenzt den Bruch auf die kleinste Schicht, die sich tatsächlich geändert hat.

3. Halten Sie Vorgänger verifizierbar. Ältere Datensatzversionen bleiben als eingefrorene Schemas lesbar. Ein Verifizierer wählt die Konstruktion anhand der Versions-Diskriminatoren des Datensatzes selbst aus, sodass eine einzige Implementierung v1 und einen künftigen Nachfolger nebeneinander verifizieren kann. Kein Datensatz hört je auf zu verifizieren, nur weil ein Nachfolger ausgeliefert wurde.

Verwandte Seiten

• Algorithmus-Register: die benannten Kennungen, deren Namensräume bei einer Migration versioniert werden.
• Versiegelte PoE: der hybride KEM X-Wing, die Bindung des Schlüssel-Commitment-Transkripts und die Diskriminatoren enc.scheme / enc.kem.
• Signaturen: die strikte Ed25519-Verifizierung und die Signatur-Registry, der die reservierten post-quantensicheren Algorithmen beitreten würden.