Re: Straw-man charter for http-bis

Keith Moore wrote on 6/10/07 23:33 -0400:
>>> Digest has a bad reputation particularly among Web App developers for
>>> a number of reasons, some inherent to the design and specification,
>>> some stemming from implementation and deployment choices.
>>>
>>
>> Nearly all is implementation.
>>
> ah, but what's the reason for all of those implementation-imposed
> constraints?

I would speculate it's because the following mandatory pieces of a complete 
DIGEST-based solution were never written down:

* Client UI requirements
* How to store DIGEST H(A1) in a central authentication repository such as
  LDAP or RADIUS in an interoperable fashion
* How web CGIs, PHP modules, etc. interface to the HTTP server's DIGEST support
* How to tie the DIGEST identity to whatever real identity system happens to
  be deployed at the web site.  From an IETF standards perspective, that
  means getting the LDAP directory entry and/or RADIUS/DIAMETER attributes for
  the user to the subsystem that needs that information.  In practice this can
  also involve a SQL database with unspecified keys and attributes.
* How a web page can securely associate branding with a DIGEST authentication
  UI in the browser
* How to migrate an existing password repository using an arbitrary
  one-way-function to store password verifiers to one that's DIGEST compatible,
  and do so in a way that won't generate service calls from customers.

Since implementations already have all this infrastructure for plaintext 
passwords (existing standards are sufficient due to plaintext simplicity), why 
should they waste time doing a one-off version of all this work if there aren't 
enough standards written for it to interoperate?  Besides, DIGEST without TLS 
is now so weak in a 10-cents-per-windows-zombie-CPU-week world that I question 
the value of doing any of this work just for DIGEST.

                - Chris

Received on Friday, 15 June 2007 21:58:48 UTC