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

From: "Kaliski, Burt" <[email-masked]>
Date: Wed, 10 Dec 2003 09:58:25 -0500

Dear Blake,

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".

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.

(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.)

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.

(Note that the padding step also involves a mask generation function, which
may be based on a hash function. The above discussion doesn't apply to that
hash function; it may or may not be the same as the hash function applied to
the message.)

-- Burt

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]]
Sent: Wednesday, December 03, 2003 5:54 PM
To: [email-masked]
Subject: WG LAST CALL: draft-ietf-smime-pss-02.txt

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: "Jim Schaad" <[email-masked]>
Date: Thu, 11 Dec 2003 00:54:53 -0800

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kaliski, Burt
> Sent: Wednesday, December 10, 2003 6:58 AM
> To: 'Blake Ramsdell'
> Cc: [email-masked]
> Subject: RE: WG LAST CALL: draft-ietf-smime-pss-02.txt
> 
> 
> 
> Dear Blake,
> 
> 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.
> 
> (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.)
> 
> 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.
> 
> (Note that the padding step also involves a mask generation 
> function, which may be based on a hash function. The above 
> discussion doesn't apply to that hash function; it may or may 
> not be the same as the hash function applied to the message.)
> 
> -- Burt
>     
> 

Blake