Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-10.txt

From: [email-masked]
Date: Sat, 10 Jan 2015 11:42:14 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

        Title           : HTTP Digest Access Authentication
        Authors         : Rifaat Shekh-Yusef
                          David Ahrens
                          Sophie Bremer
	Filename        : draft-ietf-httpauth-digest-10.txt
	Pages           : 30
	Date            : 2015-01-10

Abstract:
   HTTP provides a simple challenge-response authentication mechanism
   that may be used by a server to challenge a client request and by a
   client to provide authentication information.  This document defines
   the HTTP Digest Authentication scheme that can be used with the HTTP
   authentication mechanism.

Editorial Note (To be removed by RFC Editor before publication)

   Discussion of this draft takes place on the HTTPAuth working group
   mailing list ([email-masked]), which is archived at [1].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 10 Jan 2015 14:45:20 -0500

Hi,

We think that with version -10 we have addressed all the comments we
received so far.
Please, take a look and let us know if we missed anything or if you have
any further comments.

Thanks,
 Rifaat

On Sat, Jan 10, 2015 at 2:42 PM, <[email-masked]> wrote:

>  This draft is a work item of the Hypertext Transfer Protocol
> Authentication Working Group of the IETF.
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 11 Jan 2015 15:08:20 +0100

> Please, take a look and let us know if we missed anything or if you have

I will review once the HTTP/2 Last Calls are over next week (hint, hint).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jan 2015 17:42:09 +0100

On 2015-01-10 20:45, Rifaat Shekh-Yusef wrote:
> ...

I had a quick glance at the I18N related stuff, and it still doesn't work.

Section 3.1:

    Some or all of the parameters used in the various headers fields used
    by this document can be sent using the [RFC5987] encoding.

That's not really helpful. You really need to state which.

Section 3.9.2:

    The following example assumes that an access protected document is
    being requested from the server via a GET request.  The URI for the
    request is "http://api.example.org/doe.json".  Both client and server
    know the userhash of the username, support the UTF-8 character
    encoding scheme, and use the SHA-512-256 algorithm.  The username for
    the request is "Jaesoen Doe" and the password is "Secret, or not?".
    The following example assumes that an access protected document is
    being requested from the server via a GET request.  The URI for the
    request is "http://api.example.org/doe.json".  Both client and server
    know the userhash of the username, support the UTF-8 character
    encoding scheme, and use the SHA-512-256 algorithm.  The username for
    the request is "Jaesoen Doe" and the password is "Secret, or not?".

The intent was to use a user name containing non-ASCII characters, but 
that was helpfully (:-) converted away by xml2rfc. Non-ASCII examples in 
IETF docs are currently hard. See 
<http://greenbytes.de/tech/webdav/draft-ietf-httpauth-basicauth-update-latest.html#charset> 
for an example how to workaround that limitation.

Section 4:

    The only allowed value is "UTF-8", to be matched case-insensitively
    (see [RFC2978], Section 2.3).  It indicates that the server expects
    user name and password to be converted to Unicode Normalization Form
    C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
    using the UTF-8 character encoding scheme ([RFC3629]), ), and percent
    escaped in extended notation ([RFC5987]).

I don't believe RFC 5987 applies here at all; but maybe I'm missing 
something.

Best regards, Julian

---

From: Sophie Bremer <[email-masked]>
Date: Thu, 15 Jan 2015 18:58:12 +0100

Hello,

> Am 15.01.2015 um 17:42 schrieb Julian Reschke <[email-masked]>:
> 

Do you expect something like "... fields used by this document can be sent using the extended notation of [RFC5987]." ?

> The intent was to use a user name containing non-ASCII characters, but that was helpfully (:-) converted away by xml2rfc. Non-ASCII examples in IETF docs are currently hard. See <http://greenbytes.de/tech/webdav/draft-ietf-httpauth-basicauth-update-latest.html#charset> for an example how to workaround that limitation.

Thank you, we will change this.

> I don't believe RFC 5987 applies here at all; but maybe I'm missing something.

I don't unterstand you point. RFC 5987 describes a way (extended notation) of writing values with any possible charset.

Regards,
Sophie

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jan 2015 19:12:19 +0100

> Do you expect something like "... fields used by this document can be sent using the extended notation of [RFC5987]." ?

I'd expect an enumeration, and that enumeration to be restricted to 
those fields that actually need I18N.

> I don't unterstand you point. RFC 5987 describes a way (extended notation) of writing values with any possible charset.

My understanding was that the charset parameter was about how things are 
encoded into octets before Digest computations happen. Isn't that the case?

Best regards, Julian