Protocol Action: 'ESS Update: Adding CertID Algorithm Agility' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce