ietf-smime
[Top] [All Lists]

Re: SignatureAlgorithmIdentifiers

1998-07-10 06:53:35
Eric & Blake:

I prefer the single OID approach; however, I do understand the backward
compatibility concern.  Certificates use a single OID to specify the hash
(a.k.a. digest) and signature algorithm.  I would prefer a solution that
was parallel.  This admits the possibility of a common routine for all
signature verification.

I think that we all agree that id-dsa-with-sha-1 should be used for DSA and
SHA-1.  So, lets put that ncontrovercial one aside.

I propose that sha-1WithRSAEncryption be used with RSA and SHA-1.  This
combination is not deployed in any product that I am aware of, so there is
not an issue with backward compatability.  PKIX Part 1 uses
sha-1WithRSAEncryption for certificate signatures with RSA and SHA-1. 

For the reasons already stated, I would like to see implementations support
md2WithRSAEncryption and md5WithRSAEncryption.  However, rsaEncryption is
already used in many implementations.  So, for RSA with MD2 and MD5 mandate
(a MUST) the processing of rsaEncryption and allow (a SHOULD) the
processing of md2WithRSAEncryption and md5WithRSAEncryption.

Russ

Blake said:
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.

Then, Eric said:
I agree that dsa should be id-dsa-with-sha-1 for security reasons.

I do not, however, agree that we should use fooWithRSAEncryption.
It doesn't provide any obvious benefit that I can see, and
(as noted) has negative backwards compatibility consequences.
Moroever, it leaves open the question of what to do if the
OID in the SignatureAlgorithm doesn't match the OID in the
digestAlgorithm field.