Avoid ASN.1 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 05:32:53 PM

To:   Donald Eastlake/Hawthorne/IBM, w3c-xml-sig-ws@w3.org
cc:
Subject:  Re: XML versus ASN.1/DER blob





dee3@us.ibm.com wrote:

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

If you want to do anything interesting with signed data, you already have
to
include ASN.1 and DER. RSA PKCS #1 signatures have imbedded ASN.1 data. You
also need modular exponenatiation code, which swamps DER in size and
complexity.

@@@ First of all, you seem to be assuming asymetric keying and RSA, which
just isn't always true.  But even given that, your logic leads to the
following train: the inner signature is in PKCS#1 which uses
ASN.1 so as long as we are using it there for structured data, we might as
well use PKCS#7 for the manifest so as long as we have full ASN.1
capabilities for strucutred data, we might as well use it for all stuctured
data, like everthing in the web.  What's wrong with this picture?  Two
things: the intial premises that PKCS#1 involves much ASN.1 processing is
not generally true; and the fact that using ASN.1 for anything represents
a huge cost in opacity, inflexibility, lack of extensibility, etc. so you
*really* want to avoid ASN.1 becoming contagious and spreading.

@@@ Why do I say PKCS#1 doesn't involve much ASN.1 processing?  Becasue,
for many applications, all you need do is insert a baroque constant on
signing and check for it on verification.  For example, for an RSA/MD5
siganture, you just need to insert or check for hex
     3020300c06082a864886f70d020505000410

@@@ For more variable or complex cases, you need to do a little more.
Furthermore, interfaces to RSAREF and the like are happy to work at the
PKCS#1 level.  It's ASN.1'ness is unfortunate but completely hidden within
it and does not couple to any ASN.1 requirement outside the PKCS#1
formatted inner signatures.  In otherwords, PKCS#1 is not contagious.

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

I presumed there would be something like this. We then need to define that
the
DOM methodes look like for things like PKCS #7 objects.

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

So our RSA signatures should be encrypted blobs of XML, and not PKCS #1
blobs
to be real XML signatures, even though every security token in the world
would
barf on that data?

@@@ It might be nice if the encrypted blobs of PKCS#1 were XML but they are
not human observable, due to the encryption, so the readability of XML is
lost in any case.  I would certainly have never chosen to use ASN.1 inside
the PKCS#1 encrypted blob but nobody asked me and it is such a simple case
that it imposes no requirment for general ASN.1 processing and is not
contagious to the application since all the "ASN.1" processing is internal
to the inner signing and verification algorithms.

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

We're working on Signed XML. An XML digital signature, as you are trying to
define it appears to me to be and interesting academic exersize, but does
not
get us any closer to deploying and using signed XML documents -- and
certainly
does not meet any goal of getting something useful in the next 18 months!

@@@ When people see it to their advantage, they sure can read a lot into
the
workshop title...  The document point of view is not the only one.  Why
should IOTP protocol messages or AADS financial messages, if they don't
have any
certificates and might easily be using shared secret keys, be forced to use
ASN.1/DER encoded PKCS#7 instead of a clean XML Manifest?

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

So I submit that if you are trying to build a new *signature* standard,
that
work should be done under some other working group.

@@@ I'm willing to go along with the current PKCS#1 encoding for public key
signatures.  You're the one trying to get general XML/RFD assertiongs
crunched
into ASN.1/DER.

The best analogy I can think of to what you are suggesting is if someone
decided that we need an XML Image format, because JPEG is to hard. The new
format would build on JPEG, and use DCT's, have all sorts of low level
binary
data. it will have some interesting things like image size and resolution
that
the XML application can use.

@@@ I don't think it is a very good analogy.  I supose it would be nice
for JPEG's to have their header fields in XML.  But I agree with you that
it would not be worth the change.  However, the situation would be
different if people customized their JPEGs by putting in their
favorite image compression and rendering functions and even more different
if JPEGs included arbitrary attributes in XML/RDF and further different if
instead of being handed lots of existing JPEGs you are talking about
creating
and parsing JPEGs under new circumstances.  Under those conditions
I certainly would say that a recoding of JPEG in XML would be the only
reasonable way to go.

Again an interesting exersize, but not someone would actually use in a
commercial application.

bob

@@@ Donald

Received on Thursday, 22 April 1999 08:05:58 UTC