OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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