RE: [dss] Namespace inheritance, other approach

["Edward Shallow" <ed.shallow@rogers.com>]

Interesting thoughts.

I'll try a few things but I have been discouraged so far with the
complexities hoisted on the implemtors. XPath attribute in SignaturePtr is
also in the problem area list.

Wondering if the cure is worth the trouble that simple encoding solves. We
do have precedence if we did decide on an encoding approach.

Ed

-----Original Message-----
From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] 
Sent: May 5, 2005 8:54 AM
To: Trevor Perrin
Cc: dss@lists.oasis-open.org
Subject: Re: [dss] Namespace inheritance, other approach

Trevor,
If my memory does not cheat me, I think that there is a situation that is
the one that raised the encoding issue: when the client wants to send a
whole XML document, not a subtree...that document would have the initial
<?xml....>, the area of declaration/definition and finally the root
node...but the parser would complain if it finds a <?xml ....?> as child of
an element... A different issue is whether the protocol should also cover
the requirement of a client sending a complete xml document starting in its
initial PI. ....

Regards
Juan Carlos
Trevor Perrin wrote:

>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php