Sam,
>>>>>> "Russ" == Russ Housley <housley@xxxxxxxxxxxx> writes:
> Russ> Denis: I do not consider these to be new comments. You made
> Russ> them during WG Last Call, and there was considerable
> Russ> discussion on the S/MIME WG mail list. In the end, you were
> Russ> unable to gain any support for your position. Why do you
> Russ> feel I need to respond to the same comments again?
>I tend to agree with Russ.
I do not see how it may be possible to reach a consensus if a dialogue is not accepted.
There are indeed two different issues:
1 - The document goes beyond specifying how to determine if a message
is validly signed by a given signer. The core of the dispute is the following
proposed sentence:
| When the collection represents more than one signature, the successful
| validation of one of signature from each signer ought to be
| treated as a successful validation of the signed-data content type.
This sentence implicitly states that the document as a whole is well signed
when all the signers have signed it !!! It cannot stay like that.
The intent was to say the message was validly signed by a given signer,
if any of the digital signatures from that signer is valid.
The key question is first : How can the CMS engine (*not* the application)
determine which digital signatures are from the same signer.
Russ said:
"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".
The reality is the following: it is easy (but not said anywhere in te document)
if the new certificate is using rsaEncryption, but what about if the algorithm changes
to id-RSASSA-PSS ?
If the application needs to determine which signatures are from the same signer,
then it should not be in the CMS specification and .... good luck for application developpers
who are left alone ! I believe that the CMS engine should be instructed to determine
which signatures are from the same signer.
The second point (and I have not mentionned this argument before) is that saying
that "the message was validly signed by a given signer, if any of the digital signatures
from that signer is valid" only works if the algorithms used are *all* considered
as secure. A few words in the security considerations section (only 3 lines today)
would certainly help to take care of that point.
2 - There is not enough precision in the description of how to validate a signature.
In other words, is the current description for signature verification clear enough ?
On November 27, Russ said:
"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 description that is in PKCS #7 v1.5 is pretty unclear. It should be improved.
Also at the time PKCS #7 v1.5 was written, RSASSA-PSS did not existed and since
it identifies both RSA and the hash function, the controls to be made when it is used
now need to be defined.
In RFC 3852, we have a clear definition of the process to sign data:
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.
The thread initiated in January 2007 by Julien Stern has demonstrated that the current text
for signature verification is not clear enough. However, the text has not been clarified
to reflect the discussion that took place on the list. I have made a new text proposal on January 26,
and no one, including Russ, has ever responded to it .
Now, if a phone call may allow a faster progression, I am ready to call, or here is my phone number:
00 33 1 30 80 75 24.
This topic is important to me.
Denis
____________________________________________________________________________________
>The editor's job is to make changes after consensus is built.
>I tried to give you (Denis) some advice on how to break up your issues
>and focus on what you really want. It sounds from your message to
>Russ like you chose not to take that path.
>Either way, though, the document will not change unless you build
>consensus to change the document.
>--Sam
Regards,
Denis Pinkas
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf