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

Hi Donald,

You're right. I don't see a problem if you use (validate) the References etc. from the original Document and then do signature validation on the canonicalized ds:SignedInfo. A colleague of me pointed out that this is not 
according to the spec, so to strictly follow the spec, we have to c14nize SignedInfo, reparse and substitute for same-document-URIs. But well, my implementation does not do this at the moment.

Does anyone sees a security implication if we do reference validation on the not-c14nized SignedInfo? I don't.


Christian

--On Freitag, 12. Oktober 2001 12:28 -0400 "Donald E. Eastlake 3rd" <dee3@torque.pothole.com> wrote:

>
> That would work but, even if you are very strictly following the Core
> Validation Processing Rules, I don't see why you couldn't just use the
> fragment URI to get the data from the original document without
> plugging back in the parsed canonicalized SignedInfo. I don't see that
> it would make sense for the fragment to point at or inside the
> SignedInfo, although you should check for that and probably fail the
> signature if you find it's set up that way.
>
> Even further, it seems to me that most implementations will not allow
> arbitrary CannonicalizationMethod elements and, in fact, all the ones
> we have ever specified are such that you would not get in trouble
> doing the Reference Validation on the original document, then applying
> CannonicalizationMethod and doing Signature Validation, even though
> that's not what the Processing Rules say and is not safe for arbitrary
> CannonicalizationMethod elements...
>
> Donald
>
> From:  Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
> Date:  Fri, 12 Oct 2001 10:00:12 +0200
> In-reply-to:  <001a01c152a9$1d64f1f0$38844ec6@starlan.com>
> 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?
>>






Mit freundlichen Grüßen,

Christian Geuer-Pollmann


--------------------------------------------------------------------------
Institute for Data Communications Systems             University of Siegen
Hoelderlinstrasse 3                 D-57068 Siegen                 Germany

mail:  mailto:geuer-pollmann@nue.et-inf.uni-siegen.de
web:  <http://www.nue.et-inf.uni-siegen.de/~geuer-pollmann/>

Received on Friday, 12 October 2001 13:56:00 UTC