Technical Summary
This document updates RFC 2634, which defines the SigningCertificate
attribute among many other things. The SigningCertificate attribute
makes use of ESSCertID, a structure for cryptographically binding the
signer's certificate. The ESSCertID structure was hardwired to use
the SHA-1 one-way hash function. This document specifies a
replacement algorithm agile structure, and it defines a new attribute
that uses it.
Working Group Summary
This document has been reviewed by the S/MIME Working Group, and there
is solid support for the document. Many enterprises are looking to
ensure S/MIME is not tied to SHA-1.
Protocol Quality
This document updates RFC 2634. Clear guidance is given as to what
sections are replaced, while the remaining text is unaltered. Version
numbers are used to allow for easier implementation.
This document was reviewed by Tim Polk for the IESG.
Note to RFC Editor
In section 6., please make the following change:
OLD:
certHash is computed over the entire DER encoded certificate
(including the signature).
NEW:
certHash is computed over the entire DER encoded certificate
(including the signature) using the SHA-1 algorithm.
In section 7., please append the following text as new closing
paragraphs:
The attributes defined in this document permit a signer to select a
hash algorithm to identify a certificate. A poorly selected hash
algorithm may provide inadequate protection against certificate
substitution or result in denial of service for this protection. By
employing the attributes defined in this specification with the same
hash algorithm used for message signing, the sender can ensure that
these attributes provide commensurate security.
Since recipients must support the hash algorithm to verify the
signature, selecting the same hash algorithm also increases the
likelihood that the hash algorithm is supported in the context of
certificate identification. Note that an unsupported hash algorithm
for certificate identification does not preclude validating the message
but does deny the message recipient protection against certificate
substitution.
To ensure that legacy implementations are provided protection against
certificate substitution, clients are permitted to include both
ESScertID and ESScertIDv2 in the same message. Since these attributes are
generated and evaluated independently, the contents could conceivably
be in conflict. Specifically, where a signer has multiple certificates
containing the same public key, the two attributes could specify
different signing certificates. The result of signature processing may
vary depending on which certificate is used to validate the signature.
Recipients that attempt to evaluate both attributes may choose to
reject such a message.