Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (with COMMENT)

Bjoern Hoehrmann <> Thu, 19 February 2015 23:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B82B01A0398; Thu, 19 Feb 2015 15:07:55 -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 VWG812T0lZOG; Thu, 19 Feb 2015 15:07:53 -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 2ED9C1A0371; Thu, 19 Feb 2015 15:07:53 -0800 (PST)
Received: from netb ([]) by (mrgmx102) with ESMTPSA (Nemesis) id 0MQMBU-1XzAUv1myi-00TnyN; Fri, 20 Feb 2015 00:07:48 +0100
From: Bjoern Hoehrmann <>
To: Julian Reschke <>
Date: Fri, 20 Feb 2015 00:07:45 +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:wbZxUqCUNxW0Q8/kM25/FlO8qI/a6qHxc6eXjHQKH2uR6YqiE2t sG53RsQ3Zt4Itxr5r3rdiZDPy/bn41J78odppO8Xt689yVOyJvu8Zyu+iyZ3F4I4beacauo vW2Tmw1PF2GOmefu6MLx2EoOh0ipbLK+Blk7WB9PoszuZ9o8icAlh2MLYMwXcO04BKDYfTs NjtopK9fIBLg+LZd3UEgQ==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <>
Cc: Julian Reschke <>, Pete Resnick <>,, "" <>, The IESG <>, Barry Leiba <>,
Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Feb 2015 23:07:55 -0000

* Julian Reschke wrote:
>On 2015-02-19 23:33, Bjoern Hoehrmann wrote:
>> The current text is:
>>     Furthermore, a user-id containing a colon character is invalid, as
>>     recipients will split the user-pass at the first occurrence of a
>>     colon character.  Note that many user agents however will accept a
>>     colon in user-id, thereby producing a user-pass string that
>>     recipients will likely treat in a way not intended by the user.
>> So if the password contains a colon, and the draft requires support for
>> that, then what? Are recipients REQUIRED to split the string at the 1st
>> colon? If so, then I think the current text is not adequate. If not,
>> then it seems wrong to require support for colons in passwords.
>I think they are required to split on the first colon; why do you think 
>the current text is inadequate?

It should be something like

  The first colon in a user-pass string separates username and password
  from one another; text after the first colon is part of the password.
  Usernames containing colons cannot be encoded in user-pass strings.
  Note that many user agents produce user-pass strings without checking
  that usernames supplied by users do not contain colons; recipients
  will then treat part of the username input as part of the password.

This would actually define the correct interpretation of the first colon
rather than hinting at what recipients will do, avoid the "will likely"
speculation, and makes it more clear that colons in usernames are not an
option offered by the protocol that then needs to be restricted by a
MUST NOT for interoperability reasons, as far as I am concerned. It is
also more clear that "user agents accept colons" is an UI issue; with
the text in the draft `user-id` is used for both "string entered into
username form field" and "value in Authorization header" which can be
quite different due to colons.
Björn Höhrmann · ·
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 ·
 Available for hire in Berlin (early 2015)  ·