Re: Link Extensions. Need "md5" or some kind of hash.

Subject: Re: Link Extensions. Need "md5" or some kind of hash.

From: Bob Wyman <bob@xxxxxxxx>

Date: Wed, 12 May 2010 15:53:24 -0400

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=XNzbRlhDFcrzGOyjfkBGv78/9Czc8gReQ1qCKwtd6oE=; b=mzYJi9chF0HDv+stHagSMmuUnZnipnPQb7Qe+nnDn0PHUePCehyO2ikSvjNfKbpCId lvWmkvW6QE3c2twsZBIOFaNTqrfHnJ6ziRWg5SzUjDORadaSFI46bm3COBMk7hM/JxIq YsAPHhYPjbL49d9eWwbsONGveJ5LEWwRNNSAk=

Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Tfc627SCP9r5kZiF4H8Sf+5zBGaHx/oF3vI9gzA1LG4uidLTIPxPf4bqc/bSS+ziRr OM2m8nPjcCRXGz27DRiESXp7WVHcX1cFrhP6fKhBylLJl2+cikIkBLnW6vOlPC0l9Nf0 YeCDeIzJlNHlzNEyufHXply5mB9xjl+fVuhJU=

In-reply-to: <AANLkTilxTQpGhJWC7AyCrIvCvZe7M5L8KjPCJtk7bnBk@xxxxxxxxxxxxxx>

List-archive: <http://www.imc.org/atom-syntax/mail-archive/>

List-id: <atom-syntax.imc.org>

List-unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>

References: <y2m45be5cd41005041054g84783901s93762ddb7e1cfd7@xxxxxxxxxxxxxx> <AANLkTilxTQpGhJWC7AyCrIvCvZe7M5L8KjPCJtk7bnBk@xxxxxxxxxxxxxx>

Sender: owner-atom-syntax@xxxxxxxxxxxx

I would strongly encourage you to make the markup more expressive and flexible by supporting "a generic hash attribute with an internal structure for specifying algorithm and value". Actually, I would suggest that you extend this a bit further to include a specification of the encoding for the hash value.Thus, I would suggest the following pattern:

hash_algorithm.encoding.hash_value

Alternatively, you could define a single, required hash_value encoding. (Which wouldn't be too bad a thing to do.) Clearly, there should be a registry of hash_algorithms as well as encodings (if supported).

In your blog post, you mention that clients might tend to rely on the value returned by the Content-MD5 header. While this may be reasonable for HEAD requests, clients should probably not trust the remote server when doing GETs; they would be well advised to recompute the hash to ensure that the remote server isn't lying about the hash (there are quite a number of useful, but often deceitful, reasons why this might happen). Also, please note that it should be possible to include a hash value which uses a different hashing algorithm and encoding than is used by the Content-MD5 implementation. Thus, for any particular web resource, we might have quite a number of possible hash/encoding combinations and, in some cases, even have two hashes available for a single GET (i.e. The Content-MD5 header value and perhaps an SHA1/base64 hash specified in the link.) You might make a note about some of these odd cases in your security considerations section.

bob wyman

On Wed, May 12, 2010 at 12:42 PM, James Snell <jasnell@xxxxxxxxx> wrote:

Updated the Link Extensions Draft...

http://www.snellspace.com/wp/2010/05/atom-link-extensions/
http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt

- James

On Tue, May 4, 2010 at 10:54 AM, Bob Wyman <bob@xxxxxxxx> wrote:
> I find that I have a real need for the "md5" Link rel mechanism defined in
> James Snell's old Atom Link Extensions draft or something functionally
> equivalent. Basically, what I need to do is ensure that the "src" attribute
> on an atom.content element is pointing to a known version of a resource
> rather than simply to any resource that has the same URL as in the src
> attribute. I'm then going to sign the Atom entry that contains this "by ref"
> content element.
> I've looked at the HTML5 RelExtentions Wiki but don't see anything there
> that looks like it does the job.
> Has anyone else needed hashed links in Atom? If so, what approach did you
> use to provide them? Is anyone aware of plans to introduce an "md5" or
> equivalent attribute to the HTML5 list?
> bob wyman
>

--

- James Snell
http://www.snellspace.com
jasnell@xxxxxxxxx