[Top] [All Lists]

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

2003-12-10 08:50:27

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.