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

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 2 Jan 2007 13:53:14 +0100

Russ,

Thank you for the explanations.

 See my comments in line.

----- Message reçu ----- 
De : Russ Housley 
À : Denis Pinkas,[email-masked] 
Date : 2006-12-27, 18:31:37
Sujet : Re: I-D ACTION:draft-ietf-smime-multisig-00.txt

[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.

[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. 

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

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.

Denis

==================================================================

Russ

At 11:18 AM 12/27/2006, Denis Pinkas wrote:

>Russ,
>
>I probably missed something.
>
> >Denis:
>
> >You make some good points about the document, and I am sure that they
> >will spur discussion. However, I want to talk about this part of 
> your message:
>
> >>This document is necessary so that
> >>draft-ietf-smime-cms-mult-sign-02.txt may be applicable.
> >>The two documents should be merged.
>
> >>Let me explain briefly :draft-ietf-smime-cms-mult-sign-02.txt does
> >>not provide any means so that,
> >>at the CMS level, an application can figure out that the same signer
> >>has placed two SignerInfo structures.
> >>This new draft fills in the gap.
>
> >This is not accurate. In fact, for the transition that we are facing
> >right now, from RSA with SHA-1 to RSA with SHA-256, the document does
> >provide the means to determine that two SignerInfo structures are
> >associated with the same signer. Yet, other transitions require more
> >knowledge of the application, and the document warns about this situation.
>
>Usually, if the CA chooses to issue a certificate with SHA-256, it 
>will also change
>the value of the private key and sometimes augment the size of the key.
>
>Would you explain, in a few words, the assumption under which the 
>link is provided
>at the CMS level (i.e. not at the application level) ?
>
>Denis
>
> >S/MIME is not the only application that uses CMS. I think the
> >documents should remain separate.
>
> >Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 02 Jan 2007 13:33:49 -0500

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:

signed object.

[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]

[Denis]

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

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