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 Thursday, 29 April 1999 10:09:52 UTC