RFC 2634, "Enhanced Security Services for S/MIME", June 1999

Note: This RFC has been updated by RFC 5035

Errata ID: 6562
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David von Oheimb
Date Reported: 2021-04-28

Section 5.4 says:

   The first certificate identified in the sequence of certificate
   identifiers MUST be the certificate used to verify the signature. The
   encoding of the ESSCertID for this certificate SHOULD include the
   issuerSerial field. If other constraints ensure that
   issuerAndSerialNumber will be present in the SignerInfo, the
   issuerSerial field MAY be omitted. The certificate identified is used
   during the signature verification process. If the hash of the
   certificate does not match the certificate used to verify the
   signature, the signature MUST be considered invalid.

   If more than one certificate is present in the sequence of
   ESSCertIDs, the certificates after the first one limit the set of
   authorization certificates that are used during signature validation.

It should say:

   The sequence of certificate identifiers MUST contain at least one element.
   The first certificate identified MUST be the certificate used to verify the signature.
   The encoding of the ESSCertID for this certificate SHOULD include the
   issuerSerial field. If other constraints ensure that
   issuerAndSerialNumber will be present in the SignerInfo, the
   issuerSerial field MAY be omitted. The certificate identified is used
   during the signature verification process. If the hash of the
   certificate does not match the certificate used to verify the
   signature, the signature MUST be considered invalid.

   If more than one certificate identifier is present in the sequence of ESSCertIDs,
   all certificates referenced there MUST be part of the signature validation chain.

Notes:

Some aspects of the 'certs' field of a SigningCertificate attribute:

SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}

described in the sentences quoted above are very vague.
This lead to major confusion and wrong implementations.
As meanwhile has been clarified, they should be re-phrased;
see suggested new version above.

(One may further mandate/clarify that the certificate identifiers must be given in the same order
as they are expected in the validation chain, but I think this is not important because
the order should not play a critical role and will be determined by the validation chain anyway.)

Report New Errata