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

John,

I think that the intent of the WG was two faces:
- Authenticating Web resources making use of XML
- Authenticating XML contents

The first aspect leads to the signature syntax proposal while the second one
may consider other aspects such as XML canonicalization.

Sincerely,

Richard D. Brown

> -----Original Message-----
> From: w3c-xml-sig-ws-request@w3.org
> [mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of John Boyer
> Sent: Tuesday, April 20, 1999 6:32 PM
> To: dee3@us.ibm.com
> Cc: Dsig group
> Subject: 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:58:10 UTC