Re: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)

Yutaka OIWA <y.oiwa@aist.go.jp> Wed, 09 November 2016 07:18 UTC

Return-Path: <y.oiwa@aist.go.jp>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7347129451; Tue, 8 Nov 2016 23:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8FlWZ4ue7BD; Tue, 8 Nov 2016 23:18:48 -0800 (PST)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0065.outbound.protection.outlook.com [104.47.92.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484F9129430; Tue, 8 Nov 2016 23:18:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P5MVwDshv28YaxDClbqZJ9dtBMjUJgBOM3VD97yFTg4=; b=JUJJgsjlYIOB/OpTZ2fR0IW5iomY0nKvyOSbsxPoI5irNZnKihR5GCn67N2+1oCqFxeVyi1rPojJ89l0lF37bY9XUPi/AL/xvDZNASfxmoDa+M2oNHA0YD9hngBa1Jf/Oi9j6thOcmMrJXFCMnkpz+3zBzd+pNMs+kbJC+mnz2k=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=y.oiwa@aist.go.jp;
Received: from [150.29.149.113] (150.29.149.113) by TYXPR01MB0592.jpnprd01.prod.outlook.com (10.168.43.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Wed, 9 Nov 2016 07:18:43 +0000
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Alexey Melnikov <aamelnikov@fastmail.fm>
References: <147817486515.22851.10839561696168688036.idtracker@ietfa.amsl.com> <CAHbuEH6VfOOG3+nzAfje=TiNVpfC0Eqmxwnj6gO3bE1Q4oZ6oQ@mail.gmail.com>
From: Yutaka OIWA <y.oiwa@aist.go.jp>
Message-ID: <a539d222-6eac-555d-8e22-8320fabac5b8@aist.go.jp>
Date: Wed, 9 Nov 2016 16:18:41 +0900
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAHbuEH6VfOOG3+nzAfje=TiNVpfC0Eqmxwnj6gO3bE1Q4oZ6oQ@mail.gmail.com>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [150.29.149.113]
X-ClientProxiedBy: TYXPR0101CA0018.jpnprd01.prod.outlook.com (10.168.40.156) To TYXPR01MB0592.jpnprd01.prod.outlook.com (10.168.43.18)
X-MS-Office365-Filtering-Correlation-Id: 25aaf251-b56e-44bd-d211-08d40870a36b
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 2:zFHFky+by9N7EVnWo5JHI+fRJHNNxh1nUgqLMh7JHpIpnNSnac32GeQmVFzJIb3I7VQH+wDZZvDDvVGLQTmMZaJU76MuMDqUUgB9lfbD2KWOvKiatzncJxnCEiWmjw9rkM0UzRYLGtNgU5ys2t9FbaJ9XhSOPHLY8/hHaqrZxDB+dc197sP5j+yJB+vO+ukxxb3Rh2Sxv1GFh9dOzqZvMw==; 3:e3Uhb/x1H0+xROwBm6Xuy3Iidre/G4YkxjCZH8KoE6AIbneN2opmsakQvt+MMQk8VH0HCseW55heAKHkISYX/uHgp4yziiatIor+nP2vN+lrOAWW6gR/h/9EaWrpehTrHhOPtc17kUHldLZWSE989w==; 25:VzpdGroIjZyNdA8bwTV9OT5RKkLK0EOmDmZNPvWiNY9Jy4n5Y6QJ1gFOvb9+hM6M0buNBgiiDy/TlKa3ENKjRHJ5MaK79Eu71BeAv1V7NUMk7kD3MJsvjFpkrz5ZOWJpfVH03iMwUfeK947EkEfv+KZWvA29PBbEHtqD/HRoQ9xwa2lvlBAUBQc+CTkRxSH+1FYXUacxNJzuYVpUfOZmfNsjmsXI7/tjaUDIhzvxGiiR2lEnSmd/GcZFUGzhXXeCQ1OtcrT9CJPeclONVTpnZM4loNgHBaRKJrRlUoldTle3GPeiAcQRT+JZTwEjG0qXLe5ZJV37ff9h9BQRgx8VPnkgpX4mZv4Pd0kPLvWNU8eB0LLSC8i2wMDSkqWYZnMLJnW+cZfjVieN6OXUQGO+6PQ1u3jJTB1PUQMlEnUzS/YN2jgR7hUIwAJneAfy9A4E
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0592;
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 31:qc7xwyRdzAuHodpaO7IefXnNQfr1SjRTqoTCRkxEsHFfQ1aRmszHJLRL++luLtcvVlutGhjxCqAiEjMRwo9cUa1rwJiHNIly3gkbpu3qyZTZkcaOCGrAYcW1qtxxfrZXHzjdzfGEhYU8DrSLwo+urHt8x7ewZ8jhfYlOo7W7wqrw/9ukP5MpRxzEX+fdUzKtl4+iNyZwke+MwiiN52RLPYphTC2wsfe7R19J8QOLYKiqq/h6XuBuO2OPSMzVTY9DA0cUTSa+Wmxh33rSiXlVTg==; 20:N7RfjCQvr1/wGNIwa5lk/3PUE5TgqLyh9/Wa+n1dCr1ZvPxw/W86Q6mZ8WhSV0onFxSGdoDeFwgFaRiLCyliRe2w9T2iN8zsf/tq/tYKqT9CS1oWsTwK0AifcidrwFRfdeSp8DX8W3GoDlpVpeNhNchjUkQ47J5QMeoRyhBIB3Hc7PBz78n4vDogPMJ2Z9IGLf9JUS9ViAXGjjYE+vwYgqQ0oIK8VrnCD9NiXVocBqG7Awyu/kEOorEzjk51YUoocTSAQtNR6ltPTNLIU41Sxzt3QbqR/rLrybLVMTpI20X68ODJDrth8ScEN+mIv2e95YUxxmhHhZXPydXWkjVA65u/O7nm/pnAF+7H1UXSv2cm+pXuVRS6n4/ddBP3cNDgIbApJKeCr8cVxAxkSXEjn2kqnQnDVSL1OTMg7yMu/3PbZp0ALApp97WI0hSbYUbkW+6i4gP719tDSPYhb4igYKVZ9rQ7fz4AyLPM4RHvFpVlzEInWMi5q6WAQ/WtZZo/VDBjT1fwozg8QJ5Z8yd1VR1WeGU8/xMoRnhbX31dwePOUiK1Ht1t+rVWAKzKmwp0pfMhr07nzvMN28kdMTmOdhuB7WQs6m51XtDHG9G9Do8=
X-Microsoft-Antispam-PRVS: <TYXPR01MB059285BA9A0BD2E14CF18178A0B90@TYXPR01MB0592.jpnprd01.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(120809045254105)(166708455590820)(131327999870524);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:TYXPR01MB0592; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0592;
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 4:nwRbgLU0G2ZIhBcvz44inVwUnjaXXUcwDMQghAGR9OJ2V7b9vNLU+KgBL9F1Z/SWl5xZ4oGSqBGGE9AfgxRk4tiyPhGT/eAPkg/6wJHJuPJZBFvSY9D4m3dz1NT/nat7MVVEWBlcY9LpXFfz2IOcOT++SkV27KZD0gD6ps71vSGPpQYCiDBYKq5kQw9oXd0ASUnIZUqs0ly/kly7e5rphDs7A1uEpbWmPK61H5XG1WQsjs1jZSFjz+dxB+tk3+6eMeiDs0jJQQ4WamFBroKonkMIUMnHNow4ixR+x0/KF5XSNBbdWH6T3XTvLT6asBW9gM42f9YQxiRU2opJ4REhLOAohnTxshH6jFFeogtcVs7FtW3qPfPzVC3Ie90BQNxdyFgH1YUolonLcYHuQfFE9t0Q63Z+Ny9nQ4QcoLxmAtNPErZzbUdv0XuJJPmoUqkycUtCuv9C1G0jNtW4PhoPSj/fWmpMs+FTWbvoGLauBKQHyS24lC+aDlmUS9x5i7CNUalQ25q8zymB8+1zaooX3Mjmc98VXGyDDEu6j6GLfZo=
X-Forefront-PRVS: 0121F24F22
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(25584004)(377454003)(24454002)(199003)(45984002)(189002)(86362001)(4326007)(65956001)(83506001)(81156014)(77096005)(81166006)(8676002)(4001350100001)(65806001)(50466002)(36756003)(5001770100001)(230700001)(33646002)(2906002)(68736007)(97736004)(586003)(31696002)(92566002)(551544002)(66066001)(42186005)(50986999)(76176999)(54356999)(23736002)(8666005)(2950100002)(101416001)(106356001)(7736002)(64126003)(3846002)(5660300001)(6116002)(230783001)(65826007)(305945005)(189998001)(47776003)(120846001)(31686004)(42882006)(105586002)(74482002)(7846002)(7099028)(7059030)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:TYXPR01MB0592; H:[150.29.149.113]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-2022-jp?B?MTtUWVhQUjAxTUIwNTkyOzIzOmJMYzdlSVNxK2xBRStrVEhna0FvYVpP?= =?iso-2022-jp?B?WGhEMSsvVTRtSUVXdzQwYTlwZU5OeXVyWWxJT0ZEZWJuby9IWllnZ0R0?= =?iso-2022-jp?B?NWViWG9zRC9Fa0Rja1BTWk94VmpOODN4VU40OXZQTFdDSHZlTElFalBi?= =?iso-2022-jp?B?SFNDOGtkR1hPUGRma3ZnMllUcFU3bVBQdGZLeS9ZNWxkUnUvS1VNVVkr?= =?iso-2022-jp?B?VlBvQ3FvdUIySUVVTHBTcnlvV1h5Yi9QMHRSVXZWMzkvdmg0MXUvbjAy?= =?iso-2022-jp?B?aVdGbkNNZ2N6Qmx5TldEMWk2RWNwUXRJbkd2dEtwZCtoVUViZGxQSnpJ?= =?iso-2022-jp?B?ZWNpTFlVd3dockdZanRSQ2lnSEgvQURaVXFzUGlDUnJoS0xDbFFvZlN5?= =?iso-2022-jp?B?L3oyV2RLUFEzbWY2LyszZlpPSUY4dEcrNy9QT2R5MzRyRC9Yc0k2M3c2?= =?iso-2022-jp?B?Z2lWcVVCNXNUakdpVmZsVU9VZms2L0dZUTFudHVxZHpFVmx1cWM0YW9R?= =?iso-2022-jp?B?RGZoVHM3QkU5b0laOWo4L2VXQVRxcUxBVVEyU2lGN3ErWmJiT04zdDJn?= =?iso-2022-jp?B?RHRZT3E5eStsVHhKSUhKY2lOZWM2eEZzNkZvRk1KbHRKUjJZcGtvQUxO?= =?iso-2022-jp?B?WGNTREhkMkx4ZU8zVTdWWFl3NlErRVZnRG54UmRNVGVkd1VxbVVKZGdz?= =?iso-2022-jp?B?OStEMGVoMUgyQkw5UlkvRlk1TVZUR3V4clROZFg1aWZDTFBGNU5KblhG?= =?iso-2022-jp?B?WFFRSFNuZ1h0VDNFR082U3FHOUthemdUa1hpMElxWG11d2FXSERaYldz?= =?iso-2022-jp?B?QmNENFNYamN6M0tad0Q1SGF4R0lvQzBIOWM2UUZBVWFQR2I2VGhCb0Ev?= =?iso-2022-jp?B?K0UxVm1lcXJrejIvZTFXYkpSS3NwRCtvbmZmTlVkK3N0UnRPcVViVHFr?= =?iso-2022-jp?B?ZmpYYnFtQWJhNld3R3RRZVhkVnFxaG1SMHRKR2dDbkd5RHZnNEpZT081?= =?iso-2022-jp?B?bjA2N2hvODI2Yzk4Uk9GM3RpYXRiN0Nra2p3b1FUYVRRc2I3bXZhZzVs?= =?iso-2022-jp?B?RWxESDRaTXhDUnFzN0I2ajF1R1BSMk5OdUh2Nm1tUWF4Y291U1ZPSVlH?= =?iso-2022-jp?B?RitFb3JueERVeW9wOFlTYlRMQTJQRXBzNk1MRzEwOFlNU0gzNUVNMXhS?= =?iso-2022-jp?B?cTJ0YiswUk1qbWlKWlpBZGV5OWdEU3BqT1VRaVg2T04xVEwxbE5yTmh0?= =?iso-2022-jp?B?TjBxZm8yNWNPcVpldG5pb1FodFEwbUxVMFh1WU1XUjlmUG9JSzNZVmtD?= =?iso-2022-jp?B?dEx6TkZpYXkweU5CV29zQUc1c1hkbXNtNGtydHFUTXFWc2tRRGFMbDJ6?= =?iso-2022-jp?B?SGRhWlhCaFNJbDZ3YTBGam5WbUpCci9tdVJ3OFk5TWMyNDgrNXcwVmM1?= =?iso-2022-jp?B?dHFMVS81RWVaNFNpUVppeEJLQXBMSHJmNkRxZGVzN0dtQ0JsbGF6Uzdt?= =?iso-2022-jp?B?SktpUW9PT05CUS9uZTFwQW1FMVlIdk1Tem9HZlQ3ajR4OUxOZHNzKzJ4?= =?iso-2022-jp?B?SkhZOEJxa3ZYSktReGlCemx1bUUwK1JlQmNjVGxJbHZ6MUlOdENtYUtT?= =?iso-2022-jp?B?bFdTWkg4RlROeVA2TjljOGd3SGpDL3FDbXVFQVZjRG95dXlJY1JZM3ZQ?= =?iso-2022-jp?B?eDN4cElNWUhESzZVNFVWam51YTBWcGM2MVlMUSt5eFhTN1BBMjBMeHBy?= =?iso-2022-jp?B?RVlwOXY2TUdCMUNtcFUzWktOcDc2ajNuUkd3OVM0MGlrQlpaTHhKd0xS?= =?iso-2022-jp?B?UU5rcTJnd2tpdFdmNThTT0V1a0oyU1VGb0FRRGFSUWU3eEZJd2NLdFZL?= =?iso-2022-jp?B?bVBtSVRPT1JmNExmS0I1QzNVM1NYU3ZpeFEwbFNXTnlwbncrUWJPL3pN?= =?iso-2022-jp?B?RWJERW1iL0RTbmgxbVRLQy8xVk9wQXZKWE04RDU2eWV0UUdPZVZ4ajFs?= =?iso-2022-jp?B?SStyWVQvZHI0eHRCQ1dZOU0wcEF5YlRSQkdjT1pvR1oxZGQrNXN0UGJQ?= =?iso-2022-jp?B?ajJPTFJiQkNXSy9KQ0FtdG0wRUluVnFxZEYyN3ZhOXFNUko2bHNJVlZ2?= =?iso-2022-jp?B?cHlFcFVzcWNvbnFhb2pOUkdzT1pKTUxvVGtQMTZ6WjViUWV1L0NxZ0ts?= =?iso-2022-jp?B?Zz09?=
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 6:w494XZpHnmDzjwUCQSLdhUO5Zb/7l93PUreDz9DmuG4IcOmMEcC74CrTVnjzb9bquzunMGP+09/M12XdKbY3IGKGP59OSGWMynIncrfHA6mV5n8JTwmMnaQORZABlB06beECJvMXWTN259MFIES5j6uNejZy7RK1fJwdswbIevwLMZjN6WhQMYQLiBh26r5myJ8zmO7EDJID5Jj5nuBkCoBfv/HjMc9l4LR2SFLnycpfOmrzFoKRudTV1lOJT8bqV7G0e6VRoMd6ikVJ8IE4lnB9KGgjECMEv8b+j5kojvn3kOR3Fdma/V5Em6KTUs+2fU8QNv7GHnocRcvOJkgQIUbVs0mhf5gfOBxnOZ7KSQ0=; 5:ANMbSj3CZhJyvLegRGJC9XLJTAIQSzHEo4SO2jA6VQ0SskWJ1VIBRMB47FF1OYqohY5Opteuy8UKKTwmuTHpwADOcW74RRHTjC7sTH7OsqIGJrpX4qts7VCLYnCWVsEso5YB09EOyr6nsBD5iir/2A==; 24:AvZccw6CNo441JDoU1ifDH+vjLFsS5VD3jo8+urE3Ly9/GBq7qfKMhSsFfsErE9ULqt3ohabVVLSxDHcwFnNTv2C+wKEURY+TACJFdljRRA=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0592; 7:/P+Ko18pfaocZK+A0EN3ybGZtd2zLoYlF5nED6iPYHoLFerq0tOKSFkQn5SYI5TcxHPFJ9kloveDEpEu2zbdUPo6FaMhbbwi6vwypMyTk3buocjFY57NIrm8vUHsBSolET5Ceee9EmZsY96a4oqKtM/kPQzw3xGPJ5RuZtOAYIBnsRa1AnYc3PDmyvVMgHO1QrDBMqOKjK4us5hEEc2Y47XaJVI2nUzeAAE5R+tUQIhh3duDckUi5niRcaXq4WNZnMjz9yAgbXEdwHjh9lbyRyRVv9Hu9WBHC35yARSzGEzLKi4dMZY5tonZc7uyar9aOUn9Ex1BfJpf/LreV6uj0SIdKra8OyDYAYeI1UgMkK0=
X-OriginatorOrg: aist.go.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2016 07:18:43.6743 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0592
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/Bp2V92iosxWtVZhHiYCsnDueYBk>
Cc: draft-ietf-httpauth-mutual@ietf.org, "http-auth@ietf.org" <http-auth@ietf.org>, The IESG <iesg@ietf.org>, httpauth-chairs@ietf.org
Subject: Re: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2016 07:18:51 -0000

Dear Kathleen,

thank you very much.
I finally looked through all the comments (as far as I noticed),
and reflected for the draft candidate texts in the following location:
https://github.com/yoiwa/httpauth-mutual/blob/master/mutual-auth-protocol.txt
https://github.com/yoiwa/httpauth-mutual/blob/master/mutual-auth-algorithms.txt

Once the IETF draft submission system is reopened on 13 Nov, I'll submit the
revised draft formally to the IETF again.


On 11/08/16 10:44, Kathleen Moriarty wrote:
> Hello,
> 
> I have not seen a response to this discuss (or some of the other comments),
> please respond and discuss these questions and comments.  It would be good
> to wrap up these last 2 drafts soon.
> 
> Thank you,
> Kathleen
> 
> On Thu, Nov 3, 2016 at 8:07 AM, Alexey Melnikov <aamelnikov@fastmail.fm>
> wrote:
> 
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-httpauth-mutual-10: Discuss
>>
>> 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/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> This is generally a well written document. I have a couple of important
>> comments that I would like to see addressed and several less significant
>> comments.
>>
>> 1) As Mirja pointed out, this spec needs need to register "Mutual" HTTP
>> Authentication Schemes with IANA
>>
>> 2) In Section 7:
>>
>>    If HTTP is used on a non-encrypted channel (TCP and SCTP, for
>>    example), the validation type MUST be "host".  If HTTP/TLS [RFC2818]
>>    (HTTPS) is used with a server certificate, the validation type MUST
>>    be "tls-server-end-point".  If HTTP/TLS is used with an anonymous
>>    Diffie-Hellman key exchange, the validation type MUST be "tls-unique"
>>    (see the note below).
>>
>>    Implementations supporting Mutual authentication over HTTPS SHOULD
>>    support the "tls-server-end-point" validation.  Support for
>>    "tls-unique" validation is OPTIONAL for both servers and clients.
>>
>> I think the two paragraphs are in conflict. For example, the first one
>> says that if TLS with server certificate is used, then
>> "tls-server-end-point"
>> MUST be supported. But the second says that it is SHOULD be supported.
>>
>> If the intent of the first paragraph is to say what should appear
>> syntactically,
>> while the second paragraph explains what kind of validation is actually
>> required,
>> I think this still can be made clearer.
>>
>> I suggest you either delete the second of these 2 paragraphs, or you
>> need to reword text in the first (and possibly the second) to specify
>> a non conflicting set of requirements.
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> I agree that the Introduction section might need an editing pass.
>>
>> 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:
>>
>> I think you are overusing SHOULDs instead of MUSTs in many
>> places in the document (not just just in this section). For example:
>>
>>    When
>>    these values are generated from any cryptographic values, they SHOULD
>>    have their "natural length"; if these are generated from a hash
>>    function, these lengths SHOULD correspond to the hash size;
>>
>> Why not a MUST here?
>>
>>    if these
>>    are representing elements of a mathematical set (or group), its
>>    lengths SHOULD be the shortest for representing all the elements in
>>
>> Again, why not a MUST? Having a unique encoding will improve
>> interoperability.
>>
>>    the set.
>>
>>    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]).
>>
>> 7.1.  Applicability notes
>>
>>    When the client is a Web browser with any scripting capabilities, the
>>
>> Can you explain why scripting capabilities are important here?
>>
>>    underlying TLS channel used with HTTP/TLS MUST provide server
>>    identity verification.  This means (1) anonymous Diffie-Hellman key
>>    exchange cipher suites MUST NOT be used, and (2) verification of the
>>    server certificate provided by the server MUST be performed.
>>
>> In Section 9:
>>
>>    In both cases, it is the sender's duty to correctly prepare the
>>    character strings.  If any non-normalized character string is
>>    received from the other peer of the communication, recipients MAY
>>    either use it as a bare UTF-8 string without any preparation, perform
>>    any appropriate preparations (which may cause authentication
>>    failure), or reject any ill-prepared inputs from the sender and
>>    respond as a communication error.
>>
>> I think you are giving too many choices which might cause
>> interoperability issues.
>> Even reducing the choices from 3 to 2 would help here.
>>
>> In Section 11:
>>
>>       *  Otherwise, send a 200-VFY-S response.  If the session was in
>>          the "key exchanging" state, the session SHOULD be changed to an
>>          "authenticated" state.  The maximum nc and nc flags of the
>>          state SHOULD be updated appropriate.
>>
>> Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are
>> possible reasons for a server implementation to violate these SHOULDs?
>>
>> In Section 15:
>>
>> It would be good to be able to bind extension data to shared secret
>> constructed by
>> both parties.
>>
>>
>> _______________________________________________
>> http-auth mailing list
>> http-auth@ietf.org
>> https://www.ietf.org/mailman/listinfo/http-auth
>>
> 
> 
> 

-- 
大岩 寛   Yutaka OIWA             (国研)産業技術総合研究所 情報技術研究部門
                                     サイバーフィジカルウェア研究グループ長
                                      <y.oiwa@aist.go.jp>jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]