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

Alexwell Sandro alexwellll at gmail.com
Fri Aug 30 06:50:14 PDT 2013


I do not know if this is the list for this discussion.

I added this question to
stackoverflow<http://stackoverflow.com/questions/18522211/xmldsig-the-reference-processing-model-node-set-vs-octet-stream>
.

I'm studying XML Advanced Electronic
Signatures<http://www.etsi.org/deliver/etsi_ts%5C101900_101999%5C101903%5C01.04.02_60%5Cts_101903v010402p.pdf>
.

*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<http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel>
):*

*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> ).*

<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).*

<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/> ) 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20130830/a2dac28c/attachment.html>


More information about the xmlsec mailing list