Re: IETF Signed-XML BOF Notes

Phil,

From:  "Phillip hallam-Baker" <pbaker@verisign.com>
Message-ID:  <003301be7f93$177d24b0$42060a0a@pbaker-pc2.verisign.com>
To:  <dee3@us.ibm.com>, "Signed-XML Workshop" <w3c-xml-sig-ws@w3.org>
Cc:  <xml-dsig@GlobeSet.com>
Date:  Mon, 5 Apr 1999 11:34:45 -0700

>>### The main thing with which there was no disent was that
>>cannonicalization is necessary, for the reasons cited in the
>>minutes.  There was criticism by ekr (Eric Riscola) that for
>>digital signing the recursive nature of the DOM HASH proposal
>>is not needed (as it would be for efficient tree comparison)
>>and is slower than just feeding a similarly defined ordered
>>byte stream for the entire structure to be signed into a
>>single hash function.
>
>There may be agreement that IN SOME APPLICATIONS
>the ABILITY TO canonicalize is a requirement.
>
>There is intransigent objection to any requirement that
>EVERY signed document be canonicalized.

Yes, the meeting and the minutes and Joesph Reagle's condensation of
them and my partial re-expansion were all a bit incomplete.

The IETF Draft Charter proposes two documents because it really
proposed to standardize two very different things:

(1) how to sign things using an XML encoding regardless of what is
being signed.  IE, something that is, to the first approximation, an
XML verison of PKCS#7.  This certainly includes singing a unmodified
pile of bits (well, really an octet stream) even if that pile happens,
on closer inspection to by XML.

(2) how to sign XML regardless of the means of siging.  For most
cases, this would involve some canonicalization.

The case of 1 & 2 togethjer exists of course, an XML encoded signature
of XML, and is actually a fairly important case, but isn't the only
one.  (And, of course, non-XML signing of non-XML exists but isn't in
scope.)

>I know that various people have said 'of course that
>will be an option', however I now see the requirement
>that the functionality be available turning into a requirement
>the functionality be employed.
>
>The reason is that I just do not believe that semantically
>neutral transformations are possible in practice. However
>good the spec looked I would distrust the implementations. 

The canonicalization rules DEFINE the semantic content for that
particular canonicalization.  Whatever is trashed by the
canonicalization, for example the information as to whethet the
original was in UTF-7, UTF-8, or UTF-16, is by definition
insignificant or you should not have chosen that canonicalizer.

>Moreover I don't believe that there is sufficient knowledge
>to construct a formal proof of correctness that demonstrates
>that an XML cannonicalisation process is semantically
>neutral. XML is not defined using a formal method which
>is one obstacle, even if it were however XML is not a
>syntax but a meta-syntax, the only proofs I have seen in
>that domain which were convincing involved category theory.

Since I do not believe there can be a unviersal statement for all
systems of what the true semantic content of some XML is, I think you
are asking the wrong question.  For any particular specification of
what the semantic content is and a particular canonicalizer, I believe
you could often prove or disprove that the semantic content is
preserved by that canonicalizer.

>The requirement that electronic commerce systems
>be formally verified is quite realistic. Proofs relating to 
>substantially larger systems exist. I find the idea that
>digital signatures will be reliably used in any environment
>which does not preserve the integrity of messages 
>considerably less plausible. That does not mean that I
>don't expect people to try.

You are just begging the question.  What is "the integrity of
messages"?  If you want "the integirty of octet streams" that's
certainly trivial to get.  But I think the position that the integrity
of an XML "message" is not changed if it is mapped in an algorithm
one-to-one reversible way between UTF-8 and UTF-16, for example, is
quite reasonable.

And there are cases in protocols where a portion of an XML document is
moved between documents and the like where, for example, the namespace
prefix used to denote a particular namespace was changed and it is
desireable to canonicalize this aspect as well as character encoding,
etc.

>I want to sign the bits on the wire. If people want to use
>broken networks, the spec should provide them with the
>tools. I do not however agree that those of us with networks
>which do not mangle messages should be _required_ to
>perform any transformation which is not fully specified
>using formal methods and proven to be semantically neutral
>using formal methods.

If you want to use only feature (1) from above, an XML encoded
signature of a pile of bits, feel free to do so.

>I would like to see a mechanism for signing the bits on the 
>wire as a phase 1 deliverable and defer canonicalisation
>until phase 2, I think that the task will prove somewhat more 
>complex than some anticipate.

I can't conceive of any reason why these tasks can not proceed in
parallel.  Both are needed now.  I think we should try to reduce the
cases, like IOTP v1.0, where protocols have to adopt their own XML
DSIG procedures because accepted standard XML encoded signatures and
XML canonicalizations are not in place.

>        Phill

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   dee3@torque.pothole.com
 65 Shindegan Hill Rd, RR#1  +1 914-784-7913(w)     dee3@us.ibm.com
 Carmel, NY 10512 USA

Received on Tuesday, 6 April 1999 10:24:14 UTC