RE: [dss] XMLData problem in Core "Opaqueness

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

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 04 Apr 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 04 Apr 2005.