Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
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 text may be misleading. but there is 'a successful', not just 'successful'. Maybe one should clarify 'one of the successful' for that signer or so. It should say: Whenever you detect several signatures from the same signer, then it usually sufficient that only one being valid. 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. I think there is consensus. The key question is first : How can the CMS engine (*not* the application) determine which digital signatures are from the same signer. I understand that this is out of scope of the document. I don't says that I agree. 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. Since a non secure algorithm would be rejected, the signature would not be validated. But adding a comment in the security section can help. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
To the second point: Denis: you describe that the text concerning how to determine one signer with multiple signature is weak, nobody has disagreed, the text says 'ought to be' 'usually' etc. but then you start a new discussion about a single signature verification which is IMO not related at all. furthermore you insert a new feature about essCertId which is also not related. I don't think that your point 2 has anything to do with the document, I did not respond because of that although I am strongly opposed to at least some parts of what you proposed. peter 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 . i smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax (CMS) Multiple Signer Clarification) to Proposed Standard
Please see the text in the updated document. This was changed in the most recent version: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-03.txt Russ At 09:50 AM 2/15/2007, Peter Sylvester wrote: 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 text may be misleading. but there is 'a successful', not just 'successful'. Maybe one should clarify 'one of the successful' for that signer or so. It should say: Whenever you detect several signatures from the same signer, then it usually sufficient that only one being valid. 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. I think there is consensus. The key question is first : How can the CMS engine (*not* the application) determine which digital signatures are from the same signer. I understand that this is out of scope of the document. I don't says that I agree. 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. Since a non secure algorithm would be rejected, the signature would not be validated. But adding a comment in the security section can help. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
by error I send the following only to Russ 1: When more than one signature is present, the successful validation | of one signature associated with a given signer is usually treated | as a successful signature by that signer. in this text is sued twice but with different meanings, maybe this is the cause of the confusion, I propose to make the following change which does not indicate anything else. When more than one signature is present for a signer, the successful validation of one signature of that signer is usually considered as the signer having successfully signed. 2: When | the collection represents more than one signature, the successful | validation of one of signature from a given signer ought to be | treated as a successful signature by that signer. 'represent a signature' is not defined. Do you mean more than one signer? Is the text necessary at all in BOTH places? When the collection contains more than one signature from a signer the successful validation of one signature of that signer is usually considered as the signer having successfully signed. smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
My individual opinion is that these changes are a matter of style, and that the current text is fine. If there is strong support for these changes I can enter an rfc editor note. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
Sam, Russ == Russ Housley [EMAIL PROTECTED] 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
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
Denis == Denis Pinkas [EMAIL PROTECTED] writes: Denis Sam, Russ == Russ Housley [EMAIL PROTECTED] 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. Denis I do not see how it may be possible to reach a consensus if Denis a dialogue is not accepted. Russ is the editor. You said that you have already brought these issues up in the WG. It is no longer Russ's job to engage with you if he does not want to. It is the WG chairs' job to describe the reasoning for why your comments were rejected during the WG discussion and I've asked the chairs to do that. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
