W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

I command you to support Digest!!!

From: Jösh <josh@bluescreen.org>
Date: Thu, 25 Oct 2001 05:48:53 -0400
Message-ID: <00ab01c15d3a$45f0cd60$0200a8c0@wolverine>
To: "Jim Whitehead" <ejw@cse.ucsc.edu>, <mtimmerm@opentext.com>, <w3c-dist-auth@w3.org>
  Here are my thoughts on this.   Its a bit late for me, so they might be
a bit jumbled..  For those in a hurry, my short answer is:

I think that at this time, Digest is no longer the right minimum
Is there some way we can just require an "IETF recognized 'non-plaintext
over the wire'
authentication system" , such as Digest, Kerberos or SSL+Basic"?

My longer explanations...

On what/who the requirement applies to...

The Requirement applies to implementation, not operation.  If you ship a
product that claims
that it complies with WEBDAV RFC, it must support Digest in the shipped
If you dont support Digest, then you are not completely compliant.  Frankly,
I dont think this is such a big deal these days.  I imagine a product box or
spec that says
"Supports WebDAV * "  with a footnote below somewhere effectively saying:
"* Compliant with RFC XXXX except for Digest Authentication"  or
"* Conditionally compliant with RFC XXXX.  This product does not support
I think its reasonable to have customized versions of products that
may only be conditionally compliant.
As for servers in operation, it is well known that Operational Policy in an
may cause a product to be configured in such as way that it does not
interoperate with
another compliant product.    Many specs today seem to have a set of
"features" and
a minumum required set to be supported, which apply to products claiming
yet operators can configure them out of compliance.    There is probably
some work
that should be done to find good language to describe this and differentiate
it from
"real" requirements that must always be true in both implementation and

On Digest as the right choice for the requirement:
IMHO, the spirit was "Anyone procuring a product that claims WebDAV RFC
must be able to be configured to use a non-plaintext authentication that is
recognized by the IETF"
Unfortunately, requiring SSL would have been too painful both because it
is/was not IPR free
and that it is/was considered too hard/heavyweight to require.  As a result,
Digest was available
to be used to solve this problem.  Digest was created to fix this problem,
of plaintext passwords
*over the wire*.  I dont think it was obvious at the time how much its
implementation would
complicate how passwords are stored in practice.

Today, I would think that requiring SSL+basic would be less of a hardship
than Digest.
In my own experience, I know that implementing SSL (for the encryption part
at least)
was relatively simple and isolated from the rest of the system.  In fact, it
can be done
in a way that applications can use SSL with almost no code changes, similar
to socks.
Implementing Digest in Windows/IIS was very difficult, since IIS uses
integrated with system accounts.   Prior to Digest, system passwords were
in a hash that was incompatible with the digest hash.  So some pretty
serious architectural
changes had to be made to support digest in a non-hacky way.
 It seems that Daryl has come to a similar realization.

I think that at this time, Digest is no longer the right minimum
Is there some way we can just require an "IETF recognized 'non-plaintext
over the wire'
authentication system, such as Digest, Kerberos or SSL+Basic"?

On Testability:
Basic Authentication is a required part of HTTP/1.1, testing for that is the
same problem as testing for Digest.   Depending on your perspective, this
reduces to a previously unsolved (or solved) problem.
Received on Thursday, 25 October 2001 05:46:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:24 UTC