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 Wednesday, 28 April 1999 16:38:51 UTC