Date: Sat, 8 Sep 2018 13:29:10 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: alexey.melnikov@isode.com, ekr@rtfm.com, ynir.ietf@gmail.com,
 rifaat.ietf@gmail.com, poccil14@gmail.com, http-auth@ietf.org
Message-ID: <20180908182910.GR73164@kduck.kaduk.org>
References: <20180908135146.08ECDB82672@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180908135146.08ECDB82672@rfc-editor.org>
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/0d7uFsdqb-Yo5Ob2wJGEx8u4LiE>
Subject: Re: [http-auth] [Technical Errata Reported] RFC7804 (5496)
Precedence: list

I'd like to hear from Alexey before I do anything to this, but
this seems correct on first look.

-Ben

On Sat, Sep 08, 2018 at 06:51:46AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7804,
> "Salted Challenge Response HTTP Authentication Mechanism".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5496
> 
> --------------------------------------
> Type: Technical
> Reported by: Peter Occil <poccil14@gmail.com>
> 
> Section: 2.2
> 
> Original Text
> -------------
>    o  Normalize(str): Apply the Preparation and Enforcement steps
>       according to the OpaqueString profile (see [RFC7613]) to a UTF-8
>       [RFC3629] encoded "str".  The resulting string is also in UTF-8.
>       Note that implementations MUST either implement OpaqueString
>       profile operations from [RFC7613] or disallow the use of non
>       US-ASCII Unicode codepoints in "str".  The latter is a particular
>       case of compliance with [RFC7613].
> 
> 
> Corrected Text
> --------------
>    o  Normalize(str): Apply the Preparation and Enforcement steps
>       according to the OpaqueString profile (see [RFC7613]) to a UTF-8
>       [RFC3629] encoded "str".  The resulting string is also in UTF-8.
>       Note that implementations MUST either implement OpaqueString
>       profile operations from [RFC7613] or disallow the use of Unicode 
>       codepoints not ranging from U+0020 to U+007E in "str".  The latter
>       is a particular case of compliance with [RFC7613].
> 
> 
> Notes
> -----
> Control code points (including the ASCII controls U+0000 to U+001F as well as U+007F) are disallowed in the PRECIS FreeformClass, which the OpaqueString profile uses.  Thus it's not enough to just disallow non-US-ASCII codepoints (rather than implement the full OpaqueString profile) to comply with a subset of the OpaqueString profile.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC7804 (draft-ietf-httpauth-scram-auth-15)
> --------------------------------------
> Title               : Salted Challenge Response HTTP Authentication Mechanism
> Publication Date    : March 2016
> Author(s)           : A. Melnikov
> Category            : EXPERIMENTAL
> Source              : Hypertext Transfer Protocol Authentication
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG