- 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>
Donald, > 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 changes. /Gregor
Received on Friday, 12 October 2001 19:02:32 UTC