-----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 Jim
Schaad
Sent: Thursday, May 01, 2003 1:56 PM
To: Ietf-Smime
Subject: PSS Document Question
I would be happy with changing this from a SHOULD to a MUST,
but if this
is done it needs to propigate all of the way back to CMS.
In the case of digestAlgorithms, the current language in CMS says that
there MAY be any number of elements in the collection, but does not make
any statement as far as MAY/MUST/SHOULD for whether or not these should
map to the algorithms used for the signers ("The collection is intended
to list the message digest algorithms employed by all of the signers, in
any order, to facilitate one-pass signature verification"). Therefore,
if you make it a MUST, I don't think you're overriding anything in CMS,
only clarifying something that is unspecified. Your MUST wouldn't
violate the "[t]here MAY be any number of elements in the collection,
including zero" which is the only thing in CMS I found that talks about
this.
Anecdotally, my current S/MIME implementation ignores digestAlgorithms,
since I'm using Java's security providers, and as far as I can tell
there isn't a way to present just the completed digest and public key to
the signature verification process -- you have to provide the *content*
and public key (which might have parameters scattered up and down the
cert chain, so you'd better make a cert chain while you're at it), and
Java does the digesting internally as part of the signature
verification. Sigh. So I ignore digestAlgorithms completely, since I
can't use them, and just tough it out and do two passes.
Personally, I consider "best current CMS practice" to be to always
digest with every algorithm you know about and might reasonably
encounter (so, digest with SHA-1, and if you're feeling saucy, digest
with MD5 also), and ignore digestAlgorithms completely. For that
matter, I feel this way about most informational fields that aren't tied
directly to algorithm use (such as the "smime-type" parameter for
S/MIME) -- ignore 'em and pretend like the guy that made 'em is probably
lying anyway. It's just one less AlgorithmIdentifier to parse the wrong
OID or parameters out of. So even if you made this a MUST, I'm not sure
anyone should care, since the digestAlgorithm wording is so soft that
the field does not have value.
Blake