[xcbf] [Fwd: Re: New specs: Exclusive C14N REC; and XPath Filter2 CR]

[Phil Griffin <phil.griffin@asn-1.com>]

Interesting comments on security, namespaces
and multiple canonicalizations below. Thankfully
not in our problem set.

Phil

-------- Original Message --------
Subject: Re: New specs: Exclusive C14N REC; and XPath Filter2 CR
Resent-Date: Wed, 7 Aug 2002 00:03:36 -0400 (EDT)
Resent-From: w3c-ietf-xmldsig@w3.org
Date: Wed, 7 Aug 2002 00:03:33 -0400 (EDT)
From: Donald Eastlake 3rd <dee3@torque.pothole.com>
To: Rich Salz <rsalz@datapower.com>
CC: "XML Signature (W3C/IETF)" <w3c-ietf-xmldsig@w3.org>


Canonicalization can be hard even when things are simple, as in 
LISP or
ASN.1 encoding. With XML, it is very hard and different 
applications can
easily need different canonicalizations.

It may be that the current W3C XML Canonicalizations have not bee 
fully
adapted to Schema and to the sort of application they are talking 
about,
where messages are shredded to their data elements, stored in a
database, and those data element are later retrieved and used to
reconsitute messages. I've writte code that does just that sort 
of thing
for ASN.1 SET messages so I know what they are talking about.

However, the reasons from not canonicalization namespaces 
prefixes are
explained in Canonical XML. If you are talking about an application
which will NEVER encouter those problems, then it would be nicer to
canonicalize prefixes. But a growing number of W3C Recommendations
encourage absolute prefix names inside attribute and element 
values and
the use of such Recommmendations in messages signed with 
canonicalized
prefixes will be insecure. (Actually, it can be made secure for a
restricted subset of messages that use only such Recommendations 
as are
explicitly understood by and provided for in the Canonicalization but
will be insecure as soon as a new such Recommendation comes along or
the application itself makes use of prefixes embedded in data 
that the
Canonicalization does not explicitly understand.)

There point about "just an attribute node" might be due a warning but
there is no reason people should not be able to sign so as to omit
namespace declarations if they want. There are lots of ways you 
can do
something where you either shoot yourself in the foot or get the 
exact
(perahps unusual) effect you want, depending on your application.

Whether the things they have to say about the W3C 
Canonicalizations are
"limitations" or "necessities" depends on your application.

Donald
======================================================================
  Donald E. Eastlake 3rd 
dee3@torque.pothole.com
  155 Beaver Street              +1-508-634-2066(h) 
+1-508-851-8280(w)
  Milford, MA 01757 USA 
Donald.Eastlake@motorola.com

On Tue, 6 Aug 2002, Rich Salz wrote:

 > Date: Tue, 6 Aug 2002 21:26:14 -0400 (EDT)
 > From: Rich Salz <rsalz@datapower.com>
 > To: Joseph Reagle <reagle@w3.org>
 > Cc: "XML Signature (W3C/IETF)" <w3c-ietf-xmldsig@w3.org>
 > Subject: Re: New specs: Exclusive C14N REC; and XPath Filter2 CR
 > Resent-Date: Tue, 6 Aug 2002 21:26:01 -0400 (EDT)
 > Resent-From: w3c-ietf-xmldsig@w3.org
 >
 >
 > Does anyone here have comments on the UDDI C14N spec?
 > 
http://www.uddi.org/pubs/SchemaCentricCanonicalization-20020710.htm
 > in particular, section 1.1 comments on the limitations of the 
current
 > standards.
 > 	/r$
 >
 >