[www-ws-arch] <none>

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