RE: Omitting Location and Transforms from SignedInfo

Brian LaMacchia writes:
 > The impression I get from your messages is that you believe changing the
 > location of a signed object somehow invalidates the signature on that
 > object.  I strongly disagree with this notion; in fact I cannot see how the
 > location of blob of signed bits has anything (in general) to do with the
 > signed statements about that blob of bits.  The location is *not*
 > semantically significant to the signature (well, you could certainly define
 > an application domain in which was true, but I can't think of a single
 > situation in which that would be useful or meaningful).  In fact, I'd hate
 > to think that a signature on an object is invalid because I do not happen to
 > understand the particular protocol used in a Location URI.

I have an example of an application that does need to associate a
location (URI) with a particular set of bytes.  P3P
(http://www.w3.org/TR/P3P) defines a document format containing a
privacy policy, and the policy has a URI that may be used to refer to it
later.  A server refers to a privacy policy for a resource by giving
just the URI for the policy.  A client is permitted to trust that if the
policy URI is the same as one it already knows, then it can assume the
policy is unchanged.  It does not have to revalidate the policy URI for
each subsequent request.  The P3P specification working group has had
much discussion about whether this mechanism is adequate, but that's
what are currently going with.  (W3C members can see the resolution in 
http://lists.w3.org/Archives/Member/w3c-p3p-specification/1999Aug/0010.html)

If we could use digital signatures, then it would make sense to sign a
package of the policy URI and a hash of the policy document at that URI.
This signature would provide non-repudiation if the client wishes to
verify that the policy document at that URI has not changed.

 > Can you explain why you think that the location of an object is somehow
 > semantically relevant to the signature on that object?  

It amounts to an efficiency hack, so that the client does not have to
revalidate the policy URI for each subsequent request covered by the
same policy.

A signature by itself, used as an identifier, regardless of the policy
URI, might also support this efficiecy hack, and we previously had a
unique ID, called a "propID" for that purpose.  If the propID was an MD5
hash, we would have non-repudiation.  But because the propID is not
resolvable by itself, we also need a URI, and once we have a URI, and
since we are relying on promises anyway, the URI by itself is enough.

 > What sort of semantics are you trying to express?

The only semantics that should be associated with a URI by itself is
identity.  In other words, the URI may be used to represent the thing it
refers to.

 > And how do you expect such semantics to interact with common Web
 > elements such as caching servers, proxies, redirects, insecure DNS
 > and unauthenticated HTTP GET methods (e.g. all the various ways in
 > which it is perfectly legal and useful to spoof location)?

It still doesn't matter how the client uses a URI to get the appropriate
resource.  If there is any spoofing or brain damage going on, then the
wrong bytes might be returned, but then the client can validate those
bytes given the signature.  None of this changes just because the
signature also covers the URI itself.

Please note that even though this is an argument for being able to sign
the package of a URI together with the hash of the content at that URI,
I am not arguing that all applications must do this.  In fact, I am
coming to the conclusion that the specific set of information that must
be signed is up to the application, and it should not be mandated one
way or another by the core digital signature mechanism.

-- 
Daniel LaLiberte
liberte@w3.org

Received on Thursday, 18 November 1999 10:11:20 UTC