Zusammenfassung

  • Das W3C teilt w3.org/2026/08/xmldsig-more# XML Security zu, verweist aber auf die jeweils neueste Entwurfsfassung statt auf eine nummerierte Version mit Hash.
  • In -08 stand noch w3.org/tbd#; -09 ersetzte den Platzhalter am 21. August durch den neuen Namensraum und ergänzte weiteres Material. Die W3C-Seite ist zwei Tage älter.
  • Die eigene W3C-Leitlinie verlangt eine Regel dazu, wie Namen definiert oder entfernt werden und wer dies entscheidet. Die neue Seite enthält sie nicht; Schweigen beweist weder Veränderlichkeit noch Unveränderlichkeit.
  • Eine Namensraum-Verfassung sollte Zuteilung, Version und Hash verbinden, erlaubte Änderungen vor dem Einfrieren ordnen, Kompatibilität und Entscheider benennen und die Zustände von W3C, IETF und IANA trennen.
  • Es gibt keinen Beleg für eine ungültige Zuteilung, eine Algorithmusbilligung, IETF-Adoption, IANA-Verzögerung oder gescheiterte Zusammenarbeit. Es fehlt die öffentlich lesbare Verwahrungskette.

Zwei Tage zwischen Adresse und Text

Die W3C-Seite des Namensraums erklärt, der URI sei XML Security zugeteilt, verknüpft ihn über den Datatracker mit RFC 9231bis und nennt Simone Onofri sowie den 19. August 2026 als letzte Überarbeitung. Sie nennt keine Entwurfsnummer, keinen Hash, keinen öffentlichen Zuteilungsakt und keine Regel für lokale Namen.

Eine frühe Zuteilung ist kein vorzeitiges Gütesiegel. Sie ersetzt behelfsmäßige Marker, verhindert Kollisionen und ermöglicht die gemeinsame Prüfung mehrerer Spezifikationen. Das W3C kann eine dauerhafte Adresse bereitstellen, ohne den technischen Inhalt zu billigen.

Ein dynamischer Link beantwortet jedoch nur, wo der Text heute steht. Er beantwortet nicht, welcher Stand der Genehmigung zugrunde lag und welche späteren Änderungen sie noch umfasst. Auffindbarkeit und Autorität sind verschiedene Funktionen.

Aus dem Workshop wurde ein offener Arbeitsfaden

Das W3C-Strategy-Issue 484 begann am 17. November 2024 als Vorschlag für einen Workshop zu Post-Quanten-Kryptografie in XML Signature und XML Encryption. Es dokumentiert offene Koordination, aber keine Recommendation, Charta oder formale Übergangsentscheidung.

Am 21. November 2024 bot der Autor des individuellen Entwurfs an, Algorithmen in RFC 9231bis aufzunehmen. Am 14. Juni 2025 wurden HSS/LMS, ML-DSA, SLH-DSA und ML-KEM aufgelistet; zugleich stand im Raum, statt des Workshops das Issue zu nutzen. Beides sind produktive Beiträge, aber weder W3C-Konsens noch IETF-Adoption.

Am 17. August 2026 hieß es, -08 enthalte die vier verfolgten Familien und -09 werde um weiteres Material ergänzt. Die Namensraumseite ist vom 19. August. Der Autor meldete -09 am 21. August. Am 26. August wurde das Issue nicht mehr als Workshopvorbereitung, sondern als Nachverfolgung des Aktualisierungsbedarfs beschrieben.

Diese Anpassung spricht für lebendige Zusammenarbeit. Sie begründet zugleich den Bedarf an einem eigenständigen Versionsbeleg: Forum, Beteiligte und Text können wechseln, während der URI bleibt.

Welche Bytes das W3C prüfte, lässt sich nicht belegen. Ebenso wenig lässt sich das Fehlen interner Unterlagen behaupten. Sicher ist nur, dass die öffentliche Seite die Verbindung nicht zeigt.

Autorenabsicht und institutioneller Stand

