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 11:04:18 UTC