[xmlsec] XmlDSig: The Reference Processing Model (Node set vs Octet stream)
Alexwell Sandro
alexwellll at gmail.com
Fri Sep 6 12:22:16 PDT 2013
Resolved!
I realized that using standard transformers, external URI only use
ArchiveTimeStamp canonicalization transform if ds:reference contains the
XPath transform as last transform.
So, external URI="fakefile.xml#child1" result "octet stream" and external
URI="fakefile.xml" with transform Xpath to get child1 result "node set".
In the end I was the one complicating.
Thank you for contacting.
On Fri, Aug 30, 2013 at 7:13 PM, Aleksey Sanin <aleksey at aleksey.com> wrote:
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20130906/89bfcb15/attachment-0001.html>
More information about the xmlsec
mailing list