Subject: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt

From: Julian Reschke <[email-masked]>
Date: Sun, 29 Jan 2012 16:38:02 +0100

Hi there,

I just submitted a new revision of d draft-reschke-basicauth-enc - see 
below (HTML version at 
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-04.html>; 
this version also includes new hooks for providing feedback; please try!).

At this point, I'd like to solicit additional feedback before I proceed; 
in particular: should this potentially be an Applications Area WG 
deliverable?

With respect to intended status: in theory, this is a candidate for 
Experimental. However, Basic Authentication (as defined in RFC 2617) 
doesn't have a registry for extension parameters, so the cleanest 
approach appears to say "Updates 2617", which IMHO requires a standards 
track document.

Best regards, Julian

-------- Original Message --------
Subject: I-D Action: draft-reschke-basicauth-enc-04.txt
Date: Sun, 29 Jan 2012 07:28:40 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : An Encoding Parameter for HTTP Basic Authentication
	Author(s)       : Julian F. Reschke
	Filename        : draft-reschke-basicauth-enc-04.txt
	Pages           : 9
	Date            : 2012-01-29

    The "Basic" authentication scheme defined in RFC 2617 does not
    properly define how to treat non-ASCII characters.  This has lead to
    a situation where user agent implementations disagree, and servers
    make different assumptions based on the locales they are running in.
    There is little interoperability for characters in the ISO-8859-1
    character set, and even less interoperability for any characters
    beyond that.

    This document defines a backwards-compatible extension to "Basic",
    specifying the server's character encoding expectation, using a new
    authentication scheme parameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-basicauth-enc-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-reschke-basicauth-enc-04.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 30 Jan 2012 12:22:51 +1100

Quick comment on draft-reschke-basicauth-enc-04.txt "An Encoding Parameter for HTTP Basic Authentication":

The text about not including the 'encoding' parameter when sending the password is a bit confusing [section 3].

   For credentials sent by the user agent, the "encoding" parameter is
   reserved for future use and MUST NOT be sent.

   The reason for this is that the information that could be included
   does not seem to be useful to the server, but the additional
   complexity of parsing and processing the additional parameter might
   make this extension harder to deploy.

