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

Re: Clarification on 4.3.3.1 -- elided URI attributes

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Sat, 13 Oct 2001 09:26:52 +0200
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, w3c-ietf-xmldsig@w3.org
Cc: merlin <merlin@baltimore.ie>, Brian LaMacchia <bal@microsoft.com>
Message-id: <2237832447.1002965212@localhost>
Hi Donald,

I implemented this just to play around it. Well, it's a little but hairy, but it works. My implementation [1] allows this behaviour.


Christian

[1] http://cvs.apache.org/viewcvs.cgi/xml-security/src_samples/org/apache/xml/s
ecurity/samples/signature/
    - CreateNullURIReference.java
    - NullURIReferenceResolver.java


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

>
> As a WG member, I oppose this change. If you are being grossly
> application dependent, you can always just have one Reference where
> the application magicly knows how to construct a composite TLV encoded
> octet string or the like with all the data you want to sign.  Or just
> forget about using the XMLDSIG standard at all.
>
> I would assume the way some XMLDSIG libraries would work is that you
> give them the Signature element and they use a call back to get the
> data based on the URI. Under such an arrangement, there is no problem
> with application dependent URIs like "x:1", "x:2", etc. And the
> application could know what to do for a special callback indicating no
> URI. But how could it work for multiple call backs for no URI? After
> all, the XMLDSIG library isn't constrained to do these Reference call
> backs in any particular order. With multiple null URIs there would be
> no way to know which Reference a call back was for.
>
> Thanks,
> Donald
>
> From:  merlin <merlin@baltimore.ie>
> To:  "Brian LaMacchia" <bal@microsoft.com>
> Cc:  w3c-ietf-xmldsig@w3.org
> In-reply-to:
> <BCDB2C3F59F5744EBE37C715D66E779C02903034@red-msg-04.redmond.corp.micro
> soft.com>
> Date:  Thu, 11 Oct 2001 16:42:16 +0100
> Message-Id:  <20011011154216.B9B3343C1A@yog-sothoth.ie.baltimore.com>
>
>> I agree (subject to usual caveats of not delaying the process).
>>
>> Merlin
>>
>> r/bal@microsoft.com/2001.10.10/11:13:54
>>> XMLDSIG Section 4.3.3.1 contains this paragraph which identifies when
>>> you can elide the URI attribute on a Reference:
>>>
>>> If the URI attribute is omitted altogether, the receiving application is
>>> expected to know the identity of the object. For example, a lightweight
>>> data protocol might omit this attribute given the identity of the object
>>> is part of the application context. This attribute may be omitted from
>>> at most one Reference in any particular SignedInfo, or Manifest.
>>>
>>> What is the justification for the restriction embodied in the last
>>> sentence?  Once you elide a single URI attribute from a Reference,
>>> you're guaranteed to be in an application-specific domain where the
>>> verifier must have out-of-band knowledge to match up Reference and
>>> referenced content.  Given that the receiving application has to know
>>> how to find one referenced object, why can't it know implicitly how to
>>> find multiple referenced objects and match them up?  Since we're talking
>>> about application-specific context anyway there's no interop issue, so
>>> what's the benefit of having the restriction on elided URLs?
>>>
>>> Unless there's a compelling reason to keep the restriction (which I
>>> can't see), I suggest we remove it and delete the last sentence of the
>>> quoted paragraph from 4.3.3.1.
>>>
>>>					--bal
>>
>






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 Saturday, 13 October 2001 03:24:55 GMT

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