ietf-smime
[Top] [All Lists]

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

2006-11-29 08:40:59
Russ,

Sorry, once again I disagree with the wording. The *application* can verify 
both signatures and be pleased if one of them is valid.
No change needs to be made to the CMS document.
 
Denis



Denis:

We seem to be working on two different problems.  We want to transition from 
RSA with SHA-1 to RSA with SHA-256.  So, the signer puts two signatures on the 
message, since not all of the recipients support RSA with SHA-256 yet.  If 
either of the signatures can be validated by a recipient, then that recipient 
will consider the message valid.

Russ


At 04:06 AM 11/29/2006, Denis Pinkas wrote:

Russ,
 
I believe that we have a major disagreement on the goal of the proposed 
document.
 
The current goal is :     
 
    ... 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.
It is possible to check that a given signature is valid.
The golden rule is that only one signature can be verified at a time. 
 
This is fully different of saying that a "protected content" (i.e. a document) 
is valid, which may mean to verify multiple signatures.
 
As an example, a document can be said to be only be valid when it bears three 
parallel signatures 
from particular signers, and in addition of two them need to be counter-signed 
by other particular signers.
 
The verification of multiple signatures is at the level of the application, not 
at the level of a CMS toolkit.
 
Besides this major observation, there is no need to support multiple signatures 
from the same signer for algorithm agility purposes.
 
Finally, you raised the following question:
 
"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".
 
Please refer to RFC 3126 :
 

  B.4.7  Time-Stamping for Long Life of Signature                    
79<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
 
Signatures may need to be maintained, which means that for signatures that need 
to last very long, more than one time-stamp 
may need to be added later on, but only in case of a real collision. To respond 
to your question, RSA with SHA-256 will need 
to be mandatorilly used, when after X months of computation someone will 
demonstrate a collision. Then since it takes X months 
to make a collision, the signature maintenance needs to be made in a time less 
than X months.
 
Denis
 


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

 Russ,
 
See my comments embedded.
 
Denis Pinkas, Denis(_dot_)Pinkas(_at_)bull(_dot_)net
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

Denis:

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 ? 
You did not acknowledged that this is the goal of the draft proposal. 

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.


 

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.

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.

 
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.

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


 
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.

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

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 
all the necessary protection.

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