Denis,
I was expecting it is bad because ... I believe we should provide more
information when we can and we can in this case - so I think this draft is
very useful. Unless I hear a stampede of support to kill off this draft,
it's going proceed through the WG last call process. Assuming it makes it
all the way through without further objections, when I produce the write up
for the AD I will make sure to note your concern.
spt
_____
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Denis Pinkas
Sent: Friday, December 01, 2006 7:42 AM
To: 'ietf-smime'
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Sean,
The CMS specification may say : "The digital signature is valid if ..."
The CMS specification may also say : "The decryption process is valid if
..."
The CMS specification should not attempt to enter the area of saying " The
message is valid if ...."
Validity of a message implies its semantics, may imply whether it is
encrypted or not,
whether it is signed by the right entities or not, whether it is
counter-signed by the right entities or not, etc ...
The key point is to say how to validate ONE digital signature. We already
have some text in CMS.
I believe that this text would need to be improved, but this is another
story.
Digital signature validation occurs one by one, independently of any other
digital signature validation.
Using CMS it is already possible to have multiple signatures.
Now, if you really think to some *guidance* should be added to explain
algorithm transition
from the perspective of RPs, then it should be in an INFORMATIVE annex and
the core of the document
does not need to be changed. It could also be in an INFORMATIVE RFC.
Denis
PS. I will be leaving my office tonight for 2 weeks.
Be aware, that you will not get replies from me on this thread during
that time period.
_____
Denis,
Why is saying something about processing multiple signatures a bad idea? I
think it's a good idea to provide as much implementation advice as possible
especially knowing that some implementations will transition with multiple
signatures. I think including the text is much better than relying on the
collective obviousness of something.
I am also confused about why you think the draft says "the message is valid
if". The draft doesn't not use the RFC 2119 words when describing
processing of multiple signatures ("usually" and "ought" are the two words
that stick out). Further, the draft then says application environments can
be configured to do other things ... so there's an out for environments that
want to act differently.
spt
_____
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Denis Pinkas
Sent: Thursday, November 30, 2006 11:42 AM
To: ietf-smime
Subject: Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
Russ,
You are correct: "The current CMS specification says nothing about
validating multiple signatures. "
... and it should stay this way.
The CMS specification should not attempt to enter the area of saying " The
message is valid if ...."
Transition can simply be accomplished by placing two signatures.
I do not think that we need an amendment to CMS to say this, since it is
obvious.
Denis
_____
Denis:
The current CMS specification says nothing about validating multiple
signatures. This means that it is unclear whether a message is valid if the
recipient cannot validate all of them. The S/MIME WG started by considering
two choices:
(1) The message is valid if any of the signatures is valid; and
(2) The message is valid if all of the signatures are valid.
Discussion on this mail list made it clear that neither of these approaches
was acceptable. There are some applications that have multiple signers, and
the application needs a valid signature for each one of them. So, we
settled on:
(3) The message is valid if one signature from each signer is valid.
Further discussion made it clear that the application was going to have to
be involved in determining which signatures are associated with the same
signer in some cases. However, in the most urgent case we are concerned
with RSA with SHA-1 and RSA with SHA-256, the same certificate will be used
for both signatures, so the same signer is obvious.
Russ
At 02:23 AM 11/30/2006, Denis Pinkas wrote:
Russ,
Your short response below does not seem to me an objection to my
argumentation.
You say: the application (...) can only verify one of the signatures.
I say: The *application* [will] be pleased if one of them is valid.
The core issue is still that no change needs to be made to the CMS document.
Denis
_____
Not so. If the application only implements SHA-1, then it can only verify
one of the signatures.
Russ
At 09:51 AM 11/29/2006, Denis Pinkas wrote:
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
_____
_____
_____
_____
_____