Re: [dss] Namespace inheritance, other approach

[Trevor Perrin <trevp@trevp.net>]

Edward Shallow wrote:
> Interesting thoughts.
> 
> I'll try a few things but I have been discouraged so far with the
> complexities hoisted on the implemtors.

I hope you keep track of what's difficult and let us know.  I too wish 
things were simpler, but every feature has its advocates.  At least a 
lot of complexity has been pushed off to the Options, where profiles can 
pick and choose.


> XPath attribute in SignaturePtr is also in the problem area list.

We could do away with that, if the client was required to process the 
Enveloped Signature Transform locally.  Perhaps we should make 
SignaturePtr support into an option somehow.


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

If we encode anything that might clash with the dss namespace, do we 
also have to encode the SignatureObject, KeySelector, Properties, 
Transforms, etc?7


Trevor


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