Re: I-D ACTION:draft-ietf-smime-cms-mult-sign-02.txt
2006-11-30 09:59:24
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
|
|