RFC Errata
RFC 5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", June 2010
Note: This RFC has been updated by RFC 6960, RFC 9480
Source of RFC: pkix (sec)
Errata ID: 4145
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierce Leonberger
Date Reported: 2014-10-23
Section 14 says:
-- 3. A more complex version, but one that automatically ties -- together both the signature algorithm and the -- signature value for automatic decoding. -- SIGNED{ToBeSigned} ::= SEQUENCE { toBeSigned ToBeSigned, algorithmIdentifier SEQUENCE { algorithm SIGNATURE-ALGORITHM. &id({SignatureAlgorithms}), parameters SIGNATURE-ALGORITHM. &Params({SignatureAlgorithms} {@algorithmIdentifier.algorithm}) OPTIONAL }, signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value( {SignatureAlgorithms} {@algorithmIdentifier.algorithm})) }
It should say:
SIGNED{ToBeSigned} ::= SEQUENCE { toBeSigned ToBeSigned, algorithmIdentifier SEQUENCE { algorithm SIGNATURE-ALGORITHM. &id({SignatureAlgorithms}), parameters SIGNATURE-ALGORITHM. &Params({SignatureAlgorithms} {@algorithmIdentifier.algorithm}) OPTIONAL }, signature BIT STRING }
Notes:
I *believe* the 3rd option for SIGNED{} is invalid. The "signature" BIT STRING contains an OpenType which references an optional class field. It's possible to define objects with no type and OpenTypes must refer to a type. There's no mechanism to allow an OpenType to reference random bytes (not ASN.1 encoded).
I understand the intent is to allow for automatic decoding, but unless the "&Value" is required in SIGNATURE-ALGORITHM this will not work. Requiring it will not work because not all signature algorithms require the signature value to be encoded (e.g. RSA). The syntax would be valid is if "signature" was OPTIONAL (obviously not desirable).
So I propose we revert "signature" to "BIT STRING" without constraints.