RE: Clarification on 4.3.3.1 -- elided URI attributes

Don,

I believe there will be implementations of XMLDSIG that will be able to
deal with multiple elided URLs.

Your alternative suggestion, to use application-specific URLs in
References, seems worse in that it promotes the proliferation of
private-label URLs that cannot easily be filtered as private.  If the
URL is elided that is a clear signal that interpretation of the
Reference is application specific.  If the URL begins with "don:", how
do I distinguish between private use of a prefix and public (but unknown
to the verifier) use of the prefix?

I could see you making an argument that elided URIs should be completely
prohibited, but I can't see a justification for claiming that one is OK
but two are evil.  

				--bal   

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] 
Sent: Friday, October 12, 2001 9:31 AM
To: w3c-ietf-xmldsig@w3.org
Cc: merlin; Brian LaMacchia
Subject: 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 14:05:33 UTC