Subject: WG LAST CALL: draft-ietf-smime-pss-02.txt

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 3 Dec 2003 14:54:03 -0800

This message initiates an SMIME Working Group Last Call on the document:

	Title		: Use of the PSS Signature Algorithm in CMS
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-pss-02.txt
	Pages		: 5
	Date		: 2003-12-2

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

The purpose of this WG Last Call is to ensure that the Working Group has
achieved consensus that the document is suitable for publication as a
Proposed Standard.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list.  Editorial issues may
be sent to the document editor.

The Last Call period will end on Wednesday, December 10, 2003.

Upon completion of the last call, the WG chairs will take action based
upon the consensus of the WG. Possible actions include:

   1) recommending to the IETF Security Area Directors
      that the document, after possible editorial or
      other minor changes, be considered by the IESG
      for publication as a Standard Track RFC
      (which generally involves an IETF-wide Last Call); or

   2) requiring that outstanding issues be adequately
      addressed prior to further action (including,
      possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process.  So, please read and comment!

Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com

---

From: Russ Housley <[email-masked]>
Date: Sun, 07 Dec 2003 12:32:42 -0500

An informative note would be helpful.  I think the reader would like to 
know that [RSA-ALGS] includes an ASN.1 module that includes all of the OIDs 
and structures discussed in this document.

Russ

---

From: "Alberti Antoine" <[email-masked]>
Date: Wed, 10 Dec 2003 16:50:17 +0100

I totally agree with Burt's proposition. It tends to mix up a little bit more the concepts of signature and digest (I consider the second one as part of the first one). It also tends to specify, by constraining, more, which is the goal of a specification, from my point of view. Anyway I'd like to make a few comments on this message that are of a very secondary importance. I'm sure some of them will lead to discussions I'd like to see. Moreover, they may point out some of my misunderstandings of the RFCs, in which case it would certainly be of interest for me that somebody explains these to me.

> 
> The draft looks good except for one paragraph:
> 
>    The same one-way hash function SHOULD be used for computing the 
>    message digest on the signedAttributes and as the hashAlgorithm in 
>    the RSA-PSS-params structure. 
> 
> I think the paragraph should say "MUST".

One have to be aware of the fact that SMIME's RFC does not say MUST.

> 
> The id-RSASSA-PSS OID is for the full process of signing a message,
> including hashing, padding, and the RSA primitive.
> 
> The RSASSA-PSS-params structure specifies the hash function 
> that is employed
> during hashing and padding. The same hash function is employed in both
> steps. So, the hash function in the RSASSA-PSS-params 
> structure MUST be the
> same as the message digest algorithm applied to the 
> signedAttributes values.

This MUST is not a logical consequence of the previous sentences: the 2 digests (the one of the signedAttribute and the one of the signature) are not the same at all. Two distinct digest contexts have to be maintained anyway.

> 
> (If the signedAttributes are omitted, and the eContent value is signed
> directly, then the message digest algorithm that is applied 
> to the eContent
> value likewise MUST be the same as the hash function in the
> RSASSA-PSS-params structure. I'm not sure if the 
> eContent-only mode is still
> supported in CMS, though.)

In this case, it is true that the digest algorithms MUST be the same, as the digests ARE the same one. Furthermore, even if CMS still allows eContent-only signedDatas, SMIME requires the presence of some signedAttributes (contentType, messageDigest, ...)

> 
> id-RSASSA-PSS-params is similar to id-dsa-with-sha1 in that 
> it specifies the
> full process of signing a message. It is different than 
> rsaEncryption, whcih
> only includes padding and the RSA primitive, not hashing. 
> This is why it
> constrains the message digest algorithm, while rsaEncryption doesn't.

I still believe that rsaEncryption is an encryption OID, not a signature one. This should logically not (MUST NOT?) be stated as a signature descriptor. Signature OIDs should be sha1WithRSAEncryption, or md5WithRSAEncryption, in this case.

Best regards.

Antoine Alberti.

---

From: "Kaliski, Burt" <[email-masked]>
Date: Thu, 11 Dec 2003 09:33:25 -0500

Hi Jim,

I understand the motivation, but the RSASSA-PSS-params specify the full
signature process, including the hash.

When using RSASSA-PSS in CMS, there are potentially three hashes (not
including the one on the mask generation function):

1. hash of eContent
2. hash of signedAttributes
3. hash within PSS padding

Hashes 2. and 3. are both part of the RSASSA-PSS signature process. In
RSASSA-PSS, hashes 2. and 3. MUST be the same. (This is part of the
definition of RSASSA-PSS, not a security requirement per se.)

This requirement does not present a problem for a timestamp authority. If
the timestamp authority is given only the hash of signedAttributes and the
hash algorithm (hash 2.), then the timestamp authority can just select the
same hash algorithm within the PSS padding (hash 3.).

-- Burt

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, December 11, 2003 3:55 AM
To: Kaliski, Burt; 'Blake Ramsdell'
Cc: [email-masked]
Subject: RE: WG LAST CALL: draft-ietf-smime-pss-02.txt

Bert,

I wrote this as should since I do not want to rule out the ability for a
time stamp authority to be able to sign a message when just the hash and
hash algorithm are provided.

The two hash functions are in many ways independent, the hash and hash
algorithm are really part of the data that is then hashed as part of the
signature process.  This should refers to the body of the message,
producing a hash value that is part of the actual signature processing.

jim