RE: IETF Signed-XML BOF Notes

Do I need formal methods to assess the neutrality of a canonicalizer? This
is probably true if I want to define a "general purpose" canonicalizer for a
given syntax (i.e. DER for ASN1). However, in most circumstances, people
have considered canonicalization in the confines of well-defined business
frameworks. There, it is very simple to ensure neutrality of the
canonicalizer. This because, from a business standpoint, XML is secondary.
It is just a syntax (or to be more precise a ML that could be used to define
such a syntax) - Adopting some XML DTD instead of ASN1 is just a matter of
convenience. The framework defines the semantics and dictate to the rules.
In such circumstances, a canonicalizer has many benefits and among others
relieves the business logic from the requirement of maintaining a copy of
the bitstream to ensure verifiability of the signature.

The previous comment does not preclude the definition of "general purpose"
canonicalizers such as DOM-HASH and X-HASH (respectively proposed by IBM and
GlobeSet). It shall be a matter of the different business frameworks to
decide if these algorithms are sufficient and semantically neutral from
their respective standpoint. In fact, they have been proven satisfactory in
several circumstances.

But you are correct, canonicalization shall not be a REQUIREMENT - It shall
be possible to sign at the bitstream level. (Though one may argue that the
simple fact to define what should be signed is a matter of
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 Phillip
> hallam-Baker
> Sent: Monday, April 05, 1999 1:35 PM
> To: dee3@us.ibm.com; Signed-XML Workshop
> Cc: xml-dsig@GlobeSet.com
> Subject: Re: IETF Signed-XML BOF Notes
>
>
>
> >### 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
>         Phill
>

Received on Monday, 5 April 1999 20:04:11 UTC