Subject: I-D ACTION:draft-ietf-smime-rfc3852bis-00.txt

From: [email-masked]
Date: Tue, 9 Jun 2009 12:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Cryptographic Message Syntax (CMS)
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc3852bis-00.txt
	Pages		: 57
	Date		: 2009-6-9
	
   This document describes the Cryptographic Message Syntax (CMS).  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary message content.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3852bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 11 Jun 2009 22:07:25 -0700

Russ,

I would like to modify two sections in order to add some clarification text.

In section 5.3
OLD
     digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer.  The message digest is
      computed on either the content being signed or the content
      together with the signed attributes using the process described in
      section 5.4.  The message digest algorithm SHOULD be among those
      listed in the digestAlgorithms field of the associated SignerData.
      Implementations MAY fail to validate signatures that use a digest
      algorithm that is not included in the SignedData digestAlgorithms
      set.

NEW
     digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer to compute the hash on the
      content being signed.  The message digest algorithm SHOULD be among
those
      listed in the digestAlgorithms field of the associated SignerData.
      Implementations MAY fail to validate signatures that use a digest
      algorithm that is not included in the SignedData digestAlgorithms
      set.  When signedAttributes are absent, this value should match the
      digest portion of the signature algorithm in the signatureAlgorithm
field.
      When validating and not signedAttributes are present, this value may
be ignored.

I debated if a security consideration needs to be added as well.  It would
appear that, due to structuring, a weaker hash algorithm would probably be
more acceptable for the signatureAlgorithm than the digestAlgorithm. After
deliberation I think that this probably does not need to be included, but it
is an issue you might wish to think about.

Rational for the change:

1.  We get somewhat routine questions about what should go into this field,
and I think this text is more explicit.
2.  There are situations, such as timestamp providers, where the selection
of the digest algorithm is not under their control so the situation of a
difference between the digest algorithm used for the content and that used
for the signature is very possible.
3.  If we get a parameterized hash function in the future, there is exists a
high degree of probability that the content and signature digest algorithms
will either be different algorithms, or have different parameters.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, June 09, 2009 12:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-smime-rfc3852bis-00.txt
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jun 2009 16:19:01 -0400

The only changes that this document includes are based on errata and 
updated references.  I'm reluctant to open this up for 
improvements.  That said, these changes are fairly minor.  Do these 
changes address something where we have evidence of problems?

Russ