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

Re: newbie Question about PKCS#7

From: Tom Gindin <tgindin@us.ibm.com>
Date: Tue, 21 May 2002 16:04:12 -0400
To: reagle@w3.org
Cc: "Ed Simon" <edsimon@xmlsec.com>, "Roman Huditsch" <roman.huditsch@hico.com>, <w3c-ietf-xmldsig@w3.org>
Message-ID: <OF33EC779D.3B8D1798-ON85256BC0.006D2BDF@pok.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
      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:42:28 UTC

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