Re: Clarification on 4.3.3.1 -- elided URI attributes

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
>

Received on Friday, 12 October 2001 12:33:02 UTC