Subject: [http-auth] Digest Encoding

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 4 Jul 2013 10:42:49 -0400

All,

Based on the discussion on the mailing list it seems that people wanted to
discuss the encoding issue in a separate *experimental* draft. So, I have
just submitted the following draft:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding/

The draft defines a new parameter and two possible mechanisms. The
parameter and one of the mechanisms are identical to what was defined
in draft-ietf-httpauth-basicauth-enc.
The second mechanism take advantage of the fact that with Digest the user
agent has the ability to respond to the server with the encoding it
supports, which is not possible with the Basic scheme.

I would appreciate any feedback on this draft.

Regards,
 Rifaat

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 04 Jul 2013 16:49:36 +0200

>supports, which is not possible with the Basic scheme.

Could you clarify what purpose this is intended to serve? There is no
interest in supporting character encodings other than UTF-8.
-- 
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: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 4 Jul 2013 11:30:14 -0400

The purpose of this draft is to address the encoding issue for the *Digest*
scheme, as draft-ietf-httpauth-basicauth-enc addresses only the Basic
scheme.
The draft has two possible mechanisms, one of them is exactly what you are
alluding to, which is to use UTF-8, similar to the Basic mechanism.

The other approach is more involved and allows for more flexibility of
supporting more than just UTF-8. I wanted to get feedback from the
community if this is needed for the Digest mechanism; if that is not needed
then we can definitely remove the second approach.

Regards,
 Rifaat

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Jul 2013 19:51:57 +0200

On 2013-07-04 17:30, Rifaat Shekh-Yusef wrote:
> The purpose of this draft is to address the encoding issue for the
> *Digest* scheme, as draft-ietf-httpauth-basicauth-enc addresses only the
> Basic scheme.
> The draft has two possible mechanisms, one of them is exactly what you
> are alluding to, which is to use UTF-8, similar to the Basic mechanism.
>
> community if this is needed for the Digest mechanism; if that is not
> needed then we can definitely remove the second approach.
>
> Regards,
>   Rifaat

I would strongly suggest to avoid any complexity that isn't needed.

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 4 Jul 2013 15:20:01 -0400

Hi Julian,

There are two main differences between the Server Indicated Encoding
mechanism and the Negotiated Encoding mechanism:
1. The Negotiated Encoding mechanism does not specify any required encoding
in the current version of the draft; we could change that and specify UTF-8
as the default encoding.
2. The Negotiated Encoding mechanism asks the browser to provide an
indication back to the server. That indication from the browser would allow
the server to decline the request immediately without any
further processing if the client does not support the encoding indicated by
the server. Existing servers will not get the indication because the
browser is expected to send it only if it received the parameter from the
server.

What is the complexity you see with this?

Regards,
 Rifaat

On Thu, Jul 4, 2013 at 1:51 PM, Julian Reschke <[email-masked]>wrote:

>> *Digest* scheme, as draft-ietf-httpauth-basicauth-**enc addresses only
>> the
>> Basic scheme.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Jul 2013 22:41:54 +0200

On 2013-07-04 21:20, Rifaat Shekh-Yusef wrote:
> 1. The Negotiated Encoding mechanism does not specify any required
> encoding in the current version of the draft; we could change that and
> specify UTF-8 as the default encoding.

You can't make it the default unless it's the default already, or all 
UAs are willing to switch.

> indication back to the server. That indication from the browser would
> allow the server to decline the request immediately without any
> further processing if the client does not support the encoding indicated
> by the server. Existing servers will not get the indication because the
> browser is expected to send it only if it received the parameter from
> the server.
>

Having the indication -> good. Allowing anything except UTF-8 -> not needed.

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Jul 2013 19:11:50 -0700

> Having the indication -> good. Allowing anything except UTF-8 -> not needed.

+1

--Paul Hoffman

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 05 Jul 2013 13:44:09 +0900

I agree with Björn. Please make it UTF-8 only, and save everybody some 
pain. In this day and age, that's the only reasonable solution.

Regards,   Martin.

On 2013/07/05 0:30, Rifaat Shekh-Yusef wrote:
> On Thu, Jul 4, 2013 at 10:49 AM, Bjoern Hoehrmann<[email-masked]>  wrote:
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 05 Jul 2013 06:03:44 -0600

On 7/4/13 10:44 PM, "Martin J. Dürst" wrote:
> I agree with Björn. Please make it UTF-8 only, and save everybody
> some pain. In this day and age, that's the only reasonable
> solution.

+1

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 5 Jul 2013 09:12:28 -0400

Thank you all for your feedback.
I have just submitted a new version of the draft that hopefully addresses
all the comments I received so far.
http://www.ietf.org/id/draft-ietf-httpauth-digest-encoding-01.txt

Please, take a look and let me know if you have any more comments.

Regards,
 Rifaat

