Re: [http-auth] Barry Leiba's Yes on draft-ietf-httpauth-scram-auth-14: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Barry,
Thank you for your comments.

On 16/12/2015 05:00, Barry Leiba wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> -- Section 3 --
>
>     It sends
>     the username to the server, which retrieves the corresponding
>     authentication information, i.e. a salt, StoredKey, ServerKey and the
>     iteration count i.
>
> As this is written, it's not clear whether the "corresponding
> authentication information" is "a salt" alone, or the whole list of
> things after.  I suggest this:
>
> NEW
>     It sends
>     the username to the server, which retrieves the corresponding
>     authentication information: a salt, a StoredKey, a ServerKey,
>     and an iteration count (i).
> END
Done, thank you.
> Why does the paragraph end in a colon ("and sends a ClientProof to the
> server:")?
>
>     To begin with, the SCRAM client is in possession of a username and
>     password (*) (or a ClientKey/ServerKey, or SaltedPassword).
>
> ...and...
>
>     (*) - Note that both the username and the password MUST be encoded in
>     UTF-8 [RFC3629].
>
> I suggest that splitting these up with a bunch of text in between isn't a
> good way to do it.  I think this would be better:
>
> NEW
>     To begin with, the SCRAM client is in possession of a username and
>     password, both encoded in UTF-8 [RFC3629] (or a ClientKey/ServerKey,
>     or SaltedPassword).
> END
Yes, this is better.
> There's no pressing need to use the word "MUST" there.
>
>     Informative Note: Implementors are encouraged to create test cases
>     that use both username passwords with non-ASCII codepoints.  In
>     particular, it is useful to test codepoints whose "Unicode
>     Normalization Form C" and "Unicode Normalization Form KC" are
>     different.
>
> It would be good to include an informative reference to the Unicode
> Normalization Forms document here, so people can easily look up what NFC
> and NFKC are.  It might also be good to say "Normalization Form Canonical
> Composition (NFC)" and "Normalization Form Compatibility Composition
> (NFKC)", rather than to use the mixed versions that you have here.
Ok
> -- Section 4 --
>
>     from the IANA "Hash Function Textual Names" registry (see
>     http://www.iana.org) .
>
> Better, I think, to use the direct URL for the registry (which is fine
> with IANA):
> http://www.iana.org/assignments/hash-function-text-names/
Ok.