RFC2616 vs RFC2617, was: Straw-man charter for http-bis

Julian Reschke <julian.reschke@gmx.de> Thu, 07 June 2007 16:01 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKQK-0003rE-Kh; Thu, 07 Jun 2007 12:01:20 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwKQI-0003qC-TT for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:01:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKQI-0003pY-IN for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:01:18 -0400
Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwKQH-0003ol-4s for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:01:18 -0400
Received: (qmail invoked by alias); 07 Jun 2007 16:01:16 -0000
Received: from p508F9544.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.149.68] by mail.gmx.net (mp004) with SMTP; 07 Jun 2007 18:01:16 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19wGag3G+9wUYPLmty4wgheyNHkxepdWhABOD3XBQ s3vpY2BNUySCY6
Message-ID: <46682BC9.9050504@gmx.de>
Date: Thu, 07 Jun 2007 18:01:13 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Paul Hoffman <phoffman@imc.org>
Subject: RFC2616 vs RFC2617, was: Straw-man charter for http-bis
References: <BA772834-227A-4C1B-9534-070C50DF05B3@mnot.net> <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <p06240871c28dd59e7371@[10.20.30.108]>
In-Reply-To: <p06240871c28dd59e7371@[10.20.30.108]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: Apps Discuss <discuss@apps.ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Paul Hoffman wrote:
> 
> At 3:42 PM -0700 6/6/07, Chris Newman wrote:
>> 1. HTTP Digest Authentication
>>
>> The SASL WG appears to have decided that SASL DIGEST-MD5 is not a 
>> useful authentication mechanism for a number of technical reasons. I 
>> would be uncomfortable having a WG spend a lot of time refining the 
>> existing HTTP Digest mechanism based on that experience. However, 
>> documenting the i18n behavior of deployed implementations sounds like 
>> a sensible thing to do.
> 
> It seems weird to do significant clarification work on 2616 and 
> basically ignore 2617, given the normative reference to the latter. A 
> better option would be to do full clarifications in 2617, including a 
> discussion of the not-clarifiable internationalization issues. One such 
> clarification is a list of the problems of HTTP Digest in the modern world.
> 
> This probably should not take "a lot of time"; if it does, it means that 
> the clarifications are all the more valuable. HTTP implementers who see 
> a lot of work in 2616bis and nothing in 2617 will not necessarily come 
> to the conclusion that the IETF wants; it would be better to have a 
> 2617bis that says what we want to say.
> ...

Hi,

maybe things become clearer if we consider re-organizing the security stuff?

Currently,

- RFC2616 refers (normatively?) to RFC2617 for authentication, and

- RFC2617 defines a framework (Section 1.2) and two schemes (Basic and 
Digest).

Assuming that there's no immediate need to change the framework defines 
in RCF2617, Section 1.2, wouldn't it make sense to:

- Move the authentication framework itself into RFC2616bis, and

- to then publish stand-alone documents upgrading/fixing both Basic and 
Digest?

The benefits being:

- RFC2616bis doesn't have the dependency on its sister spec anymore, 
which suffers from Basic and Digest problems, and

- Basic, Digest and new schemes could evolve independently.

Best regards, Julian