Summary

  • RFC 9688 deliberately gives different SHA3-related CMS roles different parameter rules: absent for digest, ECDSA, HMAC and HKDF identifiers; required ASN.1 NULL for RSA PKCS#1 v1.5-with-SHA3; conditional customization octets for KMAC-based KDFs.
  • A parser saying “supported,” an interface showing the correct OID or a verifier returning success does not prove that the received bytes were conforming, preserved, executed under the intended key and policy, or accepted by the application.

Imagine an archival gateway that ingests a signed CMS object, decodes it, shows id-rsassa-pkcs1-v1-5-with-sha3-256, and stores a normalized copy. The signature verifies before normalization. Months later, another verifier rejects the stored object because the gateway removed the NULL parameters from the RSA signature identifier. Nothing visible in the algorithm name changed. The hash family did not change. The key did not change. Yet the object did, because RFC 9688 says that this RSA identifier's parameters must contain NULL.

That scenario is analysis, not a claim about a named product. Its value is that it reveals a boundary that inventory screens routinely hide. An object identifier coordinates the name of an algorithm. It does not alone preserve the complete AlgorithmIdentifier, the surrounding CMS field, nested parameters, input bytes, key selection, executed code path or policy decision.

One family, several wire obligations

RFC 9688 specifies SHA3-224, SHA3-256, SHA3-384 and SHA3-512 in several CMS roles. The digest OIDs can appear in SignedData.digestAlgorithms, SignerInfo.digestAlgorithm, DigestedData.digestAlgorithm and AuthenticatedData.digestAlgorithm. In those uses, parameters must be absent—not encoded as ASN.1 NULL, but absent.

ECDSA-with-SHA3 follows the same absence rule for its signature algorithm parameters. HMAC-with-SHA3 also requires absence. The four HKDF-with-SHA3 identifiers likewise require absence. A generic encoder that learned an old habit—“algorithm identifiers should include NULL”—would therefore manufacture a prohibited representation while retaining a correct-looking OID.

RSA PKCS#1 v1.5-with-SHA3 goes the other way. For rsaEncryption and the four RSA-with-SHA3 signature OIDs, RFC 9688 requires the parameters field to contain NULL. A generic cleanup pass that treats NULL as meaningless decoration can break this branch while apparently making the object tidier.

KMAC refuses both family-wide shortcuts. For KMAC128-KDF or KMAC256-KDF, parameters must be absent when there is no customization label S. If the originator supplies S, parameters must be present and contain that exact value as an OCTET STRING. “Absent” and “present with a zero-length string” are not automatically interchangeable descriptions. They are different encoded states and can express different input construction.

The operational lesson is not that ASN.1 is fussy. It is that the protocol assigns meaning at a smaller surface than many dashboards preserve. The correct common layer is the exact field-specific rule. Local policy may decide which algorithms to permit, but it cannot rewrite the shared syntax and still claim to have observed the same object.

The KDF name does not reconstruct the KDF

The KMAC branch makes the evidence gap wider. RFC 9688 writes KMAC as KMAC128(K, X, L, S) or KMAC256(K, X, L, S). K is the key-derivation key, often the output of a KEM decapsulation. X is context; with RFC 9629 it contains the DER encoding of CMSORIforKEMOtherInfo. L is the output length in bits. S is the optional customization label.

A log line that records only id-kmac128 therefore omits three non-key inputs that determine the result. Even if the OID and parameter bytes are retained, the operator still needs evidence of the exact context bytes and output length. If a KEM operation succeeded but the originator and recipient constructed X differently, the same OID cannot reconcile the derived keys.

KDF2 and KDF3 add a nested obligation. Their parameters carry another message-digest AlgorithmIdentifier. If that nested identifier selects SHA3, its own parameters must follow the Section 2 absence rule. A validator that checks only the outer KDF OID can report an incomplete kind of conformance.

This is why “supports SHA3” is too coarse for an asset inventory. A useful capability claim names the CMS role, the algorithm OID, the parameter form, the nested identifier rules, accepted BER/DER forms, key interface and tested output. Without that tuple, two green checks may describe different programs.

Preserve the received bytes before making them legible

Decoders are designed to turn encoded objects into usable structures. That is necessary, but it can destroy evidence if the decoded structure is re-serialized as a canonical-looking substitute and the original bytes are discarded. A parser may accept both absent and NULL, map both to one internal empty value and later emit whichever convention its library prefers. The application sees one state; the wire carried two.

For incident response and migration, retain at least four receipts: the hash of the received CMS bytes; the parsed field path and exact OID; the parameter state and parameter-octet hash; and the cryptographic operation result produced from a named implementation and policy version. If the object is transformed, record the transformed-byte hash separately. Never let a normalized copy impersonate the received artifact.

Cryptographic success is also bounded. A valid RSA or ECDSA signature proves a relationship among selected bytes, a signature and a public key under an algorithm. It does not by itself prove that a certificate path was valid at the relevant time, that the signer was authorized for the content, that signed attributes expressed the intended content type, that the object was fresh, or that the application committed the requested action.

The receipt chain should therefore remain explicit:

  1. record the selected content and CMS content type;
  2. record the CMS field role;
  3. record the exact OID;
  4. record whether parameters were absent, NULL or a particular customization value;
  5. record any nested algorithm identifier;
  6. hash the exact received encoding;
  7. identify parser version and whether it preserved or normalized bytes;
  8. identify the cryptographic implementation, key reference and operation;
  9. record verification, MAC or KDF outcome;
  10. separately record certificate, key-purpose and local-policy decisions;
  11. separately record the application's outcome.

No single green light should be promoted across those steps.

Registry assignment is a coordinate, not a deployment report

RFC 9688 caused IANA assignments for four HKDF-with-SHA3 identifiers and an ASN.1 module. Those assignments are valuable because independent implementers can name the same thing. They are not an installed-base census. They do not show that a library accepts the identifier, encodes its parameters correctly, reaches the intended provider, protects the right key or interoperates with another stack.

That distinction follows a broader discipline. A registry is strongest when it coordinates uniqueness and weakest when its symbolic entry is treated as authority over operational truth. Running code supplies different evidence: captured bytes, reproducible vectors, differential parser results and application receipts. Neither layer should impersonate the other.

Sources