[dss] Draft for a informative annexes: Echoing Data, Binary Identity

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

Dear all,

Echoing data:

To be compatible and with other xml applications one should always make
a distinction between a) data that enters the chain of transforms and
that should be echoed as it is in an enveloped signature document or
<ds:Object> and b) different data of two or more documents that produce
the same digest value (i.e. are valid inputs for a reference to be
verified assuming only trustworthy transforms and canonicalization where
used so that all input documents are "legally" equal, but technically
different).

Data as in b) could be usable in front of a judge in the case of a
dispute, but users of other xml application might have lost valuable
information.

Where possible data should always be returned as it was sent by the
client, although parts of a document may not be relevant for signing,
but relevant for other processing. For example a comment or processing
instruction or element nodes removed in the chain of transforms may be
relevant for other processing though not signed and hence not
influencing the digest value.

In special situations the omission of such nodes may cause side-effects
in the chain of transforms due to the dependency of a node set on the
underlying document causing signatures that are not verifiable any more.

This applies to sections 3.3.2 in combination with sections 3.5.6.1 or
3.5.7 ... . (and a reference to this text should be added there).

If a client sends data inside an <InputDocument>/<Document>/<InlineXML>
(i.e. it is not opaquely encoded in <Base64XML> or <EscapedXML>) the
server MAY not return (echo) an exactly matching <DocumentWithSignature>
after an EnvelopedSignatureTransform.This happens due to potential loss
of comments or processing instructions on extraction or loss of
information about namespace declarations. Namespace declarations MAY due
to Canonicalization (or outer processing like SOAP etc..) have moved and
hence have a different parent node. Intuitively speaking; they have
become "attributes" of  other nodes or even became redundant.

A round tripping requirement for the complete set of information an
input document carries can thus only be achieved by using <Base64XML> or
<EscapedXML>.

This standard however does appreciate the fact that there are ways to
realize round tripping like behavior in DOM, but found that this is not
concisely enough specified and would constrain this specification to the
use of DOM.
see:
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-adoptNode
Please also note the fact that namespace declarations can be lost and
default attributes are assigned after performing one of those operations.

Hence this specification talks about context free extraction which is
specified as the exclusive canonicalization of an <xs:any> element and
all of its descendants into an octet stream that then can be parsed
again if required, taking into account that this supports round tripping
only for that set of documents, where a document is not changing after
applying exclusive canonicalization one ore more times.

Binary identity (Encoding issues):

This applies to section 3.3.3 step 1a. and 3.3.1 step 1.d.v. .

If an input document <InputDocument>/<Document>/<EscapedXML> is to be
signed using an external Uri in the <ds:Reference> and this reference
does not contain any transforms requiring NodeSetData as input (i.e the
data will be parsed at lest once and canonicalized at least once) the
digest value depends on the underlying binary format of the dereferenced
octet stream (endianess and byte order marks). Transforms taking binary
input and having binary output may also behave differently depending on
the underlying encoding and hence produce different digest values on
different platforms and systems. Canonicalization can overcome these
problems if the Data is a well-formed XML document, hence there is a
need for binary canonicalization.

best regards
Konrad