Re: XML versus ASN.1/DER blob

> (3) XML Signature Syntax.  There appears to be controversy here.  Some want
> to start with CMS/PKCS#7 but map it into XML syntax and extend it to meet
> the requirements, presumably resulting in something like the Richard Brown
> proposal.  Others want to just use a PKCS#7 binary blob.
>      The blob approach loses all of the transparency and extensibility of
> XML.  It is not clear that it can meet the requirements for support of
> keyed hashes.  You are locked into having two mutually alien sets of
> encoding/decodig logic: XML and ASN.1/DER.

So there are a couple types of data that will wind up in XML signatures:
    1) binary data -- the actual signature itself is some form of binary
encoding. It will have no meaning to an XML application itself. This also
includes things like X.509 certificates.
    2) data the underlying security system needs to verify the signature.
    3) data the XML application needs to to interpret to complete it's task
(authentication, authorization, semantic meaning of the signature, etc).

Data types 1 and 2 should be PKCS #7 blobs. Data types 3 should be XML. The
resulting document should be an XML document with imbedded PKCS #7 blobs.

The issue comes when the the data overlaps (both the underlying security system
AND the application needs the data). Even worse is the case where the data is
somehow imbedded in the X.509 Certificate. The Certificate is already a binary
object. They are not cannonicalized objects... who arbitarily cast them into
XML and still verify their signature. If an application need to access the DN
in the cert, or some certificate extension in order to do it's work, the
application will necessarily need to cooperate with the underlying security
system to get these functions. You could define XML copies of these fields, but
there would be no way of verifying these fields were correct (other than asking
the underlying security system if they matched).

This means that we need to define how XML applications can get access to
non-XML objects anyway.

>
>      On the other hand, wtih XML syntax as show in the Richard Brown
> proposal, you do have the readability and extensibility that are goals of
> XML.

I don't see anything wrong with the base structure of Richard's proposal. We
just need to spend the time to hash out what specifically shows up as XML tags,
what shows up in PKCS #7 blobs, what shows up in both, and how do XML
applications get to stuff in the PKCS #7 blob, and what shows up in both.

>
>      Quite frankly, if you go with the blob, I don't see any justification
> for calling the result an XML digital signature.

Any more than MIME considers the PKCS #7 blob at the end of an S/MIME message a
MIME signature? It's a MIME signature because it signs a mime document, and is
bundled in a package. You can spit this thing out to a standard MIME reader and
it will do something reasonable with it. XML should be the same thing.

bob

Received on Tuesday, 20 April 1999 13:12:43 UTC