- From: Ed Simon <ed.simon@entrust.com>
- Date: Fri, 7 Apr 2000 15:24:46 -0400
- To: "'w3c-xml-core-wg@w3.org'" <w3c-xml-core-wg@w3.org>, "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
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:25:19 UTC