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

RE: Clarification on -- elided URI attributes

From: Gregor Karlinger <gregor.karlinger@iaik.at>
Date: Sat, 13 Oct 2001 00:54:47 +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: <LBEPJAONIMDADHFHAEAOKELGCJAA.gregor.karlinger@iaik.at>

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

I cannot see your point. It is no technical problem to design the call-
back in a way to deal with the situation drafted by you. For instance
the library could provide the position of the particular <Reference>
within the sequence of <Reference>s, or instead of providing a null
URI, the library could provide a proprietary URI indicating the posi-
tion within the sequence of <Reference>s, such as "myProt:pos1".

On the other side, I see no reason to allow an empty URI in a 
<Reference> at all, since you can solve all those scenarios with
proprietary URIs.

But that are all minor issues. The most important point I think is
that the specification reaches Recommendation status asap. If changing
anything here leads to further delays, I am strongly opposed to such

Received on Friday, 12 October 2001 19:02:32 UTC

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