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

"Roy T. Fielding" <> Thu, 19 February 2015 23:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BCA751A1A27; Thu, 19 Feb 2015 15:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fjmp8kSFZAFe; Thu, 19 Feb 2015 15:13:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 96E461A00E2; Thu, 19 Feb 2015 15:13:06 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 767C69405E; Thu, 19 Feb 2015 15:13:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=De908Y4L1m5lzlz5I6sJ/1n8C6U=; b=zaj6r6QpUW9P3LZkZSWwvIG6d7Pd C8QMvIft5ugJ0+IgqGpF19WP+7n/tFE0jDgWNgOZxlFD3efWNrqH72tXZGdBkCkK qxKaQXuztHK1XcdxL7qSvDHsDp8giL07Ui4AXQUMjfuXxUOASwn3MKT+L2PIh3Z6 tmeLm6DfmIFMsDY=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 461BA9405C; Thu, 19 Feb 2015 15:13:06 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Thu, 19 Feb 2015 15:12:50 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Bjoern Hoehrmann <>
X-Mailer: Apple Mail (2.1283)
Archived-At: <>
Cc: Julian Reschke <>, Pete Resnick <>,, " Auth" <>, 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:13:07 -0000

On Feb 19, 2015, at 3:07 PM, Bjoern Hoehrmann wrote:

> * 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.

+1  (FYI, Apache httpd does exactly that.)