Re: [dss] Groups - Digital Signature Service Core Protocols, Elements,and Bindings (oasis-dss-1.0-core-spec-wd-33pre9.doc) uploaded

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Dear Nick and Stefan and all,


Nick Pope wrote:

>[...]
>
>More specifically:
>
>A) Description of handling Canonicalization in 3.3 is broken up into item 1c, Item 2 and 3.3.1 which I found very difficult to follow.
>
>I suggest that there is one item that describes the rules for canonicalisation combining these three into 3 separate points:
>
> i) (from 1c) If carried in <InlineXML> the need to extract XML data without namespace or other dependencies.  This may be achieved using Exclusive Canonical XML (How does this fit in with next point)
>
>ii) (from 3.3.1) If no other transform use canonical XML, As per XML-Sig rule
>  
>iii) (from 2) if applying other transforms which result in node-set then need to apply Canonical XML.  Also follow XML Sig rules
>  
>
I think we should not mix up the point i) with ii) and iii) as they have
different purposes.

i) is to be able to do context free extraction and to assure that
comments and processing instructions are striped of and not echoed (in
enveloped signatures or ds:Objects).

Even servers that support PIs and Comments behave uniformly, if PIs and
Comments shall be ignored.
Hence servers using parsers or unmarshalling that do not keep processing
instructions and Comments behave in the same way as others supporting
PIs and Comments.

ii) and iii) on the other hand are to convert node-set data to octet
stream data before hashing.

>B) Item 1 / 3.  It should be made clear that steps 1 & 2 apply to each <Document> at the start before Item 1.
>
>_[...]
>_
>D) Item 1a. Not sure I understand the reason for the reference [XML-NT-Document].  Is this trying to say that the XML contained within <Document> MUST be a complete XML Document as defined in [XML-NT-Document].
>  
>
This is excatly what it is trying to say.

>E) Item 1c  This is confusing.
>The requirement is to extract the data without any namespace or other dependencies or XML containing document.  One way of achieving this is to use exclusive Canonicalization.
>  
>
Exactly, this is what we were trying to say and we were hoping for
feedback, so how about the following wording:

In the case where <Document> contains <InlineXML>, the server extracts
the content of <InlineXML> as node set data.
Appropriate measures MUST be taken to free the content of its namespace
context and other dependencies on the dss protocol.

A second requirement here is also that this extraction is to be
well-defined and hence done in the same way by all servers.
A third requirement is that the the document's infoset remains unchanged
during the whole process until being processed by the first server side
transform (client side embedding, client side serializing, server side
parsing, and extraction).
Alternatively changes that happened (e.g. an unnecessary namespace
declaration that has been removed etc..) are taken care of by the first
server side transform. Exclusive Canonicalization can add here a lot of
robustness if used for extraction.

So we might also add sentences similar to the following as well:
This MAY be achieved in a well-defined way by using exclusive
Canonicalization to free <InlineXML> of it's namespace context and other
dependencies on the dss protocol as the first server side transformation.
Alternative extraction measures that affect the context free infoset
inside InlineXML have to reflect this by adding an appropriate server
side transform at the beginning.

Further points that are relevant in the light of this discussion:
If no server side transforms are to be applied and the RefURI is an
external URI binary identity has to be achieved.

    See [XMLSig]  4.3.3.2 The Reference Processing Model: In particular,
    an XML document identified by URI is not parsed by the signature
    application unless the URI is a same-document reference or unless a
    transform that requires XML parsing is applied. (See Transforms
    <http://www.w3.org/TR/xmldsig-core/#sec-Transforms> (section 4.3.3.1).)


Hence a xml declaration will have to be added by the server which is
impractical if binary identity has to be achieved. Or if someone wants
to transport an UTF-16 and an UTF-8 encoded InlineXML Document inside
the same UTF-8 dss request or other encoding combinations mutatis mutandis.
In such cases the use of Base64XML is indicated and should be compulsory.

Alternatively we would have to specify exact constraints like how the
xml declaration has to look like and how to achieve binary identity
including the setting of ByteOrderMarks and Endianess etc... .

EscapedXML will suffer similar problems if binary identity has to be
achieved for non-same document references.

>J) 2.4.2 ignorePIsComments Attribute
>
>Line 399 – 
>
>Change It contains the ignorePIsComments attribute.  … MAY be ignored. 
>
>To
>
>It may contain the ignorePIsComments attribute.  ….  SHALL be ignored.
>  
>
In the case where Comments and PIs are ignored we should ask for a
server side XPath transformation that strips of Comments and PIs placed
as the second transformation after exclusive Canonicalization for
extraction or first.

In the case of ignorePIsComments="true" we should also make people aware
that they are not only ignored for digest creation, but also that they
cannot be echoed in ds:Objects or enveloped signatures as well. As they
might have gone lost already during client side serialization, server
side parsing or server side extraction.

In the case of ignorePIsComments="flase" they also have to be echoed in
ds:Objects and enveloped signatures.


best regards
Konrad

P.S.: I tidied up the tracked formatting changes that do not carry a lot 
of information.

oasis-dss-1.0-core-spec-wd-33pre10.doc