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
From: Blake Ramsdell [mailto:blake(_at_)brutesquadlabs(_dot_)com]
Sent: Wednesday, December 03, 2003 5:54 PM
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:
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
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 Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com