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
At 01:07 AM 6/12/2009, Jim Schaad wrote:
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.