My guess is that the spec intended to say that including the encoding information *would* be useful, but it cannot be added easily. This is a good illustration of the 3rd dot point from "2.3.1 Considerations for new Authentication Schemes" [draft-ietf-httpbis-p7-auth-18#section-2.3.1]: "b64token ... can only be used once ... future extensions will be impossible".

My suggested replacement for these 2 paragraphs:

   Note: The 'encoding' parameter cannot be included when sending
   credentials (eg in the Authorization header) as the "Basic" scheme
   uses a single base64 token for that ('b64token' syntax), not a
   parameter list ('#auth-param' syntax)
   [draft-ietf-httpbis-p7-auth-18#section-2.1].

P.S. What are the odds that everyone treats the following lines as exactly equivalent to the example of encoding="UTF-8" as they are supposed to?
  encoding=UTF-8
  Encoding="utf\-8"

--
James Manger

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 30 Jan 2012 12:17:18 +0100

><http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-04.html>; 

Well, "There is little interoperability for characters in the ISO-8859-1
character set" the US-ASCII subset works reasonably well.

Don't repeat so much of / so literally the Abstract in the Introduction,
it's confusing to read the duplicate.

I think you should mention "WWW-Authenticate" earlier than section 4,
(something like "for use in headers like WWW-Authenticate" somewhere),
otherwise it's easy to expect this is for `Authorization` (in part due
to the name, `useUTF8` or `use-utf-8="yes" or some such would have been
clearer).

"For credentials sent by the user agent, the "encoding" parameter is
reserved for future use and MUST NOT be sent." You can only reserve
among options, and RFC 2617 does not allow `encoding` in credentials.
This should simply say it does not apply to credentials.

The following "The reason for this is" paragraph is confused, it should
probably be an editor's note to be removed later, otherwise you would
have to be much clearer what your idea for the parameter's content is,
the main use case would seem to be recognizing whether the client did
understand the request to use UTF-8, and that would seem useful enough.

>approach appears to say "Updates 2617", which IMHO requires a standards 

Updates 2617 sounds good to me; if there is any problem with that, we
could make two specifications, one that updates 2617 and establishes a
registry and then have your extension as experimental document.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jan 2012 14:31:20 +0100

> My guess is that the spec intended to say that including the encoding information *would* be useful, but it cannot be added easily. This is a good illustration of the 3rd dot point from "2.3.1 Cons…

Actually, this text was written long before we fixed the auth-param 
grammar in HTTPbis, and I just forgot about the outcome.

>     [draft-ietf-httpbis-p7-auth-18#section-2.1].

+1. Thanks for catching this!

> P.S. What are the odds that everyone treats the following lines as exactly equivalent to the example of encoding="UTF-8" as they are supposed to?

Dunno. Examples. Test cases. Etc.

My experience is that once you publish test cases and report on browser 
compliance, browsers actually get fixed. (And yes, sometimes this means 
fixing them myself :-)-

One alternative would be to special case this one (ugh!), or to change 
the defaults HTTP-wide (ugh!).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jan 2012 18:28:23 +0100

>> <http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-04.html>;

Hi Björn,

thanks for the feedback; see 
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html> 
for my work-in-progress.

> character set" the US-ASCII subset works reasonably well.

Noted and fixed.

> it's confusing to read the duplicate.

I like it that way :-)

> otherwise it's easy to expect this is for `Authorization` (in part due

Done.

> to the name, `useUTF8` or `use-utf-8="yes" or some such would have been

That's another good suggestion; we're not going to allow any other 
encoding, so maybe making it a real flag is the best solution. What do 
others think?

> This should simply say it does not apply to credentials.

That text is gone based on James' feedback.

> registry and then have your extension as experimental document.

Or we could revise RFC 2617's definition of "Basic" and move it into a 
separate document. Technically that would be the cleanest approach, but 
I fear that doing so would summon those who insist on a complete fix for 
all HTTP security issues.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 31 Jan 2012 02:39:28 +0100

>> it's confusing to read the duplicate.

I can understand it's annoying to phrase them differently, and while
Agent Smith might not be around the next corner, but "What, I just
read that" is very distracting nevertheless.

>all HTTP security issues.

Looking at the recent xml-dev thread on Basic, this seems indeed likely.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 31 Jan 2012 16:34:15 +0900

>> it's confusing to read the duplicate.

I'm definitely with Björn on this one. Reading the same text twice is 
really annoying. If this were the way it should be, there would be no 
need at all for both an abstract and an introduction.

> encoding, so maybe making it a real flag is the best solution. What do

I'm all in favor.

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Jan 2012 22:18:43 +0100

On 2012-01-31 08:34, "Martin J. Dürst" wrote:
> ...
> ...

(tracked at 
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.paramname>)

So

   WWW-Authenticate: Basic realm="foo", useUTF8

looks cute, but then there's

   auth-param     = token BWS "=" BWS ( token / quoted-string )

(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-18.html#rfc.section.2.1>)

So it needs a value. We could say

   useUTF8="yes"

but then there's always the problem of remembering whether the syntax is 
"0"/"1", "false"/"true" or "no"/"yes".

We also could say that the presence of the parameter is sufficient, such 
as with

   useUTF8=""

but then people will be confused when useUTF8="false" does the same 
thing as for "true".

So overall, I think it's better to stick to

   encoding="value"

and hard-wire the value to "UTF-8". (I'm open to renaming the parameter 
to "enc" or "charset")

Feedback on both points appreciated; in doubt, I'll leave things as they 
are now.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 1 Feb 2012 13:18:38 +1100

Seems reasonable. If this is where we're at WRT this draft, it suggests to me it's ready to go...

Cheers,

On 01/02/2012, at 8:18 AM, Julian Reschke wrote:

> (tracked at <http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-issues.html#issue.paramname>)
> 
> So
> 
> but then there's always the problem of remembering whether the syntax is "0"/"1", "false"/"true" or "no"/"yes".
> 
> We also could say that the presence of the parameter is sufficient, such as with
> 
>  useUTF8=""
> 
> but then people will be confused when useUTF8="false" does the same thing as for "true".
> 
> and hard-wire the value to "UTF-8". (I'm open to renaming the parameter to "enc" or "charset")
> 
> Feedback on both points appreciated; in doubt, I'll leave things as they are now.
> 
> Best regards, Julian
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 01 Feb 2012 03:45:44 +0100

>"0"/"1", "false"/"true" or "no"/"yes".

Well you need to know what the value should be in any case and since we
only have one valid value this particular problem does not really arise;
one could similarily argue that encoding=utf-8 is confusing because it
suggests other encodings can be used, or that it applies to the WWW-Au-
thenticate header (like the realm parameter if using non-ascii wasn't
deprecated, if I recall correctly). We could meet in the middle and use
something like `use=utf-8` or `options="utf-8"`. But whatever, not a big
issue.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/