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.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