- From: David Orchard <dorchard@bea.com>
- Date: Thu, 2 Jan 2003 14:53:06 -0800
- To: <xml-dist-app@w3.org>
- Cc: <www-ws-arch@w3.org>
Noah and I have been noodling on some architectural words around XMLP and Signature/Encryption interactions that we'd like the WS-CG to look at. Here's the latest that we have. Your comments appreciated. I've cc'ed the ws-arch group because there are some discussions there about supporting profiles of XML. Noah, I've done a bit of rewording on the "processor" issue. Dear WS-CG, One of the key uses for XML Signatures appears to be for authenticating the contents of SOAP messages. Nontheless, your respsective recommendations have evolved on parallel tracks, with DSig and Encryption having been out for some time, and SOAP seemingly well on the way to Recommendation now. The purpose of this note is to set out some areas in which we believe that additional coordination of our work might be beneficial. Signature and Canonicalization-Related Concerns =============================================== The DSIG-related areas we have identified break down into two major categories: * Infoset vs. XPath Data Model: XML Canonicalization [1] and Exclusive XML [2] Canonicalization both adopt a data model based on XPath. SOAP message envelopes are defined as XML Infosets [3]. Thus, the existing C14N drafts do not apply directly to SOAP messages. The XMLP workgroup believes that this disconnect should be resolved as a relatively high priority undertaking. We are unclear at this time whether the problems are essentially limited to the way equivalent concepts are presented, or whether there might be edge cases (non-significant whitespace, perhaps?) in which the mappings from Infoset to XPath and back are unclear. In any case, we believe that the normative recommendations from W3C should use consistent models, and should work together directly. We note that XML Schema, to which we are closely tied, also operates on Infosets. Note in considering the above that SOAP has pluggable bindings to network protocols. While the HTTP binding uses XML 1.0 syntax (with end tags, etc.), other bindings might make other choices. For example, an "in memory" connection might be effected by merely passing a DOM root from sender to receiver. In principle, a SOAP message can be gatewayed through an intermediary, using one form on the first hop and another on the second. We believe it's important to allow signing of the logical message, as opposed to its encoded serialization as characters, so that the signature can remain valid over the several hops and re-encodings. We believe that both your XPath and our Infoset approaches allow this, but it's something that we should not "break" as we move forward. * SOAP-specific canonicalization: SOAP permits certain constructions to be treated as equivalent when processing a message, and allows for intermediaries to substitute equivalent representations when relaying a message. For example, the values "1" and "true" are considered equivalent for certain attributes, and the omission of certain attributes is defined as equivalent to providing them with some specific value (NOTE: neither of these equivalences is defined in terms of XML schema validation; validation is never required in the processing of a SOAP message. The equivalences are expressed directly in the SOAP recommendation.) Accordingly, the XMLP workgroup believes that there may be use for an additional c14n recommendation, which will produce the same output for any equivalent SOAP forms. We believe that signatures over such c14ns will be useful to those applications that choose to tolerate such message manipulations by intermediaries. Of course, the natural course for us would be for that c14n to be Infoset-based. >>>> Discussion about realities of XML/SOAP/DSig stacks (Dave O.: the following is from your note. I'm unclear on the point you raise about processors. None of us says anything about what processor to use, I think. We merely define c14ns and signatures. What is a "Digital Signature Compliant Processor"? I don't see why there's an issue here. If someone builds a SOAP message, then that message won't have entities, internal subsets, etc. If they hand it to a processor that would have allowed those, what's the problem? I would also be careful in framing this: one of the key aspects of SOAP is in the 2nd para in the first bullet above: we're not signing serializations, we're signing the abstract message. Accordingaly, I'm not quite sure we should be in the business of discussing this or that "processor". The c14n is merely a mathematical function that takes in one Infoset (Data model) and produces another as output.) <QuoteofDavidNote> 2. The subset of XML 1.0 used by SOAP is not the same subset as that used by Digital signature - particularly DTDs, the internal subset and entities. This means that an Digital signature compliant processor might use a different XML Processor than that used by a SOAP processor. For example, a SOAP processor will not include support for DTDs, whereas this may be required for digital signature verification, which has a dsig dtd. Another example, from the DSig spec, is the use of entities <!-- <XPath xmlns:dsig="&dsig;"> -->. DSig and XEnc should use the same subset/profile of XML that SOAP 1.2 uses. </QuoteofDavidNote> Noah: My concern is that if one receives a message with signatures then there will have to be 2 different XML parsers. Imagine I build a "signature header verifying intermediary". It's got to make sure the header is a valid DSIG message. And it also has to make sure it's a soap message. I wouldn't want the software to have to deal with 2 different xml stacks. My proposed rewording is: The subset of XML 1.0 used by SOAP is not the same subset as that used by Digital signature - particularly DTDs, the internal subset and entities. This means that software that performs c14n will require a different understanding of XML than the SOAP processor. In reality, a typical realization of this will be through two different XML parsers. For example, a SOAP processor will not include support for DTDs, whereas this may be required for digital signature verification, which has a dsig dtd. Another example, from the DSig spec, is the use of entities <!-- <XPath xmlns:dsig="&dsig;"> -->. DSig and XEnc should use the same subset/profile of XML that SOAP 1.2 uses. <<<< EOD. XML Encryption-Related Concerns =============================== XMLP comments to XMLE at [4] spoke of Infoset fixup (item #3). This did lead to the decision to register an Xenc media-type, but did not ultimate resolve the relationship between schema validation of xenc elements and the decrypted elements. During the summer, we had a follow on discussion, which generated [5]. This clearly talks about the decision to base Encryption upon xml syntax rather than infoset (item #6). As discussed above, SOAP messages are fundamentally infosets, which may or may not be serialized as XML 1.0 for transmission. The decision by XML Encryption to work only on serializations thus limits its potential applicability to use in conjunction with particular SOAP protocol bindings (e.g. HTTP), which seems unfortunate. Furthermore, one presumably wants the ability to selectively encrypt selected structures such as header blocks. These are unlikely to be conveniently managed separately at the level of a transport binding (though certainly with care it is possible to create implementations in which the bindings and the main SOAP implementations conspire to "do the right thing.") Furthermore, there seems currently to be no architecturally clean way to encrypt a SOAP header that is traversing multiple hops (because the only place SOAP uses the serialized form is hop-to-hop.) So, here too, we think it would be important to re-open the discussion of Insfosets vs. serializations (vs. XPath models). XML Subsets =========== The TAG has also started discussion of the issue of XML Profile and subsetting [6]. There has been ongoing conversation about creating a profile of XML specifications that includes the XML Infoset, as well as a subset of XML 1.0. SOAP has been one of the motivations for such discussions. Obviously, DSIG and Encryption should be effective when used with the subset of XML employed by SOAP. If the TAG discussions lead to a decision to more broadly standardize a subset, then one may wish to consider the applicability of DSIG and Encryption to that more widely adopted subset. Cheers, Dave and Noah [1] http://www.w3.org/TR/xml-c14n [2] http://www.w3.org/TR/xml-exc-c14n/ [3] http://www.w3.org/TR/2002/CR-soap12-part1-20021219/#soapenv [4] http://lists.w3.org/Archives/Public/xml-encryption/2002Feb/0013.html [5] http://lists.w3.org/Archives/Public/xml-encryption/2001Jul/0021.html [6] http://www.w3.org/2001/tag/ilist#xmlProfiles-29
Received on Thursday, 2 January 2003 17:56:31 UTC