W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 2001

Re: Canonicalization of <SignedInfo> for Reference Validation (redux)

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Fri, 12 Oct 2001 10:00:12 +0200
To: Vamsi Motukuru <vamsi@phaos.com>
Cc: w3c-ietf-xmldsig@w3.org
Message-id: <2153432166.1002880812@pinkpanther>
Hi Vamsi,

you could take ds:SignedInfo, canonicalize, re-parse and substitute the 
original-un-c14nized ds:SignedInfo with the c14nized-re-parsed 
ds:SignedInfo.


BTW, for your example, you need to declare the Signature namespace for your 
signature.

Christian

--On Donnerstag, 11. Oktober 2001 19:04 -0400 Vamsi Motukuru 
<vamsi@phaos.com> wrote:

> However, I'm still having trouble understanding how this would really be
> implemented for same-document fragment Reference URIs where the
> referenced  XML is a sibling subtree of the enclosing document. For
> example:
>
> <MyDoc>
>    <ItemList ID="TheList">
>      <Item num="001">First item</Item>
>      <Item num="002">Second item</Item>
>    </ItemList>
>    <Signature>
>      <SignedInfo>
>        <CanonicalizationMethod> ... </CanonicalizationMethod>
>        <SignatureMethod> ... </SignatureMethod>
>        <Reference URI="#TheList">
>          <DigestMethod> ... </DigestMethod>
>          <DigestValue> ... </DigestValue>
>        </Reference>
>      </SignedInfo>
>      <SignatureValue> ... </SignatureValue>
>    </Signature>
> </MyDoc>
>
> When, at the start of reference validation, XML-C14N (or some other
> canonicalization) is applied to the SignedInfo, the result is an octet
> stream. In order to proceed with retrieving the referenced object and
> calculating the digest value, the application will first need to parse
> the  octet stream to recover an XML document with Reference elements in
> it. This  results in a new document that does not contain the data object
> identified  in the Reference URI. What now?
Received on Friday, 12 October 2001 03:58:02 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:14 GMT