Re: [xml-dist-app] <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.

As an aside, you probably already saw this David, but I honestly don't 
remember how widely I distributed it, in October I started a document 
identifying some of the issues related to refactoring xsec into 
Infoset/Schema.

http://www.w3.org/2002/10/xsec-refactoring.html
    1. Introduction
    2. Infoset
         1. Is XDSIG based on XML Infoset?
         2. Can XDSIG they work with Infoset applications?
         3. Can XENC applications encrypt Infoset Items?
    3. Schema
         1. Can XDSIG work with XML Schema applications?
         2. How does XENC affect an instance's validity?
    4. XML 1.1 and Namespaces 1.1


>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.

As Rich mentioned, for signing purposes there will have to be a serialized 
form for the cryptographic operation of the signature or encryption. The 
trick is using a representative form that is portable -- both with respect 
to being removed, and being reinserted into a new context.

>* 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.

Yes, this is certainly possible with xmldsig, one could write an XSLT as its 
specification most likely.

>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.

I'm a little confused and concerned about the points on different 
processors, "there will have to be 2 different XML parsers." If they are 
XML 1.0 processors then they should interoperate. A SOAP instance/processor 
can be a profile of a XML instance/processor but then where is this 
assumption that a SOAP processor is going to have to process generic XML 
coming from? (And if that's the case it will have to be a XML and xmlsec 
processor as well, right?)

>The decision by XML Encryption to work only on serializations

Again, from a cryptographic point of view encryption can only work with a 
serialization regardless. The question is a serialization of what?

>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.)

I don't understand this, could you provide an explicit scenario?

Received on Tuesday, 7 January 2003 13:14:27 UTC