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 07:39:50 -0400
To: reagle@w3.org
Cc: "Ed Simon" <edsimon@xmlsec.com>, "Roman Huditsch" <roman.huditsch@hico.com>, <w3c-ietf-xmldsig@w3.org>
Message-ID: <OFC86C6433.6C16274D-ON85256BC0.003FB483@pok.ibm.com>


      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."

            Tom Gindin

Joseph Reagle <reagle@w3.org> on 05/20/2002 05:40:02 PM

Please respond to reagle@w3.org

To:    Tom Gindin/Watson/IBM@IBMUS, "Ed Simon" <edsimon@xmlsec.com>
cc:    "Roman Huditsch" <roman.huditsch@hico.com>,
Subject:    Re: newbie Question about PKCS#7

On Thursday 16 May 2002 11:28, Tom Gindin wrote:
>       Maybe I'm confused about the standard, but I don't see a "Type"
> value for transparent binary data or a transform for it.  Does a
> Reference with both Type and Transforms omitted mean binary?

It is octets or a node-set.

  Identifies the element with ID attribute value 'chapter1' of the
  external XML resource 'http://example.com/bar.xml', provided as an
  octet stream. 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).
The data-type of the result of URI dereferencing or subsequent Transforms
is either an octet stream or an XPath node-set.
If the data object is a node-set and the next transform requires octets,
the signature application MUST attempt to convert the node-set to an octet
stream using Canonical XML [XML-C14N].
Received on Tuesday, 21 May 2002 07:40:37 UTC

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