- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Mon, 27 Mar 2000 02:11:25 -0500 (EST)
- To: Ed Simon <ed.simon@entrust.com>
- cc: w3c-ietf-xmldsig@w3.org, Joseph Reagle <reagle@w3.org>
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0226.html >In summary, by making support for minimal-c14n canonicalization >of the SignedInfo element, the spec really makes things >painful for XML Signature toolkit implementors. If there >is someone out there who has actually implemented code that >can support minimal-c14n canonicalization of the SignedInfo >element, I'd like to hear about it. 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. The two problems that exist for that route are security and fragments, and things seem to be falling out as follows (IMHO): Security: You can't do enveloped or partial documents signatures really without operating in the XML as XML paradigm, if that frightens you from a security point of view, use detached. (Or see Phil's comment: http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0246.html ) Fragments: We need some way of serializing the results of DOM/XPath node lists (abstractions). Canonical XML only processes full documents, what to do? I liked Gregor's proposal: http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/0156.html These approaches work well for XML as a refereant being signed, I'm not sure if it's a compelling enough case to make the WG get off the fence (move to the XML as XML or XML as character sequence) yet with respect to SignedInfo, but given the comments from Gregor, Kent, and Ed (based on implementation experience) I'm certainly leaning that way.
Received on Monday, 27 March 2000 02:11:27 UTC