W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

RE: Example of XML-DSIG and CMS

From: Richard D. Brown <rdbrown@GlobeSet.com>
Date: Fri, 30 Apr 1999 13:28:16 -0500
To: <dee3@us.ibm.com>, "'XML-DSig Workshop'" <w3c-xml-sig-ws@w3.org>
Message-ID: <002201be9337$3754a0d0$0bc0010a@artemis.globeset.com>
Donald,

I was not proposing that we change anything in CMS, but rather not make use
of some of its features when signing XML. I assumed that attributes (other
that the mandatory ones for detached-signature) are not inserted by the CMS
engine unless explicitly requested by the application layer.

Otherwise, I totally agree with you regarding the huge among of data that is
replicated in the CMS blob, and be sure that I do not promote this solution.
I was trying to be objective not denying the possibility to support CMS or
Pen-OP with the current syntax.

Sincerely,

Richard D. Brown


> -----Original Message-----
> From: w3c-xml-sig-ws-request@w3.org
> [mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of dee3@us.ibm.com
> Sent: Friday, April 30, 1999 9:38 AM
> To: 'XML-DSig Workshop'
> Subject: RE: Example of XML-DSIG and CMS
>
>
> Well, you can say that you are prohibiting attributes inside
> the CMS blob
> but the idea of using CMS is to use current code, as I
> understand it.  Thus
> I don't see how you can enforce this prohibition.  And if you
> are going to
> go to the effort to modify CMS to not allow attributes, you
> might as well
> just directly call the lower level crypto.
>
> You have a lot of algorithm/keying/identification information in ASN.1
> inside the blob and in XML outside the blob.  How can you
> tell that they
> are the same?  If there are policy constraints, seems like
> they can't just
> act on the XML version but need to excavate the info from
> inside CMS where
> it is actually effective.
>
> I have no problem with the canonicalizer being seprately specified.
>
> Thanks,
> Donald
>
> Donald E. Eastlake, 3rd
> 17 Skyline Drive, Hawthorne, NY 10532 USA
> dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833
>
> home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> dee3@torque.pothole.com   tel: 1-914-276-2668
>
>
>
> "Richard D. Brown" <rdbrown@globeset.com> on 04/29/99 10:09:24 AM
>
> Please respond to rdbrown@globeset.com
>
> To:   Donald Eastlake/Hawthorne/IBM, "'XML-DSig Workshop'"
>       <w3c-xml-sig-ws@w3.org>
> cc:
> Subject:  RE: Example of XML-DSIG and CMS
>
>
>
>
>
> Donald,
>
> I think that there is another approach that could satisfy the
> requirements
> of a crypto-engine (CMS, PenOP, etc...) in general. We could
> simply assume
> these engines as "specific crypto-algorithms" and leverage the current
> syntax.
>
> <Signature>
>   <Manifest>
>     (resource information block)
>     (optional authenticated attributes)
>     (originator information block)
>     (optional recipient information block)
>     <Canonicalizer>
>       <Algorithm type='urn:w3c-org:xcf'\>
>     </Canonicalizer>
>     <SignatureAlgorithm>
>       <Algorithm type='urn:ietf-org:cms'\>
>     </SignatureAlgorithm>
>   </Manifest>
>   <Value encoding='base64'>
>     (CMS Blob)
>   </Value>
> </Signature>
>
> <Certificates>
>   (certificate information blocks)
> </Certificates>
>
> For signature computation the XML-DSIG implementation will
> have to indicate
> the underlying crypto-algorithm (i.e. RSAwithSHA1), the
> keying material,
> and
> optionaly the certificate-chain to the CMS crypto-engine.
>
> This simple approach should work, but, as you have mentioned in your
> previous email, there will be a lot of redundant pieces of information
> between the Manifest and the encoded CMS blob. Also, I think we should
> mandate that the CMS blob SHALL NOT contain any authenticated
> attribute.
> Also, if we were to consider "crypto-engines", none SHALL be made
> mandatory.
>
> BTW: Notice that the Manifest explicitly refers to the canonicalizer
> algorithm. This has nothing to do with this particular
> proposal (though
> helpful in this case), but is an option that I have proposed
> in the last
> draft document (see #99040103).
>
> *** THIS PROPOSAL DOES NOT REFLECT MY POSITION IN REGARD TO USING
> CRYPTO-ENGINES SUCH AS CMS OR PEN-OP ***
>
> Sincerely,
>
> Richard D. Brown
>
>
> > -----Original Message-----
> > From: w3c-xml-sig-ws-request@w3.org
> > [mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of dee3@us.ibm.com
> > Sent: Wednesday, April 28, 1999 3:23 PM
> > To: XML-DSig Workshop
> > Subject: Re: Example of XML-DSIG and CMS
> >
> >
> > I would say, in its purest form, it is the difference
> between the top
> level
> > element in Richard  Brown's draft
> >
> > <signature>
> >      <manifest>
> >           (resources information block)
> >           (optional authenticated attributes)
> >           (originator information block)
> >           (optional recipient information block)
> >           (optional key agreement algorithm block)
> >           (sigature algorithm)
> >      </manifest>
> >      <value encoding='base64'>
> >           base64-of-PKCS#1-or-other-encrypted-blob-signature
> >      </value>
> > </signature>
> >
> > and
> >
> > <signature encoding='base64'>
> >      base64-of-ASN.1-encoded-CMS-signatures-blob
> > </signature>
> >
> > where all the stuff out in the open in the Brown proposal
> is now buried
> in
> > an ASN.1 BER blob.  Since this is pretty distasteful, you
> would probably
> > want to back out the resources blob, which is straightforward
> > to do, so you get
> >
> > <siganture>
> >      (resources information block)
> >      <value encoding='base64'
> >           base64-of-ASN.1-encoded-CMS-detached-sigantures-blob
> >      </value>
> > </signature>
> >
> > which would also mean that any per resource attributes
> would be in the
> > open.  However, as you try to go further and drag more out
> of the ASN.1
> > encoding into the light of day while staying with CMS
> >
> (<http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-13.
> txt>), it
> > gets much stickier.  You can try dragging the signature level
> authenicated
> > attributes out like
> >
> > <siganture>
> >      <manifest>
> >           (resources information block)
> >           (authenticated attributes block)
> >      </manifest>
> >      <value encoding='base64'
> >           base64-of-ASN.1-encoded-CMS-detached-sigantures-blob-
> >           including-ASN.1-encoded-authenticated-attributes
> >      </value>
> > </signature>
> >
> > but, as shown, there could still be some, which might be the same or
> > contradictory or just different, buried in the CMS.  In fact CMS
> > specifically defines an ASN.1 encoded time of signing
> > attribute which is
> > presumably what you are supposed to use for that if you are
> > CMS conformant
> > and defines an ASN.1 encoded countersignature attribute,
> etc.  And you
> > really can't drag out the algorithm, originator, or recipient
> information.
> > Or at least, while you can put them in an XML encoded
> > manifest, they still
> > have to appear ASN.1 encoded inside the CMS blob where they could be
> > inconsistent, etc.
> >
> > (Well, to be precise, you could just explode the
> > non-encrypted part of the
> > CMS from ASN.1 into XML after some signature engine produced
> > the CMS blob
> > but you would, of course, have to have encoded all the
> > information into
> > ASN.1 when it was signed and re-encode all the information
> > back into an
> > ASN.1 CMS blob for verification.  Doing this doesn't seem
> to make much
> > sense, since it implies code that which understands XML and
> all these
> > elements.  This code could just as easily call the next
> level down of
> > crypto library.  Requiring the code to also undersand ASN.1
> > and going into
> > and out of an ASN.1 form doesn't seem to add anything but
> complexity.)
> >
> > At the risk of further controvery, I suppose I should talk about
> > certificates/CRLs also.  With CMS, these are included in
> the blob and
> > constrained to be X.509, which is ASN.1 encoded.   With the Richard
> Brown's
> > markup, certficiates, when needed, are in a <certificate> element,
> usually
> > gathered into a <certificates> aggregate, and there is provision for
> > arbitrary certificate types of which, no doubt, X.509 will
> be common for
> > some time.  It might seem natural to have certificates coupled to
> > sigantures in a strucuture, such as CMS, but as soon as you get to
> complex
> > cases like messages with multiple different signatures, it
> is common for
> a
> > certificate to help in the authentication of several of
> these.  Thus, I
> > believe, it is really the most natural model to consider all the
> > certificates in a message to be in a single pool that needs to be
> available
> > to help validate any of the signatures in the message, rather than
> coupled
> > to a particular signature.
> >
> > Hope this is helpful,
> >
> > Thanks,
> > Donald
> >
> > Donald E. Eastlake, 3rd
> > 17 Skyline Drive, Hawthorne, NY 10532 USA
> > dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833
> >
> > home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
> > dee3@torque.pothole.com   tel: 1-914-276-2668
> >
> >
> >
> > "Joseph M. Reagle Jr." <reagle@w3.org> on 04/27/99 04:59:42 PM
> >
> > To:   "XML-DSig Workshop" <w3c-xml-sig-ws@w3.org>
> > cc:    (bcc: Donald Eastlake/Hawthorne/IBM)
> > Subject:  Example of XML-DSIG and CMS
> >
> >
> > I often find it helps me when their's contention to have
> two proposals
> > before me, with examples. Since I'm not sure there _is any_
> disagreement,
> > would someone do me the favor of writing up at least one
> quick example
> > showing what a CMS blob would look like in (an extension)
> of Richard's
> > synatx? If someone then sees they disagree, it should be
> clear what type
> of
> > example would demonstrate the difference.
> >
> > ___________________________________________________________
> > Joseph Reagle Jr.  W3C:     http://www.w3.org/People/Reagle/
> > Policy Analyst     Personal:  http://web.mit.edu/reagle/www/
> >                    mailto:reagle@w3.org
> >
>
>
>
Received on Friday, 30 April 1999 14:28:34 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 11:28:04 EDT