Subject: PSS Document Question

From: "Jim Schaad" <[email-masked]>
Date: Thu, 1 May 2003 13:55:36 -0700

I have had a private mail that requested the following:

> In section 3, you say:
>
>     digestAlgorithms SHOULD contain the one-way hash function used to
>     compute the message digest on the eContent value.
>
> I would rather this be a MUST!

My reply was that this would impose a new behavior on the CMS document
where this behavior is a SHOULD not a MUST.  The reply to this was to
ask me to take it to the list as a question of wheither the CMS document
is too lienant on this issue.

HERE IS MY TAKE!

1.  Presence of a digest algorithm is not techincally needed to
successfully validate a signature.  The one that is needed is in the
SignerInfo structure.

2.  My implementations of CMS WILL FAIL if the digest algorithm is not
present in this field.  I have a stream based implementation of
signature processing that requires the digest algorithm to be known
prior to starting to process the content.  (I have a fall back of adding
SHA-1 if the field is empty.)  This is permitted behavior under CMS.

3.  I do not know of anybody who delibrately omits putting this into the
message.

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.

Jim

---

From: "Blake Ramsdell" <[email-masked]>
Date: Mon, 5 May 2003 23:02:57 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Thursday, May 01, 2003 1:56 PM
> To: Ietf-Smime
> Subject: PSS Document Question
> 

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