Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 10 Nov 2006 13:35:22 +0100

Russ,

The issue is more complex than presented.  :-(

The idea is to say that a message is correctly signed by a given signer, if one of the signatures 
from the *same* signer computed using a different signature algorithm is valid.

Correct ?

In the same section from RFC 3852, just above we have:

"   The process by which signed-data is constructed involves the
   following steps:

      1. For each signer, a message digest, or hash value, is computed
         on the content with a signer-specific message-digest algorithm.
         If the signer is signing any information other than the
         content, the message digest of the content and the other
         information are digested with the signer's message digest
         algorithm (see Section 5.4), and the result becomes the
         "message digest."

      2. For each signer, the message digest is digitally signed using
         the signer's private key.

      3. For each signer, the signature value and other signer-specific
         information are collected into a SignerInfo value, as defined
         in Section 5.3.  Certificates and CRLs for each signer, and
         those not corresponding to any signer, are collected in this
         step.

      4. The message digest algorithms for all the signers and the
         SignerInfo values for all the signers are collected together
         with the content into a SignedData value, as defined in Section
         5.1".

We should have a similar construct for verification, but we don't. 
It should start with:

   The process by which signed-data is verified involves the
   following steps:

  1. For each SignerInfo present in SignerInfos ...

The exercise is more difficult than it looks, because unless ESSCertID is being used, 
it is not possible to know for sure that a signature is from the same signer.

Denis

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the S/MIME Mail Security Working Group of the IETF.
>
>	Title		: Cryptographic Message Syntax (CMS) Multiple Signer Clarification
>	Author(s)	: R. Housley
>	Filename	: draft-ietf-smime-cms-mult-sign-02.txt
>	Pages		: 5
>	Date		: 2006-11-9
>	
>This document updates the Cryptographic Message Syntax (CMS), which
>   is published in RFC 3852.  This document clarifies the proper
>   handling of the SignedData protected content type when more than one
>   digital signature is present.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of 
>the message. 
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then 
>"get draft-ietf-smime-cms-mult-sign-02.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt
>

Regards,

Denis Pinkas

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Nov 2006 14:03:31 -0500

>We should have a similar construct for verification, but we don't.

When CMS was first adopted by the S/MIME WG, we decided to keep the 
specification as close to the structure of PKCS #7 v1.5 as 
possible.  The idea was to make it easy for one to determine the 
differences.  I see no reason why this discussion ought to change 
that decision.

>it is not possible to know for sure that a signature is from the same signer.

I recognize that this is true.  That is the reason that the proposed 
text points to the application that is using CMS to help when the sid 
field is not sufficient.

Russ

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 28 Nov 2006 09:52:24 +0100

Russ,

See my comments embedded.

Denis Pinkas, [email-masked]
2006-11-28 
----- Message reçu ----- 
De : Russ Housley 
À : Denis Pinkas 
Date : 2006-11-27, 20:03:31
Sujet : Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt

>from the *same* signer computed using a different signature 

You did not acknowledged that this is the goal of the draft proposal. 

The text from PKCS # 7 v1.5 is:

A recipient verifies the signatures by decrypting the encrypted message digest 
for each signer with the signer's public key, then comparing the recovered message 
digest to an independently computed message digest. The signer's public key is 
either contained in a certificate included in the signer information, or is referenced 
by an issuer distinguished name and an issuer-specific serial number that uniquely 
identify the certificate for the public key.
The text from RFC 3852 is:

A recipient independently computes the message digest.  This message digest and 
the signer's public key are used to verify the signature value.  The signer's public key 
is referenced either by an issuer distinguished name along with an issuer-specific 
serial number or by a subject key identifier that uniquely identifies the certificate 
containing the public key.  The signer's certificate can be included in the SignedData 
certificates field.

These texts are clearly insufficient, since they do not cover the case of certificate substitution.

The new draft is wishing to cover the case of signatures from the same signer. 
It is restricted to the use of certificates. Then the only way to know that is is the same signer 
is to compare the certificates. We should say some words on how this comparison shall be done.
If certificates are substituted, then we are also running into trouble.

The proposed text is clearly insufficient to cover the case.

The second point, which is even more important, is that I am not convinced 
that this is the right way to solve the problem.

If the certificate is used for non repudiation purposes, then time-stamping provides 
all the necessary protection.

If the certificate is used for authentication purposes, then the signers' certificate can simply be changed.

Denis

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 28 Nov 2006 10:49:05 -0500

At 03:52 AM 11/28/2006, Denis Pinkas wrote:

Russ,

Denis Pinkas,
[email-masked]

2006-11-28

----- Message reçu -----

De : Russ Housley

À : Denis Pinkas

Sujet : Re: I-D
ACTION:draft-ietf-smime-cms-mult-sign-02.txt

>The idea is to say that a message is correctly signed by a given

>signer, if one of the signatures

>from the *same* signer computed using a different signature

>algorithm is valid.

The document is clear.  It says:

... This document

provides replacement text for a few paragraphs, making it
clear that

the protected content is valid if any of the digital
signatures for a

particular signer is valid.

that decision.

A recipient verifies the
signatures by decrypting the encrypted message digest

for each signer with the signer's public key, then comparing the
recovered message

digest to an independently computed message digest. The signer's
public key is

either contained in a certificate included in the signer information,
or is referenced

by an issuer distinguished name and an issuer-specific serial number
that uniquely

A recipient independently computes the message
digest.  This message digest and

the signer's public key are used to verify the signature value.
The signer's public key

is referenced either by an issuer distinguished name along with an
issuer-specific

serial number or by a subject key identifier that uniquely identifies
the certificate

containing the public key.  The signer's certificate can be
included in the SignedData

certificates field.

These texts are clearly insufficient, since they do not
cover the case of certificate substitution.

The new draft is wishing to cover the case of signatures
from the same signer.

It is restricted to the use of certificates. Then the only way to
know that is is the same signer

is to compare the certificates. We should say some words on how this
comparison shall be done.

If certificates are substituted, then we are also running into
trouble.

This is not the issue at all.  Different certificates may represent
the same signer in some applications.

>The exercise is more difficult than it looks, because unless

>ESSCertID is being used,

field is not sufficient.

The proposed text is clearly insufficient to cover the
case.

The second point, which is even more important, is that
I am not convinced

This discussion has been going on for about a year.  If you are
unhappy with the proposed solution, do not ask for more work to be done
on it.  Instead, propose an alternative.  Without such, we
should proceed on the current course.

If the certificate is used for non repudiation purposes,
then time-stamping provides

This make no sense to me at all.  How does time-stamping facilitate
the transition from RSA with SHA-1 to RSA with SHA-256?  In fact, it
make it worse.  We need to transition the time stamp authority
signature too.

Russ