Re: [dss] XMLData problem in Core "Opaqueness

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Ed,

I tend to agree with you in that

1. We may add the "encoding" attribute  to
<dss:XMLData> for dealing with
encoded XML... the escaped one is the obvious,
can you think in others?

2. I also agree in that if one wants to get rid
of all this, he always could send the document
base-64 encoded...

I am not either very skillful with DOM.. I am
more familiar with JDOM... which I do not know if
it has this kind of facilities as the importNode()
function....

Regards

Juan Carlos.
Edward Shallow wrote:

>A quick update ...
> 
>What I am doing right now in support of both raw XML content in the XMLData
>element, as well as encoded content in the same element is as follows:
> 
>When processing the inbound request, when I arrive at the XMLData node I
>check the child node count. If that count is more than 1, then I assume it
>is raw XML and serialize the entire sub-tree. If it is 1, I can assume that
>it is encoded since there are no descendent nodes, and I then GetContent.
>Presently the only encoding that will work transparently is &lt; and &gt;
>escaping. It would be up to the implementation to ensure that the content
>before hashing is unescaped (i.e. back to < and >). Most librairies should
>do this, Gnome's libxml2 does. If not, it would be the implementation's
>responsibility. If the implementation chooses not to support this, then the
>XML directive line and PI lines would not likely be supportable. These
>restrictions would have to be documented.
> 
>The only other encoding that could be supported right now without structural
>change to the core schema is base64 by using the Base64Data choice of
>Document for XMLDSIG as well as CMS/PKCS7.
> 
>We could also consider simply adding an attribute to XMLData called
>"encoding" use="optional"
> 
>This could be in addition to Conrad's suggested change.
> 
>What do you folks think,
>Ed
>
>  _____  
>
>From: Edward Shallow [mailto:ed.shallow@rogers.com] 
>Sent: April 8, 2005 10:02 AM
>To: ed.shallow@rogers.com; 'Konrad Lanz'
>Cc: 'Juan Carlos Cruellas'; 'OASIS DSS TC'
>Subject: RE: [dss] XMLData problem in Core "Opaqueness
>
>
>Thanks Conrad for the reference back to your Apr 4th eMail. I (think I)
>understand your position now.
> 
>I believe your suggestions will work, although I am wary of the DOM-specific
>nature of the approach (i.e. node.ownerDocument, etc ...)
> 
>Also from a simplicity viewpoint, could we not consider more generalized
>support for "opaqueness thru encoding" as we do with Base64Data ? This would
>also address the PI and declaration issues.
> 
>I guess I am saying ... should we not consider both ?
> 
>Ed
>
>  _____  
>
>From: Edward Shallow [mailto:ed.shallow@rogers.com] 
>Sent: April 8, 2005 9:36 AM
>To: 'Konrad Lanz'
>Cc: 'Juan Carlos Cruellas'; 'OASIS DSS TC'
>Subject: RE: [dss] XMLData problem in Core "Opaqueness
>
>
>Thanks Conrad,
> 
>   I think you are agreeing with me in principle ? Not sure what you mean by
>
> 
>... and enclosed in tags similar to the <dss:XMLData> tags ...
> 
>Perhaps you could provide an example ? I was thinking more along the lines
>of additional <dss:Document> choices which are inherently more specific wrt
>encoding.
> 
>The problem with <dss:XMLData> is that it is of type AnyType and as such is
>too silent on potential use of encoding.
> 
>This makes it difficult to implement as there is no basis for infering
>content make-up which is my current dilemna.
> 
>Ed
> 
>P.S. I have got around the <Document> within <Document> problem should a
>user's payload contain a dss element. The "PI and declaration" lines is
>still a problem/challenge.
>
>  _____  
>
>From: Konrad Lanz [mailto:Konrad.Lanz@iaik.tugraz.at] 
>Sent: April 8, 2005 5:59 AM
>To: ed.shallow@rogers.com
>Cc: 'Juan Carlos Cruellas'; 'OASIS DSS TC'
>Subject: Re: [dss] XMLData problem in Core "Opaqueness
>
>
>Dear all,
>please see below.
>
>Konrad
>
>Edward Shallow wrote: 
>
>(In fact DocumentBaseType could easily be extended to further collapse the
>
>excessive number of document/signature type elements we presently have i.e.
>
>Document, DocumentWithSignature, SignatureObject, UpdatedSignature,
>
>Timestamp, etc ...)
>
>  
>
>However I would advocate that everything that is xml and is to be
>transported in an opaque way 
>by the dss core protocol should be clearly identified as payload (or plain
>raw xml data if you want)
>and enclosed in tags similar to the <dss:XMLData> tags to underline the
>required opaqueness.
>
>This should be done in either direction for signing and verifying for
>request and response.
>
>Hence this also applies to detached and enveloping signatures which are to
>be returned in a 
><dss:SignatureObject> in a <dss:SignResponse> or <dss:VerifyRequest> and
>potentially 
>other forms of payload like <ds:Transforms> and <ds:KeyInfo>.
>
>This further allows to use xml binding frameworks like JAXB to extract
>documents having 
><dss:XMLData> as root element and it's child nodes can easily separated from
>the ancestry
>context.
>(for a detailed explanation search for importNode in my last email
><http://lists.oasis-open.org/archives/dss/200504/msg00012.html>  04 Apr
><http://lists.oasis-open.org/archives/dss/200504/msg00012.html> 2005)
>
>However the problem concerning the transport of certain processing
>instructions and xml declarations 
>remains.
>
>
>Did
>
>not one of the public comments mention problems associated with 
>
>unwanted namespace inheritance from parent nodes in the request ? 
>
>    
>
>So far we have not received any other comment about that...I think that
>
>maybe one of the things that we should do is to test this feature in the
>
>interop and leave it documented.....
>
>  
>
>please search for "get rid of the namespace context" in my last email
><http://lists.oasis-open.org/archives/dss/200504/msg00012.html>  04 Apr
><http://lists.oasis-open.org/archives/dss/200504/msg00012.html> 2005.
><http://lists.oasis-open.org/archives/dss/200504/msg00012.html>  
>
>  
>