Der Datatracker führte -09 zum Stichtag als aktiven individuellen Internet-Draft mit I-D Exists, ohne definierten RFC-Stream und ohne verantwortlichen Area Director. Ein Internet-Draft ist legitime offene Arbeit, aber keine IETF-Adoption.

Im Kopf des Dokuments stehen Independent, Obsoletes: 9231 (if approved), die angestrebte Kategorie Standards Track und das Ablaufdatum 22. Februar 2027. Der Kopf beschreibt Ziel und bedingte Wirkung aus Autorensicht. Der Datatracker beschreibt den zurechenbaren Verfahrensstand. Die beiden Angaben widersprechen sich nicht.

Die archivierte Fassung -08 vom 26. Mai verwendete für die neuen Identifikatoren noch w3.org/tbd#. Ihr SHA-256 lautet cd9d7a31d66dabcb692b2bba3804102b5bba9e3376b999b0cb1404a20ff7f10f.

Die Fassung -09 vom 21. August ersetzte diese Marker durch w3.org/2026/08/xmldsig-more#, ergänzte ein Schema für die neue Generation und enthielt weitere Änderungen. Ihr SHA-256 lautet 09d36d24b05cbc0c1be1579d65fab88e6f9b6cfc13f214d55d4eeed42ad3866b.

Die öffentliche Versionshistorie bestätigt beide Daten, ohne eine Working-Group-Adoption, Stream-Zuordnung oder Zuständigkeit eines Area Director auszuweisen.

Belegt ist damit die Reihenfolge: Platzhalter in -08, W3C-Seite am 19., echter URI in -09 am 21. Nicht belegt sind Entscheidungsdatum, geprüfte Bytes oder der Umfang der Erlaubnis für alle weiteren Änderungen in -09.

Drei Zuständigkeiten dürfen nicht zu einer Freigabe verschmelzen

Der genehmigte Bezugspunkt bleibt RFC 9231. Er dokumentiert die vorige Generation und trennt bereits den Identifikator vom offiziellen Status eines Algorithmus bei W3C oder IETF.

Das IANA-Register XML Security URIs verweist weiterhin korrekt auf RFC 9231, nutzt Specification Required und nennt Designated Experts. Solange ein Nachfolger nicht genehmigt oder ein anderer gültiger Weg beschritten ist, ist dies weder Rückstand noch Ablehnung.

Das W3C verwaltet den URI in seinem Webraum. Das IETF-Dokumentverfahren kann eine Spezifikation entwickeln, übernehmen, prüfen und gegebenenfalls genehmigen. IANA wendet die Registerregel an. Ein Entwurfsautor kontrolliert Text, nicht die W3C-Namensraumpolitik. W3C teilt eine Adresse zu, genehmigt damit aber keinen RFC. IANA pflegt Einträge, ordnet aber keine Einführung an.

Die fehlende Übergabeakte soll diese Grenzen verbinden, nicht aufheben.

Die allgemeine W3C-Regel stellt bereits die richtige Frage

Der W3C-Leitfaden für Namensräume erkennt datierte Formen an und erklärt, dass @w3c/transitions sie im Rahmen von Pull Requests in w3c/ns zuteilt und autorisiert. Dauerhafte Identifikatoren während der Diskussion sind nützlich; Zuteilung bedeutet keine Billigung.

Der Leitfaden verlangt zugleich, dass Gruppen klar beschreiben, wie sich kontrollierte Namensräume ändern oder nicht ändern werden, und dies im Namensraumdokument oder über einen klaren Link zugänglich machen.

Das TAG-Finding präzisiert: Ist ein Namensraum nicht unveränderlich, sollte die Spezifikation erklären, wie Namen definiert oder entfernt werden und durch wen. Ohne ausdrückliche Aussage darf Unveränderlichkeit nicht vermutet werden.

Auch das Gegenteil folgt nicht aus dem Schweigen. Die Seite gewährt keine offene Änderungsbefugnis. Der öffentliche Zustand bleibt schlicht unbestimmt.

Die W3C-Richtlinie zur URI-Persistenz schützt datierte Ressourcen, lässt aber Änderungen mit Archivierung früherer Zustände zu. Beständigkeit der Adresse ist nicht Unveränderlichkeit des Vokabulars.

