ietf-smime
[Top] [All Lists]

Re: I-D ACTION:draft-ietf-smime-multisig-00.txt

2007-01-02 12:25:01
Denis:

I do not know how to constructively continue this discussion.  We do not seem to be communicating with each other.

Trying one more time...  See below.

[Russ]
Denis:

We are talking about signatures on CMS object, not signatures on
certificates. The recipient of the signed CMS object needs to be
able to validate the signature on the certificate as well as the CMS
signed object.

If the signer has a certified RSA public key, then the signer can
sign a CMS object using both RSA with SHA-1 and RSA with
SHA-256. Each one will be a SignerInfo, and the sid (using either
the issuerAndSerialNumber or the subjectKeyIdentifier) in each of
them will identify the same certified public key.

[Denis]
 
If the algorithm is "RSA" rather than "a hash function + RSA", then it works.
However, this kind of explanation is lacking in the current draft.

In most certificates used for S/MIME today, the subject public key identifier contains the algorithm identifier listed in 2.3.1 of RFC 3279:

   The OID rsaEncryption identifies RSA public keys.

      pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                     rsadsi(113549) pkcs(1) 1 }

      rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

Then, the CMS SignerInfo indicates RSA as well as the one-way hash function that is used for the encapsulated content.  These are the OID that I found in the RFCs:

      md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }

      md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }

      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }

      sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }

      sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 }

      sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 }

      sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 }

The certificate does not require the subject public key to be used with any particular one-way hash function, but the signature itself tells which one-way hash function way employed by the signer.  None of this is new!

What text needs to be added to the document?  I am willing to consider additional text, but so far, I do not see a need.

 [Russ]

If the RSA public key is placed in two certificates, one signed by
the CA using RSA with SHA-1 and the other signed by the CA using RSA
with SHA-256, then you get a better situation from a cryptographic
strength perspective. However, the subject key identifier will be
the same in both certificates, which allows the recipient to easily
detect that the signatures are from the same signer if that form of
sid is used. Which is the one that S/MIME has been encouraging for
quite some years, mostly due to size.
[Denis]
 
I disagree. RFC 3280 states:
 
4.2.1.2  Subject Key Identifier

   The subject key identifier extension provides a means of identifying
   certificates that contain a particular public key.

   (...)

   For end entity certificates, subject key identifiers SHOULD be
   derived from the public key.

You did not quote the part of Section 4.2.1.2 of RFC 3280 that describe the most commonly used technique for computing a key identifier:

      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
      value of the BIT STRING subjectPublicKey (excluding the tag,
      length, and number of unused bits).

If the two certificates contain the same RSA public key, then this value will most certainly be the same!

 Since the public keys will be different, the subject key identifiers will NOT be the same in both certificates.

Again, if the two certificates contain the same RSA public key, then this value will most certainly be the same!  You seem to be making some unstated assumptions about certification policies.

If the certificates are issued by the same CA, the subject field from the certificate would normally be the same.
If the certificates are not issued by the same CA, the permanent identifier, if present would help.
These kinds of explanations are lacking in the current draft.

I am not trying to distinguish the certificates.  The issuer and serial number would allow me to do that.

At this point, I do not know what else to say.  I am going to leave it to the S/MIME WG Chairs to determine what changes, if any, are needed to resolve your Last Call comment.

Russ
<Prev in Thread] Current Thread [Next in Thread>