Re: [http-auth] New Version Notification - draft-ietf-httpauth-basicauth-update-06.txt

[Tony Hansen <[e-mail]>]

On 2/13/15 4:29 AM, Kathleen Moriarty wrote:
> Thank you, Julian.
>
> On Fri, Feb 13, 2015 at 2:58 AM, Julian Reschke <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 2015-02-12 23:15, [e-mail]
>     <mailto:[e-mail]> wrote:
>
>
>         A new version (-06) has been submitted for
>         draft-ietf-httpauth-basicauth-update:
>         http://www.ietf.org/internet-drafts/draft-ietf-httpauth-basicauth-update-06.txt
>         ...
>
>
>     This draft addresses most of the feedback received so far; I
>     posted it so the the IESG doesn't have to re-report things.
>

I read the document afresh from the beginning to the end. I consider it 
ready for publication.

Minor nits below. None are showstoppers.

     Tony Hansen

section 2 (add the before user-id, to parallel "the password"):

< constructs the user-pass by concatenating user-id, a single colon
< (":") character, and the password,
--
 > constructs the user-pass by concatenating the user-id, a single colon
 > (":") character, and the password,

section 2.1 (change comma to semi-colon):

<      Note: The 'charset' is only defined on challenges, as "Basic" uses
<      a single token for credentials ('token68' syntax), thus the
<      credentials syntax isn't extensible.
--
 >      Note: The 'charset' is only defined on challenges, as "Basic" uses
 >      a single token for credentials ('token68' syntax); thus the
 >      credentials syntax isn't extensible.

Section 3 (add "a revision to"):

<   The "realm" parameter carries data that can be considered textual,
<   however [RFC7235] does not define a way to reliably transport non-US-
<   ASCII characters.  This is a known issue that would need to be
<   addressed in that specification.
--
 >   The "realm" parameter carries data that can be considered textual,
 >   however [RFC7235] does not define a way to reliably transport non-US-
 >   ASCII characters.  This is a known issue that would need to be
 >   addressed in a revision to that specification.

Section 4 (add "other" to better clarify the use of "those sites"):

<   The owner or administrator of such a
<   system could therefore expose all users of the system to the risk of
<   unauthorized access to all those sites if this information is not
<   maintained in a secure fashion.
--
 >   The owner or administrator of such a
 >   system could therefore expose all users of the system to the risk of
 >   unauthorized access to all those other sites if this information is not
 >   maintained in a secure fashion.

Section 4 (we'll soon have more than just Digest, so how about ...):

<  This type of attack is not possible with Digest
<   Authentication.
--
 >  This type of attack is not possible with other authentication 
schemes, such as Digest
 >   Authentication.
or
 >  This type of attack is not possible with Digest
 >   Authentication, or other authentication schemes that do not send 
the credentials
 >   directly.

Section 6 (verb usage):

<   The internationalization problem with respect to the character
<   encoding scheme used for user-pass has been reported as a Mozilla bug
<   back in the year 2000 (see
--
 >   The internationalization problem with respect to the character
 >   encoding scheme used for user-pass was reported as a Mozilla bug
 >   back in the year 2000 (see

Section B.3 ("what" -> "which"):


<   Note that sites might even inspect the User-Agent header field
<   ([RFC7231], Section 5.5.3) to decide what character encoding scheme
<   to expect from the client.
--
 >   Note that sites might even inspect the User-Agent header field
 >   ([RFC7231], Section 5.5.3) to decide which character encoding scheme
 >   to expect from the client.