Das belegt keinen Regelverstoß. Möglich sind gültige, nur nicht verknüpfte Unterlagen. Der geforderte Schritt ist Veröffentlichung an der Stelle, auf die Nutzer ohnehin verwiesen werden.

Frühere Generationen haben einen benannten Gefrierpunkt

-09 bezeichnet den Präfix von 2000 als „Frozen by W3C“ und verbindet die Generationen 2001, 2007 und 2021 mit RFC 4051, RFC 6931 und RFC 9231. Einfrieren ist dort ein historisch zurechenbarer Akt.

Für 2026 bleibt offen: Dürfen Namen vor einem RFC hinzukommen oder entfallen? Bleibt eine bereits zitierte Schreibweise reserviert? Friert eine RFC-Genehmigung automatisch ein oder braucht es einen W3C-Akt? Benötigt eine spätere Erweiterung eine neue Datumskennung?

Die Antworten müssen nicht von außen vorgegeben werden. Sie sollten jedoch feststehen, bevor installierte Abhängigkeiten sie faktisch erzwingen.

Ein URI ist kein Kryptografie-Urteil

XML Signature 1.1 und XML Encryption 1.1 zeigen, warum interoperable Identifikatoren für XML-Strukturen nötig sind. Sie billigen nicht automatisch jeden künftig benannten Algorithmus.

RFC 8126 beschreibt Specification Required als öffentlich und dauerhaft verfügbare Spezifikation plus Expertenprüfung. Das ist eine Zulassungsregel für Registereinträge, keine allgemeine Sicherheitszertifizierung und kein Einsatzbefehl.

Dieser Artikel bewertet keinen Algorithmus und behauptet weder Sicherheit noch Unsicherheit, Reife, Implementierung oder Verbreitung. Das Governance-Problem bestünde bei jedem dauerhaften Vokabular, dessen definierendes Dokument noch wandert.

Eine kurze Namensraum-Verfassung

Sie beginnt mit URI, Datumsklasse, Zuteilungsentscheidung, Akteur, Datum und öffentlichem Pull Request oder Übergangsnachweis. Die bei Zuteilung betrachtete Version samt Hash steht getrennt von der heute verlinkten Version.

Danach folgen Änderungsarten: Hinzufügen, Korrigieren, Umbenennen, Entfernen, Veraltenlassen. Für jede Art werden Vorschlag, Entscheidung und Behandlung bestehender Referenzen festgelegt.

Der Gefrierpunkt braucht Ereignis, Entscheider und Zeitpunkt. Die Regel danach erklärt, ob Erweiterungen denselben Präfix, IANA-Expert Review, Errata, einen Nachfolge-RFC oder eine neue datierte Generation nutzen.

Getrennte Felder zeigen W3C-Verwahrung, IETF-Dokumentklasse, Gruppe, Stream, Adoption und Area Director, sofern vorhanden, sowie IANA-Status, Regel und Expertenumfang. Quellen für Identifikatorsyntax und Algorithmussemantik bleiben getrennt. Korrektur, Ablösung, Ablauf und nächste Prüfung schließen die Kette.

Namensraumzuteilung, Entwurfsveröffentlichung, IETF-Adoption oder Stream-Zuordnung, RFC-Genehmigung, IANA-Aktualisierung und betriebliche Einführung sind sechs verschiedene Handlungen.

Private Beratungen oder sensible Implementierungsberichte müssen nicht offengelegt werden. Version, Zuständigkeit, Änderungsart und Übergang genügen.

Lesbarkeit statt Fehlverhalten

Die Akte enthält offene Diskussion, archivierte Fassungen, einen dauerhaften W3C-URI, ein korrektes IANA-Register und ausdrückliche Grenzen gegen implizite Billigung. Nichts belegt böse Absicht, Capture, unbefugte Registrierung oder misslungene Zusammenarbeit.

Deshalb ist die Reparatur klein: Der dynamische Link bleibt für den aktuellen Text. Ein versionierter Nachweis erklärt daneben die frühere Erlaubnis und die nächste zulässige Änderung.