ietf-smime
[Top] [All Lists]

RE: cmsalg-02 RSA OID Proposal

2001-09-05 12:44:36

Do previous message threads have any relevance here?

11/7/1997
DigestEncryptionAlgorithmIdentifiers for DSS / DSA (was RE:S/MIME V3 Msg
Spec Comments)

7/9/1998
SignatureAlgorithmIdentifiers

The bottom line seems to be that we picked an unfortunate name for the
signatureAlgorithm field.  The original name (digestEncryptionAlgorithm) was
bad for one reason (implies encryption), and the new one is bad for another
reason (implies both digesting and protection).  The use of id-dsa-with-sha1
seems to be the only culprit in my mind (should be id-dsa).  One way to look
at this is "what identifier from a certificate's SubjectPublicKeyInfo would
be required to verify this signature), which doesn't work right now with
DSA.

Blake

-----Original Message-----
From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com]
Sent: Saturday, September 01, 2001 9:03 AM
To: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: cmsalg-02 RSA OID Proposal



Peter:

RFC2630 CMS, section 12.2.2, specifies the use of the rsaEncryption
object
identifier (OID) in the signedData signerInfo signatureAlgorithm field
when
the RSA (PKCS #1 v1.5) algorithm is used as part of the signature
generation
process.  cmsalg-02, Section 3.2, specifies the use of the
md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate) in
the
signedData signerInfo signatureAlgorithm field (instead of the id-
rsaEncryption OID).

Isn't this kind of asking for trouble?  In addition since SignerInfo
already
specifies the hash algorithm being used as DigestAlgorithmIdentifiers, why
is
there a need to specify it again in the SignatureAlgorithmIdentifier?

Yes, this does lead to some redundancy. However, it is completely 
justifiable.  The massage digest algorithm identifier comes before the 
data, and the signature algorithm identifier comes after the data.  This 
ordering facilitates pipeline processing by the recipient.

Is this change going to cause backwards compatibility problems with 
legacy CMS
implementations?

cryptlib has a many-to-one mapping of OIDs, so this shouldn't be a problem,
as
long as there's an RSA in there somewhere it'll identify it as RSA.

Cool.

Russ