Re: XML versus ASN.1/DER blob

See comments indicated by ###

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



relyea@netscape.com (Bob Relyea) on 04/20/99 01:12:01 PM

To:   Donald Eastlake/Hawthorne/IBM
cc:   w3c-xml-sig-ws@w3.org
Subject:  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.

### While the inner encrypted hash or keyed hash or whatever is an octet
stream, it has no structure.  In Secure XML, structured items should be
encoded in XML.  That's what XML is good for, structured data.  This
certainly includes 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.

### If you want to define a "PKCS7" signature algorithm and do things in
a hybrid XML / ASN.1 fashion, I suppose you should be able to.  But people
who want to really do it in XML without having to drag in ASN.1/DER
encoders and decoders, in addition to their XML logic, should be able to
also.

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.

### XML applications should be accessing things with DOM or the like.

>      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.

### In an XML standard, things should be in XML tags.  If you want to do
PKCS#7 signatures that make some use of XML packaging, you can.  Just don't
pretend they are XML signatures.

>      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.

### A PKCS#7 blob is an ASN.1/DER signature.  It is never a MIME signature.
In S/MIME, it is an ASN.1/DER signature of a MIME object packaged with
MIME.
You could certainly design a way to use PKCS#7 blobs to get an ASN.1/DER
signature of arbitrary stuff, including XML, packaged in XML.

bob

### Donald

Received on Tuesday, 20 April 1999 16:53:14 UTC