From julian.reschke@gmx.de Mon Apr 8 07:22:42 2013 Return-Path: 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 EFB6721F93C6 for ; Mon, 8 Apr 2013 07:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVCfCboOBZVx for ; Mon, 8 Apr 2013 07:22:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D394021F976B for ; Mon, 8 Apr 2013 07:22:40 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M1TnD-1Uj5KY09m5-00tSR3 for ; Mon, 08 Apr 2013 16:22:39 +0200 Received: (qmail invoked by alias); 08 Apr 2013 14:22:38 -0000 Received: from p54BB25AB.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.37.171] by mail.gmx.net (mp001) with SMTP; 08 Apr 2013 16:22:38 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Q94g95eSQo+su/WEAT1QPUtmxbMCef6T7eoX4gK PS/O7HgeeDdY5x Message-ID: <5162D2AD.5070408@gmx.de> Date: Mon, 08 Apr 2013 16:22:37 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "http-auth@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [http-auth] Fwd: [Bug 41489] HTTP authentication does not support non-ISO-8859-1 characters X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:22:42 -0000 FYI and so it's archived: defines a "charset" parameter for Digest/SASL. This is *very* similar to what my draft proposes for Basic and Digest in HTTP; maybe it should simply align with that. Best regards, Julian -------- Original Message -------- Subject: [Bug 41489] HTTP authentication does not support non-ISO-8859-1 characters Date: Mon, 08 Apr 2013 13:38:11 +0000 From: bugzilla-daemon@mozilla.org To: julian.reschke@gmx.de https://bugzilla.mozilla.org/show_bug.cgi?id=41489 ggo changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #734492| |review?(bsmith@mozilla.com) Flags| | --- Comment #122 from ggo 2013-04-08 06:38:11 PDT --- Comment on attachment 734492 --> https://bugzilla.mozilla.org/attachment.cgi?id=734492 Allow utf-8 encoded username in digest authentication response header. This patch allows the http digest authentication module to send back utf8 encoded username in the response header in order to enable support for non-ascii usernames. It can be enabled by setting the "network.auth.digest-response-header-username-utf8" flag to true in the FF config (about:config). the patch could be improved by using the charset parameter as defined in RFC 2831, even if the flag is not set. I can probably do if it is asked. -- Configure bugmail: https://bugzilla.mozilla.org/userprefs.cgi?tab=email ------------------------------- Product/Component: Core :: Networking: HTTP ------- Tracking Flags: ------- blocking2.0:- ------- You are receiving this mail because: ------- You are on the CC list for the bug. From ynir@checkpoint.com Wed Apr 10 04:23:47 2013 Return-Path: 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 D8F6F21F93EE for ; Wed, 10 Apr 2013 04:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.832 X-Spam-Level: X-Spam-Status: No, score=-6.832 tagged_above=-999 required=5 tests=[AWL=3.767, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9pGP2dDzN3p for ; Wed, 10 Apr 2013 04:23:47 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ED13E21F93E3 for ; Wed, 10 Apr 2013 04:23:46 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3ABNjJ2024006 for ; Wed, 10 Apr 2013 14:23:45 +0300 X-CheckPoint: {51654B95-6-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 14:23:45 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Call for Acceptance: draft-williams-http-rest-auth Thread-Index: AQHONd3duwkdKeL9ikikaYK5rZtYew== Date: Wed, 10 Apr 2013 11:23:45 +0000 Message-ID: <4C3646E1-F98E-4E31-9F33-7DF99456040A@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.52] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <072A3045EB0E2347851C64FBAD124454@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Call for Acceptance: draft-williams-http-rest-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:23:48 -0000 Hi folks As per our charter, we are considering taking on draft-williams-http-rest-a= uth to eventually publish as an experimental RFC. This is the call for acce= ptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and co= ntribute text in needed. - no, we should not take this on because=85 The document will be accepted only if there are sufficient reviewers volunt= eering. Just to make it interesting, we also require that each document aut= hor review at least one other document. Thanks Matt & Yoav= From ynir@checkpoint.com Wed Apr 10 04:23:48 2013 Return-Path: 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 4998121F9322 for ; Wed, 10 Apr 2013 04:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.774 X-Spam-Level: X-Spam-Status: No, score=-7.774 tagged_above=-999 required=5 tests=[AWL=2.825, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el+V9XRkSv-h for ; Wed, 10 Apr 2013 04:23:47 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F35D021F93E9 for ; Wed, 10 Apr 2013 04:23:46 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3ABNfQt023988 for ; Wed, 10 Apr 2013 14:23:41 +0300 X-CheckPoint: {51654B91-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 14:23:41 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Call for Acceptance: draft-montenegro-httpbis-multilegged-auth Thread-Index: AQHONd3aAVFxcFIdI0Kf8jRU1b2+oA== Date: Wed, 10 Apr 2013 11:23:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.52] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <05E59ECF3A71504093806B0AF227B090@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Call for Acceptance: draft-montenegro-httpbis-multilegged-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:23:48 -0000 Hi folks As per our charter, we are considering taking on draft-montenegro-httpbis-m= ultilegged-auth to eventually publish as an experimental RFC. This is the c= all for acceptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and co= ntribute text in needed. - no, we should not take this on because=85 The document will be accepted only if there are sufficient reviewers volunt= eering. Just to make it interesting, we also require that each document aut= hor review at least one other document. Thanks Matt & Yoav= From ynir@checkpoint.com Wed Apr 10 04:23:48 2013 Return-Path: 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 6C5E321F93E3 for ; Wed, 10 Apr 2013 04:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.339 X-Spam-Level: X-Spam-Status: No, score=-8.339 tagged_above=-999 required=5 tests=[AWL=2.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOQ16R4tf0VP for ; Wed, 10 Apr 2013 04:23:47 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F108221F93E6 for ; Wed, 10 Apr 2013 04:23:46 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3ABNhuh023992 for ; Wed, 10 Apr 2013 14:23:43 +0300 X-CheckPoint: {51654B93-A-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 14:23:43 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Call for Acceptance: draft-farrell-httpbis-hoba Thread-Index: AQHONd3bDwnufyD/vkSbIXQUduCYPA== Date: Wed, 10 Apr 2013 11:23:42 +0000 Message-ID: <682622D5-F419-41D8-ADB8-3DCD36730BB5@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.52] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Call for Acceptance: draft-farrell-httpbis-hoba X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:23:48 -0000 Hi folks As per our charter, we are considering taking on draft-farrell-httpbis-hoba= to eventually publish as an experimental RFC. This is the call for accepta= nce. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and co= ntribute text in needed. - no, we should not take this on because=85 The document will be accepted only if there are sufficient reviewers volunt= eering. Just to make it interesting, we also require that each document aut= hor review at least one other document. Thanks Matt & Yoav= From ynir@checkpoint.com Wed Apr 10 04:23:48 2013 Return-Path: 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 ABB1421F9322 for ; Wed, 10 Apr 2013 04:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.716 X-Spam-Level: X-Spam-Status: No, score=-8.716 tagged_above=-999 required=5 tests=[AWL=1.883, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJnSkLhQC-I7 for ; Wed, 10 Apr 2013 04:23:48 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 01B6221F93EA for ; Wed, 10 Apr 2013 04:23:46 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3ABNier024000 for ; Wed, 10 Apr 2013 14:23:44 +0300 X-CheckPoint: {51654B94-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 14:23:44 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Call for Acceptance: draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension Thread-Index: AQHONd3cEJKzd+8TC0WdAoqIjGc32w== Date: Wed, 10 Apr 2013 11:23:43 +0000 Message-ID: <8A42F29D-9C13-45E0-87F1-8F477E7AB631@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.52] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <801E5B1E220C954E9C5969E4D25BE075@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Call for Acceptance: draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:23:48 -0000 Hi folks As per our charter, we are considering taking on draft-oiwa-http-mutualauth= and draft-oiwa-http-auth-extension to eventually publish as experimental R= FCs. This is the call for acceptance. Please reply to this mail with a resp= onse such as: - yes, we should take this on, and I can be counted on to review it and co= ntribute text in needed. - no, we should not take this on because=85 The documents will be accepted only if there are sufficient reviewers volun= teering. Just to make it interesting, we also require that each document au= thor review at least one other document. Thanks Matt & Yoav= From stephen.farrell@cs.tcd.ie Wed Apr 10 04:28:39 2013 Return-Path: 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 534EE21F9425 for ; Wed, 10 Apr 2013 04:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ0BykZJMAFd for ; Wed, 10 Apr 2013 04:28:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A016821F9423 for ; Wed, 10 Apr 2013 04:28:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B81AEBE55; Wed, 10 Apr 2013 12:28:16 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf5I0AHwMUDE; Wed, 10 Apr 2013 12:28:16 +0100 (IST) Received: from [IPv6:2001:770:10:203:39a4:985d:d52e:956] (unknown [IPv6:2001:770:10:203:39a4:985d:d52e:956]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9A4D0BE2F; Wed, 10 Apr 2013 12:28:16 +0100 (IST) Message-ID: <51654CD0.1030003@cs.tcd.ie> Date: Wed, 10 Apr 2013 12:28:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yoav Nir References: <682622D5-F419-41D8-ADB8-3DCD36730BB5@checkpoint.com> In-Reply-To: <682622D5-F419-41D8-ADB8-3DCD36730BB5@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Call for Acceptance: draft-farrell-httpbis-hoba X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:28:39 -0000 Yes to all 4 from me. And I'll review the other 3. S. On 04/10/2013 12:23 PM, Yoav Nir wrote: > Hi folks > > As per our charter, we are considering taking on draft-farrell-httpbis-hoba to eventually publish as an experimental RFC. This is the call for acceptance. Please reply to this mail with a response such as: > - yes, we should take this on, and I can be counted on to review it and contribute text in needed. > - no, we should not take this on because… > > The document will be accepted only if there are sufficient reviewers volunteering. Just to make it interesting, we also require that each document author review at least one other document. > > Thanks > > Matt & Yoav > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From ynir@checkpoint.com Wed Apr 10 04:32:00 2013 Return-Path: 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 85FE021F8A40 for ; Wed, 10 Apr 2013 04:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.985 X-Spam-Level: X-Spam-Status: No, score=-8.985 tagged_above=-999 required=5 tests=[AWL=1.614, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QISKj2aM9Ipb for ; Wed, 10 Apr 2013 04:32:00 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 836BF21F8A09 for ; Wed, 10 Apr 2013 04:31:59 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3ABNlKZ024013 for ; Wed, 10 Apr 2013 14:23:47 +0300 X-CheckPoint: {51654B97-3-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 14:23:47 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Call for Acceptance: draft-melnikov-httpbis-scran-auth Thread-Index: AQHONd3dW2LFUQcfdEqsV96jr8Ly1w== Date: Wed, 10 Apr 2013 11:23:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.52] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <9031CA93AE64B043807D5C23B68C69F7@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Call for Acceptance: draft-melnikov-httpbis-scran-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 11:32:00 -0000 Hi folks As per our charter, we are considering taking on draft-melnikov-httpbis-scr= an-auth to eventually publish as an experimental RFC. This is the call for = acceptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and co= ntribute text in needed. - no, we should not take this on because=85 The document will be accepted only if there are sufficient reviewers volunt= eering. Just to make it interesting, we also require that each document aut= hor review at least one other document. Thanks Matt & Yoav= From paul.hoffman@vpnc.org Wed Apr 10 09:01:28 2013 Return-Path: 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 709C921F991C for ; Wed, 10 Apr 2013 09:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R5COTw81ecR for ; Wed, 10 Apr 2013 09:01:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 131D921F991A for ; Wed, 10 Apr 2013 09:01:28 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3AG1QC1006491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 10 Apr 2013 09:01:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <4C3646E1-F98E-4E31-9F33-7DF99456040A@checkpoint.com> Date: Wed, 10 Apr 2013 09:01:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C3646E1-F98E-4E31-9F33-7DF99456040A@checkpoint.com> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [http-auth] Call for Acceptance: draft-williams-http-rest-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:01:28 -0000 This should be a WG document and I will review it, including making = suggestions for the TODOs. --Paul Hoffman= From paul.hoffman@vpnc.org Wed Apr 10 09:02:06 2013 Return-Path: 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 C8E0521F98D2 for ; Wed, 10 Apr 2013 09:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag3vJxqYFadc for ; Wed, 10 Apr 2013 09:02:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 69CD521F98BE for ; Wed, 10 Apr 2013 09:02:06 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3AG1QC2006491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 10 Apr 2013 09:02:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <682622D5-F419-41D8-ADB8-3DCD36730BB5@checkpoint.com> Date: Wed, 10 Apr 2013 09:02:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <487B9D14-ABB1-49DB-8B2F-78474B2B2590@vpnc.org> References: <682622D5-F419-41D8-ADB8-3DCD36730BB5@checkpoint.com> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: Re: [http-auth] Call for Acceptance: draft-farrell-httpbis-hoba X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:02:06 -0000 This should be a WG document. I am co-author, so I am clearly biased. --Paul Hoffman From yaronf.ietf@gmail.com Wed Apr 10 09:03:45 2013 Return-Path: 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 31C7B21F9939 for ; Wed, 10 Apr 2013 09:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgzZwapt2AVs for ; Wed, 10 Apr 2013 09:03:44 -0700 (PDT) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9757521F9938 for ; Wed, 10 Apr 2013 09:03:43 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d4so311332eek.15 for ; Wed, 10 Apr 2013 09:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ogod9Bdi4uB4SvaqzD1z+S+1ygklovQt0KpwDBKGrQs=; b=TxHSmiEieo6cDrIJmTRKSx8qikQJCPbE6S/RErv6G0kbdyBC6zaF9i1XxMzbuWNQLf KNNzu6MY/+Bjxnl35nH1ZkI91IqQiYsGvJM/c4n9+VqIzWLUWUOj+lv/wNG8dY6KNzif 6f6IQfLRO8m8J/N022jSb5oAeEqs11cBEfA2F+ENMytaLasy9QFRzn9BoyFgj0y3Yej8 Aun5PSolixvAujTuzDz43A/MmirJ2/loRfBJrUm8nPqLqIX4qVCeclWkDEK6svVYAjq2 kvT1gVVpEY9Jylot9HwUb04xtBuOE5EBoZp1qZGjedOhvTFI2BTRCHaYdNghA3gcInlE eYvA== X-Received: by 10.14.5.137 with SMTP id 9mr2422389eel.30.1365609822467; Wed, 10 Apr 2013 09:03:42 -0700 (PDT) Received: from [10.0.0.14] (109-186-115-180.bb.netvision.net.il. [109.186.115.180]) by mx.google.com with ESMTPS id bj2sm704581eeb.1.2013.04.10.09.03.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 09:03:41 -0700 (PDT) Message-ID: <51658D5A.5020706@gmail.com> Date: Wed, 10 Apr 2013 19:03:38 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yoav Nir References: <8A42F29D-9C13-45E0-87F1-8F477E7AB631@checkpoint.com> In-Reply-To: <8A42F29D-9C13-45E0-87F1-8F477E7AB631@checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Call for Acceptance: draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:03:45 -0000 I support this pair of documents and will review them. Thanks, Yaron On 2013-04-10 14:23, Yoav Nir wrote: > Hi folks > > As per our charter, we are considering taking on draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension to eventually publish as experimental RFCs. This is the call for acceptance. Please reply to this mail with a response such as: > - yes, we should take this on, and I can be counted on to review it and contribute text in needed. > - no, we should not take this on because… > > The documents will be accepted only if there are sufficient reviewers volunteering. Just to make it interesting, we also require that each document author review at least one other document. > > Thanks > > Matt & Yoav > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From cuiyang@huawei.com Wed Apr 10 09:07:33 2013 Return-Path: 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 1748F21F9956 for ; Wed, 10 Apr 2013 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk+Gt6-hGZgk for ; Wed, 10 Apr 2013 09:07:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CD80C21F98F9 for ; Wed, 10 Apr 2013 09:07:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARR46981; Wed, 10 Apr 2013 16:07:22 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Apr 2013 17:06:44 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Apr 2013 17:07:16 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.98]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Thu, 11 Apr 2013 00:07:14 +0800 From: Cuiyang To: Yaron Sheffer , Yoav Nir Thread-Topic: [http-auth] Call for Acceptance: draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension Thread-Index: AQHONd3cEJKzd+8TC0WdAoqIjGc325jPGBQAgACGuzo= Date: Wed, 10 Apr 2013 16:07:14 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE21637323916@nkgeml505-mbx.china.huawei.com> References: <8A42F29D-9C13-45E0-87F1-8F477E7AB631@checkpoint.com>, <51658D5A.5020706@gmail.com> In-Reply-To: <51658D5A.5020706@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.216.46.11] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Call for Acceptance: draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:07:33 -0000 U3VwcG9ydCB0aGVzZSB0d28gZHJhZnRzLCBhbmQgd291bGQgbGlrZSB0byByZXZpZXcgdGhlbS4N Cg0KUmVnYXJkcywNCllhbmcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kt6K8/sjLOiBodHRwLWF1dGgtYm91bmNlc0BpZXRmLm9yZyBbaHR0cC1hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gWWFyb24gU2hlZmZlciBbeWFyb25mLmlldGZAZ21haWwuY29tXQ0K t6LLzcqxvOQ6IDIwMTPE6jTUwjExyNUgMDowMw0Ktb06IFlvYXYgTmlyDQpDYzogaHR0cC1hdXRo QGlldGYub3JnDQrW98ziOiBSZTogW2h0dHAtYXV0aF0gQ2FsbCBmb3IgQWNjZXB0YW5jZTogZHJh ZnQtb2l3YS1odHRwLW11dHVhbGF1dGggYW5kIGRyYWZ0LW9pd2EtaHR0cC1hdXRoLWV4dGVuc2lv bg0KDQpJIHN1cHBvcnQgdGhpcyBwYWlyIG9mIGRvY3VtZW50cyBhbmQgd2lsbCByZXZpZXcgdGhl bS4NCg0KVGhhbmtzLA0KICAgICAgICBZYXJvbg0KDQpPbiAyMDEzLTA0LTEwIDE0OjIzLCBZb2F2 IE5pciB3cm90ZToNCj4gSGkgZm9sa3MNCj4NCj4gQXMgcGVyIG91ciBjaGFydGVyLCB3ZSBhcmUg Y29uc2lkZXJpbmcgdGFraW5nIG9uIGRyYWZ0LW9pd2EtaHR0cC1tdXR1YWxhdXRoIGFuZCBkcmFm dC1vaXdhLWh0dHAtYXV0aC1leHRlbnNpb24gdG8gZXZlbnR1YWxseSBwdWJsaXNoIGFzIGV4cGVy aW1lbnRhbCBSRkNzLiBUaGlzIGlzIHRoZSBjYWxsIGZvciBhY2NlcHRhbmNlLiBQbGVhc2UgcmVw bHkgdG8gdGhpcyBtYWlsIHdpdGggYSByZXNwb25zZSBzdWNoIGFzOg0KPiAgIC0geWVzLCB3ZSBz aG91bGQgdGFrZSB0aGlzIG9uLCBhbmQgSSBjYW4gYmUgY291bnRlZCBvbiB0byByZXZpZXcgaXQg YW5kIGNvbnRyaWJ1dGUgdGV4dCBpbiBuZWVkZWQuDQo+ICAgLSBubywgd2Ugc2hvdWxkIG5vdCB0 YWtlIHRoaXMgb24gYmVjYXVzZaGtDQo+DQo+IFRoZSBkb2N1bWVudHMgd2lsbCBiZSBhY2NlcHRl ZCBvbmx5IGlmIHRoZXJlIGFyZSBzdWZmaWNpZW50IHJldmlld2VycyB2b2x1bnRlZXJpbmcuIEp1 c3QgdG8gbWFrZSBpdCBpbnRlcmVzdGluZywgd2UgYWxzbyByZXF1aXJlIHRoYXQgZWFjaCBkb2N1 bWVudCBhdXRob3IgcmV2aWV3IGF0IGxlYXN0IG9uZSBvdGhlciBkb2N1bWVudC4NCj4NCj4gVGhh bmtzDQo+DQo+IE1hdHQgJiBZb2F2DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IGh0dHAtYXV0aCBtYWlsaW5nIGxpc3QNCj4gaHR0cC1hdXRoQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHR0cC1hdXRo DQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaHR0 cC1hdXRoIG1haWxpbmcgbGlzdA0KaHR0cC1hdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHAtYXV0aA== From nico@cryptonector.com Wed Apr 10 09:22:17 2013 Return-Path: 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 EF5E421F850C for ; Wed, 10 Apr 2013 09:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPGbtMYZ9LUX for ; Wed, 10 Apr 2013 09:22:16 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3106E21F8506 for ; Wed, 10 Apr 2013 09:22:16 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 96EC226410D for ; Wed, 10 Apr 2013 09:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0ffkvJLiAJLT4CfsYllc Qz6Y108=; b=Q34DEMNGoMA50O5TIx9SHl1xb66dKdsZS5xPHU3kZmEapF8HjLf2 sBkiU4mQxJIhzSR3wDwMtvIPNOOuXcjeGpjgr4FwScoNbBuvjUAX57d7+Vo5IxJN HMkOu/k0g+9/bUvP7uFwENBM3aIFEdn3NoRlTghyb/6hkf0hcvTq3lc= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 63C0726413D for ; Wed, 10 Apr 2013 09:13:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id r3so512454wey.17 for ; Wed, 10 Apr 2013 09:12:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.173.167 with SMTP id bl7mr4646426wjc.50.1365610359849; Wed, 10 Apr 2013 09:12:39 -0700 (PDT) Received: by 10.217.105.195 with HTTP; Wed, 10 Apr 2013 09:12:39 -0700 (PDT) In-Reply-To: References: <4C3646E1-F98E-4E31-9F33-7DF99456040A@checkpoint.com> Date: Wed, 10 Apr 2013 11:12:39 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Call for Acceptance: draft-williams-http-rest-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:22:17 -0000 Thanks Paul. I've been AWOL from my IETF duties the last couple of weeks. I'll publish new versions of my websec and this I-D this weekend, I hope -- the following at the latest. Nico -- From ynir@checkpoint.com Wed Apr 10 12:46:42 2013 Return-Path: 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 8D4DA21F90F1 for ; Wed, 10 Apr 2013 12:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.187 X-Spam-Level: X-Spam-Status: No, score=-9.187 tagged_above=-999 required=5 tests=[AWL=1.413, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFJ9TCPKC2lj for ; Wed, 10 Apr 2013 12:46:42 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 831F021F9015 for ; Wed, 10 Apr 2013 12:46:41 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3AJkaT3007183 for ; Wed, 10 Apr 2013 22:46:39 +0300 X-CheckPoint: {5165C16B-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 22:46:36 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Call for Acceptance: draft-melnikov-httpbis-scram-auth Thread-Index: AQHONiQc3+YSGbw9O0uOuery+7LiZA== Date: Wed, 10 Apr 2013 19:46:35 +0000 Message-ID: <22CE3B0B-1A9B-4A7D-AE50-83E2037523C6@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.141] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <35A2F1C53FBEB3408BB11B19F5B34AB7@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] Call for Acceptance: draft-melnikov-httpbis-scram-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 19:46:42 -0000 Oops. Fixed the typo. On Apr 10, 2013, at 2:23 PM, Yoav Nir wrote: > Hi folks >=20 > As per our charter, we are considering taking on draft-melnikov-httpbis-s= cram-auth to eventually publish as an experimental RFC. This is the call fo= r acceptance. Please reply to this mail with a response such as: > - yes, we should take this on, and I can be counted on to review it and c= ontribute text in needed. > - no, we should not take this on because=85 >=20 > The document will be accepted only if there are sufficient reviewers volu= nteering. Just to make it interesting, we also require that each document a= uthor review at least one other document. >=20 > Thanks >=20 > Matt & Yoav From y.oiwa@aist.go.jp Wed Apr 10 16:22:36 2013 Return-Path: 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 0279621F8AF0 for ; Wed, 10 Apr 2013 16:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05qF1swKwld9 for ; Wed, 10 Apr 2013 16:22:35 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB1A21F8A7E for ; Wed, 10 Apr 2013 16:22:34 -0700 (PDT) Received: from mail-qe0-f72.google.com ([209.85.128.72]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUWX0OnNi2G2ENToGTYT+ctWQrvUkAh1l@postini.com; Wed, 10 Apr 2013 16:22:35 PDT Received: by mail-qe0-f72.google.com with SMTP id 1so1701361qee.11 for ; Wed, 10 Apr 2013 16:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=OPAYd/K80kp3oaJbl6G9/mN7rCnjw7oeXtRCX78QlOU=; b=Z1ImWpOMExnD1AUYe1Vmbjc7tgLoFe+DTK7XaTeTVQHAgpx7BxD6fUikAV+mZfRaWc iWoqqZBZ7mxfxRocWdbN43IXffiEB9MdU+IK1d+wZjv6a8EFDd0cSJ+hEec+k1pLP+M+ GctMJ7HsMDrc/E1mkybNMfCVXCbG5xpkfeyVg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=OPAYd/K80kp3oaJbl6G9/mN7rCnjw7oeXtRCX78QlOU=; b=QzxeXPSPPJ8dI2LRxU2QEMRIK23sP7pElWAtljdOwx6Msg6gfIvAgoN893AGkZ4rJp i/Rn82Yp4QaMpbnAKiqQwW2Mre8Hb0GjOjxGOVCtpJAMgT6j6GZ/B/+AiXMem4rpKjUd hElI7vn7Ba8X90wU9fHw96/k4ZHt8uUXuJmRXyelTkXEXHTeM8LlahqLn2sTef12I5Jc WvuQefVeenr2xeryW2+cMxV/gmkeb/wPKIzENZLF2+Qzm+s1Aua1SCjS9OA7homwHmn1 9cB15XAX6Vj1rFfg5oYLFLesLye9ThVOyqGerLl+aFwI3flSGaX4QjEAgSUvCL0Vp/JD l6hw== X-Received: by 10.220.104.20 with SMTP id m20mr3173295vco.70.1365636154068; Wed, 10 Apr 2013 16:22:34 -0700 (PDT) X-Received: by 10.220.104.20 with SMTP id m20mr3173294vco.70.1365636154001; Wed, 10 Apr 2013 16:22:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.180.166 with HTTP; Wed, 10 Apr 2013 16:22:13 -0700 (PDT) In-Reply-To: References: From: Yutaka OIWA Date: Thu, 11 Apr 2013 08:22:13 +0900 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkAhy2b4/E5ELZYL5Sx9/H+ykUw1plCT4HS3T48xOS+7DOpG7M/SLi7CeR2prxwf9Imx/Na1iny1CeZ/NtFNMBAMCxSmlgUR7Xs3flWXcrsK4T+Tno86ir172BEM+XwhmI/yJI6bM0yE6WX0/Vyd3Z+xtQ3PQ== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Call for Acceptance: draft-melnikov-httpbis-scran-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 23:22:36 -0000 Yes, I will support it and review the document. 2013/4/10 Yoav Nir : > Hi folks > > As per our charter, we are considering taking on draft-melnikov-httpbis-s= cran-auth to eventually publish as an experimental RFC. This is the call fo= r acceptance. Please reply to this mail with a response such as: > - yes, we should take this on, and I can be counted on to review it and = contribute text in needed. > - no, we should not take this on because=85 > > The document will be accepted only if there are sufficient reviewers volu= nteering. Just to make it interesting, we also require that each document a= uthor review at least one other document. > > Thanks > > Matt & Yoav > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --=20 Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] From tony@att.com Wed Apr 10 20:00:57 2013 Return-Path: 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 B897B21F8BE2 for ; Wed, 10 Apr 2013 20:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL5ekpjtnGul for ; Wed, 10 Apr 2013 20:00:57 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E17B321F8BD0 for ; Wed, 10 Apr 2013 20:00:56 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 86726615.0.424934.00-434.1183758.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 11 Apr 2013 03:00:56 +0000 (UTC) X-MXL-Hash: 5166276874008c61-58a24f40d9bbb1a1bf06707b60cc400fe52676de Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3B30urr019363 for ; Wed, 10 Apr 2013 23:00:56 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3B30qG1019344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Apr 2013 23:00:54 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Thu, 11 Apr 2013 04:00:38 +0100 Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r3B30cOW007316 for ; Wed, 10 Apr 2013 23:00:38 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r3B30Wql006759 for ; Wed, 10 Apr 2013 23:00:35 -0400 Received: from [135.70.241.43] (vpn-135-70-241-43.vpn.east.att.com[135.70.241.43]) by maillennium.att.com (mailgw1) with ESMTP id <20130411025839gw1000m5hse> (Authid: tony); Thu, 11 Apr 2013 02:58:43 +0000 X-Originating-IP: [135.70.241.43] Message-ID: <5166274D.1060503@att.com> Date: Wed, 10 Apr 2013 23:00:29 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yoav Nir References: <682622D5-F419-41D8-ADB8-3DCD36730BB5@checkpoint.com> In-Reply-To: <682622D5-F419-41D8-ADB8-3DCD36730BB5@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=dcs3Kwre c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=eRgAXS4uelgA:10 a=_nfIMGA1H_4A:10 a=OHhASyi7ybwA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=N659UExz7-8A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=CanGlQ3x-ikA:10 a=RfywL-paIX4J0ArWZN0A:9 a=pILNO] X-AnalysisOut: [xqGKmIA:10] Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Call for Acceptance: draft-farrell-httpbis-hoba X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 03:00:57 -0000 I support its adoption. Tony Hansen On 4/10/2013 7:23 AM, Yoav Nir wrote: > Hi folks > > As per our charter, we are considering taking on draft-farrell-httpbis-hoba to eventually publish as an experimental RFC. This is the call for acceptance. Please reply to this mail with a response such as: > - yes, we should take this on, and I can be counted on to review it and contribute text in needed. > - no, we should not take this on because… > > The document will be accepted only if there are sufficient reviewers volunteering. Just to make it interesting, we also require that each document author review at least one other document. > > Thanks > > Matt & Yoav From julian.reschke@gmx.de Tue Apr 16 05:09:18 2013 Return-Path: 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 D987721F96BF for ; Tue, 16 Apr 2013 05:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs8+j6hpt9pA for ; Tue, 16 Apr 2013 05:09:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id DC60B21F95CE for ; Tue, 16 Apr 2013 05:09:16 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MMIQV-1USruo2sxB-007yof for ; Tue, 16 Apr 2013 14:09:15 +0200 Received: (qmail invoked by alias); 16 Apr 2013 12:09:15 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 16 Apr 2013 14:09:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18TH4ZJhpIT6+Ky3iS2Prj3hB57FA48qC8r+Kd0jL oiY3aqYHT8SANl Message-ID: <516D3F69.4030701@gmx.de> Date: Tue, 16 Apr 2013 14:09:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [http-auth] Working Group Last Call on the HTTPbis document set from Mark Nottingham on 2013-03-17 (ietf-http-wg@w3.org from January to March 2013) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 12:09:19 -0000 Hi there, reminder: HTTPbis is in WGLC, ending at the end of April: This includes Part 7, which should be of interest for everybody over here :-). Best regards, Julian From ynir@checkpoint.com Wed Apr 17 23:37:42 2013 Return-Path: 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 E91A921F8F4A for ; Wed, 17 Apr 2013 23:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emDV7m1ZjoX2 for ; Wed, 17 Apr 2013 23:37:42 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0115921F8F28 for ; Wed, 17 Apr 2013 23:37:41 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3I6be0w003541 for ; Thu, 18 Apr 2013 09:37:40 +0300 X-CheckPoint: {516F9423-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 18 Apr 2013 09:37:40 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Call for Acceptance: draft-montenegro-httpbis-multilegged-auth Thread-Index: AQHONd3aAVFxcFIdI0Kf8jRU1b2+oJjbkdpA Date: Thu, 18 Apr 2013 06:37:39 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772111A0F04A@IL-EX10.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.121] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] Call for Acceptance: draft-montenegro-httpbis-multilegged-auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 06:37:43 -0000 Hi again Gabriel has decided to withdraw the draft from consideration for this worki= ng group, at least until HTTP/2.0 takes a more final form. I'd like to tha= nk Gabriel for participating, and hopefully he will still volunteer to revi= ew one of the other drafts. Matt & Yoav -----Original Message----- From: Yoav Nir=20 Sent: Wednesday, April 10, 2013 2:24 PM To: http-auth@ietf.org Subject: Call for Acceptance: draft-montenegro-httpbis-multilegged-auth Hi folks As per our charter, we are considering taking on draft-montenegro-httpbis-m= ultilegged-auth to eventually publish as an experimental RFC. This is the c= all for acceptance. Please reply to this mail with a response such as: - yes, we should take this on, and I can be counted on to review it and co= ntribute text in needed. - no, we should not take this on because... The document will be accepted only if there are sufficient reviewers volunt= eering. Just to make it interesting, we also require that each document aut= hor review at least one other document. Thanks Matt & Yoav From msporny@digitalbazaar.com Thu Apr 18 14:27:13 2013 Return-Path: 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 8A41B21F90EB; Thu, 18 Apr 2013 14:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[AWL=-5.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcGV3lQfD4ta; Thu, 18 Apr 2013 14:27:12 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id D87F121F90CC; Thu, 18 Apr 2013 14:27:12 -0700 (PDT) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1USwMK-00028p-03; Thu, 18 Apr 2013 17:27:12 -0400 Message-ID: <5170652F.60609@digitalbazaar.com> Date: Thu, 18 Apr 2013 17:27:11 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: IETF HTTP Auth , IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Apr 2013 03:32:36 -0700 Cc: Web Payments CG Subject: [http-auth] Web Keys and HTTP Signatures X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 21:29:20 -0000 My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor of various W3C specs and member of the HTML WG and RDF WG. There is a relatively new spec at W3C called Web Keys[1] that now supports HTTP Signatures[2]. It is being worked on as a part of the Web Payments[3] work. Specifically, the PaySwarm[4] specifications use Web Keys and HTTP request signatures. We'd like to coordinate with the IETF on this work to make sure we have all parties interested in solving this problem involved in the work. We would also like more eyes doing security audits[5] on the protocol. For a high-level introduction to Web Keys, see the Mozilla Hacks article: https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/ For a high-level introduction to the Web Payments work, look here: http://blog.meritora.com/launch/ One of the first questions that came up in the IETF HTTP WG thread[5] on the matter is why none of the other HTTP authentication schemes were acceptable to the Web Payments group at W3C. Here is a quick run-down of the reasoning: HTTP Origin-Bound Authentication (HOBA) http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt We had considered signatures in the URL in the second approach to the problem in the Web Keys spec. We eventually rejected the solution because of limitations in the URL length in some browsers and because we wanted the semantics of the HTTP headers to be able to be a part of the digital signature. We also didn't want large signed messages being dumped to the webserver logs (the request line is typically included). So, while HOBA does solve the problem, it doesn't solve it in a way that is acceptable to us. HTTP Mutual Authentication http://tools.ietf.org/html/draft-oiwa-http-mutualauth-12 Overkill for our purposes and requires multiple bounces back and forth between the client and the server. Key exchange isn't required since that's taken care of by the Web Keys PKI framework. We don't intend the Web Keys HTTP signature protocol to be session-based, as a session-based value can be built on top of HTTP signatures pretty easily. HTTP Multilegged Auth http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt Seems like overkill for our needs and is fairly specific to HTTP 2.0. We wanted something that could work for HTTP 1.0. Multi-legged authentication is something that we're not interested in solving using HTTP Signatures. Putting state into the protocol is something we'd like to avoid if possible. HTTP Salted Challenge Response http://tools.ietf.org/html/draft-melnikov-httpbis-scram-auth-00 Uses HMACs, doesn't use public key crypto, which is a requirement for Web Keys and the Web Payments work. HTTP REST Auth http://tools.ietf.org/id/draft-williams-http-rest-auth-03.txt This was the solution that seemed to be most interesting to the Web Keys and Web Payments work. However, it requires quite a bit of state to be remembered by the server (the Session URIs). Keeping the state of a "session" around isn't desirable. We didn't want there to be a concept of logging in and logging out of a website w/ the HTTP Signature stuff. We'd rather that sessions are built on top of HTTP Signatures via a HTTP header or cookie. Again, if we had to pick a back-up solution, HTTP REST Auth seems like it might work for us, but we'd rather not use if we don't have to. I'll stop here and wait for feedback from the groups that are involved. I am in contact with Stephen Farrell and a few other folks at IETF about where best to coordinate the work. -- manu [1] https://payswarm.com/specs/source/web-keys/ [2] https://github.com/joyent/node-http-signature/blob/master/http_signing.md [3] http://www.w3.org/community/webpayments/ [4] https://payswarm.com/ [5] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0145.html -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From stephen.farrell@cs.tcd.ie Fri Apr 19 03:58:30 2013 Return-Path: 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 3FF4B21F9305; Fri, 19 Apr 2013 03:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6jXXMTEmCnh; Fri, 19 Apr 2013 03:58:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 93D3D21F8F28; Fri, 19 Apr 2013 03:58:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 16AABBE70; Fri, 19 Apr 2013 11:58:05 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6fUiIlILzr9; Fri, 19 Apr 2013 11:58:05 +0100 (IST) Received: from [IPv6:2001:770:10:203:b90d:e185:2958:9b0] (unknown [IPv6:2001:770:10:203:b90d:e185:2958:9b0]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DAE5CBE6E; Fri, 19 Apr 2013 11:58:04 +0100 (IST) Message-ID: <5171233D.303@cs.tcd.ie> Date: Fri, 19 Apr 2013 11:58:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Manu Sporny References: <5170652F.60609@digitalbazaar.com> In-Reply-To: <5170652F.60609@digitalbazaar.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth , Web Payments CG , IETF Apps Discuss Subject: Re: [http-auth] Web Keys and HTTP Signatures X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 10:58:30 -0000 Hi Manu, Just on the HOBA bit... On 04/18/2013 10:27 PM, Manu Sporny wrote: > > HTTP Origin-Bound Authentication (HOBA) > http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt > > We had considered signatures in the URL in the second approach to the > problem in the Web Keys spec. We eventually rejected the solution > because of limitations in the URL length in some browsers and because we > wanted the semantics of the HTTP headers to be able to be a part of the > digital signature. We also didn't want large signed messages being > dumped to the webserver logs (the request line is typically included). > So, while HOBA does solve the problem, it doesn't solve it in a way that > is acceptable to us. I think you're misreading the spec a little, or we've written it badly:-) The HTTP scheme in HOBA is an HTTP authentication scheme so I don't know what you mean when you say putting the signatures in the URLs, since we don't do that. I think its that part (section 4 of the HOBA draft) where there's most in common between these, but also section 6. The non-normative JS stuff does say to put the signature in the URL though yes, but is quite a work-in-progress. That section is really there to demonstrate that a site could do the moral equivalent of HOBA without waiting for all UAs to implement the spec. so e.g., if forms made for a better example that'd be ok too I think (not sure if my co-authors agree though). But your points about message size and logs are reasonable. HOBA is just about public key methods, not HMAC which is a real difference. All in all your stuff and this looks quite similar to me, so I'd say we should talk all right. Cheers, S. From cyrus@daboo.name Fri Apr 19 08:33:55 2013 Return-Path: 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 7708A21F8E48; Fri, 19 Apr 2013 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbGJPzd-RjyJ; Fri, 19 Apr 2013 08:33:54 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 833C121F8F45; Fri, 19 Apr 2013 08:33:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 06D1541A2A7C; Fri, 19 Apr 2013 11:33:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdkhLuDa--nT; Fri, 19 Apr 2013 11:33:53 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 03ADA41A2A6E; Fri, 19 Apr 2013 11:33:51 -0400 (EDT) Date: Fri, 19 Apr 2013 11:33:48 -0400 From: Cyrus Daboo To: Manu Sporny , IETF HTTP Auth , IETF Apps Discuss Message-ID: <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com> In-Reply-To: <5170652F.60609@digitalbazaar.com> References: <5170652F.60609@digitalbazaar.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1912 X-Mailman-Approved-At: Fri, 19 Apr 2013 08:35:48 -0700 Cc: Web Payments CG Subject: Re: [http-auth] [apps-discuss] Web Keys and HTTP Signatures X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:33:55 -0000 Hi Manu, --On April 18, 2013 at 5:27:11 PM -0400 Manu Sporny wrote: > My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON > for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor > of various W3C specs and member of the HTML WG and RDF WG. > > There is a relatively new spec at W3C called Web Keys[1] that now > supports HTTP Signatures[2]. It is being worked on as a part of the Web > Payments[3] work. Specifically, the PaySwarm[4] specifications use Web > Keys and HTTP request signatures. > > We'd like to coordinate with the IETF on this work to make sure we have > all parties interested in solving this problem involved in the work. We > would also like more eyes doing security audits[5] on the protocol. > [2] > https://github.com/joyent/node-http-signature/blob/master/http_signing.md That draft is very similar to the approach we have used in iSchedule () - which is an HTTP-based calendar and scheduling messaging protocol. We choose to re-use existing email signing technology - DKIM () - primarily because the security model and key management were a good fit for our application. There is also the benefit of code re-use, and working with a protocol that is already deployed and used heavily in the email environment. Also, DKIM was designed with the prospect of being applicable to protocols beyond email technology - and I think with iSchedule we have proven it can work with HTTP. I would definitely urge you to take a serious look at DKIM. There are a number of interesting features there that don't seem to have been addressed in the draft you cited. In particular dealing with both header and body canonicalization (headers are particular problem in HTTP due to intermediaries, caches etc). -- Cyrus Daboo From msporny@digitalbazaar.com Sat Apr 20 20:20:04 2013 Return-Path: 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 17D8121F8ECB; Sat, 20 Apr 2013 20:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgmBYBvYpaVV; Sat, 20 Apr 2013 20:20:02 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 73F9F21F89FB; Sat, 20 Apr 2013 20:20:02 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UTkoh-0001UP-WB; Sat, 20 Apr 2013 23:19:54 -0400 Message-ID: <51735AD2.9040900@digitalbazaar.com> Date: Sat, 20 Apr 2013 23:19:46 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <5170652F.60609@digitalbazaar.com> <5171233D.303@cs.tcd.ie> In-Reply-To: <5171233D.303@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth , Mark Cavage , Web Payments CG , IETF Apps Discuss Subject: Re: [http-auth] Web Keys and HTTP Signatures X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 03:20:04 -0000 On 04/19/2013 06:58 AM, Stephen Farrell wrote: >> HTTP Origin-Bound Authentication (HOBA) >> http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt >> >> We had considered signatures in the URL in the second approach to >> the problem in the Web Keys spec. We eventually rejected the >> solution because of limitations in the URL length in some browsers >> and because we wanted the semantics of the HTTP headers to be able >> to be a part of the digital signature. We also didn't want large >> signed messages being dumped to the webserver logs (the request >> line is typically included). So, while HOBA does solve the problem, >> it doesn't solve it in a way that is acceptable to us. > > I think you're misreading the spec a little, or we've written it > badly:-) I did misread the spec a bit, confusing some of the features in other HTTP Auth specs with some of the HOBA features. So, I took tonight to do a thorough review of the spec and outline the issues that we have with the current HOBA spec located at: http://tools.ietf.org/html/draft-farrell-httpbis-hoba-02 I do agree that we should chat a bit more deeply about HOBA, Web Keys, Persona, and HTTP Signatures. So, please take this not as negative feedback, but constructive criticism and the first exchange toward attempting to map out a way forward for these specs. Here's the HOBA spec review from a Web Keys / Web Payments perspective: 1. Introduction ---------------- > HOBA also defines some services that are required for modern HTTP > authentication: > > o Servers can bind a CPK with an identifier, such as an account > name. HOBA allows servers to define their own policies for binding > CPKs with accounts during account registration. While a bit vague, we want to ensure that there is a well-defined way to do this. We're currently in the process of discussing how this should happen with the Mozilla Persona team. Ideally, the CPKs are setup or transmitted to the server when a Persona-like login exchange happens. We'd like to provide CPKs via some sort of identity expressed as Linked Data, like the sort that's defined in the Web Keys spec: curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu > o Users are likely to use more than one device or user agent (UA) > for the same HTTP based service, so HOBA gives a way to associate > more than one CPK to the same account, but without having to register > for each separately. +1, the approach above is how we accomplish this for Web Keys. > o Users are also likely to lose a private key, or the client's > memory of which key pair is associated with which origin. For > example if a user loses the computer or mobile device in which state > is stored. HOBA allows for clients to tell servers to delete the > association between a CPK and an account. We took this approach 3+ years ago and quickly found that it would be a nightmare to have to contact every server that you've performed a login on to delete the association. Even worse, if you don't do this and the key is compromised, you enable the attacker to gain access to the server without your knowledge. Instead, the server should track an "identity" and that identity will have keys that are currently valid, or that have been revoked (like the following): curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3 The server MUST check the validity of a key before allowing login. There could be cache values / E-Tags associated with keys to make sure that they're being properly cached via HTTP proxies. > o Logout features can be useful for user agents, so HOBA defines a > way to close a current HTTP "session", and also a way to close all > current sessions, even if more than one session is currently active > from different user agents for the same account. Session management absolutely should not be a part of the base specification on HTTP Signatures. It should be layered on top of HTTP signatures. I realize that HOBA might be doing this to "solve" the session login problem on the Web via HTTP Auth once and for all, but this is at the wrong level of abstraction. You can implement sessions on top of HTTP Signatures any way that you would like (session cookies, HTTP headers carrying session information, URL query parameters with session information, etc.). There should be a separation between HTTP Signatures and HTTP session management. 1.2. Terminology ----------------- > also optionally include an HTTP "realm" as defined in the HTTP > authentication specification. We don't use realm as most Access Control List (ACL) systems require far more complicated forms of specifying what the client can and cannot do with a particular CPK. For example, look at the way OAuth is used in Twitter. When you provide a website with a particular OAuth token, you can grant them a number of privileges wrt. your account: let them see my e-mail address, let them tweet on my behalf, let them see my followers, let them see my profile information, etc. These sorts of access grants rarely fit nicely into a "realm" field. We think ACL should be a completely separate spec that is layered on top of HTTP Signatures or HOBA. We don't think it is a good idea to solve the problem at this level. 2. HOBA for Both HTTP Authentication and JavaScript ---------------------------------------------------- > On receipt of a challenge from a server, the client marshals a > to-be- signed blob that includes the web-origin name, the realm, and > the challenge string; and signs that hashed blob using the hash > algorithm identified with the challenge and the private key > corresponding to the CPK for that web-origin. Yikes, this stomps all over the work that Mozilla is doing on Persona (and not in a good way). They seem to have a good solution for this, we should build off of that. The Javascript implementation of HOBA is also a hack in that it shoves authentication parameters into the URL and we /definitely/ don't want a Web where that becomes the norm. If this stuff is going to be integrated into the browser, we should not create a solution that makes it difficult for that to happen. The solution shouldn't have a JavaScript-version and an HTTP-version. It should all run over HTTP, especially since the very large majority of JavaScript environments are capable of accessing and writing HTTP headers. 3. HOBA HTTP Authentication Mechanism -------------------------------------- > On receipt of a challenge from a server, the client marshals a > to-be- signed blob that includes the web-origin name, the realm, and > the challenge string; and signs that hashed blob using the hash > algorithm identified with the challenge and the private key > corresponding to the CPK for that web-origin. This challenge-response-session approach is a tried and true design, but one that's fairly inefficient in that it requires multiple round-trips in the common case between server and client to perform a single authenticated operation. The Web Keys specification takes a different approach in that the server does not need to provide a challenge because the client includes a client-specific time-boxed nonce. The nonce is guaranteed to increment so replay attacks are prevented as long as the server tracks the nonces correctly, which is the same requirement that TLS has. Only the latest nonce per client needs to be tracked for a certain period of time, e.g. 5 minutes, which greatly reduces memory overhead on the server. The downside is that both client and server must have their clocks fairly closely aligned, which is not necessarily a terrible requirement given the state of modern timekeeping technology on the Internet. In the very worst case, the protocol could be expanded such that the server provides a clock timestamp that the client can use to calculate it's own clock skew based on the server's current clock. Using a Linked Data-based identity coupled with an HTTP Signature and a time-boxed nonce allows a client to make a direct signed request to a server in 1 HTTP exchange instead of 2. This is a fairly sharp deviation between the Web Keys + HTTP Signatures spec and the HOBA spec. 4. Using HOBA-http ------------------- > 4.1. CPK Preparation Phase > > In the CPK preparation phase, the client determines if it already > has a CPK for the web-origin it is going to. If the has a CPK, the > client will use it; if the client does not have a CPK, it generates > one in anticipation of the server asking for one. With Web Keys, the client does not create a new CPK for every web-origin. It creates a single CPK for each identity associated with the client. With HOBA, providing a new key for every website that the client visits is overkill and would result in a key management nightmare for the person using a browser. Dialogs would include dozens of keys in the average case, which would be a bit of a usability nightmare. The Web Keys approach is to provide every identity on each device a key. So, if you visit google.com and you have one personal identity and one professional identity, and you use both on your home computer, then your home computer would have two keys regardless of the number of websites that you visit. Those keys would be tied to each public Linked Data identity. > 4.2. Signing Phase > > The user agent tries to access a protected resource on the server. > The server sends the HOBA WWW-Authenticate challenge. The user > agent receives the challenge and signs the challenge using the CPK > it either already had or just generated. The server validates the > signature. If validation fails, the server aborts the transaction. As explained above, the Web Keys + HTTP Signature approach is to not utilize a challenge-response approach, but rather a Linked Data identity coupled with a client-specific time-boxed nonce to achieve the same level of protection. There /could/ be a Web Keys WWW-Authenticate message, but all that would do would be to notify the client that a Web Keys-based authentication should be performed when communicating with the server. > 4.3. Authentication Phase > > In the authentication phase, the server extracts the CPK from the > signing phase and decides if it recognizes the CPK. If the server > recognizes the CPK, the server may finish the client authentication > process. Since the Web Keys specification uses a URL to express the key used for the digital signature, a server can discover the identity associated with the key pretty easily. For example, if this key was specified in the HTTP Signature: https://dev.payswarm.com/i/manu/keys/3 The server would get the key: curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3 look for the owner of the key in the data, which would be: https://dev.payswarm.com/i/manu fetch that profile: curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu and then see if it has that identity on record as having an account on the server. If it does, then it would verify that the key is owned by the profile and check the validity of the signature. 4.3. Authentication Phase -------------------------- The last part of the first paragraph and the last 3 paragraphs should just say that each topic covered is out of scope. The vast majority of this section deals with things that are out of scope for HOBA (and most HTTP Auth schemes). 4.4. Logging in on a New User Agent ------------------------------------ The vast majority of this section is out of scope for this spec as well. 5. Using HOBA-js ----------------- I don't understand why HOBA-http cannot be accomplished via JavaScript and XHR? Why do you need an entirely different way of encoding the HOBA protocol using only URL-based parameters? Unless I'm missing something, the entirety of this section is at the wrong level of abstraction and unnecessary. 6.1. Registration ------------------ This section is interesting because we've been struggling to figure out a way to have UAs automatically (or semi-automatically) create accounts on new web-origins. That said, Mozilla Persona is far ahead of us here, so we should probably just fall in line w/ what they're doing. 6.2. Associating Additional Keys to an Exiting Account ------------------------------------------------------- As explained above, this is unnecessary if you use a Linked Data identity like Web Keys does. You never have to add additional keys to an existing account because the person accessing the site has already paired their device with a key using their Identity Provider. When they hit a web-origin, that association is already complete, therefore there is nothing for the web-origin to do except lookup the key and the identity. In effect, that key is automatically picked up by every website that accesses the Linked Data identity. 6.3. Logging Out ----------------- Again, this is at the wrong level of abstraction, at least as far as Web Keys and HTTP Signatures are concerned. If HOBA is to become a standard way of doing HTTP session management, then this would be fine. That said, I think you'll be competing with Mozilla Persona at that point. ----------------------------------------------------------------------- Hopefully this is helpful to the HOBA editors. I'm having a chat with one of the editors next week and I wanted to make sure to get this out there so he has time to review the comments before our chat. Again, this was just a friendly review of the spec before we try to figure out how we can coordinate this activity between W3C and IETF. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From stephen.farrell@cs.tcd.ie Sun Apr 21 11:14:06 2013 Return-Path: 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 172B721F86EA; Sun, 21 Apr 2013 11:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsQrzvWNTM2g; Sun, 21 Apr 2013 11:14:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8E121F8411; Sun, 21 Apr 2013 11:14:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39FBBBE60; Sun, 21 Apr 2013 19:13:41 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB3yYL5bFFAj; Sun, 21 Apr 2013 19:13:38 +0100 (IST) Received: from [10.87.48.4] (unknown [86.42.31.67]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A83C7BE25; Sun, 21 Apr 2013 19:13:38 +0100 (IST) Message-ID: <51742C51.1010003@cs.tcd.ie> Date: Sun, 21 Apr 2013 19:13:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Manu Sporny References: <5170652F.60609@digitalbazaar.com> <5171233D.303@cs.tcd.ie> <51735AD2.9040900@digitalbazaar.com> In-Reply-To: <51735AD2.9040900@digitalbazaar.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth , Mark Cavage , Web Payments CG , IETF Apps Discuss Subject: Re: [http-auth] Web Keys and HTTP Signatures X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 18:14:06 -0000 HI Manu, Thanks for the thorough review. Some good points and defo a bunch of things to check out... but not today:-) I'll take a better look at this Monday, Cheers, S. On 04/21/2013 04:19 AM, Manu Sporny wrote: > On 04/19/2013 06:58 AM, Stephen Farrell wrote: >>> HTTP Origin-Bound Authentication (HOBA) >>> http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt >>> >>> We had considered signatures in the URL in the second approach to >>> the problem in the Web Keys spec. We eventually rejected the >>> solution because of limitations in the URL length in some browsers >>> and because we wanted the semantics of the HTTP headers to be able >>> to be a part of the digital signature. We also didn't want large >>> signed messages being dumped to the webserver logs (the request >>> line is typically included). So, while HOBA does solve the problem, >>> it doesn't solve it in a way that is acceptable to us. >> >> I think you're misreading the spec a little, or we've written it >> badly:-) > > I did misread the spec a bit, confusing some of the features in other > HTTP Auth specs with some of the HOBA features. So, I took tonight to do > a thorough review of the spec and outline the issues that we have with > the current HOBA spec located at: > > http://tools.ietf.org/html/draft-farrell-httpbis-hoba-02 > > I do agree that we should chat a bit more deeply about HOBA, Web Keys, > Persona, and HTTP Signatures. So, please take this not as negative > feedback, but constructive criticism and the first exchange toward > attempting to map out a way forward for these specs. > > Here's the HOBA spec review from a Web Keys / Web Payments perspective: > > 1. Introduction > ---------------- > >> HOBA also defines some services that are required for modern HTTP >> authentication: >> >> o Servers can bind a CPK with an identifier, such as an account >> name. HOBA allows servers to define their own policies for binding >> CPKs with accounts during account registration. > > While a bit vague, we want to ensure that there is a well-defined way to > do this. We're currently in the process of discussing how this should > happen with the Mozilla Persona team. Ideally, the CPKs are setup or > transmitted to the server when a Persona-like login exchange happens. > We'd like to provide CPKs via some sort of identity expressed as Linked > Data, like the sort that's defined in the Web Keys spec: > > curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu > >> o Users are likely to use more than one device or user agent (UA) >> for the same HTTP based service, so HOBA gives a way to associate >> more than one CPK to the same account, but without having to register >> for each separately. > > +1, the approach above is how we accomplish this for Web Keys. > >> o Users are also likely to lose a private key, or the client's >> memory of which key pair is associated with which origin. For >> example if a user loses the computer or mobile device in which state >> is stored. HOBA allows for clients to tell servers to delete the >> association between a CPK and an account. > > We took this approach 3+ years ago and quickly found that it would be a > nightmare to have to contact every server that you've performed a login > on to delete the association. Even worse, if you don't do this and the > key is compromised, you enable the attacker to gain access to the server > without your knowledge. > > Instead, the server should track an "identity" and that identity will > have keys that are currently valid, or that have been revoked (like the > following): > > curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3 > > The server MUST check the validity of a key before allowing login. There > could be cache values / E-Tags associated with keys to make sure that > they're being properly cached via HTTP proxies. > >> o Logout features can be useful for user agents, so HOBA defines a >> way to close a current HTTP "session", and also a way to close all >> current sessions, even if more than one session is currently active >> from different user agents for the same account. > > Session management absolutely should not be a part of the base > specification on HTTP Signatures. It should be layered on top of HTTP > signatures. I realize that HOBA might be doing this to "solve" the > session login problem on the Web via HTTP Auth once and for all, but > this is at the wrong level of abstraction. You can implement sessions on > top of HTTP Signatures any way that you would like (session cookies, > HTTP headers carrying session information, URL query parameters with > session information, etc.). > > There should be a separation between HTTP Signatures and HTTP session > management. > > 1.2. Terminology > ----------------- > >> also optionally include an HTTP "realm" as defined in the HTTP >> authentication specification. > > We don't use realm as most Access Control List (ACL) systems require far > more complicated forms of specifying what the client can and cannot do > with a particular CPK. > > For example, look at the way OAuth is used in Twitter. When you provide > a website with a particular OAuth token, you can grant them a number of > privileges wrt. your account: let them see my e-mail address, let them > tweet on my behalf, let them see my followers, let them see my profile > information, etc. These sorts of access grants rarely fit nicely into a > "realm" field. We think ACL should be a completely separate spec that is > layered on top of HTTP Signatures or HOBA. We don't think it is a good > idea to solve the problem at this level. > > 2. HOBA for Both HTTP Authentication and JavaScript > ---------------------------------------------------- > >> On receipt of a challenge from a server, the client marshals a >> to-be- signed blob that includes the web-origin name, the realm, and >> the challenge string; and signs that hashed blob using the hash >> algorithm identified with the challenge and the private key >> corresponding to the CPK for that web-origin. > > Yikes, this stomps all over the work that Mozilla is doing on Persona > (and not in a good way). They seem to have a good solution for this, we > should build off of that. The Javascript implementation of HOBA is also > a hack in that it shoves authentication parameters into the URL and we > /definitely/ don't want a Web where that becomes the norm. If this stuff > is going to be integrated into the browser, we should not create a > solution that makes it difficult for that to happen. > > The solution shouldn't have a JavaScript-version and an HTTP-version. It > should all run over HTTP, especially since the very large majority of > JavaScript environments are capable of accessing and writing HTTP headers. > > 3. HOBA HTTP Authentication Mechanism > -------------------------------------- > >> On receipt of a challenge from a server, the client marshals a >> to-be- signed blob that includes the web-origin name, the realm, and >> the challenge string; and signs that hashed blob using the hash >> algorithm identified with the challenge and the private key >> corresponding to the CPK for that web-origin. > > This challenge-response-session approach is a tried and true design, but > one that's fairly inefficient in that it requires multiple round-trips > in the common case between server and client to perform a single > authenticated operation. > > The Web Keys specification takes a different approach in that the server > does not need to provide a challenge because the client includes a > client-specific time-boxed nonce. The nonce is guaranteed to increment > so replay attacks are prevented as long as the server tracks the nonces > correctly, which is the same requirement that TLS has. Only the latest > nonce per client needs to be tracked for a certain period of time, e.g. > 5 minutes, which greatly reduces memory overhead on the server. > > The downside is that both client and server must have their clocks > fairly closely aligned, which is not necessarily a terrible requirement > given the state of modern timekeeping technology on the Internet. In the > very worst case, the protocol could be expanded such that the server > provides a clock timestamp that the client can use to calculate it's own > clock skew based on the server's current clock. > > Using a Linked Data-based identity coupled with an HTTP Signature and a > time-boxed nonce allows a client to make a direct signed request to a > server in 1 HTTP exchange instead of 2. > > This is a fairly sharp deviation between the Web Keys + HTTP Signatures > spec and the HOBA spec. > > 4. Using HOBA-http > ------------------- > >> 4.1. CPK Preparation Phase >> >> In the CPK preparation phase, the client determines if it already >> has a CPK for the web-origin it is going to. If the has a CPK, the >> client will use it; if the client does not have a CPK, it generates >> one in anticipation of the server asking for one. > > With Web Keys, the client does not create a new CPK for every > web-origin. It creates a single CPK for each identity associated with > the client. > > With HOBA, providing a new key for every website that the client visits > is overkill and would result in a key management nightmare for the > person using a browser. Dialogs would include dozens of keys in the > average case, which would be a bit of a usability nightmare. > > The Web Keys approach is to provide every identity on each device a key. > So, if you visit google.com and you have one personal identity and one > professional identity, and you use both on your home computer, then your > home computer would have two keys regardless of the number of websites > that you visit. Those keys would be tied to each public Linked Data > identity. > >> 4.2. Signing Phase >> >> The user agent tries to access a protected resource on the server. >> The server sends the HOBA WWW-Authenticate challenge. The user >> agent receives the challenge and signs the challenge using the CPK >> it either already had or just generated. The server validates the >> signature. If validation fails, the server aborts the transaction. > > As explained above, the Web Keys + HTTP Signature approach is to not > utilize a challenge-response approach, but rather a Linked Data identity > coupled with a client-specific time-boxed nonce to achieve the same > level of protection. > > There /could/ be a Web Keys WWW-Authenticate message, but all that would > do would be to notify the client that a Web Keys-based authentication > should be performed when communicating with the server. > >> 4.3. Authentication Phase >> >> In the authentication phase, the server extracts the CPK from the >> signing phase and decides if it recognizes the CPK. If the server >> recognizes the CPK, the server may finish the client authentication >> process. > > Since the Web Keys specification uses a URL to express the key used for > the digital signature, a server can discover the identity associated > with the key pretty easily. For example, if this key was specified in > the HTTP Signature: https://dev.payswarm.com/i/manu/keys/3 > > The server would get the key: > > curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3 > > look for the owner of the key in the data, which would be: > > https://dev.payswarm.com/i/manu > > fetch that profile: > > curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu > > and then see if it has that identity on record as having an account on > the server. If it does, then it would verify that the key is owned by > the profile and check the validity of the signature. > > 4.3. Authentication Phase > -------------------------- > > The last part of the first paragraph and the last 3 paragraphs should > just say that each topic covered is out of scope. The vast majority of > this section deals with things that are out of scope for HOBA (and most > HTTP Auth schemes). > > 4.4. Logging in on a New User Agent > ------------------------------------ > > The vast majority of this section is out of scope for this spec as well. > > 5. Using HOBA-js > ----------------- > > I don't understand why HOBA-http cannot be accomplished via JavaScript > and XHR? Why do you need an entirely different way of encoding the HOBA > protocol using only URL-based parameters? > > Unless I'm missing something, the entirety of this section is at the > wrong level of abstraction and unnecessary. > > 6.1. Registration > ------------------ > > This section is interesting because we've been struggling to figure out > a way to have UAs automatically (or semi-automatically) create accounts > on new web-origins. That said, Mozilla Persona is far ahead of us here, > so we should probably just fall in line w/ what they're doing. > > 6.2. Associating Additional Keys to an Exiting Account > ------------------------------------------------------- > > As explained above, this is unnecessary if you use a Linked Data > identity like Web Keys does. You never have to add additional keys to an > existing account because the person accessing the site has already > paired their device with a key using their Identity Provider. When they > hit a web-origin, that association is already complete, therefore there > is nothing for the web-origin to do except lookup the key and the > identity. In effect, that key is automatically picked up by every > website that accesses the Linked Data identity. > > 6.3. Logging Out > ----------------- > > Again, this is at the wrong level of abstraction, at least as far as Web > Keys and HTTP Signatures are concerned. If HOBA is to become a standard > way of doing HTTP session management, then this would be fine. That > said, I think you'll be competing with Mozilla Persona at that point. > > ----------------------------------------------------------------------- > > Hopefully this is helpful to the HOBA editors. I'm having a chat with > one of the editors next week and I wanted to make sure to get this out > there so he has time to review the comments before our chat. > > Again, this was just a friendly review of the spec before we try to > figure out how we can coordinate this activity between W3C and IETF. > > -- manu > From msporny@digitalbazaar.com Sun Apr 21 14:18:20 2013 Return-Path: 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 3657D21F8B5F; Sun, 21 Apr 2013 14:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNXlNVAwMeUz; Sun, 21 Apr 2013 14:18:19 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFC321F8682; Sun, 21 Apr 2013 14:18:19 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UU1eF-0003sw-U2; Sun, 21 Apr 2013 17:18:13 -0400 Message-ID: <5174578E.70601@digitalbazaar.com> Date: Sun, 21 Apr 2013 17:18:06 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Cyrus Daboo References: <5170652F.60609@digitalbazaar.com> <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com> In-Reply-To: <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth , Web Payments CG , IETF Apps Discuss Subject: Re: [http-auth] [apps-discuss] Web Keys and HTTP Signatures X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 21:18:20 -0000 On 04/19/2013 11:33 AM, Cyrus Daboo wrote: >> https://github.com/joyent/node-http-signature/blob/master/http_signing.md > > That draft is very similar to the approach we have used in iSchedule > () - > which is an HTTP-based calendar and scheduling messaging protocol. Thanks for the pointer to the draft. I skimmed it and I agree that there are a number of very interesting similarities. > We choose to re-use existing email signing technology - DKIM > () - primarily because the > security model and key management were a good fit for our > application. There is also the benefit of code re-use, and working > with a protocol that is already deployed and used heavily in the > email environment. Also, DKIM was designed with the prospect of > being applicable to protocols beyond email technology - and I think > with iSchedule we have proven it can work with HTTP. Yes, it seems like a very applicable technology for your use case. The one thing I missed is whether or not DKIM allows multiple identities per user in a domain? Does it let users create as many sub-accounts as they want and associate keys with them? Anything is possible, what I'm asking is if this is something that is standardized. Access to DNS places a pretty high bar and we were hoping to lower that by a significant amount with Web Keys. >From my understanding, DKIM defines a domain-level digital signature authentication framework. WebKeys defines a identity-level digital signature authentication framework. Where DKIM uses the DNS system to discover key information for a domain. Web Keys uses the Web and Linked Data formats to discover key information for a particular identity. > I would definitely urge you to take a serious look at DKIM. There > are a number of interesting features there that don't seem to have > been addressed in the draft you cited. In particular dealing with > both header and body canonicalization (headers are particular problem > in HTTP due to intermediaries, caches etc). Yes, Proxy header modification is a problem for Web Keys and HTTP Signatures now. We think we have some working solutions, but won't know for sure until we get some deployment experience with the protocol (or someone that has already been through that pain point can let us know what we're doing wrong). I agree with you. We need to take a serious look at DKIM and your spec and figure out if we missed something obvious with Web Keys and HTTP Signatures. Glancing through your spec sparked a few ideas, so I'm looking forward to a thorough read and review of it wrt. Web Keys and HTTP Signatures. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From mike@mtcc.com Sun Apr 21 14:40:11 2013 Return-Path: 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 1446B21F929E; Sun, 21 Apr 2013 14:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVJbjoVjEnYy; Sun, 21 Apr 2013 14:40:10 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 6916C21F8D2C; Sun, 21 Apr 2013 14:40:10 -0700 (PDT) Received: from piolinux.mtcc.com (65-172-209-232.dsl.volcano.net [65.172.209.232]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r3LLduT2019446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Apr 2013 14:39:57 -0700 Message-ID: <51745CA7.20907@mtcc.com> Date: Sun, 21 Apr 2013 14:39:51 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Manu Sporny References: <5170652F.60609@digitalbazaar.com> <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com> <5174578E.70601@digitalbazaar.com> In-Reply-To: <5174578E.70601@digitalbazaar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1807; t=1366580397; x=1367444397; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20[apps-discuss]=20Web=20Ke ys=20and=20HTTP=20Signatures |Sender:=20 |To:=20Manu=20Sporny=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=s8EamIKRYfgcDQbZV7K8irnk6CgAclrNO7VNDDijtCg=; b=tVQevi6VdKP3D7+1LO0qrBaitfThrfpqkgv0VqY/Z2C0mr7X3DLE4Vl78K 4Z1ItGQHZysnjEp1JkTB86xpq+yPqwTOKCFLOUs1XC8pQIfw72UKbytxT8dK k+/xDQ2iXI9sw9BzqyMoslnAYIq4Ior6SIXkMSb9fMuEhp3lvN3Ds=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Cyrus Daboo , IETF HTTP Auth , IETF Apps Discuss , Web Payments CG Subject: Re: [http-auth] [apps-discuss] Web Keys and HTTP Signatures X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 21:40:11 -0000 Manu Sporny wrote: > Yes, it seems like a very applicable technology for your use case. The > one thing I missed is whether or not DKIM allows multiple identities per > user in a domain? Does it let users create as many sub-accounts as they > want and associate keys with them? Anything is possible, what I'm asking > is if this is something that is standardized. Access to DNS places a > pretty high bar and we were hoping to lower that by a significant amount > with Web Keys. > >>From my understanding, DKIM defines a domain-level digital signature > authentication framework. WebKeys defines a identity-level digital > signature authentication framework. You can have any number of selectors per domain. Selectors can be delegated as needed (or not). Whether it's a good idea to have zillions of records served by given zone is another matter. I assume that an untrusted client has a selector. That is another thing that's worth considering because the use case it's been deployed with is mainly ~trustable entities. I don't see why that would be problem off the top of my head, but it's worth thinking about. > Where DKIM uses the DNS system to discover key information for a domain. > Web Keys uses the Web and Linked Data formats to discover key > information for a particular identity. DKIM uses DNS to store raw public keys. No more, no less. It is linked to a domain insofar as the domain's owners/managers determines what is populated in its zone files. The bigger issue in my mind is whether you need DNSSEC. For mail signing, it was an acceptable risk to not have the keys themselves be signed. If you require that level of protection, then it implies DNSSEC and all of the machinery behind it. Which isn't to say it's not possible, just TANSTAAFL. Mike From mike@mtcc.com Sun Apr 21 15:28:05 2013 Return-Path: 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 6508721F8606; Sun, 21 Apr 2013 15:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1yQ54p36+FC; Sun, 21 Apr 2013 15:28:04 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id B17F721F85EE; Sun, 21 Apr 2013 15:28:04 -0700 (PDT) Received: from piolinux.mtcc.com (65-172-209-232.dsl.volcano.net [65.172.209.232]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r3LMRsFN005687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Apr 2013 15:27:56 -0700 Message-ID: <517467E6.5050407@mtcc.com> Date: Sun, 21 Apr 2013 15:27:50 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Manu Sporny References: <5170652F.60609@digitalbazaar.com> <5171233D.303@cs.tcd.ie> <51735AD2.9040900@digitalbazaar.com> In-Reply-To: <51735AD2.9040900@digitalbazaar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4113; t=1366583277; x=1367447277; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Web=20Keys=20and=20HTTP=2 0Signatures |Sender:=20 |To:=20Manu=20Sporny=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=8ZBasjG/AvuJPxLUB+9nYO6kLTbXp5GcSKFuh6Y3aWE=; b=g3Nj4eog5rEx1C3Pn/riVYayUxMpTVYuVAk6a65IcA2kVQLHvEHK15lhfl oeLUlWyVWf1r0ht0PGkvhlqjuHVz5uv0LibdZ7jFk/JYFKT1lbxUE1+0ZysA BoqFJrlLrSdSWfz2gCWEdsPWDCxuG1qJjLwv22w9BjUHwW1uKQoM8=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: IETF Apps Discuss , IETF HTTP Auth , Web Payments CG , Mark Cavage Subject: Re: [http-auth] Web Keys and HTTP Signatures X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 22:28:05 -0000 Manu Sporny wrote: > The Javascript implementation of HOBA is also > a hack in that it shoves authentication parameters into the URL and we > /definitely/ don't want a Web where that becomes the norm. If this stuff > is going to be integrated into the browser, we should not create a > solution that makes it difficult for that to happen. Um, HOBA-js is just client server protocol. It is completely normal and expected for a web site to define the url parameters coming from the client. There's nothing magical about signature parameters. The one thing that would need to be mentioned is that there is no significance to the parameter names -- there would be no iana registry or anything like that. The client and server would just need to agree to their names and functionality which is nothing different than any other parameter. > The server would get the key: > > curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3 > > look for the owner of the key in the data, which would be: > > https://dev.payswarm.com/i/manu > > fetch that profile: > > curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu > > and then see if it has that identity on record as having an account on > the server. If it does, then it would verify that the key is owned by > the profile and check the validity of the signature. I don't know whether this is relevant, but HOBA doesn't require third parties. It's just a get-rid-of-passwords-as-currently-deployed scheme. As such, it doesn't require 3rd party trust, somebody else's business model, etc. Just drop hoba in and deprecate passwords being stored on servers. I for one would be happy to see a spec that limits itself to just the client server problem so that web sites can get their heads around even that smaller problem without them exploding when you drag 3rd party complexity in. > 4.3. Authentication Phase > -------------------------- > > The last part of the first paragraph and the last 3 paragraphs should > just say that each topic covered is out of scope. The vast majority of > this section deals with things that are out of scope for HOBA (and most > HTTP Auth schemes). > > 4.4. Logging in on a New User Agent > ------------------------------------ > > The vast majority of this section is out of scope for this spec as well. I think you might be taking this draft way too literally. At least from my vantage point, the idea in HOBA for the here and now is to sketch out how this kind of idea could work, and the discussions about session, etc, is to illustrate how it might work with real world sites today with real world session management, etc. That is, you shouldn't read too much normative into this draft. > > 5. Using HOBA-js > ----------------- > > I don't understand why HOBA-http cannot be accomplished via JavaScript > and XHR? Why do you need an entirely different way of encoding the HOBA > protocol using only URL-based parameters? The current draft is an amalgamation of two ideas that are generally similar. I had independently come up with HOBA-js and then noticed Paul and Stephen working on something similar. My idea was to use javascript+crypto libraries and do this entirely at the application layer. Obviously webcrypto would be a huge help, and get rid of dodgy js crypto libraries but it isn't available yet. This blog post documents what I did. http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html I actually have a live implementation that does this. FWIW, it uses time stamps instead of nonces for replay protection. > Unless I'm missing something, the entirety of this section is at the > wrong level of abstraction and unnecessary. It shows that this can be done today, and that it doesn't even require standardization. The reason I put it out there is because crypto is hard to get right, and even if it doesn't _require_ standardization, standardization is a good way of getting clueful eyeballs on would-be crypto deployments. Mike From julian.reschke@gmx.de Tue Apr 23 03:44:10 2013 Return-Path: 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 31FAB21F8D0D for ; Tue, 23 Apr 2013 03:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=-3.925, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqzQ-x67BzCa for ; Tue, 23 Apr 2013 03:44:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 057C721F8D00 for ; Tue, 23 Apr 2013 03:44:08 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0McCWP-1UBXqj3pu3-00JacF for ; Tue, 23 Apr 2013 12:44:06 +0200 Received: (qmail invoked by alias); 23 Apr 2013 10:44:06 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 23 Apr 2013 12:44:06 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+4t+FLzea4+zN66ep0kFxxjFBroNOD8mqRC9kvdM 55NFcuM8mqItN3 Message-ID: <517665EF.3070507@gmx.de> Date: Tue, 23 Apr 2013 12:43:59 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [http-auth] draft-farrell-httpbis-hoba feedback X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 10:44:10 -0000 Hi there, below a few comments wrt to the base HTTP spec. Editorial: the "b64token" ABNF production is now "token68". Furthermore: "The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge/credentials. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions will be impossible." -- ...so why is HOBA using it? Best regards, Julian From stephen.farrell@cs.tcd.ie Tue Apr 23 03:51:37 2013 Return-Path: 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 87E9821F9647 for ; Tue, 23 Apr 2013 03:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0B4SXXzRiS0 for ; Tue, 23 Apr 2013 03:51:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3E921F9627 for ; Tue, 23 Apr 2013 03:51:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A3420BEC9; Tue, 23 Apr 2013 11:51:13 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZB3b7vBgDIm; Tue, 23 Apr 2013 11:51:13 +0100 (IST) Received: from [IPv6:2001:770:10:203:13c:34a0:e749:4270] (unknown [IPv6:2001:770:10:203:13c:34a0:e749:4270]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 849BCBE3E; Tue, 23 Apr 2013 11:51:13 +0100 (IST) Message-ID: <517667A1.4040900@cs.tcd.ie> Date: Tue, 23 Apr 2013 11:51:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Julian Reschke References: <517665EF.3070507@gmx.de> In-Reply-To: <517665EF.3070507@gmx.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-farrell-httpbis-hoba feedback X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 10:51:37 -0000 Hiya, On 04/23/2013 11:43 AM, Julian Reschke wrote: > Hi there, > > below a few comments wrt to the base HTTP spec. > > Editorial: the "b64token" ABNF production is now "token68". Thanks. > Furthermore: > > "The "token68" notation was introduced for compatibility with existing > authentication schemes and can only be used once per > challenge/credentials. New schemes thus ought to use the "auth-param" > syntax instead, because otherwise future extensions will be impossible." Gotta admit I don't get that fully, but fwiw our definite intent is to be a good citizen here. Is there somewhere we're misusing the auth-param thing in the current version? Ta, S. From julian.reschke@gmx.de Tue Apr 23 04:32:54 2013 Return-Path: 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 D8A2021F96D2 for ; Tue, 23 Apr 2013 04:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.739 X-Spam-Level: X-Spam-Status: No, score=-105.739 tagged_above=-999 required=5 tests=[AWL=-3.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBPGOQJquvGz for ; Tue, 23 Apr 2013 04:32:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2596D21F96D1 for ; Tue, 23 Apr 2013 04:32:54 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ly8b5-1UYCNU01KP-015W6f for ; Tue, 23 Apr 2013 13:32:53 +0200 Received: (qmail invoked by alias); 23 Apr 2013 11:32:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 23 Apr 2013 13:32:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/buCtVk8PbmFGR/VI93fdqW08YOwpu1mywfIJ/w7 KFLaf+jJ0DvXMz Message-ID: <5176715E.7030000@gmx.de> Date: Tue, 23 Apr 2013 13:32:46 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Stephen Farrell References: <517665EF.3070507@gmx.de> <517667A1.4040900@cs.tcd.ie> In-Reply-To: <517667A1.4040900@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-farrell-httpbis-hoba feedback X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 11:32:55 -0000 On 2013-04-23 12:51, Stephen Farrell wrote: > > Hiya, > > On 04/23/2013 11:43 AM, Julian Reschke wrote: >> Hi there, >> >> below a few comments wrt to the base HTTP spec. >> >> Editorial: the "b64token" ABNF production is now "token68". > > Thanks. > >> Furthermore: >> >> "The "token68" notation was introduced for compatibility with existing >> authentication schemes and can only be used once per >> challenge/credentials. New schemes thus ought to use the "auth-param" >> syntax instead, because otherwise future extensions will be impossible." > > Gotta admit I don't get that fully, but fwiw our definite intent > is to be a good citizen here. Is there somewhere we're misusing > the auth-param thing in the current version? > ... Currently it says: When the "client response" is created, the HOBA-http client encodes the result as a b64token and returns that b64token in the Authorization header. So this uses the same format as Basic (which is discouraged): Authorization: 12345678 What it *should* use is an auth-param, so something like Authorization: response="12345678" Best regards, Julian From stephen.farrell@cs.tcd.ie Tue Apr 23 06:09:21 2013 Return-Path: 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 ECA1A21F8A80 for ; Tue, 23 Apr 2013 06:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRMxmLO9g7b5 for ; Tue, 23 Apr 2013 06:09:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 596A421F8738 for ; Tue, 23 Apr 2013 06:09:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AAA9CBEC4; Tue, 23 Apr 2013 14:08:58 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8qmgpZbaLsu; Tue, 23 Apr 2013 14:08:58 +0100 (IST) Received: from [IPv6:2001:770:10:203:13c:34a0:e749:4270] (unknown [IPv6:2001:770:10:203:13c:34a0:e749:4270]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8DF65BEAF; Tue, 23 Apr 2013 14:08:58 +0100 (IST) Message-ID: <517687EA.9080502@cs.tcd.ie> Date: Tue, 23 Apr 2013 14:08:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Julian Reschke References: <517665EF.3070507@gmx.de> <517667A1.4040900@cs.tcd.ie> <5176715E.7030000@gmx.de> In-Reply-To: <5176715E.7030000@gmx.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-farrell-httpbis-hoba feedback X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 13:09:21 -0000 On 04/23/2013 12:32 PM, Julian Reschke wrote: > On 2013-04-23 12:51, Stephen Farrell wrote: >> >>> >>> "The "token68" notation was introduced for compatibility with existing >>> authentication schemes and can only be used once per >>> challenge/credentials. New schemes thus ought to use the "auth-param" >>> syntax instead, because otherwise future extensions will be impossible." >> >> Gotta admit I don't get that fully, but fwiw our definite intent >> is to be a good citizen here. Is there somewhere we're misusing >> the auth-param thing in the current version? >> ... > > Currently it says: > > When the "client response" is created, the HOBA-http client encodes > the result as a b64token and returns that b64token in the > Authorization header. > > So this uses the same format as Basic (which is discouraged): > > Authorization: 12345678 > > > What it *should* use is an auth-param, so something like > > Authorization: response="12345678" Ah gotcha, will do that when we re-spin, Thanks, S. > > Best regards, Julian From johnsonhammond2@hushmail.com Sat Apr 27 09:58:19 2013 Return-Path: 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 9E08621F9836 for ; Sat, 27 Apr 2013 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU2BYyqGHfsU for ; Sat, 27 Apr 2013 09:58:19 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2DF21F9835 for ; Sat, 27 Apr 2013 09:58:19 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id 9DB64580A5 for ; Sat, 27 Apr 2013 16:58:18 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 16:58:18 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 6E74E14DBDE; Sat, 27 Apr 2013 16:58:18 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 12:58:18 -0400 To: http-auth@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427165818.6E74E14DBDE@smtp.hushmail.com> Subject: [http-auth] Biggest Fake Conference in Computer Science X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:18:54 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From ynir@checkpoint.com Tue Apr 30 00:22:31 2013 Return-Path: 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 E689A21F9BA3 for ; Tue, 30 Apr 2013 00:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEtFCVg9JSzo for ; Tue, 30 Apr 2013 00:22:26 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B648521F9B9C for ; Tue, 30 Apr 2013 00:22:25 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3U7MNLN025944 for ; Tue, 30 Apr 2013 10:22:23 +0300 X-CheckPoint: {517F7001-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Tue, 30 Apr 2013 10:21:21 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Reminder: Looking for reviewers Thread-Index: AQHORXNQnNg5usCGsUWkSSJrNCEOYw== Date: Tue, 30 Apr 2013 07:21:21 +0000 Message-ID: <6B6B39DB-CC09-419C-9089-1CCEBB0F8B7D@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.185] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <63C36A52C40A45479E278C27896236E8@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Reminder: Looking for reviewers X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 07:22:32 -0000 Hi Folks. On Apris 10th, we issued a call for acceptance for several drafts. One has = since been withdrawn. The remaining ones are (in no particular order): - draft-williams-http-rest-auth - draft-farrell-httpbis-hoba - draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension - draft-melnikov-httpbis-scram-auth We already have 2-3 people who have committed to reviewing each of these dr= afts. Of course we value quality over quantity, but we would like to have s= ome more. So this is a call for volunteers to review these drafts. You don'= t have to be a cryptographer to do these reviews (but if you are, that woul= d be great!). We will ask reviewers to look at security, at implementation = pitfalls, and at barriers to implementation in browsers, programmatic clien= ts, and servers. So if you have a good "feel" for security, we need you. A= nd if you have experience in developing browsers or web applications, espec= ially when such web applications require authentication and are high-value = (think banks, online shopping), we really, really need you. Please send email to the list, or to me directly. Just to get things started, I will review rest-auth and SCRAM. Thanks in advance Matt & Yoav=