Die Verbundsignatur war gültig. Der Umschlag nannte einen anderen Algorithmus.

Zusammenfassung

• Composite ML-DSA verlangt, dass beide Signaturkomponenten bestehen. CMS führt daneben eigene Angaben zu Digest, Signaturalgorithmus und signierten Attributen. Ein grünes Kryptografie-Ergebnis ist deshalb nur belastbar, wenn diese Angaben mit dem gewählten Verbundalgorithmus übereinstimmen.
• Prüfer müssen die exakten signierten Bytes rekonstruieren, den Inhaltsdigest neu berechnen und die Algorithmuskennungen vergleichen. Zertifikatspfad, Berechtigung und die spätere Anwendungshandlung bleiben eigenständige Entscheidungen.

Zwei Prüfanzeigen leuchten grün: ML-DSA gültig, klassische Signatur gültig. Die Anwendung meldet dennoch einen Fehler. Im SignerInfo steht ein Digest, den der ausgewählte Composite-Algorithmus nicht vorsieht.

Das ist kein kosmetischer Widerspruch. Die Mathematik kann auf genau den gelieferten Eingaben stimmen, während der CMS-Umschlag unterschiedliche Aussagen darüber macht, welche Eingaben autoritativ sind. Wer in diesem Moment nur „Composite-Signatur gültig“ protokolliert, vernichtet die Information, die den Fehler erklären könnte.

Revision 05 des LAMPS-Entwurfs Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in Cryptographic Message Syntax (CMS) beschreibt diese Bindung. Der Text trägt das Datum 22. Mai 2026, läuft am 23. November 2026 ab und ist als Proposed Standard vorgesehen. Der Datatracker verzeichnet seit dem 1. Oktober die RFC-Editor-Warteschlange und wartet auf einen zweiten Editor. Das ist ein Verfahrensstand, keine RFC-Veröffentlichung und erst recht kein Nachweis für Bibliotheksunterstützung, Zertifikatsausgabe oder produktive Interoperabilität.

Eine Schnittstelle, mehrere Behauptungen

Die begleitende Composite-ML-DSA-Spezifikation kombiniert ML-DSA mit RSA, ECDSA, Ed25519 oder Ed448. Nach außen erscheinen öffentlicher Schlüssel und Signatur als ein Algorithmus. Die Verifikation ist nur erfolgreich, wenn jede Komponente besteht. Für Migrationen ist das attraktiv: Ein Protokoll muss nicht zwei unabhängige Signaturcontainer samt eigener Kombinationsregel erfinden.

CMS besitzt aber bereits eine reichhaltige Hülle. SignedData.digestAlgorithms nennt die in einer Sammlung vorkommenden Digests. Jeder SignerInfo trägt einen digestAlgorithm und einen signatureAlgorithm. Signierte Attribute können CMSAlgorithmProtection enthalten. Das Zertifikat benennt wiederum den Schlüsselalgorithmus. Diese Felder sind keine austauschbaren Schreibweisen für dasselbe Etikett.

Deshalb braucht der Betrieb einen Übereinstimmungsbeleg. Er sollte den Composite-OID, den Schlüsselalgorithmus des Zertifikats, beide AlgorithmIdentifier aus SignerInfo, die An- oder Abwesenheit ihrer Parameter, die Werte aus CMSAlgorithmProtection und die Einzelresultate beider Komponenten getrennt festhalten. Erst aus dieser Koordinatenmenge lässt sich schließen, ob die Hülle und die primitive Prüfung dasselbe Verfahren meinten.

Der Entwurf führt 18 OIDs für Kombinationen unterschiedlicher ML-DSA-Parametersätze mit klassischen Verfahren auf. Beim signatureAlgorithm muss das Parameterfeld fehlen. Ein explizites NULL ist nicht bloß eine zweite harmlose Kodierung, wenn das Profil Abwesenheit verlangt.

Der Name legt den äußeren Digest fest

