RE: ObjectReference shouldn't be signed, was RE: Location shouldn't be signed!

Actually, I would agree with the assertions as stated (as far as they go)
because the failure results not from different assertions but rather from
ambiguities in the assertions.

The data does have a Location of "URI", and if the URI is changed, then the
data is truly at that new location.  The assertion as stated says nothing
about whether URI must be invariant once the signature is created.  Andreas
is basically pointing out that the spec as written implicitly assumes this
invariance.

This is contrary to one of Dave Solo's earlier design principles.  The main
thing I'm pointing out is that if we remove this invariance, then we must
also allow Transforms to vary.  A scenario communicated to us by Rich Himes
is as follows:

Use XML file with data enveloped to deliver signed data to desktop.  Once on
desktop, switch data to residing on desktop, and change URI to point to that
data, then remove the copy of the data from the XML file (making it much
smaller), and store the detached signature for possible later use.

Unfortunately, the digest value needs to be signed or there is no security,
so we must sign ObjectReference.  So we either sign the whole thing and live
with invariance (using Don's manifest ideas and application processing rules
to accomplish the desired effect), or we do something like add Transforms to
omit the things that the primary signature shouldn't sign (like Location
and/or Transforms in the ObjectReference).

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
Jr.
Sent: Wednesday, November 03, 1999 11:38 AM
To: John Boyer; Andreas Schmidt
Cc: IETF/W3C XML-DSig WG; Reiner Hüttl; Robert Frost
Subject: Re: ObjectReference shouldn't be signed, was RE: Location
shouldn't be signed!


At 13:07 99/10/28 -0700, John Boyer wrote:
 >I just wanted to briefly comment on this.  The problem addressed in
Andreas'
 >email is what happens when an externally validated resource moves from one
 >location to another.

I just wanted to address this point in a round about way. In order to be
rigorous in our semantics I think of what we are doing in terms of
assertions. I suspect people are going to buy themselves a lot of trouble
for things like URIs, HTTP, mirroring and caching if they don't do the same.
I tried to tease out some of the assertions back in August [1], but wanted
to restate what I think an ObjectReference states with my present
understanding [2]. Object Reference includes 3 assertions:

        1. Each Resource has a Location of "URI"
        2. and each Resource has Transformations performed over the
            dereferenced URI content.
        3. and each Resource has an associated DigestValue resulting
            a digest value being applied to the dereferenced URI content.

It seems you might be saying that there is some content (byte stream) that
has one or more URIs. This is a different way of looking at the problem and
I can see this point of view, and to that end I think our term "Location" is
a misnomer since it references a URI, not necessarily a URL. If people
wanted to associated a resource with a URN and the means of dereferencing
that URN to derive the content is defined elsewhere, fine. If they want to
associate some sort of remapping, or query/resolution with a URL to do the
same, fine.

I think Andreas's point was that there are four meta-assertions (that might
incude others) we could make, and should we provide the syntax to express
them.

I'd opt for one:

 >1) Use Don's proposal indirectly by pushing these problems off to
 >application processing rules.

It is not _our_ job to redefine or reinvent URI, URN, or URLs or ways of
doing indirection/redirection over them. Maybe my take on this is wrong, and
if so I would ask what exactly is the set of assertions associated with the
other proposal?

[1] http://www.w3.org/Signature/Drafts/xmldsig-datamodel-19990819.gif
[2] http://www.w3.org/Signature/Drafts/xmldsig-datamodel-19991029.gif
[3]
[4]

_________________________________________________________
Joseph Reagle Jr.
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Wednesday, 3 November 1999 15:18:48 UTC