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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Internet-Drafts(_at_)ietf(_dot_)org
Sent: Tuesday, June 09, 2009 12:15 PM
To: i-d-announce(_at_)ietf(_dot_)org
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: I-D ACTION:draft-ietf-smime-rfc3852bis-00.txt
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.