OK, now for something controversial (well, maybe it isn't). Object
identifiers.
There is currently a field in the SignerInfo structure called
signatureAlgorithm which is of type SignatureAlgorithmIdentifier. This
was called digestEncryptionAlgorithm and was of type
DigestEncryptionAlgorithmIdentifier in PKCS #7 v1.5 (RFC 2315). It was
renamed because DSA is not technically an encryption of a digest which
was implied by the old name. In any case, in S/MIME v2 which used PKCS
#7 v1.5, this field always contained the OID "rsaEncryption" defined
under PKCS #1.
It has been suggested through various non-list channels that the
semantics of this field be changed to be the complete signature
algorithm. That is, the OID that combines the digest algorithm with the
method by which the digest is protected. For instance,
md2WithRSAEncryption, md5WithRSAEncryption, sha-1WithRSAEncryption, and
id-dsa-with-sha1 instead of the currently specified values of
rsaEncryption and id-dsa.
I have one concern about this -- backwards compatibility. I'm a baby
about this, and I know for a fact that some S/MIME v2 agents will freak
out if they spot md5WithRSAEncryption or sha-1WithRSAEncryption in the
digestEncryptionAlgorithm field of the SignerInfo.
If people think that this change is a good idea, then how should we word
it?
First cut:
Sending agents SHOULD use md2WithRSAEncryption, md5WithRSAEncryption,
sha-1WithRSAEncryption when signing with any of those algorithm
combinations. Sending agents SHOULD not use rsaEncryption except when
compatibility with v2 is required. Sending agents MUST use
id-dsa-with-sha1 since there are no backwards compatibility issues.
Receiving agents MUST accept these as well as the (deprecated)
rsaEncryption.
I think it gets a bit messy, and any suggestions are welcome.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060