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.