XmlDSig: The Reference Processing Model (Node set vs Octet stream)

Question

I'm studying XML Advanced Electronic Signatures.

To create "ArchiveTimeStamp" (page 58) the Specification says:

Process the retrieved ds:Reference element according to the reference processing model of XMLDSIG.

If the result is a XML node set, canonicalize it. (...)

The Reference Processing Model is over this:

<ds:Reference Id="myId" URI="http://fakefile.xml">
    <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    </ds:Transforms>
    <ds:DigestMethod/>
    <ds:DigestValue/>
</ds:Reference>

The process uses "URI=..." and "ds:Transforms" to retrieve the data.

Below are some parts extracted from (4.3.3.2 The Reference Processing Model):

The data-type of the result of URI dereferencing or subsequent Transforms is either an octet stream or an XPath node-set. (...)

In this specification, a 'same-document' reference is defined as a URI-Reference that consists of a hash sign ('#') followed by a fragment or alternatively consists of an empty URI (...)

Unless the URI-Reference is such a 'same-document' reference, the result of dereferencing the URI-Reference MUST be an octet stream. 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.

The following examples demonstrate what the URI attribute identifies and how it is dereferenced:

URI="http://example.com/bar.xml"
Identifies the octets (...)

URI="http://example.com/bar.xml#chapter1"
Identifies the element with ID attribute value 'chapter1' of the external XML resource (...), provided as an octet stream. (...)

URI=""
Identifies the node-set (...)

URI="#chapter1"
Identifies a node-set containing the (...)

The question.

For these References:

<ds:Reference Id="myId" URI="http://fakefile.xml">
...
(empty transform list)
...
</ds:Reference>

Result 1#: ( <file> ... childs ... <file> ). Without apply Digest Transform

<ds:Reference Id="myId" URI="http://fakefile.xml">
...
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
...
</ds:Reference>

Result 2#: (xml with exc-c14n). Without apply Digest Transform

<ds:Reference Id="myId" URI="http://fakefile.xml">
...
<ds:Transform "fake_Xpath_transform_to_get_all_childs"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
...
</ds:Reference>

Result 3#: ( only childs with exc-c14n <child_1/>...<child_x/> ) Without apply Digest Transform. This is not valid XML file to parse, does not has single root. But can be "node set" with in fakefile.xml context.

Are results (1#, 2# and 3#) "octet stream" ?

Because: Unless the URI-Reference is such a 'same-document' reference, the result of dereferencing the URI-Reference MUST be an octet stream.

Or are they "XML node set" required by XML Advanced Electronic Signatures to canonicalize?

Because: (...) 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.

Or the (unless a transform that requires XML parsing is applied) is valid only with in Reference context and the results are octet stream?

Articles are welcome.

Answer 1

They are all octet streams, i.e. binary, but the processing is different.

Besides the Reference Processing Model section also consider the Transforms element section for the following explanation.

1: Because http://fakefile.xml is not a same document reference and:

Unless the URI-Reference is such a 'same-document' reference, the result of dereferencing the URI-Reference MUST be an octet stream

Since there are no transforms, this octet-stream is the input for digest calculation

2: As stated in 1 http://fakefile.xml is not a same document reference, so the input for the transforms is an octet stream.

Since the canonicalization transform works over XML nodes, its input has to be converted to a XML node set, as stated on section Reference Processing Model:

If the data object is an octet stream and the next transform requires a node-set, the signature application MUST attempt to parse the octets yielding the required node-set via [XML] well-formed processing.

The output of the canonicalization transform is an octet stream by definition.

3: As stated in 1 http://fakefile.xml is not a same document reference, so the input for the transforms is an octet stream.

The XPath transform works over XML nodes which means the octet stream has to be converted to a node set (stated again in section XPath filtering). The output of the XPath transform is also a node set.

The following transform is canonicalization, which requires a XML node set as input. Since the inputs/outputs are chained (Transforms element section) and the previous output was already a node set, no conversion is needed.

Finally, the output of the canonicalization transform is an octet stream by definition.

---

In your examples the output of the transforms is always an octet stream, but if you have a single XPath transform, for example, then the result of transforms is a XML node set. It then has to be canonicalized as required by the ArchiveTimeStamp property definition. In this case you use the canonicalization algorithm defined on the ArchiveTimeStamp property itself, or the XML-DSIG default, if not specified.

Hope this helps.