Subject: RE: cmsalg-02 RSA OID Proposal

From: [email-masked] (Peter Gutmann)
Date: Sat, 1 Sep 2001 17:59:49 +1200 (NZST)

"Pawling, John" <[email-masked]> writes:

>RFC2459 specifies the use of the rsaEncryption OID to indicate that an RSA
>public key is present in the subjectPublicKey field of a certificate. RFC2459
>specifies the use of the md5WithRSAEncryption or sha1WithRSAEncryption OID (as
>appropriate) in the certificate signatureAlgorithm field when the RSA (PKCS #1
>v1.5) algorithm is used to sign the certificate.
>
>RFC2630 specifies the use of the rsaEncryption OID in the signedData
>signerInfo signatureAlgorithm field when the RSA (PKCS #1 v1.5) algorithm is
>used as part of the signature generation process.

RFC2459 requires a unified OID because there's only one place to specify both,
the signatureAlgorithm field.  RFC2630 splits this so there's on OID for the
hash algorithm and another for the signature algorithm.  Both usages are
consistent, it doesn't seem a good idea to force RFC2630 into an inconsistent
usage just to make it look like RFC2459.

Peter.

---

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 5 Sep 2001 12:44:20 -0700

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:[email-masked]]
Sent: Saturday, September 01, 2001 9:03 AM
To: [email-masked]
Cc: [email-masked]
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

---

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 5 Sep 2001 16:06:20 -0700

I don't disagree with your comments, John -- the only thing I was trying to
point out is that there was a precedent in the original design that we chose
to ignore for DSA, and just trying to justify the original separation the
identification of "digest" and "the other thing that isn't the digest but
which takes as input the digest and the public key and maybe other stuff in
order to make sure the signature is valid" (which I think would make a lousy
name for this field in the ASN.1, but I don't have a good substitute).

If all we're trying to do is change it to satisfy our own guilt that this
inconsistency exists, I might suggest that we simply get over it and put a
big apologetic paragraph in here that indicates our remorse, and not risk
breaking implementations with this change.

Blake

-----Original Message-----
From: Pawling, John [mailto:[email-masked]]
Sent: Wednesday, September 05, 2001 2:11 PM
To: [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal

Blake,

I agree with your point that the RFC 2630 specification of
signatureAlgorithm OIDs is inconsistent (i.e. id-dsa-with-sha1 is
inconsistent with rsaEncryption).  However, I disagree with your statement
that id-dsa-with-sha1 doesn't work as an indicator of "what identifier from
a certificate's SubjectPublicKeyInfo would be required to verify this
signature".  It is straightforward to develop CMS implementations to
recognize that the presence of the id-dsa-with-sha1 OID in the signedData
signerInfo signatureAlgorithm field indicates that the certificate required
to verify the signature must contain the id-dsa OID in the
SubjectPublicKeyInfo algorithm field.  Similarly, it is straightforward to
develop CMS implementations to recognize that the presence of either the
md5WithRSAEncryption or sha1WithRSAEncryption OID in the signedData
signerInfo signatureAlgorithm field indicates that the certificate required
to verify the signature must contain the rsaEncryption OID in the
SubjectPublicKeyInfo algorithm field.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

---

From: "Pawling, John" <[email-masked]>
Date: Thu, 6 Sep 2001 15:25:51 -0400

Russ,

I like that idea.  That strategy would allow the S/MIME Message Spec to
specify the use of the rsaEncryption OID to preserve backwards compatibility
with legacy S/MIME implementations (if that is what is decided by the
group).  It would also allow another protocol that employs CMS to specify
the use of the md5WithRSAEncryption or sha1WithRSAEncryption OID (as
appropriate).

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 11:31 AM
To: [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal

Hey everyone.

Perhaps the CMSALG document should include the specifications for both 
approaches.  Then, the upcoming MSG update will deal with the MUST and 
SHOULD statements.

What do you think?

Russ

---

From: "Blake Ramsdell" <[email-masked]>
Date: Thu, 6 Sep 2001 14:42:57 -0700

Yes, that seems reasonable.  As long as the CMS spec does not preclude the
use of rsaEncryption in this section, the MSG draft can specify how
important it is to use it for backward compatibility.

Blake

-----Original Message-----
From: Pawling, John [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 12:26 PM
To: [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal

Russ,

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 11:31 AM
To: [email-masked]
Subject: RE: cmsalg-02 RSA OID Proposal

Hey everyone.

What do you think?

Russ

---

From: "Dieter Bratko" <[email-masked]>
Date: Tue, 11 Sep 2001 17:58:25 +0200

Hello,

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

Since CMS respectively S/MIMEv3 claims for backward compability to PKCS#7v1.5
respectively S/MIMEv2 should backward compatibility problems with  
PKCS#7v1.5 and S/MIMEv2 applications not be of concern, too?

Just for testing I have tried to send two signed mails to Netscape
Messenger (4.7), the one specifiying rsaEncryption as the signerInfo´s
signature algorithm, the second sha1WithRSAEncryption. Whereas the
first mail was succesfully verified, Netscape failed in verifying
the second mail by giving the following warning message:

Invalid Signature:
"Warning! In the time since the sender sent you this message and you
received it, the message appears to have been altered. Some or all of the
content of this message has been changed. You should contact the
message sender and/or your system administrator."

However, no problems for both messages when verifying with Outlook 
Express or Outlook 2000.

Regards,
Dieter Bratko, IAIK

-----Ursprüngliche Nachricht-----
Von: [email-masked]
[mailto:[email-masked]]Im Auftrag von Pawling, John
Gesendet: Freitag, 31. August 2001 17:44
An: SMIME WG (E-mail)
Betreff: cmsalg-02 RSA OID Proposal

All,

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).  The cmsalg-02 proposed use of these OIDs is
consistent with their use in the RFC2459 PKIX Certificate/CRL Profile.  The
RFC2630 use of the id-rsaEncryption OID is inconsistent with RFC2459.  

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

The current release of the S/MIME Freeware Library (SFL) (available from
<http://www.getronicsgov.com/hot/sfl_lib.htm>) can successfully verify a
signedData content type that includes a signerInfo signatureAlgorithm field
that includes the md5WithRSAEncryption, sha1WithRSAEncryption or
rsaEncryption OID (as appropriate).  Therefore, the proposed cmsalg-02 use
of the md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate)
would not cause backwards compatibility problems for those applications that
use the SFL along with a crypto library that supports the algorithms
indicated by the OIDs. 

Feedback from others is welcome!  This is an important issue.

---

From: "Pawling, John" <[email-masked]>
Date: Wed, 12 Sep 2001 10:27:52 -0400

Terry,

Thank you for reporting that the cmsalg-02 proposal to require the use of
the md5WithRSAEncryption or sha1WithRSAEncryption OID (as appropriate) in
the signedData signerInfo signatureAlgorithm field when the RSA (PKCS #1
v1.5) algorithm is used as part of the signature generation process is
incompatible with the Netscape Communicator S/MIME (CMS) implementation. 

Based on that fact, I agree that the son-of-RFC2633 S/MIME v3 Message Spec
should mandate the use of the rsaEncryption OID in the signedData signerInfo
signatureAlgorithm field when the RSA (PKCS #1 v1.5) algorithm is used as
part of the signature generation process.