W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2002

Re: newbie Question about PKCS#7

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Wed, 22 May 2002 13:59:51 +0200
To: Tom Gindin <tgindin@us.ibm.com>, reagle@w3.org
Cc: Ed Simon <edsimon@xmlsec.com>, Roman Huditsch <roman.huditsch@hico.com>, w3c-ietf-xmldsig@w3.org
Message-ID: <112054896.1022075991@pinkpanther>
Depends on whether the URI is a "same-document-URI" or not: For a 
non-same-document-URI, the octets are directly digested. Same-document URIs 
do contain nodeset magic:



means that the octets fetched from the ftp server (the rfc3075.txt file) is 
piped directly into the digest method.



is a same-document URI which identifies all nodes in the current document 
(except the comments). There is no ds:Transforms element which is a little 
bit tricky: The digest method requires octets, the input is an xpath node 
set, so the REQUIRED c14n algorithm (c14n omitting comments) is used to 
convert the nodes into octets.



is a same-document URI which identifies ALL nodes in the current document. 
There is no ds:Transforms element: The digest method requires octets, the 
input is an xpath node set, so the REQUIRED c14n algorithm (c14n omitting 
comments) is used to convert the nodes into octets. This means that the 
input to c14n contained comments while the c14n filtered them out.


The same applied to URI="#foo" and URI="#xpointer(id('foo'))" which makes 
the omitting/with comments dereferencing on subtrees rooted by the element 
with ID foo.


The example

<Reference URI="http://example.com/bar.xml#chapter1">

is a little bit tricky because it identifies a particular element in the 
XML instance, but (my implementation) does simply digest the octets from 
the xml file.


--On Dienstag, 21. Mai 2002 16:04 -0400 Tom Gindin <tgindin@us.ibm.com> 

>       My question can be most simply stated as whether a reference with
> neither type nor transform is to be interpreted as a transparent octet
> stream to be fed to the digest algorithms, and if not, what syntax is
> interpreted that way?  I am trying to ensure that we have a syntax defined
> for data that will NOT be interpreted as XML.  A very simple example would
> be the following:
> <Reference URI="ftp://ftp.isi.edu/in-notes/rfc3075.txt">
> <DigestMethod Algorithm
> ="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>Xyz=</DigestValue>
> </Reference>
>       Obviously, the digest value included in the sample is not the real
> one.  I hope this clarifies things.
>             Tom Gindin
> Joseph Reagle <reagle@w3.org> on 05/21/2002 08:50:54 AM
> Please respond to reagle@w3.org
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    "Ed Simon" <edsimon@xmlsec.com>, "Roman Huditsch"
>        <roman.huditsch@hico.com>, <w3c-ietf-xmldsig@w3.org>
> Subject:    Re: newbie Question about PKCS#7
> On Tuesday 21 May 2002 07:39, Tom Gindin wrote:
>>       If the syntax which has been suggested for transparent non-XML data
>> could be interpreted as a node-set, then IMO we need a syntax which
>> explicitly tells developers: "This reference accesses data transparently
>> as a sequence of octets.  That data is part of the base on which the
>> digest is calculated, but is not to be interpreted as XML."
> I'm not sure I understand your question (nor understand or agree with
> Christian's response.)  I don't grok "transparent non-XML data could be
> interpreted as a node-set". The process and result of dereferencing a URI
> is defined by the scheme. In the URI="http://example.com/bar.xml#chapter1"
> the http scheme yields an entity body that is naturally octets.
> Furthermore, the client's interpratation of those octets (such as the
> fragment identifier) is further defined by the octets' media type
> (specified "out-of-band", for example in the http headers). In this case,
> the fragment identifier identifies a particular element (and sub-tree via
> XPointer), if no subsequent transforms are defined, that nodeset is
> serialiazed via c14n. However, because of this "server provides,
> client/proxy interprets" confusion, we recommend against this approach
> regardless. "Again, for the sake of interoperability, the element
> identified as 'chapter1' should be obtained using an XPath transform
> rather
> than a URI fragment (barename XPointer resolution in external resources is
> not REQUIRED in this specification)."
> Regardless, I've expect I've gone afield from your original question.
> Perhaps if you could provide a complete example?
Received on Wednesday, 22 May 2002 07:55:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC