Zusammenfassung

  • SHA3-Digest, ECDSA, HMAC und HKDF verlangen in RFC 9688 abwesende Parameter; RSA PKCS#1 v1.5 mit SHA3 verlangt NULL; KMAC verlangt je nach Customization Abwesenheit oder die exakten Oktette.
  • Parser-Erfolg, OID-Erkennung und gültige Signatur sind begrenzte Belege. Sie beweisen weder Byte-Treue noch den tatsächlich ausgeführten Pfad, Zertifikats- und Schlüsselpolitik, Autorisierung oder Anwendungsergebnis.

Der aufschlussreiche Fall entsteht beim Einlesen. Eine Bibliothek akzeptiert sowohl einen fehlenden Parameter als auch NULL und bildet beides auf denselben internen Leerwert ab. Später schreibt sie nur ihre bevorzugte Form. Das Dashboard bleibt grün. Die Information, was der Absender wirklich gesendet hat, ist verschwunden.

Dies ist kein behaupteter Vorfall eines benannten Produkts. Es ist eine Prüffrage: Welche Aussage kann ein System nach Normalisierung noch belegen? Der OID benennt den Algorithmus. Er bewahrt nicht automatisch CMS-Feld, Parameterform, innere Kennung, Eingabebytes, Schlüssel, Implementierung und lokale Entscheidung.

Eine absichtlich asymmetrische Matrix

Für SHA3-224, -256, -384 und -512 als Digest müssen Parameter fehlen. Das gilt in den Digest-Feldern von SignedData, SignerInfo, DigestedData und AuthenticatedData. Fehlend ist nicht dasselbe wie vorhandenes NULL.

ECDSA-with-SHA3, HMAC-with-SHA3 und HKDF-with-SHA3 verlangen ebenfalls Abwesenheit. Ein universeller Encoder, der jedem AlgorithmIdentifier ein NULL hinzufügt, verändert also eine normative Aussage.

RSA PKCS#1 v1.5-with-SHA3 kehrt die Regel um. Seine Kennungen müssen NULL enthalten. Ein Bereiniger, der Nullwerte überall entfernt, beschädigt diese Variante, obwohl der sichtbare Algorithmusname gleich bleibt.

KMAC128-KDF und KMAC256-KDF kennen einen dritten Zustand. Ohne Customization S fehlen die Parameter. Mit S müssen sie vorhanden sein und genau diesen Wert als OCTET STRING tragen. Abwesenheit und eine vorhandene leere Zeichenfolge sind keine beweislos zusammenlegbaren Defaults.

Die gemeinsame Spezifikation bleibt damit schmal: Feldrolle, OID und genaue Parameterregel. Lokale Politik darf Algorithmen zulassen oder ablehnen. Sie darf das empfangene Objekt nicht lautlos umschreiben.

KMAC benötigt mehr als einen Namen

KMAC arbeitet mit K, X, L und S. K kann aus KEM-Decapsulation stammen. X enthält im RFC-9629-Kontext das DER von CMSORIforKEMOtherInfo. L bestimmt die Ausgabelänge. S liefert optionale Domain Separation.

Ein Protokolleintrag id-kmac128 reicht nicht zur Reproduktion. Selbst OID und Parameter lassen Kontext und Länge offen. Zwei Implementierungen können denselben Namen unterstützen und verschiedene Schlüssel ableiten.

KDF2 und KDF3 tragen zusätzlich einen Digest-AlgorithmIdentifier in ihren Parametern. Wählt dieser SHA3, gilt auch innen die Abwesenheitsregel. Die Prüfung des äußeren OID ist kein Beleg für den inneren Vertrag.

Empfang, Interpretation und Ausführung getrennt quittieren

Für Diagnose und Migration braucht es mindestens den Hash der empfangenen CMS-Bytes, Feldpfad und OID, Parameterzustand und Parameterhash, innere Kennungen, Parser-Version und Normalisierung, Kryptoprovider und Schlüsselreferenz sowie Operationsausgang. Zertifikatspfad, Verwendungszweck, Autorisierung und Anwendungsergebnis folgen als eigene Belege.

Eine gültige Signatur bleibt wichtig. Sie beweist die kryptographische Beziehung zwischen ausgewählten Bytes, Signatur und öffentlichem Schlüssel. Sie beweist nicht allein die Befugnis des Unterzeichners, Frische, geschäftliche Bedeutung oder Ausführung einer Anweisung.

IANA weist zu; laufender Code führt aus

IANA-Kennungen schaffen gemeinsame Koordinaten. Sie sind weder Produktzertifikat noch Installationszählung. Konformität wird durch konkrete Bytes, Testvektoren, Differentialtests und reproduzierbare Ausgaben sichtbar.

Diese Trennung hält die Koordinationsfunktion dünn und die operative Behauptung ehrlich. Ein Symbol kann auf eine Definition verweisen. Es kann keinen Ausführungsbeleg ersetzen.

Quellen