Re: [http-auth] Last Call: <draft-ietf-httpauth-basicauth-update-05.txt> (The 'Basic' HTTP Authentication Scheme) to Proposed Standard

Bjoern Hoehrmann <> Fri, 06 February 2015 07:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ACEEB1A1A4B; Thu, 5 Feb 2015 23:58:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iWizcNACli-c; Thu, 5 Feb 2015 23:58:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4CEF1A017C; Thu, 5 Feb 2015 23:58:40 -0800 (PST)
Received: from netb ([]) by (mrgmx101) with ESMTPSA (Nemesis) id 0M0tr1-1XUqXL0mw3-00v88Y; Fri, 06 Feb 2015 08:58:39 +0100
From: Bjoern Hoehrmann <>
To: Julian Reschke <>
Subject: Re: [http-auth] Last Call: <draft-ietf-httpauth-basicauth-update-05.txt> (The 'Basic' HTTP Authentication Scheme) to Proposed Standard
Date: Fri, 06 Feb 2015 08:58:37 +0100
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:DBmHZBLJJxMyzyfibu1ex7RZKbumZzq7VDqNUWEzYZGRlliXVY0 6v57+eSE7KuqwIfjJJOc11G5sQuh4UyDVItStwZM7J4q5k0O6TSTKeEIttNkgaIsKvStt0W welIkbbmXK+5YEDzPF9atmUXhWRnsE1SCrfPZ1pIxXi7hqd3kuy+iLIWeWO58jr6yMg+hpL HGPVIiUKh8R7GMl+IOZ4w==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Feb 2015 07:58:42 -0000

* Julian Reschke wrote:
>On 2015-02-05 23:49, Bjoern Hoehrmann wrote:
>> * The IESG wrote:
>>> Abstract
>>>    This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
>>>    Authentication Scheme, which transmits credentials as userid/password
>>>    pairs, obfuscated by the use of Base64 encoding.
>> I do not think the use of Base64 is intended as obfuscation and it seems
>> misleading to me to describe it as such. (The Introduction has the same
>> problem).
>I think it was.

I would take it to mean, in this context, "make difficult to decode",
while it's more likely used to "deal with special characters". In any
case, if the idea is to note that Base64 is easily reversible, say that
instead of "obfuscated".

>> In the Introduction:
>>     The "Basic" scheme previously was defined in Section 2 of [RFC2617].
>>     This document updates the definition, and also addresses
>>     internationalization issues by introducing the "charset"
>>     authentication parameter (Section 2.1).
>> I think "updates" is the wrong word considering the document is intended
>> to "obsolete" RFC 2617.
>It does update the definition, no? Also: "Other documents updating RFC 
>2617 are "Hypertext Transfer Protocol (HTTP/1.1): Authentication" 
>([RFC7235], defining the authentication framework) and "HTTP Digest 
>Access Authentication" ([DIGEST], updating the definition of the 
>'"Digest" authentication scheme). Taken together, these three documents 
>obsolete RFC 2617."

A better word would be "replaces".

>That is true.
>>     The original definition of this authentication scheme failed to
>>     specify the character encoding scheme used to convert the user-pass
>>     into an octet sequence.
>> I think it would be more appropriate to say that it did not do so. That
>> wasn't a particular "failure", sending unlabeled 8bit (and 7bit) content
>> was normal at the time, in part because other system parts also did not
>> know or care about character encodings.
>It's a defect in that specification, no matter when it was written.

Regardless, I think "did not" would be better than "failed to".
Björn Höhrmann · ·
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 ·
 Available for hire in Berlin (early 2015)  ·