The IESG has approved the following document: - 'ESS Update: Adding CertID Algorithm Agility ' <draft-ietf-smime-escertid-06.txt> as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-06.txt 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. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
