Subject: Re: WG Last Call: draft-ietf-smime-multisig-03

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 10 Dec 2007 14:45:05 +0100

>This message initiates an SMIME Working Group Last Call on the document:

> Title     : Multiple Signatures in S/MIME 
> Author(s) : S. Turner and J. Schaad
> Filename  : draft-ietf-smime-multisig-03.txt
> Pages     : 19
> Date      : 2007-11-16

I have two minor comments:

1 - On page 5, the last line refers to section 4.3. However, it is unclear why.

2 - In the security considerations section, the third paragraph states:

   This attribute provides no protection if all of the algorithms used 
   in the signer attribute are 'cracked'. 

This is not always true. If two different one way functions exhibit collisions, 
finding a message where a collision may be found *at the same time* 
for each one way function may not be straightforward.

Denis

>CMS SignedData includes the SignerInfo structure to convey per-signer
>information. SignedData supports multiple signers and multiple signature
>algorithms per-signer with multiple SignerInfo structures. If a signer
>attaches more than one SignerInfo, there are concerns that an attacker could
>perform a downgrade attack by removing the SignerInfo(s) with the 'strong'
>algorithm(s). This document defines the multiple-signatures attribute, its
>generation rules, and its processing rules to allow signers to convey
>multiple SignerInfo while protecting against downgrade attacks.
>Additionally, this attribute may assist during periods of algorithm
>migration.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-03.txt
>
>The purpose of this WG Last Call is to ensure that the Working Group has
>achieved consensus that the document is suitable for publication as a
>Standards Track RFC.
>
>Please review the document for both technical and editorial problems.
>Technical issues should be discussed on this list. Editorial issues may be
>sent to the document editor.
>
>The Last Call period will end on 9 Janurary 2008.
>
>Upon completion of the last call, the WG chairs will take action based upon
>the consensus of the WG. Possible actions include:
>
>    1) recommending to the IETF Security Area Directors
>       that the document, after possible editorial or
>       other minor changes, be considered by the IESG
>       for publication as an Informational RFC
>       (which generally involves an IETF-wide Last Call); or
>
>    2) requiring that outstanding issues be adequately
>       addressed prior to further action (including,
>       possibly, another WG Last Call).
>
>Remember that it is our responsibility as Working Group members to ensure
>the quality of our documents and of the Internet Standards process.  So,
>please read and comment!
>
>Blake
>-- 
>Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 10 Dec 2007 10:15:36 -0800

Denis,

See below.

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Denis Pinkas
> Sent: Monday, December 10, 2007 5:45 AM
> To: [email-masked]
> Subject: Re: WG Last Call: draft-ietf-smime-multisig-03
> 
> 
> 

I agree this is true.  How about the wording:

This attribute cannot be relied upon in the event that all of the algorithms
used in the signer attribute are 'cracked'.  It is not possible for a
verifier to determine that a collision could not be found that satisfies all
of the algorithms.

Jim

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 13 Dec 2007 10:09:27 +0100

Jim,

1 - What would you propose to solve comment 1 ?

2 - For comment 2, I would propose the following text instead:

If two different one-way functions used in different signed attributes
exhibit collisions, finding a message where a collision may be found at 
the same time for each one way function may not be straightforward. So, 
if both one-way functions are cracked, verifying two linked signerInfo 
structures at the same time may still provide some level of confidence.

Denis

>>>This message initiates an SMIME Working Group Last Call on the
>>>      
>>>
>>document:
>>
>>    
>>
>>>information. SignedData supports multiple signers and multiple
>>>      
>>>
>>signature
>>    
>>
>>>attaches more than one SignerInfo, there are concerns that an attacker
>>>      
>>>
>>could
>>    
>>
>>>perform a downgrade attack by removing the SignerInfo(s) with the
>>>      
>>>
>>'strong'
>>    
>>
>>>algorithm(s). This document defines the multiple-signatures attribute,
>>>      
>>>
>>its
>>    
>>
>>>The purpose of this WG Last Call is to ensure that the Working Group
>>>      
>>>
>>has
>>    
>>
>>>Technical issues should be discussed on this list. Editorial issues
>>>      
>>>
>>may be
>>    
>>
>>>Upon completion of the last call, the WG chairs will take action based
>>>      
>>>
>>upon
>>    
>>
>>>Remember that it is our responsibility as Working Group members to
>>>      
>>>
>>ensure
>>    
>>
>>>the quality of our documents and of the Internet Standards process.
>>>      
>>>
>>So,
>>    
>>
>>>please read and comment!
>>>
>>>Blake
>>>--

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 13 Dec 2007 22:20:31 -0800

Denis,

1.  We are going to change the reference, I thought you had already been
copied on such a message.

2.  I cannot accept this language as I don't believe one will be able to
tell when the problem is straightforward and when it is not.  I think that
we need to be more conservative that your proposed language is.

Jim

> Sent: Thursday, December 13, 2007 1:09 AM
> To: [email-masked]

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 14 Dec 2007 10:01:44 -0500

We're going to change the reference to 4.4.1 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Jim Schaad
>Sent: Friday, December 14, 2007 1:21 AM
>To: 'Denis Pinkas'; [email-masked]
>Subject: RE: WG Last Call: draft-ietf-smime-multisig-03
>
>
>Denis,
>
>1.  We are going to change the reference, I thought you had 
>already been copied on such a message.
>
>2.  I cannot accept this language as I don't believe one will 
>be able to tell when the problem is straightforward and when 
>it is not.  I think that we need to be more conservative that 
>your proposed language is.
>
>Jim
>
>> exhibit collisions, finding a message where a collision may be found 
>> at the same time for each one way function may not be 
>straightforward. 
>> So, if both one-way functions are cracked, verifying two linked 
>> signerInfo structures at the same time may still provide 
>some level of confidence.
>> 
>> Denis
>> 
>> >Denis,
>> >
>> >See below.
>> >
>> >
>> >>>Author(s) : S. Turner and J. Schaad Filename  : 
>> >>>draft-ietf-smime-multisig-03.txt
>> >>>Pages     : 19
>> >>>Date      : 2007-11-16
>> >>>
>> >>>
>> >>This is not always true. If two different one way 
>functions exhibit 
>> >>collisions, finding a message where a collision may be 
>found *at the 
>> >>same time* for each one way function may not be straightforward.
>> >>
>> >>
>> >
>> >>>achieved consensus that the document is suitable for 
>publication as
>> a
>> >>>Standards Track RFC.
>> >>>

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 14 Dec 2007 10:04:24 -0500

I prefer the general consideration too.