W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: Instance Digests in HTTP (RFC3230)

From: Anthony Bryan <anthonybryan@gmail.com>
Date: Sun, 4 Oct 2009 02:21:48 -0400
Message-ID: <bb9e09ee0910032321r281e2980h67783268d8c9fc27@mail.gmail.com>
To: Lisa Dusseault <lisa.dusseault@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Interoperability seems rather lax, especially because I haven't been
able to find if there is actually any server side support (in shipping
code) for anything to interoperate with. Does anyone know of any?
I know of a few clients with support.

>From RFC3230, 4.3.2 Digest

   A Digest header field MAY contain multiple instance-digest values.
   This could be useful for responses expected to reside in caches
   shared by users with different browsers, for example.

   A recipient MAY ignore any or all of the instance-digests in a Digest
   header field.

   A sender MAY send an instance-digest using a digest-algorithm without
   knowing whether the recipient supports the digest-algorithm, or even
   knowing that the recipient will ignore it.

Because there are no recent values in the registry, I see download
clients do this (3x variants of SHA1, 2x of other hashes):

Want-Digest: MD5;q=0.3, MD-5;q=0.3, SHA1;q=0.8, SHA;q=0.8,
SHA-1;q=0.8, SHA256;q=0.9, SHA-256;q=0.9, SHA384;q=0.9, SHA-384;q=0.9,
SHA512;q=1, SHA-512;q=1

(IANA registry Hash Function Textual Names
has updated values).

Various organizations warn...


"Do not use the MD5 algorithm
Software developers, Certification Authorities, website owners, and
users should avoid using the MD5 algorithm in any capacity. As
previous research has demonstrated, it should be considered
cryptographically broken and unsuitable for further use."


"Federal agencies should stop using SHA-1 for digital signatures,
digital time stamping and other applications that require collision
resistance as soon as practical, and must use the SHA-2 family of hash
functions for these applications after 2010... Regardless of use, NIST
encourages application and protocol designers to use the SHA-2 family
of hash functions for all new applications and protocols."

And various organizations have put it into practice:


On Thu, Oct 1, 2009 at 7:22 PM, Lisa Dusseault <lisa.dusseault@gmail.com> wrote:
> Isn't more digest values worse for interoperability?  Is there an overriding
> security concern that would justify worse interoperability?
> Lisa
> On Mon, Sep 28, 2009 at 11:27 PM, Anthony Bryan <anthonybryan@gmail.com>
> wrote:
>> I'd like to update the Hypertext Transfer Protocol (HTTP) Digest
>> Algorithm Values registry [1] created by RFC3230.
>> Current values are MD5, SHA, UNIXsum, UNIXcksum.
>> I'd like to add SHA-224, SHA-256, SHA-384, and SHA-512.
>> My metalinkhttp ID [2] lists these in the IANA considerations section.
>> I'd also like to find out about current support of Instance Digests on
>> the client & server side.
>> Should I keep these registrations in the metalinkhttp ID, or separate
>> them [attached]? They're not specifically tied to metalinkhttp.
>> Other questions...
>> Current registry: MD5 lists both RFC1521 and RFC20456 for base64
>> encoding. Should this draft update it to refer to just one?
>> Current registry: SHA link ( http://csrc.nist.gov/fips/fip180-1.txt )
>> is no longer valid. Should this draft update it?
>> If we update SHA in the registry, should this draft refer to SHS or
>> RFC3174?
>> --
>> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
>>  )) Easier, More Reliable, Self Healing Downloads
>> [1] http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml
>> [2] http://tools.ietf.org/html/draft-bryan-metalinkhttp

(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads
Received on Sunday, 4 October 2009 06:22:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC