From julian.reschke@gmx.de Mon Feb 3 08:40:54 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568481A0121 for ; Mon, 3 Feb 2014 08:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIo37jW4qBQn for ; Mon, 3 Feb 2014 08:40:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B74E11A00E0 for ; Mon, 3 Feb 2014 08:40:51 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LbxQO-1VR9s641Rs-00jHMi for ; Mon, 03 Feb 2014 17:40:51 +0100 Message-ID: <52EFC691.9060304@gmx.de> Date: Mon, 03 Feb 2014 17:40:49 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: public-webpayments@w3.org, "http-auth@ietf.org" References: <52ED42C9.2070809@digitalbazaar.com> <52ED42C9.2070809@digitalbazaar.com> In-Reply-To: <52ED42C9.2070809@digitalbazaar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZHnnJFNBUlrDGU/stvtpV013WUtJ4CZnHDIWYrEfSMId8kYEimV Cl5La28sf8u4Tfbr00nvtVx4OhSm7bj/aIdGFHPHTgzh/AI2oxmIn+paUOdeAUPdw+J+U4L vlHLz6NXHCrfie5PbTEERJFHQm32yKvNUd+DF41dm1lc7nUJPQQbg9LY5ZtrAs8RIIHt6S2 X+vrygagU1IRBEZELyA3Q== Subject: Re: [http-auth] HTTP Signatures specification updated X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 16:40:54 -0000 Manu Sporny: > In order to make Web Payments (and REST APIs in general) more secure on > the Web, this group has been working on extensions to the HTTP protocol > so that you can digitally sign HTTP headers and content. > > We just pushed an update to the specification and believe that it's > ready for public comment. The specification is already deployed in > production at Joyent and Digital Bazaar: > > http://tools.ietf.org/html/draft-cavage-http-signatures-01 > > This technology is useful when you just need to make a secure request to > your financial provider to transmit money from you to someone else, make > a payment, create an invoice, etc. without having to perform a login > handshake (OAuth, user+pass, etc.). > ... Hi Manu, find below my feedback: Technical: 1) The spec seems to be confused about whether it defines an HTTP authentication scheme or not. If it does, it needs to follow the requirements in 6) 1. If the header name is not `request-line` then append the lowercased header name followed with an ASCII colon `:` and an ASCII space ` `. - And the field value? - Also: what if there are multiple instances of a given field name? - What about leading and trailing whitespace in the header field value? 7) Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= - If this is the Digest header field defined in then the spec should say so. 8) Error handling: as this is relevant for security, the spec needs to state how to handle ambiguous values, such as multiple occurrences of the same parameter name in "Authorization". Editorial: - In the boilerplate, please say where to send feedback. - Please cite the HTTPbis drafts instead of RFC 2616. - Please do not cite RFC 2617 except when talking about Basic and Digest - s/header/header field/ - please use symbolic references (xml2rfc PI symrefs="yes") - in xml2rfc, you get appendices by putting
elements into the element - if BNF notation is needed, please use ABNF as defined in RFC 5234. - (IANAL) the statement about Public Domain may or may not be in conflict with the Copyright Statement on the front page - OAuth reference missing - the reference to RFC 3339 seems to be unused Best regards, Julian From julian.reschke@gmx.de Mon Feb 3 08:56:06 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6FD1A0125 for ; Mon, 3 Feb 2014 08:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TysA6hLDwr3k for ; Mon, 3 Feb 2014 08:56:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id C3D3F1A0122 for ; Mon, 3 Feb 2014 08:56:04 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M2WgT-1VHzm50ZkL-00sOqU for ; Mon, 03 Feb 2014 17:56:04 +0100 Message-ID: <52EFCA1F.5070609@gmx.de> Date: Mon, 03 Feb 2014 17:55:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Matthew Lepinski References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> In-Reply-To: <524FD569.9020103@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0://o5/5os7vJWrUNW6LmvznovFSKrH4KY1+aXbcD3HnLsw9l2+BW G7ZFYjMzGywR1RnLiD9oNirrYSpxdNo/7hYbNw8QqUygLtfVhbXUx5+284WIHWzYAlnl99W 6hFju2UDH7FeYah6FRhEft4miAs2sRagntnSRLZv6DHNlMUqGWPbUwwR8p5I6ahf5ApqDfM 47BTgDLcgyj9xtQW9APsw== Cc: http-auth@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 16:56:06 -0000 On 2013-10-05 11:01, Julian Reschke wrote: > On 2013-09-12 12:35, Julian Reschke wrote: >> On 2013-08-21 21:22, Matthew Lepinski wrote: >>> Draft minutes for the HTTP-AUTH session have been posted. >>> >>> They can be found at: >>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>> >>> If you notice any omissions or other errors in the minutes, please let >>> us know. >>> ... >> >> OK, the minutes mention: >> >> "Unicode Normalization : Getting from what is typed in to Unicode code >> points will require discussion" >> >> So how do we proceed from here? Any concrete proposals for what to say? > > It seems we don't know what to say then, right? > > How about: "Beware that differing Unicode normalization forms can cause > interoperability problems. See [http://unicode.org/reports/tr15/]."? > > > Best regards, Julian So, does anybody have a good plan how to approach the normalization problem? Otherwise we'll just have to state that there are dragons out there, and that we don't know the solution... Best regards, Julian From msweet@apple.com Mon Feb 3 09:07:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311EA1A01AF for ; Mon, 3 Feb 2014 09:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G2XC8R0Bfd1 for ; Mon, 3 Feb 2014 09:07:16 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E796B1A016B for ; Mon, 3 Feb 2014 09:07:11 -0800 (PST) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0F004WPJHPMJ91@mail-out.apple.com> for http-auth@ietf.org; Mon, 03 Feb 2014 09:06:43 -0800 (PST) X-AuditID: 11807143-f79f66d0000015d3-a6-52efcca37708 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 2F.28.05587.3ACCFE25; Mon, 03 Feb 2014 09:06:43 -0800 (PST) Received: from [17.153.46.99] (unknown [17.153.46.99]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0F00MC9JJ5K660@aniseed.apple.com> for http-auth@ietf.org; Mon, 03 Feb 2014 09:06:43 -0800 (PST) Content-type: multipart/signed; boundary="Apple-Mail=_805556F7-6537-4094-8129-146BFB7FA1F2"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <52EFCA1F.5070609@gmx.de> Date: Mon, 03 Feb 2014 12:06:42 -0500 Message-id: <8295EEDE-0B44-46E9-8AA2-B9654D9A4D65@apple.com> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1868) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FAsrrv4zPsgg7NLtSw+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHMrV7MVbHKtmPdsDmMD4wLHLkZODgkBE4mJS18yQdhiEhfu rWfrYuTiEBLoZ5I4sfQgM4SzgEni6NIOVpAqYYEsiTf9a5lBbF4BPYmJj56zgBQxC0xhlOh8 uBisiE1ATeL3pD4gm4ODE8g+vb8MJMwioCpx/3MfI4jNLOAssWrPBSaIOTYSh6b0g80UEljE KLHtfgWILSKgJXH73l5GiOtkJb6s62CawMg/C8nqWchWzwKbqy2xbOFr5llAq5kFdCQmL2SE CJtKPHm7nQ3Ctpb4OecRVFxRYkr3Q/YFjOyrGAWKUnMSK430EgsKclL1kvNzNzGCQ7jQeQfj sWVWhxgFOBiVeHg79r4LEmJNLCuuzD3EqAI04tGG1RcYpVjy8vNSlUR4hU6/DxLiTUmsrEot yo8vKs1JLT7EKM3BoiTOm2r0JkhIID2xJDU7NbUgtQgmy8TBKdXAGHWb7VktK7votiPeJVpM CpHeJqIGunOjXkQb66x/9OWt8KF4X3njcHMXuc4i/upS3YTuJYzvvoR1hwZt1EqInyNZcMD/ PPcippXlKW80uYMe/T/y2/Trj2UJl/3YPwn+ffpHd07fpuRdyxqPHnh8Vun/Bx/n4BPCnGmP Hbfvs+37mM4xYRqLEktxRqKhFnNRcSIAkmSMLmkCAAA= Cc: http-auth@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 17:07:24 -0000 --Apple-Mail=_805556F7-6537-4094-8129-146BFB7FA1F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Julian, I thought (perhaps just hoped) we were going to reference RFC 5198 = (network unicode) and provide some words about normalization forms so = that clients and servers don't blindly send and receive UTF-8 regardless = of the normalization form. On Feb 3, 2014, at 11:55 AM, Julian Reschke = wrote: > On 2013-10-05 11:01, Julian Reschke wrote: >> On 2013-09-12 12:35, Julian Reschke wrote: >>> On 2013-08-21 21:22, Matthew Lepinski wrote: >>>> Draft minutes for the HTTP-AUTH session have been posted. >>>>=20 >>>> They can be found at: >>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>>>=20 >>>> If you notice any omissions or other errors in the minutes, please = let >>>> us know. >>>> ... >>>=20 >>> OK, the minutes mention: >>>=20 >>> "Unicode Normalization : Getting from what is typed in to Unicode = code >>> points will require discussion" >>>=20 >>> So how do we proceed from here? Any concrete proposals for what to = say? >>=20 >> It seems we don't know what to say then, right? >>=20 >> How about: "Beware that differing Unicode normalization forms can = cause >> interoperability problems. See [http://unicode.org/reports/tr15/]."? >>=20 >>=20 >> Best regards, Julian >=20 > So, does anybody have a good plan how to approach the normalization = problem? >=20 > Otherwise we'll just have to state that there are dragons out there, = and that we don't know the solution... >=20 > Best regards, Julian >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_805556F7-6537-4094-8129-146BFB7FA1F2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjAzMTcwNjQzWjAjBgkqhkiG9w0BCQQxFgQUDEoVKtAsABQSJSzjFCvv7Q4Q /VgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQCNuJam03O+lmZNlRI5Hc3mBErf8tYjp0I0Frl9ps46ONYMO54LHSMuGZtmxbrDlY5U6jr56qA0 31kWPDwh+BF0s9fWVqB1oTzVsBHpq08wpMVcz2tjvunutfGGIQ8g6vaibVLYI+/aWW0k3fYmjb0k sK4BXVKQMM7YAV30A6LwiiUoXwki6Nrpf/mt0Worzm4aH/wE4Tau/aRZ4omrRjBY1YO9V2q/vzbN 6vzfVrrl349QQAY0GFTsavG2U4XinvaiiPhOAbnScyoXATTfLne9NABT1WWWiqkZiWbEyuK2kOYE 79oIPvhn6Zx19/IGNKzr5sYKYEo3GekgbwDk943sAAAAAAAA --Apple-Mail=_805556F7-6537-4094-8129-146BFB7FA1F2-- From julian.reschke@gmx.de Mon Feb 3 10:11:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC91A01CE for ; Mon, 3 Feb 2014 10:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Xnn4d5Uf_r for ; Mon, 3 Feb 2014 10:10:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB241A01DB for ; Mon, 3 Feb 2014 10:10:58 -0800 (PST) Received: from [192.168.2.117] ([93.217.108.58]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M0smx-1VFFap47v5-00v9wV for ; Mon, 03 Feb 2014 19:10:57 +0100 Message-ID: <52EFDBAF.5030801@gmx.de> Date: Mon, 03 Feb 2014 19:10:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Michael Sweet References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <8295EEDE-0B44-46E9-8AA2-B9654D9A4D65@apple.com> In-Reply-To: <8295EEDE-0B44-46E9-8AA2-B9654D9A4D65@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5hLx2qFtROnQM5iCRfZ465zEEl17LVEIGSqnxtcunkQ24mBJuZR Rxc4/zkO4+5yjDLniTrL3G7p+Ocme/cQpGH+jM7gArJMl9h9UgOe0v9XR+Wk5HVVgCPs1GQ Hgq7QSuTMaJ5nD0gnQnQiSwIDl1UK5kgOFNRUxJMoCkpuGcmD7JyQmhr1JD+VTJMiF0FwK7 W125jmsGAF+gR9KMCiEHA== Cc: http-auth@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 18:11:01 -0000 On 2014-02-03 18:06, Michael Sweet wrote: > Julian, > > I thought (perhaps just hoped) we were going to reference RFC 5198 (network unicode) and provide some words about normalization forms so that clients and servers don't blindly send and receive UTF-8 regardless of the normalization form. > ... Well, what *exactly* should we say, and is that deployable in practice? Best regards, Julian From nico@cryptonector.com Mon Feb 3 10:47:56 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54D31A016D for ; Mon, 3 Feb 2014 10:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMsvTIf-Fhko for ; Mon, 3 Feb 2014 10:47:55 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id AC2C21A0162 for ; Mon, 3 Feb 2014 10:47:55 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id C8987428076 for ; Mon, 3 Feb 2014 10:47:55 -0800 (PST) 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=y85jgw9Nwe7DsWgSPDTf Tjy1PAE=; b=kIfgePpceKagzWYuTSGsY8JpHra5k6rJc1UuXf4FBHYp3ayzD9Vf ulHTEHwEKHttCi4Il1FrvGM3mUd5vnwewLPNMJAkMCDfK3v9JcqS4Y1Fa0COEXlk Sh5gDsARs+Fzcpq5hsq0ZHL/cCZHdAsZNVZrzp/0iqTI3NYawmoLjUk= Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 5B789428078 for ; Mon, 3 Feb 2014 10:47:55 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id x55so2802025wes.4 for ; Mon, 03 Feb 2014 10:47:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9oOcfLToWoT9MyYdKLtztIxP2IeG5jX4+mtXMR+MuLs=; b=PzI0FVkF1OhIFbu/ld/ApjYMl7OOkcAgC+L/FhVgO0OH6jEzpra/A/qWFWArXwJztw vNsdMbIw5RqrYeFvgMm3AjzVKLXN5iSryeGSU7uUXKz7+xmwV9qgt5qgxQzYcNdZRPzw FrnPOKczUKM0vtXtA514ElN2CiH9erL3VgXCgKqVAtB23qol1GXjY0W+GjOqDJLbuS1X QpJ8DElraJVOYKOkaTn+Tpdkrxo0gvDr4y2TQbstGRr1Qx7qzJxnelmRsxblhX7Nx+x3 I2fRFrTQ94AGCx9J2MImacP9AmgY5Hg/LrjsNuXEXZXbDCIpkRQLYDWPQjrZHFuI5rQk goQw== MIME-Version: 1.0 X-Received: by 10.180.101.40 with SMTP id fd8mr4761904wib.1.1391453273637; Mon, 03 Feb 2014 10:47:53 -0800 (PST) Received: by 10.227.198.69 with HTTP; Mon, 3 Feb 2014 10:47:53 -0800 (PST) In-Reply-To: <52EFCA1F.5070609@gmx.de> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> Date: Mon, 3 Feb 2014 12:47:53 -0600 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 18:47:57 -0000 On Mon, Feb 3, 2014 at 10:55 AM, Julian Reschke wrote: > So, does anybody have a good plan how to approach the normalization problem? Strictly in the context of authentication, or more generally in the context of apps like WebDAV? In general, IMO, the best thing to do is to RECOMMEND normalization-insensitive string comparison semantics, applied at the last possible moment, and only if necessary. So, for example, in the case of Basic auth any normalization can be left to the server. But since so many existing servers (all of them using Basic) fail to do this, it may help to RECOMMEND that the client normalize to NFC. In the case of Digest the password needs to be in a canonical form on both sides (I know, the server stores a verifier; that verifier needs to be computed from the canonical password) before proceeding. The same "but" applies to the username and domain as to the username in Basic. In the case of something like a filesystem, file names should be matched in a normalization-insensitive (but preferably form-preserving) manner. But this can only be reasonably implemented in the filesystem itself, not a WebDAV server (or NFSv4, or...), so if the filesystem doesn't do this then the only alternatives are: "tough" and "normalize on CREATE and LOOKUP on the server". Note that normalizing on CREATE and LOOKUP on the client precludes any migration to "the filesystem makes it right" model. All of this applies any time a protocol exposes a "search" or "match" function on Unicode strings. So if a server exposes a "search all documents for input string" function, then it'd be best if the search (and any indexing) could be done in normalization-insensitive, form-preserving manner. All of this applies to Internet protocols in general, not just to HTTP auth. > Otherwise we'll just have to state that there are dragons out there, and > that we don't know the solution... That's fine for HTTP auth. For Latin scripts it really helps that input modes almost universally (if not universally) output pre-composed codepoints. For other scripts the situation may be messier. Nico -- From msweet@apple.com Mon Feb 3 11:25:44 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5473F1A0162 for ; Mon, 3 Feb 2014 11:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rwhg74NaQPT for ; Mon, 3 Feb 2014 11:25:42 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 902AC1A010F for ; Mon, 3 Feb 2014 11:25:42 -0800 (PST) MIME-version: 1.0 Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0F00B8WPYLZM91@mail-out.apple.com> for http-auth@ietf.org; Mon, 03 Feb 2014 11:25:42 -0800 (PST) X-AuditID: 11807157-f79aa6d0000017b2-44-52efed3620c3 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 43.3D.06066.63DEFE25; Mon, 03 Feb 2014 11:25:42 -0800 (PST) Received: from [17.153.46.99] (unknown [17.153.46.99]) by aniseed.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0F00CUWPYTTC30@aniseed.apple.com> for http-auth@ietf.org; Mon, 03 Feb 2014 11:25:42 -0800 (PST) Content-type: multipart/signed; boundary="Apple-Mail=_83C86A95-29C9-4B2E-8676-6C2A77589890"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <52EFDBAF.5030801@gmx.de> Date: Mon, 03 Feb 2014 14:25:42 -0500 Message-id: <1ABEA965-FF69-404F-9595-E384F14B3299@apple.com> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <8295EEDE-0B44-46E9-8AA2-B9654D9A4D65@apple.com> <52EFDBAF.5030801@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1868) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi2FAsrmv29n2Qwe5jOhYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRt+z2II37hWHb/5jbWD85tTFyMkhIWAiMWHnHUYIW0ziwr31 bF2MXBxCAv1MErO7jjNCOAuYJF5+WsYEUiUskCXxpn8tM4jNK6AnMfHRcxaQImaBKYwSd77+ YgNJsAmoSfye1McKYnMC2ZNeTABbwSKgKnH94VywGmYBZ4lVey4wQQyykXj8dhbUtveMEveO bwJrFhHQkrh9by/UfbISX9Z1ME1g5J+FZPksZMtngQ3Wlli28DUzhK0n8bLpHTuEbSrx5O12 qBpriZ9zHjFC2IoSU7ofsi9gZF/FKFCUmpNYaaKXWFCQk6qXnJ+7iREcxoXhOxj/LbM6xCjA wajEw9ux912QEGtiWXFl7iFGFaARjzasvsAoxZKXn5eqJMJ77Pz7ICHelMTKqtSi/Pii0pzU 4kOM0hwsSuK85U+BUgLpiSWp2ampBalFMFkmDk6pBkYZqw1c357v6o9Vi2W9371jnYxS3CST rDeld2ud3eZNUmX+bGp1KPb5Kjnl9E3xcTE9cnu0Nitss7AXVj/zsUjAZvqJxKgIl5sqHbMf MR0uE6uNykiLTpxqdmNWk5OoS4ZVdGtYlsO32/bGsZ6uwmdnms75dkWC/fNNa4YNoTvPFS/5 KpU7S4mlOCPRUIu5qDgRAINNHblrAgAA Cc: http-auth@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 19:25:44 -0000 --Apple-Mail=_83C86A95-29C9-4B2E-8676-6C2A77589890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 3, 2014, at 1:10 PM, Julian Reschke = wrote: > On 2014-02-03 18:06, Michael Sweet wrote: >> Julian, >>=20 >> I thought (perhaps just hoped) we were going to reference RFC 5198 = (network unicode) and provide some words about normalization forms so = that clients and servers don't blindly send and receive UTF-8 regardless = of the normalization form. >> ... >=20 > Well, what *exactly* should we say, and is that deployable in = practice? How about the following (using the Digest draft as a basis, since the = Basic draft currently does not include the charset parameter): 4 Internationalization In challenges, servers SHOULD use the "charset" authentication parameter (case-insensitive) to express the character encoding they expect the user agent to use. The only allowed value is "UTF-8", to be matched case-insensitively, indicating that the server expects the UTF-8 character encoding to be used ([RFC3629][RFC5198]). If the user agent supports the encoding indicated by the server, it MUST use normalization form D as required for the Unicode Format for Network Interchange [RFC5198] and SHOULD add the "charset" parameter, with the value it received from the server, to the Proxy-Authenticate or WWW-Authenticate header fields it sends back to the server. If the user agent does not support the encoding indicated by the server, it MUST fail the request. Servers and user agents that support the "UTF-8" character encoding MUST convert any UTF-8 username or password to NFD prior to applying the hash function. (The latter paragraph can be omitted for the Basic draft...) We should also reference the RFC 3629, section 10 and RFC 5198, section = 6 security considerations sections from the basic and digest security = considerations sections since they talk about common UTF-8 issues for = normalization, string comparison, and so forth. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_83C86A95-29C9-4B2E-8676-6C2A77589890 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMjAzMTkyNTQyWjAjBgkqhkiG9w0BCQQxFgQUE0KJmIVL3Ch3LCnTD0anL8ta BLEwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQAp4BMXXheZ2pkiaaEFBAQ6JvUQQx4oe2fXwKNZvHYTzvDNe15+pKPxThwL1uuhy0vIFwv71cK8 xQ9gNtW8LPlOh7VhpQqV159d+zC0yrpxv0rcyGmg+XX75GUqRg3yVboIf4jnctreYAgT4AZSe72n BdXKnw5fDMU1QnctQE/KGduqnpuIXOS881k5b8jwpmAlZJ0RwwUTOPpJcxOCbKKKjkrwMqC2ohX9 ocAdqeMfo2s0YJ0PlBSHjXYwVoa2YPh92q82QTT/SKRunvvIhRp0bkqzMyJ+ik5BI5lUu6GGUgI1 3qzHXJgUC0ot9nTPcs9Mdu8CYGCQIMKWfgSwIlkhAAAAAAAA --Apple-Mail=_83C86A95-29C9-4B2E-8676-6C2A77589890-- From julian.reschke@gmx.de Mon Feb 3 13:01:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8831A015A for ; Mon, 3 Feb 2014 13:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp3kX4_J47en for ; Mon, 3 Feb 2014 13:01:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5695B1A012E for ; Mon, 3 Feb 2014 13:01:20 -0800 (PST) Received: from [192.168.2.117] ([93.217.108.58]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZlEg-1Vwl8b1kyM-00LVOa for ; Mon, 03 Feb 2014 22:01:19 +0100 Message-ID: <52F0039D.4030808@gmx.de> Date: Mon, 03 Feb 2014 22:01:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nico Williams References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:P//hjXpjg8fpHymx0OsBuf1+oTEY8Z85EeAUOB//i7/tHUSKGfV QbEGyHQxSbnY/ex2aBzZU4MLod93uObYYBwD0pmmJTOodpOWt9r9kpJlz/S33kafw5R+1SA hzZbkft9EJ9UBipZM82qHRxNhz8qrG2SUsMF3oWgprSeBywni1X/goEYCdyNtao5ZQeqXI/ UvE/fILh9qqVcHy/JSBTw== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:01:23 -0000 On 2014-02-03 19:47, Nico Williams wrote: > On Mon, Feb 3, 2014 at 10:55 AM, Julian Reschke wrote: >> So, does anybody have a good plan how to approach the normalization problem? > > Strictly in the context of authentication, or more generally in the > context of apps like WebDAV? Right now just for authentication. > In general, IMO, the best thing to do is to RECOMMEND > normalization-insensitive string comparison semantics, applied at the > last possible moment, and only if necessary. > > So, for example, in the case of Basic auth any normalization can be > left to the server. But since so many existing servers (all of them > using Basic) fail to do this, it may help to RECOMMEND that the client > normalize to NFC. We'll need to make sure that if I type "Ü" in different browsers / on different platforms the right thing happens. Optimally, we'd test what those browsers that do use UTF-8 already do, but I didn't yet have time for this. > ... Best regards, Julian From nico@cryptonector.com Mon Feb 3 13:40:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E430F1A0218 for ; Mon, 3 Feb 2014 13:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88_-BW28Upyg for ; Mon, 3 Feb 2014 13:40:25 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id C0D651A01EE for ; Mon, 3 Feb 2014 13:40:25 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 6EA4E2C806C for ; Mon, 3 Feb 2014 13:40:24 -0800 (PST) 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:content-transfer-encoding; s= cryptonector.com; bh=djwIF4ZzkAOltoti8Q2AD1ezq34=; b=jEFS/0li2SK cBoV8SljbafN7GDUDku/BATEt8I5tdFGF12io37o/o7nj99b/XlURp8jf1gezkXB LoQlSCya0X4aZoNeneW1hZ3BBzZgu8meoh5wDAC0TMh0hdauDBa6sck8rYKKoMso y1ID6J1/YjPUrjwescXw5qpYSaxeTL7Y= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 179132C806B for ; Mon, 3 Feb 2014 13:40:23 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so3273012wes.30 for ; Mon, 03 Feb 2014 13:40:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=u6Fqj/6hkj26QTLEaiBNR4Ff0ofZlFmfwLGLw1sHACs=; b=hKisrR6BP39XP35U7Q8lampmI20q7/FNK/gyQWH9q4kQdQUqcrdWLPoQgbcruY1weB ujLTKAff4Gh79qWEaqNkRP+coyqxcAeqjCcWaijKfSPVWEDZpR+DXstgB98NSZ3Mxe7c VWmbzYwe2OCXp8nW36CRwPC2gHBSeSFbtHkkgRf1ivwW4/rUEaZoW6mi4mm3pi3/TvZT fRGMrnm99Evrt9cXI0cw2ejiQCv7G+h+5WHgTFWTA/YzWuouOxvMCoT29DaIaenGdPLL fu+YgODEaGyZKP8nxI07G2tX6z+1u6xljJPuMBWhr/Gu8nwAgc9V8s+7M1tgToM53rDx E96w== MIME-Version: 1.0 X-Received: by 10.194.185.237 with SMTP id ff13mr373591wjc.64.1391463622531; Mon, 03 Feb 2014 13:40:22 -0800 (PST) Received: by 10.227.198.69 with HTTP; Mon, 3 Feb 2014 13:40:22 -0800 (PST) In-Reply-To: <52F0039D.4030808@gmx.de> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0039D.4030808@gmx.de> Date: Mon, 3 Feb 2014 15:40:22 -0600 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 21:40:27 -0000 On Mon, Feb 3, 2014 at 3:01 PM, Julian Reschke wrot= e: > On 2014-02-03 19:47, Nico Williams wrote: >> >> On Mon, Feb 3, 2014 at 10:55 AM, Julian Reschke >> wrote: >>> >>> So, does anybody have a good plan how to approach the normalization >>> problem? >> >> >> Strictly in the context of authentication, or more generally in the >> context of apps like WebDAV? > > > Right now just for authentication. OK. BTW, this has come up recently in the context of SASL and PRECIS. The point: it's not just about HTTP; similar issues come up in other contexts. Also: it's not just about authentication; similar issues come up in other contexts. Generic advice would be nice to give in an Informational/BCP RFC. I'd bolunteer to write one (since I have a fair portion of one written). >> So, for example, in the case of Basic auth any normalization can be >> left to the server. But since so many existing servers (all of them >> using Basic) fail to do this, it may help to RECOMMEND that the client >> normalize to NFC. > > We'll need to make sure that if I type "=C3=9C" in different browsers / o= n > different platforms the right thing happens. Optimally, we'd test what th= ose > browsers that do use UTF-8 already do, but I didn't yet have time for thi= s. I suspect that browsers depend on native input methods exclusively, but maybe nowadays browsers have enough functionality not found in native input methods that they must implement their own? When I last looked into input methods (some years ago) I found that Windows, OS X, Solaris, and Linux all output pre-computed codepoints for Latin script characters I knew how to input (e.g., using Compose key sequences or US-International keyboard layouts). I very much doubt that any input modes produce NFC, or NFD. I suspect that they produce whatever is most convenient to produce given the Compose / international keyboard layout input sequence, and internal details (mapping tables). The thing I found fascinating (and obnoxious) was that OS X's input modes output pre-composed sequences but HFS+ would normalize to NFD on CREATE. A recipe for disaster (with a lower-case 'd' anyways) IMO. This was one of the things that led to ZFS implementing a form-insensitive/form-preserving scheme. Oh, and another thing I found fascinating was less than universal support for rendering decomposed sequences; I forget which OSes could and which couldn't. IIRC Solaris and Linux couldn't. That testing was too long ago -and too focused on Latin- to be of any value now. Fairly comprehensive tests need to be done now. Nico -- From msweet@apple.com Mon Feb 3 14:10:13 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07641A0232 for ; Mon, 3 Feb 2014 14:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVu_gw5c1RiF for ; Mon, 3 Feb 2014 14:10:12 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 10EE51A01EE for ; Mon, 3 Feb 2014 14:10:12 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0N0F004YKXKQMJ22@mail-out.apple.com> for http-auth@ietf.org; Mon, 03 Feb 2014 14:10:12 -0800 (PST) X-AuditID: 11807157-f79aa6d0000017b2-e6-52f013c30cce Received: from haralson.apple.com (haralson.apple.com [17.171.2.64]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 51.FF.06066.3C310F25; Mon, 03 Feb 2014 14:10:12 -0800 (PST) Received: from [10.0.1.21] (208-96-65-222.eastlink.ca [208.96.65.222]) by haralson.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N0F0077IXKYTN00@haralson.apple.com> for http-auth@ietf.org; Mon, 03 Feb 2014 14:10:11 -0800 (PST) References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <8295EEDE-0B44-46E9-8AA2-B9654D9A4D65@apple.com> <52EFDBAF.5030801@gmx.de> <1ABEA965-FF69-404F-9595-E384F14B3299@apple.com> In-reply-to: <1ABEA965-FF69-404F-9595-E384F14B3299@apple.com> Message-id: X-Mailer: iPad Mail (11B554a) From: Michael Sweet Date: Mon, 03 Feb 2014 17:10:11 -0500 To: Julian Reschke X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiuJrJQfeI8Icgg5XbmCw+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJcr57MXPBKuOP32J2MD4z/+LkZODgkBE4kV3x4xQdhiEhfu rWfrYuTiEBLoZ5I4ufs2K4SzkUnixPdpjCBVQgKLmCQePc3qYuTg4BSwlfi4UhAkzCsgLvH6 6BSwEmYBbYkn7y6wQthaEut3HmeCqLGReHhoCztEXFdi6cluRojFshJnbk8Bi7MJqEn8ntQH 1isskCXxpn8tM4jNIqAqsbVrJxuILQI08/a9vYwTGAVmIVk9C8nqWUhWL2BkXsUoUJSak1hp opdYUJCTqpecn7uJERR4DYXhOxj/LbM6xCjAwajEw9ux912QEGtiWXFl7iFGCQ5mJRFeA2DY CvGmJFZWpRblxxeV5qQWH2KU5mBREuctf/o+SEggPbEkNTs1tSC1CCbLxMEp1cA4y/0i50zO RSHdbw+VnYjw/X3ogo7j4hdsPjZcbW3hR4/m32go0T9qcTf02Y2IFvO7ul+nvV5z+nx75GfW 5txW8QVtNp+jrjZ58E3eLJ45/YPli19Rm5+/d9/gfr7llpZfWYXugeunTvS8X3ir91qhyUzG /TWxeR48lY9VPTPSSipnMHxWY7utxFKckWioxVxUnAgABZyBYDgCAAA= Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:10:14 -0000 Err, make that *NFC*, not NFD. That'll teach me to send an email on my way out the door... Sent from my iPad > On Feb 3, 2014, at 2:25 PM, Michael Sweet wrote: > >> On Feb 3, 2014, at 1:10 PM, Julian Reschke wrote: >>> On 2014-02-03 18:06, Michael Sweet wrote: >>> Julian, >>> >>> I thought (perhaps just hoped) we were going to reference RFC 5198 (network unicode) and provide some words about normalization forms so that clients and servers don't blindly send and receive UTF-8 regardless of the normalization form. >>> ... >> >> Well, what *exactly* should we say, and is that deployable in practice? > > How about the following (using the Digest draft as a basis, since the Basic draft currently does not include the charset parameter): > > 4 Internationalization > > In challenges, servers SHOULD use the "charset" authentication > parameter (case-insensitive) to express the character encoding they > expect the user agent to use. > > The only allowed value is "UTF-8", to be matched case-insensitively, > indicating that the server expects the UTF-8 character encoding to be > used ([RFC3629][RFC5198]). > > If the user agent supports the encoding indicated by the server, it > MUST use normalization form D as required for the Unicode Format for > Network Interchange [RFC5198] and SHOULD add the "charset" parameter, > with the value it received from the server, to the Proxy-Authenticate > or WWW-Authenticate header fields it sends back to the server. > > If the user agent does not support the encoding indicated by the > server, it MUST fail the request. > > Servers and user agents that support the "UTF-8" character encoding > MUST convert any UTF-8 username or password to NFD prior to applying > the hash function. > > (The latter paragraph can be omitted for the Basic draft...) > > We should also reference the RFC 3629, section 10 and RFC 5198, section 6 security considerations sections from the basic and digest security considerations sections since they talk about common UTF-8 issues for normalization, string comparison, and so forth. > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nico@cryptonector.com Mon Feb 3 14:40:58 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F031A0271 for ; Mon, 3 Feb 2014 14:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTU0nF35mCTi for ; Mon, 3 Feb 2014 14:40:57 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2C01A015D for ; Mon, 3 Feb 2014 14:40:57 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 5B4A42F406A for ; Mon, 3 Feb 2014 14:40:57 -0800 (PST) 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=a1Iqe7Q8XpPKuhRvnRRR SM/i4bU=; b=pdAGecgFMWuh2nF7NIgi+o5+vF5CEBC7POvh/JzdXCovHzAk2x1T EJSDDQeYa3S0/lOHKNLz3N1vA/DnEPTdtAevXRyJOCPvXumIgeEvzOUJ9iS97cb/ eh3RkmCXktxdbpB8ChFhPZfcG1YXOa//YG7gLnBoOX4Ir78HC+8qino= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id F21DC2F4060 for ; Mon, 3 Feb 2014 14:40:56 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id x55so3289719wes.5 for ; Mon, 03 Feb 2014 14:40:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VJA0n2EPuzGOPh402eWhLnInwH4womRRBVT3fD9b5YA=; b=J4hb9Y35M198HorZLS7eZsD1Jd3aFuIkZoNX1F2LPRIWNxrBki8aPW72Dk2O1HcpoM JSCJs9/NOMp9o13ZljzQR+EBxWuyD5vuu/4KmVMimo0xh5s3liCHYbEHmhQicY45uqBV cpuIwPElt0YD1HBJ18h3RCtmVkhs+nZUYYZL6D7N2m6KZAupcJ3CWklTxC9CvD7WkKXu aBMj28rcLxXUozuDiB99mmLf0hSQbCh+GcVEG30EMs3k/kBOidt2eAZ0aD6hEafxjcgx r1eis4AliSUbyqBCwcjZ20rS4ckqkF1guy9PEtUH7qclCPPuyYJZ9z03aw3M9/i49qg0 F/2w== MIME-Version: 1.0 X-Received: by 10.180.101.40 with SMTP id fd8mr5316907wib.1.1391467255450; Mon, 03 Feb 2014 14:40:55 -0800 (PST) Received: by 10.227.198.69 with HTTP; Mon, 3 Feb 2014 14:40:55 -0800 (PST) In-Reply-To: References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <8295EEDE-0B44-46E9-8AA2-B9654D9A4D65@apple.com> <52EFDBAF.5030801@gmx.de> <1ABEA965-FF69-404F-9595-E384F14B3299@apple.com> Date: Mon, 3 Feb 2014 16:40:55 -0600 Message-ID: From: Nico Williams To: Michael Sweet Content-Type: text/plain; charset=UTF-8 Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:40:58 -0000 On Mon, Feb 3, 2014 at 4:10 PM, Michael Sweet wrote: > Err, make that *NFC*, not NFD. That'll teach me to send an email on my way out the door... I'd make it a SHOULD, not a MUST, explaining the likely result if one does not normalize to NFC and what users can do about any non-interop resulting from clients failing to normalize. This is to document what happens now and how users can deal with it (e.g., mostly by either avoiding characters with multiple forms, or by avoiding systems whose input modes do not produce expected results (NFC), which is, after all, what basically happens every day). Nico -- From y.oiwa@aist.go.jp Mon Feb 3 16:18:38 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A0E1A02BA for ; Mon, 3 Feb 2014 16:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yQ9Qw-6STKt for ; Mon, 3 Feb 2014 16:18:36 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id DDF931A02A0 for ; Mon, 3 Feb 2014 16:18:35 -0800 (PST) Received: from mail-ve0-f170.google.com ([209.85.128.170]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUvAx2+AXXNjMXy1K0eLsLX8yzlWb9kcE@postini.com; Mon, 03 Feb 2014 16:18:36 PST Received: by mail-ve0-f170.google.com with SMTP id cz12so5519514veb.15 for ; Mon, 03 Feb 2014 16:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fqwaK3F6W1EAaOeN7KfsH1QiM0CJliyYpJuPM/soF8g=; b=b6kB6n/x17YQFm7MD49ROnW13yXSm01sO7c2M8Rel8m1uq4q60vy6UdUaLLUPpoNfa lge7vbhg3cph4puQlxOhPee421hDF966gp/h0GQn235E+3rze26n7QJMR0LYdVo9L8qi YYaIYZV8SharrXmrCg2p8rTnSEL3j62O3xGQo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fqwaK3F6W1EAaOeN7KfsH1QiM0CJliyYpJuPM/soF8g=; b=Wcxqp4WMvRtb4uduhBnDypni3poNYS7WYPlPU6wOzmZEuDLBdUVOb4RKxpZh42n+lp A+450977ZGQNw+G+RTgh8bWay3d4+X0enTdDdO3nJ3cl9jZMETgFCFQfnJAcd8fAW/LZ imYgaFheWfD9ysNCOns73e/hlrVrFclLCNyYJjaOKeXppghOwTKVXnid+8Wft1tf3aMm i/QSdmWoZC/H7m4IG5RemjucxYMsK6SIPfIl0hG2BiRKd9zHD0Qs7+jbxquvnt2fcmW2 VVsHNrWNUSj9cxB59rxZeXeZ8teOdahkL98CtWHXWt2nKnUVVClnvulBHqd6E/FOBThu yEuQ== X-Gm-Message-State: ALoCoQkFTP0smipUCEi6P65T6dh4bVM0xNBh+g3axzwJCoPbde+E808PXUr/Azf4l7NdO0bWAe+3loHjUcjhl1rldaVFcCLSydxZ6/Hi9qob2H0sN5OESiLOPaGSa4s/Nj+mg3MxITM+uK5oAXKJ4d0nysL3b7nVAQ== X-Received: by 10.52.117.115 with SMTP id kd19mr25494575vdb.15.1391473115199; Mon, 03 Feb 2014 16:18:35 -0800 (PST) X-Received: by 10.52.117.115 with SMTP id kd19mr25494568vdb.15.1391473115098; Mon, 03 Feb 2014 16:18:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Mon, 3 Feb 2014 16:18:14 -0800 (PST) In-Reply-To: <52EFCA1F.5070609@gmx.de> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> From: Yutaka OIWA Date: Tue, 4 Feb 2014 09:18:14 +0900 Message-ID: To: Julian Reschke , Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" , precis@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 00:18:38 -0000 Dear Julian and Peter (added), how about the things ongoing about handling of HTTP-AUTH normalization in context of PRECIS? I proposed general-purpose HTTP-AUTH normalization profile to PRECIS WG (just because I need it :-), and they considered merging it with new SASLPREPbis. My current draft is http://tools.ietf.org/html/draft-oiwa-precis-httpauthprep-00 . SASLPREPbis is in WG pool as http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-06 . I am awaiting actions for whether the merging will actually happen or not. In my understanding, removing of SASL-dependent natures (e.g. that in Username grammer) from current saslprepbis is not going forward yet, and current SASLPREPbis is, at least personally, not applicable for any HTTP auth schemes except SASL-backed ones. For clarify, SASLPREPbis is really good, and the differences are not large but critical. I think there is several possible directions for us to go: 1) Go merging: push forward to make saslprepbis a general-purpose precis profile by separating still-remaining SASL-only features. IMO, in this case we may need two separate application notes documents for SASL and HTTP-AUTH. 2) Go separate: discuss HTTPAUTH in context of PRECIS separately from SASLPREP. I believe that my draft will give us a good starting point, as my best effort. 3) for Julian, one possible best current cheating, if you can't wait PRECIS WG, might be just specify NFC as a canonical form. Both SASLPREP and HTTPAUTHprep (and many other PRECIS profiles) are NFC based, so it will not likely harm future development of proper PRECIS-based "preparation" (including normalization). Also, I would be happy if Julian (as talked in Vancouver) and other people in HTTPAUTH WG and PRECIS WG could give us a feedback on my proposal from the both WG's points of view. 2014-02-04 Julian Reschke : > On 2013-10-05 11:01, Julian Reschke wrote: >> >> On 2013-09-12 12:35, Julian Reschke wrote: >>> >>> On 2013-08-21 21:22, Matthew Lepinski wrote: >>>> >>>> Draft minutes for the HTTP-AUTH session have been posted. >>>> >>>> They can be found at: >>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>>> >>>> If you notice any omissions or other errors in the minutes, please let >>>> us know. >>>> ... >>> >>> >>> OK, the minutes mention: >>> >>> "Unicode Normalization : Getting from what is typed in to Unicode code >>> points will require discussion" >>> >>> So how do we proceed from here? Any concrete proposals for what to say? >> >> >> It seems we don't know what to say then, right? >> >> How about: "Beware that differing Unicode normalization forms can cause >> interoperability problems. See [http://unicode.org/reports/tr15/]."? >> >> >> Best regards, Julian > > > So, does anybody have a good plan how to approach the normalization problem? > > Otherwise we'll just have to state that there are dragons out there, and > that we don't know the solution... > > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 nico@cryptonector.com Mon Feb 3 16:32:15 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA021A026A; Mon, 3 Feb 2014 16:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNGw2-T88cW2; Mon, 3 Feb 2014 16:32:14 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF181A0264; Mon, 3 Feb 2014 16:32:14 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id D42612005D105; Mon, 3 Feb 2014 16:32:13 -0800 (PST) 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=h1e6PNoE2SLLI9viwhHE 7XN1BGo=; b=otROKLRJQ3+3Jdwbp0XUNAjPOehxSwGSSb/J+Txik50LmReibDqR nJt4uZkXxBm7mHyITGbt+OVCXz90CjApxDj2uOCWU0kfHumndDH/puLxik6170VL 9aqjuwnNjXRmQ/1X+fmBdmqDjvV+3ogd4aRtbtrAY7WYdvgwtLSlUxI= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 584452005D107; Mon, 3 Feb 2014 16:32:13 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id w61so3467181wes.12 for ; Mon, 03 Feb 2014 16:32:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vXFMVFTPhrMNZyrd/wXhkUVkUj3p0HAcNLsl7tssS4c=; b=OsKGQy1v7j0iz//ir9ijyzVqxmVBxBHOX7b0jqZacYGyPNJSBpa52tcdS5qGMy+3wW BE3HKPDzkTe8iIWeqdUP56rXIN6F68rnkOh8Eu2WYW4Pm3uAPE7ZFA7ac3i28spGImso 23X+dIK/o7zgYYI+Q/TqiQXVWB1cBmkSpsIi5Y55AIi/r1Q0/7SyfieD/4rrb0Lpoaay a4zCu4VPiJFguGfUVLI8D8WqF4Gy7wFNnrsVkZT6Gz0ZFGbK4vFylugGXdCi1cviCcFD u/ARhMgcSoLVI0OmhfevLDpOqwBGUytShIjLf1c9siBZ9nFDDw7UCP/4mQVtc+AaQOfW SlPQ== MIME-Version: 1.0 X-Received: by 10.194.86.200 with SMTP id r8mr3625083wjz.49.1391473931578; Mon, 03 Feb 2014 16:32:11 -0800 (PST) Received: by 10.227.198.69 with HTTP; Mon, 3 Feb 2014 16:32:11 -0800 (PST) In-Reply-To: References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> Date: Mon, 3 Feb 2014 18:32:11 -0600 Message-ID: From: Nico Williams To: Yutaka OIWA Content-Type: text/plain; charset=UTF-8 Cc: Julian Reschke , "http-auth@ietf.org" , "precis@ietf.org" , Peter Saint-Andre Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 00:32:15 -0000 +1 to using/referencing PRECIS, but first make sure that it doesn't continue to say anything inappropriate about case folding. Nico -- From stpeter@stpeter.im Mon Feb 3 18:31:57 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC1D1A0251; Mon, 3 Feb 2014 18:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jguE6dz2qoEk; Mon, 3 Feb 2014 18:31:56 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB391A01B6; Mon, 3 Feb 2014 18:31:56 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 320C34010C; Mon, 3 Feb 2014 19:31:55 -0700 (MST) Message-ID: <52F0511A.5010200@stpeter.im> Date: Mon, 03 Feb 2014 19:31:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nico Williams , Yutaka OIWA References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "http-auth@ietf.org" , "precis@ietf.org" Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 02:31:57 -0000 On 2/3/14, 5:32 PM, Nico Williams wrote: > +1 to using/referencing PRECIS, but first make sure that it doesn't > continue to say anything inappropriate about case folding. Nico, as you might recall, with your help we revised the saslprepbis document to remove the inappropriate text about case folding. :-) Also, after talking with Yutaka and Julian at the last IETF meeting, personally I concluded that we do indeed need a separate PRECIS profile for HTTPAUTH (not merge it into saslprepbis). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Feb 3 18:33:58 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FCB1A0257; Mon, 3 Feb 2014 18:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRv_RcLeShiM; Mon, 3 Feb 2014 18:33:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B81FE1A0251; Mon, 3 Feb 2014 18:33:55 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F19CC4010C; Mon, 3 Feb 2014 19:33:49 -0700 (MST) Message-ID: <52F0518C.9060506@stpeter.im> Date: Mon, 03 Feb 2014 19:33:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yutaka OIWA , Julian Reschke References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , precis@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 02:33:58 -0000 Yes, I think it is best to define a separate profile for HTTPAUTH (based on various conversations at the last IETF meeting). I will try to review your document again very soon. Peter On 2/3/14, 5:18 PM, Yutaka OIWA wrote: > Dear Julian and Peter (added), > > how about the things ongoing about handling of > HTTP-AUTH normalization in context of PRECIS? > > I proposed general-purpose HTTP-AUTH normalization > profile to PRECIS WG (just because I need it :-), > and they considered merging it with new SASLPREPbis. > My current draft is > http://tools.ietf.org/html/draft-oiwa-precis-httpauthprep-00 . > SASLPREPbis is in WG pool as > http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-06 . > > I am awaiting actions for whether the merging > will actually happen or not. > In my understanding, removing of SASL-dependent > natures (e.g. that in Username grammer) from current > saslprepbis is not going forward yet, and current > SASLPREPbis is, at least personally, not applicable > for any HTTP auth schemes except SASL-backed ones. > For clarify, SASLPREPbis is really good, and the differences > are not large but critical. > > I think there is several possible directions for us to go: > > 1) Go merging: push forward to make saslprepbis a > general-purpose precis profile by separating > still-remaining SASL-only features. > IMO, in this case we may need two separate > application notes documents for SASL and HTTP-AUTH. > > 2) Go separate: discuss HTTPAUTH in context of > PRECIS separately from SASLPREP. > I believe that my draft will give us a good starting point, > as my best effort. > > 3) for Julian, one possible best current cheating, if you > can't wait PRECIS WG, might be just specify NFC as a > canonical form. Both SASLPREP and HTTPAUTHprep > (and many other PRECIS profiles) are NFC based, > so it will not likely harm future development of proper > PRECIS-based "preparation" (including normalization). > > Also, I would be happy if Julian (as talked in Vancouver) > and other people in HTTPAUTH WG and PRECIS WG > could give us a feedback on my proposal from the > both WG's points of view. > > 2014-02-04 Julian Reschke : >> On 2013-10-05 11:01, Julian Reschke wrote: >>> >>> On 2013-09-12 12:35, Julian Reschke wrote: >>>> >>>> On 2013-08-21 21:22, Matthew Lepinski wrote: >>>>> >>>>> Draft minutes for the HTTP-AUTH session have been posted. >>>>> >>>>> They can be found at: >>>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>>>> >>>>> If you notice any omissions or other errors in the minutes, please let >>>>> us know. >>>>> ... >>>> >>>> >>>> OK, the minutes mention: >>>> >>>> "Unicode Normalization : Getting from what is typed in to Unicode code >>>> points will require discussion" >>>> >>>> So how do we proceed from here? Any concrete proposals for what to say? >>> >>> >>> It seems we don't know what to say then, right? >>> >>> How about: "Beware that differing Unicode normalization forms can cause >>> interoperability problems. See [http://unicode.org/reports/tr15/]."? >>> >>> >>> Best regards, Julian >> >> >> So, does anybody have a good plan how to approach the normalization problem? >> >> Otherwise we'll just have to state that there are dragons out there, and >> that we don't know the solution... >> >> >> Best regards, Julian >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > > -- Peter Saint-Andre https://stpeter.im/ From mnot@mnot.net Mon Feb 3 18:54:36 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587421A034F for ; Mon, 3 Feb 2014 18:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkifr1JpPJog for ; Mon, 3 Feb 2014 18:54:34 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CA3891A0345 for ; Mon, 3 Feb 2014 18:54:33 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.1.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4EF4722E1F4; Mon, 3 Feb 2014 21:54:27 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: <52EFC691.9060304@gmx.de> Date: Tue, 4 Feb 2014 13:54:22 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <21862A74-9B9A-40D5-BCAE-61C491F793FE@mnot.net> References: <52ED42C9.2070809@digitalbazaar.com> <52ED42C9.2070809@digitalbazaar.com> <52EFC691.9060304@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1827) Cc: "http-auth@ietf.org" , public-webpayments@w3.org Subject: Re: [http-auth] HTTP Signatures specification updated X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 02:54:36 -0000 Since we're giving feedback on this: * There are many ways that signatures could be useful in HTTP, and this = is just one way. So, "HTTP Signatures" is a terrible name for this; it's = way to generic. Please change it. Suggestion: "The 'Signature' HTTP = Authentication Scheme' (but see Julian's comment below). * Abstract - The term 'origin' is defined by RFC6454, and I don't think = that's how you're using it here; at best, you're authenticating the = client *to* the origin.=20 * 1. Introduction - this is a protocol extension, not a protocol in and = of itself. * 1. Introduction - "However, it is common place..." -- this sentence is = probably going to get you in more trouble than it's worth :) Recommend = dropping it. Also, you don't cover why Digest auth isn't good. * 2.1.1.2 algorithm - "The full list of supported signature mechanisms = is listed below." This sort of thing is usually delegated to a = registry, so that you don't have to revise the whole spec to modify the = list. Also, "supported" is odd here, because this is a protocol = specification, not a product specification. * 2.1.1.3 headers - Signing the *whole* request-line is a very bad idea, = because the HTTP version is a hop-by-hop artefact, not end-to-end. Also, = the spacing of the request-line can be irregular. I'd suggest you define = how to canonicalise the request method + URI (ideally, the effective = request URI, *not* the request-target; see = ). * 2.1.2 Signature String Construction - You need to define how to = canonicalise headers before processing, taking into account that headers = can recur, have varying whitespace between the field-name, colon and = value, whitespace at the EOL and varying line termination. =20 * You don't define a corresponding challenge. Your use cases might not = require a 401 + WWW-Authenticate, but have you considered that some will = want this? A few more comments below. On 4 Feb 2014, at 3:40 am, Julian Reschke wrote: > Manu Sporny: >> In order to make Web Payments (and REST APIs in general) more secure = on >> the Web, this group has been working on extensions to the HTTP = protocol >> so that you can digitally sign HTTP headers and content. >>=20 >> We just pushed an update to the specification and believe that it's >> ready for public comment. The specification is already deployed in >> production at Joyent and Digital Bazaar: >>=20 >> http://tools.ietf.org/html/draft-cavage-http-signatures-01 >>=20 >> This technology is useful when you just need to make a secure request = to >> your financial provider to transmit money from you to someone else, = make >> a payment, create an invoice, etc. without having to perform a login >> handshake (OAuth, user+pass, etc.). >> ... >=20 > Hi Manu, >=20 > find below my feedback: >=20 > Technical: >=20 > 1) The spec seems to be confused about whether it defines an HTTP = authentication scheme or not. If it does, it needs to follow the = requirements in = .=20= > 2) > REQUIRED. The `algorithm` parameter is used if the client and = server > agree on a non-standard digital signature algorithm. The full list > of supported signature mechanisms is listed below. >=20 > - This should be aligned with other IETF specs using algorithm names. >=20 > 3) > OPTIONAL. The `headers` parameter is used to specify the list of > HTTP headers used to sign the request. If specified, it should be a > quoted list of HTTP header names, separated by a single space > character. By default, only one HTTP header is signed, which is the > `Date` header. Note that the list MUST be specified in the order = the > values are concatenated together during signing. To include the = HTTP > request line in the signature calculation, use the special `request- > line` value. While this is overloading the definition of `headers` > in HTTP linguism, the request-line is defined in RFC 2616 [RFC2616], > and as the outlier from headers in useful signature calculation, it > is deemed simpler to use `request-line` than to add a separate > parameter for it. >=20 > - just state that the list order is significant for the signature = algorithm >=20 > - for request-line, just pick a name that is guaranteed not to = conflict (such as "(request-line)"). That being said, the request line = is gone from HTTP/2, and it might be good to break the information down = into components that are more generic. >=20 > 4) > OPTIONAL. The `extensions` parameter is used to include additional > information which is covered by the request. The content and format > of the string is out of scope for this document, and expected to be > specified by implementors. >=20 > - the BNF says 'ext' >=20 > - this will make it incredible hard to have more than one extension. = why not allow extension specs to use (and register) new parameter names? >=20 >=20 > 5) > REQUIRED. The `signature` parameter is a `Base64` encoded digital > signature generated by the client. The client uses the `algorithm` > and `headers` request parameters to form a canonicalized `signing > string`. This `signing string` is then signed with the key > associated with `keyId` and the algorithm corresponding to > `algorithm`. The `signature` parameter is then set to the `Base64` > encoding of the signature. >=20 > - Which base64? Please pick a concrete on, such as the one defined in = >=20 > 6) > 1. If the header name is not `request-line` then append the > lowercased header name followed with an ASCII colon `:` and an > ASCII space ` `. >=20 > - And the field value? >=20 > - Also: what if there are multiple instances of a given field name? >=20 > - What about leading and trailing whitespace in the header field = value? >=20 > 7) > Digest: SHA-256=3DX48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=3D >=20 > - If this is the Digest header field defined in = then the spec should = say so. This confused me too. >=20 > 8) Error handling: as this is relevant for security, the spec needs to = state how to handle ambiguous values, such as multiple occurrences of = the same parameter name in "Authorization". >=20 >=20 > Editorial: >=20 > - In the boilerplate, please say where to send feedback. >=20 > - Please cite the HTTPbis drafts instead of RFC 2616. >=20 > - Please do not cite RFC 2617 except when talking about Basic and = Digest >=20 > - s/header/header field/ >=20 > - please use symbolic references (xml2rfc PI symrefs=3D"yes") >=20 > - in xml2rfc, you get appendices by putting
elements into = the element >=20 > - if BNF notation is needed, please use ABNF as defined in RFC 5234. >=20 > - (IANAL) the statement about Public Domain may or may not be in = conflict with the Copyright Statement on the front page >=20 > - OAuth reference missing >=20 > - the reference to RFC 3339 seems to be unused >=20 > Best regards, Julian >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Mark Nottingham http://www.mnot.net/ From internet-drafts@ietf.org Tue Feb 4 01:15:44 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461641A03C0; Tue, 4 Feb 2014 01:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbY8gSeFnsD6; Tue, 4 Feb 2014 01:15:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7535F1A03A1; Tue, 4 Feb 2014 01:15:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204091541.27376.24269.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 01:15:41 -0800 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:15:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : An Encoding Parameter for HTTP Basic Authentication Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-enc-02.txt Pages : 10 Date : 2014-02-04 Abstract: The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has led to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character repertoire, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding scheme expectation, using a new authentication scheme parameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-enc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-enc-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-enc-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From julian.reschke@gmx.de Tue Feb 4 01:21:11 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A2C1A03A1 for ; Tue, 4 Feb 2014 01:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvZ6ISH-d_qK for ; Tue, 4 Feb 2014 01:21:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 955111A03C7 for ; Tue, 4 Feb 2014 01:21:08 -0800 (PST) Received: from [192.168.2.117] ([93.217.104.31]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MWxtA-1VgwGl2dam-00W0Se for ; Tue, 04 Feb 2014 10:21:07 +0100 Message-ID: <52F0B0FF.7050602@gmx.de> Date: Tue, 04 Feb 2014 10:21:03 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: http-auth@ietf.org References: <20140204091541.27376.24269.idtracker@ietfa.amsl.com> In-Reply-To: <20140204091541.27376.24269.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jtzAKHpYsFamC/1M/Vr+Z1tnT8DajxJyJ9fX/eJJcffX8ItrIgK nLgBkiHpPqW6BuchTL/+x2OcjfDVPUK1u+z0BLDvL9rWLR8+YAHXBb5+ARafzIQVP2+AzMn iHlzLb/YV+nHrvv2i7Kuqy/mTs0IbBkAN2XBRTsFPknf8yZonCvfVA+u7zuERCSmlY1uwDJ QqC0bNFeCtMMXgt9fDrdA== Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:21:11 -0000 On 2014-02-04 10:15, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. > ... Just updating references and adding a note about draft-ietf-httpauth-basicauth-update... Best regards, Julian From julian.reschke@gmx.de Tue Feb 4 07:33:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35761A012F for ; Tue, 4 Feb 2014 07:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A_iLUxPkz-V for ; Tue, 4 Feb 2014 07:33:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id D4D3D1A00F9 for ; Tue, 4 Feb 2014 07:33:19 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MPD8G-1W6KHG2SqO-004Vtm for ; Tue, 04 Feb 2014 16:33:18 +0100 Message-ID: <52F1083B.2020102@gmx.de> Date: Tue, 04 Feb 2014 16:33:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Saint-Andre , Yutaka OIWA References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> In-Reply-To: <52F0518C.9060506@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:wEgO7WRhlf/HZsYdikEzFX8GRw7A0AtEW/UsfrS+poC2M8yoiD/ fgQa+lSe0sEek82HKu84+Dk/vOo2Gj40SFBFLKQxpdr1q5mnyZGdO9oN2tyDWGtbnmZsiu0 QacZdPUQXgbWUJVp1Q1izEgN8K32ecT5JaFTDOzM4m8pGPRWL215eoRQFfv0gH/Ug7KzA8J Ts70reUOD7WbrDcXRwLog== Cc: "http-auth@ietf.org" , precis@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:33:24 -0000 On 2014-02-04 03:33, Peter Saint-Andre wrote: > Yes, I think it is best to define a separate profile for HTTPAUTH (based > on various conversations at the last IETF meeting). I will try to review > your document again very soon. > > Peter Peter: that would be awesome. That being said I fear that this is going to take some time. Alternatives for "Basic": 1) Keep the separation of the base spec (draft-ietf-httpauth-basicauth-update) from the one addressing I18N (draft-ietf-httpauth-basicauth-enc), and try to get the former out of the door as soon as possible. 2) As previously agreed upon, merge the two specs but only do some handwaving with respect to normalization for now. Best regards, Julian From derhoermi@gmx.net Tue Feb 4 17:26:19 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6125E1A0196 for ; Tue, 4 Feb 2014 17:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8nNVVti2IRf for ; Tue, 4 Feb 2014 17:26:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4291A016C for ; Tue, 4 Feb 2014 17:26:16 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.28.118]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MFR2O-1VymQ63NWm-00EL0a for ; Wed, 05 Feb 2014 02:26:15 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Wed, 05 Feb 2014 02:26:16 +0100 Message-ID: References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> In-Reply-To: <52F1083B.2020102@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:SIjfktc4RwbY2fAmGVMe0JBWoDQhQtk43JFLspFJFJx8m2xESQn QQagd92FRIiw8DYmzRwUrr8nxGnjgp1CrAJnBnEOavNTq6TRFHO5Csxf6NJdRxucVIQOMYO nMB8/kuCW1zi9U6xBM+/zUqGkRY5xeR8IHqJsRitTAqsV2ysFiqseoXbnhkg1Zk7B3k/0eQ fLACmhb2SRMOvDYpDOtGw== Cc: "http-auth@ietf.org" , precis@ietf.org Subject: Re: [http-auth] [precis] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 01:26:19 -0000 * Julian Reschke wrote: >Alternatives for "Basic": > >1) Keep the separation of the base spec >(draft-ietf-httpauth-basicauth-update) from the one addressing I18N >(draft-ietf-httpauth-basicauth-enc), and try to get the former out of >the door as soon as possible. > >2) As previously agreed upon, merge the two specs but only do some >handwaving with respect to normalization for now. I like 2). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From y.oiwa@aist.go.jp Wed Feb 5 01:15:15 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23661A00B2 for ; Wed, 5 Feb 2014 01:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZJTtqXxHezC for ; Wed, 5 Feb 2014 01:15:13 -0800 (PST) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7601A00B0 for ; Wed, 5 Feb 2014 01:15:13 -0800 (PST) Received: from mail-vb0-f45.google.com ([209.85.212.45]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUvIBILCtcnjjdnQMr1eqXMnwA4xaOA8C@postini.com; Wed, 05 Feb 2014 01:15:12 PST Received: by mail-vb0-f45.google.com with SMTP id m10so78868vbh.18 for ; Wed, 05 Feb 2014 01:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ApOr162ZL8aV5qnYGIQKPiBLDr8YNwZe+KIINGGJuss=; b=acccS9KcrIIOlDxk93luhNUY+0BAwDpSI6BGSQM6byu7znkHJoc+lMXz77N45xRtWJ VIf2FXpjdxkR/o47AZpIEHyEtw8lEHoaXR18u+PuOZjV6LATq9w+mSpYLViYtzFIZ2qp JbR1OMercLG9uFonNqZIiBgoOLzwLkFk0TPgU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ApOr162ZL8aV5qnYGIQKPiBLDr8YNwZe+KIINGGJuss=; b=Uh33MVPFQuuGSoIary5YYEzpsPfLAZLY7cLSW6UVYaS035RYRe5YLpMQgXZq4Ec+Ks VUJcJwNmZYbusqoZQvxEAlG179vAzaFft7TbHKs/elcVxMO7lT4JC/WKU92frso7aARp W+iPWBMDSQG8gy6OZNB5cRMQaLkgJgApQUaHdzvFci3lBtzDsHatvupyHTiiLpGctuHK LWRvVuIG/hQNxp2E/C8levAcoKjyYs84GMUw9xmruntThW4HyiKKhTAqAr9T/DgYR1IV Jn55ODEaxhEGaf1vbPd/QIaWFRPJue2G1mOEsJ56IDKfIhMtN9bEtZ9UFcJhx0+/gfw5 M9HQ== X-Gm-Message-State: ALoCoQmgPi9N0sxHVySuufuDWW6x0o7zaoow35ZBrz5Q20p5i0JvRwbatiiERL5b9S3pTm5xUODqzYIjmcYx8HC8NyRRy1MzRKI2VBoZFxsEYYt1gQUk9UA4eOADIjxYEaGQO0/pFahL6GhDJauSToB4/UyYl3tw6Q== X-Received: by 10.58.181.230 with SMTP id dz6mr143898vec.35.1391591711936; Wed, 05 Feb 2014 01:15:11 -0800 (PST) X-Received: by 10.58.181.230 with SMTP id dz6mr143887vec.35.1391591711818; Wed, 05 Feb 2014 01:15:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Feb 2014 01:14:51 -0800 (PST) In-Reply-To: <52F0518C.9060506@stpeter.im> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> From: Yutaka OIWA Date: Wed, 5 Feb 2014 18:14:51 +0900 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , "http-auth@ietf.org" , precis@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:15:16 -0000 Thank you very much for making our next steps very clear. I'll do my best to improve our proposal. 2014-02-04 Peter Saint-Andre : > Yes, I think it is best to define a separate profile for HTTPAUTH (based on > various conversations at the last IETF meeting). I will try to review your > document again very soon. > > Peter > > > On 2/3/14, 5:18 PM, Yutaka OIWA wrote: >> >> Dear Julian and Peter (added), >> >> how about the things ongoing about handling of >> HTTP-AUTH normalization in context of PRECIS? >> >> I proposed general-purpose HTTP-AUTH normalization >> profile to PRECIS WG (just because I need it :-), >> and they considered merging it with new SASLPREPbis. >> My current draft is >> http://tools.ietf.org/html/draft-oiwa-precis-httpauthprep-00 . >> SASLPREPbis is in WG pool as >> http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-06 . >> >> I am awaiting actions for whether the merging >> will actually happen or not. >> In my understanding, removing of SASL-dependent >> natures (e.g. that in Username grammer) from current >> saslprepbis is not going forward yet, and current >> SASLPREPbis is, at least personally, not applicable >> for any HTTP auth schemes except SASL-backed ones. >> For clarify, SASLPREPbis is really good, and the differences >> are not large but critical. >> >> I think there is several possible directions for us to go: >> >> 1) Go merging: push forward to make saslprepbis a >> general-purpose precis profile by separating >> still-remaining SASL-only features. >> IMO, in this case we may need two separate >> application notes documents for SASL and HTTP-AUTH. >> >> 2) Go separate: discuss HTTPAUTH in context of >> PRECIS separately from SASLPREP. >> I believe that my draft will give us a good starting point, >> as my best effort. >> >> 3) for Julian, one possible best current cheating, if you >> can't wait PRECIS WG, might be just specify NFC as a >> canonical form. Both SASLPREP and HTTPAUTHprep >> (and many other PRECIS profiles) are NFC based, >> so it will not likely harm future development of proper >> PRECIS-based "preparation" (including normalization). >> >> Also, I would be happy if Julian (as talked in Vancouver) >> and other people in HTTPAUTH WG and PRECIS WG >> could give us a feedback on my proposal from the >> both WG's points of view. >> >> 2014-02-04 Julian Reschke : >>> >>> On 2013-10-05 11:01, Julian Reschke wrote: >>>> >>>> >>>> On 2013-09-12 12:35, Julian Reschke wrote: >>>>> >>>>> >>>>> On 2013-08-21 21:22, Matthew Lepinski wrote: >>>>>> >>>>>> >>>>>> Draft minutes for the HTTP-AUTH session have been posted. >>>>>> >>>>>> They can be found at: >>>>>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>>>>> >>>>>> If you notice any omissions or other errors in the minutes, please let >>>>>> us know. >>>>>> ... >>>>> >>>>> >>>>> >>>>> OK, the minutes mention: >>>>> >>>>> "Unicode Normalization : Getting from what is typed in to Unicode code >>>>> points will require discussion" >>>>> >>>>> So how do we proceed from here? Any concrete proposals for what to say? >>>> >>>> >>>> >>>> It seems we don't know what to say then, right? >>>> >>>> How about: "Beware that differing Unicode normalization forms can cause >>>> interoperability problems. See [http://unicode.org/reports/tr15/]."? >>>> >>>> >>>> Best regards, Julian >>> >>> >>> >>> So, does anybody have a good plan how to approach the normalization >>> problem? >>> >>> Otherwise we'll just have to state that there are dragons out there, and >>> that we don't know the solution... >>> >>> >>> Best regards, Julian >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >> >> >> >> > > > -- > Peter Saint-Andre > https://stpeter.im/ -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 y.oiwa@aist.go.jp Wed Feb 5 01:21:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0E61A00B4 for ; Wed, 5 Feb 2014 01:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ub0tvPmwzyc for ; Wed, 5 Feb 2014 01:21:24 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id DEA391A00B1 for ; Wed, 5 Feb 2014 01:21:23 -0800 (PST) Received: from mail-vc0-f171.google.com ([209.85.220.171]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUvICk+b5DP+62G5sqPZA1kmCDHBwM99y@postini.com; Wed, 05 Feb 2014 01:21:23 PST Received: by mail-vc0-f171.google.com with SMTP id le5so85383vcb.2 for ; Wed, 05 Feb 2014 01:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=87ZI9PmBlpw8Em6DkLz/xW7fTrkxENYoHnq8Dq9FkO4=; b=enNeEJdOle7pADNTBb4AN6G6yUb11mKyEj2ZpnhjbOD7TuCJMQk6en9AninVgJYEfL cRYpMBrvWCjuANrsDLUb+zKYFTQaus/VuKb4IcLyyyEqaCheLa4L5TZfGudiTPLLmSkd iqxpofVeUosUVN+wIc2dSfudqgb7fRma9yqNY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=87ZI9PmBlpw8Em6DkLz/xW7fTrkxENYoHnq8Dq9FkO4=; b=c6zu4cqrjn2LzhCwVPT7yimY5OTt5TTCQKCrbfGZ92ctxhk3Oi1WcW4DpKxki4XISq uGW3QfD4ig5D4Eplh3m59oc1MkZICGWmUVz4hgZBxjC2rHBuu9j0nFSrbWxBWKy85+z0 OWyHQHafucSiY+uyu9PK3MEyc3/RZ3w2lbltepdKMjoHLy+hcYGU5DgSC2kLj1tUTU3b F+/u+DkynCFJZjPypaBIn5zBYIXSq0l4+10n1YaueGqCxtnE2byluS/7VlC4sfb8VTxW t74DB5xxxgasMya8BXcQdk7uyJGHbEu/bEVOsvNlm6owB+DbbAFxef2vMmw/I7FHC8ZZ qNOw== X-Gm-Message-State: ALoCoQl9m/OelnWpOMLsivrk0Ii4Bp5G7958X3co1+KXP4w2NFSI4ui2CLqECTbuD3Kt5B2YOdWJs/DcSqBNePVqP3iYnazXQ/46afJE4SQlfNIxh3hFMQKBvkhypDMe+JdbuNC7JXL7C/H7d54edXLfThafH39dIQ== X-Received: by 10.58.90.202 with SMTP id by10mr217345veb.6.1391592082918; Wed, 05 Feb 2014 01:21:22 -0800 (PST) X-Received: by 10.58.90.202 with SMTP id by10mr217331veb.6.1391592082720; Wed, 05 Feb 2014 01:21:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Feb 2014 01:21:02 -0800 (PST) In-Reply-To: References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> From: Yutaka OIWA Date: Wed, 5 Feb 2014 18:21:02 +0900 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , "http-auth@ietf.org" , precis@ietf.org Subject: Re: [http-auth] [precis] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:21:26 -0000 >>2) As previously agreed upon, merge the two specs but only do some >>handwaving with respect to normalization for now. > > I like 2). Given taking 2), is it technically possible to make an "update" to the merged Basic-auth spec by a PRECIS profile document defined later (but sooner)? # I think, if any, the update may be something to "RECOMMEND" # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST", # considering very pervasive and pragmatic nature of the Basic authenticati= on. 2014-02-05 Bjoern Hoehrmann : > * Julian Reschke wrote: >>Alternatives for "Basic": >> >>1) Keep the separation of the base spec >>(draft-ietf-httpauth-basicauth-update) from the one addressing I18N >>(draft-ietf-httpauth-basicauth-enc), and try to get the former out of >>the door as soon as possible. >> >>2) As previously agreed upon, merge the two specs but only do some >>handwaving with respect to normalization for now. > > I like 2). > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ --=20 Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 ynir@checkpoint.com Wed Feb 5 01:31:03 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25671A00B5; Wed, 5 Feb 2014 01:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9e0xwTEspQb; Wed, 5 Feb 2014 01:31:01 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AEFC31A00B1; Wed, 5 Feb 2014 01:31:00 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s159Uofa005566; Wed, 5 Feb 2014 11:30:50 +0200 X-CheckPoint: {52F1FDE8-15-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 11:30:50 +0200 From: Yoav Nir To: Yutaka OIWA , Bjoern Hoehrmann Thread-Topic: [http-auth] [precis] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session Thread-Index: AQHPIlOqXWllV0ATE0aQ3qoBK1NG85qmYu9w Date: Wed, 5 Feb 2014 09:30:49 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772121BA73CB@DAG-EX10.ad.checkpoint.com> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> 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.27] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "http-auth@ietf.org" , "precis@ietf.org" Subject: Re: [http-auth] [precis] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:31:03 -0000 [With http-auth chair hat on] It is possible for one draft document to normatively reference another draf= t document. It can go through WGLC, IETF-LC, and IESG review and approval = with this reference.=20 In such cases, the document does not get published until the reference also= becomes an RFC, at which point the RFC editor converts the reference to a = reference to the new RFC. There are two downsides to this process: - It delays the original document indefinitely. Not a problem in our case = because nobody (other than the authors is waiting for our document) - You get into a messy situation if the precis document ends up stalled. If we have a direction, and we have authors volunteering to write this in p= recis, I'm not opposed to taking this route.=20 Please note, that precise encoding issues apply to both passwords and usern= ames, as the new Digest algorithm allows hiding of usernames ([1]) Yoav [1] http://tools.ietf.org/html/draft-ietf-httpauth-digest-04#section-3.4.4 -----Original Message----- From: http-auth [mailto:http-auth-bounces@ietf.org] On Behalf Of Yutaka OIW= A Sent: Wednesday, February 05, 2014 11:21 AM To: Bjoern Hoehrmann Cc: Julian Reschke; http-auth@ietf.org; precis@ietf.org Subject: Re: [http-auth] [precis] Unicode normalization, was: Draft Minutes= Posted for IETF 87 HTTP-AUTH Session >>2) As previously agreed upon, merge the two specs but only do some=20 >>handwaving with respect to normalization for now. > > I like 2). Given taking 2), is it technically possible to make an "update" to the merg= ed Basic-auth spec by a PRECIS profile document defined later (but sooner)? # I think, if any, the update may be something to "RECOMMEND" # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST", # con= sidering very pervasive and pragmatic nature of the Basic authentication. 2014-02-05 Bjoern Hoehrmann : > * Julian Reschke wrote: >>Alternatives for "Basic": >> >>1) Keep the separation of the base spec >>(draft-ietf-httpauth-basicauth-update) from the one addressing I18N=20 >>(draft-ietf-httpauth-basicauth-enc), and try to get the former out of=20 >>the door as soon as possible. >> >>2) As previously agreed upon, merge the two specs but only do some=20 >>handwaving with respect to normalization for now. > > I like 2). > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7=20 > http://bjoern.hoehrmann.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681= =20 > =B7 http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7=20 > http://www.websitedev.de/ --=20 Yutaka OIWA, Ph.D. Leader, System Life-cycle 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= ] _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth Email secured by Check Point From julian.reschke@gmx.de Wed Feb 5 01:41:18 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB911A00B3 for ; Wed, 5 Feb 2014 01:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ5z1j-btIit for ; Wed, 5 Feb 2014 01:41:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB91A00B7 for ; Wed, 5 Feb 2014 01:41:15 -0800 (PST) Received: from [192.168.1.102] ([93.217.75.252]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lh6sJ-1VPanO2lCZ-00oXar for ; Wed, 05 Feb 2014 10:41:14 +0100 Message-ID: <52F20734.4080405@gmx.de> Date: Wed, 05 Feb 2014 10:41:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yutaka OIWA , Bjoern Hoehrmann References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2fdKWHUHiQEscLstkW/ok28NmqfkQJpH+0z2ymbgs3ZwJUIbmRp F38E4EkeokBZGxZCvaiJICy0a0WbMsdUiLb5eWpBLBi9ZFkSozcqUcqiIcUOVirQ5BVUqYt oJSLJ5UNbUBlGoHNNi4klR2SHXiOU14yR/lUdR7c4gX4fu0AgDm18mM3o2rKKQiDLIE8P7t R7SXXihxmaAwGLYiopZQw== Cc: "http-auth@ietf.org" , precis@ietf.org Subject: Re: [http-auth] [precis] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:41:18 -0000 On 2014-02-05 10:21, Yutaka OIWA wrote: >>> 2) As previously agreed upon, merge the two specs but only do some >>> handwaving with respect to normalization for now. >> >> I like 2). > > Given taking 2), is it technically possible to make an "update" to > the merged Basic-auth spec by a PRECIS profile document defined > later (but sooner)? > > # I think, if any, the update may be something to "RECOMMEND" > # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST", > # considering very pervasive and pragmatic nature of the Basic authentication. We're going for Proposed Standard here. We can always revise the document again, change this, and go to Full Standard later on. The key issue aren't the specs, but what implementations do. So we need to agree on what they should do and try to get *that* implemented, Otherwise the whole exercise is completely academic. Best regards, Julian From julian.reschke@gmx.de Wed Feb 5 01:43:04 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A711A00B3 for ; Wed, 5 Feb 2014 01:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvTTV2y8iglX for ; Wed, 5 Feb 2014 01:43:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B3AB01A00B5 for ; Wed, 5 Feb 2014 01:43:02 -0800 (PST) Received: from [192.168.1.102] ([93.217.75.252]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MFdDB-1VzClN3euT-00EbPu for ; Wed, 05 Feb 2014 10:43:01 +0100 Message-ID: <52F207A1.80506@gmx.de> Date: Wed, 05 Feb 2014 10:42:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yoav Nir , Yutaka OIWA , Bjoern Hoehrmann References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> <4613980CFC78314ABFD7F85CC302772121BA73CB@DAG-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC302772121BA73CB@DAG-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KVTRQSUniyedOa0s544YUsLQAVLVIEtge7crHw0hMCe9Mq4A8q4 PfEuXqeHCHAnEFfS24RV2A0MCXCnn6bkwrhgeVatCE3kQ0VNDML0AZbqLZTHo4PRt7jPJ+1 /7QQCUQ+lL9nOe60d/TG4JrjyoKKegDXi+IuoSMQZ4HW42gqzkTWQQMP5FRPvEqxBck3+nt cgXBtJalcILIL+s5yOwIg== Cc: "http-auth@ietf.org" , "precis@ietf.org" Subject: Re: [http-auth] [precis] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 09:43:04 -0000 On 2014-02-05 10:30, Yoav Nir wrote: > [With http-auth chair hat on] > > It is possible for one draft document to normatively reference another draft document. It can go through WGLC, IETF-LC, and IESG review and approval with this reference. > > In such cases, the document does not get published until the reference also becomes an RFC, at which point the RFC editor converts the reference to a reference to the new RFC. > > There are two downsides to this process: > - It delays the original document indefinitely. Not a problem in our case because nobody (other than the authors is waiting for our document) Understood, but no, I believe we should get this done. Either by ignoring I18N for now (a), or by documenting what happens in practice (b). (a) Status Quo (b) Requires research. > ... Best regards, Julian From y.oiwa@aist.go.jp Wed Feb 5 02:46:04 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357E51A00D5 for ; Wed, 5 Feb 2014 02:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LseaDpk9Cso3 for ; Wed, 5 Feb 2014 02:46:02 -0800 (PST) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id D617F1A00CA for ; Wed, 5 Feb 2014 02:46:01 -0800 (PST) Received: from mail-vc0-f174.google.com ([209.85.220.174]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUvIWaVp4VA014o2xDNNo55wskZen13bQ@postini.com; Wed, 05 Feb 2014 02:46:01 PST Received: by mail-vc0-f174.google.com with SMTP id im17so144391vcb.33 for ; Wed, 05 Feb 2014 02:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eLLjRxA9+8srn4t0Lk4XcZPtzPjVjM1y8KiaAZsYhCo=; b=CAzfKrqAO5UGd+yd6Engk5qLncQPZtEMQJW0jtqZmLBXYLKv4bAUxwmqpKQTu5o2Ky td4YuzFEJWyUa5577VVL2OxYD1hNKSdPrRLVFpAIcWGACRVUGW32aplDI5LxPOPKrpP7 HBkEkL1wz4veIMBlzz9hKYNCLO2YXZHTJoSCM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eLLjRxA9+8srn4t0Lk4XcZPtzPjVjM1y8KiaAZsYhCo=; b=dGevGKPwV+4IYoYPA8mjc1YYn9TOxfzAtVIKt5h89W6Zjg870KXn+ZWh2esoRBLBYd S8nT00df42LSNf+BOMxF0NFaaz6lNUVUm62Zwb1eAmqtwOTZ/1V3UY9uZN7Wul9rwX4+ +aI60Vmua667t+C/uCulWNefw25gXX7N91kBbhviP0LDExCtQV0GVdkWXmZ+/4yooYsj /jRDdJJbW1D08qSgS45KzaFTpQuXIgU5fNLLslnoePAcRZPyrHNnj94g7hS0lHnTQdYl UdsNVtVSC9fzMpAayhT0nbWdPq4eA6cgNL4WsPluugTGjx1VMMP2dBNJ6jnuSCZxbbWn eSvw== X-Gm-Message-State: ALoCoQkmKeWhfo1bhnoascDn7csDESVttHfMGTREKgHgERge5fnLwz7kEN4V3ztls7Csh2iuRZNiuTPFY1l5Antl/eHkxcWFBjgM0CofGzWlYIgHPNXczhwMUnehMM10wg1mOxB4UOvIEeGzB9kOpJAgdOSFSyydtg== X-Received: by 10.52.170.3 with SMTP id ai3mr387255vdc.35.1391597160712; Wed, 05 Feb 2014 02:46:00 -0800 (PST) X-Received: by 10.52.170.3 with SMTP id ai3mr387247vdc.35.1391597160601; Wed, 05 Feb 2014 02:46:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.100.227 with HTTP; Wed, 5 Feb 2014 02:45:40 -0800 (PST) In-Reply-To: <52F20734.4080405@gmx.de> References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <52EFCA1F.5070609@gmx.de> <52F0518C.9060506@stpeter.im> <52F1083B.2020102@gmx.de> <52F20734.4080405@gmx.de> From: Yutaka OIWA Date: Wed, 5 Feb 2014 19:45:40 +0900 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" , Bjoern Hoehrmann , precis@ietf.org Subject: Re: [http-auth] [precis] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 10:46:04 -0000 Dear Julian, > The key issue aren't the specs, but what implementations do. So we need to agree on what they should do and try to get *that* implemented, Otherwise the whole exercise is completely academic. Your point is really understood and agreed. We need a thorough discussion for requirement strength of string preparation (including Unicode normalization) for Basic and Digest schemes. There is a tough trade-off: if the requirement is too weak, it decreases interoperability and the users will experience a frustrating failed authentications; if too strong, implementors will not just follow it. We need to find a good mid-point. My current position is not actually insisting PRECIS-based handling for a MUST requirement of UTF-8 Basic. My current preference is, assuming that the majority of people think MUST-required PRECIS handling too strong, the following: "to require NFC Unicode normalization a SHOULD, and some PRECIS handling a MAY with stating it's a good practice to do." The reason is: Unicode normalization is hard to be worked-around by end users; other PRECIS preparations are generally workaround-able by users by avoiding some characters in their input. (Oppositely, if the majority thought that UTF-8 Basic should do a correct PRESIS-based preparation as a MUST for the best interoperability assurance, I would happily follow it.) * Regarding general issue on string preparation for HTTP authentication, I have two strong opinions around here: 1) "single solution": Within HTTPAUTH technology area, There should not be randomly many ways of preparations with minor differences with no justifiable reasons. There should be a single default way of preparation which will be used for almost all HTTP-related authentications *if they do preparation*, unless there are some other dependencies (like SASLprep for SASL-backed schemes.) 2) "new good things for new technologies": For *new* auth schemes, for which we can expect they will have a new implementation efforts anyway, we have a motivation for MUST-or-SHOULD requirement of correct I18N handling. (It is something like an exercise anyway, so we may try to do the "correct" thing.) However, for retrofitting schemes like Basic and Digest, I suspect that the normative requirements for correct I18N may be too strong. I guess we may need to allow implementors to "ignore" such complex handling, and still saying their implementations are compliant to the new UTF-8 Basic. That's why, in my HTTPAUTHprep draft, I said it will serve as a dual-purpose document, both as a normative reference for new things and a best practice for other existing schemes. (See Section 1.2 of my draft, understanding the phrase is not yet polished). 2014-02-05 Julian Reschke : > On 2014-02-05 10:21, Yutaka OIWA wrote: >>>> >>>> 2) As previously agreed upon, merge the two specs but only do some >>>> handwaving with respect to normalization for now. >>> >>> >>> I like 2). >> >> >> Given taking 2), is it technically possible to make an "update" to >> the merged Basic-auth spec by a PRECIS profile document defined >> later (but sooner)? >> >> # I think, if any, the update may be something to "RECOMMEND" >> # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST", >> # considering very pervasive and pragmatic nature of the Basic >> authentication. > > > We're going for Proposed Standard here. We can always revise the document > again, change this, and go to Full Standard later on. > > The key issue aren't the specs, but what implementations do. So we need to > agree on what they should do and try to get *that* implemented, Otherwise > the whole exercise is completely academic. > > Best regards, Julian > -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 julian.reschke@gmx.de Wed Feb 5 08:25:08 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8AA61A01E2 for ; Wed, 5 Feb 2014 08:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwZvwd78emIX for ; Wed, 5 Feb 2014 08:25:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id E85BD1A0128 for ; Wed, 5 Feb 2014 08:25:06 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MLvLE-1WA0QX2cVI-007oFb for ; Wed, 05 Feb 2014 17:25:05 +0100 Message-ID: <52F265DE.90504@gmx.de> Date: Wed, 05 Feb 2014 17:25:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: multipart/mixed; boundary="------------040300010105080502040001" X-Provags-ID: V03:K0:gQymysaNboAdLgVbqCRdhSFzfeUYn/HsP2NHgT//+svwXra0A6U bv7Hz9hsY9C+2g4TUFkjYFIUyTNtYYn1u6BihH/QcTYQcizS7WHnKTz3OVtX6lsrYTAA7pf IVPDzWqazrGh/5iP5K30SgU6S7Ubi9t7gur+3zSTvbMTXRf1mxr21TReUGFXPqpoPoTjNvO AQh2EJLe8GKwP8VCXa85A== Subject: [http-auth] test results for non-ASCII characters in Basic Auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 16:25:09 -0000 This is a multi-part message in MIME format. --------------040300010105080502040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi there, testing with the attached code and german unlauts. Results: 1) The platform does not appear to matter. 2) IE and Firefox send ISO-8859-1 3) Chrome sends UTF-8 (precomposed) 4) Safari appears to send ISO-8859-1 on the first request, then UTF-8 (precomposed) (anybody have an idea what's going on?) 5) wget and curl send UTF-8 (precomposed) And, somewhat unrelated: 6) none of the clients seems to enforce the "no-colon-in-username" constraint. So it appears we can require NFC in case UTF-8 is used. Best regards, Julian --------------040300010105080502040001 Content-Type: text/plain; charset=windows-1252; name="TestBasic.java" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="TestBasic.java" package com.greenbytes.httptests; import java.io.IOException; import java.io.OutputStream; import java.net.InetSocketAddress; import java.util.UUID; import javax.xml.bind.DatatypeConverter; import com.sun.net.httpserver.HttpExchange; import com.sun.net.httpserver.HttpHandler; import com.sun.net.httpserver.HttpServer; public class TestBasic { /** * @param args */ public static void main(String[] args) throws IOException { HttpServer server = HttpServer.create(new InetSocketAddress(7999), 0); server.createContext("/simple", new MyHandler(false)); server.createContext("/simple-enc", new MyHandler(true)); server.setExecutor(null); // creates a default executor server.start(); } private static class MyHandler implements HttpHandler { boolean sendEncoding; public MyHandler(boolean sendEncoding) { this.sendEncoding = sendEncoding; } @Override public void handle(HttpExchange t) throws IOException { String auth = t.getRequestHeaders().getFirst("Authorization"); if (auth == null) { t.getResponseHeaders().set( "WWW-Authenticate", "Basic realm=\"authentication test " + UUID.randomUUID() + "\"" + (sendEncoding ? ", charset=\"UTF-8\"" : "")); t.getResponseHeaders().set("Content-Type", "text/plain"); String response = "401 Auth required\n"; t.sendResponseHeaders(401, 0); OutputStream os = t.getResponseBody(); os.write(response.getBytes("UTF-8")); os.close(); } else { String response = ""; String ua = t.getRequestHeaders().getFirst("User-Agent"); response += "UA: " + ua + "\r\n"; response += "Raw authentication header: " + auth + "\r\n"; if (auth.startsWith("Basic ")) { String creds = auth.substring(6); byte[] decoded = DatatypeConverter.parseBase64Binary(creds); response += "Decoded as byte sequence: "; for (byte b : decoded) { response += String.format("%02x ", b); } response += "\r\n"; String asiso = new String(decoded, "ISO-8859-1"); response += "Decoded as ISO-8859-1: " + asiso + "\r\n"; String asutf8 = new String(decoded, "UTF-8"); response += "Decoded as UTF-8: " + asutf8 + "\r\n"; } t.getResponseHeaders().set("Content-Type", "text/plain; charset=utf-8"); t.sendResponseHeaders(200, 0); OutputStream os = t.getResponseBody(); os.write(response.getBytes("UTF-8")); os.close(); System.out.println(response); } } } } --------------040300010105080502040001-- From msporny@digitalbazaar.com Wed Feb 5 13:13:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03791A0129 for ; Wed, 5 Feb 2014 13:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpbZExcSZoFK for ; Wed, 5 Feb 2014 13:13:21 -0800 (PST) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 15BA51A0100 for ; Wed, 5 Feb 2014 13:13:21 -0800 (PST) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1WB9ma-0007fm-9Z; Wed, 05 Feb 2014 16:13:20 -0500 Message-ID: <52F2A970.10605@digitalbazaar.com> Date: Wed, 05 Feb 2014 16:13:20 -0500 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <52ED42C9.2070809@digitalbazaar.com> <52ED42C9.2070809@digitalbazaar.com> <52EFC691.9060304@gmx.de> In-Reply-To: <52EFC691.9060304@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: public-webpayments@w3.org Subject: Re: [http-auth] HTTP Signatures specification updated X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:13:24 -0000 On 02/03/2014 11:40 AM, Julian Reschke wrote: > find below my feedback: Hi Julian, thanks for the feedback, responses to you feedback with some additional questions below. > 1) The spec seems to be confused about whether it defines an HTTP > authentication scheme or not. If it does, it needs to follow the > requirements in > > if it does not, it shouldn't use the "Authorization" header field. The specification started out as a way for clients to authenticate themselves to the origin. We've had a few requests to use the same general approach for the origin to authenticate certain parts of the HTTP message back to the client (which can be useful over non-TLS connections, or if you want to have extra security on top of TLS for Pervasive Monitoring scenarios). If we wanted to use the mechanism for both client-to-origin signatures and origin-to-client signatures, what would you suggest that we do? We could introduce a new header "Signature", that can be used by both clients and origins, but didn't know if that would be the proper approach. Thoughts? For the time being, I think I've followed the requirements in the draft-ietf-httpbis-p7-auth-25 spec. It's unclear exactly how I should specify the registration. The registry doesn't exist yet. So I've added an IANA Considerations appendix noting the requirement for a registration to be made if the spec makes it through the IETF process: https://web-payments.org/specs/source/http-signatures/#appendix-d It would be helpful if the text in ietf-httpbis-p7-auth-25 gave an example of how one does this, or linked to an RFC that describes how to do this. > 2) REQUIRED. The `algorithm` parameter is used if the client and > server agree on a non-standard digital signature algorithm. The full > list of supported signature mechanisms is listed below. > > - This should be aligned with other IETF specs using algorithm > names. The algorithm names are aligned w/ RFC6376: http://tools.ietf.org/html/rfc6376 JOSE chose to use different algorithm names. Which IETF specs should we align with, they're both current, no? > 3) OPTIONAL. The `headers` parameter is used to specify the list of > HTTP headers used to sign the request. If specified, it should be a > quoted list of HTTP header names, separated by a single space > character. By default, only one HTTP header is signed, which is the > `Date` header. Note that the list MUST be specified in the order > the values are concatenated together during signing. To include the > HTTP request line in the signature calculation, use the special > `request- line` value. While this is overloading the definition of > `headers` in HTTP linguism, the request-line is defined in RFC 2616 > [RFC2616], and as the outlier from headers in useful signature > calculation, it is deemed simpler to use `request-line` than to add a > separate parameter for it. > > - just state that the list order is significant for the signature > algorithm Done. I moved the explanatory text further down in the document. https://web-payments.org/specs/source/http-signatures/#headers > - for request-line, just pick a name that is guaranteed not to > conflict (such as "(request-line)"). That being said, the request > line is gone from HTTP/2, and it might be good to break the > information down into components that are more generic. Would still calling it "(request-line)" be fine and the state that for HTTP2, the request line is built using the method, path, and the string "HTTP/2"? For example: GET /foo HTTP/2 would be the request line generated for creating and validating signatures? > 4) OPTIONAL. The `extensions` parameter is used to include > additional information which is covered by the request. The content > and format of the string is out of scope for this document, and > expected to be specified by implementors. > > - the BNF says 'ext' Removed the parameter based on your feedback below: > - this will make it incredible hard to have more than one extension. > why not allow extension specs to use (and register) new parameter > names? That's a better idea, fixed: https://web-payments.org/specs/source/http-signatures/#appendix-b > 5) REQUIRED. The `signature` parameter is a `Base64` encoded > digital signature generated by the client. The client uses the > `algorithm` and `headers` request parameters to form a canonicalized > `signing string`. This `signing string` is then signed with the key > associated with `keyId` and the algorithm corresponding to > `algorithm`. The `signature` parameter is then set to the `Base64` > encoding of the signature. > > - Which base64? Please pick a concrete on, such as the one defined > in I picked the one you mentioned: https://web-payments.org/specs/source/http-signatures/#signature > 6) 1. If the header name is not `request-line` then append the > lowercased header name followed with an ASCII colon `:` and an ASCII > space ` `. > > - And the field value? Fixed: https://web-payments.org/specs/source/http-signatures/#canonicalization > - Also: what if there are multiple instances of a given field name? Added guidance if there are multiple instances: http://sites.local/web-payments.org/specs/source/http-signatures/#canonicalization > - What about leading and trailing whitespace in the header field > value? They are preserved, we want to stay as far away from canonicalizing the headers as we can. If a library, client, proxy, or server adds/removes whitespace, then the application is screwed. Canonicalization of header field values is something we do not want to specify, even if it means that signatures in some environments will fail. That said, if this becomes a major issue, then an extension specification can deal with it (or we can rev the spec to include some basic canonicalization). Unfortunately, at that point we're firmly in DKIM-Signature territory. One of the goals of this specification is to not be more complex than necessary. I added a note to mention that header field values must not be modified: https://web-payments.org/specs/source/http-signatures/#canonicalization > 7) Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE= > > - If this is the Digest header field defined in > then the spec > should say so. Fixed, the spec now refers to that RFC (although, informally as Digest isn't required for the spec). https://web-payments.org/specs/source/http-signatures/#canonicalization > 8) Error handling: as this is relevant for security, the spec needs > to state how to handle ambiguous values, such as multiple occurrences > of the same parameter name in "Authorization". The specification now states what to do w/ multiple occurrences of the same Signature parameter in the Authorization header: http://sites.local/web-payments.org/specs/source/http-signatures/#ambiguity It also describes what to do with multiple header fields: https://web-payments.org/specs/source/http-signatures/#canonicalization Is there a list somewhere of other sorts of error handling that should be taken into account with HTTP? > Editorial: > > - In the boilerplate, please say where to send feedback. Done: https://github.com/web-payments/web-payments.org/commit/0da85e2066011ab7e9eb8595ecd136affb6a5346 Although, I don't know if I added the note in the right way. The W3C spec tool allows you to modify the Status section, I couldn't find out how to do that w/ the xml2rfc tool. > - Please cite the HTTPbis drafts instead of RFC 2616. Fixed: https://github.com/web-payments/web-payments.org/commit/83c9cba2a3fc99bef0e71bd0fadeb058b7576966 > - Please do not cite RFC 2617 except when talking about Basic and > Digest Done: https://github.com/web-payments/web-payments.org/commit/6f97a12df79619b8eb264db8ce209ef149c30598 > - s/header/header field/ Fixed: https://github.com/web-payments/web-payments.org/commit/e8c14fa0b2fdc291473f1aa7302281e4915ee66e > - please use symbolic references (xml2rfc PI symrefs="yes") I thought I was, but the xml2rfc tool doesn't seem to be picking it up? https://github.com/web-payments/web-payments.org/blob/6f97a12df79619b8eb264db8ce209ef149c30598/specs/source/http-signatures/index.xml#L17 > - in xml2rfc, you get appendices by putting
elements into > the element Fixed: https://github.com/web-payments/web-payments.org/commit/e3ea00aa4e75b6791647baa2a0b5eecaeb87a72b > - if BNF notation is needed, please use ABNF as defined in RFC 5234. Fixed, I think: https://github.com/web-payments/web-payments.org/commit/937875db36e7799fafdfd6b5c4e35fb9e0a7df79 > - (IANAL) the statement about Public Domain may or may not be in > conflict with the Copyright Statement on the front page Fixed: https://github.com/web-payments/web-payments.org/commit/0d21fa41cf9fec2aa06007919aca8bceefa13d28 > - OAuth reference missing https://github.com/web-payments/web-payments.org/commit/774c7842f5c76e32e565f26303763e1c155242eb > - the reference to RFC 3339 seems to be unused Removed the reference. Thanks a bunch for your input Julian, it really helped clean up the spec! It would be great to hear your thoughts on whether this spec should continue to use the Authorization header or if it should try to do origin-to-client authentication as well. We'd like to do the latter if there is a simple, clean way to do it. It would be nice if the HTTP message information passed back from the financial servers that would be using this spec could be digitally signed as well. Answers to the other questions asked would also be greatly appreciated. :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Worlds First Web Payments Workshop http://www.w3.org/2013/10/payments/ -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Worlds First Web Payments Workshop http://www.w3.org/2013/10/payments/ From julian.reschke@gmx.de Wed Feb 5 13:37:13 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FB71A0101 for ; Wed, 5 Feb 2014 13:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1ow6y8aoFOQ for ; Wed, 5 Feb 2014 13:37:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6207F1A002B for ; Wed, 5 Feb 2014 13:37:11 -0800 (PST) Received: from [192.168.2.117] ([93.217.105.46]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LnkiR-1VaSEM26yF-00huq6 for ; Wed, 05 Feb 2014 22:37:09 +0100 Message-ID: <52F2AF01.7030008@gmx.de> Date: Wed, 05 Feb 2014 22:37:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <52F265DE.90504@gmx.de> In-Reply-To: <52F265DE.90504@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GAC/tgDoF0Ddjw0s1/PFyZB3D4tyv1cAXIElWbS0nXrgSW5pySW JTMBhqnv2hUd/vuvXizDd1j1WHkeN8jzzq105J6vc9Hi/HPU19veJnD/FUipLnpzQIvketa a3Pa+05gCWokFeWG0ekLFaE7THGk+qdF0yuQXm8NRnvfp0j1cSmgq4/mshsIYNm526m5h4o EFdGKxc9I+VuFnG9hk21w== Subject: Re: [http-auth] test results for non-ASCII characters in Basic Auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:37:13 -0000 On 2014-02-05 17:25, Julian Reschke wrote: > ... > 5) wget and curl send UTF-8 (precomposed) > ... ...which is a result of how the shell mapped the characters before invoking the tools. Best regards, Julian From nico@cryptonector.com Wed Feb 5 13:42:32 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3E11A0100 for ; Wed, 5 Feb 2014 13:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHuybLjie3zb for ; Wed, 5 Feb 2014 13:42:32 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 165E21A002B for ; Wed, 5 Feb 2014 13:42:32 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 63C122005D106 for ; Wed, 5 Feb 2014 13:42:31 -0800 (PST) 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=9ewNZ/jRmTCL4HzfqvPu pokpTiQ=; b=qxdbT7qsZWIl1P0oIj8u07OEY81/bOVenK8AtKbI49xNIL42L9WH 0w5JgjTVJa2VBTjfJ36vyYZXaEKp/U0uX5e960dH0dekA11VZqysPq+zo3W/DNJr DKfHQgLRz4Zh9oE3X/9EeG0Mdb/7Ht9yz6XJd948WsjF2irDxiBcsWI= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id 0FEB22005D105 for ; Wed, 5 Feb 2014 13:42:30 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so5813928wgh.2 for ; Wed, 05 Feb 2014 13:42:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ci+buJEMwERChyIRORzw+nIbwxtWpRwNEROtLHu1nGY=; b=DQJgkBYjsW32iKTB+Ez3o7phNcFpgkVU3TsqHdy7hoyBXxwHu/tuCNR4cZKn5e1IVC muTJlX4hzWY6j5dtILu8fH4/MgZ8rSgDD6sztGZatAgA6i8fgmP+0JsoHpm5EY6Or6qI lviKnjsz8+2vfE90Pal+TVW4nPaBRP8ZpdvTdW3luxpvYfWpZDL3zL8t1k8xymgTivzA B3dDZd8L7t+CJCJU2CqGyOBv/pkPPExDf9WO+GIVnYO/8pKS1u0XuKlOOKpm9LOWrpeN F3PPs4Xp2AbNTVMhiR3HVMITckhRTYVD6BNxwNI0mZIdaGVWKezVSbK4/a1ZgQig0Mfu VqFg== MIME-Version: 1.0 X-Received: by 10.180.96.102 with SMTP id dr6mr14244752wib.61.1391636548788; Wed, 05 Feb 2014 13:42:28 -0800 (PST) Received: by 10.227.198.69 with HTTP; Wed, 5 Feb 2014 13:42:28 -0800 (PST) In-Reply-To: <52F2AF01.7030008@gmx.de> References: <52F265DE.90504@gmx.de> <52F2AF01.7030008@gmx.de> Date: Wed, 5 Feb 2014 15:42:28 -0600 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] test results for non-ASCII characters in Basic Auth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:42:33 -0000 On Wed, Feb 5, 2014 at 3:37 PM, Julian Reschke wrote: > On 2014-02-05 17:25, Julian Reschke wrote: >> 5) wget and curl send UTF-8 (precomposed) >> ... > > ...which is a result of how the shell mapped the characters before invoking > the tools. The shell had nothing to do with it. It was the input mode and/or [pseudo-]terminal. You could manually encode a decomposed sequence (e.g., with the printf(1) shell built-in, if you have a modern-enough shell) and try cat'ing that into the right place and it should get passed through as-is (decomposed). For this reason I think one of the interesting things to do is gather information about input mode behavior. And not just for Latin scripts, but also Hangul and a few others with pre-composed and decomposed equivalents. Nico -- From msporny@digitalbazaar.com Fri Feb 7 09:34:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0AD1ACCEA for ; Fri, 7 Feb 2014 09:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC50-lsEdjDM for ; Fri, 7 Feb 2014 09:34:48 -0800 (PST) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id EFAAC1ACCE4 for ; Fri, 7 Feb 2014 09:34:47 -0800 (PST) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1WBpKB-0004WW-2u; Fri, 07 Feb 2014 12:34:47 -0500 Message-ID: <52F51936.5060106@digitalbazaar.com> Date: Fri, 07 Feb 2014 12:34:46 -0500 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <52ED42C9.2070809@digitalbazaar.com> <52ED42C9.2070809@digitalbazaar.com> <52EFC691.9060304@gmx.de> <21862A74-9B9A-40D5-BCAE-61C491F793FE@mnot.net> In-Reply-To: <21862A74-9B9A-40D5-BCAE-61C491F793FE@mnot.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: public-webpayments@w3.org Subject: Re: [http-auth] HTTP Signatures specification updated X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:34:51 -0000 Hey Mark, Thanks a bunch for your feedback, responses to your comments below: On 02/03/2014 09:54 PM, Mark Nottingham wrote: > * There are many ways that signatures could be useful in HTTP, and > this is just one way. So, "HTTP Signatures" is a terrible name for > this; it's way to generic. Please change it. Suggestion: "The > 'Signature' HTTP Authentication Scheme' (but see Julian's comment > below). Changed to what you suggested: https://github.com/web-payments/web-payments.org/commit/3e22397d0d0222983d9d3a64342654e30eac5854 As I mentioned to Julian, we may change the spec to provide both client to server and server to client authentication (or verifiability of header fields where a receiving application can assume authentication based on the digital signature). We'd love to hear your thoughts on the best way to do that. For example, should we introduce a new HTTP header field called "Signature" or "Verification"? Or should we extend the "Authentication" header field in the response from the server to the client? So, the name of the spec may change to: "HTTP Security Rock Goddess version 3.awesome" ... which I'm sure we can all agree is a way better name that anything that has been proposed to date. :P > * Abstract - The term 'origin' is defined by RFC6454, and I don't > think that's how you're using it here; at best, you're > authenticating the client *to* the origin. Changed it to "server" since that's what I think the original author meant: https://github.com/web-payments/web-payments.org/commit/b6ba31f143105a084094be39644e70b8a76cd339 > * 1. Introduction - this is a protocol extension, not a protocol in > and of itself. Fixed: https://github.com/web-payments/web-payments.org/commit/b48b4a76f84cbe268992afcd877b2f9da60d4e03#diff-d50cc99f156dfafd46bcd16c22ee2187L85 > * 1. Introduction - "However, it is common place..." -- this > sentence is probably going to get you in more trouble than it's worth > :) Recommend dropping it. Also, you don't cover why Digest auth > isn't good. https://github.com/web-payments/web-payments.org/commit/95d724119b6cc7e797f42841338dbcbbedacd53b > * 2.1.1.2 algorithm - "The full list of supported signature > mechanisms is listed below." This sort of thing is usually > delegated to a registry, so that you don't have to revise the whole > spec to modify the list. Also, "supported" is odd here, because this > is a protocol specification, not a product specification. Done: https://github.com/web-payments/web-payments.org/commit/a42cdf5119f99cc9025ac8a56ecde70f36dc1b83 and fixed the text here: https://github.com/web-payments/web-payments.org/commit/9b1f24dfbc7b9da2c2d0d5b48ed636c5ad79a168 > * 2.1.1.3 headers - Signing the *whole* request-line is a very bad > idea, because the HTTP version is a hop-by-hop artefact, not > end-to-end. Also, the spacing of the request-line can be irregular. > I'd suggest you define how to canonicalise the request method + URI > (ideally, the effective request URI, *not* the request-target; see > ). Fixed the algorithm to generate the request line: https://github.com/web-payments/web-payments.org/commit/c64c7cf327b7e034ecf4793787f34f888a351385 I'm hesitant to require the use of the effective request URI since the Host can be digitally signed as well. I realize that there is still an issue if an HTTP-based request is replayed over HTTPS, but if that's a concern then the application should be using nonces. If there is a stronger attack vector than that, we could use the effective request URI. I'm just concerned that some applications may not know whether they're going to submit the request over HTTP or HTTPS. I mean, most of them should know that, but some of them might not? Looking for guidance here because this is not an area that I know much about (other than "this sounds like it might be a pain for developers and not really increase the security of protocol extension enough to warrant the increase in complexity"). > * 2.1.2 Signature String Construction - You need to define how to > canonicalise headers before processing, taking into account that > headers can recur, have varying whitespace between the field-name, > colon and value, whitespace at the EOL and varying line termination. Addressed the headers recurring issue here: https://github.com/web-payments/web-payments.org/commit/e8c14fa0b2fdc291473f1aa7302281e4915ee66e#diff-d50cc99f156dfafd46bcd16c22ee2187R208 We don't specify how to deal with whitespace in the field name because we don't want to get into canonicalization. We could do a lighter form of canonicalization (strip all whitespace at beginning and end of string), but we'd rather the signature just not work for the applications than have funky whitespace than try to explain how canonicalization happens. The approach is: We'll sign whatever you give us for the header field name. How has this approach worked out in the past? I have a good idea of what your response is going to be. :) I think we're fairly explicit about line termination being LF (aka "\n"), what am I missing? We don't explicitly state LF or use hex values in the spec, do you want us to do that? > * You don't define a corresponding challenge. Your use cases might > not require a 401 + WWW-Authenticate, but have you considered that > some will want this? Yes, we did consider it. We wanted this to be a mostly "you're verified or you're not" mechanism. We didn't really want any sort of back-and-forth negotiation. That said, it's a weak argument because you probably want to be able to notify clients that they could access the resource if they provided a signature. If we decide that this is going to use the "Authorization" header (and not some new kind of header), we'll define the WWW-Authenticate bits of it. I've raised an issue to track it: https://github.com/web-payments/web-payments.org/issues/23 >> 1) The spec seems to be confused about whether it defines an HTTP >> authentication scheme or not. If it does, it needs to follow the >> requirements in >> > >> it does not, it shouldn't use the "Authorization" header field. > > See especially > . Ok, I've gone down the list and attempted to address each item (or make a note that we need to deal w/ the item in the spec): > HTTP authentication is presumed to be stateless Check, it's stateless. > The authentication parameter "realm" is reserved We don't use it. > The "token68" notation was introduced for compatibility with > existing authentication schemes and can only be used once per > challenge or credential. We use the auth-param approach and stay far away from token68. > When the auth-param syntax is used, all parameters ought to support > both token and quoted-string syntax, and syntactical constraints > ought to be defined on the field value after parsing (i.e., > quoted-string processing). We were not doing this, it's been clarified in the spec now by removing the ABNF, which was largely unnecessary: https://github.com/web-payments/web-payments.org/commit/3b37035ae0c8c94c8705c4cb103fd801daa4b96f > Definitions of new schemes ought to define the treatment of unknown > extension parameters. Fixed: https://github.com/web-payments/web-payments.org/commit/dfed1f92341722749c2dd653b1658dd092232967 > Authentication schemes need to document whether they are usable in > origin-server authentication (i.e., using WWW-Authenticate), and/or > proxy authentication (i.e., using Proxy-Authenticate). Waiting on feedback from Julian and you to address this issue. It's being tracked here: https://github.com/web-payments/web-payments.org/issues/23 > Therefore, new authentication schemes that choose not to carry > credentials in the Authorization header field (e.g., using a newly > defined header field) will need to explicitly disallow caching I'm sure someone more versed in HTTP knows what this means, but I'm having a hard time figuring out if this applies to us. My reading on it is: If you chose to use some information that's outside of the Authorization header that is used by the authorization scheme in some way, you need to be explicit about whether or not the request should be cached. I don't think this applies to this spec because we are okay with a response being cached if the digital signature on the request is the same (ie: a botnet of clients requesting the exact same document with the same set of headers signed). That said, I'm probably not the best person to make this determination, do you have any thoughts on the matter? >> - If this is the Digest header field defined in >> then the spec >> should say so. > > This confused me too. Fixed: https://github.com/web-payments/web-payments.org/commit/3e3d215d30ae7069703061b5be7db3917888fa00 Thanks a ton for the feedback Mark! It's very much appreciated. If you could let us know your thoughts on how we should extend the spec to cover both client to server and server to client verified HTTP headers, that'd be swell. It doesn't seem like it would be much work, but we're struggling wrt. a proper approach that would fit in with the larger body of work on HTTP. :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Worlds First Web Payments Workshop http://www.w3.org/2013/10/payments/ From ynir@checkpoint.com Fri Feb 7 15:19:54 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452A91A0445 for ; Fri, 7 Feb 2014 15:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwBpmAUCeoHW for ; Fri, 7 Feb 2014 15:19:53 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA811A042B for ; Fri, 7 Feb 2014 15:19:52 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s17NJpFk000518 for ; Sat, 8 Feb 2014 01:19:51 +0200 X-CheckPoint: {52F5630E-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Sat, 8 Feb 2014 01:19:51 +0200 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Meeting in London Thread-Index: AQHPJFsZUstvpRyXt02Jd8e410gWaw== Date: Fri, 7 Feb 2014 23:19:50 +0000 Message-ID: <6B0296E0-E324-4BAE-AFC9-47254641AE84@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.20] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <4CFECC4919CF8C41AC658E41A689AADA@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Meeting in London X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 23:19:54 -0000 Hi The final agenda has been published ([1]). HTTP-Auth is meeting for 2 hours= and ten minutes. It's actually a concatenation of two 1-hour sessions, plu= s the 10 minute break between them. Don't worry about missing the break, it= is not one of the beverage or snack breaks. We already have some items on our (as yet to be published) agenda, but ther= e's still some time left. So if you have requests for meeting time, and wou= ld like to present or discuss something, please drop us a note. See you all there, Matt & Yoav [1] http://tools.ietf.org/agenda/89/= From ynir@checkpoint.com Fri Feb 7 15:21:15 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5E21A0445 for ; Fri, 7 Feb 2014 15:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUA8s6AGDE08 for ; Fri, 7 Feb 2014 15:21:13 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9B31A0444 for ; Fri, 7 Feb 2014 15:21:13 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s17NLCeG000805 for ; Sat, 8 Feb 2014 01:21:12 +0200 X-CheckPoint: {52F5635F-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Sat, 8 Feb 2014 01:21:12 +0200 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Meeting in London Thread-Index: AQHPJFsZUstvpRyXt02Jd8e410gWa5qqTFQA Date: Fri, 7 Feb 2014 23:21:11 +0000 Message-ID: References: <6B0296E0-E324-4BAE-AFC9-47254641AE84@checkpoint.com> In-Reply-To: <6B0296E0-E324-4BAE-AFC9-47254641AE84@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.20] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] Meeting in London X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 23:21:16 -0000 Forgot to say the time. It's Monday, March 3rd, 15:20-17:30 in the "Palace = C" room. On Feb 8, 2014, at 1:19 AM, Yoav Nir wrote: > Hi >=20 > The final agenda has been published ([1]). HTTP-Auth is meeting for 2 hou= rs and ten minutes. It's actually a concatenation of two 1-hour sessions, p= lus the 10 minute break between them. Don't worry about missing the break, = it is not one of the beverage or snack breaks. >=20 > We already have some items on our (as yet to be published) agenda, but th= ere's still some time left. So if you have requests for meeting time, and w= ould like to present or discuss something, please drop us a note. >=20 > See you all there, >=20 > Matt & Yoav >=20 > [1] http://tools.ietf.org/agenda/89/ From internet-drafts@ietf.org Wed Feb 12 15:51:20 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9EA1A0032; Wed, 12 Feb 2014 15:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJl1DoqcWDqy; Wed, 12 Feb 2014 15:51:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 855E11A004C; Wed, 12 Feb 2014 15:51:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212235118.16328.74424.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 15:51:18 -0800 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-05.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:51:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-05.txt Pages : 30 Date : 2014-02-12 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Wed Feb 12 15:55:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886961A0031; Wed, 12 Feb 2014 15:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNERfDUeL1IY; Wed, 12 Feb 2014 15:55:44 -0800 (PST) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id A22151A002F; Wed, 12 Feb 2014 15:55:43 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id e51so4116402eek.28 for ; Wed, 12 Feb 2014 15:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hbtKTfDrLG7ttDkqxKIKx8+xw3owNrA/EtrxaNXUYWQ=; b=UGF5ZMWs88mkA6AJlBQ4Xrt9BldDJLvAtDEKOiB2vLbl6FxpfZLUK89x/EKnhrW/T5 PWVGGw9UBWtlgj270cKTrKc3jVxg0Y9e6K5GLiOmkk+hvvofjdoc5qJxs1app7WpFD2p pEdEYuZIDCnL2mmfYPefyh3YpPzHJsap4r172EL6oAPvrQ9Ge5KZB+8cLFdBR4xhV4wa sFi+TACCWmsAMOejBsZRKFNyGRoaj9IkIH+cVWZTM0KK3UhkpzKqhfcd2MLj5wjALA5X KFYfUkxLOkWcP/GMO1OSR90azhr6TWfFLsKxTt6SCZpbkjjkgRvt5EZHdNW1TVZyXZDj bkrQ== MIME-Version: 1.0 X-Received: by 10.14.202.136 with SMTP id d8mr7271963eeo.46.1392249342258; Wed, 12 Feb 2014 15:55:42 -0800 (PST) Received: by 10.14.149.6 with HTTP; Wed, 12 Feb 2014 15:55:42 -0800 (PST) In-Reply-To: <20140212235118.16328.74424.idtracker@ietfa.amsl.com> References: <20140212235118.16328.74424.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 18:55:42 -0500 Message-ID: From: Rifaat Shekh-Yusef To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=047d7b343afa7bf39304f23e4f64 Cc: "http-auth@ietf.org" , i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-05.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:55:46 -0000 --047d7b343afa7bf39304f23e4f64 Content-Type: text/plain; charset=ISO-8859-1 Hi, This new version of the draft addresses the latest comments with regards to syntax, registration of the Authentication-Info header, text around obsoleting RFC2617, and many editorials fixes. We would appreciate any feedback on this latest version of the document. Regards, Rifaat On Wed, Feb 12, 2014 at 6:51 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-05.txt > Pages : 30 > Date : 2014-02-12 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --047d7b343afa7bf39304f23e4f64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

This new version of the = draft addresses the latest comments with regards to syntax, registration of= the Authentication-Info header, text around obsoleting RFC2617, and many e= ditorials fixes.
We would appreciate any feedback on this latest version of the documen= t.

Regards,
=A0Rifaat





On Wed, Feb 12, 2014 at 6:51 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP Digest Access Authenticati= on
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-digest-05.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-12

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-05
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-05


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

--047d7b343afa7bf39304f23e4f64-- From julian.reschke@gmx.de Thu Feb 13 00:05:04 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82DB1A0164 for ; Thu, 13 Feb 2014 00:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7eKrwe59IIf for ; Thu, 13 Feb 2014 00:04:57 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 859AF1A0160 for ; Thu, 13 Feb 2014 00:04:57 -0800 (PST) Received: from [192.168.1.103] ([93.217.97.16]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MWBpJ-1Vh0YT0BQ1-00XNSp for ; Thu, 13 Feb 2014 09:04:56 +0100 Message-ID: <52FC7CA9.3080808@gmx.de> Date: Thu, 13 Feb 2014 09:04:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20140212235118.16328.74424.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:n2GfBqKtp3rcZ0YYqE28bukyG5nqZfilVkHKiY2y75giZB7bj6O P3kcogtvQIULfYAGaSfwnovRuE9uJnB55W8+ec5SR4I8cHZFQZNOjkoW3R+C9z2irBfJDnx /RCphhSsIF5nHJY9vOdXItfzg8182rNWsvVwI+GLWVl1Y0wdoFVUTIb7eEB2sWbeTc1d9eU 4xCM35MMp6IT0PWglIzKA== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-05.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 08:05:04 -0000 On 2014-02-13 00:55, Rifaat Shekh-Yusef wrote: > Hi, > > This new version of the draft addresses the latest comments with regards > to syntax, registration of the Authentication-Info header, text around > obsoleting RFC2617, and many editorials fixes. > We would appreciate any feedback on this latest version of the document. > > Regards, > Rifaat > ... Two points after a quick read: 1) Your references to Internet Drafts should have the actual draft name in them (). 2) You now cite RFC 5234 (good). RFC 2617 used an ABNF variant that used implied linear white space. Did you check that those ABNF productions that were carried over from 2617 are still correct? Best regards, Julian From pauljleach@msn.com Thu Feb 13 02:25:21 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68C71A01C7 for ; Thu, 13 Feb 2014 02:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-1fC2YNEIIA for ; Thu, 13 Feb 2014 02:25:20 -0800 (PST) Received: from snt0-omc3-s20.snt0.hotmail.com (snt0-omc3-s20.snt0.hotmail.com [65.55.90.159]) by ietfa.amsl.com (Postfix) with ESMTP id 696851A01CA for ; Thu, 13 Feb 2014 02:25:18 -0800 (PST) Received: from SNT147-DS26 ([65.55.90.135]) by snt0-omc3-s20.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Feb 2014 02:25:17 -0800 X-TMN: [QI0Anq2cA0+Rn0VI+Lmso5iOwqLoP0zy] X-Originating-Email: [pauljleach@msn.com] Message-ID: From: Paul Leach To: "'Rifaat Shekh-Yusef'" References: <20140212235118.16328.74424.idtracker@ietfa.amsl.com> <52FC7CA9.3080808@gmx.de> In-Reply-To: <52FC7CA9.3080808@gmx.de> Date: Thu, 13 Feb 2014 02:25:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGMOKr+NsQI5Lc3KWnoJeHR+8QpWgHnsamWAZtY+o+bHMFhMA== Content-Language: en-us X-OriginalArrivalTime: 13 Feb 2014 10:25:17.0688 (UTC) FILETIME=[E3FEDF80:01CF28A5] Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-05.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:25:21 -0000 Note that in the following text from section 3.3, the algorithm is SHA-256, yet the description refers to MD5. "For example: For the "SHA-256" and "SHA-256-sess" algorithms H(data) = SHA-256(data) i.e., the digest is the MD5 of the secret concatenated with a colon concatenated with the data. The "MD5-sess" algorithm is..." > -----Original Message----- > On 2014-02-13 00:55, Rifaat Shekh-Yusef wrote: > > Hi, > > > > This new version of the draft addresses the latest comments with > > regards to syntax, registration of the Authentication-Info header, > > text around obsoleting RFC2617, and many editorials fixes. > > We would appreciate any feedback on this latest version of the document. > > > > Regards, > > Rifaat > > ... From rifaat.ietf@gmail.com Thu Feb 13 05:40:20 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7894C1A017E for ; Thu, 13 Feb 2014 05:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0H-7FVboIvp for ; Thu, 13 Feb 2014 05:40:18 -0800 (PST) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F0AF81A01D5 for ; Thu, 13 Feb 2014 05:40:17 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id b15so5031114eek.4 for ; Thu, 13 Feb 2014 05:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dcbn3VVev49FN1SGRzQHmP4kUU+VcoZBlw1VPnZkb7o=; b=NN8kZ/jBIBBWPa5elZ7nQ2CD/ao4wj74hLLWHqWVGfIDRo+sQ39vJfTnq9DPZ5LzaE SfPlGw3oWtnK0gK9hkuhLtkbiw3+UhjZAWq2FUzR8TG0KMcynCDAwCs6vQ7WkENFAi6e LIHAOX92O13FzsdIFfFxa8oPf0PKVeCgvqoO+HpGe8WG2hMG0nJIbCeQplpuvllbfKZ/ uSPOwgp/AaVbmr1UtIfNHFRZgx9DnT+Lx07wx2W4PxuHckbIaUZZ7XWD2zjRCC9uS5Vf vGzalr8MyHsYGdMHQzhrUY/nMLNAjJrhbxAaHj4RwC9dkqQBXqsVcvklJxZh/EDOC02U fm3A== MIME-Version: 1.0 X-Received: by 10.15.82.72 with SMTP id z48mr90986eey.115.1392298816366; Thu, 13 Feb 2014 05:40:16 -0800 (PST) Received: by 10.14.149.6 with HTTP; Thu, 13 Feb 2014 05:40:16 -0800 (PST) In-Reply-To: References: <20140212235118.16328.74424.idtracker@ietfa.amsl.com> <52FC7CA9.3080808@gmx.de> Date: Thu, 13 Feb 2014 08:40:16 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Paul Leach Content-Type: multipart/alternative; boundary=089e015383765eebb404f249d4f7 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-05.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:40:20 -0000 --089e015383765eebb404f249d4f7 Content-Type: text/plain; charset=ISO-8859-1 Thanks Paul, I will fix that in the next version of the document. Regards, Rifaat On Thu, Feb 13, 2014 at 5:25 AM, Paul Leach wrote: > Note that in the following text from section 3.3, the algorithm is SHA-256, > yet the description refers to MD5. > > "For example: > > For the "SHA-256" and "SHA-256-sess" algorithms > > H(data) = SHA-256(data) > > > > i.e., the digest is the MD5 of the secret concatenated with a > colon concatenated with the data. The "MD5-sess" algorithm is..." > > > -----Original Message----- > > On 2014-02-13 00:55, Rifaat Shekh-Yusef wrote: > > > Hi, > > > > > > This new version of the draft addresses the latest comments with > > > regards to syntax, registration of the Authentication-Info header, > > > text around obsoleting RFC2617, and many editorials fixes. > > > We would appreciate any feedback on this latest version of the > document. > > > > > > Regards, > > > Rifaat > > > ... > > --089e015383765eebb404f249d4f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Paul,

I will fix = that in the next version of the document.

Regards,=
=A0Rifaat

<= br>
On Thu, Feb 13, 2014 at 5:25 AM, Paul Leach = <pauljleach@msn.com> wrote:
Note that in the following text from section 3.3, the algorithm is SHA-256,=
yet the description refers to MD5.

"For example:

=A0 =A0 =A0 =A0 =A0 =A0For the "SHA-256" and "SHA-256-sess&q= uot; algorithms

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0H(data) =3D SHA-256(data)



=A0 =A0 =A0 =A0 =A0i.e., the digest is the MD5 of the secret concatenated w= ith a
=A0 =A0 =A0 =A0 =A0colon concatenated with the data. The "MD5-sess&quo= t; algorithm is..."

> -----Original Message-----
> On 2014-02-13 00:55, Rifaat Shekh-Yusef wrote:
> > Hi,
> >
> > This new version of the draft addresses the latest comments with<= br> > > regards to syntax, registration of the Authentication-Info header= ,
> > text around obsoleting RFC2617, and many editorials fixes.
> > We would appreciate any feedback on this latest version of the do= cument.
> >
> > Regards,
> > =A0 Rifaat
> > ...


--089e015383765eebb404f249d4f7-- From nobody Fri Feb 14 07:18:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E191A02A7 for ; Fri, 14 Feb 2014 07:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiY9SdPdEMBM for ; Fri, 14 Feb 2014 07:18:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id ABA491A02A6 for ; Fri, 14 Feb 2014 07:18:19 -0800 (PST) Received: from netb.Speedport_W_700V ([84.180.224.119]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LzHZ7-1VAlKr0gPx-014Vnw for ; Fri, 14 Feb 2014 16:18:17 +0100 From: Bjoern Hoehrmann To: http-auth@ietf.org Date: Fri, 14 Feb 2014 16:18:19 +0100 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:sp3sZyrQBtH2bfzqJFA0us+jFNC0FESIudQC+xFMNLvAGuq/Cx9 viub4+bsYtMzxdyGImFCKXSxw2WnqU4Rk4g1Aa9r0kIJ+/DzDcH4+3owR5JYs4Cb/SYJsqT S6Cb6UPQ9M26rUJNL+nk6qGrqdJ9CfK6wRfF+ZrlVr01OnvKolm4Lq4NnNHIMw0OWUb2gGs KGvJOuyLmjK/GYdceqOZA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/vbkAVwX7c0TqL7ye7QWfmPJDZzI Subject: [http-auth] HTTP Authentication encoding test results X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:18:22 -0000 Hi, On the German Apache HTTPD users mailing list someone was having difficulties using non-ascii characters in HTTP Basic Authentication and posted these test results,   TortoiseSVN   Password: "E€D$P§äöü123"   Hex: "45,E2,82,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33"     Chrome   Password: "Eâ?¬D$P§äöü123"   Hex: "45,C3,A2,C2,82,C2,AC,44,24,50,C3,82,C2,A7,C3,83,C2,A4,C3,83,C2,B6,C3,83,C2,BC,31,32,33"     Internet Explorer   Password: "E?D$P§äöü123"   Hex: "45,C2,80,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33"     Firefox   Password: "E¬D$P§äöü123"   Hex: "45,C2,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" I analysed these samples and TortoiseSVN does just plain UTF-8, Chrome does double-UTF-8, and IE and Firefox first apply Windows-1252 and then UTF-8 on the result. I do recall Firefox doing something worse but could not find the bug report when I briefly looked for it... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Fri Feb 14 07:56:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4F11A02B0 for ; Fri, 14 Feb 2014 07:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBGJPWs33xDt for ; Fri, 14 Feb 2014 07:56:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A86531A0284 for ; Fri, 14 Feb 2014 07:56:43 -0800 (PST) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MC3zg-1W5VQO3v1M-008tVc for ; Fri, 14 Feb 2014 16:56:41 +0100 Message-ID: <52FE3CB8.6050502@gmx.de> Date: Fri, 14 Feb 2014 16:56:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bjoern Hoehrmann , http-auth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:76BbPgTxLODPbXzYVz5AEo5OLCKjmklVWNpr/sn0VWdFm7eJ1YY XhFeQMVHWxDhM7++1p0m1tcB6tbe2Tz87PiytmFDucdtiMplGe6g7iUX5v6NjBx0gaoQ1/4 NhTnLEA77kVWVg7cWsyYvPztkq5S/3AJJDpn1Jkn/NOy31pWmIypTpaAjLnjHKWX0p6vY2Q tw1B1cFMMEiKJZmNPNmpg== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/z9uT49gKUZNH6b9jI2v-77MGaf0 Subject: Re: [http-auth] HTTP Authentication encoding test results X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:56:45 -0000 On 2014-02-14 16:18, Bjoern Hoehrmann wrote: > Hi, > > On the German Apache HTTPD users mailing list someone was having > difficulties using non-ascii characters in HTTP Basic Authentication > and posted these test results, > > TortoiseSVN > Password: "E€D$P§äöü123" > Hex: "45,E2,82,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" > > Chrome > Password: "Eâ?¬D$P§äöü123" > Hex: "45,C3,A2,C2,82,C2,AC,44,24,50,C3,82,C2,A7,C3,83,C2,A4,C3,83,C2,B6,C3,83,C2,BC,31,32,33" > > Internet Explorer > Password: "E?D$P§äöü123" > Hex: "45,C2,80,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" > > Firefox > Password: "E¬D$P§äöü123" > Hex: "45,C2,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" > > I analysed these samples and TortoiseSVN does just plain UTF-8, Chrome > does double-UTF-8, and IE and Firefox first apply Windows-1252 and then > UTF-8 on the result. I do recall Firefox doing something worse but could > not find the bug report when I briefly looked for it... With my test server, the username "test" and the password "E€D$P§äöü123" I see: > UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 > Raw authentication header: Basic dGVzdDpFrEQkUKfk9vwxMjM= > Decoded as byte sequence: 74 65 73 74 3a 45 ac 44 24 50 a7 e4 f6 fc 31 32 33 > Decoded as ISO-8859-1: test:E¬D$P§äöü123 > Decoded as UTF-8: test:E?D$P???? Firefox: the € ends up as 0xac, so it appears the lower 8 bits of 20ac have been sent. > UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36 > Raw authentication header: Basic dGVzdDpF4oKsRCRQwqfDpMO2w7wxMjM= > Decoded as byte sequence: 74 65 73 74 3a 45 e2 82 ac 44 24 50 c2 a7 c3 a4 c3 b6 c3 bc 31 32 33 > Decoded as ISO-8859-1: test:Eâ?¬D$P§äöü123 > Decoded as UTF-8: test:E€D$P§äöü123 Chrome: proper UTF-8. > UA: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko > Raw authentication header: Basic dGVzdDpFgEQkUKfk9vwxMjM= > Decoded as byte sequence: 74 65 73 74 3a 45 80 44 24 50 a7 e4 f6 fc 31 32 33 > Decoded as ISO-8859-1: test:E?D$P§äöü123 > Decoded as UTF-8: test:E?D$P???? IE: sends the € as 0x80, which probably make sense from their point of view ;-) Best regards, Julian From nobody Sun Feb 23 23:17:39 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39841A0357 for ; Sun, 23 Feb 2014 23:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2f3hkjIL1iS for ; Sun, 23 Feb 2014 23:17:36 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B0D481A081A for ; Sun, 23 Feb 2014 23:17:35 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s1O7HUNa018250 for ; Mon, 24 Feb 2014 09:17:31 +0200 Received: from IL-EX10.ad.checkpoint.com ([169.254.2.228]) by DAG-EX10.ad.checkpoint.com ([169.254.3.228]) with mapi id 14.03.0123.003; Mon, 24 Feb 2014 09:17:30 +0200 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: HTTP-Auth Meeting at IETF 89 Thread-Index: AQHPMTB6tF9Opc3hn0iQPHPfi6CeAQ== Date: Mon, 24 Feb 2014 07:17:29 +0000 Message-ID: <818504B2-69B3-4313-B585-531635A526D2@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.203] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <6B2302B338BBA149AEB94C706F9FDFF6@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Ei75_Z0mKxg4Im6jm3UsZB0K1Q0 Subject: [http-auth] HTTP-Auth Meeting at IETF 89 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 07:17:38 -0000 Hi all The agenda has been posted (also attached below) https://datatracker.ietf.org/meeting/89/agenda/httpauth/ Rifaat, Julian, Alexey: please send in your slides before the meeting, as w= e're meeting on Monday. Also, please include slide numbers, as those make i= t much easier to describe things on Jabber. For those of you not able to attend, here's how to join in remotely: Audio stream: http://ietf89streaming.dnsalias.net/ietf/ietf894.m3u Jabber room: xmpp:httpauth@jabber.ietf.org?join Yoav & Matt Agenda for the HTTP-Auth Meeting at IETF 89 Time: Monday, March 3rd, 2014, 15:20-17:30 (both UTC and local) Room: Palace C Agenda: 00:00-00:05 - Agenda bashing, Note well, and blue sheets 00:05-00:35 - Digest - Rifaat 00:35-00:45 - Basic - Julian 00:45-01:00 - Obsoleting RFC 2617 - chairs 01:00-01:30 - SCRAM - Alexey 01:30-01:40 - Progress on experimental drafts - chairs 01:40-02:10 - open mic / early access to cookies =20 Note that many of the issues with Basic and Digest are common,=20 so the discussion of these may overlap From nobody Wed Feb 26 18:43:16 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE691A036F; Wed, 26 Feb 2014 18:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HZeAKZiXg1R; Wed, 26 Feb 2014 18:43:07 -0800 (PST) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 157931A071F; Wed, 26 Feb 2014 18:43:06 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id g12so1863125oah.30 for ; Wed, 26 Feb 2014 18:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=28ggBlHHr405OJTWYBxva2Wu8ucIe8MnlzOwaJJuTWQ=; b=M89axJ3GJMxiL6NJrlski0QEhzKiHsySrKQJZaMwge09M9+6nGlVEXeabTUroTef8P Xpn/o0ezmoHhXXKtBcF17blSQ4bNL7CNWOnFxvGAx6IvW8od5pbutZts1+VDu3yq7Sb5 Q1UK9n42RGM4u2fG9iuXZBhgxYb9VXs+Ifoi8o1IzE6toTHjzMzFjP9HEacFbspO5HXy 0B1Dh3pB53bzjKvFEAwFgpnbfN/Z0MQkKQT50+DvbAK5rzQRYpJvJ3c21OV1QMF/uZds aPQUSRp7Pk2wkwTBgeMReW8W6vCf45dDmXejuSWnYvp6xDWjkAQdISb/SLx39WakZxH7 8mtA== MIME-Version: 1.0 X-Received: by 10.182.153.41 with SMTP id vd9mr8865obb.87.1393468984565; Wed, 26 Feb 2014 18:43:04 -0800 (PST) Received: by 10.76.190.104 with HTTP; Wed, 26 Feb 2014 18:43:04 -0800 (PST) In-Reply-To: <52FE3CB8.6050502@gmx.de> References: <52FE3CB8.6050502@gmx.de> Date: Thu, 27 Feb 2014 11:43:04 +0900 Message-ID: From: Kaoru Maeda To: Julian Reschke Content-Type: multipart/alternative; boundary=089e013a1046d4a6e204f35a476f Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/gfTBP8NDcexZpnJivu-Z1WZ0h90 Cc: http-auth@ietf.org, Bjoern Hoehrmann , precis@ietf.org Subject: Re: [http-auth] HTTP Authentication encoding test results X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 02:43:10 -0000 --089e013a1046d4a6e204f35a476f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I tested how Authorization Basic implementations handle Japanese characters= . Tests done in Japanese environment on MacOS X (10.9.2). Safari 7.0.2 (9537.74.9) * If any Japanese Characters (Kanji, Hiragana, etc) exist in either username or password, Safari does not produce any Authorization header at all, even without any error messages. It behaves as if password was incorrect, from the user's point of view. * You might want to try the same with European accented characters above U+00FF. Firefox 27.0.1 * lowest 8 bit of the Unicode code point, 1-byte for each character. Chrome 33.0.1750.117 * UTF-8 precomposed (this is what we expect). CJK characters have problems (except Chrome) in this respect. Japanese users are well familiar with avoiding non-ASCII usernames and passwords. :P Best regards, --=20 Kaoru Maeda Lepidum Co., Ltd. 2014-02-15 0:56 GMT+09:00 Julian Reschke : > On 2014-02-14 16:18, Bjoern Hoehrmann wrote: > >> Hi, >> >> On the German Apache HTTPD users mailing list someone was having >> difficulties using non-ascii characters in HTTP Basic Authentication >> and posted these test results, >> >> TortoiseSVN >> Password: "E EURO D$P=A7=E4=F6=FC123" >> Hex: "45,E2,82,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> Chrome >> Password: "E=E2?=ACD$P=C2=A7=C3=A4=C3=B6=C3 1/4 123" >> Hex: "45,C3,A2,C2,82,C2,AC,44,24,50,C3,82,C2,A7,C3,83,C2,A4,C3, >> 83,C2,B6,C3,83,C2,BC,31,32,33" >> >> Internet Explorer >> Password: "E?D$P=A7=E4=F6=FC123" >> Hex: "45,C2,80,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> Firefox >> Password: "E=ACD$P=A7=E4=F6=FC123" >> Hex: "45,C2,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> I analysed these samples and TortoiseSVN does just plain UTF-8, Chrome >> does double-UTF-8, and IE and Firefox first apply Windows-1252 and then >> UTF-8 on the result. I do recall Firefox doing something worse but could >> not find the bug report when I briefly looked for it... >> > > With my test server, the username "test" and the password "E EURO D$P=A7= =E4=F6=FC123" I > see: > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 >> Firefox/27.0 >> Raw authentication header: Basic dGVzdDpFrEQkUKfk9vwxMjM=3D >> Decoded as byte sequence: 74 65 73 74 3a 45 ac 44 24 50 a7 e4 f6 fc 31 3= 2 >> 33 >> Decoded as ISO-8859-1: test:E=ACD$P=A7=E4=F6=FC123 >> Decoded as UTF-8: test:E?D$P???? >> > > Firefox: the EURO ends up as 0xac, so it appears the lower 8 bits of 20ac > have been sent. > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like >> Gecko) Chrome/32.0.1700.107 Safari/537.36 >> Raw authentication header: Basic dGVzdDpF4oKsRCRQwqfDpMO2w7wxMjM=3D >> Decoded as byte sequence: 74 65 73 74 3a 45 e2 82 ac 44 24 50 c2 a7 c3 a= 4 >> c3 b6 c3 bc 31 32 33 >> Decoded as ISO-8859-1: test:E=E2?=ACD$P=C2=A7=C3=A4=C3=B6=C3 1/4 123 >> Decoded as UTF-8: test:E EURO D$P=A7=E4=F6=FC123 >> > > Chrome: proper UTF-8. > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko >> Raw authentication header: Basic dGVzdDpFgEQkUKfk9vwxMjM=3D >> Decoded as byte sequence: 74 65 73 74 3a 45 80 44 24 50 a7 e4 f6 fc 31 3= 2 >> 33 >> Decoded as ISO-8859-1: test:E?D$P=A7=E4=F6=FC123 >> Decoded as UTF-8: test:E?D$P???? >> > > IE: sends the EURO as 0x80, which probably make sense from their point of > view ;-) > > Best regards, Julian > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e013a1046d4a6e204f35a476f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

I tested how Authoriz= ation Basic implementations handle Japanese characters.
Tests don= e in Japanese environment on MacOS X (10.9.2).

Saf= ari 7.0.2 (9537.74.9)
 * If any Japanese Characters (Kanji, Hiragana, etc) exist in eit= her username or password, Safari does not produce any Authorization header = at all, even without any error messages.  It behaves as if password wa= s incorrect, from the user's point of view.
 * You might want to try the same with European accented characte= rs above U+00FF.

Firefox 27.0.1
 * = lowest 8 bit of the Unicode code point, 1-byte for each character.

Chrome 33.0.1750.117
 * UTF-8 precomposed (this i= s what we expect).

CJK characters have problems (e= xcept Chrome) in this respect.
Japanese users are well familiar w= ith avoiding non-ASCII usernames and passwords. :P

Best regards,

-- 
Kaoru Maeda <maeda@lepidum.co.jp>
Lepidum Co., Ltd.



2= 014-02-15 0:56 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>= :
On 2014-02-14 16:18, Bjoern = Hoehrmann wrote:
Hi,

   On the German Apache HTTPD users mailing list someone was havi= ng
difficulties using non-ascii characters in HTTP Basic Authentication
and posted these test results,

   TortoiseSVN
   Password: "E€D$P=A7=E4=F6=FC123"
   Hex: "45,E2,82,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC= ,31,32,33"

   Chrome
   Password: "E=E2?=ACD$P=C2=A7=C3=A4=C3=B6=C3¼123&qu= ot;
   Hex: "45,C3,A2,C2,82,C2,AC,44,24,50,C3,82,C2,A7,C3= ,83,C2,A4,C3,83,C2,B6,C3,83,C2,BC,31,32,33"

   Internet Explorer
   Password: "E?D$P=A7=E4=F6=FC123"
   Hex: "45,C2,80,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31= ,32,33"

   Firefox
   Password: "E=ACD$P=A7=E4=F6=FC123"
   Hex: "45,C2,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31= ,32,33"

I analysed these samples and TortoiseSVN does just plain UTF-8, Chrome
does double-UTF-8, and IE and Firefox first apply Windows-1252 and then
UTF-8 on the result. I do recall Firefox doing something worse but could not find the bug report when I briefly looked for it...

With my test server, the username "test" and the password "E= €D$P=A7=E4=F6=FC123" I see:

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.= 0
Raw authentication header: Basic dGVzdDpFrEQkUKfk9vwxMjM=3D
Decoded as byte sequence: 74 65 73 74 3a 45 ac 44 24 50 a7 e4 f6 fc 31 32 3= 3
Decoded as ISO-8859-1: test:E=ACD$P=A7=E4=F6=FC123
Decoded as UTF-8: test:E?D$P????

Firefox: the € ends up as 0xac, so it appears the lower 8 bits of 20ac= have been sent.

UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gec= ko) Chrome/32.0.1700.107 Safari/537.36
Raw authentication header: Basic dGVzdDpF4oKsRCRQwqfDpMO2w7wxMjM=3D<= br> Decoded as byte sequence: 74 65 73 74 3a 45 e2 82 ac 44 24 50 c2 a7 c3 a4 c= 3 b6 c3 bc 31 32 33
Decoded as ISO-8859-1: test:E=E2?=ACD$P=C2=A7=C3=A4=C3=B6=C3¼123
Decoded as UTF-8: test:E€D$P=A7=E4=F6=FC123

Chrome: proper UTF-8.

UA: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Raw authentication header: Basic dGVzdDpFgEQkUKfk9vwxMjM=3D
Decoded as byte sequence: 74 65 73 74 3a 45 80 44 24 50 a7 e4 f6 fc 31 32 3= 3
Decoded as ISO-8859-1: test:E?D$P=A7=E4=F6=FC123
Decoded as UTF-8: test:E?D$P????

IE: sends the € as 0x80, which probably make sense from their point of= view ;-)

Best regards, Julian



_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

--089e013a1046d4a6e204f35a476f--