In diesem CMS-Profil wird Composite ML-DSA ausschließlich im Pre-Hash-Modus verwendet. Jeder Algorithmusname legt den CMS-seitigen Digest fest: je nach Kombination SHA-256, SHA-512 oder SHAKE256. SignerInfo.digestAlgorithm muss genau dazu passen.

Auch die Parameterregeln sind Teil der Übereinkunft. Bei SHA-256 und SHA-512 müssen die Parameter fehlen. Gleiches gilt für SHAKE256; hier beträgt die Ausgabe 64 Byte. Ein Prüfer, der nur den OID betrachtet und unerwartete Parameter verwirft, repariert die Nachricht stillschweigend, statt sie gegen das Profil zu prüfen.

Innerhalb der klassischen Komponente kann dennoch ein anderer Digest vorkommen. ECDSA mit P-384 kann intern SHA-384 verwenden, obwohl der CMS-Pre-Hash der Composite-Kombination SHA-512 ist. Das ist kein Widerspruch. Es sind verschiedene Schichten. Telemetrie muss deshalb notieren, ob sie den äußeren CMS-Digest oder einen internen Komponentenparameter beschreibt.

Die Digest-Menge in SignedData soll den passenden Algorithmus enthalten, damit ein Ein-Pass-Prüfer die richtige Berechnung vorbereiten kann. Fehlt er, kann ein solcher Prüfer scheitern. Diese Sammlung ersetzt jedoch nicht die zwingende Gleichheit zwischen SignerInfo.digestAlgorithm und dem vom Composite-OID festgelegten Pre-Hash. Ein Sammlungshinweis und eine Aussage des einzelnen Signierers sind zwei verschiedene Belege.

Der signierte Bytebereich wechselt mit den Attributen

Ohne signierte Attribute umfasst die Signatur den Wert des gekapselten eContent-OCTET-STRING. Tag- und Längenbytes gehören nicht dazu. Mit signierten Attributen ändert sich der signierte Gegenstand: Geprüft wird die vollständige DER-Kodierung von SignedAttrs, einschließlich Tag und Länge.

Dabei gibt es eine leicht zu übersehende Kodierungsgrenze. Im fertigen SignerInfo erscheinen die Attribute unter einem IMPLICIT-Tag [0]. Für die Signaturberechnung wird dagegen der EXPLICIT-Tag für SET OF verwendet. Wer lediglich die im Umschlag sichtbaren Bytes ausschneidet oder eine ASN.1-Darstellung neu serialisiert, kann einen anderen Bytebereich prüfen als der Signierer.

Zu den Pflichtattributen gehören mindestens content-type und message-digest. Der Empfänger muss den Digest des gekapselten Inhalts selbst berechnen und mit dem signierten Wert vergleichen. Eine korrekte Verbundsignatur über Attribute, deren Inhaltsdigest nie abgeglichen wurde, beweist nur, dass genau diese Attribute signiert waren. Sie beweist nicht, dass der ausgelieferte Inhalt dazugehört.

Ein brauchbarer Prüfbeleg beginnt daher mit dem Hash des unveränderten CMS-Objekts. Danach folgen der Hash des extrahierten Inhalts, der Hash der exakt signierten DER-Attribute, der empfangene und der neu berechnete message-digest sowie der Bytebereich, der tatsächlich an Composite ML-DSA übergeben wurde. Eine normalisierte JSON-Ausgabe oder ein hübscher ASN.1-Baum darf das Original nicht ersetzen.

Die zugrunde liegende Primitive kennt zudem einen Kontextstring. Dieses CMS-Profil setzt ihn fest auf die leere Zeichenfolge. Eine Anwendung kann also nicht behaupten, eine nichtleere primitive Kontextkennung trenne etwa Zahlungsfreigaben von Softwarefreigaben. Die fachliche Trennung muss aus geprüftem Inhaltstyp, signierten Attributen, Zertifikatspolitik oder einer anderen ausdrücklich verifizierten Regel kommen.

Algorithmusschutz gehört in den geschützten Bereich

