RE: WG Last Call: draft-ietf-smime-multisig-03

We're going to change the reference to 4.4.1 

> -----Original Message-----
> From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
> [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Jim Schaad
> Sent: Friday, December 14, 2007 1:21 AM
> To: 'Denis Pinkas'; ietf-smime(_at_)imc(_dot_)org
> 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
>
> > -----Original Message-----
> > 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, December 13, 2007 1:09 AM
> > To: ietf-smime(_at_)imc(_dot_)org
> > Subject: Re: WG Last Call: draft-ietf-smime-multisig-03
> >
> >
> > 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
> >
> > > Denis,
> > >
> > > See below.
> > >
> > >
> > > > -----Original Message-----
> > > > 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: Monday, December 10, 2007 5:45 AM
> > > > To: ietf-smime(_at_)imc(_dot_)org
> > > > Subject: Re: WG Last Call: draft-ietf-smime-multisig-03
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > 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.
> > > 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
> > >
> > >
> > >
> > > > 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.tx
> > > > > t
> > > > >
> > > > > 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