RFC Errata
Found 2 records.
Status: Verified (1)
RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007
Source of RFC: smime (sec)
Errata ID: 2364
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Tim Polk
Date Verified: 2010-07-29
Section 4 says:
On mid-page 6, Section 4 of RFC 5035 gives the following text as part of the new Section 5.4.1.1, Certificate Identification Version 2 : The fields of ESSCertIDv2 are defined as follows: hashAlgorithm contains the identifier of the algorithm used in computing certHash. certHash is computed over the entire DER-encoded certificate (including the | signature) using the SHA-1 algorithm. [...] The core reason for the new Cert ID version is algorithm agility. Therefore, specifying SHA-1 here does not make any sense (and it would turn the hashAlgorithm field useless) ! The 'certHash' field explanation should say: certHash is computed over the entire DER-encoded certificate (including the | signature) using the algorithm specified by hashAlgorithm. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It should say:
See above.
Notes:
See above.
Status: Reported (1)
RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007
Source of RFC: smime (sec)
Errata ID: 6566
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David von Oheimb
Date Reported: 2021-04-29
Section 3 says:
certs contains the list of certificates that are to be used in validating the message. The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertIDv2 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, subsequent certificates limit the set of certificates that are used during validation.
It should say:
certs contains the list of certificates that are to be used in validating the message. It MUST contain at least one element. The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertIDv2 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 ESSCertIDv2s, all certificates referenced there MUST be part of the signature validation chain.
Notes:
Some aspects of the 'certs' field of a SigningCertificateV2 attribute:
SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
described in the sentences quoted above are rather 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.)