RE: XML Signature use of Canonical XML

Hi all,

Is there some reason why the serialization algorithm described in the latest
XPath Transform spec cannot be used to

1) Serialize SignedInfo without W3C c14n.  The serializer is essentially
like minimal c14n except that it takes into account the limitations of some
XML toolkits w.r.t. attribute order, assuming an XML processor has been
used, etc.

2) Describe how to serialize fragments of XML (if you have a fragment, where
did you get it from? And if you got it from somewhere, isn't it always
possible to think about it in terms of a parse tree (or rather a parse
forest, aka a node-set)?).

John Boyer
Software Development Manager
PureEdge Solutions, Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Ed Simon
Sent: Friday, April 07, 2000 12:25 PM
To: 'w3c-xml-core-wg@w3.org'; 'w3c-ietf-xmldsig@w3.org'
Subject: RE: XML Signature use of Canonical XML


Thanks Joseph for the summary,

I would like to make a clarification regarding the paragraph:

  However, during last call (which ended yesterday) there's been substantive
  call for removing minimal all together based on implementation experience
  [1], though the security concerns associated with XML Canonical are still
  raised [2]. I expressed my view that "We've been trying to play agnostic
  between XML as XML, and XML as a character sequence, but I believe the
spec
  should follow the implementations, which seem to be adopting the XML
toolkit
  (XML as XML) route." [3] Consequently, the advancement of Canonical XML is
  very important to us even though we still have our own difficult
  consensus/balancing act between XML-as-XML and something some security
folks
  are comfortable with.

I do not object to minimal canonicalization for the resources being
digested,
only for the <SignedInfo> element.  In my view, and I think Kent Tamura's
view
(Kent, please let us know if I am misrepresenting you), it is very difficult
to support the minimal canonicalization of the <SignedInfo> element for the
reasons I outlined in
"http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0226.html".

In response to that note, Phill has proposed
that XML parsers contain an interface to support minimal canonicalization.
From
"http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0246.html":

  Briefly, one needs to code the XML parser with separate FSR
  and parse tree building modules (a good idea in any case).
  The initial FSR module needs to have a switch to divert code
  through a hash algorithm when required. The switch needs to be
  activated by the signature verifier at the appropriate point.

  It is quite easy to write an integrated parsing / signature
  verification module in C on this structure without the use of
  any global variables. XML was designed to be very easy to
  write parse tools for.

If XML parsers were coded that way, miminal canonicalization could be
supported for the <SignedInfo> element.  However, to my knowledge such
functionality is NOT part of most parsers meaning some recoding would
be necessary by either the parser maker or an XML Signature implementor
who has access to the source code.  I would like to hear others' opinions
on this, especially those who have written XML parsers.

We also need to address the concerns expressed (eg.
"http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0281.html")

of whether "Canonical XML" will stand up to a security analysis.
To fully understand the Canonical XML spec (as short as it is), does require
that one be very familiar with the XML spec, character models, and
namespaces.  I expect these topics will generally be new areas to
the cryptographic community and we need to consider that.  Generally, I
think that XML and XML applications (not just XML Signatures) open up
a whole new set of challenges to the security community (see
"http://www.xml.com/pub/2000/02/xtech/megginson.html" for a similar
view).  To paraphrase a 60s song, what the world needs now is people
who are good at both XML and security.

Regards, Ed
-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Thursday, April 06, 2000 6:57 PM
To: IETF/W3C XML-DSig WG
Subject: XML Signature use of Canonical XML (Was: Minutes for XML Core
WG telcon of 2000 Apr 5)


The Core WG has been trying to decide what to do with the Canonical XML spec
as they have many deliverables on their plate and presently we are the only
consumer (though I believe we are only the first, there will be many other
applications with requirements similar to our own.) I hope they will produce
another draft soon, and there is sometimes talk of them handing the spec off
to us, but nothing conlusive so far. However, I did try to update them on my
view of this WG's view of that spec. Any thoughts are appreciated.

Forwarded Text ----
 Date: Thu, 06 Apr 2000 18:50:56 -0400
 To: w3c-xml-core-wg@w3.org
 From: "Joseph M. Reagle Jr." <reagle@w3.org>
 Subject: XML Signature use of Canonical XML (Was: Minutes for XML Core WG
telcon of 2000 Apr 5)

 [Note: I had an agreement with the Core's predessor (Syntax) for
cross-posting any c14n relevent information to the public list. I'm not
cc'ing this, but will make this information available in some way -- I'd
like to forward it if I could have a similar understanding with the Core WG.
Also, this is only my summary of the WG's position and likely direction, but
not a formal/endorsed statement.]

 >...

 The XML Signature WG's approach on the c14n issue has been mixed because of
a difference between those who planned to approach the processing of XML in
the Infoset/DOM manner (that requires node serialiazation and
canonicalization), and those that wanted to process it merely as characters
(that required some line feed and CR canonicalization at most.) Our
compromise was to require "minimal" and strongly recommend XML Canonical.

 However, during last call (which ended yesterday) there's been substantive
call for removing minimal all together based on implementation experience
[1], though the security concerns associated with XML Canonical are still
raised [2]. I expressed my view that "We've been trying to play agnostic
between XML as XML, and XML as a character sequence, but I believe the spec
should follow the implementations, which seem to be adopting the XML toolkit
(XML as XML) route." [3] Consequently, the advancement of Canonical XML is
very important to us even though we still have our own difficult
consensus/balancing act between XML-as-XML and something some security folks
are comfortable with.

 I'm looking forward to the next draft of the spec that resolves some of the
other comments sent during last call [4] (though I know the Core WG is very
busy). Also, the Signature WG identified in our comments  [5] that we're
going to have to figure out some way canonicalize XML fragments (i.e.
serialized returns of XPath), though I'm beginning to wonder if this would
be a useful feature to include in the Canonical XML spec itself? Gregor
Karlinger has suggested that the fragments be wrapped in a declaration and a
specific element from the Signature element type in our case, though that
could be generalized. [6]

 [1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0214.html
 [2]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0246.html
 [3]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0257.html
 [4]
http://lists.w3.org/Archives/Public/www-xml-canonicalization-comments/2000Ma
r
/
 [5]
http://lists.w3.org/Archives/Public/www-xml-canonicalization-comments/2000Fe
b
/0004.html
 [6]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0156.html

End Forwarded Text ----

_________________________________________________________
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Friday, 7 April 2000 15:53:07 UTC