Signed XML or XML Signatures Re: XML versus ASN.1/DER blob

Hi Donald,

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


I don't think there is a need for pretending.  The workshop we just did was
on "Signed XML".  We're trying to figure out how to sign XML.  This is a
logically distinct concept from how we choose to express the signature.

Consider the consequences of requiring that signed XML should create XML
signatures.  The W3C needs to create a reference implementation of the
signed XML spec.  If that implementation includes the cryptographic layer,
then the W3C will have to change its name to the USCWC (United States and
Canada Web Committee).

Hence, we are talking about a spec that defines an interface to external
cryptographic modules.  Are we simply going to exchange blocks of XML with
those modules?  If so, this means that all existing signature technologies
and all new ones going forward would need to embed XML read and write
modules.  This might just work in a field as young and cutting edge as
cryptography, but we cannot generally assume that other technologies will
switch their formats to XML to satisfy only one group of possible users.  A
humorous analogy would be to claim to have a fix for "the" Y2K bug, but that
the fix requires everyone to change their file formats to XML.  In this
example the file format is the problem in the first place (the humourous
part), but unless we want to be stuck with writing an XML parser in COBOL,
the solution just isn't appropriate (the analogy part).  The same is true
for the low-level operation of existing cryptographic engines.  It may not
be appropriate, desirable or feasible to wire XML read and write
capabilities into every cryptographic engine.  Also, even if the
manufacturer views signing XML as high priority, that doesn't mean they have
to express their signatures in XML in order to sign XML.

So, as I said, the XML awareness requirement might just work in this case,
but for the sake of covering all cases... Recall that we don't want the W3C
to build the crypto layer, and let's suppose we don't want to require XML
awareness on the crypto modules.  Well, *somebody* has to translate from XML
to the crypto modules' blob formats.  Since the crypto modules won't do it
(else see above), that means we have to specify the translation in the
signed XML spec.  This of course means that we need to know the binary
formats with which we intend to interchange data.  In particular, suppose
some unforeseen technology comes out that simply requires additional data
for which we didn't define tags.  New signed XML spec, new DTD, worldwide
software upgrade, high cost.

Why do it this way when we already have an example of existing technology
whose viability depends on non-readability?

Why do it this way when we can write a spec now that does not have to change
with new technologies because it does not try to stick its tags where they
don't belong.

We should leave signing details to the creators of signature technology.
Let them create their own formats, cryptographic or otherwise, and let them
convince the market about the efficacy of the solution in various
circumstances.  Let us focus on creating a paradigm that makes it simple to
integrate all technologies without digging too deep.  XML itself doesn't
have to solve the world's security problems.  Naturally, our spec should not
introduce new security problems during integration, but the integrated
modules themselves should be responsible for providing the real security.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

Received on Tuesday, 20 April 1999 19:28:24 UTC