Re: Clarification on 4.3.3.1 -- elided URI attributes

Hi,

In trying to explain the logic behind the original design decision, I
left out the most important reason to leave it alone, that it is not
worth making such a change at this late date.

Basicly, XML is verbose, so the logic of trying to save a few
characters is always open to question. The things the spec lets you
leave out are at most one Reference URI and the KeyInfo element. It
could have also permitted omission of CanonicalizationMethod,
SignatureMethod, DigestMethod, and maybe a few other things, but did
not.

KeyInfo omission is, in my opinion, motivated by its possible huge
size as well as other factors mentioned in the spec. (KeyInfo is also
different in not being secured unless you add a Reference to it...)

Omitting at most one URI was allowed, I believe, because it does not
break the model that a Refence can be processed in isolation without
taking into account anything else about the SignedInfo (or Manifest)
in which it appears.  Thus, in some way, an absent URI is just a
particular kind of unique pointer to the verifying application. This
model is broken if multiple URIs can be elided, resulting in added
complexity.

From:  "Brian LaMacchia" <bal@microsoft.com>
Date:  Fri, 12 Oct 2001 11:04:49 -0700
Message-ID:  <BCDB2C3F59F5744EBE37C715D66E779C01E1C3BB@red-msg-04.redmond.corp.microsoft.com>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            <w3c-ietf-xmldsig@w3.org>
Cc:  "merlin" <merlin@baltimore.ie>

>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

I have no idea what your image of the modularization is or what is
doing this filtering, but it seems to me you'd be pretty safe using
schemes that start with "x-", such as "x-1:", "x-2:", if you want or
"microsoft.com:1", etc.

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

Use of a different namesapce than the XMLDSIG one would also be a
clear signal that interpretation of the whole Signature is application
specific. So it's not like you can't escape to a different world if
you want. There are many ways an applications could formulate URIs so
that it would be trivial for a URI dereferencing module to recognize
them.  I've given two above.

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

Please point out where I said anything about this was "evil".

As I tried to explain below, it changes the modulariztion coupling and
a minor design principle and, I believe, changes them for the
worse. If multiple Reference URIs can be elided, then the Reference no
longer identifies its data.  Think what you will of this point I
really don't see any clearer way of explaining it than I have above
and below.

>				--bal

Donald

>-----Original Message-----
>From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]=20
>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=20
>
>
>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>=20
>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:=20
>>>
>>>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?=20
>>>
>>>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 Wednesday, 17 October 2001 21:04:09 UTC