RFC 6211 definiert CMSAlgorithmProtection. Das Attribut nimmt den Digest-Algorithmus und entweder den Signatur- oder MAC-Algorithmus in die signierten Attribute auf. Revision 05 empfiehlt seine Verwendung gegen Algorithmussubstitution. RFC 8933 verschärft zusätzlich die Konsistenzregeln für CMS-Digests.

Der operative Wert liegt in der Position des Attributs. Ein ausschließlich äußeres Feld kann verändert werden, ohne den signierten Bytebereich zu verändern. Stehen Digest und Signaturkennung auch im geschützten Attribut, kann der Empfänger sie mit den äußeren SignerInfo-Feldern und dem Composite-OID vergleichen.

Das Attribut ist trotzdem kein Freibrief. Der Prüfer muss Syntax, zulässige Häufigkeit, Algorithmuswerte, Parameterregeln und Kompatibilität mit dem Zertifikat kontrollieren. Da der Entwurf ein SHOULD und kein bedingungsloses MUST verwendet, kann Abwesenheit in einer lokalen Politik zulässig sein. Sie darf aber nicht unsichtbar in einem allgemeinen Erfolgsstatus verschwinden.

Eine gute Entscheidung beantwortet einzeln: Waren signierte Attribute vorhanden? War CMSAlgorithmProtection vorhanden und tatsächlich mit signiert? Stimmte sein Digest mit SignerInfo.digestAlgorithm überein? Stimmte seine Signaturkennung mit dem Composite-OID überein? Fehlten verbotene Parameter? Passte der Zertifikatsschlüssel? Waren beide Komponenten gültig? Entsprach der neu berechnete Inhaltsdigest dem signierten Wert?

Register, Warteschlange und Einsatz sind getrennte Zustände

Der Entwurf beantragt eine SMI-Sicherheitsnummer für sein ASN.1-Modul. In der eingefrorenen Revision 05 steht dafür noch ein Platzhalter. Das öffentlich abrufbare IANA-SMI-Register vom 2. Oktober führt bereits den Dezimalwert 88 für id-mod-composite-mldsa-cms-2026 mit Verweis auf den Entwurf.

Beides kann gleichzeitig wahr sein. Das Register hat eine Nummer vergeben, die Textrevision enthält noch den Publikationsplatzhalter, und der Datatracker zeigt die RFC-Editor-Warteschlange. Keiner dieser Zustände allein bedeutet, dass bereits ein RFC existiert. Ebenso wenig beweisen sie, dass eine Bibliothek die OIDs akzeptiert, ein CA-Profil sie ausstellt oder ein Betreiber sie aktiviert hat.

Für den Modulwert ist das öffentliche Register zum Erfassungszeitpunkt der belastbare Beleg. Für den Standardstatus sind Datatracker und spätere RFC-Veröffentlichung andere Belege. Ein Dashboard, das all dies unter „postquantenfähig“ zusammenfasst, verwechselt Verwaltungsfortschritt mit funktionierender Vertrauenskette.

Gültige Kryptografie ist noch keine Berechtigung

Die Composite-Prüfung verlangt beide Komponenten. Außerdem dürfen die zugehörigen Komponentenschlüssel nicht in anderen Kontexten wiederverwendet werden. Diese Vorgabe schützt vor protokollübergreifender Exposition und gehört in Schlüsselgenerierung, Inventar und Lebenszyklusnachweise.

Trotzdem beantwortet „beide gültig“ nur einen Teil der Betriebsfrage. Der Zertifikatspfad kann scheitern, Statusdaten können veraltet sein, der Schlüssel kann für E-Mail-Schutz statt Codesignatur zugelassen sein, und der identifizierte Signierer kann für genau diese Handlung keine Befugnis besitzen. Ein gültig signierter Auftrag beweist auch nicht, dass die versprochene Außenwirkung eingetreten ist.

Die Belegkette bleibt deshalb geschichtet: Parser- und Kodierungsergebnis, Algorithmusübereinstimmung, Inhaltsdigest, beide Komponenten, Zertifikatspfad und Statusfrische, Schlüsselverwendung, Identität und Berechtigung, Anwendungsentscheidung, Auslieferung, dauerhafte Speicherung und externes Ergebnis.