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 <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> 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 > > > [email protected] <mailto:[email protected]> > > > http://www.aleksey.com/mailman/listinfo/xmlsec > > > > > > > > > > > > > _______________________________________________ > > xmlsec mailing list > > [email protected] > > http://www.aleksey.com/mailman/listinfo/xmlsec > > >
_______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
