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

Aleksey Sanin aleksey at aleksey.com
Fri Aug 30 15:13:28 PDT 2013


You should probably ask xadec people. They are inventing new way to do
signatures that has nothing to do with w3c xmldsig spec. I have no idea
what are they trying to do.

Aleksey

On 8/30/13 9:03 AM, Alexwell Sandro wrote:
> Sorry for the confusion.
> 
> The digest transform require an "octet stream". So all retrieved data
> can be used as "octet stream". 
> 
> But, ArchiveTimeStamp from /XML Advanced Electronic Signatures
> <http://www.etsi.org/deliver/etsi_ts%5C101900_101999%5C101903%5C01.04.02_60%5Cts_101903v010402p.pdf>/ (page
> 58) seems refers to "The Reference Process Model
> <http://www.w3.org/TR/xmldsig-core/#sec-ReferenceProcessingModel>"
> without the digest transform, because the digest algorithm may be weak.
> 
> *I will try to explain:*
> 
> If I signed a detached file, using Xpath to get the node "*child*" and
> apply exc-c14n:
> 
> - FakeFile.xml
> 
> <file xmlns:ns1="ns1">
> *<child>Text<child>*
> <file/>
> 
> I know that the *<child>Text<child> *is a "node set" with in
> FakeFile.xml. So I can use exc-c14n or inc-c14n.
> 
> But after retrieved process without apply digest transform. Is this "nod
> set" or "octet strem"?
> 
> *The Reference process Model says:*
> 
> /Unless the URI-Reference is such a 'same-document' reference , the
> result of dereferencing the URI-Reference MUST be an octet stream.
> /
> /
> /
> /URI="http://example.com/bar.xml#chapter1" /
> /Identifies the element with ID attribute value 'chapter1' of the
> external XML resource 'http://example.com/bar.xml', provided as an octet
> stream./
> 
> "provided as an octet stream" is the resource or the element?
> 
> Consider a signature over the digest "sha1" of "*<child>Text<child>*"
> 
> *Now the algorithm is weak, and I want to add ArchiveTimeStamp, 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. If
> ds:Canonicalization is present, the algorithm indicated by this element
> is used. If not, the standard canonicalization method specified by
> XMLDSIG is used./
> 
> *I can understand this like: Get data using URI and ds:Transforms
> without apply digest transform.*
> 
> So I will get *<child>Text<child> (*without digest transform)*, *if this
> is XML node set, canonicalize it.
> *
> *
> But this is a problem.
> *
> *
> If I consider the result of extern URI as a "node set" to apply
> ArchiveTimeStamp and the canonicalize transform used by Archive is
> inc-c14n, I will archive another file.
> *
> *
> *<child *xmlns:ns1="ns1"*>Text<child>*
> *
> *
> *If the documento change:*
> *
> *
> <file xmlns:ns1="ns1" xmlns:ns2="ns2">
> *<child>Text<child>*
> <file/>
> *
> *
> *I will try to verify the **ArchiveTimeStamp with:*
> *
> *
> *<child *xmlns:ns1="ns1" xmlns:ns2="ns2"*>Text<child>. *
> *
> *
> *The process to verify will fail. Because the Archive is over:*
> *
> *
> *<child *xmlns:ns1="ns1"*>Text<child>**
> *
> *
> *
> *The question.*
> *
> *
> *For these References:*
> 
> <ds:Reference Id="myId" URI="http://fakefile.xml <http://fakefile.xml/>">
> ...
> (empty transform list)
> ...
> </ds:Reference>
> *Result 1#: ( <file> ... childs ... <file> ).*
> 
> <ds:Reference Id="myId" URI="http://fakefile.xml <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 <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?*
> 
> Thanks
> 
> 
> 
> On Fri, Aug 30, 2013 at 12:05 PM, Aleksey Sanin <aleksey at aleksey.com
> <mailto:aleksey at aleksey.com>> wrote:
> 
>     I don't understand your question. At the end, digest is always
>     applied to the octet stream. The rules in the spec describe how
>     to get to the octet stream. In human language, there are only
>     two rules:
> 
>     1) Do not parse to XML unless it is necessary: it is already
>     parsed (same document) or there is an XML transform (e.g. XPath)
>     2) To convert back to octet stream use the specified c14n method.
> 
>     IMHO, it's pretty straightforward and logical.
> 
>     Best,
> 
>     Aleksey
> 
>     On 8/30/13 6:50 AM, Alexwell Sandro wrote:
>     > 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.
>     >
>     >
>     > _______________________________________________
>     > xmlsec mailing list
>     > xmlsec at aleksey.com <mailto:xmlsec at aleksey.com>
>     > http://www.aleksey.com/mailman/listinfo/xmlsec
>     >
> 
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
> 


More information about the xmlsec mailing list