Namespace inheritance, other approach

[Trevor Perrin <trevp@trevp.net>]

I'm wondering if the <XMLData> namespace-inheritance issue is less of a 
problem than we thought, and can be handled more elegantly than with 
opaque encodings.

The problem is that dss namespace prefixes could confuse the 
interpretation of documents, keys, or signatures (<XMLData>, 
<KeySelector>, or <SignatureObject> respectively), since these things 
are all XML structures that might be ripped out of their original 
context and plopped in DSS messages.

Problems can occur due to:
  1) XML structure uses namespace prefixes not defined by DSS
  2) XML structure uses namespace prefixes defined differently by DSS
  3) processing of XML structure depends on namespace prefixes "in 
context" (e.g. XML canonicalization of an input document)

1) is resolved by canonicalizing the XML structure, so it defines the 
prefixes it uses.

2) is resolved by choosing prefixes for dss that don't collide (i.e., if 
your document uses xmnls:dss, then use something else for DSS itself).

3) is resolved by specifying slightly different processing rules to 
exclude DSS-inherited context.  For example, in Signature Basic 
Processing, the Server should use Exclusive Canonicalization instead of 
Normal Canonicalization.

The reason the core spec mandates Normal Canonicalization is because 
XML-DSIG mandates Normal Canonicalization, for converting XML to 
octet-strings during Reference processing.  But applying Exclusive 
Canonicalization on the Input Document, as it appears within the DSS 
message, is actually the *same thing* as applying Normal 
Canonicalization on the Input Document itself, I think.  Because 
Exclusive Canonicalization is the same as Normal, just omitting 
irrelevant namespaces.

I haven't thought this through.  It would be helpful if other people 
with more XML experience could spend time on this.  There's several 
other places that process the Input Documents as XML that need 
consideration (for example, the <SignaturePlacement> option for 
signature insertion).  But I'm cautiously hopeful we can make things 
work with relatively minor spec changes.


Trevor