[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]