On Fri, Jul 5, 2013 at 8:03 AM, Peter Saint-Andre <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJR1rYgAAoJEOoGpJErxa2pGoQP/22I33drVYj6FNhvt0S8GW0w
> n9dN1viiYkhB3KSs0/H5dUH+wajXi5jkJDBNxdBysnhs3LWZk8RpZxuHHABA7Aip
> TRYLL9OJYAp2GHpat80mMSJ205WCYbSe3GzIC5g7l1Hu8lAOhzvQ+xm9VRQ0EG4S
> GHtwc5a+W7Qpc24lA9QzEfQHKIuqAUgPs8NxSeuXv3L8l7j+fWDdVwzj+oKx2nI+
> 3zKQTkxgpVB7h13yvlAkh2n14Iz0bAJVSdoMedZMTLhFjcN/BbrMNNXleA9KPOma
> hYd7N1JWVbDUSbxDARNMa4b3HB3m3cB57lJ8ShU2o+ookzCwIIDEYvqxIiTDv0L+
> aEcvZjXnuR1J/H2PP9zujrQ3QHPwIQPiJGrudeIRyoC8y1UnEMZIb1NT9AX/JeNh
> pBTloA06SjTi8mahPT8zvulIvmf1jQInORdPuCHbmZKFjX4TyQntMEl/zOLN3Qof
> lZrhlEG0c75bnK8w0nB1kyCmOiPJPwDE///97cS7M8gyztpm/732WK1DvZBSUky3
> 5v01M7BWJBK5gneTXq7e6KgeowTsn4gTlRl0It6dzOwNwbPxD12rA617Ft1s6/+h
> SC+l3mZZ5gBhk1Bf9UthUYRT7vgL/rlRIzPGZK2jCqxGnd7fhWn3jNtDIm7uqTXN
> fP+3nkCPPu8ZZtIyC+nv
> =1lyE
> -----END PGP SIGNATURE-----
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 05 Jul 2013 09:46:12 -0600

On 7/5/13 7:12 AM, Rifaat Shekh-Yusef wrote:
> Thank you all for your feedback. I have just submitted a new
> version of the draft that hopefully addresses all the comments I
> received so far.

I suggest a bit more care in defining the scope.

OLD

   RFC2617 does not define how to treat non-ASCII characters with the
   "Digest" scheme. This document defines an extension to the "Digest"
   scheme, and a mechanism that would allow the client and server to
   negotiate the proper character encoding support.

NEW

   RFC2617 does not define how to treat Unicode characters [UNICODE]
   outside the ASCII range [RFC20] with the "Digest" scheme.  This
   document defines an extension to the "Digest" scheme, and a
   mechanism that enables the client and server to negotiate their
   support for the UTF-8 [RFC3629] character encoding scheme.

I'd also cite RFC 6365 in the Terminology section, such as:

   Several terms used in this document are defined in [RFC6365] and
   [UNICODE].

Then you'd need to add references to RFC 20, RFC 3629, RFC 6365, and
the Unicode specification.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 5 Jul 2013 13:14:25 -0400

Thanks Peter,

I like your proposed changes and will incorporate them in the next version
of the draft.

Regards,
 Rifaat

On Fri, Jul 5, 2013 at 11:46 AM, Peter Saint-Andre <[email-masked]>wrote:

> iQIcBAEBAgAGBQJR1upEAAoJEOoGpJErxa2pPqsP/iX4Cw5vqoK0BHXwzPP4pyvk
> b9P0FAtgJbfvfmzyX095BlDy9U+oloJiBIP9pthTdbldU7FR5U23SLSZMZ1mPR0H
> PElMn8uB4/KUSzCXnb9o26u3IcQvbHhY4T+My0ejJmNg6oF/bQZHIYBmLfp0tnT8
> G47gDasM6di1wRRb6NaS8HxjTyS1JuSB7hT26NbQmOgSfP5N7hQ2PyK0EPcjjGjp
> JbzMmB3WzeqoZ4esxD7RSswu0yUJ/A/H43yukxt7Ddtgrc9GtX/cv488UQD2l1Gc
> UOOnD4L74DIJEUtVPNvbr0Awpw8VXJpsX7w3sDOEVW/6bfJait6DLWnwpH/U4yFY
> WiUxz2NtwmOYmvGa4uR7iEA1+NhCS7LfPR/yoYQcdzoVVgPZ8UzvwaFOpmbnAq7D
> WLdmAWykm715yH6nPW0+bwQ0qBeTeaygk/AVgHzFrznw1w+fsB56wYrR2iN4Kvp2
> 2asKHoCcfAvfrOXqZSe1QddGKdqnajXIvdh0wAWNTKHMvTxUEjnpEr+ftFF+llj9
> RdRtLC0RTYivf+gxa3tML6Loothac1Q5l1XJswMKi/uhnI3Qg3LIG4sJSdXz4veo
> Qyvk9SslgLgf8xGiUvUZGLjG3BB2GDnAJrCTXNAVA4fPTiDqTsKSGBZ7Yv8EMdl2
> JYfQGvW0Jb7SXWIv+aEt
> =ODrA

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 7 Jul 2013 09:16:50 -0400

I have just submitted a new version that incorporates the feedback I got so
far, and added an acknowledgments section.
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding/

Please, let me know if you have any further comments.

Regards,
 Rifaat