[http-auth] Alexey Melnikov's No Record on draft-ietf-httpauth-mutual-10: (with COMMENT)
"Alexey Melnikov" <firstname.lastname@example.org> Wed, 02 November 2016 19:20 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0953B129801; Wed, 2 Nov 2016 12:20:47 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: "Alexey Melnikov" <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Date: Wed, 02 Nov 2016 12:20:46 -0700
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Subject: [http-auth] Alexey Melnikov's No Record on draft-ietf-httpauth-mutual-10: (with COMMENT)
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2016 19:20:47 -0000
Alexey Melnikov has entered the following ballot position for draft-ietf-httpauth-mutual-10: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I only reviewed sections 1-6, but I am sending my comments so far: In Section 1, next to the last paragraph: The Mutual authentication protocol proposed in this document is a strong cryptographic solution for password authentications. It mainly provides the two key features: Exactly the same paragraph appears earlier in the same section. Did you forget to delete this instance? 3.2. Values The parameter values contained in challenge/credentials MUST be parsed strictly conforming to the HTTP semantics (especially un- quoting of the string parameter values). In this protocol, those values are further categorized into the following value types: tokens (bare-token and extensive-token), string, integer, hex-fixed-number, and base64-fixed-number. For clarity, implementations are RECOMMENDED to use the canonical representations specified in the following subsections for sending values. Recipients SHOULD accept both quoted and unquoted representations interchangeably as specified in HTTP. I think the last SHOULD must be a MUST, because clients that generate these values might be using libraries that automatically quote values. So this is really not under sender's control. 3.2.2. Strings All character strings MUST be encoded to octet strings using the UTF-8 encoding [RFC3629] for the ISO 10646-1 character set [ISO.10646-1.1993]. This is the same as Unicode 1.1. Unicode now released version 9.0! I suggest you use a Unicode reference. In 3.2.3: The numbers represented as base64-fixed-number SHALL be generated as follows: first, the number is converted to a big-endian radix-256 binary representation as an octet string. The length of the representation is determined in the same way as mentioned above. Then, the string is encoded using the Base 64 encoding [RFC4648] I assume you meant Section 4 alphabet and not Section 5 alphabet from this RFC. Please add section reference to the above. without any spaces and newlines. Implementations decoding base64- fixed-number SHOULD reject any input data with invalid characters, excess/insufficient padding, or non-canonical pad bits (See Sections 3.1 to 3.5 of [RFC4648]).
- [http-auth] Alexey Melnikov's No Record on draft-… Alexey Melnikov