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
-----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 Kaliski,
Burt
Sent: Wednesday, December 10, 2003 6:58 AM
To: 'Blake Ramsdell'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: WG LAST CALL: draft-ietf-smime-pss-02.txt
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:blake(_at_)brutesquadlabs(_dot_)com]
Sent: Wednesday, December 03, 2003 5:54 PM
To: ietf-smime(_at_)imc(_dot_)org
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.tx
t
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