Re: Clarification on 4.3.3.1 -- elided URI attributes

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
>


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Thursday, 11 October 2001 11:42:22 UTC