From nobody Fri Jan 3 09:54:45 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A66120091 for ; Fri, 3 Jan 2020 09:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 HDEWo-Wv50eX for ; Fri, 3 Jan 2020 09:54:41 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8F1120013 for ; Fri, 3 Jan 2020 09:54:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E7526300B31 for ; Fri, 3 Jan 2020 12:54:39 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id c9iDg_Fzy8b5 for ; Fri, 3 Jan 2020 12:54:39 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id F39F13001CC for ; Fri, 3 Jan 2020 12:54:38 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 3 Jan 2020 12:54:39 -0500 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> To: LAMPS WG In-Reply-To: Message-Id: <399BE14D-FD3E-4528-A6AA-E170BB46ED85@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 17:54:43 -0000 A few people have spoken in support of adopting this document without = GRASP discovery. No one has spoken against adoption. So, the LAMPS WG has adopted it. Michael, please revise the document to remove GRASP discovery, and then = post draft-ietf-lamps-rfc7030est-clarify-00. Russ > On Dec 22, 2019, at 9:46 PM, Russ Housley = wrote: >=20 > Please indicate whether you support adoption of = draft-richardson-lamps-rfc7030est-clarify by the LAMPS WG by January = 3rd. >=20 > I previously sent a message with this correct subject, but the body = contained the wrong draft name. This restarts the call with a new date. >=20 > Russ >=20 From nobody Fri Jan 3 11:05:31 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AF6120875 for ; Fri, 3 Jan 2020 11:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 I6A8soCV7lAx for ; Fri, 3 Jan 2020 11:05:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E2812009E for ; Fri, 3 Jan 2020 11:05:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39481BE51; Fri, 3 Jan 2020 19:05:22 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DIan2FRnd6d; Fri, 3 Jan 2020 19:05:20 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 36C96BE50; Fri, 3 Jan 2020 19:05:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578078320; bh=aXi1S2KKv/vuT4is+Gtm1qX5noWW42Ibcfr0jRxERbw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=zjQCEcueidkebICFDdcwU7/vsu1vqd49GGiOCgfBV0MyHH9fSVVbk8YmxPXR8GsBS fjTPk3USfNRRaIAiGpbQFqpEkwAwGxe4y6U7eAho8/JdvdTCylFx4fUCF5gt26f3oY HI0hLale1zb1ERfORyneGyRsGVmU6kPzDBb84frI= To: Russ Housley , LAMPS WG References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <399BE14D-FD3E-4528-A6AA-E170BB46ED85@vigilsec.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <40d059ff-402d-27c2-cd81-916dc423a648@cs.tcd.ie> Date: Fri, 3 Jan 2020 19:05:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <399BE14D-FD3E-4528-A6AA-E170BB46ED85@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="35I8w5Y8XL5LcJTmm1wsAYtYoIQhuRxgy" Archived-At: Subject: Re: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 19:05:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --35I8w5Y8XL5LcJTmm1wsAYtYoIQhuRxgy Content-Type: multipart/mixed; boundary="UyzY4JDxmnhd5prjsxP1iMYfQEtLqi0Lc"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , LAMPS WG Message-ID: <40d059ff-402d-27c2-cd81-916dc423a648@cs.tcd.ie> Subject: Re: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <399BE14D-FD3E-4528-A6AA-E170BB46ED85@vigilsec.com> In-Reply-To: <399BE14D-FD3E-4528-A6AA-E170BB46ED85@vigilsec.com> --UyzY4JDxmnhd5prjsxP1iMYfQEtLqi0Lc Content-Type: multipart/mixed; boundary="------------7A3DE11B7C703850C588969F" Content-Language: en-US This is a multi-part message in MIME format. --------------7A3DE11B7C703850C588969F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, On 03/01/2020 17:54, Russ Housley wrote: > A few people have spoken in support of adopting this document without > GRASP discovery. No one has spoken against adoption. >=20 > So, the LAMPS WG has adopted it. I looked back and it seems that two of the three people who support adoption are co-authors. FWIW, while I'm not against adoption (I had a quick read and am neutral) I'm not convinced that's sufficient, nor wise - given this is modifying an existing spec. and I'm not sure all EST implementers are on this list, I'd say it'd be a better plan to ask e.g. on saag to see if there are any real objections (or not). I'm not formally appealing or anything though, mostly just bemoaning yet another aspect of the reincarnation of pkix;-) S. >=20 > Michael, please revise the document to remove GRASP discovery, and > then post draft-ietf-lamps-rfc7030est-clarify-00. >=20 > Russ >=20 >=20 >> On Dec 22, 2019, at 9:46 PM, Russ Housley >> wrote: >>=20 >> Please indicate whether you support adoption of >> draft-richardson-lamps-rfc7030est-clarify by the LAMPS WG by >> January 3rd. >>=20 >> I previously sent a message with this correct subject, but the body >> contained the wrong draft name. This restarts the call with a new >> date. >>=20 >> Russ >>=20 >=20 > _______________________________________________ Spasm mailing list=20 > Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm >=20 --------------7A3DE11B7C703850C588969F Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7A3DE11B7C703850C588969F-- --UyzY4JDxmnhd5prjsxP1iMYfQEtLqi0Lc-- --35I8w5Y8XL5LcJTmm1wsAYtYoIQhuRxgy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4PkG8ACgkQWrL68XsX K+okaw/9Hkl9lGrJOkDM8aC4faMsAKyVnUM7R60pQQR91XAk3OvEuFAVM3KG+xpv 2abw6+iC6muDOq32KcFT1aQV4GqQSrKip8YxFXf9Jg6C7BcQ/1yPogMsKsh9r0a8 FyVjf8C/jmlhFPB5buS+XgVWZAAhi7QlYTaDOqcq/KXeo8NAnFOJ9UPyUjxwUEhD ZtxZ1Uv8QYa7WIcHueYtVEKalMQHYhd4OgpOFH3AmPVV6j2jksLF7AsW+fWU+svt ZdzDBFd3x8OHHbUDOb51L5flUf0Td84BavAEecnWniVGXvQx98IkNDXEw8VvEnXa bzbizss+obgRAaphDDL2zHJueGnbhHg2w5vL+U3wFMj/TWgh5aWLpkeLJJw28Rjq b0V9dH44JHtOBKiM+RCld6+P396CAlDIyvW37i/fuj8LyTiIL/iXvO/orRSaCIjE Nr25KUqChF+LEu7F364dLkZdeY3A7r4m1cHPIZo0/hjJIJi0/o4X7MrrCiPdS1L8 Xw69HHzPjy1iyF9tYrP2OPiHupoFedYlg/RyLg3ubWgux1LW/20Pp5bx+ol+B2Q9 RI5zcBRDlxZgqhLuwtc4VS9sHDVfnMSWc380x0IrpVCOMW00XnPGe7s2CemFUEQj C1Pj54IlrhKy1wVXkGSkKDiWA5/s5cfuCAEztV5mrVPHakCZ+X0= =EQOD -----END PGP SIGNATURE----- --35I8w5Y8XL5LcJTmm1wsAYtYoIQhuRxgy-- From nobody Fri Jan 3 13:37:13 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BD2120045; Fri, 3 Jan 2020 13:37:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <157808743177.8962.5244977294732727430@ietfa.amsl.com> Date: Fri, 03 Jan 2020 13:37:11 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 21:37:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 Authors : Michael Richardson Thomas Werner Wei Pan Filename : draft-ietf-lamps-rfc7030est-clarify-00.txt Pages : 10 Date : 2020-01-03 Abstract: This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that was reported, and which has proven to have interoperability when RFC7030 has been extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints, providing a way to do this in an upward compatible way. This document fixes some syntactical errors in ASN.1 that was presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-00 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 nobody Fri Jan 3 13:55:16 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4170E1200B8; Fri, 3 Jan 2020 13:55:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157808851526.9008.7146932204538934999.idtracker@ietfa.amsl.com> Date: Fri, 03 Jan 2020 13:55:15 -0800 Archived-At: Subject: [lamps] The LAMPS WG has placed draft-richardson-lamps-rfc7030est-clarify in state "Adopted by a WG" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 21:55:15 -0000 The LAMPS WG has placed draft-richardson-lamps-rfc7030est-clarify in state Adopted by a WG (entered by Russ Housley) The document is available at https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ From nobody Fri Jan 3 14:51:21 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEC71200DE for ; Fri, 3 Jan 2020 14:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 a4JE1vu_0wJh for ; Fri, 3 Jan 2020 14:51:17 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933C1120071 for ; Fri, 3 Jan 2020 14:51:17 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BE00A3897D for ; Fri, 3 Jan 2020 17:50:59 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C1322725 for ; Fri, 3 Jan 2020 17:51:16 -0500 (EST) From: Michael Richardson To: LAMPS WG In-Reply-To: <40d059ff-402d-27c2-cd81-916dc423a648@cs.tcd.ie> References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <399BE14D-FD3E-4528-A6AA-E170BB46ED85@vigilsec.com> <40d059ff-402d-27c2-cd81-916dc423a648@cs.tcd.ie> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 22:51:19 -0000 --=-=-= Content-Type: text/plain Stephen Farrell wrote: > On 03/01/2020 17:54, Russ Housley wrote: >> A few people have spoken in support of adopting this document without >> GRASP discovery. No one has spoken against adoption. >> >> So, the LAMPS WG has adopted it. > I looked back and it seems that two of the three people who > support adoption are co-authors. > FWIW, while I'm not against adoption (I had a quick read > and am neutral) I'm not convinced that's sufficient, nor > wise - given this is modifying an existing spec. and I'm > not sure all EST implementers are on this list, I'd say > it'd be a better plan to ask e.g. on saag to see if there > are any real objections (or not). I actually went out to surveyed a few EST implementors back in April/May last year, hoping that we could kill the base64 by signaling it with Content-Transfer-Encoding:, but we can't, because EST implementors out there do not include or pay attention to the header. Do you want the mailarchive links? > I'm not formally appealing or anything though, mostly > just bemoaning yet another aspect of the reincarnation of > pkix;-) My opinion is that anything that makes it easier to automate provisioning of certificates can make it easier to replace the format without causing a flag day. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4PxWQACgkQgItw+93Q 3WWWtQf9FE3KaQmYF/kS4XXXSOpxD+XdyWJT+NM+mYct7Bcm+I9ENo5qSyE6X4UE hGJE3WVEdOeIinpgAYdqj0ZSnH3bOgnkhyYnWx1Z4CjVuInTOxrlLUkRKqSuTST4 VnHcUTOyy5rXlqK34VOzMHFPrdR67FSMoXyRnCkhgzlZDzEVidajKtTVOVIEiw74 TXjl1Hz3Sh2SkG7e0uZEHyN8E3JUSx1Vb5Ro5QJ1lCfYUaFEIBZ7CBzujA7A3E6Y UBA6kHWJ1mgybSdT9h7VaEMYUmOZczgqQnN5XNG0QUL3LphCXj3nZoIoQWWlc/r5 i1RbLXfjoeu9kfVZ1Gt8dFdMifijCg== =84zG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 6 21:03:49 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E71120104 for ; Mon, 6 Jan 2020 21:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uhzT77eG-efR for ; Mon, 6 Jan 2020 21:03:45 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D12120091 for ; Mon, 6 Jan 2020 21:03:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B53A3203BA3; Mon, 6 Jan 2020 21:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCiwWRhpIBhm; Mon, 6 Jan 2020 21:00:59 -0800 (PST) Received: from [172.31.98.5] (unknown [96.229.48.220]) by c8a.amsl.com (Postfix) with ESMTPA id 5B676203AED; Mon, 6 Jan 2020 21:00:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20191228011627.6DD09F40742@rfc-editor.org> Date: Mon, 6 Jan 2020 21:03:44 -0800 Cc: Russ Housley , "Roman D. Danyliw" , kaduk@mit.edu, Tim Hollebeek , spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <21FCE760-611E-492D-AFBC-F5024DE01EC6@amsl.com> References: <20191228011627.6DD09F40742@rfc-editor.org> To: RFC System X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5947) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 05:03:47 -0000 Greetings, FYI - this report has been deleted (junk). Thank you. RFC Editor/mf On Dec 27, 2019, at 5:16 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC8649, > "Hash Of Root Key Certificate Extension". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5947 >=20 > -------------------------------------- > Type: Editorial > Reported by: jarek >=20 > Section: 5 >=20 > Original Text > ------------- >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8649 (draft-ietf-lamps-hash-of-root-key-cert-extn-07) > -------------------------------------- > Title : Hash Of Root Key Certificate Extension > Publication Date : August 2019 > Author(s) : R. Housley > Category : INFORMATIONAL > Source : Limited Additional Mechanisms for PKIX and SMIME > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Tue Jan 7 04:31:21 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A45A1200F1; Tue, 7 Jan 2020 04:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HxrLFcf/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VX987zpg 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 9DQQti3AegmQ; Tue, 7 Jan 2020 04:31:15 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5CB120044; Tue, 7 Jan 2020 04:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74022; q=dns/txt; s=iport; t=1578400274; x=1579609874; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fCNJ6Hu5ZLAR+0sc8aJInRzjs8MIiN3dX7lzDRJaddk=; b=HxrLFcf/89c0Xy8UI9KRrOQ/2OPZYj3E4uvRWpxqJj23kpbr+BlO5ohF fGO2We0C5p/648ch8F5ktG+wbZaaPB02W7cXwzNgQagYaUAXPlXo0ZiOj KdcRYTi3wJv72eoWZLaw8QptycFKTPDJ1uZEFkT4rIGs7aXoNjMfyx7cA 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AgRaOYx0Ecu45rSMnsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGOt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQDkPhLfPuRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAACkeRRe/5JdJa1PDQUCAhoBAQE?= =?us-ascii?q?BAQEBAQEDAQEBAREBAQECAgEBAQGBfIElLyQFJwVsTwEIIAQLKgqDf4NGA4s?= =?us-ascii?q?Dgl+YDYJSA1QJAQEBDAEBGAEOBgIBAYFMgi9FAheBUiQ4EwIDDQEBBAEBAQI?= =?us-ascii?q?BBQRthTcMhV4BAQEBAwEBEAgBCAoTAQEsCwEPAgEIEQQBARQDAggBBgMCAgI?= =?us-ascii?q?lCxQJCAEBBA4FCBqDAYF5TQMuAQIMoQACgTiIYXWBMoJ+AQEFgTUBAwICDEG?= =?us-ascii?q?CfxiCDAMGgTaMGRqBQT+BEUeCTD6CZAEBAgEBgRwZFAwMKwkSBwWCPDKCLI0?= =?us-ascii?q?zGTMDgj+FVySXcnUKgjaHNYwigmCaX4IMhBCRC5INAgQCBAUCDgEBBYFpIiq?= =?us-ascii?q?BLnAVO4JsUBgNjRIMF4EEAQmCQoUUhT90AQmBHosDDxUCB4EEAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.69,406,1571702400"; d="scan'208,217";a="418982091" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2020 12:31:12 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 007CVC5j019868 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 12:31:12 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 06:31:11 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 07:31:11 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 7 Jan 2020 07:31:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IbEY18J0L9h1gHWCiWMvTWo1FPGKCdVDIJsDlKo1xhECFNZC4GHAAUPlXU1fh4spgLX9tf/jhj1uXNfpfJf3vEHm8xizdX/Xi50tWLjx/yVp/mgo5PIt2VcWaGM9MlSXR66/3J0s4k/83Z2GgHf530a1gTvzMe5oMAGnz/CtCidBq/0+g9/hLdmU2TADLStH3Kf7vm2qWQMfiV6C8rAadjEWzfDTNy+O/RAkgSvH6JAiT3hCH6hvDV44TdBroRAu7/3rhHXzY+z1btEf9r9BLyDocjf+gJdMkrfjFQQrwnulUFRN9K45hUCtletM1T9c4WjFtmueTX8GtiCUnylTRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fCNJ6Hu5ZLAR+0sc8aJInRzjs8MIiN3dX7lzDRJaddk=; b=TbJ0Ih4oOk4zOyEFtkiNm7GjYHy6TkI4HgmVVH9gGZmFAiNXO+wnnhJlt13Qe1u/8OLWJIhFmRKSWUJZQ8O56J+70bJfntWedjcRUCHA+3A+AQCA62sha6z3U1M7s37JCF4F3jJBYc5LgkEJGaSJN4OCanOOgQG8m2uzsLjPNE2AbfZ+1LtnWJne0D//LX1iBnoxkAJTMm383TlzlrWSf+DaTddZtHDAR/Xs1jmjxTY/UxmhKUFCVHcPZKSOSPQ/CnZkMrv8jZAIxEnQ9Supohyo+sQYcUWM3RPghKLTRbWCvXEqhFfOAEJAMX/PjQT4cX/7XkmXZ2FOmLnpqNtjMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fCNJ6Hu5ZLAR+0sc8aJInRzjs8MIiN3dX7lzDRJaddk=; b=VX987zpgEillm9hKxlO054X7RFVizpa1kTg2HLgqYdV0RALzoWjnK2bawYjXCVCIADi1jR0WDUDQZSJzP2x9zzzHqr4YYkyTvgP3CxqX2O9Mx615oBvcTVxLCSuj0j3pDE+5PPgvSGs/DgHAutGftJhRbUsGBwiCvu+oQXF9E8M= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4046.namprd11.prod.outlook.com (20.179.151.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Tue, 7 Jan 2020 12:31:10 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::d1b8:3e63:ead8:10c9]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::d1b8:3e63:ead8:10c9%7]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 12:31:10 +0000 From: "Owen Friel (ofriel)" To: Ryan Sleevi CC: EMU WG , "spasm@ietf.org" Thread-Topic: [lamps] EAP/EMU recommendations for client cert validation logic Thread-Index: AdWxNKzqTmo8NKHtQwSIp+NEgFXHNACbMPUABFOaI2A= Date: Tue, 7 Jan 2020 12:31:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [64.103.40.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c7bf0ce-5d2f-418a-f4b7-08d7936d79ce x-ms-traffictypediagnostic: MN2PR11MB4046: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(366004)(346002)(396003)(51444003)(51914003)(189003)(199004)(7696005)(52536014)(5660300002)(30864003)(186003)(26005)(55016002)(86362001)(8676002)(478600001)(71200400001)(2906002)(8936002)(66574012)(316002)(66556008)(66476007)(53546011)(66946007)(6916009)(4326008)(9686003)(966005)(6506007)(66446008)(64756008)(76116006)(81166006)(81156014)(33656002)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4046; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9GQDdHmHcnJlB8hko4+hGWqbZ2TIHBnp3Ee5gZ51bGN39TA8t+T/OOGVEPB6f+B74XdhZHvgibUOm68nRSsjHRI/CKOuv6pz7/X7rppA4lyEQPpAdPmMvGVupQJID3loAC/y+KGA6hgNSDf1rehvMz/uJq0qGtn91jDGDmCs7iA1K06e82MyiKSgnbkjIC/lxVTfNXk49Rl6NYsmilVSvlM/9f0rrJlf2S0ydyPOaNRFGCm5hL2bBrlD6so/Kgh5WftjfG/J2JFuYlJZrImFlgu/361f70q5JlsctFSBebuK+BiN68h+QyjptkS4EXX/ZuMwGHJq/buFg34TsdFJIGeU5ChOmVvZ5NjBA14A7ycOwjXCYLfvVGMKpLuZocB53u4IYw9bEMX9M7mxETG6DA1SADwytzWOh4Ciw2QM3SVgzfMsRuOQCZ69dTValpJ/DqflZebAvTMCDRqQbCfW01X221ZCa1oqdFYTvbmhD/YB7A/7T3F4QdHd9jDrYOKi7H6mgD7xAcWo9YTZFaFCSFX7O9LRM3m7Ghj2g/lAYk+fm3vT47m88VyP4tO1lUgB x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB39013D4C54FEACDC8228D136DB3F0MN2PR11MB3901namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5c7bf0ce-5d2f-418a-f4b7-08d7936d79ce X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 12:31:09.6161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2p/UenXbgenYeigkvkG6P5skHwcm6tGtgluC7KgnYE1h4QyJe1fee9u55t+yuJVRzJinSmRroyntKz2LHbGqkg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4046 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [lamps] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 12:31:19 -0000 --_000_MN2PR11MB39013D4C54FEACDC8228D136DB3F0MN2PR11MB3901namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmVwbHkgUnlhbi4gU2VlIGxpbmUuDQoNCkZyb206IFJ5 YW4gU2xlZXZpIDxyeWFuLWlldGZAc2xlZXZpLmNvbT4NClNlbnQ6IDE1IERlY2VtYmVyIDIwMTkg MjM6NDMNClRvOiBPd2VuIEZyaWVsIChvZnJpZWwpIDxvZnJpZWxAY2lzY28uY29tPg0KQ2M6IEVN VSBXRyA8ZW11QGlldGYub3JnPjsgc3Bhc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbGFtcHNd IEVBUC9FTVUgcmVjb21tZW5kYXRpb25zIGZvciBjbGllbnQgY2VydCB2YWxpZGF0aW9uIGxvZ2lj DQoNCg0KDQpPbiBTdW4sIERlYyAxNSwgMjAxOSBhdCA0OjAxIFBNIE93ZW4gRnJpZWwgKG9mcmll bCkgPG9mcmllbEBjaXNjby5jb208bWFpbHRvOm9mcmllbEBjaXNjby5jb20+PiB3cm90ZToNCkhp LA0KDQpBdCBBQ01FIG1lZXRpbmcgYXQgSUVURjEwNiwgdGhlIGxhc3QgZGlzY3Vzc2lvbiBvZiB0 aGUgd2VlayB3YXMgYXJvdW5kIEVNVSBsb29raW5nIGZvciByZWNvbW1lbmRhdGlvbnMgZm9yIEVB UCBjbGllbnQvcGVlci9zdXBwbGljYW50IGNlcnQgdmVyaWZpY2F0aW9uIGxvZ2ljIHdoZW4gdGhl IGNsaWVudCBpcyB2ZXJpZnlpbmcgdGhlIGNlcnQgdGhhdCB0aGUgRUFQIHNlcnZlciBwcmVzZW50 cy4gTWludXRlcyBoZXJlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVz LTEwNi1hY21lLyAgVGhlIHJlY29tbWVuZGF0aW9uIHdhcyB0byBhc2sgbGFtcHMuIFRoaXMgd2Fz IGFsc28gZGlzY3Vzc2VkIG9uIEVNVSBtYWlsZXIgcmVjZW50bHkuDQoNClF1b3Rpbmcgc29tZSBh ZGRpdGlvbmFsIGJhY2tncm91bmQgdGhhdCBBbGFuIGdhdmUgb24gRU1VIG1haWxlcjoNCg0KDQri gJxCYWNrZ3JvdW5kOg0KDQoNCg0KYSkgdGhlIGN1cnJlbnQgcHJhY3RpY2UgaW4gVExTLWJhc2Vk IEVBUCBtZXRob2RzIGlzIHRvIHVzZSBjZXJ0aWZpY2F0ZXMgd2l0aCAiaWQta3Atc2VydmVyQXV0 aCIgT0lEIHNldCBmb3IgRXh0ZW5kZWQgS2V5IFVzYWdlLg0KDQpiKSBtYW55IHN1cHBsaWNhbnRz IGNoZWNrIGZvciB0aGlzIE9JRCwgYW5kIHJlZnVzZSB0byBwZXJmb3JtIGF1dGhlbnRpY2F0aW9u IGlmIGl0IGlzIG1pc3NpbmcNCg0KYykgc3VwcGxpY2FudHMgZG8gbm90IGNoZWNrIEROUyBuYW1l cyBvciBhbnkgb3RoZXIgZmllbGQgaW4gdGhlIGNlcnRpZmljYXRlcw0KDQpkKSBhcyBhIHJlc3Vs dCBvZiB0aGlzIGxhY2sgb2YgdmVyaWZpY2F0aW9uLCBzdXBwbGljYW50cyBzaGlwIHdpdGggYWxs IGtub3duIENBcyBkaXNhYmxlZCBmb3IgVExTLWJhc2VkIEVBUCBtZXRob2Rz4oCdDQoNClRoZSBr ZXkgY29uc2lkZXJhdGlvbiBpcyB0aGF0IFJGQ3MgdGhhdCByZWNvbW1lbmQgY2VydCBmaWVsZHMg Zm9yIEVBUCBzZXJ2ZXJzIHRoYXQgY2xpZW50cyBzaG91bGQgY2hlY2sgZm9yIGFyZSBub3QgY3Vy cmVudGx5IGlzc3VlZCBieSBwdWJsaWMgQ0FzLCBhbmQgaW4gc29tZSBpbnN0YW5jZXMgKGUuZy4g U1NJRCkgb3duZXJzaGlwIGNhbiBvZnRlbiBub3QgYmUgcHJvdmVuIGJ5IENBcy4NCg0KRm9yIGV4 YW1wbGU6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MzM0I3NlY3Rpb24tMiBp ZC1rcC1lYXBPdmVyTEFOIEVLVQ0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDMz NCNzZWN0aW9uLTMgaWQtcGUtd2xhblNTSUQNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc1ODUjc2VjdGlvbi0yLjIgTkFJUmVhbG0NCg0KSWYgYW4gRUFQIHNlcnZlciBvcGVyYXRv ciB3YW50cyB0byB1c2UgYSBwdWJsaWMgQ0EgaWRlbnRpdHkgY2VydCBvbiB0aGVpciBFQVAgc2Vy dmVyLCB3aGF0IHJlY29tbWVuZGF0aW9ucyBzaG91bGQgd2UgZ2l2ZSB0byBFQVAgY2xpZW50cyBz byB0aGF0IHRoZSBzdXBwbGljYW50IGNvZGUgY2FuIGhhbmRsZSBwdWJsaWMgb3IgcHJpdmF0ZSBD QSBpc3N1ZWQgRUFQIHNlcnZlciBpZGVudGl0eSBpbiBhIHNlY3VyZSBhIGZhc2hpb24gYXMgcG9z c2libGU/DQoNCkRlZmluZSDigJxwdWJsaWMgQ0HigJ0gZmlyc3QsIGFuZCBpdOKAmWxsIGJlIGNs ZWFyZXIgdGhhdCB0aGUgcXVlc3Rpb24gaXMgcmVhbGx5IHN1cHBsaWNhbnQtc3BlY2lmaWMuDQoN ClRoYXQgaXMsIG1vc3QgZGVmaW5pdGlvbnMgZm9yIOKAnHB1YmxpYyBDQXPigJ0gY29tZSBkb3du IHRvIOKAnEkgZG9u4oCZdCB3YW50IHRvIHRoaW5rIGFib3V0IC8gYW5hbHl6ZSB0aGUgc2VjdXJp dHkgb3IgdmFsaWRhdGlvbiBwcmFjdGljZXMgb2YgdGhlIENBLCBJIHdhbnQgbXkgc3VwcGxpY2Fu dCAvIHNvZnR3YXJlIC8gaGFyZHdhcmUgdmVuZG9yIHRvIGRvIGl0IGZvciBtZSwgYWdhaW5zdCBz b21lIGNyaXRlcmlhIHRoZSB2ZW5kb3IgaXMgcmVzcG9uc2libGUgZm9yLCBhbmQgaG9wZSBpdCBh bGwgd29ya3Mgb3V04oCdLiBUbyB0aGUgZXh0ZW50IFRMUyB1c2VzIOKAmHB1YmxpYyBDQXPigJks IGl0IGVpdGhlciBib2lscyBkb3duIHRvIHRoZSBPUyBvciBicm93c2VyIHZlbmRvcnMgcmVhY2hp bmcgcm91Z2ggKGluZGVwZW5kZW50KSBjb25zZW5zdXMgb24gd2hvIGlzIHdvcnRoIHRydXN0aW5n LCBvciB0aGUgdmVuZG9yIGdvaW5nIGFsb25nIHdpdGggZXZlcnlvbmUgZWxzZeKAmXMgZGVjaXNp b25zIGZvciBjb3N0ICh0b28gZXhwZW5zaXZlIGZvciB0aGUgdmVuZG9yIHRvIGV2YWx1YXRlKSBv ciBjb21wYXRpYmlsaXR5IChldmVyeW9uZSBlbHNlIHRydXN0cyB0aGVtIGFuZCBpdOKAmWQgYnJl YWsgdGhpbmdzIGlmIHRoZSB2ZW5kb3IgZG9lc27igJl0KSByZWFzb25zLg0KDQpbb2ZyaWVsXSBU aGF04oCZcyBwcmV0dHkgbXVjaCBpdC4gRm9yIHN1cHBsaWNhbnRzIHJ1bm5pbmcgb24gc3RhbmRh cmQgT1NlcyAoV2luZG93cywgTWFjT1MsIGlPUywgQW5kcm9pZCksIHRoZXkgY291bGQgdXNlIGxv Z2ljIHNpbWlsYXIgdG8gQ2hyb21pdW0gKHdoaWNoIHlvdSBtdXN0IGJlIGZhbWlsaWFyIHdpdGgg c2VlaW5nIGFzIHlvdSBoZWxwZWQgd3JpdGUgaXQ6IGh0dHBzOi8vZ2l0aHViLmNvbS9jaHJvbWl1 bS9jaHJvbWl1bS9jb21taXQvMzZmMjBlNDY1MTVhYjYxZGY0YWU0YWY5NjU1YjY0N2JmOWEwZWE1 YSNkaWZmLWZhNDU1YjZlNjVhYjJhZTE5ZDY0NjM1YWRhODgwNzdlICkgdG8gYXNrIHRoZSBPUyBp ZiBhIHByZXNlbnRlZCBFQVAgY2VydCBpcyBvbmUgaXNzdWVkIGJ5IGEgcHVibGljIENBLiBUaGlz IGRvZXMgbWVhbiB0aGF0IHRoZSBzdXBwbGljYW50IGlzIGFza2luZyBhYm91dCBXZWIgVExTIGNl cnRzIHRoYXQgQnJvd3NlcnMgdHJ1c3QuIEhvd2V2ZXIsIHRoZXJlIGFyZSBhbXBsZSBleGFtcGxl cyBhbmQgc3VwcG9ydCBjYXNlcyBvcGVuZWQgYnkgb3BlcmF0b3JzIHdobyBhcmUgdHJ5aW5nIHRv IGRvIGV4YWN0bHkgdGhhdCDigJMgZ2V0IGEgd2ViIFBLSSBjZXJ0IGZyb20gYSBwdWJsaWMgVExT L0Jyb3dzZXIgQ0EgYW5kIGRlcGxveSBpdCBvbiBhbiBFQVAgc2VydmVyLiBJcyB0aGlzIHJlY29t bWVuZGVkPyBOb3QgcmVhbGx5LiBJcyBpdCB1c2luZyBhIFdlYi9UTFMgY2VydCBmb3IgYSBwdXJw b3NlIGl0cyBub3Qgc3RyaWN0bHkgaW50ZW5kZWQgZm9yPyBZZXMuIERvZXMgdGhpcyBoYXBwZW4g aW4gcmVhbCBkZXBsb3ltZW50cz8gQWJzb2x1dGVseS4gSG93IHByZXZhbGVudCBpcyBpdD8gSSBk byBub3QgaGF2ZSB0aGF0IGRhdGEuDQoNCklzIHRoZSBzdXBwbGljYW50IG1hcmtldCBsaWtlbHkg dG8gcmVhY2ggdGhhdCBjb25zZW5zdXM/IEl0IHNlZW1zIHVubGlrZWx5LCB1bmxlc3MgYW5kIHVu dGlsIHlvdSBkZWZpbmUgdGhlIOKAnHRoaW5nIGV2ZXJ5b25lIGNhbiBhbmQgd2FudHMgYW5kIG5l ZWRzIHRvIHZhbGlkYXRl4oCdLCBhbmQgdGhhdCB0aGluZyBpcyBlaXRoZXIgZ2xvYmFsbHkgdW5p cXVlIChsaWtlIEROUykgb3Igc3VmZmljaWVudGx5IGRvbWFpbiBzcGVjaWZpYyAoZS5nLiBQYXNz cG9pbnQpIHRoYXQgdmVuZG9ycyBjYW4gYWdyZWUuDQoNCltvZnJpZWxdIEkgdGhpbmsgdGhlIHN1 cHBsaWNhbnRzIHJ1bm5pbmcgb24gdGhlIG1haW4gT1NlcyB3b3VsZCBiZSBoYXBweSB0byBkZWxl Z2F0ZSB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBhIENBIGlzIGEg4oCYcHVibGljIENB4oCZIHRv IHRoZSBPUy4gRm9yIG1hbnVmYWN0dXJlcnMgb2YgdGhpbmdzL2VtYmVkZGVkIGRldmljZXMvZXRj LiB0aGVuIGl0cyBjdXJyZW50bHkgdmVyeSBtdWNoIGF0IHRoZSBtYW51ZmFjdHVyZXJzIGRpc2Ny ZXRpb24sIGFuZCBjb25zZW5zdXMgaGVyZSB3b3VsZCBiZSB1bmxpa2VseS4NCg0KSWYgYXQgc29t ZSBwb2ludCBpbiB0aGUgZnV0dXJlLCBwdWJsaWMgQ0FzIGFyZSB3aWxsaW5nIHRvIGlzc3VlIGNl cnRzIHdpdGggc29tZSBvciBhbGwgb2YgdGhlIGFib3ZlIGZpZWxkcywgdGhlbiB3aGF0IGlzIHRo ZSBtaWdyYXRpb24gcGxhbiwgd2hhdCBkbyB3ZSB0ZWxsIEVBUCBjbGllbnRzIHRvIGRvIG5vdywg YW5kIGhvdyB0byB0aGV5IG1pZ3JhdGUgdGhlaXIgdmVyaWZpY2F0aW9uIGxvZ2ljPw0KDQpUaGlz IHN0YXRlbWVudCBzaW1pbGFybHkgcmVxdWlyZXMgdW50YW5nbGluZy4gVGhlcmUgYXJlIOKAnHB1 YmxpYyBDQXPigJ0gYXMg4oCcVGhlIHNldCBvZiBrZXlzL2NlcnRpZmljYXRlcyB1c2VkIGZvciBh dXRoZW50aWNhdGluZyBwYXJ0aWN1bGFyIHNlcnZpY2Vz4oCdIGFuZCDigJxwdWJsaWMgQ0Fz4oCd IGFzIHRoZSBzZXQgb2Ygb3JnYW5pemF0aW9ucyB0aGF0IG93bi9vcGVyYXRlIHRob3NlIGtleXMu DQoNClRoZSBjYXNlIG9mIHRoZSBmb3JtZXIgaXMgZXh0cmVtZWx5IHVubGlrZWx5LCBhcyB0aGUg aW5kdXN0cnkgaXMgYWN0aXZlbHkgbW92aW5nIGF3YXkgZnJvbSB0aGF0IGFwcHJvYWNoIHRvIFBL SSwgYnkgdHJ5aW5nIHRvIGVuc3VyZSBzZXBhcmF0ZSBrZXlzIGZvciBzZXBhcmF0ZSB1c2UgY2Fz ZXMgb3IgYXV0aGVudGljYXRpb24gcmVhbG1zLCBvZiB3aGljaCBFQVAgd291bGQgc3VyZWx5IGJl Lg0KDQpbb2ZyaWVsXSBBbmQgYnkgdGhpcyB5b3UgbWVhbiB0aGF0IGEgcm9vdCBDQSB3aWxsIGhh dmUgZS5nLiBvbmUgaW50ZXJtZWRpYXRlIHdpdGggRUtVcyBvZiBpZC1rcC1zZXJ2ZXJBdXRoL2lk LWtwLWNsaWVudEF1dGgsIGFuZCBhIGRpZmZlcmVudCBpbnRlcm1lZGlhdGUgd2l0aCBhbiBFS1Ug Zm9yIGlkLWtwLWVtYWlsUHJvdGVjdGlvbiwgcmlnaHQ/IFRoZSBsb2dpY2FsIGV4dGVuc2lvbiBo ZXJlIGZvciBFQVAgaXMgeWV0IGFub3RoZXIgaW50ZXJtZWRpYXRlIHdpdGggYW4gRUtVIGZvciBp ZC1rcC1lYXBPdmVyTEFOLg0KDQpUaGUgY2FzZSBvZiB0aGUgbGF0dGVyIGlzIGFscmVhZHkgYXZh aWxhYmxlIGZyb20gc2FpZCBvcmdhbml6YXRpb25zIGFzIHBhcnQgb2Yg4oCcbWFuYWdlZCBDQeKA nSBvciDigJxwcml2YXRlIENB4oCdIG9mZmVyaW5ncywgd2hpY2ggYXJlIG9wZXJhdGVkIGJ5IHRo YXQgcHVibGljIENBIG9yZ2FuaXphdGlvbiwgYnV0IHRoYXTigJlzIGVmZmVjdGl2ZWx5IGdyZWVu ZmllbGQgYmVjYXVzZSB5b3UgYXJlbuKAmXQgaGF2aW5nIHRvIGludGVyb3BlcmF0ZSB3aXRoIGFu eSBleHRhbnQga2V5cyBvciBjZXJ0aWZpY2F0ZSBwcm9maWxlcy4NCg0KW29mcmllbF0gUmlnaHQs IGJ1dCBmcm9tIGEgc3VwcGxpY2FudCBwZXJzcGVjdGl2ZSAob3IgaW4gZ2VuZXJhbCBmb3IgYW55 IGNsaWVudCBydW5uaW5nIG9uIGFueSBPUyBlLmcuIEJyb3dzZXIgb24gV2luZG93cyksIHRoZXJl IGlzIHplcm8gZGlmZmVyZW5jZSBiZXR3ZWVuIGFuIG9wZXJhdG9yIHdobyBkZXBsb3lzIGFuZCBy dW5zIHRoZWlyIG93biBwcml2YXRlIENBLCBvciB0YWtlcyBhIGNvbnRyYWN0IG91dCB3aXRoIGEg cHVibGljIENBIG9yZ2FuaXphdGlvbiBhbmQgZ2V0cyB0aGVtIHRvIHJ1biBhIG1hbmFnZWQvcHJp dmF0ZSBDQSBvbiB0aGVpciBiZWhhbGYuDQoNClRoZSBpZGVhbCBleHBlcmllbmNlIHdvdWxkIGJl IGFsb25nIHRoZXNlIGxpbmVzIGZvciBhIGNsaWVudCB3aXRoIHJlYWwgdXNlciBpbnRlcmFjdGlv bnM6DQotIGNsaWVudCBjb25uZWN0cyB0byBhbiBFQVAgc2VydmVyDQotIGNsaWVudCBwcm9tcHRz IHVzZXIgZm9yIHVzZXJJZCArIHJlYWxtIGFuZCBwYXNzd29yZA0KLSBjbGllbnQgdmVyaWZpZXMg c2VydmVyIGNlcnQgaGFzIGlkLWtwLWVhcE92ZXJMQU4gc2V0DQoNCldoYXQgYXNzdXJhbmNlIGlz IHRoaXMgdG8gcHJvdmlkZT8NCg0KW29mcmllbF0gVG8gYXNzdXJlIHRoYXQgdGhlIGNlcnQgaXMg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIOKAkyA4MDIuMVgvRUFQIHNlcnZlciBhdXRoLiBKdXN0 IGxpa2Ugb3RoZXIgVExTL0Jyb3dzZXIgY2xpZW50cyBjaGVja3MgZm9yIGlkLWtwLXNlcnZlckF1 dGguDQoNCi0gTkFJUmVhbG0gaW4gY2VydCBtYXRjaGVzIHVzZXLigJlzIHJlYWxtDQoNClRoaXMg b25seSB3b3JrcyBpZmYgdGhlIE5BSXMgYXJlIGdsb2JhbGx5IHVuaXF1ZSAoZS5nLiBtYXAgdG8g RE5TKSwgd2hpY2ggaW1wb3NlcyByZXF1aXJlbWVudHMgb24gTkFJcyB0aGF0IGFyZW7igJl0IHBy ZXNlbnQgaW4gUkZDIDc1NDIsIGFuZCBzZWVtaW5nbHkgaW50ZW50aW9uYWxseSwgY29tcGFyZWQg dG8gNDI4Mi4NCg0KW29mcmllbF0gQWxhbiBoYXMgY2xhcmlmaWVkIHRoaXMuDQotIHZlcmlmeSB0 aGUgY2VydCBzaWduaW5nIGNoYWluDQoNClRoZSByZWFsaXR5IHRvZGF5IGlzIHRoYXQgaWYgdGhl IHNlcnZlciBjZXJ0IGlzIGlzc3VlZCBieSBhIHB1YmxpYyBDQSwgdGhlbiBhbGwgdGhhdCBjbGll bnQgY2FuIHJlYWxseSBjaGVjayBpczoNCi0gaWQta3Atc2VydmVyQXV0aCBpcyBzZXQNCi0gZE5T TmFtZSBpbiBjZXJ0IG1hdGNoZXMgdXNlcuKAmXMgcmVhbG0NCi0gdmVyaWZ5IHRoZSBjZXJ0IHNp Z25pbmcgY2hhaW4NCg0KV2Ugd291bGQgbGlrZSB0byBkb2N1bWVudCBzb21lIHJlY29tbWVuZGF0 aW9ucyBmb3IgRUFQIGNsaWVudHMgYW5kIEVBUCBvcGVyYXRvcnMgc28gdGhhdCBwdWJsaWMgQ0Fz IGNvdWxkIGJlIHVzZWQsIGFuZCByZWNvbW1lbmQgY2hlY2tzIGZvciBwdWJsaWMgdnMuIHByaXZh dGUgQ0EgaXNzdWVkIEVBUCBzZXJ2ZXIgY2VydHMuDQoNCklmIHlvdSBtZWFuIHRoZSBzYW1lIHNl dCBvZiBDQXMgYW5kIGtleXMgdXNlZCBmb3IgVExTIGJ5IGNvbW1vbiBvcGVyYXRpbmcgc3lzdGVt cyBhbmQgYnJvd3NlcnMsIGl0IGJlYXJzIGhpZ2hsaWdodGluZyBhZ2FpbjogaW5kdXN0cnkgaXMg bW92aW5nIGF3YXkgZnJvbSB0aGF0LiBXaGljaCBpcyB0byBzYXkgdGhhdCBjb250cmFjdHMgYW5k IHJlcXVpcmVtZW50cyBmb3IgUEtJcyB1c2VkIOKAnGJ5IGRlZmF1bHTigJ0gYnkgYnJvd3NlcnMg YW5kIG9wZXJhdGluZyBzeXN0ZW1zIGFyZSBiZWluZyBleHBsaWNpdCBhYm91dCB0aGUgbmVlZCB0 byBzZWdtZW50IHB1cnBvc2UgYW5kIHVzZSBjYXNlIGFuZCBub3QgdXNlIHN1Y2ggY2VydGlmaWNh dGVzIGZvciBzdWNoIHB1cnBvc2VzLg0KDQpbb2ZyaWVsXSBJIGFncmVlIHRoYXQgaWRlYWxseSAg V2ViL1RMUyBCcm93c2VyIGNlcnRzIHNob3VsZCBub3QgcmVhbGx5IGJlIHVzZWQgYnkgb3BlcmF0 b3JzIGFzIHRoZWlyIEVBUCBzZXJ2ZXIgaWRlbnRpdHkgY2VydHMsIGhvd2V2ZXIsIHRoaXMgZG9l cyBhY3R1YWxseSBoYXBwZW4gdG9kYXkuIEluIGFuIGlkZWFsIHdvcmxkLCBpdCB3b3VsZCBiZSBn cmVhdCBpZiBzb21lIG9mIHRoZSBsYXJnZSBjb21tZXJjaWFsIChvciBmcmVlIGUuZy4gTGV0c0Vu Y3J5cHQpIHB1YmxpYyBXZWIvVExTIENBcyBoYWQgYW4gaW50ZXJtZWRpYXRlIHNpZ25pbmcgQ0Eg d2l0aCBpZC1rcC1lYXBPdmVyTEFOLiBCdXQgdG9kYXksIGFuZCBmb3IgdGhlIGZvcmVzZWVhYmxl IGZ1dHVyZSwgd2hhdCBjYW4gd2UgYWR2aXNlIHN1cHBsaWNhbnRzIHRvIGRvIGlmIHdlIGtub3cg dGhhdCBzb21lIG9wZXJhdG9ycyB3aWxsIHB1dCBXZWIvVExTIGlkZW50aXR5IGNlcnRzIGZyb20g cHVibGljIENBcyBvbiB0aGVpciBFQVAgc2VydmVycz8NCg0KQWxyZWFkeSwgVExTIGFuZCBlLW1h aWwsIHRoZSB0d28gZG9taW5hbnQgdXNlcyBvZiBQS0kgaW4gc3VjaCBzeXN0ZW1zLCBhcmUgcmVx dWlyZWQgdG8gYmUgZGlzdGluZ3Vpc2hlZCBhdCB0aGVpciBpbnRlcm1lZGlhdGUgbGV2ZWwuIEJy b3dzZXJzIGFyZSBsb29raW5nIHRvIGV4cGxpY2l0bHkgb25seSB0cnVzdCB0aGUgVExTLVdlYiBz aWRlIG9mIHRoZSBQS0ksIGFuZCBtYWtpbmcgc3VyZSB0aGF0IHRoZSBUTFMtV2ViIFBLSSBzaWRl IGlzIGhpZ2hseSBhZ2lsZS4gT3RoZXIgY2FzZXMsIHN1Y2ggYXMgcmVzdHJpY3RlZCB1c2Ugc2Vy dmVyIHRvIHNlcnZlciBQS0kgb3IgaW5kdXN0cnkgYmVzcG9rZSBjYXNlcyAoc3VjaCBhcyBmaW5h bmNpYWwgc2VydmljZXMgb3Igc3lzdGVtIG5ldHdvcmtpbmcpIGFyZSBiZWluZyByZXN0cmljdGVk IHRvIFBLSXMgdGhhdCBhcmVu4oCZdCBmZWRlcmF0ZWQtYnktZGVmYXVsdC4NCg0KRm9yIGV4YW1w bGUsIFg5IHJlY2VudGx5IHJldml2ZWQgdGhlaXIgUEtJIFdHLCB0byBkZWZpbmUgUEtJIHJlcXVp cmVtZW50cyBhcHByb3ByaWF0ZSBmb3IgZmluYW5jaWFsIHNlcnZpY2VzIGN1c3RvbWVycyAobGlr ZSBBVE0gdG8gYmFuayksIGJlY2F1c2UgZmluYW5jaWFsIHNlcnZpY2VzIHN0cnVnZ2xlIHRvIG1v dmUgYXQgdGhlIHNhbWUgc3BlZWQgYXMgbW9kZXJuIHNvZnR3YXJlLCBmb3IgdW5kZXJzdGFuZGFi bGUgcmVhc29ucy4gVGhlIHVzZSBvZiBkb21haW4vcHVycG9zZS1zcGVjaWZpYyBQS0lzIGlzIHNv bWV0aGluZyB3ZSBjYW4gYW5kIHNob3VsZCBiZSBlbWJyYWNpbmcgbW9yZSBvZi4NCg0KW29mcmll bF0gU3VyZSwgSeKAmW0gbm90IHNheWluZyB0aGF0IGlkLWtwLWVhcE92ZXJMQU4gaXMgYSBiYWQg aWRlYSBvciB0aGF0IHN1cHBsaWNhbnRzIHNob3VsZCBuZXZlciBsb29rIGZvciBpdC4gQnV0IGhv dyBkbyB3ZSBnZXQgdG8gdGhlIHBvaW50IHdoZXJlIHdlIGNvdWxkIGFjdHVhbGx5IGVuZm9yY2Ug dGhhdCwgZ2l2ZW4gdGhhdCB0b2RheSBvcGVyYXRvcnMgZG8gdHJ5IHRvIHVzZSBFQVAgd2l0aCBX ZWIvVExTIGNlcnRzLg0KDQpJdCBzZWVtcyBsaWtlIGxvZ2ljIHNob3VsZCBiZSBzb21ldGhpbmcg bGlrZToNCg0KLSByZWNvbW1lbmQgRUFQIG9wZXJhdG9ycyB3aXRoIHByaXZhdGUgQ0EgaXNzdWVk IGNlcnRzIG9uIHRoZWlyIEVBUCBzZXJ2ZXJzIHNldCBpZC1rcC1lYXBPdmVyTEFOIGFuZCBOQUlS ZWFsbSBzZXQNCi0gcmVjb21tZW5kIEVBUCBvcGVyYXRvcnMgdXNpbmcgcHVibGljIENBcyBnZXQg RUFQIHNlcnZlciBjZXJ0cyB3aXRoIGlkLWtwLXNlcnZlckF1dGggYW5kIGROU05hbWUgc2V0DQot IHJlY29tbWVuZCBjbGllbnRzIGVuYWJsZSB0cnVzdCBpbiBwdWJsaWMgQ0FzDQoNClRoaXMgaXMg d2h5IEkgc3RhcnRlZCB3aXRoIHRyeWluZyB0byBkZWZpbmUgd2hhdCDigJxwdWJsaWMgQ0Fz4oCd IGFyZS4gSWYgeW91IG1lYW4gdGhlIGV4dGFudCBDQXMgdHJ1c3RlZCBieSBicm93c2VycyBhbmQg b3BlcmF0aW5nIHN5c3RlbXMsIGJvdGggdGhpcyByZWNvbW1lbmRhdGlvbiBhbmQgdGhlIG9uZSBw cm9jZWVkaW5nIGl0IG1heSBub3QgYmUgZ29vZCByZWNvbW1lbmRhdGlvbnMgb3IgbG9uZy10ZXJt IHZpYWJsZSBwcmFjdGljZXMuDQoNCltvZnJpZWxdIFllcywgSSBtZWFuIGV4dGFudCBDQXMgdHJ1 c3RlZCBieSBCcm93c2VycyBhbmQgT1Nlcy4gWWVzIHRoZSByZWNvbW1lbmRhdGlvbnMgYXMgd3Jp dHRlbiBhYm92ZSB3b3VsZCBtZWFuIHVzaW5nIGEgY2VydCB3aXRoIGEgRUtVIGZvciBvbmUgcHVy cG9zZSwgZm9yIGEgZGlmZmVyZW50IHB1cnBvc2UsIGJ1dCB0aGF0IGlzIHRoZSB1bmZvcnR1bmF0 ZSByZWFsaXR5LiBEbyB3ZSBpZ25vcmUgdGhlIHByb2JsZW0gYW5kIHNheSDigJhEb27igJl0IGRv IHRoaXPigJkgb3IgZG8gd2UgdHJ5IHRvIGRvY3VtZW50IHNvbWUgY29tcHJvbWlzZSByZWNvbW1l bmRhdGlvbnMgZm9yIGJvdGggc3VwcGxpY2FudHMgYW5kIENBcywgd2l0aCBhIHJvYWRtYXAgb2Yg aG93IHRvIGV2b2x2ZT8NCg0KVGhhdOKAmXMgbm90IHRvIHNheSB5b3UgY291bGRu4oCZdCwgYnV0 IGl0IG1lYW5zIHlvdXIgRUFQIHNlcnZpY2VzIGFuZCBzZXJ2ZXJzIG5lZWQgdG8gYmUgcHJlcGFy ZWQgdG8gYmUgYXMgYWdpbGUgYXMgdGhlIFdlYiBlY29zeXN0ZW0gaXMgYW5kIG1vZGVybiBvcGVy YXRpbmcgc3lzdGVtcyBhcmUgY29udmVyZ2luZyBvbi4gVGhlIGFiaWxpdHkgdG8gc3VwcG9ydCBv ciBiZSBiZWhvbGRlbiB0byDigJxsZWdhY3nigJ0gLSB3aGV0aGVyIGFsZ29yaXRobXMsIHByb2Zp bGVzLCBvciB0cnVzdCBpbiBwYXJ0aWN1bGFyIG9yZ2FuaXphdGlvbnMgLSBpcyBzb21ldGhpbmcg dGhhdCBpbmR1c3RyeSBpcyByZWNvZ25pemluZyBkb2VzIG5vdCBhbGlnbiB3aXRoIHVzZXIgbmVl ZHMuIFRoaXMgbWVhbnMgYWRvcHRpbmcgcHJhY3RpY2VzIGxpa2UgYXV0b21hdGlvbiwgYmVpbmcg YWJsZSB0byBxdWFudGlmeSBjb21wYXRpYmlsaXR5IHJpc2tzLCBhbmQgYmVpbmcgYWJsZSB0byBt b3ZlIHF1aWNrbHkgYXMgZXhwZWN0YXRpb25zIGNoYW5nZSwgaW4gcmVzcG9uc2UgdG8gZWNvc3lz dGVtIGNoYWxsZW5nZXMuDQoNCltvZnJpZWxdIEkgaG9wZSB0aGF0IHRoaXMgcHJvYmxlbSBpcyBl YXNpZXIgdG8gdGFja2xlIGZvciBzdXBwbGljYW50cyBydW5uaW5nIG9uIHRoZSBtYWpvciBPU2Vz LiBGb3IgdGhpbmdzL2VtYmVkZGVkIGRldmljZXMsIHRoaXMgaXMgYSBmYXIgaGFyZGVyIHByb2Js ZW0gdG8gc29sdmUgZm9yIHN1cmUuDQoNCk1heWJlIHRoYXTigJlzIGZpbmUgZm9yIEVBUCwgYnV0 IEnigJltIHdpbGxpbmcgdG8gc3VzcGVjdCB0aGF0IGl0IGJlY2F1c2UgdXBkYXRlcyBtYXkgaW52 b2x2ZSBwaHlzaWNhbGx5IHJlcGxhY2luZyBjbGllbnQgaGFyZHdhcmUgb3IgcGh5c2ljYWxseSBp bnN0YWxsaW5nIGZpcm13YXJlLCB5b3UgcmVhbGx5IGRvbuKAmXQgd2FudCBFQVAgbmVlZGluZyB0 byBiZSBiZWhvbGRlbiB0byB0aG9zZSBhZ2lsaXR5IG5lZWRzIG9mIHRoZSBXZWIgYW5kIE9TZXMu IEFuZCwgYWdhaW4sIHRoYXTigJlzIHBlcmZlY3RseSBPSywgaXQganVzdCBtZWFucyBkZWZpbmlu ZyBhIFBLSSBhbmQgc2V0IG9mIHByb2NlZHVyZXMgdGhhdCBpcyBhcHByb3ByaWF0ZSBmb3IgdGhh dCB1c2UgY2FzZSwgYW5kIGNvbnZpbmNpbmcgaW5kdXN0cnkgdG8gYWRvcHQgaXQgYXMgYW4g4oCc b3V0IG9mIHRoZSBib3jigJ0gY29uZmlndXJhdGlvbi4gT3IsIGFsdGVybmF0aXZlbHksIGVtYnJh Y2luZyBwcml2YXRlIFBLSS4NCg0KW29mcmllbF0gTWF5YmUgYW4gYXBwcm9hY2ggdG8gdGFrZSBp cyB0byBoYXZlIG9uZSBzZXQgb2YgcmVjb21tZW5kYXRpb25zIGZvciBzdXBwbGljYW50IGNsaWVu dHMgb24gbWFqb3IgT1NlcyB3aGVyZSB0aGV5IGNhbiBkZWxlZ2F0ZSwgYW5kIHBvc3NpYmx5IHBp Z2d5IGJhY2sgb24gdG9wIG9mLCBzaW1pbGFyIE9TIGZ1bmN0aW9uYWxpdHkgZm9yIFdlYi9UTFM7 IGFuZCBoYXZlIGEgZGlmZmVyZW50IHNldCBvZiByZWNvbW1lbmRhdGlvbnMgZm9yIHRoaW5nIG1h bnVmYWN0dXJlcnMuIE9yIHBvc3NpYmx5IGZyYW1lIHRoZSByZXF1aXJlbWVudHMgYXMg4oCYcmVx dWlyZW1lbnRzIHRoZSBzdXBwbGljYW50IHNob3VsZCBlbmZvcmNl4oCZIHZzLiDigJhyZXF1aXJl bWVudHMgdGhlIHN1cHBsaWNhbnQgc2hvdWxkIGRlbGVnYXRlIHRvIHRoZSBPUyAoZS5nLiBpcyB0 aGlzIGEgcHVibGljIENBPynigJkuDQoNCi0gcmVjb21tZW5kIGNsaWVudHMgaW1wbGVtZW50IGRp ZmZlcmVudCBjZXJ0IHZlcmlmaWNhdGlvbiBsb2dpYyBkZXBlbmRpbmcgb24gd2hldGhlciB0aGUg RUFQIHNlcnZlciBjZXJ0IGlzIGlzc3VlZCBieSBhIHB1YmxpYyBDQSBvciBwcml2YXRlIENBDQoN CldoeSBpcyB0aGlzIGdvb2Q/DQoNClRvIHRoZSBleHRlbnQgYnJvd3NlcnMgb3IgT1NlcyBtYWtl IHRoaXMgZGlzdGluY3Rpb24sIGl04oCZcyBsYXJnZWx5IGJhc2VkIG9uIHNpbXBseSBwaGFzaW5n IHJvbGxvdXRzIG9mIG5ldyByZXF1aXJlbWVudHMsIHdpdGggdGhlIGdvYWwgdG8gZXZlbnR1YWxs eSByZXF1aXJlIGNvbnNpc3RlbnQgYW5kIHVuaWZvcm0gdHJlYXRtZW50IHRvIGVuc3VyZSBzaW1w bGVyIGNvZGUgd2l0aCBjb25zaXN0ZW50IGFuZCB1bmlmb3JtIHNlY3VyaXR5IHByb3BlcnRpZXMu IEhhdmluZyBhIGxvbmctdGVybSBzZWdtZW50YXRpb24gb2YgcmVxdWlyZW1lbnRzLCBvciBldmVu IGVuY291cmFnaW5nIHRoZW0gd2l0aG91dCBhIGNsZWFyIHZpc2lvbiBiYWNrIHRvIGhhcm1vbml6 YXRpb24sIGlzIGRlZmluaXRlbHkgYW4gYW50aS1wYXR0ZXJuIGhlcmUuDQpbb2ZyaWVsXSBDb21w bGV0ZWx5IGFncmVlLiBXaGljaCBpcyB3aHkgSSBzdGF0ZWQgYmVsb3cg4oCcYXMgYSBsb25nZXIg dGVybSBnb2FsIHNlZSBpZiBwdWJsaWMgQ0FzIHdpbGwgaXNzdWUgaWQta3AtZWFwT3ZlckxBTiBh bmQgTkFJUmVhbG3igJ0NCg0KLSBmb3IgcHVibGljIENBIGNlcnRzLCBjbGllbnQgY2hlY2tzIHRo YXQgaWQta3Atc2VydmVyQXV0aCBpcyBzZXQgKmFuZCogZE5TTmFtZSBtYXRjaGVzIHVzZXIgcmVh bG0uIElmIGVpdGhlciBjaGVjayBmYWlscywgcmVqZWN0Lg0KLSBmb3IgcHJpdmF0ZSBDQSBjZXJ0 cywgY2xpZW50IGNoZWNrcyB0aGF0IGlkLWtwLXNlcnZlckF1dGggb3IgaWQta3AtZWFwT3ZlckxB TiBpcyBzZXQgKmFuZCogTkFJUmVhbG0gbWF0Y2hlcyB1c2VyIHJlYWxtLi4gSWYgZWl0aGVyIGNo ZWNrIGZhaWxzLCByZWplY3QuDQoNCi0gYXMgYSBsb25nZXIgdGVybSBnb2FsIHNlZSBpZiBwdWJs aWMgQ0FzIHdpbGwgaXNzdWUgaWQta3AtZWFwT3ZlckxBTiBhbmQgTkFJUmVhbG0uIEFsdGhvdWdo IG9mIGNvdXJzZSBpZiBzb21lIHdlcmUgdG8gc3RhcnQgZG9pbmcgdGhpcywgdGhlbiB0aGVyZSBp cyBhIG1pZ3JhdGlvbiBjaGFsbGVuZ2UsIGFuZCBjbGllbnRzIGNhbm5vdCBtYWtlIGEgaGFyZCBj aGVjayBmb3IgdGhlc2UgdmFsdWVzIGFnYWluc3QgYWxsIHB1YmxpYyBDQXMuIFRoaXMgZG9lc27i gJl0IHJlYWxseSBzZWVtIHByYWN0aWNhbCBpbiB0aGUgbmVhciB0ZXJtIGF0IGFsbC4NCg0KVGhl IGVmZmVjdCBvZiB0aGUgc2VwYXJhdGUgRUtVLCB3aGljaCBpcyBhY3R1YWxseSBxdWl0ZSBkZXNp cmFibGUsIGlzIHRoYXQgaXQgZnVuY3Rpb25hbGx5IG1ha2VzIGl0IGRpZmZpY3VsdCBmb3IgQ0Fz IHRvIGlzc3VlIHRoZXNlIGNlcnRpZmljYXRlcyBmcm9tIGludGVybWVkaWF0ZWQgdGhhdCBsYWNr IHRoaXMgRUtVIG9yIGFueSBFS1UuIEZ1cnRoZXIsICBDQXMgc3ViamVjdCB0byBicm93c2VyL09T IHZlbmRvciBvdmVyc2lnaHQgYXJlIGNvbnNpc3RlbnRseSByZXF1aXJlZCB0byBzZWdtZW50IG91 dCB0aGVpciBFS1VzIGF0IHRoZSBpbnRlcm1lZGlhdGUgbGV2ZWwsIGFuZCByZXF1aXJlZCB0byBh bHdheXMgc3BlY2lmeSBFS1VzLg0KDQpUaGUgZW5kIHJlc3VsdCBpcyB0aGF0LCB0byBhY2hpZXZl IHRoaXMgbG9uZyB0ZXJtIGdvYWwsIHlvdeKAmXZlIGVmZmVjdGl2ZWx5IHJlcXVpcmVkIHRoZSBl c3RhYmxpc2htZW50IG9mIGEgbmV3IFBLSSAtIGp1c3QgYXQgdGhlIGludGVybWVkaWF0ZSBsZXZl bCByYXRoZXIgdGhhbiB0aGUgcm9vdC4gQW5kIGFzIG1hbnkgb2YgdGhlIHB1YmxpYyBDQXMgY2Fu IHRlbGwgeW91LCBoYXZpbmcgcmVjZW50bHkgZW5jb3VudGVyZWQgY2hhbGxlbmdlcyByZWdhcmRp bmcgbm9uLVRMUyBpbnRlcm1lZGlhdGVzIGZyb20gcm9vdHMgdGhhdCBhcmUgc3ViamVjdCB0byBi cm93c2VyL09TIG92ZXJzaWdodCwgaXTigJlzIG9mdGVuIGVhc2llciB0byB1c2Ugc2VwYXJhdGUg cm9vdHMgYXMgd2VsbC4NCg0KQWdhaW4sIEkgdGhpbmsgdGhhdOKAmXMgZGVzaXJhYmxlLCB0byBk ZWZpbmUgYW4gZW50aXJlbHkgbmV3IFBLSSB3aXRoIHplcm8gb3ZlcmxhcCB3aXRoIHRoZSBzZXJ2 ZXIgYXV0aC9UTFMgUEtJIHVzZWQgYnkgT1Nlcy9icm93c2VycywgYnV0IHRoYXQgZG9lcyBjaGFu Z2UgeW91ciByZWNvbW1lbmRhdGlvbnMgYW5kIGRlc2lnbiBhIGJpdCA6KSBUaGUgc2hvcnQgdGVy bSByZWNvbW1lbmRhdGlvbiBiZWNvbWVzIOKAnGRvbuKAmXQgdXNlIHB1YmxpYyBDQXPigJ0sIGFu ZCB0aGF0IHNlZW1zIGVhc2llciB0byBleHBsYWluIGFuZCBlYXNpZXIgdG8gZXZvbHZlIHRoZSB0 ZWNobmljYWwgcmVxdWlyZW1lbnRzLCB1bnRpbCB0aGUgdGltZSB0aGF0IHN1Y2ggYSBuZXcsIEVB UC1zcGVjaWZpYyBwdWJsaWMgUEtJIGNhbiBiZSBpbnRyb2R1Y2VkLg0KDQpbb2ZyaWVsXSBHZXR0 aW5nIHB1YmxpYyBDQXMgdG8gbWFuYWdlIGEgbmV3IFBLSSByb290IChpZiB0aGF04oCZcyBlYXNp ZXIgdGhhbiBqdXN0IGEgbmV3IGludGVybWVkaWF0ZSkgd2l0aCBpZC1rcC1lYXBPdmVyTEFOIGlz IGEgcmVhbGx5IHJlYWxseSBsb25nIHJvYWQuIEFuZCB3ZSBrbm93IHRoYXQgc29tZSBvcGVyYXRv cnMgZG8gdXNlIHB1YmxpYyBXZWIvVExTIGNlcnRzIGFzIEVBUCBpZGVudGl0eSBjZXJ0cy4gV2hp Y2ggbWVhbnMgdGhhdCB3ZSBjYW5ub3QgcmVjb21tZW5kIHN1cHBsaWNhbnRzIGVuZm9yY2UgYSBj aGVjayBmb3IgaWQta3AtZWFwT3ZlckxBTi4NCg0KU28gaXQgbG9va3MgbGlrZSB0aGVyZSBhcmUg dGhyZWUgY2hvaWNlczoNCg0KICAxLiAgQ29tcGxldGVseSBpZ25vcmUgaWQta3AtZWFwT3ZlckxB TiBmb3IgZXZlci4NCiAgMi4gIEdldCBzdXBwbGljYW50cyB0byBjaGVjayBpZC1rcC1lYXBPdmVy TEFOIGlmIGl0cyBub3QgYSBwdWJsaWMgQ0EgKGFuZCB1c2UgQ2hyb21pdW0gc3R5bGUgcHVibGlj IENBIGRldGVjdGlvbikuIFJvbGxvdXQgb2YgdGhpcyB3b3VsZCBuZWVkIHRvIGJlIGNhcmVmdWxs eSBtYW5hZ2VkIHRvbyBzbyB0aGF0IGV4aXN0aW5nIHByaXZhdGUgQ0Egb3BlcmF0b3JzIHdobyBk byBub3Qgc2V0IGlkLWtwLWVhcE92ZXJMQU4gZG8gbm90IGJyZWFrLg0KICAzLiAgRG8gbm90aGlu ZyB1bnRpbCAgc3VmZmljaWVudCBudW1iZXJzIG9mIHB1YmxpYyBDQXMgc3VwcG9ydCBpZC1rcC1l YXBPdmVyTEFOIChpbiBsaWtlIDIwMzUuLj8pLCB0aGVuIGNoYW5nZSBzdXBwbGljYW50cyB0byBh bHdheXMgY2hlY2sgZm9yIGlkLWtwLWVhcE92ZXJMQU4uDQoNCkl0cyBub3QgY2xlYXIgdG8gbWUg d2hlcmUgdGhlIGNvcnJlY3QgZm9ydW0gaXMgdG8gZXZlbiBkb2N1bWVudCB0aGVzZSByZWNvbW1l bmRhdGlvbnMsIG9yIHdobyBuZWVkcyB0byBiZSBpbnZvbHZlZC4NCg0KSW4gbXkgbWluZCwgdGhp cyBpcyBubyBkaWZmZXJlbnQgZnJvbSBvcmdhbml6YXRpb25zIHRoYXQgd2FudCBUTFMgY2VydGlm aWNhdGVzIGZvciB0aGVpciBzZXJ2ZXJzIG5hbWVkIOKAnHdlYm1haWzigJ0gKG5vdCBnbG9iYWxs eSB1bmlxdWUpIG9yIOKAnG1haWxfMDEuY29tcGFueS5leGFtcGxl4oCdIChub3QgcHJlZmVycmVk IG5hbWUgZm9ybSAvIExESCkuIFRoZSBhbnN3ZXIgaXMg4oCcdXNlIHByaXZhdGUgQ0FzLCBkb27i gJl0IHVzZSBwdWJsaWMgQ0Fz4oCdDQoNCg0KTm90ZSB0aGF0IGZvciBhbiBJb1QgZGV2aWNlLCB0 aGVyZSBpcyBzb21lIHdvcmsgdG8gZG8gdG8gZGVmaW5lIGhvdyB0byBlLmcuIGV4dGVuZCB0aGUg UkZDODM2NiBzbyB0aGF0IGl0IGNhbiBzcGVjaWZ5IHRoZSBkTlNOYW1lIHRoYXQgZGV2aWNlcyBz aG91bGQgY2hlY2sgZm9yIHdoZW4gdmVyaWZ5aW5nIEVBUCBpZGVudGl0eSB3aGVyZSB0aGV5IEVB UCBzZXJ2ZXIgdXNlcyBhIHB1YmxpYyBDQS4gU29tZSByZWxhdGVkIG9wdGlvbnMgYXJlIG91dGxp bmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mcmllbC1hbmltYS1icnNr aS1jbG91ZC0wMS4NCg0KQ29tbWVudHMvdGhvdWdodHM/DQoNClJlZ2FyZHMsDQpPd2VuDQoNCg0K DQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClNwYXNtIG1haWxpbmcgbGlzdA0KU3Bhc21AaWV0Zi5vcmc8bWFpbHRvOlNwYXNtQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbQ0K --_000_MN2PR11MB39013D4C54FEACDC8228D136DB3F0MN2PR11MB3901namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoyODU1NTAzMjI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzAyNzAxNDAwIDIwMTIxMTI4ODggMTM0ODA3NTU1IDEz NDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1 IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTQ3NTk0NjQyNDsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODUyNTQ5MDcyIC0xNDAzNTA3 NDE0IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0 ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgZm9yIHRoZSBkZXRhaWxlZCByZXBseSBSeWFuLiBT ZWUgbGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBSeWFuIFNsZWV2aSAmbHQ7cnlhbi1pZXRmQHNsZWV2aS5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50 OjwvYj4gMTUgRGVjZW1iZXIgMjAxOSAyMzo0Mzxicj4NCjxiPlRvOjwvYj4gT3dlbiBGcmllbCAo b2ZyaWVsKSAmbHQ7b2ZyaWVsQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEVNVSBXRyAm bHQ7ZW11QGlldGYub3JnJmd0Ozsgc3Bhc21AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtsYW1wc10gRUFQL0VNVSByZWNvbW1lbmRhdGlvbnMgZm9yIGNsaWVudCBjZXJ0IHZhbGlk YXRpb24gbG9naWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBTdW4sIERl YyAxNSwgMjAxOSBhdCA0OjAxIFBNIE93ZW4gRnJpZWwgKG9mcmllbCkgJmx0OzxhIGhyZWY9Im1h aWx0bzpvZnJpZWxAY2lzY28uY29tIj5vZnJpZWxAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KSGksPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpBdCBB Q01FIG1lZXRpbmcgYXQgSUVURjEwNiwgdGhlIGxhc3QgZGlzY3Vzc2lvbiBvZiB0aGUgd2VlayB3 YXMgYXJvdW5kIEVNVSBsb29raW5nIGZvciByZWNvbW1lbmRhdGlvbnMgZm9yIEVBUCBjbGllbnQv cGVlci9zdXBwbGljYW50IGNlcnQgdmVyaWZpY2F0aW9uIGxvZ2ljIHdoZW4gdGhlIGNsaWVudCBp cyB2ZXJpZnlpbmcgdGhlIGNlcnQgdGhhdCB0aGUgRUFQIHNlcnZlciBwcmVzZW50cy4gTWludXRl cyBoZXJlOg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRl cy0xMDYtYWNtZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9taW51dGVzLTEwNi1hY21lLzwvYT4mbmJzcDsgVGhlIHJlY29tbWVuZGF0aW9uIHdhcyB0 byBhc2sgbGFtcHMuIFRoaXMgd2FzIGFsc28gZGlzY3Vzc2VkIG9uIEVNVSBtYWlsZXIgcmVjZW50 bHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM2LjBwdCI+DQpRdW90aW5nIHNvbWUgYWRkaXRpb25hbCBiYWNrZ3JvdW5kIHRoYXQg QWxhbiBnYXZlIG9uIEVNVSBtYWlsZXI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+4oCcQmFja2dyb3VuZDo8bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+YSkgdGhlIGN1cnJlbnQgcHJhY3RpY2UgaW4gVExTLWJh c2VkIEVBUCBtZXRob2RzIGlzIHRvIHVzZSBjZXJ0aWZpY2F0ZXMgd2l0aCAmcXVvdDtpZC1rcC1z ZXJ2ZXJBdXRoJnF1b3Q7IE9JRCBzZXQgZm9yIEV4dGVuZGVkIEtleSBVc2FnZS48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmIpIG1hbnkgc3VwcGxpY2FudHMg Y2hlY2sgZm9yIHRoaXMgT0lELCBhbmQgcmVmdXNlIHRvIHBlcmZvcm0gYXV0aGVudGljYXRpb24g aWYgaXQgaXMgbWlzc2luZzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Yykgc3VwcGxpY2FudHMgZG8gbm90IGNoZWNrIEROUyBuYW1lcyBvciBhbnkgb3RoZXIg ZmllbGQgaW4gdGhlIGNlcnRpZmljYXRlczxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+ZCkgYXMgYSByZXN1bHQgb2YgdGhpcyBsYWNrIG9mIHZlcmlmaWNhdGlv biwgc3VwcGxpY2FudHMgc2hpcCB3aXRoIGFsbCBrbm93biBDQXMgZGlzYWJsZWQgZm9yIFRMUy1i YXNlZCBFQVAgbWV0aG9kc+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhlIGtleSBjb25zaWRlcmF0aW9uIGlz IHRoYXQgUkZDcyB0aGF0IHJlY29tbWVuZCBjZXJ0IGZpZWxkcyBmb3IgRUFQIHNlcnZlcnMgdGhh dCBjbGllbnRzIHNob3VsZCBjaGVjayBmb3IgYXJlIG5vdCBjdXJyZW50bHkgaXNzdWVkIGJ5IHB1 YmxpYyBDQXMsIGFuZCBpbiBzb21lIGluc3RhbmNlcyAoZS5nLiBTU0lEKSBvd25lcnNoaXAgY2Fu IG9mdGVuIG5vdCBiZSBwcm92ZW4gYnkgQ0FzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KRm9yIGV4YW1wbGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDMzNCNz ZWN0aW9uLTIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NDMzNCNzZWN0aW9uLTI8L2E+IGlkLWtwLWVhcE92ZXJMQU4gRUtVPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDMzNCNzZWN0aW9uLTMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDMzNCNzZWN0aW9uLTM8 L2E+IGlkLXBlLXdsYW5TU0lEPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzU4NSNzZWN0aW9uLTIuMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTg1I3NlY3Rpb24tMi4yPC9hPiBOQUlSZWFsbTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KSWYgYW4gRUFQIHNlcnZlciBvcGVyYXRvciB3YW50cyB0byB1c2UgYSBwdWJsaWMg Q0EgaWRlbnRpdHkgY2VydCBvbiB0aGVpciBFQVAgc2VydmVyLCB3aGF0IHJlY29tbWVuZGF0aW9u cyBzaG91bGQgd2UgZ2l2ZSB0byBFQVAgY2xpZW50cyBzbyB0aGF0IHRoZSBzdXBwbGljYW50IGNv ZGUgY2FuIGhhbmRsZSBwdWJsaWMgb3IgcHJpdmF0ZSBDQSBpc3N1ZWQgRUFQIHNlcnZlciBpZGVu dGl0eSBpbiBhIHNlY3VyZSBhIGZhc2hpb24gYXMgcG9zc2libGU/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ RGVmaW5lIOKAnHB1YmxpYyBDQeKAnSBmaXJzdCwgYW5kIGl04oCZbGwgYmUgY2xlYXJlciB0aGF0 IHRoZSBxdWVzdGlvbiBpcyByZWFsbHkgc3VwcGxpY2FudC1zcGVjaWZpYy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhdCBpcywgbW9zdCBkZWZp bml0aW9ucyBmb3Ig4oCccHVibGljIENBc+KAnSBjb21lIGRvd24gdG8g4oCcSSBkb27igJl0IHdh bnQgdG8gdGhpbmsgYWJvdXQgLyBhbmFseXplIHRoZSBzZWN1cml0eSBvciB2YWxpZGF0aW9uIHBy YWN0aWNlcyBvZiB0aGUgQ0EsIEkgd2FudCBteSBzdXBwbGljYW50IC8gc29mdHdhcmUgLyBoYXJk d2FyZSB2ZW5kb3IgdG8gZG8gaXQgZm9yIG1lLA0KIGFnYWluc3Qgc29tZSBjcml0ZXJpYSB0aGUg dmVuZG9yIGlzIHJlc3BvbnNpYmxlIGZvciwgYW5kIGhvcGUgaXQgYWxsIHdvcmtzIG91dOKAnS4g VG8gdGhlIGV4dGVudCBUTFMgdXNlcyDigJhwdWJsaWMgQ0Fz4oCZLCBpdCBlaXRoZXIgYm9pbHMg ZG93biB0byB0aGUgT1Mgb3IgYnJvd3NlciB2ZW5kb3JzIHJlYWNoaW5nIHJvdWdoIChpbmRlcGVu ZGVudCkgY29uc2Vuc3VzIG9uIHdobyBpcyB3b3J0aCB0cnVzdGluZywgb3IgdGhlIHZlbmRvciBn b2luZyBhbG9uZw0KIHdpdGggZXZlcnlvbmUgZWxzZeKAmXMgZGVjaXNpb25zIGZvciBjb3N0ICh0 b28gZXhwZW5zaXZlIGZvciB0aGUgdmVuZG9yIHRvIGV2YWx1YXRlKSBvciBjb21wYXRpYmlsaXR5 IChldmVyeW9uZSBlbHNlIHRydXN0cyB0aGVtIGFuZCBpdOKAmWQgYnJlYWsgdGhpbmdzIGlmIHRo ZSB2ZW5kb3IgZG9lc27igJl0KSByZWFzb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bb2Zy aWVsXSBUaGF04oCZcyBwcmV0dHkgbXVjaCBpdC4gRm9yIHN1cHBsaWNhbnRzIHJ1bm5pbmcgb24g c3RhbmRhcmQgT1NlcyAoV2luZG93cywgTWFjT1MsIGlPUywgQW5kcm9pZCksIHRoZXkgY291bGQg dXNlIGxvZ2ljIHNpbWlsYXIgdG8gQ2hyb21pdW0gKHdoaWNoIHlvdSBtdXN0IGJlIGZhbWlsaWFy IHdpdGggc2VlaW5nIGFzIHlvdSBoZWxwZWQgd3JpdGUgaXQ6DQo8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vY2hyb21pdW0vY2hyb21pdW0vY29tbWl0LzM2ZjIwZTQ2NTE1YWI2MWRmNGFlNGFm OTY1NWI2NDdiZjlhMGVhNWEjZGlmZi1mYTQ1NWI2ZTY1YWIyYWUxOWQ2NDYzNWFkYTg4MDc3ZSI+ DQpodHRwczovL2dpdGh1Yi5jb20vY2hyb21pdW0vY2hyb21pdW0vY29tbWl0LzM2ZjIwZTQ2NTE1 YWI2MWRmNGFlNGFmOTY1NWI2NDdiZjlhMGVhNWEjZGlmZi1mYTQ1NWI2ZTY1YWIyYWUxOWQ2NDYz NWFkYTg4MDc3ZTwvYT4gKSB0byBhc2sgdGhlIE9TIGlmIGEgcHJlc2VudGVkIEVBUCBjZXJ0IGlz IG9uZSBpc3N1ZWQgYnkgYSBwdWJsaWMgQ0EuIFRoaXMgZG9lcyBtZWFuIHRoYXQgdGhlIHN1cHBs aWNhbnQgaXMgYXNraW5nIGFib3V0IFdlYiBUTFMgY2VydHMNCiB0aGF0IEJyb3dzZXJzIHRydXN0 LiBIb3dldmVyLCB0aGVyZSBhcmUgYW1wbGUgZXhhbXBsZXMgYW5kIHN1cHBvcnQgY2FzZXMgb3Bl bmVkIGJ5IG9wZXJhdG9ycyB3aG8gYXJlIHRyeWluZyB0byBkbyBleGFjdGx5IHRoYXQg4oCTIGdl dCBhIHdlYiBQS0kgY2VydCBmcm9tIGEgcHVibGljIFRMUy9Ccm93c2VyIENBIGFuZCBkZXBsb3kg aXQgb24gYW4gRUFQIHNlcnZlci4gSXMgdGhpcyByZWNvbW1lbmRlZD8gTm90IHJlYWxseS4gSXMg aXQgdXNpbmcgYQ0KIFdlYi9UTFMgY2VydCBmb3IgYSBwdXJwb3NlIGl0cyBub3Qgc3RyaWN0bHkg aW50ZW5kZWQgZm9yPyBZZXMuIERvZXMgdGhpcyBoYXBwZW4gaW4gcmVhbCBkZXBsb3ltZW50cz8g QWJzb2x1dGVseS4gSG93IHByZXZhbGVudCBpcyBpdD8gSSBkbyBub3QgaGF2ZSB0aGF0IGRhdGEu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPklzIHRo ZSBzdXBwbGljYW50IG1hcmtldCBsaWtlbHkgdG8gcmVhY2ggdGhhdCBjb25zZW5zdXM/IEl0IHNl ZW1zIHVubGlrZWx5LCB1bmxlc3MgYW5kIHVudGlsIHlvdSBkZWZpbmUgdGhlIOKAnHRoaW5nIGV2 ZXJ5b25lIGNhbiBhbmQgd2FudHMgYW5kIG5lZWRzIHRvIHZhbGlkYXRl4oCdLCBhbmQgdGhhdCB0 aGluZyBpcyBlaXRoZXIgZ2xvYmFsbHkgdW5pcXVlIChsaWtlDQogRE5TKSBvciBzdWZmaWNpZW50 bHkgZG9tYWluIHNwZWNpZmljIChlLmcuIFBhc3Nwb2ludCkgdGhhdCB2ZW5kb3JzIGNhbiBhZ3Jl ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W29mcmllbF0gSSB0aGluayB0aGUgc3VwcGxpY2Fu dHMgcnVubmluZyBvbiB0aGUgbWFpbiBPU2VzIHdvdWxkIGJlIGhhcHB5IHRvIGRlbGVnYXRlIHRo ZSBxdWVzdGlvbiBvZiB3aGV0aGVyIGEgQ0EgaXMgYSDigJhwdWJsaWMgQ0HigJkgdG8gdGhlIE9T LiBGb3IgbWFudWZhY3R1cmVycyBvZiB0aGluZ3MvZW1iZWRkZWQgZGV2aWNlcy9ldGMuIHRoZW4g aXRzIGN1cnJlbnRseSB2ZXJ5IG11Y2ggYXQgdGhlIG1hbnVmYWN0dXJlcnMNCiBkaXNjcmV0aW9u LCBhbmQgY29uc2Vuc3VzIGhlcmUgd291bGQgYmUgdW5saWtlbHkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpJZiBhdCBz b21lIHBvaW50IGluIHRoZSBmdXR1cmUsIHB1YmxpYyBDQXMgYXJlIHdpbGxpbmcgdG8gaXNzdWUg Y2VydHMgd2l0aCBzb21lIG9yIGFsbCBvZiB0aGUgYWJvdmUgZmllbGRzLCB0aGVuIHdoYXQgaXMg dGhlIG1pZ3JhdGlvbiBwbGFuLCB3aGF0IGRvIHdlIHRlbGwgRUFQIGNsaWVudHMgdG8gZG8gbm93 LCBhbmQgaG93IHRvIHRoZXkgbWlncmF0ZSB0aGVpciB2ZXJpZmljYXRpb24gbG9naWM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+VGhpcyBzdGF0ZW1lbnQgc2ltaWxhcmx5IHJlcXVpcmVzIHVudGFuZ2xpbmcu IFRoZXJlIGFyZSDigJxwdWJsaWMgQ0Fz4oCdIGFzIOKAnFRoZSBzZXQgb2Yga2V5cy9jZXJ0aWZp Y2F0ZXMgdXNlZCBmb3IgYXV0aGVudGljYXRpbmcgcGFydGljdWxhciBzZXJ2aWNlc+KAnSBhbmQg 4oCccHVibGljIENBc+KAnSBhcyB0aGUgc2V0IG9mIG9yZ2FuaXphdGlvbnMgdGhhdCBvd24vb3Bl cmF0ZQ0KIHRob3NlIGtleXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPlRoZSBjYXNlIG9mIHRoZSBmb3JtZXIgaXMgZXh0cmVtZWx5IHVubGlrZWx5 LCBhcyB0aGUgaW5kdXN0cnkgaXMgYWN0aXZlbHkgbW92aW5nIGF3YXkgZnJvbSB0aGF0IGFwcHJv YWNoIHRvIFBLSSwgYnkgdHJ5aW5nIHRvIGVuc3VyZSBzZXBhcmF0ZSBrZXlzIGZvciBzZXBhcmF0 ZSB1c2UgY2FzZXMgb3IgYXV0aGVudGljYXRpb24gcmVhbG1zLCBvZiB3aGljaCBFQVANCiB3b3Vs ZCBzdXJlbHkgYmUuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bb2ZyaWVsXSBBbmQgYnkgdGhp cyB5b3UgbWVhbiB0aGF0IGEgcm9vdCBDQSB3aWxsIGhhdmUgZS5nLiBvbmUgaW50ZXJtZWRpYXRl IHdpdGggRUtVcyBvZiBpZC1rcC1zZXJ2ZXJBdXRoL2lkLWtwLWNsaWVudEF1dGgsIGFuZCBhIGRp ZmZlcmVudCBpbnRlcm1lZGlhdGUgd2l0aCBhbiBFS1UgZm9yIGlkLWtwLWVtYWlsUHJvdGVjdGlv biwgcmlnaHQ/IFRoZSBsb2dpY2FsIGV4dGVuc2lvbiBoZXJlIGZvciBFQVAgaXMNCiB5ZXQgYW5v dGhlciBpbnRlcm1lZGlhdGUgd2l0aCBhbiBFS1UgZm9yIGlkLWtwLWVhcE92ZXJMQU4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoZSBjYXNlIG9m IHRoZSBsYXR0ZXIgaXMgYWxyZWFkeSBhdmFpbGFibGUgZnJvbSBzYWlkIG9yZ2FuaXphdGlvbnMg YXMgcGFydCBvZiDigJxtYW5hZ2VkIENB4oCdIG9yIOKAnHByaXZhdGUgQ0HigJ0gb2ZmZXJpbmdz LCB3aGljaCBhcmUgb3BlcmF0ZWQgYnkgdGhhdCBwdWJsaWMgQ0Egb3JnYW5pemF0aW9uLCBidXQg dGhhdOKAmXMgZWZmZWN0aXZlbHkgZ3JlZW5maWVsZCBiZWNhdXNlDQogeW91IGFyZW7igJl0IGhh dmluZyB0byBpbnRlcm9wZXJhdGUgd2l0aCBhbnkgZXh0YW50IGtleXMgb3IgY2VydGlmaWNhdGUg cHJvZmlsZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltvZnJpZWxdIFJpZ2h0LCBidXQgZnJv bSBhIHN1cHBsaWNhbnQgcGVyc3BlY3RpdmUgKG9yIGluIGdlbmVyYWwgZm9yIGFueSBjbGllbnQg cnVubmluZyBvbiBhbnkgT1MgZS5nLiBCcm93c2VyIG9uIFdpbmRvd3MpLCB0aGVyZSBpcyB6ZXJv IGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBvcGVyYXRvciB3aG8gZGVwbG95cyBhbmQgcnVucyB0aGVp ciBvd24gcHJpdmF0ZSBDQSwgb3IgdGFrZXMgYSBjb250cmFjdCBvdXQNCiB3aXRoIGEgcHVibGlj IENBIG9yZ2FuaXphdGlvbiBhbmQgZ2V0cyB0aGVtIHRvIHJ1biBhIG1hbmFnZWQvcHJpdmF0ZSBD QSBvbiB0aGVpciBiZWhhbGYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpUaGUgaWRlYWwgZXhwZXJpZW5jZSB3b3VsZCBi ZSBhbG9uZyB0aGVzZSBsaW5lcyBmb3IgYSBjbGllbnQgd2l0aCByZWFsIHVzZXIgaW50ZXJhY3Rp b25zOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQotIGNsaWVudCBjb25uZWN0cyB0byBhbiBFQVAgc2VydmVyPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCi0gY2xpZW50IHBy b21wdHMgdXNlciBmb3IgdXNlcklkICYjNDM7IHJlYWxtIGFuZCBwYXNzd29yZDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQotIGNsaWVu dCB2ZXJpZmllcyBzZXJ2ZXIgY2VydCBoYXMgaWQta3AtZWFwT3ZlckxBTiBzZXQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5XaGF0IGFzc3VyYW5jZSBpcyB0aGlzIHRvIHByb3ZpZGU/PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPltvZnJpZWxdIFRvIGFzc3VyZSB0aGF0IHRoZSBjZXJ0IGlzIGZvciB0aGUgaW50 ZW5kZWQgcHVycG9zZSDigJMgODAyLjFYL0VBUCBzZXJ2ZXIgYXV0aC4gSnVzdCBsaWtlIG90aGVy IFRMUy9Ccm93c2VyIGNsaWVudHMgY2hlY2tzIGZvciBpZC1rcC1zZXJ2ZXJBdXRoLg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBw dCI+DQotIE5BSVJlYWxtIGluIGNlcnQgbWF0Y2hlcyB1c2Vy4oCZcyByZWFsbTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPlRoaXMgb25seSB3b3JrcyBpZmYgdGhlIE5BSXMgYXJlIGdsb2JhbGx5IHVuaXF1ZSAo ZS5nLiBtYXAgdG8gRE5TKSwgd2hpY2ggaW1wb3NlcyByZXF1aXJlbWVudHMgb24gTkFJcyB0aGF0 IGFyZW7igJl0IHByZXNlbnQgaW4gUkZDIDc1NDIsIGFuZCBzZWVtaW5nbHkgaW50ZW50aW9uYWxs eSwgY29tcGFyZWQgdG8gNDI4Mi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W29mcmllbF0gQWxhbiBoYXMgY2xhcmlmaWVk IHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KLSB2ZXJpZnkgdGhl IGNlcnQgc2lnbmluZyBjaGFpbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhlIHJlYWxpdHkgdG9kYXkgaXMgdGhh dCBpZiB0aGUgc2VydmVyIGNlcnQgaXMgaXNzdWVkIGJ5IGEgcHVibGljIENBLCB0aGVuIGFsbCB0 aGF0IGNsaWVudCBjYW4gcmVhbGx5IGNoZWNrIGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQotIGlkLWtwLXNlcnZlckF1dGggaXMg c2V0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NCi0gZE5TTmFtZSBpbiBjZXJ0IG1hdGNoZXMgdXNlcuKAmXMgcmVhbG08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KLSB2ZXJp ZnkgdGhlIGNlcnQgc2lnbmluZyBjaGFpbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KV2Ugd291bGQgbGlrZSB0byBk b2N1bWVudCBzb21lIHJlY29tbWVuZGF0aW9ucyBmb3IgRUFQIGNsaWVudHMgYW5kIEVBUCBvcGVy YXRvcnMgc28gdGhhdCBwdWJsaWMgQ0FzIGNvdWxkIGJlIHVzZWQsIGFuZCByZWNvbW1lbmQgY2hl Y2tzIGZvciBwdWJsaWMgdnMuIHByaXZhdGUgQ0EgaXNzdWVkIEVBUCBzZXJ2ZXIgY2VydHMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+SWYgeW91IG1lYW4gdGhlIHNhbWUgc2V0IG9mIENBcyBhbmQga2V5cyB1 c2VkIGZvciBUTFMgYnkgY29tbW9uIG9wZXJhdGluZyBzeXN0ZW1zIGFuZCBicm93c2VycywgaXQg YmVhcnMgaGlnaGxpZ2h0aW5nIGFnYWluOiBpbmR1c3RyeSBpcyBtb3ZpbmcgYXdheSBmcm9tIHRo YXQuIFdoaWNoIGlzIHRvIHNheSB0aGF0IGNvbnRyYWN0cyBhbmQgcmVxdWlyZW1lbnRzIGZvcg0K IFBLSXMgdXNlZCDigJxieSBkZWZhdWx04oCdIGJ5IGJyb3dzZXJzIGFuZCBvcGVyYXRpbmcgc3lz dGVtcyBhcmUgYmVpbmcgZXhwbGljaXQgYWJvdXQgdGhlIG5lZWQgdG8gc2VnbWVudCBwdXJwb3Nl IGFuZCB1c2UgY2FzZSBhbmQgbm90IHVzZSBzdWNoIGNlcnRpZmljYXRlcyBmb3Igc3VjaCBwdXJw b3Nlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W29mcmllbF0gSSBhZ3JlZSB0aGF0IGlkZWFs bHkgJm5ic3A7V2ViL1RMUyBCcm93c2VyIGNlcnRzIHNob3VsZCBub3QgcmVhbGx5IGJlIHVzZWQg Ynkgb3BlcmF0b3JzIGFzIHRoZWlyIEVBUCBzZXJ2ZXIgaWRlbnRpdHkgY2VydHMsIGhvd2V2ZXIs IHRoaXMgZG9lcyBhY3R1YWxseSBoYXBwZW4gdG9kYXkuIEluIGFuIGlkZWFsIHdvcmxkLCBpdCB3 b3VsZCBiZSBncmVhdCBpZiBzb21lIG9mIHRoZSBsYXJnZSBjb21tZXJjaWFsDQogKG9yIGZyZWUg ZS5nLiBMZXRzRW5jcnlwdCkgcHVibGljIFdlYi9UTFMgQ0FzIGhhZCBhbiBpbnRlcm1lZGlhdGUg c2lnbmluZyBDQSB3aXRoIGlkLWtwLWVhcE92ZXJMQU4uIEJ1dCB0b2RheSwgYW5kIGZvciB0aGUg Zm9yZXNlZWFibGUgZnV0dXJlLCB3aGF0IGNhbiB3ZSBhZHZpc2Ugc3VwcGxpY2FudHMgdG8gZG8g aWYgd2Uga25vdyB0aGF0IHNvbWUgb3BlcmF0b3JzIHdpbGwgcHV0IFdlYi9UTFMgaWRlbnRpdHkg Y2VydHMgZnJvbSBwdWJsaWMgQ0FzDQogb24gdGhlaXIgRUFQIHNlcnZlcnM/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFscmVhZHksIFRMUyBhbmQg ZS1tYWlsLCB0aGUgdHdvIGRvbWluYW50IHVzZXMgb2YgUEtJIGluIHN1Y2ggc3lzdGVtcywgYXJl IHJlcXVpcmVkIHRvIGJlIGRpc3Rpbmd1aXNoZWQgYXQgdGhlaXIgaW50ZXJtZWRpYXRlIGxldmVs LiBCcm93c2VycyBhcmUgbG9va2luZyB0byBleHBsaWNpdGx5IG9ubHkgdHJ1c3QgdGhlIFRMUy1X ZWIgc2lkZSBvZiB0aGUgUEtJLCBhbmQNCiBtYWtpbmcgc3VyZSB0aGF0IHRoZSBUTFMtV2ViIFBL SSBzaWRlIGlzIGhpZ2hseSBhZ2lsZS4gT3RoZXIgY2FzZXMsIHN1Y2ggYXMgcmVzdHJpY3RlZCB1 c2Ugc2VydmVyIHRvIHNlcnZlciBQS0kgb3IgaW5kdXN0cnkgYmVzcG9rZSBjYXNlcyAoc3VjaCBh cyBmaW5hbmNpYWwgc2VydmljZXMgb3Igc3lzdGVtIG5ldHdvcmtpbmcpIGFyZSBiZWluZyByZXN0 cmljdGVkIHRvIFBLSXMgdGhhdCBhcmVu4oCZdCBmZWRlcmF0ZWQtYnktZGVmYXVsdC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Rm9yIGV4YW1wbGUs IFg5IHJlY2VudGx5IHJldml2ZWQgdGhlaXIgUEtJIFdHLCB0byBkZWZpbmUgUEtJIHJlcXVpcmVt ZW50cyBhcHByb3ByaWF0ZSBmb3IgZmluYW5jaWFsIHNlcnZpY2VzIGN1c3RvbWVycyAobGlrZSBB VE0gdG8gYmFuayksIGJlY2F1c2UgZmluYW5jaWFsIHNlcnZpY2VzIHN0cnVnZ2xlIHRvIG1vdmUg YXQgdGhlIHNhbWUgc3BlZWQgYXMgbW9kZXJuDQogc29mdHdhcmUsIGZvciB1bmRlcnN0YW5kYWJs ZSByZWFzb25zLiBUaGUgdXNlIG9mIGRvbWFpbi9wdXJwb3NlLXNwZWNpZmljIFBLSXMgaXMgc29t ZXRoaW5nIHdlIGNhbiBhbmQgc2hvdWxkIGJlIGVtYnJhY2luZyBtb3JlIG9mLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5bb2ZyaWVsXSBTdXJlLCBJ4oCZbSBub3Qgc2F5aW5nIHRoYXQgaWQta3At ZWFwT3ZlckxBTiBpcyBhIGJhZCBpZGVhIG9yIHRoYXQgc3VwcGxpY2FudHMgc2hvdWxkIG5ldmVy IGxvb2sgZm9yIGl0LiBCdXQgaG93IGRvIHdlIGdldCB0byB0aGUgcG9pbnQgd2hlcmUgd2UgY291 bGQgYWN0dWFsbHkgZW5mb3JjZSB0aGF0LCBnaXZlbiB0aGF0IHRvZGF5IG9wZXJhdG9ycyBkbyB0 cnkgdG8gdXNlIEVBUCB3aXRoIFdlYi9UTFMNCiBjZXJ0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkl0IHNlZW1zIGxp a2UgbG9naWMgc2hvdWxkIGJlIHNvbWV0aGluZyBsaWtlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KLSByZWNvbW1l bmQgRUFQIG9wZXJhdG9ycyB3aXRoIHByaXZhdGUgQ0EgaXNzdWVkIGNlcnRzIG9uIHRoZWlyIEVB UCBzZXJ2ZXJzIHNldCBpZC1rcC1lYXBPdmVyTEFOIGFuZCBOQUlSZWFsbSBzZXQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KLSByZWNv bW1lbmQgRUFQIG9wZXJhdG9ycyB1c2luZyBwdWJsaWMgQ0FzIGdldCBFQVAgc2VydmVyIGNlcnRz IHdpdGggaWQta3Atc2VydmVyQXV0aCBhbmQgZE5TTmFtZSBzZXQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCi0gcmVjb21tZW5kIGNs aWVudHMgZW5hYmxlIHRydXN0IGluIHB1YmxpYyBDQXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iYm9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+VGhpcyBpcyB3 aHkgSSBzdGFydGVkIHdpdGggdHJ5aW5nIHRvIGRlZmluZSB3aGF0IOKAnHB1YmxpYyBDQXPigJ0g YXJlLiBJZiB5b3UgbWVhbiB0aGUgZXh0YW50IENBcyB0cnVzdGVkIGJ5IGJyb3dzZXJzIGFuZCBv cGVyYXRpbmcgc3lzdGVtcywgYm90aCB0aGlzIHJlY29tbWVuZGF0aW9uDQogYW5kIHRoZSBvbmUg cHJvY2VlZGluZyBpdCBtYXkgbm90IGJlIGdvb2QgcmVjb21tZW5kYXRpb25zIG9yIGxvbmctdGVy bSB2aWFibGUgcHJhY3RpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W29mcmll bF0gWWVzLCBJIG1lYW4gZXh0YW50IENBcyB0cnVzdGVkIGJ5IEJyb3dzZXJzIGFuZCBPU2VzLiBZ ZXMgdGhlIHJlY29tbWVuZGF0aW9ucyBhcyB3cml0dGVuIGFib3ZlIHdvdWxkIG1lYW4gdXNpbmcg YSBjZXJ0IHdpdGggYSBFS1UgZm9yIG9uZSBwdXJwb3NlLCBmb3IgYSBkaWZmZXJlbnQgcHVycG9z ZSwgYnV0IHRoYXQgaXMgdGhlIHVuZm9ydHVuYXRlIHJlYWxpdHkuIERvIHdlIGlnbm9yZSB0aGUg cHJvYmxlbQ0KIGFuZCBzYXkg4oCYRG9u4oCZdCBkbyB0aGlz4oCZIG9yIGRvIHdlIHRyeSB0byBk b2N1bWVudCBzb21lIGNvbXByb21pc2UgcmVjb21tZW5kYXRpb25zIGZvciBib3RoIHN1cHBsaWNh bnRzIGFuZCBDQXMsIHdpdGggYSByb2FkbWFwIG9mIGhvdyB0byBldm9sdmU/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJib3Jk ZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj5UaGF04oCZcyBub3QgdG8gc2F5 IHlvdSBjb3VsZG7igJl0LCBidXQgaXQgbWVhbnMgeW91ciBFQVAgc2VydmljZXMgYW5kIHNlcnZl cnMgbmVlZCB0byBiZSBwcmVwYXJlZCB0byBiZSBhcyBhZ2lsZSBhcyB0aGUgV2ViIGVjb3N5c3Rl bSBpcyBhbmQgbW9kZXJuIG9wZXJhdGluZw0KIHN5c3RlbXMgYXJlIGNvbnZlcmdpbmcgb24uIFRo ZSBhYmlsaXR5IHRvIHN1cHBvcnQgb3IgYmUgYmVob2xkZW4gdG8g4oCcbGVnYWN54oCdIC0gd2hl dGhlciBhbGdvcml0aG1zLCBwcm9maWxlcywgb3IgdHJ1c3QgaW4gcGFydGljdWxhciBvcmdhbml6 YXRpb25zIC0gaXMgc29tZXRoaW5nIHRoYXQgaW5kdXN0cnkgaXMgcmVjb2duaXppbmcgZG9lcyBu b3QgYWxpZ24gd2l0aCB1c2VyIG5lZWRzLiBUaGlzIG1lYW5zIGFkb3B0aW5nIHByYWN0aWNlcyBs aWtlDQogYXV0b21hdGlvbiwgYmVpbmcgYWJsZSB0byBxdWFudGlmeSBjb21wYXRpYmlsaXR5IHJp c2tzLCBhbmQgYmVpbmcgYWJsZSB0byBtb3ZlIHF1aWNrbHkgYXMgZXhwZWN0YXRpb25zIGNoYW5n ZSwgaW4gcmVzcG9uc2UgdG8gZWNvc3lzdGVtIGNoYWxsZW5nZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5bb2ZyaWVsXSBJIGhvcGUgdGhhdCB0aGlzIHByb2JsZW0gaXMgZWFzaWVy IHRvIHRhY2tsZSBmb3Igc3VwcGxpY2FudHMgcnVubmluZyBvbiB0aGUgbWFqb3IgT1Nlcy4gRm9y IHRoaW5ncy9lbWJlZGRlZCBkZXZpY2VzLCB0aGlzIGlzIGEgZmFyIGhhcmRlciBwcm9ibGVtIHRv IHNvbHZlIGZvciBzdXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iYm9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjBjbSI+TWF5YmUgdGhhdOKAmXMgZmluZSBmb3IgRUFQLCBidXQgSeKAmW0gd2lsbGluZyB0 byBzdXNwZWN0IHRoYXQgaXQgYmVjYXVzZSB1cGRhdGVzIG1heSBpbnZvbHZlIHBoeXNpY2FsbHkg cmVwbGFjaW5nIGNsaWVudCBoYXJkd2FyZSBvciBwaHlzaWNhbGx5IGluc3RhbGxpbmcgZmlybXdh cmUsDQogeW91IHJlYWxseSBkb27igJl0IHdhbnQgRUFQIG5lZWRpbmcgdG8gYmUgYmVob2xkZW4g dG8gdGhvc2UgYWdpbGl0eSBuZWVkcyBvZiB0aGUgV2ViIGFuZCBPU2VzLiBBbmQsIGFnYWluLCB0 aGF04oCZcyBwZXJmZWN0bHkgT0ssIGl0IGp1c3QgbWVhbnMgZGVmaW5pbmcgYSBQS0kgYW5kIHNl dCBvZiBwcm9jZWR1cmVzIHRoYXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoYXQgdXNlIGNhc2UsIGFu ZCBjb252aW5jaW5nIGluZHVzdHJ5IHRvIGFkb3B0IGl0IGFzIGFuDQog4oCcb3V0IG9mIHRoZSBi b3jigJ0gY29uZmlndXJhdGlvbi4gT3IsIGFsdGVybmF0aXZlbHksIGVtYnJhY2luZyBwcml2YXRl IFBLSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltvZnJpZWxdIE1heWJlIGFuIGFw cHJvYWNoIHRvIHRha2UgaXMgdG8gaGF2ZSBvbmUgc2V0IG9mIHJlY29tbWVuZGF0aW9ucyBmb3Ig c3VwcGxpY2FudCBjbGllbnRzIG9uIG1ham9yIE9TZXMgd2hlcmUgdGhleSBjYW4gZGVsZWdhdGUs IGFuZCBwb3NzaWJseSBwaWdneSBiYWNrIG9uIHRvcCBvZiwgc2ltaWxhciBPUyBmdW5jdGlvbmFs aXR5IGZvciBXZWIvVExTOyBhbmQgaGF2ZSBhIGRpZmZlcmVudCBzZXQgb2YNCiByZWNvbW1lbmRh dGlvbnMgZm9yIHRoaW5nIG1hbnVmYWN0dXJlcnMuIE9yIHBvc3NpYmx5IGZyYW1lIHRoZSByZXF1 aXJlbWVudHMgYXMg4oCYcmVxdWlyZW1lbnRzIHRoZSBzdXBwbGljYW50IHNob3VsZCBlbmZvcmNl 4oCZIHZzLiDigJhyZXF1aXJlbWVudHMgdGhlIHN1cHBsaWNhbnQgc2hvdWxkIGRlbGVnYXRlIHRv IHRoZSBPUyAoZS5nLiBpcyB0aGlzIGEgcHVibGljIENBPynigJkuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQotIHJlY29t bWVuZCBjbGllbnRzIGltcGxlbWVudCBkaWZmZXJlbnQgY2VydCB2ZXJpZmljYXRpb24gbG9naWMg ZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhlIEVBUCBzZXJ2ZXIgY2VydCBpcyBpc3N1ZWQgYnkgYSBw dWJsaWMgQ0Egb3IgcHJpdmF0ZSBDQTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPldoeSBpcyB0aGlzIGdvb2Q/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRvIHRo ZSBleHRlbnQgYnJvd3NlcnMgb3IgT1NlcyBtYWtlIHRoaXMgZGlzdGluY3Rpb24sIGl04oCZcyBs YXJnZWx5IGJhc2VkIG9uIHNpbXBseSBwaGFzaW5nIHJvbGxvdXRzIG9mIG5ldyByZXF1aXJlbWVu dHMsIHdpdGggdGhlIGdvYWwgdG8gZXZlbnR1YWxseSByZXF1aXJlIGNvbnNpc3RlbnQgYW5kIHVu aWZvcm0gdHJlYXRtZW50IHRvIGVuc3VyZSBzaW1wbGVyIGNvZGUNCiB3aXRoIGNvbnNpc3RlbnQg YW5kIHVuaWZvcm0gc2VjdXJpdHkgcHJvcGVydGllcy4gSGF2aW5nIGEgbG9uZy10ZXJtIHNlZ21l bnRhdGlvbiBvZiByZXF1aXJlbWVudHMsIG9yIGV2ZW4gZW5jb3VyYWdpbmcgdGhlbSB3aXRob3V0 IGEgY2xlYXIgdmlzaW9uIGJhY2sgdG8gaGFybW9uaXphdGlvbiwgaXMgZGVmaW5pdGVseSBhbiBh bnRpLXBhdHRlcm4gaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltv ZnJpZWxdIENvbXBsZXRlbHkgYWdyZWUuIFdoaWNoIGlzIHdoeSBJIHN0YXRlZCBiZWxvdyDigJxh cyBhIGxvbmdlciB0ZXJtIGdvYWwgc2VlIGlmIHB1YmxpYyBDQXMgd2lsbCBpc3N1ZSBpZC1rcC1l YXBPdmVyTEFOIGFuZCBOQUlSZWFsbeKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KLSBmb3IgcHVibGljIENBIGNlcnRz LCBjbGllbnQgY2hlY2tzIHRoYXQgaWQta3Atc2VydmVyQXV0aCBpcyBzZXQgKjxiPmFuZDwvYj4q IGROU05hbWUgbWF0Y2hlcyB1c2VyIHJlYWxtLiBJZiBlaXRoZXIgY2hlY2sgZmFpbHMsIHJlamVj dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4w cHQiPg0KLSBmb3IgcHJpdmF0ZSBDQSBjZXJ0cywgY2xpZW50IGNoZWNrcyB0aGF0IGlkLWtwLXNl cnZlckF1dGggb3IgaWQta3AtZWFwT3ZlckxBTiBpcyBzZXQgKjxiPmFuZDwvYj4qIE5BSVJlYWxt IG1hdGNoZXMgdXNlciByZWFsbS4uIElmIGVpdGhlciBjaGVjayBmYWlscywgcmVqZWN0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KLSBhcyBhIGxvbmdlciB0ZXJtIGdvYWwgc2VlIGlmIHB1YmxpYyBDQXMgd2lsbCBp c3N1ZSBpZC1rcC1lYXBPdmVyTEFOIGFuZCBOQUlSZWFsbS4gQWx0aG91Z2ggb2YgY291cnNlIGlm IHNvbWUgd2VyZSB0byBzdGFydCBkb2luZyB0aGlzLCB0aGVuIHRoZXJlIGlzIGEgbWlncmF0aW9u IGNoYWxsZW5nZSwgYW5kIGNsaWVudHMgY2Fubm90IG1ha2UgYSBoYXJkIGNoZWNrIGZvciB0aGVz ZSB2YWx1ZXMgYWdhaW5zdCBhbGwgcHVibGljIENBcy4gVGhpcw0KIGRvZXNu4oCZdCByZWFsbHkg c2VlbSBwcmFjdGljYWwgaW4gdGhlIG5lYXIgdGVybSBhdCBhbGwuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ VGhlIGVmZmVjdCBvZiB0aGUgc2VwYXJhdGUgRUtVLCB3aGljaCBpcyBhY3R1YWxseSBxdWl0ZSBk ZXNpcmFibGUsIGlzIHRoYXQgaXQgZnVuY3Rpb25hbGx5IG1ha2VzIGl0IGRpZmZpY3VsdCBmb3Ig Q0FzIHRvIGlzc3VlIHRoZXNlIGNlcnRpZmljYXRlcyBmcm9tIGludGVybWVkaWF0ZWQgdGhhdCBs YWNrIHRoaXMgRUtVIG9yIGFueSBFS1UuIEZ1cnRoZXIsICZuYnNwO0NBcw0KIHN1YmplY3QgdG8g YnJvd3Nlci9PUyB2ZW5kb3Igb3ZlcnNpZ2h0IGFyZSBjb25zaXN0ZW50bHkgcmVxdWlyZWQgdG8g c2VnbWVudCBvdXQgdGhlaXIgRUtVcyBhdCB0aGUgaW50ZXJtZWRpYXRlIGxldmVsLCBhbmQgcmVx dWlyZWQgdG8gYWx3YXlzIHNwZWNpZnkgRUtVcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIGVuZCByZXN1bHQgaXMgdGhhdCwgdG8gYWNoaWV2 ZSB0aGlzIGxvbmcgdGVybSBnb2FsLCB5b3XigJl2ZSBlZmZlY3RpdmVseSByZXF1aXJlZCB0aGUg ZXN0YWJsaXNobWVudCBvZiBhIG5ldyBQS0kgLSBqdXN0IGF0IHRoZSBpbnRlcm1lZGlhdGUgbGV2 ZWwgcmF0aGVyIHRoYW4gdGhlIHJvb3QuIEFuZCBhcyBtYW55IG9mIHRoZSBwdWJsaWMgQ0FzIGNh biB0ZWxsDQogeW91LCBoYXZpbmcgcmVjZW50bHkgZW5jb3VudGVyZWQgY2hhbGxlbmdlcyByZWdh cmRpbmcgbm9uLVRMUyBpbnRlcm1lZGlhdGVzIGZyb20gcm9vdHMgdGhhdCBhcmUgc3ViamVjdCB0 byBicm93c2VyL09TIG92ZXJzaWdodCwgaXTigJlzIG9mdGVuIGVhc2llciB0byB1c2Ugc2VwYXJh dGUgcm9vdHMgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+QWdhaW4sIEkgdGhpbmsgdGhhdOKAmXMgZGVzaXJhYmxlLCB0byBkZWZpbmUg YW4gZW50aXJlbHkgbmV3IFBLSSB3aXRoIHplcm8gb3ZlcmxhcCB3aXRoIHRoZSBzZXJ2ZXIgYXV0 aC9UTFMgUEtJIHVzZWQgYnkgT1Nlcy9icm93c2VycywgYnV0IHRoYXQgZG9lcyBjaGFuZ2UgeW91 ciByZWNvbW1lbmRhdGlvbnMgYW5kIGRlc2lnbiBhIGJpdCA6KSBUaGUgc2hvcnQgdGVybQ0KIHJl Y29tbWVuZGF0aW9uIGJlY29tZXMg4oCcZG9u4oCZdCB1c2UgcHVibGljIENBc+KAnSwgYW5kIHRo YXQgc2VlbXMgZWFzaWVyIHRvIGV4cGxhaW4gYW5kIGVhc2llciB0byBldm9sdmUgdGhlIHRlY2hu aWNhbCByZXF1aXJlbWVudHMsIHVudGlsIHRoZSB0aW1lIHRoYXQgc3VjaCBhIG5ldywgRUFQLXNw ZWNpZmljIHB1YmxpYyBQS0kgY2FuIGJlIGludHJvZHVjZWQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPltvZnJpZWxdIEdldHRpbmcgcHVibGljIENBcyB0byBtYW5hZ2UgYSBuZXcgUEtJIHJvb3Qg KGlmIHRoYXTigJlzIGVhc2llciB0aGFuIGp1c3QgYSBuZXcgaW50ZXJtZWRpYXRlKSB3aXRoIGlk LWtwLWVhcE92ZXJMQU4gaXMgYSByZWFsbHkgcmVhbGx5IGxvbmcgcm9hZC4gQW5kIHdlIGtub3cg dGhhdCBzb21lIG9wZXJhdG9ycyBkbyB1c2UgcHVibGljIFdlYi9UTFMgY2VydHMgYXMgRUFQIGlk ZW50aXR5IGNlcnRzLg0KIFdoaWNoIG1lYW5zIHRoYXQgd2UgY2Fubm90IHJlY29tbWVuZCBzdXBw bGljYW50cyBlbmZvcmNlIGEgY2hlY2sgZm9yIGlkLWtwLWVhcE92ZXJMQU4uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNvIGl0IGxvb2tzIGxpa2UgdGhlcmUgYXJlIHRocmVlIGNob2ljZXM6PG86 cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPkNvbXBsZXRlbHkgaWdub3JlIGlkLWtwLWVhcE92ZXJM QU4gZm9yIGV2ZXIuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+R2V0IHN1cHBs aWNhbnRzIHRvIGNoZWNrIGlkLWtwLWVhcE92ZXJMQU4gaWYgaXRzIG5vdCBhIHB1YmxpYyBDQSAo YW5kIHVzZSBDaHJvbWl1bSBzdHlsZSBwdWJsaWMgQ0EgZGV0ZWN0aW9uKS4gUm9sbG91dCBvZiB0 aGlzIHdvdWxkIG5lZWQgdG8gYmUgY2FyZWZ1bGx5IG1hbmFnZWQgdG9vIHNvIHRoYXQgZXhpc3Rp bmcNCiBwcml2YXRlIENBIG9wZXJhdG9ycyB3aG8gZG8gbm90IHNldCBpZC1rcC1lYXBPdmVyTEFO IGRvIG5vdCBicmVhay48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj5EbyBub3Ro aW5nIHVudGlsICZuYnNwO3N1ZmZpY2llbnQgbnVtYmVycyBvZiBwdWJsaWMgQ0FzIHN1cHBvcnQg aWQta3AtZWFwT3ZlckxBTiAoaW4gbGlrZSAyMDM1Li4/KSwgdGhlbiBjaGFuZ2Ugc3VwcGxpY2Fu dHMgdG8gYWx3YXlzIGNoZWNrIGZvciBpZC1rcC1lYXBPdmVyTEFOLjxvOnA+PC9vOnA+PC9saT48 L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JdHMgbm90IGNsZWFyIHRvIG1lIHdoZXJlIHRoZSBjb3JyZWN0IGZvcnVt IGlzIHRvIGV2ZW4gZG9jdW1lbnQgdGhlc2UgcmVjb21tZW5kYXRpb25zLCBvciB3aG8gbmVlZHMg dG8gYmUgaW52b2x2ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPkluIG15IG1pbmQsIHRoaXMgaXMgbm8gZGlmZmVyZW50IGZyb20gb3JnYW5pemF0 aW9ucyB0aGF0IHdhbnQgVExTIGNlcnRpZmljYXRlcyBmb3IgdGhlaXIgc2VydmVycyBuYW1lZCDi gJx3ZWJtYWls4oCdIChub3QgZ2xvYmFsbHkgdW5pcXVlKSBvciDigJxtYWlsXzAxLmNvbXBhbnku ZXhhbXBsZeKAnSAobm90IHByZWZlcnJlZCBuYW1lIGZvcm0gLyBMREgpLiBUaGUgYW5zd2VyIGlz DQog4oCcdXNlIHByaXZhdGUgQ0FzLCBkb27igJl0IHVzZSBwdWJsaWMgQ0Fz4oCdPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+ DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KTm90ZSB0aGF0IGZvciBhbiBJb1QgZGV2aWNlLCB0aGVyZSBpcyBzb21lIHdv cmsgdG8gZG8gdG8gZGVmaW5lIGhvdyB0byBlLmcuIGV4dGVuZCB0aGUgUkZDODM2NiBzbyB0aGF0 IGl0IGNhbiBzcGVjaWZ5IHRoZSBkTlNOYW1lIHRoYXQgZGV2aWNlcyBzaG91bGQgY2hlY2sgZm9y IHdoZW4gdmVyaWZ5aW5nIEVBUCBpZGVudGl0eSB3aGVyZSB0aGV5IEVBUCBzZXJ2ZXIgdXNlcyBh IHB1YmxpYyBDQS4gU29tZSByZWxhdGVkIG9wdGlvbnMgYXJlIG91dGxpbmVkDQogaW4gPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZyaWVsLWFuaW1hLWJyc2tpLWNs b3VkLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZnJpZWwtYW5pbWEtYnJza2ktY2xvdWQtMDE8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KQ29tbWVudHMv dGhvdWdodHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpPd2VuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4w cHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NClNwYXNtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpTcGFzbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlNwYXNtQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Bh c20iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwYXNtPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB39013D4C54FEACDC8228D136DB3F0MN2PR11MB3901namp_-- From nobody Tue Jan 7 05:53:35 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE78712011A; Tue, 7 Jan 2020 05:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lbRcm54H; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NxoSyXpW 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 uTgkNzvduMVj; Tue, 7 Jan 2020 05:53:30 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97111120116; Tue, 7 Jan 2020 05:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19496; q=dns/txt; s=iport; t=1578405210; x=1579614810; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yaQF7bl5eNIMDd6K8mejF2duADFXgvmVjxe4rCQZb1s=; b=lbRcm54H0znbDB+ZfaI9imYVfkmSS59m5mHORxz3rjB9sWY0qPnWLBv9 l8L0EgP0lcoMWKP/DNYzswwZ+96E3+QN6OvQ5qPOSAQhjDrbAAH9QifvP raWLyCCVSa1IWXICkrG6sNeq3z0Qoa0BrPqWWb2hWl9+aSvFjQnxhNbpz g=; IronPort-PHdr: =?us-ascii?q?9a23=3AvzLGvhRvxf2PVDVVk0aYcuPNDNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOis0BsVPUHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AABjjBRe/5RdJa1QDQUCAhoBAQE?= =?us-ascii?q?BAQEBAQEDAQEBAREBAQECAgEBAQGBfIFUKScFbFAIIAQLKgqDf4NGA4sDgl+?= =?us-ascii?q?YDYJSA1QJAQEBDAEBJwYCAQGBTIIvRQIXgVIkOBMCAw0BAQQBAQECAQUEbYU?= =?us-ascii?q?3DIVeAQEBAQIBEhERDAEBNwEEBwQCAQgaAg8DAhICAgIwFRABAQQODRqDAYJ?= =?us-ascii?q?GAw4gAQIMoRUCgTiIYXWBMoJ+AQEFgTUBg1QYggwDBoEOKIwZGoFBP4FYgkw?= =?us-ascii?q?+gmQCAoEeGRQMDEYHBYI8MoIsjTMZMwOCP4V7l3J1CoI2hzWMIoJgml+CDIQ?= =?us-ascii?q?QkQuSDQIEAgQFAg4BAQWBaSKBWHAVgydQGA2NEgwXgQQBCYJCilN0CoEeinQ?= =?us-ascii?q?PFQIHgQQBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,406,1571702400"; d="scan'208";a="406290925" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2020 13:53:29 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 007DrTa6031403 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 13:53:29 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 07:53:28 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 07:53:27 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 7 Jan 2020 08:53:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ga7/lGJRezIP2h8zGBwvUhjtguuuPGX7P6FvuPEvx9GqE9OxY6/O1An8aPBUePPBs5TJXFByKHgtUBpZiW4E41nvuoqanMCJFiRFKKjg2xLso884UIrPqw9r8THZ3pDp7lnlzitP3QxguaIwhfGwfR5bfZwTTX/UGWc5my35Rs9B6UVEwuIRN24/X9DsPN2Wtuohv6HIUWbOzNLai6A7U7beEf/U/V1mwliUs2iX0xn2N38YFE1iJv0gUIji61RFQrOEcbI5MOcBKER2GCf0/Sl9ebAs53crVoaEOIa2EP8nzVQWbgAcUqaG7RZj0zokTkH1Mhi4usxL3k1Jv+S/hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yaQF7bl5eNIMDd6K8mejF2duADFXgvmVjxe4rCQZb1s=; b=E270A7fIJRXywB92f6i3xWmEo+mOA/2QC/oUjL+hiTa9z5DWwyGWOYgvif31idFsEDLGGGTIuOGaw5YoTDDSs9DDcw49LsRLGgcLZ7bLMXO8WZuTe7PtKDUIkyVMtt6i2Tq/iHGarC5278wAvjbB+qUjyZrg7qdu5hD3v8ctrSbxbJOX+ioSC8zXIC3NlgedkQpaydP+km0uzSgkENYVB4mgZtE7N4k2Z1UJs0mOQEL8pRP6MJrYfnCWRIUIVc8zx4Aq0yWS6citewRzElKIAbFvjM+3lSx/sh6ZDu/E+dTJsA2tldq9N+YNIRGltKNgTXrsi675CszRocb5xOojGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yaQF7bl5eNIMDd6K8mejF2duADFXgvmVjxe4rCQZb1s=; b=NxoSyXpWtQL7wuQxWI6IWoVfhQGEfPwkBJo8/ZU9zSug3vtaHgGd1o+p00nsx6nEwmOhtubgzVACFHyd6b1Z6flqDtJhoJVfvdPwkYwHEe8Eqw9PyqZh0LbEsrD2IDjDN6e32A053mye+DBbETQAm47yInpsXtr3Or0MIe3SEcU= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3597.namprd11.prod.outlook.com (20.178.251.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Tue, 7 Jan 2020 13:53:25 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::d1b8:3e63:ead8:10c9]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::d1b8:3e63:ead8:10c9%7]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 13:53:25 +0000 From: "Owen Friel (ofriel)" To: Ryan Sleevi CC: EMU WG , "spasm@ietf.org" Thread-Topic: [lamps] EAP/EMU recommendations for client cert validation logic Thread-Index: AdWxNKzqTmo8NKHtQwSIp+NEgFXHNACbMPUABG/okFA= Date: Tue, 7 Jan 2020 13:53:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [64.103.40.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d1554cc-1e03-413e-be3d-08d79378f765 x-ms-traffictypediagnostic: MN2PR11MB3597: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(366004)(396003)(376002)(13464003)(189003)(199004)(51914003)(51444003)(55016002)(8676002)(5660300002)(81166006)(8936002)(2906002)(81156014)(4326008)(9686003)(6916009)(64756008)(33656002)(66446008)(30864003)(186003)(26005)(52536014)(7696005)(6506007)(66556008)(478600001)(71200400001)(66476007)(86362001)(66574012)(66946007)(76116006)(54906003)(316002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3597; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0d7lTn5xhAEcuyvQ+/sd/eguxxqDopZJJqsGsky/OKGWdbbgh/tICUbSfReJL3oMGsuWy9NZVAL7bxUIoy1rIx7odtIPA+yAA3thgRFDsZ43NYvqRGI636d8odIISz6sxndhUWbsK7e7Hftgmp6hAQVl6TCxP5LTUI52qVOIrn1QQNilOt90iH/vPqAqGlgqSDwE9msn2BGNptXiTT257v43Sqo0wgt2hqR8zBD3lEcJT0icQardoyiyQHQL4hBTftQTscYfJnW8lQbF2ZZGJgVrvwecCaK+kgU5fXjwjshQmwlPmj7kuJhmu8rJN8xfJW+Tc9Uea5ZX8GbMVZGZcAazLmncycQlZdyHeIAFZJ5cnhzF132qJZBG2ywtLBLx0Wo8ogNvs6pCI2HCto7C1+Gtc8jFi1HAb49F+og+glPvzS09zeKQw3wzlJAMGcShc1kMwELNRvkD/uVl8tBU/XsbKip+idPAbgL+++eASsQsUoNs4erygvMbtVlSLFyoI0RBzbL7KH75yCX/ZtRFcYYQ9rFTA4mVOhHVeipK0zNcdsrKKBaGC+n6Wx4U2XOLZGv2dffLPzYGT3wo34TWqsFFr9gAHz8of+RW7V6C4VJiy/MEqrawbvppI5IOOqWF x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9d1554cc-1e03-413e-be3d-08d79378f765 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 13:53:25.0694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: abA3OBkzx2OwYq4H5oITNSJ0ylvxE+/Mdhzlenqr6+M/pewt/exr0xCAQ58cV1zzL75o5X0fYzUB7b82B1loWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3597 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [lamps] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:53:33 -0000 VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgcmVwbHkgUnlhbi4gU2VlIGxpbmUuDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiANCj4gSWYgYW4gRUFQIHNlcnZlciBvcGVyYXRvciB3 YW50cyB0byB1c2UgYSBwdWJsaWMgQ0EgaWRlbnRpdHkgY2VydCBvbiB0aGVpciBFQVANCj4gc2Vy dmVyLCB3aGF0IHJlY29tbWVuZGF0aW9ucyBzaG91bGQgd2UgZ2l2ZSB0byBFQVAgY2xpZW50cyBz byB0aGF0IHRoZQ0KPiBzdXBwbGljYW50IGNvZGUgY2FuIGhhbmRsZSBwdWJsaWMgb3IgcHJpdmF0 ZSBDQSBpc3N1ZWQgRUFQIHNlcnZlciBpZGVudGl0eSBpbiBhDQo+IHNlY3VyZSBhIGZhc2hpb24g YXMgcG9zc2libGU/DQo+IA0KPiBEZWZpbmUg4oCccHVibGljIENB4oCdIGZpcnN0LCBhbmQgaXTi gJlsbCBiZSBjbGVhcmVyIHRoYXQgdGhlIHF1ZXN0aW9uIGlzIHJlYWxseQ0KPiBzdXBwbGljYW50 LXNwZWNpZmljLg0KPiANCj4gVGhhdCBpcywgbW9zdCBkZWZpbml0aW9ucyBmb3Ig4oCccHVibGlj IENBc+KAnSBjb21lIGRvd24gdG8g4oCcSSBkb27igJl0IHdhbnQgdG8gdGhpbmsNCj4gYWJvdXQg LyBhbmFseXplIHRoZSBzZWN1cml0eSBvciB2YWxpZGF0aW9uIHByYWN0aWNlcyBvZiB0aGUgQ0Es IEkgd2FudCBteQ0KPiBzdXBwbGljYW50IC8gc29mdHdhcmUgLyBoYXJkd2FyZSB2ZW5kb3IgdG8g ZG8gaXQgZm9yIG1lLCBhZ2FpbnN0IHNvbWUgY3JpdGVyaWENCj4gdGhlIHZlbmRvciBpcyByZXNw b25zaWJsZSBmb3IsIGFuZCBob3BlIGl0IGFsbCB3b3JrcyBvdXTigJ0uIFRvIHRoZSBleHRlbnQg VExTDQo+IHVzZXMg4oCYcHVibGljIENBc+KAmSwgaXQgZWl0aGVyIGJvaWxzIGRvd24gdG8gdGhl IE9TIG9yIGJyb3dzZXIgdmVuZG9ycyByZWFjaGluZw0KPiByb3VnaCAoaW5kZXBlbmRlbnQpIGNv bnNlbnN1cyBvbiB3aG8gaXMgd29ydGggdHJ1c3RpbmcsIG9yIHRoZSB2ZW5kb3INCj4gZ29pbmcg YWxvbmcgd2l0aCBldmVyeW9uZSBlbHNl4oCZcyBkZWNpc2lvbnMgZm9yIGNvc3QgKHRvbyBleHBl bnNpdmUgZm9yIHRoZQ0KPiB2ZW5kb3IgdG8gZXZhbHVhdGUpIG9yIGNvbXBhdGliaWxpdHkgKGV2 ZXJ5b25lIGVsc2UgdHJ1c3RzIHRoZW0gYW5kIGl04oCZZA0KPiBicmVhayB0aGluZ3MgaWYgdGhl IHZlbmRvciBkb2VzbuKAmXQpIHJlYXNvbnMuDQogDQoNCltvZnJpZWxdIFRoYXTigJlzIHByZXR0 eSBtdWNoIGl0LiBGb3Igc3VwcGxpY2FudHMgcnVubmluZyBvbiBzdGFuZGFyZCBPU2VzIChXaW5k b3dzLCBNYWNPUywgaU9TLCBBbmRyb2lkKSwgdGhleSBjb3VsZCB1c2UgbG9naWMgc2ltaWxhciB0 byBDaHJvbWl1bSAod2hpY2ggeW91IG11c3QgYmUgZmFtaWxpYXIgd2l0aCBzZWVpbmcgYXMgeW91 IGhlbHBlZCB3cml0ZSBpdDogaHR0cHM6Ly9naXRodWIuY29tL2Nocm9taXVtL2Nocm9taXVtL2Nv bW1pdC8zNmYyMGU0NjUxNWFiNjFkZjRhZTRhZjk2NTViNjQ3YmY5YTBlYTVhI2RpZmYtZmE0NTVi NmU2NWFiMmFlMTlkNjQ2MzVhZGE4ODA3N2UgKSB0byBhc2sgdGhlIE9TIGlmIGEgcHJlc2VudGVk IEVBUCBjZXJ0IGlzIG9uZSBpc3N1ZWQgYnkgYSBwdWJsaWMgQ0EuIFRoaXMgZG9lcyBtZWFuIHRo YXQgdGhlIHN1cHBsaWNhbnQgaXMgYXNraW5nIGFib3V0IFdlYiBUTFMgY2VydHMgdGhhdCBCcm93 c2VycyB0cnVzdC4gSG93ZXZlciwgdGhlcmUgYXJlIGFtcGxlIGV4YW1wbGVzIGFuZCBzdXBwb3J0 IGNhc2VzIG9wZW5lZCBieSBvcGVyYXRvcnMgd2hvIGFyZSB0cnlpbmcgdG8gZG8gZXhhY3RseSB0 aGF0IOKAkyBnZXQgYSB3ZWIgUEtJIGNlcnQgZnJvbSBhIHB1YmxpYyBUTFMvQnJvd3NlciBDQSBh bmQgZGVwbG95IGl0IG9uIGFuIEVBUCBzZXJ2ZXIuIElzIHRoaXMgcmVjb21tZW5kZWQ/IE5vdCBy ZWFsbHkuIElzIGl0IHVzaW5nIGEgV2ViL1RMUyBjZXJ0IGZvciBhIHB1cnBvc2UgaXRzIG5vdCBz dHJpY3RseSBpbnRlbmRlZCBmb3I/IFllcy4gRG9lcyB0aGlzIGhhcHBlbiBpbiByZWFsIGRlcGxv eW1lbnRzPyBBYnNvbHV0ZWx5LiBIb3cgcHJldmFsZW50IGlzIGl0PyBJIGRvIG5vdCBoYXZlIHRo YXQgZGF0YS4NCg0KPiANCj4gSXMgdGhlIHN1cHBsaWNhbnQgbWFya2V0IGxpa2VseSB0byByZWFj aCB0aGF0IGNvbnNlbnN1cz8gSXQgc2VlbXMgdW5saWtlbHksDQo+IHVubGVzcyBhbmQgdW50aWwg eW91IGRlZmluZSB0aGUg4oCcdGhpbmcgZXZlcnlvbmUgY2FuIGFuZCB3YW50cyBhbmQgbmVlZHMg dG8NCj4gdmFsaWRhdGXigJ0sIGFuZCB0aGF0IHRoaW5nIGlzIGVpdGhlciBnbG9iYWxseSB1bmlx dWUgKGxpa2UgRE5TKSBvciBzdWZmaWNpZW50bHkNCj4gZG9tYWluIHNwZWNpZmljIChlLmcuIFBh c3Nwb2ludCkgdGhhdCB2ZW5kb3JzIGNhbiBhZ3JlZS4NCj4gDQoNCltvZnJpZWxdIEkgdGhpbmsg dGhlIHN1cHBsaWNhbnRzIHJ1bm5pbmcgb24gdGhlIG1haW4gT1NlcyB3b3VsZCBiZSBoYXBweSB0 byBkZWxlZ2F0ZSB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciBhIENBIGlzIGEg4oCYcHVibGljIENB 4oCZIHRvIHRoZSBPUy4gRm9yIG1hbnVmYWN0dXJlcnMgb2YgdGhpbmdzL2VtYmVkZGVkIGRldmlj ZXMvZXRjLiB0aGVuIGl0cyBjdXJyZW50bHkgdmVyeSBtdWNoIGF0IHRoZSBtYW51ZmFjdHVyZXJz IGRpc2NyZXRpb24sIGFuZCBjb25zZW5zdXMgaGVyZSB3b3VsZCBiZSB1bmxpa2VseS4NCg0KPiBJ ZiBhdCBzb21lIHBvaW50IGluIHRoZSBmdXR1cmUsIHB1YmxpYyBDQXMgYXJlIHdpbGxpbmcgdG8g aXNzdWUgY2VydHMgd2l0aCBzb21lDQo+IG9yIGFsbCBvZiB0aGUgYWJvdmUgZmllbGRzLCB0aGVu IHdoYXQgaXMgdGhlIG1pZ3JhdGlvbiBwbGFuLCB3aGF0IGRvIHdlIHRlbGwgRUFQDQo+IGNsaWVu dHMgdG8gZG8gbm93LCBhbmQgaG93IHRvIHRoZXkgbWlncmF0ZSB0aGVpciB2ZXJpZmljYXRpb24g bG9naWM/DQo+IA0KPiBUaGlzIHN0YXRlbWVudCBzaW1pbGFybHkgcmVxdWlyZXMgdW50YW5nbGlu Zy4gVGhlcmUgYXJlIOKAnHB1YmxpYyBDQXPigJ0gYXMg4oCcVGhlDQo+IHNldCBvZiBrZXlzL2Nl cnRpZmljYXRlcyB1c2VkIGZvciBhdXRoZW50aWNhdGluZyBwYXJ0aWN1bGFyIHNlcnZpY2Vz4oCd IGFuZA0KPiDigJxwdWJsaWMgQ0Fz4oCdIGFzIHRoZSBzZXQgb2Ygb3JnYW5pemF0aW9ucyB0aGF0 IG93bi9vcGVyYXRlIHRob3NlIGtleXMuDQo+IA0KPiBUaGUgY2FzZSBvZiB0aGUgZm9ybWVyIGlz IGV4dHJlbWVseSB1bmxpa2VseSwgYXMgdGhlIGluZHVzdHJ5IGlzIGFjdGl2ZWx5DQo+IG1vdmlu ZyBhd2F5IGZyb20gdGhhdCBhcHByb2FjaCB0byBQS0ksIGJ5IHRyeWluZyB0byBlbnN1cmUgc2Vw YXJhdGUga2V5cw0KPiBmb3Igc2VwYXJhdGUgdXNlIGNhc2VzIG9yIGF1dGhlbnRpY2F0aW9uIHJl YWxtcywgb2Ygd2hpY2ggRUFQIHdvdWxkIHN1cmVseQ0KPiBiZS4gDQogDQpbb2ZyaWVsXSBBbmQg YnkgdGhpcyB5b3UgbWVhbiB0aGF0IGEgcm9vdCBDQSB3aWxsIGhhdmUgZS5nLiBvbmUgaW50ZXJt ZWRpYXRlIHdpdGggRUtVcyBvZiBpZC1rcC1zZXJ2ZXJBdXRoL2lkLWtwLWNsaWVudEF1dGgsIGFu ZCBhIGRpZmZlcmVudCBpbnRlcm1lZGlhdGUgd2l0aCBhbiBFS1UgZm9yIGlkLWtwLWVtYWlsUHJv dGVjdGlvbiwgcmlnaHQ/IFRoZSBsb2dpY2FsIGV4dGVuc2lvbiBoZXJlIGZvciBFQVAgaXMgeWV0 IGFub3RoZXIgaW50ZXJtZWRpYXRlIHdpdGggYW4gRUtVIGZvciBpZC1rcC1lYXBPdmVyTEFOLg0K DQpUaGUgY2FzZSBvZiB0aGUgbGF0dGVyIGlzIGFscmVhZHkgYXZhaWxhYmxlIGZyb20gc2FpZCBv cmdhbml6YXRpb25zIGFzIHBhcnQNCj4gb2Yg4oCcbWFuYWdlZCBDQeKAnSBvciDigJxwcml2YXRl IENB4oCdIG9mZmVyaW5ncywgd2hpY2ggYXJlIG9wZXJhdGVkIGJ5IHRoYXQgcHVibGljDQo+IENB IG9yZ2FuaXphdGlvbiwgYnV0IHRoYXTigJlzIGVmZmVjdGl2ZWx5IGdyZWVuZmllbGQgYmVjYXVz ZSB5b3UgYXJlbuKAmXQgaGF2aW5nDQo+IHRvIGludGVyb3BlcmF0ZSB3aXRoIGFueSBleHRhbnQg a2V5cyBvciBjZXJ0aWZpY2F0ZSBwcm9maWxlcy4NCj4gDQoNCg0KW29mcmllbF0gUmlnaHQsIGJ1 dCBmcm9tIGEgc3VwcGxpY2FudCBwZXJzcGVjdGl2ZSAob3IgaW4gZ2VuZXJhbCBmb3IgYW55IGNs aWVudCBydW5uaW5nIG9uIGFueSBPUyBlLmcuIEJyb3dzZXIgb24gV2luZG93cyksIHRoZXJlIGlz IHplcm8gZGlmZmVyZW5jZSBiZXR3ZWVuIGFuIG9wZXJhdG9yIHdobyBkZXBsb3lzIGFuZCBydW5z IHRoZWlyIG93biBwcml2YXRlIENBLCBvciB0YWtlcyBhIGNvbnRyYWN0IG91dCB3aXRoIGEgcHVi bGljIENBIG9yZ2FuaXphdGlvbiBhbmQgZ2V0cyB0aGVtIHRvIHJ1biBhIG1hbmFnZWQvcHJpdmF0 ZSBDQSBvbiB0aGVpciBiZWhhbGYuDQoNCj4gVGhlIGlkZWFsIGV4cGVyaWVuY2Ugd291bGQgYmUg YWxvbmcgdGhlc2UgbGluZXMgZm9yIGEgY2xpZW50IHdpdGggcmVhbCB1c2VyDQo+IGludGVyYWN0 aW9uczoNCj4gLSBjbGllbnQgY29ubmVjdHMgdG8gYW4gRUFQIHNlcnZlcg0KPiAtIGNsaWVudCBw cm9tcHRzIHVzZXIgZm9yIHVzZXJJZCArIHJlYWxtIGFuZCBwYXNzd29yZA0KPiAtIGNsaWVudCB2 ZXJpZmllcyBzZXJ2ZXIgY2VydCBoYXMgaWQta3AtZWFwT3ZlckxBTiBzZXQNCj4gDQo+IFdoYXQg YXNzdXJhbmNlIGlzIHRoaXMgdG8gcHJvdmlkZT8NCg0KDQpbb2ZyaWVsXSBUbyBhc3N1cmUgdGhh dCB0aGUgY2VydCBpcyBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Ug4oCTIDgwMi4xWC9FQVAgc2Vy dmVyIGF1dGguIEp1c3QgbGlrZSBvdGhlciBUTFMvQnJvd3NlciBjbGllbnRzIGNoZWNrcyBmb3Ig aWQta3Atc2VydmVyQXV0aA0KDQo+IA0KPiAtIE5BSVJlYWxtIGluIGNlcnQgbWF0Y2hlcyB1c2Vy 4oCZcyByZWFsbQ0KPiANCj4gVGhpcyBvbmx5IHdvcmtzIGlmZiB0aGUgTkFJcyBhcmUgZ2xvYmFs bHkgdW5pcXVlIChlLmcuIG1hcCB0byBETlMpLCB3aGljaA0KPiBpbXBvc2VzIHJlcXVpcmVtZW50 cyBvbiBOQUlzIHRoYXQgYXJlbuKAmXQgcHJlc2VudCBpbiBSRkMgNzU0MiwgYW5kDQo+IHNlZW1p bmdseSBpbnRlbnRpb25hbGx5LCBjb21wYXJlZCB0byA0MjgyLg0KPiANCj4gLSB2ZXJpZnkgdGhl IGNlcnQgc2lnbmluZyBjaGFpbg0KPiANCj4gVGhlIHJlYWxpdHkgdG9kYXkgaXMgdGhhdCBpZiB0 aGUgc2VydmVyIGNlcnQgaXMgaXNzdWVkIGJ5IGEgcHVibGljIENBLCB0aGVuIGFsbCB0aGF0DQo+ IGNsaWVudCBjYW4gcmVhbGx5IGNoZWNrIGlzOg0KPiAtIGlkLWtwLXNlcnZlckF1dGggaXMgc2V0 DQo+IC0gZE5TTmFtZSBpbiBjZXJ0IG1hdGNoZXMgdXNlcuKAmXMgcmVhbG0NCj4gLSB2ZXJpZnkg dGhlIGNlcnQgc2lnbmluZyBjaGFpbg0KPiANCj4gV2Ugd291bGQgbGlrZSB0byBkb2N1bWVudCBz b21lIHJlY29tbWVuZGF0aW9ucyBmb3IgRUFQIGNsaWVudHMgYW5kIEVBUA0KPiBvcGVyYXRvcnMg c28gdGhhdCBwdWJsaWMgQ0FzIGNvdWxkIGJlIHVzZWQsIGFuZCByZWNvbW1lbmQgY2hlY2tzIGZv ciBwdWJsaWMNCj4gdnMuIHByaXZhdGUgQ0EgaXNzdWVkIEVBUCBzZXJ2ZXIgY2VydHMuDQo+IA0K PiBJZiB5b3UgbWVhbiB0aGUgc2FtZSBzZXQgb2YgQ0FzIGFuZCBrZXlzIHVzZWQgZm9yIFRMUyBi eSBjb21tb24gb3BlcmF0aW5nDQo+IHN5c3RlbXMgYW5kIGJyb3dzZXJzLCBpdCBiZWFycyBoaWdo bGlnaHRpbmcgYWdhaW46IGluZHVzdHJ5IGlzIG1vdmluZyBhd2F5DQo+IGZyb20gdGhhdC4gV2hp Y2ggaXMgdG8gc2F5IHRoYXQgY29udHJhY3RzIGFuZCByZXF1aXJlbWVudHMgZm9yIFBLSXMgdXNl ZCDigJxieQ0KPiBkZWZhdWx04oCdIGJ5IGJyb3dzZXJzIGFuZCBvcGVyYXRpbmcgc3lzdGVtcyBh cmUgYmVpbmcgZXhwbGljaXQgYWJvdXQgdGhlDQo+IG5lZWQgdG8gc2VnbWVudCBwdXJwb3NlIGFu ZCB1c2UgY2FzZSBhbmQgbm90IHVzZSBzdWNoIGNlcnRpZmljYXRlcyBmb3Igc3VjaA0KPiBwdXJw b3Nlcy4NCj4gDQoNCg0KW29mcmllbF0gSSBhZ3JlZSB0aGF0IGlkZWFsbHkgIFdlYi9UTFMgQnJv d3NlciBjZXJ0cyBzaG91bGQgbm90IHJlYWxseSBiZSB1c2VkIGJ5IG9wZXJhdG9ycyBhcyB0aGVp ciBFQVAgc2VydmVyIGlkZW50aXR5IGNlcnRzLCBob3dldmVyLCB0aGlzIGRvZXMgYWN0dWFsbHkg aGFwcGVuIHRvZGF5LiBJbiBhbiBpZGVhbCB3b3JsZCwgaXQgd291bGQgYmUgZ3JlYXQgaWYgc29t ZSBvZiB0aGUgbGFyZ2UgY29tbWVyY2lhbCAob3IgZnJlZSBlLmcuIExldHNFbmNyeXB0KSBwdWJs aWMgV2ViL1RMUyBDQXMgaGFkIGFuIGludGVybWVkaWF0ZSBzaWduaW5nIENBIHdpdGggaWQta3At ZWFwT3ZlckxBTi4gQnV0IHRvZGF5LCBhbmQgZm9yIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUsIHdo YXQgY2FuIHdlIGFkdmlzZSBzdXBwbGljYW50cyB0byBkbyBpZiB3ZSBrbm93IHRoYXQgc29tZSBv cGVyYXRvcnMgd2lsbCBwdXQgV2ViL1RMUyBpZGVudGl0eSBjZXJ0cyBmcm9tIHB1YmxpYyBDQXMg b24gdGhlaXIgRUFQIHNlcnZlcnM/DQoNCj4gQWxyZWFkeSwgVExTIGFuZCBlLW1haWwsIHRoZSB0 d28gZG9taW5hbnQgdXNlcyBvZiBQS0kgaW4gc3VjaCBzeXN0ZW1zLCBhcmUNCj4gcmVxdWlyZWQg dG8gYmUgZGlzdGluZ3Vpc2hlZCBhdCB0aGVpciBpbnRlcm1lZGlhdGUgbGV2ZWwuIEJyb3dzZXJz IGFyZSBsb29raW5nDQo+IHRvIGV4cGxpY2l0bHkgb25seSB0cnVzdCB0aGUgVExTLVdlYiBzaWRl IG9mIHRoZSBQS0ksIGFuZCBtYWtpbmcgc3VyZSB0aGF0IHRoZQ0KPiBUTFMtV2ViIFBLSSBzaWRl IGlzIGhpZ2hseSBhZ2lsZS4gT3RoZXIgY2FzZXMsIHN1Y2ggYXMgcmVzdHJpY3RlZCB1c2Ugc2Vy dmVyIHRvDQo+IHNlcnZlciBQS0kgb3IgaW5kdXN0cnkgYmVzcG9rZSBjYXNlcyAoc3VjaCBhcyBm aW5hbmNpYWwgc2VydmljZXMgb3Igc3lzdGVtDQo+IG5ldHdvcmtpbmcpIGFyZSBiZWluZyByZXN0 cmljdGVkIHRvIFBLSXMgdGhhdCBhcmVu4oCZdCBmZWRlcmF0ZWQtYnktZGVmYXVsdC4NCj4gDQo+ IEZvciBleGFtcGxlLCBYOSByZWNlbnRseSByZXZpdmVkIHRoZWlyIFBLSSBXRywgdG8gZGVmaW5l IFBLSSByZXF1aXJlbWVudHMNCj4gYXBwcm9wcmlhdGUgZm9yIGZpbmFuY2lhbCBzZXJ2aWNlcyBj dXN0b21lcnMgKGxpa2UgQVRNIHRvIGJhbmspLCBiZWNhdXNlDQo+IGZpbmFuY2lhbCBzZXJ2aWNl cyBzdHJ1Z2dsZSB0byBtb3ZlIGF0IHRoZSBzYW1lIHNwZWVkIGFzIG1vZGVybiBzb2Z0d2FyZSwN Cj4gZm9yIHVuZGVyc3RhbmRhYmxlIHJlYXNvbnMuIFRoZSB1c2Ugb2YgZG9tYWluL3B1cnBvc2Ut c3BlY2lmaWMgUEtJcyBpcw0KPiBzb21ldGhpbmcgd2UgY2FuIGFuZCBzaG91bGQgYmUgZW1icmFj aW5nIG1vcmUgb2YuDQoNCg0KW29mcmllbF0gU3VyZSwgSeKAmW0gbm90IHNheWluZyB0aGF0IGlk LWtwLWVhcE92ZXJMQU4gaXMgYSBiYWQgaWRlYSBvciB0aGF0IHN1cHBsaWNhbnRzIHNob3VsZCBu ZXZlciBsb29rIGZvciBpdC4gQnV0IGhvdyBkbyB3ZSBnZXQgdG8gdGhlIHBvaW50IHdoZXJlIHdl IGNvdWxkIGFjdHVhbGx5IGVuZm9yY2UgdGhhdCwgZ2l2ZW4gdGhhdCB0b2RheSBvcGVyYXRvcnMg ZG8gdHJ5IHRvIHVzZSBFQVAgd2l0aCBXZWIvVExTIGNlcnRzLg0KDQo+IA0KPiBJdCBzZWVtcyBs aWtlIGxvZ2ljIHNob3VsZCBiZSBzb21ldGhpbmcgbGlrZToNCj4gDQo+IC0gcmVjb21tZW5kIEVB UCBvcGVyYXRvcnMgd2l0aCBwcml2YXRlIENBIGlzc3VlZCBjZXJ0cyBvbiB0aGVpciBFQVAgc2Vy dmVycw0KPiBzZXQgaWQta3AtZWFwT3ZlckxBTiBhbmQgTkFJUmVhbG0gc2V0DQo+IC0gcmVjb21t ZW5kIEVBUCBvcGVyYXRvcnMgdXNpbmcgcHVibGljIENBcyBnZXQgRUFQIHNlcnZlciBjZXJ0cyB3 aXRoIGlkLWtwLQ0KPiBzZXJ2ZXJBdXRoIGFuZCBkTlNOYW1lIHNldA0KPiAtIHJlY29tbWVuZCBj bGllbnRzIGVuYWJsZSB0cnVzdCBpbiBwdWJsaWMgQ0FzDQo+IA0KPiBUaGlzIGlzIHdoeSBJIHN0 YXJ0ZWQgd2l0aCB0cnlpbmcgdG8gZGVmaW5lIHdoYXQg4oCccHVibGljIENBc+KAnSBhcmUuIElm IHlvdSBtZWFuDQo+IHRoZSBleHRhbnQgQ0FzIHRydXN0ZWQgYnkgYnJvd3NlcnMgYW5kIG9wZXJh dGluZyBzeXN0ZW1zLCBib3RoIHRoaXMNCj4gcmVjb21tZW5kYXRpb24gYW5kIHRoZSBvbmUgcHJv Y2VlZGluZyBpdCBtYXkgbm90IGJlIGdvb2QNCj4gcmVjb21tZW5kYXRpb25zIG9yIGxvbmctdGVy bSB2aWFibGUgcHJhY3RpY2VzLg0KDQoNCltvZnJpZWxdIFllcywgSSBtZWFuIGV4dGFudCBDQXMg dHJ1c3RlZCBieSBCcm93c2VycyBhbmQgT1Nlcy4gWWVzIHRoZSByZWNvbW1lbmRhdGlvbnMgYXMg d3JpdHRlbiBhYm92ZSB3b3VsZCBtZWFuIHVzaW5nIGEgY2VydCB3aXRoIGEgRUtVIGZvciBvbmUg cHVycG9zZSwgZm9yIGEgZGlmZmVyZW50IHB1cnBvc2UsIGJ1dCB0aGF0IGlzIHRoZSB1bmZvcnR1 bmF0ZSByZWFsaXR5LiBEbyB3ZSBpZ25vcmUgdGhlIHByb2JsZW0gYW5kIHNheSDigJhEb27igJl0 IGRvIHRoaXPigJkgb3IgZG8gd2UgdHJ5IHRvIGRvY3VtZW50IHNvbWUgY29tcHJvbWlzZSByZWNv bW1lbmRhdGlvbnMgZm9yIGJvdGggc3VwcGxpY2FudHMgYW5kIENBcywgd2l0aCBhIHJvYWRtYXAg b2YgaG93IHRvIGV2b2x2ZT8NCg0KPiANCj4gVGhhdOKAmXMgbm90IHRvIHNheSB5b3UgY291bGRu 4oCZdCwgYnV0IGl0IG1lYW5zIHlvdXIgRUFQIHNlcnZpY2VzIGFuZCBzZXJ2ZXJzDQo+IG5lZWQg dG8gYmUgcHJlcGFyZWQgdG8gYmUgYXMgYWdpbGUgYXMgdGhlIFdlYiBlY29zeXN0ZW0gaXMgYW5k IG1vZGVybg0KPiBvcGVyYXRpbmcgc3lzdGVtcyBhcmUgY29udmVyZ2luZyBvbi4gVGhlIGFiaWxp dHkgdG8gc3VwcG9ydCBvciBiZSBiZWhvbGRlbg0KPiB0byDigJxsZWdhY3nigJ0gLSB3aGV0aGVy IGFsZ29yaXRobXMsIHByb2ZpbGVzLCBvciB0cnVzdCBpbiBwYXJ0aWN1bGFyIG9yZ2FuaXphdGlv bnMgLQ0KPiBpcyBzb21ldGhpbmcgdGhhdCBpbmR1c3RyeSBpcyByZWNvZ25pemluZyBkb2VzIG5v dCBhbGlnbiB3aXRoIHVzZXIgbmVlZHMuIFRoaXMNCj4gbWVhbnMgYWRvcHRpbmcgcHJhY3RpY2Vz IGxpa2UgYXV0b21hdGlvbiwgYmVpbmcgYWJsZSB0byBxdWFudGlmeQ0KPiBjb21wYXRpYmlsaXR5 IHJpc2tzLCBhbmQgYmVpbmcgYWJsZSB0byBtb3ZlIHF1aWNrbHkgYXMgZXhwZWN0YXRpb25zIGNo YW5nZSwgaW4NCj4gcmVzcG9uc2UgdG8gZWNvc3lzdGVtIGNoYWxsZW5nZXMuDQo+IA0KDQoNCltv ZnJpZWxdIEkgaG9wZSB0aGF0IHRoaXMgcHJvYmxlbSBpcyBlYXNpZXIgdG8gdGFja2xlIGZvciBz dXBwbGljYW50cyBydW5uaW5nIG9uIHRoZSBtYWpvciBPU2VzLiBGb3IgdGhpbmdzL2VtYmVkZGVk IGRldmljZXMsIHRoaXMgaXMgYSBmYXIgaGFyZGVyIHByb2JsZW0gdG8gc29sdmUgZm9yIHN1cmUu DQoNCj4gTWF5YmUgdGhhdOKAmXMgZmluZSBmb3IgRUFQLCBidXQgSeKAmW0gd2lsbGluZyB0byBz dXNwZWN0IHRoYXQgaXQgYmVjYXVzZSB1cGRhdGVzDQo+IG1heSBpbnZvbHZlIHBoeXNpY2FsbHkg cmVwbGFjaW5nIGNsaWVudCBoYXJkd2FyZSBvciBwaHlzaWNhbGx5IGluc3RhbGxpbmcNCj4gZmly bXdhcmUsIHlvdSByZWFsbHkgZG9u4oCZdCB3YW50IEVBUCBuZWVkaW5nIHRvIGJlIGJlaG9sZGVu IHRvIHRob3NlIGFnaWxpdHkNCj4gbmVlZHMgb2YgdGhlIFdlYiBhbmQgT1Nlcy4gQW5kLCBhZ2Fp biwgdGhhdOKAmXMgcGVyZmVjdGx5IE9LLCBpdCBqdXN0IG1lYW5zDQo+IGRlZmluaW5nIGEgUEtJ IGFuZCBzZXQgb2YgcHJvY2VkdXJlcyB0aGF0IGlzIGFwcHJvcHJpYXRlIGZvciB0aGF0IHVzZSBj YXNlLCBhbmQNCj4gY29udmluY2luZyBpbmR1c3RyeSB0byBhZG9wdCBpdCBhcyBhbiDigJxvdXQg b2YgdGhlIGJveOKAnSBjb25maWd1cmF0aW9uLiBPciwNCj4gYWx0ZXJuYXRpdmVseSwgZW1icmFj aW5nIHByaXZhdGUgUEtJLg0KPiANCg0KDQpbb2ZyaWVsXSBNYXliZSBhbiBhcHByb2FjaCB0byB0 YWtlIGlzIHRvIGhhdmUgb25lIHNldCBvZiByZWNvbW1lbmRhdGlvbnMgZm9yIHN1cHBsaWNhbnQg Y2xpZW50cyBvbiBtYWpvciBPU2VzIHdoZXJlIHRoZXkgY2FuIGRlbGVnYXRlLCBhbmQgcG9zc2li bHkgcGlnZ3kgYmFjayBvbiB0b3Agb2YsIHNpbWlsYXIgT1MgZnVuY3Rpb25hbGl0eSBmb3IgV2Vi L1RMUzsgYW5kIGhhdmUgYSBkaWZmZXJlbnQgbG9vc2VyIHNldCBvZiByZWNvbW1lbmRhdGlvbnMg Zm9yIHRoaW5nIG1hbnVmYWN0dXJlcnMuIE9yIHBvc3NpYmx5IGZyYW1lIHRoZSByZXF1aXJlbWVu dHMgYXMg4oCYcmVxdWlyZW1lbnRzIHRoZSBzdXBwbGljYW50IHNob3VsZCBlbmZvcmNl4oCZIHZz LiDigJhyZXF1aXJlbWVudHMgdGhlIHN1cHBsaWNhbnQgc2hvdWxkIGRlbGVnYXRlIHRvIHRoZSBP UyAoZS5nLiBpcyB0aGlzIGEgcHVibGljIENBPynigJkuDQoNCj4gLSByZWNvbW1lbmQgY2xpZW50 cyBpbXBsZW1lbnQgZGlmZmVyZW50IGNlcnQgdmVyaWZpY2F0aW9uIGxvZ2ljIGRlcGVuZGluZyBv bg0KPiB3aGV0aGVyIHRoZSBFQVAgc2VydmVyIGNlcnQgaXMgaXNzdWVkIGJ5IGEgcHVibGljIENB IG9yIHByaXZhdGUgQ0ENCj4gDQo+IFdoeSBpcyB0aGlzIGdvb2Q/DQo+IA0KPiBUbyB0aGUgZXh0 ZW50IGJyb3dzZXJzIG9yIE9TZXMgbWFrZSB0aGlzIGRpc3RpbmN0aW9uLCBpdOKAmXMgbGFyZ2Vs eSBiYXNlZCBvbg0KPiBzaW1wbHkgcGhhc2luZyByb2xsb3V0cyBvZiBuZXcgcmVxdWlyZW1lbnRz LCB3aXRoIHRoZSBnb2FsIHRvIGV2ZW50dWFsbHkNCj4gcmVxdWlyZSBjb25zaXN0ZW50IGFuZCB1 bmlmb3JtIHRyZWF0bWVudCB0byBlbnN1cmUgc2ltcGxlciBjb2RlIHdpdGgNCj4gY29uc2lzdGVu dCBhbmQgdW5pZm9ybSBzZWN1cml0eSBwcm9wZXJ0aWVzLiBIYXZpbmcgYSBsb25nLXRlcm0gc2Vn bWVudGF0aW9uDQo+IG9mIHJlcXVpcmVtZW50cywgb3IgZXZlbiBlbmNvdXJhZ2luZyB0aGVtIHdp dGhvdXQgYSBjbGVhciB2aXNpb24gYmFjayB0bw0KPiBoYXJtb25pemF0aW9uLCBpcyBkZWZpbml0 ZWx5IGFuIGFudGktcGF0dGVybiBoZXJlLg0KDQoNCltvZnJpZWxdIENvbXBsZXRlbHkgYWdyZWUu IFdoaWNoIGlzIHdoeSBJIHN0YXRlZCBiZWxvdyDigJxhcyBhIGxvbmdlciB0ZXJtIGdvYWwgc2Vl IGlmIHB1YmxpYyBDQXMgd2lsbCBpc3N1ZSBpZC1rcC1lYXBPdmVyTEFOIGFuZCBOQUlSZWFsbeKA nQ0KDQo+IC0gZm9yIHB1YmxpYyBDQSBjZXJ0cywgY2xpZW50IGNoZWNrcyB0aGF0IGlkLWtwLXNl cnZlckF1dGggaXMgc2V0ICphbmQqDQo+IGROU05hbWUgbWF0Y2hlcyB1c2VyIHJlYWxtLiBJZiBl aXRoZXIgY2hlY2sgZmFpbHMsIHJlamVjdC4NCj4gLSBmb3IgcHJpdmF0ZSBDQSBjZXJ0cywgY2xp ZW50IGNoZWNrcyB0aGF0IGlkLWtwLXNlcnZlckF1dGggb3IgaWQta3AtDQo+IGVhcE92ZXJMQU4g aXMgc2V0ICphbmQqIE5BSVJlYWxtIG1hdGNoZXMgdXNlciByZWFsbS4uIElmIGVpdGhlciBjaGVj ayBmYWlscywNCj4gcmVqZWN0Lg0KPiANCj4gLSBhcyBhIGxvbmdlciB0ZXJtIGdvYWwgc2VlIGlm IHB1YmxpYyBDQXMgd2lsbCBpc3N1ZSBpZC1rcC1lYXBPdmVyTEFOIGFuZA0KPiBOQUlSZWFsbS4g QWx0aG91Z2ggb2YgY291cnNlIGlmIHNvbWUgd2VyZSB0byBzdGFydCBkb2luZyB0aGlzLCB0aGVu IHRoZXJlIGlzDQo+IGEgbWlncmF0aW9uIGNoYWxsZW5nZSwgYW5kIGNsaWVudHMgY2Fubm90IG1h a2UgYSBoYXJkIGNoZWNrIGZvciB0aGVzZSB2YWx1ZXMNCj4gYWdhaW5zdCBhbGwgcHVibGljIENB cy4gVGhpcyBkb2VzbuKAmXQgcmVhbGx5IHNlZW0gcHJhY3RpY2FsIGluIHRoZSBuZWFyIHRlcm0g YXQgYWxsLg0KPiANCj4gVGhlIGVmZmVjdCBvZiB0aGUgc2VwYXJhdGUgRUtVLCB3aGljaCBpcyBh Y3R1YWxseSBxdWl0ZSBkZXNpcmFibGUsIGlzIHRoYXQgaXQNCj4gZnVuY3Rpb25hbGx5IG1ha2Vz IGl0IGRpZmZpY3VsdCBmb3IgQ0FzIHRvIGlzc3VlIHRoZXNlIGNlcnRpZmljYXRlcyBmcm9tDQo+ IGludGVybWVkaWF0ZWQgdGhhdCBsYWNrIHRoaXMgRUtVIG9yIGFueSBFS1UuIEZ1cnRoZXIsIMKg Q0FzIHN1YmplY3QgdG8NCj4gYnJvd3Nlci9PUyB2ZW5kb3Igb3ZlcnNpZ2h0IGFyZSBjb25zaXN0 ZW50bHkgcmVxdWlyZWQgdG8gc2VnbWVudCBvdXQgdGhlaXINCj4gRUtVcyBhdCB0aGUgaW50ZXJt ZWRpYXRlIGxldmVsLCBhbmQgcmVxdWlyZWQgdG8gYWx3YXlzIHNwZWNpZnkgRUtVcy4NCj4gDQo+ IFRoZSBlbmQgcmVzdWx0IGlzIHRoYXQsIHRvIGFjaGlldmUgdGhpcyBsb25nIHRlcm0gZ29hbCwg eW914oCZdmUgZWZmZWN0aXZlbHkNCj4gcmVxdWlyZWQgdGhlIGVzdGFibGlzaG1lbnQgb2YgYSBu ZXcgUEtJIC0ganVzdCBhdCB0aGUgaW50ZXJtZWRpYXRlIGxldmVsDQo+IHJhdGhlciB0aGFuIHRo ZSByb290LiBBbmQgYXMgbWFueSBvZiB0aGUgcHVibGljIENBcyBjYW4gdGVsbCB5b3UsIGhhdmlu Zw0KPiByZWNlbnRseSBlbmNvdW50ZXJlZCBjaGFsbGVuZ2VzIHJlZ2FyZGluZyBub24tVExTIGlu dGVybWVkaWF0ZXMgZnJvbSByb290cw0KPiB0aGF0IGFyZSBzdWJqZWN0IHRvIGJyb3dzZXIvT1Mg b3ZlcnNpZ2h0LCBpdOKAmXMgb2Z0ZW4gZWFzaWVyIHRvIHVzZSBzZXBhcmF0ZQ0KPiByb290cyBh cyB3ZWxsLg0KPiANCj4gQWdhaW4sIEkgdGhpbmsgdGhhdOKAmXMgZGVzaXJhYmxlLCB0byBkZWZp bmUgYW4gZW50aXJlbHkgbmV3IFBLSSB3aXRoIHplcm8gb3ZlcmxhcA0KPiB3aXRoIHRoZSBzZXJ2 ZXIgYXV0aC9UTFMgUEtJIHVzZWQgYnkgT1Nlcy9icm93c2VycywgYnV0IHRoYXQgZG9lcyBjaGFu Z2UNCj4geW91ciByZWNvbW1lbmRhdGlvbnMgYW5kIGRlc2lnbiBhIGJpdCA6KSBUaGUgc2hvcnQg dGVybSByZWNvbW1lbmRhdGlvbg0KPiBiZWNvbWVzIOKAnGRvbuKAmXQgdXNlIHB1YmxpYyBDQXPi gJ0sIGFuZCB0aGF0IHNlZW1zIGVhc2llciB0byBleHBsYWluIGFuZCBlYXNpZXINCj4gdG8gZXZv bHZlIHRoZSB0ZWNobmljYWwgcmVxdWlyZW1lbnRzLCB1bnRpbCB0aGUgdGltZSB0aGF0IHN1Y2gg YSBuZXcsIEVBUC0NCj4gc3BlY2lmaWMgcHVibGljIFBLSSBjYW4gYmUgaW50cm9kdWNlZC4NCj4g DQoNCg0KW29mcmllbF0gR2V0dGluZyBwdWJsaWMgQ0FzIHRvIG1hbmFnZSBhIG5ldyBQS0kgcm9v dCAoaWYgdGhhdOKAmXMgZWFzaWVyIHRoYW4ganVzdCBhIG5ldyBpbnRlcm1lZGlhdGUpIHdpdGgg aWQta3AtZWFwT3ZlckxBTiBpcyBhIHJlYWxseSByZWFsbHkgbG9uZyByb2FkLiBBbmQgd2Uga25v dyB0aGF0IHNvbWUgb3BlcmF0b3JzIGRvIHVzZSBwdWJsaWMgV2ViL1RMUyBjZXJ0cyBhcyBFQVAg aWRlbnRpdHkgY2VydHMuIFdoaWNoIG1lYW5zIHRoYXQgd2UgY2Fubm90IHJlY29tbWVuZCBzdXBw bGljYW50cyBlbmZvcmNlIGEgY2hlY2sgZm9yIGlkLWtwLWVhcE92ZXJMQU4uDQoNClNvIGl0IGxv b2tzIGxpa2UgdGhlcmUgYXJlIHRocmVlIGNob2ljZXM6DQoxLglDb21wbGV0ZWx5IGlnbm9yZSBp ZC1rcC1lYXBPdmVyTEFOIGZvciBldmVyLg0KMi4JR2V0IHN1cHBsaWNhbnRzIHRvIGNoZWNrIGlk LWtwLWVhcE92ZXJMQU4gaWYgaXRzIG5vdCBhIHB1YmxpYyBDQSAoYW5kIHVzZSBDaHJvbWl1bSBz dHlsZSBwdWJsaWMgQ0EgZGV0ZWN0aW9uKS4gUm9sbG91dCBvZiB0aGlzIHdvdWxkIG5lZWQgdG8g YmUgY2FyZWZ1bGx5IG1hbmFnZWQgdG9vIHNvIHRoYXQgZXhpc3RpbmcgcHJpdmF0ZSBDQSBvcGVy YXRvcnMgd2hvIGRvIG5vdCBzZXQgaWQta3AtZWFwT3ZlckxBTiBkbyBub3QgYnJlYWsuDQozLglE byBub3RoaW5nIHVudGlsICBzdWZmaWNpZW50IG51bWJlcnMgb2YgcHVibGljIENBcyBzdXBwb3J0 IGlkLWtwLWVhcE92ZXJMQU4gKGluIGxpa2UgMjAzNS4uPyksIHRoZW4gY2hhbmdlIHN1cHBsaWNh bnRzIHRvIGFsd2F5cyBjaGVjayBmb3IgaWQta3AtZWFwT3ZlckxBTi4NCg0KSXRzIG5vdCBjbGVh ciB0byBtZSB3aGVyZSB0aGUgY29ycmVjdCBmb3J1bSBpcyB0byBldmVuIGRvY3VtZW50IHRoZXNl IHJlY29tbWVuZGF0aW9ucywgb3Igd2hvIG5lZWRzIHRvIGJlIGludm9sdmVkLg0KDQo+IEluIG15 IG1pbmQsIHRoaXMgaXMgbm8gZGlmZmVyZW50IGZyb20gb3JnYW5pemF0aW9ucyB0aGF0IHdhbnQg VExTIGNlcnRpZmljYXRlcw0KPiBmb3IgdGhlaXIgc2VydmVycyBuYW1lZCDigJx3ZWJtYWls4oCd IChub3QgZ2xvYmFsbHkgdW5pcXVlKSBvcg0KPiDigJxtYWlsXzAxLmNvbXBhbnkuZXhhbXBsZeKA nSAobm90IHByZWZlcnJlZCBuYW1lIGZvcm0gLyBMREgpLiBUaGUgYW5zd2VyIGlzDQo+IOKAnHVz ZSBwcml2YXRlIENBcywgZG9u4oCZdCB1c2UgcHVibGljIENBc+KAnQ0KPiANCj4gDQoNCg== From nobody Tue Jan 7 06:54:37 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE2D12003E; Tue, 7 Jan 2020 06:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 FwGd-EM1x9ZM; Tue, 7 Jan 2020 06:54:30 -0800 (PST) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33B212001A; Tue, 7 Jan 2020 06:54:29 -0800 (PST) Received: by mail-ed1-f54.google.com with SMTP id m8so50533206edi.13; Tue, 07 Jan 2020 06:54:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HxS8O+Q6cpqDzS7j9cYNc8Aeia4acuyfEKRnSEsNDRo=; b=uSkps/ZySc5swBt3nmyQhGTSBHCqyX2r1KSUTcOfSfZSE7tyQXyrO8mnRatk/E3uyg Eesaf+7Rz93Z6MKZ17k5BA1SiP7GJYPI6UJiMPMM5msri6/6LkKixudnB51HYuOowWc4 RF5tHW5gEid6YsS92af/RerOsCaoTn4HJbtyX9yv1D6Du9lhtPeL0v798PwPk+Fwo41W St+T55uMYFjKwVkl/lRL4QEWBzoSx3PydYmw8ZPR+k2Cw30KA7GlsRQgRRBRTAlLUyAL LfhusvpYguqRvyHT2M4zYZypWE7eKZxw34fomig6aapqhFB59AgCfx6HQMH1lLiLxQtO foUg== X-Gm-Message-State: APjAAAV9N+7W3O9mIurxJwil3SZCJfjCBlnDVioZsOnQfoH6SIrmrxX6 KyOX7kQj/85PHMZdedXmXTT3eafY X-Google-Smtp-Source: APXvYqxY+aDxcjD0GrH7QeeQYYliuCDOE69xPzmMu5KhBzb7Z9VIHK2w5fdTPPAYB3v610holLhyyg== X-Received: by 2002:a05:6402:1611:: with SMTP id f17mr152910edv.266.1578408866825; Tue, 07 Jan 2020 06:54:26 -0800 (PST) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com. [209.85.128.54]) by smtp.gmail.com with ESMTPSA id q13sm1199edn.2.2020.01.07.06.54.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jan 2020 06:54:26 -0800 (PST) Received: by mail-wm1-f54.google.com with SMTP id t14so19711303wmi.5; Tue, 07 Jan 2020 06:54:26 -0800 (PST) X-Received: by 2002:a1c:1d8c:: with SMTP id d134mr42080182wmd.16.1578408865982; Tue, 07 Jan 2020 06:54:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Sleevi Date: Tue, 7 Jan 2020 09:54:15 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Owen Friel (ofriel)" Cc: Ryan Sleevi , EMU WG , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c47680059b8df3c8" Archived-At: Subject: Re: [lamps] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 14:54:34 -0000 --000000000000c47680059b8df3c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Owen, While I have responses inline below, I am concerned that if I'm disagreeing so much with you, there might be some high-level impedance mismatches that we should get sorted first. At the high-level, I will say that using TLS (id-kp-serverAuth) certificates, from the intersection of CAs that are commonly trusted by operating systems and browsers, is bad. It will create security issues, will create interoperability issues, and will not help users. Conceptually, it's akin to suggesting a protocol violation, and the best thing to do with those is be strict in what you accept and break those implementations as early as possible, in the spirit of https://tools.ietf.org/html/draft-iab-protocol-maintenance . The set of CAs that are trusted for TLS on a given device, platform, or application are intrinsically tied to purpose (TLS) and the library used to implement that TLS and PKI behaviour. They are not separable, and trying to do so is a problem, not a solution. This is perhaps most obvious as vendors like Apple have tightly integrated PKI policy requirements (such as Certificate Transparency) with the capability of their TLS libraries; for several macOS/iOS releases, any application using a TLS library other than Apple's CFNetwork would be unable to successfully verify a number of certificates from CAs Apple trusted for TLS. EAP is not TLS, and your use case here is not TLS (clearly), so don't mess with TLS, or you will break, eventually. The best I can do is try to explicitly break you sooner, than later, so that I can deal with the fallout sooner than later, and not when there's a critical issue in the TLS ecosystem needing rapid resolution. At a high-level, you're still fundamentally proposing a new root store. I realize that may not be obvious, given the suggestion of intermediates with id-kp-eapOverLAN, but that's still fundamentally what's being suggested, because you still need to define a certificate profile (such as the EKU), expected policies such as how that information is validated, and a process for ensuring that validation is performed. I think that's a laudable goal, and perhaps worth pursuing, but it's important to stress that in defining a new root store, there's no reason to reuse anything extant. The fact that operating systems may trust some organizations for other purposes (TLS or S/MIME) should by no means be dispositive towards whatever you're doing. Where to best propose certificate profiles or certificate policies for that root store, I don't know, and that clearly requires a lot more implementor experience and consensus to end up with something like the CA/Browser Forum that is useful for TLS. On Tue, Jan 7, 2020 at 7:31 AM Owen Friel (ofriel) wrote= : > Thanks for the detailed reply Ryan. See line. > > > > *From:* Ryan Sleevi > *Sent:* 15 December 2019 23:43 > *To:* Owen Friel (ofriel) > *Cc:* EMU WG ; spasm@ietf.org > *Subject:* Re: [lamps] EAP/EMU recommendations for client cert validation > logic > > > > > > > > On Sun, Dec 15, 2019 at 4:01 PM Owen Friel (ofriel) > wrote: > > Hi, > > > > At ACME meeting at IETF106, the last discussion of the week was around EM= U > looking for recommendations for EAP client/peer/supplicant cert > verification logic when the client is verifying the cert that the EAP > server presents. Minutes here: > https://datatracker.ietf.org/doc/minutes-106-acme/ The recommendation > was to ask lamps. This was also discussed on EMU mailer recently. > > > > Quoting some additional background that Alan gave on EMU mailer: > > > > =E2=80=9CBackground: > > > > a) the current practice in TLS-based EAP methods is to use certificates > with "id-kp-serverAuth" OID set for Extended Key Usage. > > b) many supplicants check for this OID, and refuse to perform > authentication if it is missing > > c) supplicants do not check DNS names or any other field in the > certificates > > d) as a result of this lack of verification, supplicants ship with all > known CAs disabled for TLS-based EAP methods=E2=80=9D > > > > The key consideration is that RFCs that recommend cert fields for EAP > servers that clients should check for are not currently issued by public > CAs, and in some instances (e.g. SSID) ownership can often not be proven = by > CAs. > > > > For example: > > > > https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU > > > > https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID > > > > https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm > > > > If an EAP server operator wants to use a public CA identity cert on their > EAP server, what recommendations should we give to EAP clients so that th= e > supplicant code can handle public or private CA issued EAP server identit= y > in a secure a fashion as possible? > > > > Define =E2=80=9Cpublic CA=E2=80=9D first, and it=E2=80=99ll be clearer th= at the question is really > supplicant-specific. > > > > That is, most definitions for =E2=80=9Cpublic CAs=E2=80=9D come down to = =E2=80=9CI don=E2=80=99t want to > think about / analyze the security or validation practices of the CA, I > want my supplicant / software / hardware vendor to do it for me, against > some criteria the vendor is responsible for, and hope it all works out=E2= =80=9D. To > the extent TLS uses =E2=80=98public CAs=E2=80=99, it either boils down to= the OS or browser > vendors reaching rough (independent) consensus on who is worth trusting, = or > the vendor going along with everyone else=E2=80=99s decisions for cost (t= oo > expensive for the vendor to evaluate) or compatibility (everyone else > trusts them and it=E2=80=99d break things if the vendor doesn=E2=80=99t) = reasons. > > > > [ofriel] That=E2=80=99s pretty much it. For supplicants running on standa= rd OSes > (Windows, MacOS, iOS, Android), they could use logic similar to Chromium > (which you must be familiar with seeing as you helped write it: > https://github.com/chromium/chromium/commit/36f20e46515ab61df4ae4af9655b6= 47bf9a0ea5a#diff-fa455b6e65ab2ae19d64635ada88077e > ) to ask the OS if a presented EAP cert is one issued by a public CA. Thi= s > does mean that the supplicant is asking about Web TLS certs that Browsers > trust. However, there are ample examples and support cases opened by > operators who are trying to do exactly that =E2=80=93 get a web PKI cert = from a > public TLS/Browser CA and deploy it on an EAP server. Is this recommended= ? > Not really. Is it using a Web/TLS cert for a purpose its not strictly > intended for? Yes. Does this happen in real deployments? Absolutely. How > prevalent is it? I do not have that data. > I'm not really sure what you're trying to suggest here, and I'm not really sure why you mentioned the code in relation to the question. The problem still remains: you haven't defined public CAs in any interoperable sense, and I think that's relevant to the discussion in the IETF, if you want to get interoperable implementations. I also think it's misguided and misunderstands the code you referenced. That code is to explicitly reject things that might otherwise be valid, so that it fails early and isn't accepted, even if there might be reasons to allow it. If the suggestion is that EAP supplicants should explicitly reject anything from common TLS-trusted CAs (including from any intermediates they issue, regardless of key policies), I wholeheartedly agree with that, but I'm under the impression you're suggesting the exact opposite. > > > Is the supplicant market likely to reach that consensus? It seems > unlikely, unless and until you define the =E2=80=9Cthing everyone can and= wants and > needs to validate=E2=80=9D, and that thing is either globally unique (lik= e DNS) or > sufficiently domain specific (e.g. Passpoint) that vendors can agree. > > > > [ofriel] I think the supplicants running on the main OSes would be happy > to delegate the question of whether a CA is a =E2=80=98public CA=E2=80=99= to the OS. For > manufacturers of things/embedded devices/etc. then its currently very muc= h > at the manufacturers discretion, and consensus here would be unlikely. > I'm afraid this side-steps the question for the "main OSes" that everyone would be happy with: they still need to make a decision, and so you're still back to manufacturer's discretion, and thus back to a lack of consensus without a clearly defined problem statement, and this answer has solved and clarified nothing. Even if you 'want' to handwave to the OS, the OS vendor still has to make a decision, just like the embedded devices do. And for that, it needs a clear problem statement. > > > If at some point in the future, public CAs are willing to issue certs wit= h > some or all of the above fields, then what is the migration plan, what do > we tell EAP clients to do now, and how to they migrate their verification > logic? > > > > This statement similarly requires untangling. There are =E2=80=9Cpublic C= As=E2=80=9D as > =E2=80=9CThe set of keys/certificates used for authenticating particular = services=E2=80=9D > and =E2=80=9Cpublic CAs=E2=80=9D as the set of organizations that own/ope= rate those keys. > > > > The case of the former is extremely unlikely, as the industry is actively > moving away from that approach to PKI, by trying to ensure separate keys > for separate use cases or authentication realms, of which EAP would surel= y > be. > > > > [ofriel] And by this you mean that a root CA will have e.g. one > intermediate with EKUs of id-kp-serverAuth/id-kp-clientAuth, and a > different intermediate with an EKU for id-kp-emailProtection, right? The > logical extension here for EAP is yet another intermediate with an EKU fo= r > id-kp-eapOverLAN. > In a sense, yes, but I don't think it goes far enough, and I think it misses the problem I was trying to highlight, which is that this means separate _roots_ for id-kp-eapOverLAN. Separating at the intermediate is happening, but equally, separating at the root is happening, and in fact more preferable. We've explicitly rejected CA applications that use an intermediate level separation, because the organizational and operational considerations are too great for folks to effectively manage. We're not the only vendor working through problems like this - https://wiki.mozilla.org/CA/Audit_Letter_Validation is an entire system developed jointly with Mozilla and Microsoft trying to work through these issues, where CAs 'intended' to separate out the intermediates but failed to do so correctly. It's a flawed design, a flawed system, and with significantly more operational overhead than simply separating at the root. We see this in new systems, which purpose-build root hierarchies, like Passpoint or Wireless Power/Qi or "Made for Apple iPhone". The point is that the *entire* hierarchy is separate, and not just branches, because that's seemingly the only practically effective way to manage PKI at Internet scale. > The case of the latter is already available from said organizations as > part of =E2=80=9Cmanaged CA=E2=80=9D or =E2=80=9Cprivate CA=E2=80=9D offe= rings, which are operated by that > public CA organization, but that=E2=80=99s effectively greenfield because= you > aren=E2=80=99t having to interoperate with any extant keys or certificate= profiles. > > > > [ofriel] Right, but from a supplicant perspective (or in general for any > client running on any OS e.g. Browser on Windows), there is zero differen= ce > between an operator who deploys and runs their own private CA, or takes a > contract out with a public CA organization and gets them to run a > managed/private CA on their behalf. > Perhaps you could rephrase this, because I think I disagree with about every interpretation I can come to, but I don't want to waste your time if I'm misunderstanding :) > The ideal experience would be along these lines for a client with real > user interactions: > > - client connects to an EAP server > > - client prompts user for userId + realm and password > > - client verifies server cert has id-kp-eapOverLAN set > > > > What assurance is this to provide? > > > > [ofriel] To assure that the cert is for the intended purpose =E2=80=93 80= 2.1X/EAP > server auth. Just like other TLS/Browser clients checks for > id-kp-serverAuth. > That's a tautological definition though. The intended purpose is the intended purpose. This question is trying to pose "What is the information or policy that is validated". As clarified later on, you've got at least the "NAI realm is appropriately unique", which in this case means matches to DNS. "Intended for 802.1X" doesn't seem correct, though, because that would similarly imply that no extant TLS CA would issue certificates used in EAP, because every CA would be verifying "intended for TLS server authentication", and that's clearly not the case when used with EAP. > If you mean the same set of CAs and keys used for TLS by common operating > systems and browsers, it bears highlighting again: industry is moving awa= y > from that. Which is to say that contracts and requirements for PKIs used > =E2=80=9Cby default=E2=80=9D by browsers and operating systems are being = explicit about the > need to segment purpose and use case and not use such certificates for su= ch > purposes. > > > > [ofriel] I agree that ideally Web/TLS Browser certs should not really be > used by operators as their EAP server identity certs, however, this does > actually happen today. In an ideal world, it would be great if some of th= e > large commercial (or free e.g. LetsEncrypt) public Web/TLS CAs had an > intermediate signing CA with id-kp-eapOverLAN. > No, this would be bad. > But today, and for the foreseeable future, what can we advise supplicants > to do if we know that some operators will put Web/TLS identity certs from > public CAs on their EAP servers? > If you know it's a TLS certificate, reject it. If it has id-kp-serverAuth, reject it. If it comes from a Root CA you know is or has been trusted for TLS, reject it. If it has not been explicitly configured by local policy to accept it, reject it. Are there existing certificates that will be rejected? Yes. Replace them. > This is why I started with trying to define what =E2=80=9Cpublic CAs=E2= =80=9D are. If you > mean the extant CAs trusted by browsers and operating systems, both this > recommendation and the one proceeding it may not be good recommendations = or > long-term viable practices. > > > > [ofriel] Yes, I mean extant CAs trusted by Browsers and OSes. Yes the > recommendations as written above would mean using a cert with a EKU for o= ne > purpose, for a different purpose, but that is the unfortunate reality. Do > we ignore the problem and say =E2=80=98Don=E2=80=99t do this=E2=80=99 or = do we try to document some > compromise recommendations for both supplicants and CAs, with a roadmap o= f > how to evolve? > Supplicants should break this case as soon as possible, because it _will_ break, and it's better to have it break within a maintenance cycle when you're prepared for breakage and migrating than one day waking up and finding it's all broken. The least deliberate form of breakage is the status quo, which is to require explicit configuration of the trust anchors and hand-wave the rest. Somewhere in the middle you have things like vendor-flag-days (i.e. this vendor requires id-kp-eapOverLan in it's new software for all certificates issued after that supplicant's release date) At the most deliberate, you have folks borrowing from that Chromium code / maintaining a list of every CA that has been used for / trusted for TLS, and explicitly rejecting/preventing certificates from them. I doubt we'll find consensus on where the 'ideal' answer is, since every vendor will have to weigh their own risks, but in no circumstances should folks use TLS CAs. > That=E2=80=99s not to say you couldn=E2=80=99t, but it means your EAP ser= vices and servers > need to be prepared to be as agile as the Web ecosystem is and modern > operating systems are converging on. The ability to support or be beholde= n > to =E2=80=9Clegacy=E2=80=9D - whether algorithms, profiles, or trust in p= articular > organizations - is something that industry is recognizing does not align > with user needs. This means adopting practices like automation, being abl= e > to quantify compatibility risks, and being able to move quickly as > expectations change, in response to ecosystem challenges. > > > > [ofriel] I hope that this problem is easier to tackle for supplicants > running on the major OSes. For things/embedded devices, this is a far > harder problem to solve for sure. > Only to the extent the supplicant is integrated in the OS, much the way the TLS library and PKI store are integrated. For anything else, such as 3P supplicants, it remains an equally hard problem. > [ofriel] Getting public CAs to manage a new PKI root (if that=E2=80=99s e= asier > than just a new intermediate) with id-kp-eapOverLAN is a really really lo= ng > road. And we know that some operators do use public Web/TLS certs as EAP > identity certs. Which means that we cannot recommend supplicants enforce = a > check for id-kp-eapOverLAN. > > > > So it looks like there are three choices: > > 1. Completely ignore id-kp-eapOverLAN for ever. > 2. Get supplicants to check id-kp-eapOverLAN if its not a public CA > (and use Chromium style public CA detection). Rollout of this would ne= ed to > be carefully managed too so that existing private CA operators who do = not > set id-kp-eapOverLAN do not break. > 3. Do nothing until sufficient numbers of public CAs support > id-kp-eapOverLAN (in like 2035..?), then change supplicants to always = check > for id-kp-eapOverLAN. > > These are all bad options. Look, any clients expecting id-kp-serverAuth are broken now. They just don't realize it, they're walking timebombs, and the answer is to fix them. Vendors can and should be more explicit in this, by checking id-kp-eapOverLan, because they're going to eat the incompatibility at some point. Better to pay for that pain now, rather than continue to defer it and hope nothing goes wrong. I mentioned above, there's a spectrum of options for how to phase that in. To explicitly reiterate #2: The implementation in Chromium very intentionally does not *grant* capabilities based on that list, it *removes* capabilities and makes code *more* strict. That is the only reasonable use for such a list, and even then, it's problematic (e.g. if the list is out of date, newcomers have advantages over incumbents). That list has a host of other caveats, and why Chromium is moving to explicitly rid itself of that list and has been. I appreciate the shout-out, but this is very much a situation of using the list exactly opposite as intended :) > --000000000000c47680059b8df3c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Owen,

While I have = responses inline below, I am concerned that if I'm disagreeing so much = with you, there might be some high-level impedance=C2=A0mismatches that we = should get sorted first.

At the high-level, I will= say that using TLS (id-kp-serverAuth) certificates, from the intersection = of CAs that are commonly trusted by operating systems and browsers, is bad.= It will create security issues, will create interoperability issues, and w= ill not help users. Conceptually, it's akin to suggesting a protocol vi= olation, and the best thing to do with those is be strict in what you accep= t and break those implementations as early as possible, in the spirit of=C2= =A0h= ttps://tools.ietf.org/html/draft-iab-protocol-maintenance=C2=A0.=C2=A0<= /div>

The set of CAs that are trusted for TLS on a given= device, platform, or application are intrinsically tied to purpose (TLS) a= nd the library used to implement that TLS and PKI behaviour. They are not s= eparable, and trying to do so is a problem, not a solution. This is perhaps= most obvious as vendors like Apple have tightly integrated PKI policy requ= irements (such as Certificate Transparency) with the capability of their TL= S libraries; for several macOS/iOS releases, any application using a TLS li= brary other than Apple's CFNetwork would be unable to successfully veri= fy a number of certificates from CAs Apple trusted for TLS.

<= /div>
EAP is not TLS, and your use case here is not TLS (clearly), so d= on't mess with TLS, or you will break, eventually. The best I can do is= try to explicitly break you sooner, than later, so that I can deal with th= e fallout sooner than later, and not when there's a critical issue in t= he TLS ecosystem needing rapid resolution.

At a hi= gh-level, you're still fundamentally proposing a new root store. I real= ize that may not be obvious, given the suggestion of intermediates with id-= kp-eapOverLAN, but that's still fundamentally what's being suggeste= d, because you still need to define a certificate profile (such as the EKU)= , expected policies such as how that information is validated, and a proces= s for ensuring that validation is performed. I think that's a laudable = goal, and perhaps worth pursuing, but it's important to stress that in = defining a new root store, there's no reason to reuse anything extant. = The fact that operating systems may trust some organizations for other purp= oses (TLS or S/MIME) should by no means be dispositive towards whatever you= 're doing. Where to best propose certificate profiles or certificate po= licies for that root store, I don't know, and that clearly requires a l= ot more implementor experience and consensus to end up with something like = the CA/Browser Forum that is useful for TLS.

On Tue, Jan 7, 2020 at 7:= 31 AM Owen Friel (ofriel) <ofriel@ci= sco.com> wrote:

Thanks for the detailed reply Ryan. See line.<= u>

=C2=A0

F= rom: Ryan Sleevi <ryan-ietf@sleevi.com>
Sent: 15 December 2019 23:43
To: Owen Friel (ofriel) <ofriel@cisco.com>
Cc: EMU WG <emu= @ietf.org>; spas= m@ietf.org
Subject: Re: [lamps] EAP/EMU recommendations for client cert validat= ion logic

=C2=A0

=C2=A0

=C2=A0

On Sun, Dec 15, 2019 at 4= :01 PM Owen Friel (ofriel) <ofriel@cisco.com> wrote:

Hi,

=C2=A0

At ACME meeting at IETF106, the last discussion of the week was around EMU = looking for recommendations for EAP client/peer/supplicant cert verificatio= n logic when the client is verifying the cert that the EAP server presents.= Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/=C2=A0 The reco= mmendation was to ask lamps. This was also discussed on EMU mailer recently= .

=C2=A0

Quoting some additional background that Alan gave on EMU mailer:<= /u>

=C2=A0

=E2=80=9CBackground:

=C2=A0

a) the current practice in TLS-based EAP meth= ods is to use certificates with "id-kp-serverAuth" OID set for Ex= tended Key Usage.

b) many supplicants check for this OID, and r= efuse to perform authentication if it is missing

c) supplicants do not check DNS names or any = other field in the certificates

d) as a result of this lack of verification, = supplicants ship with all known CAs disabled for TLS-based EAP methods=E2= =80=9D

=C2=A0

The key consideration is that RFCs that recommend cert fields for EAP serve= rs that clients should check for are not currently issued by public CAs, an= d in some instances (e.g. SSID) ownership can often not be proven by CAs.

=C2=A0

For example:

=C2=A0

https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU<= /u>

=C2=A0

https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID=

=C2=A0

https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm

=C2=A0

If an EAP server operator wants to use a public CA identity cert on their E= AP server, what recommendations should we give to EAP clients so that the s= upplicant code can handle public or private CA issued EAP server identity i= n a secure a fashion as possible?

=C2=A0

Define =E2=80=9Cpublic CA= =E2=80=9D first, and it=E2=80=99ll be clearer that the question is really s= upplicant-specific.

=C2=A0

That is, most definitions= for =E2=80=9Cpublic CAs=E2=80=9D come down to =E2=80=9CI don=E2=80=99t wan= t to think about / analyze the security or validation practices of the CA, = I want my supplicant / software / hardware vendor to do it for me, against some criteria the vendor is responsible for, and hope it all works= out=E2=80=9D. To the extent TLS uses =E2=80=98public CAs=E2=80=99, it eith= er boils down to the OS or browser vendors reaching rough (independent) con= sensus on who is worth trusting, or the vendor going along with everyone else=E2=80=99s decisions for cost (too expensive for the ven= dor to evaluate) or compatibility (everyone else trusts them and it=E2=80= =99d break things if the vendor doesn=E2=80=99t) reasons.

=C2=A0

[ofriel] That=E2=80=99s pretty much it. For supplica= nts running on standard OSes (Windows, MacOS, iOS, Android), they could use= logic similar to Chromium (which you must be familiar with seeing as you h= elped write it: https://github.com/chromium/chromium/commit/36f20e46515ab61df4ae4af9655b647= bf9a0ea5a#diff-fa455b6e65ab2ae19d64635ada88077e ) to ask the OS if a pr= esented EAP cert is one issued by a public CA. This does mean that the supp= licant is asking about Web TLS certs that Browsers trust. However, there are ample examples and support cases o= pened by operators who are trying to do exactly that =E2=80=93 get a web PK= I cert from a public TLS/Browser CA and deploy it on an EAP server. Is this= recommended? Not really. Is it using a Web/TLS cert for a purpose its not strictly intended for? Yes. Does this h= appen in real deployments? Absolutely. How prevalent is it? I do not have t= hat data.


I'm not really sure what you're trying to suggest here, and I'= m not really sure why you mentioned the code in relation to the question.

The problem still remains: you haven't defined = public CAs in any interoperable sense, and I think that's relevant to t= he discussion in the IETF, if you want to get interoperable implementations= .

I also think it's misguided and misunderstan= ds the code you referenced. That code is to explicitly reject things that m= ight otherwise be valid, so that it fails early and isn't accepted, eve= n if there might be reasons to allow it. If the suggestion is that EAP supp= licants should explicitly reject anything from common TLS-trusted CAs (incl= uding from any intermediates they issue, regardless of key policies), I who= leheartedly agree with that, but I'm under the impression you're su= ggesting the exact opposite.=C2=A0
=C2=A0

=C2=A0

Is the supplicant market = likely to reach that consensus? It seems unlikely, unless and until you def= ine the =E2=80=9Cthing everyone can and wants and needs to validate=E2=80= =9D, and that thing is either globally unique (like DNS) or sufficiently domain specific (e.g. Passpoint) that vendors can agr= ee.

=C2=A0

[ofriel] I think the supplicants running on the main= OSes would be happy to delegate the question of whether a CA is a =E2=80= =98public CA=E2=80=99 to the OS. For manufacturers of things/embedded devic= es/etc. then its currently very much at the manufacturers discretion, and consensus here would be unlikely.


I'm afraid this side-steps th= e question for the "main OSes" that everyone would be happy with:= they still need to make a decision, and so you're still back to manufa= cturer's discretion, and thus back to a lack of consensus without a cle= arly defined problem statement, and this answer has solved and clarified no= thing. Even if you 'want' to handwave to the OS, the OS vendor stil= l has to make a decision, just like the embedded devices do. And for that, = it needs a clear problem statement.
=C2=A0

<= /u>

=C2=A0

If at some point in the future, public CAs are willing to issue certs with = some or all of the above fields, then what is the migration plan, what do w= e tell EAP clients to do now, and how to they migrate their verification lo= gic?

=C2=A0

This statement similarly = requires untangling. There are =E2=80=9Cpublic CAs=E2=80=9D as =E2=80=9CThe= set of keys/certificates used for authenticating particular services=E2=80= =9D and =E2=80=9Cpublic CAs=E2=80=9D as the set of organizations that own/o= perate those keys.

=C2=A0

The case of the former is= extremely unlikely, as the industry is actively moving away from that appr= oach to PKI, by trying to ensure separate keys for separate use cases or au= thentication realms, of which EAP would surely be.

=C2=A0

[ofriel] And by this you mean that a root CA will ha= ve e.g. one intermediate with EKUs of id-kp-serverAuth/id-kp-clientAuth, an= d a different intermediate with an EKU for id-kp-emailProtection, right? Th= e logical extension here for EAP is yet another intermediate with an EKU for id-kp-eapOverLAN.

=

In a sense, yes, but I d= on't think it goes far enough, and I think it misses the problem I was = trying to highlight, which is that this means separate _roots_ for id-kp-ea= pOverLAN.

Separating at the intermediate is happen= ing, but equally, separating at the root is happening, and in fact more pre= ferable. We've explicitly rejected CA applications that use an intermed= iate level separation, because the organizational and operational considera= tions are too great for folks to effectively manage. We're not the only= vendor working through problems like this -=C2=A0https://wiki.mozilla.org/CA/Audit_Le= tter_Validation=C2=A0is an entire system developed jointly with Mozilla= and Microsoft trying to work through these issues, where CAs 'intended= ' to separate out the intermediates but failed to do so correctly. It&#= 39;s a flawed design, a flawed system, and with significantly more operatio= nal overhead than simply separating at the root.

W= e see this in new systems, which purpose-build root hierarchies, like Passp= oint or Wireless Power/Qi or "Made for Apple iPhone". The point i= s that the *entire* hierarchy is separate, and not just branches, because t= hat's seemingly the only practically effective way to manage PKI at Int= ernet scale.


The case of the latter is= already available from said organizations as part of =E2=80=9Cmanaged CA= =E2=80=9D or =E2=80=9Cprivate CA=E2=80=9D offerings, which are operated by = that public CA organization, but that=E2=80=99s effectively greenfield beca= use you aren=E2=80=99t having to interoperate with any extant keys or certific= ate profiles.

=C2=A0

[ofriel] Right, but from a supplicant perspective (o= r in general for any client running on any OS e.g. Browser on Windows), the= re is zero difference between an operator who deploys and runs their own pr= ivate CA, or takes a contract out with a public CA organization and gets them to run a managed/private CA on= their behalf.


Perhaps you could rephrase this, because I think I disagree with abou= t every interpretation I can come to, but I don't want to waste your ti= me if I'm misunderstanding :)
=C2=A0

The ideal experience would be along these lines for a client with real user= interactions:

- client connects to an EAP server

- client prompts user for userId + realm and password

- client verifies server cert has id-kp-eapOverLAN set

=C2=A0

What assurance is this to= provide?

=C2=A0

[ofriel] To assure that the cert is for the intended= purpose =E2=80=93 802.1X/EAP server auth. Just like other TLS/Browser clie= nts checks for id-kp-serverAuth.


That's a tautological definition though. The in= tended purpose is the intended purpose.

This quest= ion is trying to pose "What is the information or policy that is valid= ated". As clarified later on, you've got at least the "NAI re= alm is appropriately unique", which in this case means matches to DNS.= "Intended for 802.1X" doesn't seem correct, though, because = that would similarly imply that no extant TLS CA would issue certificates u= sed in EAP, because every CA would be verifying "intended for TLS serv= er authentication", and that's clearly not the case when used with= EAP.
=C2=A0

If you mean the same set = of CAs and keys used for TLS by common operating systems and browsers, it b= ears highlighting again: industry is moving away from that. Which is to say= that contracts and requirements for PKIs used =E2=80=9Cby default=E2=80=9D by browsers and operating systems a= re being explicit about the need to segment purpose and use case and not us= e such certificates for such purposes.

=C2=A0

[ofriel] I agree that ideally =C2=A0Web/TLS Browser = certs should not really be used by operators as their EAP server identity c= erts, however, this does actually happen today. In an ideal world, it would= be great if some of the large commercial (or free e.g. LetsEncrypt) public Web/TLS CAs had an intermediate signing = CA with id-kp-eapOverLAN.


No, this would be bad.
=C2=A0

But today, and for the foreseeable future, what can we advise supplicants = to do if we know that some operators will put Web/TLS identity certs from p= ublic CAs on their EAP servers?

<= br>
If you know it's a TLS certificate, reject it.
= If it has id-kp-serverAuth, reject it.
If it comes from a Root CA= you know is or has been trusted for TLS, reject it.
If it has no= t been explicitly configured by local policy to accept it, reject it.
=

Are there existing certificates that will be rejected? = Yes. Replace them.
=C2=A0

This is why I started wit= h trying to define what =E2=80=9Cpublic CAs=E2=80=9D are. If you mean the e= xtant CAs trusted by browsers and operating systems, both this recommendati= on and the one proceeding it may not be good recommendations or long-term via= ble practices.

=C2=A0

[ofriel] Yes, I mean extant CAs trusted by Browsers = and OSes. Yes the recommendations as written above would mean using a cert = with a EKU for one purpose, for a different purpose, but that is the unfort= unate reality. Do we ignore the problem and say =E2=80=98Don=E2=80=99t do this=E2=80=99 or do we try to document s= ome compromise recommendations for both supplicants and CAs, with a roadmap= of how to evolve?


<= /div>
Supplicants should break this case as soon as possible, because i= t _will_ break, and it's better to have it break within a maintenance c= ycle when you're prepared for breakage and migrating than one day wakin= g up and finding it's all broken.

The least de= liberate form of breakage is the status quo, which is to require explicit c= onfiguration of the trust anchors and hand-wave the rest.
Somewhe= re in the middle you have things like vendor-flag-days (i.e. this vendor re= quires id-kp-eapOverLan in it's new software for all certificates issue= d after that supplicant's release date)
At the most deliberat= e, you have folks borrowing from that Chromium code / maintaining a list of= every CA that has been used for / trusted for TLS, and explicitly rejectin= g/preventing certificates from them.

I doubt we= 9;ll find consensus on where the 'ideal' answer is, since every ven= dor will have to weigh their own risks, but in no circumstances should folk= s use TLS CAs.
=C2=A0

That=E2=80=99s not to say you couldn=E2=80=99= t, but it means your EAP services and servers need to be prepared to be as = agile as the Web ecosystem is and modern operating systems are converging on. The ability to support or be beholden to =E2=80= =9Clegacy=E2=80=9D - whether algorithms, profiles, or trust in particular o= rganizations - is something that industry is recognizing does not align wit= h user needs. This means adopting practices like automation, being able to quantify compatibility risks, and being able to = move quickly as expectations change, in response to ecosystem challenges.

=C2=A0

[ofriel] I hope that this problem is easier to tackl= e for supplicants running on the major OSes. For things/embedded devices, t= his is a far harder problem to solve for sure.

<= /div>

Only to the extent the supplicant is = integrated in the OS, much the way the TLS library and PKI store are integr= ated. For anything else, such as 3P supplicants, it remains an equally hard= problem.
=C2=A0

[ofriel] Getting public CAs to manage a new PKI root= (if that=E2=80=99s easier than just a new intermediate) with id-kp-eapOver= LAN is a really really long road. And we know that some operators do use pu= blic Web/TLS certs as EAP identity certs. Which means that we cannot recommend supplicants enforce a check for id-kp= -eapOverLAN.

=C2=A0

So it looks like there are three choices:<= /u>

  1. Completely ignore id-kp-eapOverLAN for ever.
    2. Get supplicants to check id-kp-eapOverLAN if its not a public CA (and= use Chromium style public CA detection). Rollout of this would need to be = carefully managed too so that existing private CA operators who do not set id-kp-eapOverLAN do not break.<= u>
  2. Do nothing until =C2=A0sufficient numbers of public CA= s support id-kp-eapOverLAN (in like 2035..?), then change supplicants to al= ways check for id-kp-eapOverLAN.

These are all bad options.

Look, any clients expecting id-kp-serverAuth are broken now. They ju= st don't realize it, they're walking timebombs, and the answer is t= o fix them. Vendors can and should be more explicit in this, by checking id= -kp-eapOverLan, because they're going to eat the incompatibility at som= e point. Better to pay for that pain now, rather than continue to defer it = and hope nothing goes wrong. I mentioned above, there's a spectrum of o= ptions for how to phase that in.

To explicitly rei= terate #2: The implementation in Chromium very intentionally does not *gran= t* capabilities based on that list, it *removes* capabilities and makes cod= e *more* strict. That is the only reasonable use for such a list, and even = then, it's problematic (e.g. if the list is out of date, newcomers have= advantages over incumbents). That list has a host of other caveats, and wh= y Chromium is moving to explicitly rid itself of that list and has been. I = appreciate the shout-out, but this is very much a situation of using the li= st exactly opposite as intended :)
--000000000000c47680059b8df3c8-- From nobody Tue Jan 7 07:00:55 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC7212003E for ; Tue, 7 Jan 2020 07:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 ORQJqrtw0Jh7 for ; Tue, 7 Jan 2020 07:00:48 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC1B12001A for ; Tue, 7 Jan 2020 07:00:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 163B4300ABE for ; Tue, 7 Jan 2020 10:00:46 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id V9p5FXYwhqx4 for ; Tue, 7 Jan 2020 10:00:45 -0500 (EST) Received: from [5.5.33.11] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 19F45300A2F for ; Tue, 7 Jan 2020 10:00:45 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 7 Jan 2020 10:00:45 -0500 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> Message-Id: <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 15:00:50 -0000 There are two CMP-related documents: - draft-brockhaus-lamps-cmp-updates - draft-brockhaus-lamps-lightweight-cmp-profile Please indicate whether you support adoption of zero, one, or both of = these documents by the LAMPS WG. Please respond before January 22nd. Russ From nobody Tue Jan 7 07:22:37 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49B412008C; Tue, 7 Jan 2020 07:22:27 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Zx0QofIsLyUS; Tue, 7 Jan 2020 07:22:23 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D6112003E; Tue, 7 Jan 2020 07:22:23 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 627C75F8; Tue, 7 Jan 2020 15:22:19 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Tue, 7 Jan 2020 10:22:17 -0500 Cc: Ryan Sleevi , "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 15:22:29 -0000 On Jan 7, 2020, at 8:53 AM, Owen Friel (ofriel) = wrote: > [ofriel] That=E2=80=99s pretty much it. For supplicants running on = standard OSes (Windows, MacOS, iOS, Android), they could use logic = similar to Chromium (which you must be familiar with seeing as you = helped write it: = https://github.com/chromium/chromium/commit/36f20e46515ab61df4ae4af9655b64= 7bf9a0ea5a#diff-fa455b6e65ab2ae19d64635ada88077e ) to ask the OS if a = presented EAP cert is one issued by a public CA. This does mean that the = supplicant is asking about Web TLS certs that Browsers trust. However, = there are ample examples and support cases opened by operators who are = trying to do exactly that =E2=80=93 get a web PKI cert from a public = TLS/Browser CA and deploy it on an EAP server. Is this recommended? Not = really. Is it using a Web/TLS cert for a purpose its not strictly = intended for? Yes. Does this happen in real deployments? Absolutely. How = prevalent is it? I do not have that data. So far as I know, every EAP supplicant checks for the id-kp-serverAuth = OID. So yes, *all* EAP supplicants check that the certificate presented = by the EAP server is valid for TLS web servers. That seems wrong. But it's what people do. > [ofriel] I agree that ideally Web/TLS Browser certs should not really = be used by operators as their EAP server identity certs, however, this = does actually happen today. In an ideal world, it would be great if some = of the large commercial (or free e.g. LetsEncrypt) public Web/TLS CAs = had an intermediate signing CA with id-kp-eapOverLAN. But today, and for = the foreseeable future, what can we advise supplicants to do if we know = that some operators will put Web/TLS identity certs from public CAs on = their EAP servers? Not "some", but "all". > [ofriel] Getting public CAs to manage a new PKI root (if that=E2=80=99s = easier than just a new intermediate) with id-kp-eapOverLAN is a really = really long road. And we know that some operators do use public Web/TLS = certs as EAP identity certs. Which means that we cannot recommend = supplicants enforce a check for id-kp-eapOverLAN. >=20 > So it looks like there are three choices: > 1. Completely ignore id-kp-eapOverLAN for ever. > 2. Get supplicants to check id-kp-eapOverLAN if its not a public CA = (and use Chromium style public CA detection). Rollout of this would need = to be carefully managed too so that existing private CA operators who do = not set id-kp-eapOverLAN do not break. > 3. Do nothing until sufficient numbers of public CAs support = id-kp-eapOverLAN (in like 2035..?), then change supplicants to always = check for id-kp-eapOverLAN. I think there should be continued discussion about what is the end = goal, and how we can get there. Once those issues are defined, then = it's simpler to fix the supplicants. > Its not clear to me where the correct forum is to even document these = recommendations, or who needs to be involved. The Wi-Fi alliance is already moving ahead with a similar approach. = https://www.wi-fi.org/download.php?file=3D/sites/default/files/private/WPA= 3_Specification_v2.0.pdf See Section 5, page 10. A shorter description is here: = http://lists.freeradius.org/pipermail/freeradius-users/2019-December/09708= 0.html Alan DeKok. From nobody Tue Jan 7 08:44:16 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3284112012A; Tue, 7 Jan 2020 08:44: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Phw-urENhZdM; Tue, 7 Jan 2020 08:44:04 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F774120052; Tue, 7 Jan 2020 08:44:02 -0800 (PST) Received: from [192.168.20.201] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id 6D8B8B79; Tue, 7 Jan 2020 16:44:00 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Tue, 7 Jan 2020 11:43:59 -0500 Cc: "Owen Friel (ofriel)" , "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:44:08 -0000 On Jan 7, 2020, at 9:54 AM, Ryan Sleevi wrote: > At the high-level, I will say that using TLS (id-kp-serverAuth) = certificates, from the intersection of CAs that are commonly trusted by = operating systems and browsers, is bad. It will create security issues, = will create interoperability issues, and will not help users. It's been accepted practice in all EAP implementations for ~15 years. = Are there practical issues you're aware of? Because I can't recall = seeing any. Any security issues are limited. If a site administrator has access = to the public / private keys for a web server, it's possible to re-use = those certs for EAP. This re-use cannot be prevented. > The set of CAs that are trusted for TLS on a given device, platform, = or application are intrinsically tied to purpose (TLS) and the library = used to implement that TLS and PKI behaviour. They are not separable, = and trying to do so is a problem, not a solution. This is perhaps most = obvious as vendors like Apple have tightly integrated PKI policy = requirements (such as Certificate Transparency) with the capability of = their TLS libraries; for several macOS/iOS releases, any application = using a TLS library other than Apple's CFNetwork would be unable to = successfully verify a number of certificates from CAs Apple trusted for = TLS. >=20 > EAP is not TLS, and your use case here is not TLS (clearly), so don't = mess with TLS, or you will break, eventually. The best I can do is try = to explicitly break you sooner, than later, so that I can deal with the = fallout sooner than later, and not when there's a critical issue in the = TLS ecosystem needing rapid resolution. I'm not sure what your point is here. I agree this usage is wrong, = but the goal is to *fix* it. The goal isn't to "bless" the existing = usage. The goal is to figure out what *should* supplicants do. > At a high-level, you're still fundamentally proposing a new root = store. I realize that may not be obvious, given the suggestion of = intermediates with id-kp-eapOverLAN, but that's still fundamentally = what's being suggested, because you still need to define a certificate = profile (such as the EKU), expected policies such as how that = information is validated, and a process for ensuring that validation is = performed. I think that's a laudable goal, and perhaps worth pursuing, = but it's important to stress that in defining a new root store, there's = no reason to reuse anything extant. The fact that operating systems may = trust some organizations for other purposes (TLS or S/MIME) should by no = means be dispositive towards whatever you're doing. Where to best = propose certificate profiles or certificate policies for that root = store, I don't know, and that clearly requires a lot more implementor = experience and consensus to end up with something like the CA/Browser = Forum that is useful for TLS. EAP supplicant implementations largely do this already. So there's no = "proposal" of a new root store. There's a statement that there *is* a = different root store. i.e. implementations default to not trusting CAs for EAP. The trust = has to be explicitly enabled by an admin, or by the user. This means = that there's a store of CAs *only* for EAP. Everyone knows that it's wrong to use id-kp-serverAuth for EAP. The = way forward is to figure out how to fix it. Alan DeKok. From nobody Tue Jan 7 08:51:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE8B120879 for ; Tue, 7 Jan 2020 08:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 kPaW1_UqNYvv for ; Tue, 7 Jan 2020 08:51:23 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28C912085D for ; Tue, 7 Jan 2020 08:51:23 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 007GdDmn025388; Tue, 7 Jan 2020 16:51:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3cuHAe1zlTHnKHpwWdvqZs2QyfJgMBORw9B6hVE9X34=; b=XAzUbM0I6O3dheGC3diBbNDhjsnJTw5ogmqrXnCpVoAweM8bE4d76YLYPyy17QR0LNMt Wo6oV4QawTKj0UK2g5gC4uF7qvTXVZJrfyOWjYB3KQqQRhbMaxQLfaLV9/6UQiHaoAdx v+9VAduxNRJCGD4hBlLCKus6tnAeqcO8N/8z9R2N46vcsMIEAtDs57Bji18XRShffjtI BDTplWbOiePCjyZYaU+o890G+5wNChoi/Rie8hF+H5/P22trrL/AveYdR5yRi6iE345f q3Ap72yT0HC1sqixG4BXl26h1fqYcbfYpCjJj8tsNxfFN/cPz1VuU41a3ORsyfV9JL0F +A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2xam0dc5v6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2020 16:51:22 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 007Gkxgl029805; Tue, 7 Jan 2020 11:51:21 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2xapwyngyr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 07 Jan 2020 11:51:21 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 11:51:21 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 7 Jan 2020 11:51:20 -0500 From: "Salz, Rich" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile Thread-Index: AQHVxWtE1S/IdRCTRE6OZfmgtKVF66ffaogA Date: Tue, 7 Jan 2020 16:51:20 +0000 Message-ID: <8950BE58-8EC1-473E-B800-ACC0A9ADE339@akamai.com> References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> In-Reply-To: <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.13] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-07_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=679 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001070136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-07_05:2020-01-07, 2020-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 adultscore=0 mlxlogscore=651 malwarescore=0 suspectscore=0 clxscore=1015 lowpriorityscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001070136 Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:51:25 -0000 ICAgIFRoZXJlIGFyZSB0d28gQ01QLXJlbGF0ZWQgZG9jdW1lbnRzOg0KICAgICAgLSBkcmFmdC1i cm9ja2hhdXMtbGFtcHMtY21wLXVwZGF0ZXMNCiAgICAgIC0gZHJhZnQtYnJvY2toYXVzLWxhbXBz LWxpZ2h0d2VpZ2h0LWNtcC1wcm9maWxlDQoNCkkgc3VwcG9ydCBhZG9wdGlvbiBvZiBib3RoIG9m IHRoZXNlLg0KDQpBcyBhIHNpZGUtbm90ZSwgSGVuZHJpayBhbmQgRGF2aWQgYXJlIGFjdGl2ZSBp biBjb250cmlidXRpbmcgQ01QIHN1cHBvcnQgdG8gT3BlblNTTCBmb3IgdGhlIG5leHQgbWFqb3Ig cmVsZWFzZS4NCg0KDQo= From nobody Tue Jan 7 09:33:37 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B061200CC; Tue, 7 Jan 2020 09:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 BM95KFwnEiXx; Tue, 7 Jan 2020 09:33:28 -0800 (PST) Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8D71200B8; Tue, 7 Jan 2020 09:33:28 -0800 (PST) Received: by mail-ed1-f44.google.com with SMTP id e10so248502edv.9; Tue, 07 Jan 2020 09:33:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bpYlKRTkXY9AY3PB0zpVcXM3kSAd8+KnoWiw27Wv2b0=; b=ZAzOjh+baFtPN5pfILknylumHezI+niCND37Nl1o5HtaL7Gf1gfOTIAANLausbmeiC NMF/eDFrxYRtiIwpx6duJ20BsInvtKSaxr2EKEkN3tKXuq9SAkeubap3ZG0k2i+8NJ+c 450fPeY0DrDiClP2U9m0PlTE0NWZ8G1aHXudT6jrLl9Ddd/zryyAlK+jNuX+bknpawx0 uPa8w/NtzQaxAySk+s6dKEBfKNFxnM7hCYG7XPc30w+AiD8EVIiBURJM0doLg/TAHBeg 56lSFr+FD93L+a2VE5KHa0tZvBxWiLd08RSMatIkVn3Kh3+M/1sjXIH2yNWKIvhuAXnx ORFQ== X-Gm-Message-State: APjAAAUPCl5XOHvPYa3iSbxPRna7Tj86jAy0L+IGy8RWefRQhXrBC1xW K8QW4HjcPyumeUGAggw26hN8+OZc X-Google-Smtp-Source: APXvYqwTiocfr4qjt/TMEBaPZ6aZa3BL1AUFvHNgb+Xo+Wn4eKZN0LrmEgE/pqV3tUO9sSqDvm7r+g== X-Received: by 2002:a17:906:6d4c:: with SMTP id a12mr559114ejt.94.1578418406190; Tue, 07 Jan 2020 09:33:26 -0800 (PST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com. [209.85.128.46]) by smtp.gmail.com with ESMTPSA id j21sm11951eds.8.2020.01.07.09.33.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jan 2020 09:33:25 -0800 (PST) Received: by mail-wm1-f46.google.com with SMTP id b19so386275wmj.4; Tue, 07 Jan 2020 09:33:25 -0800 (PST) X-Received: by 2002:a1c:3c89:: with SMTP id j131mr203807wma.34.1578418405551; Tue, 07 Jan 2020 09:33:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Sleevi Date: Tue, 7 Jan 2020 12:33:14 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Ryan Sleevi , "Owen Friel (ofriel)" , "spasm@ietf.org" , EMU WG Content-Type: multipart/alternative; boundary="0000000000005eb561059b902cb8" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 17:33:29 -0000 --0000000000005eb561059b902cb8 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 11:44 AM Alan DeKok wrote: > On Jan 7, 2020, at 9:54 AM, Ryan Sleevi wrote: > > At the high-level, I will say that using TLS (id-kp-serverAuth) > certificates, from the intersection of CAs that are commonly trusted by > operating systems and browsers, is bad. It will create security issues, > will create interoperability issues, and will not help users. > > It's been accepted practice in all EAP implementations for ~15 years. > Are there practical issues you're aware of? Because I can't recall seeing > any. > I'm sure "practical" will be seen as subjective, but here's some examples: Operational: - Customers of CAs having trouble when their CA has to perform timely revocation of their certificates - Migration off SHA-1 - Migration off 1024-bit RSA - CAs being shut down or exiting the business due to non-compliance with browser requirements Security: - Cross-protocol considerations due to key reuse seems like a meaningful security issue that's being dismissed. > Any security issues are limited. If a site administrator has access to > the public / private keys for a web server, it's possible to re-use those > certs for EAP. This re-use cannot be prevented. > No. But it results in prompt revocation of that certificate if anyone demonstrates it being used like that, the same as no one can prevent you from embedding a private key in software, but doing so gets it swiftly revoked. [1] [1] https://www.theregister.co.uk/2019/12/05/atlassian_zero_day_bug/ > I'm not sure what your point is here. I agree this usage is wrong, but > the goal is to *fix* it. The goal isn't to "bless" the existing usage. > > The goal is to figure out what *should* supplicants do. > There's no short-term or medium-term solution that can rely on 'accepting' or 'specifying' the use of id-kp-serverAuth, which was the original proposal as a "recommend". Any of those uses are inherently broken and unsafe and just time bombs waiting to go off. > EAP supplicant implementations largely do this already. So there's no > "proposal" of a new root store. There's a statement that there *is* a > different root store. > That doesn't match Owen's original message, so while I'm glad there's an acknowledgement here of differences, that doesn't seem to match the discussion to date. > i.e. implementations default to not trusting CAs for EAP. The trust has > to be explicitly enabled by an admin, or by the user. This means that > there's a store of CAs *only* for EAP. > > Everyone knows that it's wrong to use id-kp-serverAuth for EAP. The > way forward is to figure out how to fix it. > Update software? I'm glad there's agreement it's bad/wrong to use, but it seems the only path forward is going to be to breaking, not recommending for using public (TLS) CAs with id-kp-serverAuth. Attempting to specify some interoperable behaviour in the interim, before things are broken, for how folks can keep using id-kp-serverAuth, seems to be the problem. Just accepting that things need to be broken seems like it easily allows moving into the discussion about NAIRealm and manual configuration. I know that's easy to say when it's individual vendors who have to deal with the fallout and that's why I suggested there's a spectrum of responses for how that's phased out. But explicitly moving towards that goal, and not trying to live in the interim with id-kp-serverAuth, seems the best path forward. --0000000000005eb561059b902cb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 7, 2020 at 11:44 AM Alan = DeKok <aland@deployingradiu= s.com> wrote:
On Jan 7, 2020, at 9:54 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> At the high-level, I will say that using TLS (id-kp-serverAuth) certif= icates, from the intersection of CAs that are commonly trusted by operating= systems and browsers, is bad. It will create security issues, will create = interoperability issues, and will not help users.

=C2=A0 It's been accepted practice in all EAP implementations for ~15 y= ears.=C2=A0 Are there practical issues you're aware of?=C2=A0 Because I= can't recall seeing any.

I'm s= ure "practical" will be seen as subjective, but here's some e= xamples:

Operational:
- Customers of CAs= having trouble when their CA has to perform timely revocation of their cer= tificates
- Migration off SHA-1
- Migration off 1024-bi= t RSA
- CAs being shut down or exiting the business due to non-co= mpliance with browser requirements

Security:
=
- Cross-protocol considerations due to key reuse seems like a meaningf= ul security issue that's being dismissed.
=C2=A0
=C2=A0 Any security issues are limited.=C2=A0 If a site administrator has a= ccess to the public / private keys for a web server, it's possible to r= e-use those certs for EAP.=C2=A0 This re-use cannot be prevented.

No. But it results in prompt revocation of that = certificate if anyone demonstrates it being used like that, the same as no = one can prevent you from embedding a private key in software, but doing so = gets it swiftly revoked. [1]

=C2=A0=
=C2=A0 I'm not sure what your point is here.=C2=A0 I agree this usage i= s wrong, but the goal is to *fix* it.=C2=A0 The goal isn't to "ble= ss" the existing usage.

=C2=A0 The goal is to figure out what *should* supplicants do.

There's no short-term or medium-term solution t= hat can rely on 'accepting' or 'specifying' the use of id-k= p-serverAuth, which was the original proposal as a "recommend". A= ny of those uses are inherently broken and unsafe and just time bombs waiti= ng to go off.
=C2=A0
=C2=A0 EAP supplicant implementations largely do this already.=C2=A0 So the= re's no "proposal" of a new root store.=C2=A0 There's a s= tatement that there *is* a different root store.

<= /div>
That doesn't match Owen's original message, so while I= 9;m glad there's an acknowledgement here of differences, that doesn'= ;t seem to match the discussion to date.
=C2=A0
=C2=A0 i.e. implementations default to not trusting CAs for EAP.=C2=A0 The = trust has to be explicitly enabled by an admin, or by the user.=C2=A0 This = means that there's a store of CAs *only* for EAP.

=C2=A0 Everyone knows that it's wrong to use id-kp-serverAuth for EAP.= =C2=A0 =C2=A0The way forward is to figure out how to fix it.

Update software? I'm glad there's agreement i= t's bad/wrong to use, but it seems the only path forward is going to be= to breaking, not recommending for using public (TLS) CAs with id-kp-server= Auth.

Attempting to specify some interoperable beh= aviour in the interim, before things are broken, for how folks can keep usi= ng id-kp-serverAuth, seems to be the problem. Just accepting that things ne= ed to be broken seems like it easily allows moving into the discussion abou= t NAIRealm and manual configuration.

I know that&#= 39;s easy to say when it's individual vendors who have to deal with the= fallout and that's why I suggested there's a spectrum of responses= for how that's phased out. But explicitly moving towards that goal, an= d not trying to live in the interim with id-kp-serverAuth, seems the best p= ath forward.
--0000000000005eb561059b902cb8-- From nobody Tue Jan 7 09:51:54 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD676120131; Tue, 7 Jan 2020 09:51:51 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5KeVdK2P8dSg; Tue, 7 Jan 2020 09:51:49 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09901200E9; Tue, 7 Jan 2020 09:51:48 -0800 (PST) Received: from [192.168.20.201] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id 27C48253; Tue, 7 Jan 2020 17:51:46 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Tue, 7 Jan 2020 12:51:44 -0500 Cc: "Owen Friel (ofriel)" , "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 17:51:52 -0000 On Jan 7, 2020, at 12:33 PM, Ryan Sleevi wrote: > > At the high-level, I will say that using TLS (id-kp-serverAuth) = certificates, from the intersection of CAs that are commonly trusted by = operating systems and browsers, is bad. It will create security issues, = will create interoperability issues, and will not help users. >=20 > It's been accepted practice in all EAP implementations for ~15 = years. Are there practical issues you're aware of? Because I can't = recall seeing any. >=20 > I'm sure "practical" will be seen as subjective, but here's some = examples: >=20 > Operational: > - Customers of CAs having trouble when their CA has to perform timely = revocation of their certificates > - Migration off SHA-1 > - Migration off 1024-bit RSA > - CAs being shut down or exiting the business due to non-compliance = with browser requirements How is that specific to the use of TLS (id-kp-serverAuth) = certificates? Any use of TLS certificates by EAP would be subject to = the same issues. > Security: > - Cross-protocol considerations due to key reuse seems like a = meaningful security issue that's being dismissed. Who is dismissing it? > Any security issues are limited. If a site administrator has access = to the public / private keys for a web server, it's possible to re-use = those certs for EAP. This re-use cannot be prevented. >=20 > No. But it results in prompt revocation of that certificate if anyone = demonstrates it being used like that No, it doesn't. *Everyone* has been doing this with EAP for a very long time. i.e. = getting a certificate using id-kp-serverAuth from a root CA, and then = using that certificate for EAP. I have never heard of such a = certificate being revoked. > There's no short-term or medium-term solution that can rely on = 'accepting' or 'specifying' the use of id-kp-serverAuth, which was the = original proposal as a "recommend". Any of those uses are inherently = broken and unsafe and just time bombs waiting to go off. It's been 15+ years. There has been no such issue. I think it's acceptable to recommend people continue existing = practice, where such practice has been shown to be (a) workable, and (b) = has no known issues. > Everyone knows that it's wrong to use id-kp-serverAuth for EAP. = The way forward is to figure out how to fix it. >=20 > Update software? To do *what*? A concrete proposal would help here. > I'm glad there's agreement it's bad/wrong to use, but it seems the = only path forward is going to be to breaking, not recommending for using = public (TLS) CAs with id-kp-serverAuth. Please call Microsoft and Apple, and tell them you're going to forbid = their 15 year workflow for EAP. Then, tell them that you *want* their = systems to break, and that it's for security reasons. I suspect that request won't go over well. We just cannot break existing systems without a clear and present = security problem. And none has been demonstrated here. > Attempting to specify some interoperable behaviour in the interim, = before things are broken, for how folks can keep using id-kp-serverAuth, = seems to be the problem. Just accepting that things need to be broken = seems like it easily allows moving into the discussion about NAIRealm = and manual configuration. I think it's OK to *document* existing behaviour. Behaviour that has = been demonstrated in to be interoperable with billions of devices. > I know that's easy to say when it's individual vendors who have to = deal with the fallout and that's why I suggested there's a spectrum of = responses for how that's phased out. But explicitly moving towards that = goal, and not trying to live in the interim with id-kp-serverAuth, seems = the best path forward. I welcome concrete proposals to move forward. The discussion here = seems to recommend against using id-kp-eapOverLAN and NAIRealm. Which = means we *don't* have a way forward. In the absence of a solution, it's best to document existing practice. Alan DeKok. From nobody Tue Jan 7 11:20:07 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADDC1202DD; Tue, 7 Jan 2020 11:20:00 -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_50=0.8, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 tTyAFfjClipF; Tue, 7 Jan 2020 11:19:58 -0800 (PST) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426E51200C7; Tue, 7 Jan 2020 11:19:58 -0800 (PST) Received: by mail-ed1-f43.google.com with SMTP id i16so535651edr.5; Tue, 07 Jan 2020 11:19:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gYztrtMHtaWGNNaiEegAqKhlAXd+EHaE1705Lvqoe/k=; b=fV+F/KJe/YRY9E6cT2XsazYtYMqQ3DddIOHeRBTZDrTdvecQdnMARjcn1lUkWH+uyA kF0IhMID8/NpLZb3nnco8yoFp5E9vxaqm/z/3uk/CHFkjdC4TuPSfC2HgnnMSusXT6py AAHKEixBHyrEaNr0Ll4TWNHdCZq1aB7PI7pzPh75w7+3KiKmb6aL9P4xJ68PwIn89ywV 4ZSwypYbg5kV7xIFctZi39mjSDWsOgBBRm57k6arLdbFF0BAg3zi2SoC6Ecc81Vtc3TQ 2CVdk7oWfppfVYe1nSqI36i2ZWpoAO1N8K87JUaOAM8kvARrPzNBJPUcEjkQBG9kosVT FhHQ== X-Gm-Message-State: APjAAAXW6TvvxuuhdUQSM29agu+M3Ijn3hsr9R3jfBvvTFKAFGdrCKnE eTquIPJ0EOrcERU11er+XWQSM6D6 X-Google-Smtp-Source: APXvYqwJq9kU+qM4QBvXVz5W5GyIZxDY+b39I7Gm8djwJSmJHWrDxbZjMQqny74n/TZ+6/m7h/H7iw== X-Received: by 2002:a17:906:bcd3:: with SMTP id lw19mr1019383ejb.270.1578424796441; Tue, 07 Jan 2020 11:19:56 -0800 (PST) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com. [209.85.128.52]) by smtp.gmail.com with ESMTPSA id a9sm19388edm.82.2020.01.07.11.19.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jan 2020 11:19:56 -0800 (PST) Received: by mail-wm1-f52.google.com with SMTP id m24so723447wmc.3; Tue, 07 Jan 2020 11:19:56 -0800 (PST) X-Received: by 2002:a1c:3c89:: with SMTP id j131mr617010wma.34.1578424795818; Tue, 07 Jan 2020 11:19:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Sleevi Date: Tue, 7 Jan 2020 14:19:44 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: EMU WG , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004274c1059b91a939" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:20:01 -0000 --0000000000004274c1059b91a939 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 7, 2020 at 12:51 PM Alan DeKok wrote: > On Jan 7, 2020, at 12:33 PM, Ryan Sleevi wrote: > > > At the high-level, I will say that using TLS (id-kp-serverAuth) > certificates, from the intersection of CAs that are commonly trusted by > operating systems and browsers, is bad. It will create security issues, > will create interoperability issues, and will not help users. > > > > It's been accepted practice in all EAP implementations for ~15 years. > Are there practical issues you're aware of? Because I can't recall seein= g > any. > > > > I'm sure "practical" will be seen as subjective, but here's some > examples: > > > > Operational: > > - Customers of CAs having trouble when their CA has to perform timely > revocation of their certificates > > - Migration off SHA-1 > > - Migration off 1024-bit RSA > > - CAs being shut down or exiting the business due to non-compliance wit= h > browser requirements > > How is that specific to the use of TLS (id-kp-serverAuth) certificates? > Any use of TLS certificates by EAP would be subject to the same issues. Was there a typo here? I=E2=80=99m not sure how to parse or understand this= ? > > > Security: > > - Cross-protocol considerations due to key reuse seems like a meaningfu= l > security issue that's being dismissed. > > Who is dismissing it? > > > Any security issues are limited. ^ this seems dismissive If a site administrator has access to the public / private keys for a web > server, it's possible to re-use those certs for EAP. This re-use cannot = be > prevented. > > > > No. But it results in prompt revocation of that certificate if anyone > demonstrates it being used like that > > No, it doesn't. > > *Everyone* has been doing this with EAP for a very long time. i.e. > getting a certificate using id-kp-serverAuth from a root CA, and then usi= ng > that certificate for EAP. I have never heard of such a certificate being > revoked. The same was said for people embedding private keys in their software. > > > There's no short-term or medium-term solution that can rely on > 'accepting' or 'specifying' the use of id-kp-serverAuth, which was the > original proposal as a "recommend". Any of those uses are inherently brok= en > and unsafe and just time bombs waiting to go off. > > It's been 15+ years. There has been no such issue. This is empirically false. The use of certain CA=E2=80=99s certificates in = wireless deployments has absolutely been a barrier to compliance and improvements. > > I think it's acceptable to recommend people continue existing practice, > where such practice has been shown to be (a) workable, and (b) has no kno= wn > issues. I=E2=80=99ve demonstrated both a and b are false, perhaps not to your satis= faction, but it remains true. > > > Everyone knows that it's wrong to use id-kp-serverAuth for EAP. The > way forward is to figure out how to fix it. > > > > Update software? > > To do *what*? A concrete proposal would help here. The same message you=E2=80=99re replying to contains one, which you dismiss= as unworkable. It=E2=80=99s unclear why, or if the only solution is enshrine t= he status quo? > > I'm glad there's agreement it's bad/wrong to use, but it seems the only > path forward is going to be to breaking, not recommending for using publi= c > (TLS) CAs with id-kp-serverAuth. > > Please call Microsoft and Apple, and tell them you're going to forbid > their 15 year workflow for EAP. Then, tell them that you *want* their > systems to break, and that it's for security reasons. They=E2=80=99re on the same page already. I won=E2=80=99t claim to speak fo= r them, but the same principles and concerns I=E2=80=99m raising are and have been shared b= y all the major OS and browser vendors in some form. This is the path that is on the way out, not the way forward. I suspect that request won't go over well. > > We just cannot break existing systems without a clear and present > security problem. And none has been demonstrated here. Apologies for the confusion here, but there seems to be a lot of unresolvable contradictions here. We must do something different, but we can=E2=80=99t change. We know the current solution is bad, but there=E2=80= =99s nothing wrong with it. We need something better, but we can=E2=80=99t break anythin= g. Wanting to both have and eat cake is an unwinnable position. > > Attempting to specify some interoperable behaviour in the interim, > before things are broken, for how folks can keep using id-kp-serverAuth, > seems to be the problem. Just accepting that things need to be broken see= ms > like it easily allows moving into the discussion about NAIRealm and manua= l > configuration. > > I think it's OK to *document* existing behaviour. Behaviour that has > been demonstrated in to be interoperable with billions of devices. I strongly disagree here. Documenting bad behaviour in SDOs serves to try and legitimize it. The only benefit is to allow existing implementations to align and new implementations to be interoperable, except the behavior being specified is bad, and will break, and will cause pain. Even on the Informational track, that would be actively harmful to the ecosystem. > > > I know that's easy to say when it's individual vendors who have to deal > with the fallout and that's why I suggested there's a spectrum of respons= es > for how that's phased out. But explicitly moving towards that goal, and n= ot > trying to live in the interim with id-kp-serverAuth, seems the best path > forward. > > I welcome concrete proposals to move forward. The discussion here seem= s > to recommend against using id-kp-eapOverLAN and NAIRealm. Which means we > *don't* have a way forward. Why not? > --0000000000004274c1059b91a939 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 7, 2020 at 12:51 PM Alan DeKok <aland@deployingradius.com> wrote:
<= /div>
On Jan 7, 2020, at 12:33 PM, Ryan Sleevi <ryan-ietf@sleevi.com= > wrote:
> > At the high-level, I will say that using TLS (id-kp-serverAuth) c= ertificates, from the intersection of CAs that are commonly trusted by oper= ating systems and browsers, is bad. It will create security issues, will cr= eate interoperability issues, and will not help users.
>
>=C2=A0 =C2=A0It's been accepted practice in all EAP implementations= for ~15 years.=C2=A0 Are there practical issues you're aware of?=C2=A0= Because I can't recall seeing any.
>
> I'm sure "practical" will be seen as subjective, but her= e's some examples:
>
> Operational:
> - Customers of CAs having trouble when their CA has to perform timely = revocation of their certificates
> - Migration off SHA-1
> - Migration off 1024-bit RSA
> - CAs being shut down or exiting the business due to non-compliance wi= th browser requirements

=C2=A0 How is that specific to the use of TLS (id-kp-serverAuth) certificat= es?=C2=A0 Any use of TLS certificates by EAP would be subject to the same i= ssues.

Was there = a typo here? I=E2=80=99m not sure how to parse or understand this?



> Security:
> - Cross-protocol considerations due to key reuse seems like a meaningf= ul security issue that's being dismissed.

=C2=A0 Who is dismissing it?

>=C2=A0 =C2=A0Any security issues are limited.=C2=A0

^ this seems dismissive

If a site administrator has access t= o the public / private keys for a web server, it's possible to re-use t= hose certs for EAP.=C2=A0 This re-use cannot be prevented.
>
> No. But it results in prompt revocation of that certificate if anyone = demonstrates it being used like that

=C2=A0 No, it doesn't.

=C2=A0 *Everyone* has been doing this with EAP for a very long time.=C2=A0 = i.e. getting a certificate using id-kp-serverAuth from a root CA, and then = using that certificate for EAP.=C2=A0 I have never heard of such a certific= ate being revoked.

The same was said for people embedding private keys in their software.



> There's no short-term or medium-term solution that can rely on = 9;accepting' or 'specifying' the use of id-kp-serverAuth, which= was the original proposal as a "recommend". Any of those uses ar= e inherently broken and unsafe and just time bombs waiting to go off.

=C2=A0 It's been 15+ years.=C2=A0 There has been no such issue.

This is empirically fals= e. The use of certain CA=E2=80=99s certificates in wireless deployments has= absolutely been a barrier to compliance and improvements.



=C2=A0 I think it's acceptable to recommend people continue existing pr= actice, where such practice has been shown to be (a) workable, and (b) has = no known issues.

= I=E2=80=99ve demonstrated both a and b are false, perhaps not to your satis= faction, but it remains true.



>=C2=A0 =C2=A0Everyone knows that it's wrong to use id-kp-serverAuth= for EAP.=C2=A0 =C2=A0The way forward is to figure out how to fix it.
>
> Update software?

=C2=A0 To do *what*?=C2=A0 A concrete proposal would help here.

The same message you=E2=80= =99re replying to contains one, which you dismiss as unworkable. It=E2=80= =99s unclear why, or if the only solution is enshrine the status quo?
=


> I'm glad there's agreement it's bad/wrong to use, but it s= eems the only path forward is going to be to breaking, not recommending for= using public (TLS) CAs with id-kp-serverAuth.

=C2=A0 Please call Microsoft and Apple, and tell them you're going to f= orbid their 15 year workflow for EAP.=C2=A0 Then, tell them that you *want*= their systems to break, and that it's for security reasons.

They=E2=80=99re on the same= page already. I won=E2=80=99t claim to speak for them, but the same princi= ples and concerns I=E2=80=99m raising are and have been shared by all the m= ajor OS and browser vendors in some form. This is the path that is on the w= ay out, not the way forward.

=C2=A0 I suspect that request won't go over well.

=C2=A0 We just cannot break existing systems without a clear and present se= curity problem.=C2=A0 And none has been demonstrated here.

Apologies for the confusio= n here, but there seems to be a lot of unresolvable contradictions here. We= must do something different, but we can=E2=80=99t change. We know the curr= ent solution is bad, but there=E2=80=99s nothing wrong with it. We need som= ething better, but we can=E2=80=99t break anything.
=
Wanting to both have and eat cake is an unwinna= ble position.


> Attempting to specify some interoperable behaviour in the interim, bef= ore things are broken, for how folks can keep using id-kp-serverAuth, seems= to be the problem. Just accepting that things need to be broken seems like= it easily allows moving into the discussion about NAIRealm and manual conf= iguration.

=C2=A0 I think it's OK to *document* existing behaviour.=C2=A0 Behaviou= r that has been demonstrated in to be interoperable with billions of device= s.

I stron= gly disagree here. Documenting bad behaviour in SDOs serves to try and legi= timize it. The only benefit is to allow existing implementations to align a= nd new implementations to be interoperable, except the behavior being speci= fied is bad, and will break, and will cause pain. Even on the Informational= track, that would be actively harmful to the ecosystem.



> I know that's easy to say when it's individual vendors who hav= e to deal with the fallout and that's why I suggested there's a spe= ctrum of responses for how that's phased out. But explicitly moving tow= ards that goal, and not trying to live in the interim with id-kp-serverAuth= , seems the best path forward.

=C2=A0 I welcome concrete proposals to move forward.=C2=A0 The discussion h= ere seems to recommend against using id-kp-eapOverLAN and NAIRealm.=C2=A0 W= hich means we *don't* have a way forward.

Why not?
--0000000000004274c1059b91a939-- From nobody Tue Jan 7 12:19:31 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CCD1200EB; Tue, 7 Jan 2020 12:19:26 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cHaOF2FAJNPi; Tue, 7 Jan 2020 12:19:21 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71C3120077; Tue, 7 Jan 2020 12:19:20 -0800 (PST) Received: from [192.168.20.201] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id D8D06795; Tue, 7 Jan 2020 20:19:17 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Tue, 7 Jan 2020 15:19:16 -0500 Cc: EMU WG , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> References: To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 20:19:26 -0000 On Jan 7, 2020, at 2:19 PM, Ryan Sleevi wrote: > Was there a typo here? I=E2=80=99m not sure how to parse or understand = this? I read your previous messages as claiming there were issues *specific* = to EAP using id-kp-serverAuth. When I asked for specifics, the response = was to describe general issues with certificate management. My conclusion, then, is that there are no issues specific to EAP using = id-kp-serverAuth.=20 > > Security: > > - Cross-protocol considerations due to key reuse seems like a = meaningful security issue that's being dismissed. >=20 > Who is dismissing it? >=20 > > Any security issues are limited.=20 >=20 > ^ this seems dismissive Nonsense. I'm asking you to prove your position that there are = issues. I've given detailed explanations of security issues, including = pros and cons. There is no possible way you can see such discussion as = me being "dismissive" of the issues. > *Everyone* has been doing this with EAP for a very long time. i.e. = getting a certificate using id-kp-serverAuth from a root CA, and then = using that certificate for EAP. I have never heard of such a = certificate being revoked. >=20 > The same was said for people embedding private keys in their software. I have no idea what that means, or why it's relevant. People have advocated all kinds of stupid things over the years. None = of that is relevant. The concern here is that you're claiming there are = major issues with EAP using id-kp-serverAuth, and that those issues = *will* be seen. My counter-position is that it's been 15 years, and no = such issues have been seen. So please state *what* issues exist. *Why* they are issues. *What* = effects those issues will have. Failing that, please stop claiming that = there are issues. > > There's no short-term or medium-term solution that can rely on = 'accepting' or 'specifying' the use of id-kp-serverAuth, which was the = original proposal as a "recommend". Any of those uses are inherently = broken and unsafe and just time bombs waiting to go off. >=20 > It's been 15+ years. There has been no such issue. >=20 > This is empirically false. The use of certain CA=E2=80=99s = certificates in wireless deployments has absolutely been a barrier to = compliance and improvements. How? How are those barriers *specific* to EAP, and are not generic to = any certificate upgrade / change? You haven't said. > I think it's acceptable to recommend people continue existing = practice, where such practice has been shown to be (a) workable, and (b) = has no known issues. >=20 > I=E2=80=99ve demonstrated both a and b are false, perhaps not to your = satisfaction, but it remains true. No, you haven't demonstrated that. And not even "to my satisfaction". = You've made claims with essentially zero evidence. And let's be clear here. Your claim above is that the existing EAP = practices are *not* workable. That claim is disproven by the working of = all WiFi equipment. Since I'm not satisfied or maybe not understanding your point, please = explain *how* the current EAP practices *do not work*, in the face of = billions of devices that manifestly do work. Please make the = explanation simple, and specific to EAP. > The same message you=E2=80=99re replying to contains one, which you = dismiss as unworkable. It=E2=80=99s unclear why, or if the only solution = is enshrine the status quo? Where did I dismiss any solution as unworkable? > Apologies for the confusion here, but there seems to be a lot of = unresolvable contradictions here. We must do something different, but we = can=E2=80=99t change. We know the current solution is bad, but there=E2=80= =99s nothing wrong with it. We need something better, but we can=E2=80=99t= break anything. My position is in no way contradictory. I will re-iterate as it seems = to be misunderstood: * the existing practices work (you claim they do not) * the existing practices appear to be mostly secure (you claim they are = not) * the existing practices are imperfect (using TLS web server OIDs for = EAP is bad, and allows for a security issue) * we should come up with a better solution * that better solution CANNOT be implemented by breaking existing = systems * we need a migration path from "now" to "the better solution". * there has been discussion about what a better solution would look like * discussion has indicated that others oppose parts of the proposed = solution. > I strongly disagree here. Documenting bad behaviour in SDOs serves to = try and legitimize it. The only benefit is to allow existing = implementations to align and new implementations to be interoperable, = except the behavior being specified is bad, and will break, and will = cause pain. Even on the Informational track, that would be actively = harmful to the ecosystem. How? > > I know that's easy to say when it's individual vendors who have to = deal with the fallout and that's why I suggested there's a spectrum of = responses for how that's phased out. But explicitly moving towards that = goal, and not trying to live in the interim with id-kp-serverAuth, seems = the best path forward. >=20 > I welcome concrete proposals to move forward. The discussion here = seems to recommend against using id-kp-eapOverLAN and NAIRealm. Which = means we *don't* have a way forward. >=20 > Why not? We don't have a way forward until WG consensus is reached. Which is = why we're having this discussion. Honestly, I'm confused at the discussion here. You're not showing any = *concrete* security issues above what I've already discussed. You're = not proposing anything better. You're claiming that EAP doesn't work = today. You want to fix things by breaking everything. That's... not something I understand. Alan DeKok. From nobody Tue Jan 7 12:35:46 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99291200B3 for ; Tue, 7 Jan 2020 12:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 y0tGJPSFBUil for ; Tue, 7 Jan 2020 12:35:41 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A46120025 for ; Tue, 7 Jan 2020 12:35:40 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2D8243897D for ; Tue, 7 Jan 2020 15:35:17 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6E93060A for ; Tue, 7 Jan 2020 15:35:37 -0500 (EST) From: Michael Richardson To: LAMPS WG In-Reply-To: <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 20:35:45 -0000 --=-=-= Content-Type: text/plain I support adopting - draft-brockhaus-lamps-cmp-updates with the following (non-blocking) comments: * I find that section 3 lacks motivation for why it is making these changes. * why is "The following updates were made since RFC 4210:" in the past tense? * Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and a CMC RA. As the functionality of a CA and RA is not specific to whether use CMC or CMP as certificate management protocol, the same OIDs SHALL be used for a cmpCA and a cmpRA. I believe that I might need a little bit of convincing here on reusing cmpRA. I want to think about this a bit.... the last two paragraphs of 3.2 hint at my not well formed concerns. As such this document would seem to update RFC6402 as well. I do wonder if 4210bis might be better a better idea rather than replacing/updated so much "EncryptedValue -> EncryptedKey". - draft-brockhaus-lamps-lightweight-cmp-profile This is the document I'm more interested in. At 64 pages, I wonder about "lightweight" ;-) I believe that a two paragraph summary of Appendix D and E would be worthwhile. How much of 4210 could we just throw out in a 4210bis? s/IPSec/IPsec/ {it's the brown M&M of rfc4301} section 2.6 says: "Chapter 2", so I think the references are all dangling. XML2rfc deals with tis for you, so I'm guessing you aren't using here? I find this statement: HTTP transfer is RESOMMENDED to use for all PKI entities, but there is no transport specified as mandatory to be flexible for devices with special constrained to choose whatever transport is suitable. (aside from the typo), difficult to take in a profile. RECOMMENDED is a synonym for SHOULD, and usually needs to have some explanation of when another answer is appropriate. If you want to be open to COAP, then let's just say that. I'm glad that section 7.1 makes the URL clear. I think that lower case 'cmp' would be more consistent with other .well-known uses. 7.2 should say TLS 1.2 or greater/newer, rather than saying 1.2 or 1.3. Both the HTTP and HTTPS usage might need to be clear if support for HTTP/2 and/or QUIC is expected to be supported. Constrained environments want to know what they can skip. 7.5. CoAP transport ... Such specification is out of scope of this document and would need to be specifies in a separate document. I think that it's not that hard to specify this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4U65kACgkQgItw+93Q 3WUrbwf/a68gq3292GQ0RO39Uyyymp/XWfsUJ53xV9SRzqxKD7dg6GG2dllgXc1X 84ibSSxpCq065usxKYNOU3tpdxMKIPfkiCSoNSHY69IM+iWfGnbojS4WtcQ4bHQw IDBqduBOjg9M3y5jVlyhVqAX9eGlEySAgd4pbOutY7etFdC3Ypc2n7rWBtxmBvXf wMSYqWr3wiEqsW7J8Vupcqc3cSPmrfdXSsdUFkCVVtL4/9JYjNlLiWZLoD9tpbkY ptpXPVq3SFUccFXo9DhrUz7mo78tTgi2pK76fDEtRHV+YD9unXu+iDc33eWJN5Bv oW/wgyos21w+8jMzZor6nFgAVM5XiQ== =NgGH -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 7 13:34:43 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E18D120143; Tue, 7 Jan 2020 13:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 Yr75VX51mXzq; Tue, 7 Jan 2020 13:34:34 -0800 (PST) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A7F1200E7; Tue, 7 Jan 2020 13:34:33 -0800 (PST) Received: by mail-ed1-f49.google.com with SMTP id l8so872083edw.1; Tue, 07 Jan 2020 13:34:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ql0gVGD1qnWcJQ6S45QjyKCbS71osgCPtX+NfiLm7vs=; b=tghNReV3GZt9FpIpfjle8JzZscnH4dkwsCGpimKO9XJeP2tF+5GAgrSs9RukzezfZ8 RZ6JW3Ba8AsnA3CETV98/2sgMls5pCgnGGOHgnBJeGg58jLyiNiUoScrIFZUJmE3K9W/ Rv/QErowqsCt4kULiqJ9FuDwT2mc2rUDPtu5LmzysPknaMxrSYAvKyJg/b0jrVa7lgaW EtEgvpbKX4+kINzhK6OnafWDVSKoojaHGP+uDeTLzpZ7N0CCkbov74JTCbrYAggQi5L4 RnrtbjfjBcwHowxIixkCFFwTGC0fw/5tTGPgULfm28g0ciYES7tMlQS5T65ng3oQNiX9 wJeQ== X-Gm-Message-State: APjAAAV0qqSqgC3dWSOwUctlbGw8wLk9crIUIMp5apAsNUNIeW8QS+yl foTqCuNLokmXVgVN8/xR5M/+6/eK X-Google-Smtp-Source: APXvYqymYSuNQhOzG7VBMZ9BApOsalq99ZGDvU1vwbx2qr6faMJ8Zt4M6d2j4vlZdpO1A7KbbNuU9g== X-Received: by 2002:a17:906:90d6:: with SMTP id v22mr1557420ejw.294.1578432871418; Tue, 07 Jan 2020 13:34:31 -0800 (PST) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com. [209.85.221.52]) by smtp.gmail.com with ESMTPSA id m24sm21259edr.83.2020.01.07.13.34.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jan 2020 13:34:31 -0800 (PST) Received: by mail-wr1-f52.google.com with SMTP id q10so1140287wrm.11; Tue, 07 Jan 2020 13:34:31 -0800 (PST) X-Received: by 2002:adf:ebc1:: with SMTP id v1mr1012535wrn.351.1578432870819; Tue, 07 Jan 2020 13:34:30 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> In-Reply-To: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> From: Ryan Sleevi Date: Tue, 7 Jan 2020 16:34:19 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Ryan Sleevi , EMU WG , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000912d39059b938ab5" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 21:34:36 -0000 --000000000000912d39059b938ab5 Content-Type: text/plain; charset="UTF-8" Hi Alan, I've snipped your message, because I think we've gotten to a place where we're clearly talking past each other, as you claim I've said several things which I've most definitely not said, or expressed the opposite view. I'm hoping a reset here might help us find a more productive path forward, as well as figure out where the confusion started. I think it's useful to go back to the original message from Owen, at https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM . Perhaps there are other messages and context I've missed, since this was cross-posted across two WGs, but that's the starting point. In that, I think we've got a path forward for interoperable EAP implementations: NAIRealm with id-kp-eapOverLAN asserted as an EKU. That gives a minimal sort of certificate profile to begin discussing. The question posed in that original message is what to do with extant certificates and extant practices, such as going to CAs used for TLS and asking for an id-kp-serverAuth cert, or supplicants looking for id-kp-serverAuth, and whether to specify that. My answer to that is categorically "no, don't do that". This is not specific to EAP, but part of the general problem of repurposing different trust hierarchies and different implementations, without addressing or mitigating the ecosystem considerations. For example, the use of such certificates outside of TLS can and will lead to them being revoked, because one of the requirements for such certificates is that they be used in TLS, otherwise they're revoked. Also, the changes to how PKI libraries validate TLS certificates, and the expectations for the issuance and management of such certificates, are at odds with the goals and objectives of interoperability being discussed. Reusing private key material across protocols and use cases does cause issues, just like reusing root certificates across trust purposes does cause issues. So using the TLS PKI is and always will be fraught with peril, and the maintainers of those TLS PKIs will disregard "your" concerns (the equipment, software, and users), because "your" use case is explicitly not supported and not supportable. These concerns aren't unique to EAP, by any means. But they're reasons why using id-kp-serverAuth is going down a route of trouble, and just because it's been done by some vendors doesn't mean it's good. A transition plan is always challenging, and the IETF is generally a poor venue for figuring out those logistics, because they're often rarely technical. For example, RFC 7585 exists: implementations "just" need to adopt it. Or, if the desire is to have an RFC describe what the end state should be, it should focus on that: describing the end-state. I don't think it should specify the intermediate states, because those are going to vary on a host of concerns, and worse, encourage folks to stop at the intermediate state as being 'good enough'. One such example of an intermediate state is using id-kp-serverAuth certificates, or trying to make a public/private CA demarcation. Those are bad steps to take. I'm not as optimistic as you are for suggesting 'all' EAP clients/supplicants are behaving and enforcing those extended key usages, so that doesn't seem too unreasonable. For example, wpa_supplicant doesn't seem to do so, in the versions used by ChromeOS, Android, or the current tip of tree (using either the internal or the OpenSSL implementation), and that seems like it probably covers quite a few devices/clients. In the TLS PKI, there's lots of industry experience on how to make changes. These changes often involve significant risk of breakage, and yet have become somewhat the norm, and with minimal practical impact. These can involve setting flag days, often starting as per-vendor flag days, such as was done with SHA-1. They can start with changes in major releases, such as new behaviours introduced in a major OS release or a major supplicant release to align closer to the specification or end-state. They may involve some of the intermediate steps mentioned, but only to the extent those are intermediate accomodations; for example, Chrome often has Enterprise flags that allow disabling standards-compliant behaviour when rolling out new versions, but only for a limited time and under limited situations. These aren't, I think, good things to specify, but they're certainly good things to share information about. I don't know if the IETF is the best place for that, but that's neither here nor there. However, an important part of those experiences is that things don't move until vendors break things. Yes, there needs to be a better path, but until you're willing to remove support for the old, or provide incentives for the new, your users don't and won't move. Hopefully that's easier to understand. I'm not sure how we ended up on such different pages, but I think the assertions and requests from your last message were a good indicator that we weren't even in the same postal code, let alone the same page, as far as discussions go. --000000000000912d39059b938ab5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan,

I've snipped your message,= because I think we've gotten to a place where we're clearly talkin= g past each other, as you claim I've said several things which I've= most definitely not said, or expressed the opposite view. I'm hoping a= reset here might help us find a more productive path forward, as well as f= igure out where the confusion started.




For example, the= use of such certificates outside of TLS can and will lead to them being re= voked, because one of the requirements for such certificates is that they b= e used in TLS, otherwise they're revoked. Also, the changes to how PKI = libraries validate TLS certificates, and the expectations for the issuance = and management of such certificates, are at odds with the goals and objecti= ves of interoperability being discussed. Reusing private key material acros= s protocols and use cases does cause issues, just like reusing root certifi= cates across trust purposes does cause issues. So using the TLS PKI is and = always will be fraught with peril, and the maintainers of those TLS PKIs wi= ll disregard "your" concerns (the equipment, software, and users)= , because "your" use case is explicitly not supported and not sup= portable.

These concerns aren't unique to EAP,= by any means. But they're reasons why using id-kp-serverAuth is going = down a route of trouble, and just because it's been done by some vendor= s doesn't mean it's good. A transition plan is always challenging, = and the IETF is generally a poor venue for figuring out those logistics, be= cause they're often rarely technical. For example, RFC 7585 exists: imp= lementations "just" need to adopt it. Or, if the desire is to hav= e an RFC describe what the end state should be, it should focus on that: de= scribing the end-state. I don't think it should specify the intermediat= e states, because those are going to vary on a host of concerns, and worse,= encourage folks to stop at the intermediate state as being 'good enoug= h'. One such example of an intermediate state is using id-kp-serverAuth= certificates, or trying to make a public/private CA demarcation. Those are= bad steps to take.


In the TLS PKI, = there's lots of industry experience on how to make changes. These chang= es often involve significant risk of breakage, and yet have become somewhat= the norm, and with minimal practical impact. These can involve setting fla= g days, often starting as per-vendor flag days, such as was done with SHA-1= . They can start with changes in major releases, such as new behaviours int= roduced in a major OS release or a major supplicant release to align closer= to the specification or end-state. They may involve some of the intermedia= te steps mentioned, but only to the extent those are intermediate accomodat= ions; for example, Chrome often has Enterprise flags that allow disabling s= tandards-compliant behaviour when rolling out new versions, but only for a = limited time and under limited situations. These aren't, I think, good = things to specify, but they're certainly good things to share informati= on about. I don't know if the IETF is the best place for that, but that= 's neither here nor there. However, an important part of those experien= ces is that things don't move until vendors break things. Yes, there ne= eds to be a better path, but until you're willing to remove support for= the old, or provide incentives for the new, your users don't and won&#= 39;t move.

--000000000000912d39059b938ab5-- From nobody Tue Jan 7 18:00:46 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF66C1200F5; Tue, 7 Jan 2020 18:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 sY2_NDitWo2Q; Tue, 7 Jan 2020 18:00:39 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498E412007C; Tue, 7 Jan 2020 18:00:39 -0800 (PST) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 461FA669; Wed, 8 Jan 2020 02:00:36 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Tue, 7 Jan 2020 21:00:34 -0500 Cc: EMU WG , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 02:00:44 -0000 On Jan 7, 2020, at 4:34 PM, Ryan Sleevi wrote: >=20 > I've snipped your message, because I think we've gotten to a place = where we're clearly talking past each other, as you claim I've said = several things which I've most definitely not said, or expressed the = opposite view. I'm hoping a reset here might help us find a more = productive path forward, as well as figure out where the confusion = started. OK, that sounds good.. > I think it's useful to go back to the original message from Owen, at = https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM = . Perhaps there are other messages and context I've missed, since this = was cross-posted across two WGs, but that's the starting point. I agree. It would help to have a draft. > In that, I think we've got a path forward for interoperable EAP = implementations: NAIRealm with id-kpid--eapOverLAN asserted as an EKU. = That gives a minimal sort of certificate profile to begin discussing. My only $0.02 there is that RFC 4334 defines id-kp-eapOverLAN, but = seems to imply that it is intended for *client* certificates. That = would need clarification for this use-case. > The question posed in that original message is what to do with extant = certificates and extant practices, such as going to CAs used for TLS and = asking for an id-kp-serverAuth cert, or supplicants looking for = id-kp-serverAuth, and whether to specify that. My answer to that is = categorically "no, don't do that". The use of id-kp-serverAuth is suggested in RFC 5216 Section 5.3: In the case of the EAP-TLS peer, this involves ensuring that the certificate presented by the EAP-TLS server was intended to be used as a server certificate. Implementations SHOULD use the Extended Key Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that at least one of the following is true: 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see Section 4.2.1.13 of [RFC3280]). 3) The issuer included the id-kp-serverAuth identifier in the certificate (see Section 4.2.1.13 [RFC3280]). Realistically, we can't change these recommendations in an "update EAP = for TLS 1.3" document. > This is not specific to EAP, but part of the general problem of = repurposing different trust hierarchies and different implementations, = without addressing or mitigating the ecosystem considerations. There are many OIDs assigned to extended key purpose: = https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1= .3.6.1.5.5.7.2 On quick inspection, most of those don't define their own PKI = hierarchy. So it would seem that most have the same problem. > For example, the use of such certificates outside of TLS can and will = lead to them being revoked, because one of the requirements for such = certificates is that they be used in TLS, otherwise they're revoked. Based on personal knowledge, such revocation will take down a number = of banks world-wide. And many other enterprises. Which to me, means = it's not going to happen. And how the heck is the CA going to find out? They don't have armies = of people trolling SSIDs for "mis-use" of certificates. Any user of such a certificate could point to RFC 5216, and rightly = claim that this use-case is explicitly allowed. Further, RFC 2549 defines id-kp-serverAuth as being for "TLS Web = server authentication". But it doesn't mandate that certificates get = revoked if they're used for another purpose. TBH, I'd like to see a pointer to an official CA policy saying that = such revocation is required. > Also, the changes to how PKI libraries validate TLS certificates, and = the expectations for the issuance and management of such certificates, = are at odds with the goals and objectives of interoperability being = discussed. I'm not sure why. Having spent too much time banging my head against the OpenSSL API, I = have some depressing familiarity with it. Their certificate validation = API doesn't care about extended key usage. Those checks have to be = added by the application. So... if we upgrade EAP implementations to use id-kp-eapOverLAN, then = only the EAP applications have to be updated. The common PKI libraries = don't change. > Reusing private key material across protocols and use cases does cause = issues, Such as? > just like reusing root certificates across trust purposes does cause = issues. So using the TLS PKI is and always will be fraught with peril, = and the maintainers of those TLS PKIs will disregard "your" concerns = (the equipment, software, and users), because "your" use case is = explicitly not supported and not supportable. I disagree rather fundamentally. For one, it's not "my" use-case. = It's the use-case of literally billions of devices, and of the largest = companies on the planet.=20 You're suggesting here that the root CAs will tell those people to = "get stuffed" with no repercussions. I don't see that happening. Ever. If the root CAs try something so stupid, it will be international = news, and they will get told in no uncertain terms to stop it. And they = will. > These concerns aren't unique to EAP, by any means. But they're reasons = why using id-kp-serverAuth is going down a route of trouble, and just = because it's been done by some vendors doesn't mean it's good. Not "some vendors". All vendors. BILLIONS of devices. TRILLION = DOLLAR companies. In a fight between you and them, I'll bet on them. I understand where = you're coming from, but describing this practice as "done by some = vendors" is drastically minimizing the situation. > A transition plan is always challenging, and the IETF is generally a = poor venue for figuring out those logistics, because they're often = rarely technical. For example, RFC 7585 exists: implementations "just" = need to adopt it. Or, if the desire is to have an RFC describe what the = end state should be, it should focus on that: describing the end-state. = I don't think it should specify the intermediate states, because those = are going to vary on a host of concerns, and worse, encourage folks to = stop at the intermediate state as being 'good enough'. One such example = of an intermediate state is using id-kp-serverAuth certificates, or = trying to make a public/private CA demarcation. Those are bad steps to = take. Again, this isn't an "intermediate state". This is decades-long = existing practice, and existing standards. I think part of the disconnect here is that you're not clear on just = how entrenched this use-case is. You keep saying "some vendors" or = describe it as an "intermediate state". It's simply not true, and that = false description is leading you to false conclusions. > I'm not as optimistic as you are for suggesting 'all' EAP = clients/supplicants are behaving and enforcing those extended key = usages, so that doesn't seem too unreasonable. For example, = wpa_supplicant doesn't seem to do so, in the versions used by ChromeOS, = Android, or the current tip of tree (using either the internal or the = OpenSSL implementation), and that seems like it probably covers quite a = few devices/clients. Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth. = wpa_supplicant checks for it, too. See src/tls/tlsv1_client_read.c. = The requirements of RFC 5216 Section 5.3 are followed. Yes, this means that it's theoretically possible for a site to use = *only* wpa_supplicant, and therefore not include id-kp-serverAuth in = it's EAP server certificate. But in a multi-vendor environment, the EAP = server certificate MUST include id-kp-serverAuth, otherwise many devices = will not be able to connect. I'll bet that the only EAPoL deployments which don't include = id-kp-serverAuth are (a) tests / toys, or (b) controlled environments = used only by a tiny number of devices. So id-kp-serverAuth is *entrenched*. It's not used sometimes by some = vendors. It's baked into existing standards and implementations. = Everyone uses it all of the time. Everywhere. Always. > In the TLS PKI, there's lots of industry experience on how to make = changes. These changes often involve significant risk of breakage, and = yet have become somewhat the norm, and with minimal practical impact. = These can involve setting flag days, often starting as per-vendor flag = days, such as was done with SHA-1. They can start with changes in major = releases, such as new behaviours introduced in a major OS release or a = major supplicant release to align closer to the specification or = end-state. They may involve some of the intermediate steps mentioned, = but only to the extent those are intermediate accomodations; for = example, Chrome often has Enterprise flags that allow disabling = standards-compliant behaviour when rolling out new versions, but only = for a limited time and under limited situations. These aren't, I think, = good things to specify, but they're certainly good things to share = information about. I don't know if the IETF is the best place for that, = but that's neither here nor there. However, an important part of those = experiences is that things don't move until vendors break things. Yes, = there needs to be a better path, but until you're willing to remove = support for the old, or provide incentives for the new, your users don't = and won't move. I believe a good incentive to deploy the new behaviour has been = discussed here: ease of configuration of the end-user devices. Other SDOs like the Wi-Fi alliance are moving ahead with their own = requirements on certificates. CAs will support those requirements for = the simple reason that it makes them money. > Hopefully that's easier to understand. I'm not sure how we ended up on = such different pages, but I think the assertions and requests from your = last message were a good indicator that we weren't even in the same = postal code, let alone the same page, as far as discussions go. I agree. I think some of the disconnect may be addressed here. Alan DeKok. From nobody Wed Jan 8 00:11:29 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B469512007C; Wed, 8 Jan 2020 00:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, GB_PHARMACY=1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 4NLLktBKeKW7; Wed, 8 Jan 2020 00:11:24 -0800 (PST) Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BFD120046; Wed, 8 Jan 2020 00:11:23 -0800 (PST) Received: by mail-ed1-f42.google.com with SMTP id t17so1822531eds.6; Wed, 08 Jan 2020 00:11:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sZQNsUBta3VlKi7v1mUcsTn7se5mMIVrhyWf+u0f9X0=; b=pK1bFN4O6VWvjBJomrH2MTn4JsIC4g7yl1UTPskHTDDAbQA5RNK/gljvfrKV50u9nh asL0rIN16N4HqLcc+/VA6JONoOi2lUZ8nIDdxBHJUBnMRPdp+E3gihDaZ5DKLb1uI77r 5JVJC2UCKRnO0zmSEKVjpOpyhcGrM9dImCrwUyArkDA+vzLOGoPd+48iDg4iiA1yiY0U oFba+lqeFw0iIJn8UOsSPsd6epKHVBJanKuhDbYzu28+H56z7PH9GWXW3teTlSBBUIDl jZir0BJrhvs+hnSjSLohAvBcfxTNTNR5S5wUVbrGDCGUIB9+4HAcklYUhBHHvHbeRuFD xOEw== X-Gm-Message-State: APjAAAUJk5Plh7ezB+hH5lWXNlPp7sGFPYwYKjx1i47yANW5BRK9RTgH GM5zA0+p7z3enXk5WcsHvEZcBIFl X-Google-Smtp-Source: APXvYqzMtXjGfwiJq1nSxmfCSi/x2pmNcxlnN8wYGST2oxYGj2kmV8cw5JFHkYDgKBgTziAaJ8RC+g== X-Received: by 2002:a05:6402:12d1:: with SMTP id k17mr4093381edx.291.1578471081602; Wed, 08 Jan 2020 00:11:21 -0800 (PST) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com. [209.85.128.43]) by smtp.gmail.com with ESMTPSA id m5sm50689ede.10.2020.01.08.00.11.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 00:11:21 -0800 (PST) Received: by mail-wm1-f43.google.com with SMTP id p9so1441729wmc.2; Wed, 08 Jan 2020 00:11:21 -0800 (PST) X-Received: by 2002:a1c:3c89:: with SMTP id j131mr2278386wma.34.1578471080543; Wed, 08 Jan 2020 00:11:20 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> In-Reply-To: <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> From: Ryan Sleevi Date: Wed, 8 Jan 2020 03:11:09 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: EMU WG , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000b4e31059b9c70b5" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 08:11:28 -0000 --0000000000000b4e31059b9c70b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 7, 2020 at 9:00 PM Alan DeKok wrote= : > > The question posed in that original message is what to do with extant > certificates and extant practices, such as going to CAs used for TLS and > asking for an id-kp-serverAuth cert, or supplicants looking for > id-kp-serverAuth, and whether to specify that. My answer to that is > categorically "no, don't do that". > > The use of id-kp-serverAuth is suggested in RFC 5216 Section 5.3: > > In the case of the EAP-TLS peer, this involves ensuring that the > certificate presented by the EAP-TLS server was intended to be used > as a server certificate. Implementations SHOULD use the Extended Key > Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that > at least one of the following is true: > > 1) The certificate issuer included no Extended Key Usage identifiers > in the certificate. > 2) The issuer included the anyExtendedKeyUsage identifier in the > certificate (see Section 4.2.1.13 of [RFC3280]). > 3) The issuer included the id-kp-serverAuth identifier in the > certificate (see Section 4.2.1.13 [RFC3280]). > > Realistically, we can't change these recommendations in an "update EAP > for TLS 1.3" document. For EAP-TLS, that is, where you have the full fidelity of TLS, these are fine-ish requirements. They would be bad requirements outside the context of TLS (e.g. signed assertions or other protocols). However, if using the same set or CAs that popular OSes use for TLS, it does mean that these CAs, and their customers, will still be subject to the same agility requirements, and limited to the same profile as TLS. Because of this, there=E2=80=99s ample reason to split further into the dedicated h= ierarchy and dedicated EKU. For example, no CA that is =E2=80=9Cpublicly trusted=E2=80=9D for TLS will = be able to issue a certificate with id-kp-serverAuth and also NAIRealm in the otherName, because they are contractually limited (and in some cases, legally restricted by their local operating jurisdiction) from including other forms of subjectAltNames. The use of distinct EKUs, however, would allow them to do so, because those restrictions and regulations are largely specific to id-kp-serverAuth. > This is not specific to EAP, but part of the general problem of > repurposing different trust hierarchies and different implementations, > without addressing or mitigating the ecosystem considerations. > > There are many OIDs assigned to extended key purpose: > > > https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-= 1.3.6.1.5.5.7.2 > > On quick inspection, most of those don't define their own PKI > hierarchy. So it would seem that most have the same problem. Yup. I mentioned in the prior mail, but perhaps it wasn=E2=80=99t clear, th= at many of the PKI management concepts from ITU-T don=E2=80=99t work in practice. That is, while RFC 5280 et al provide the technical flexibility for a wide variety of PKI approaches, as demonstrated through RFC 4158, and RFC 3647 provides an approach for structuring the policy, the operational concerns that arise mean that the technological flexibility isn=E2=80=99t usable or = useful in practice. RFC 5280 envisaged that two different applications that had two different policies (for example, a hypothetical Google Root store vs a hypothetical Microsoft Root store) would, on a policy level, ensure that every CA=E2=80=99s 3647-policy was compatible with and audited against thei= r requirements, and on a technical level, ensure that every certificate they ingested was mapped to a (Google || Microsoft) specific set of policies contained in the user-initial-policy-set inputs of 6.1.1 of 5280, with the Root store applying policyMappings against those trust anchors. However, that is not and has never been the case, as applications and verifications don=E2=80=99t use the user-initial-policy-set. The consequenc= e of this is that, from an administrative perspective, the policy OID is virtually entirely ignored, and more or less from the first deployment of v3 certificates, policy has been associated and imposed at the EKU level instead. That is, if a given EKU is present, then the issuing CA is contractually and administratively subject to the Root Store=E2=80=99s poli= cies and expectations, because client software and libraries does not and roughly had never used the user-initial-policy-set. In more recent times, the differences in profiles and expectations for those EKUs (such as timestampping vs email vs TLS), and the challenges in managing hierarchies that issue multiple different EKUs and ensuring the hierarchy is adequately compliant with all the expectations, even when segmented by intermediate and EKU, has seen a shift into separating out the hierarchies such that a given hierarchy (root and all intermediates) ONLY issue certain types of certificates. This makes the CP/CPS manageable for the root store to consume, and manageable for the process of assessing and auditing. I apologize for the length of this, but it=E2=80=99s meant to underscore th= at the flexibility afforded by 5280/3647 is not usable in practice, not as idealized in the early 90s when the PKI Gold Rush was going on and folks like the ABA were figuring out how to audit/assess (c.f. the PKI Assessment Guidelines that would coevolve into/influence ISO 21188 and later WebTrust). The hyperfederated models in 4158 work on a technical level, but not on a practical level, certainly not on an Internet level, and simplicity is preferred and encouraged. > For example, the use of such certificates outside of TLS can and will > lead to them being revoked, because one of the requirements for such > certificates is that they be used in TLS, otherwise they're revoked. > > Based on personal knowledge, such revocation will take down a number of > banks world-wide. And many other enterprises. Which to me, means it's n= ot > going to happen. Folks used to say the same about certain prominent root CAs: that they were =E2=80=9Ctoo big to fail=E2=80=9D. The reality is that while I suspect you= =E2=80=99re right that the CA is strongly incentivized not to follow their own stated policies when those policies would cause harm, in many cases, they are contractually or legally bound to do so; e.g. they=E2=80=99re required to follow their po= licies by the root stores they are included in, and if they fail to do so, they are removed from those root stores. As removal from the root stores means things go from =E2=80=9Cone customer impacted=E2=80=9D to =E2=80=9Call cust= omers impacted=E2=80=9D, or impact the viability of the business model of the CA, the root CA is strongly incentivized to follow their policies over special favors for that customer. There are countless examples of this in the TLS PKI, because allowing CAs to selectively ignore stated policies to appease certain customers is, at its core, indistinguishable from malice or compromise from the point of view or those who trust that CA. Major companies have had their certificates revoked even when it left software or services non-functional. If there is any theme from the TLS PKI for the past 5 years, it=E2=80=99s b= een =E2=80=9CI=E2=80=99m sorry, that=E2=80=99s unfortunate, but for the greater good you MUST be bro= ken because you=E2=80=99re certificate does not conform.=E2=80=9D > And how the heck is the CA going to find out? They don't have armies o= f > people trolling SSIDs for "mis-use" of certificates. Perhaps it wasn=E2=80=99t clear why I linked to that Atlassian issue in The Register, but the point in doing so was to highlight that _anyone_ can report to the CA when a customer is doing something problematic. For the set of =E2=80=9Cpublicly trusted=E2=80=9D CAs, the policies they are govern= ed by require them to make available problem reporting mechanisms, to respond to those within 24 hours, and if a violation, to revoke within 24 hours to five days= . This is also why I kept emphasizing the timebomb nature of it: your Wifi may totally work, until all of a sudden someone decides to report it to the CA, which obligates the CA to revoke. Any user of such a certificate could point to RFC 5216, and rightly claim > that this use-case is explicitly allowed. > > Further, RFC 2549 defines id-kp-serverAuth as being for "TLS Web server > authentication". But it doesn't mandate that certificates get revoked if > they're used for another purpose. > > TBH, I'd like to see a pointer to an official CA policy saying that suc= h > revocation is required. As part of (Day Job), I review the policies of every CA our software decides to trust, in detail. I also manage what our expectations are for the CAs we trust. A common set of expectations is the CA/Browser Forum=E2=80=99s Baseline Requirements. Section 4.9.1.1 enshrines a number of common expectations of revocation, although both root stores and CAs are free to add more. For example, Microsoft=E2=80=99s policies and contracts, at https://aka.ms/root= cert, require prompt revocation if Microsoft=E2=80=99s directs this, under some circumstances. Section 4.9.1.1 of the BRs requires revocation for =E2=80=9Cmisuse=E2=80=9D= . Misuse is intentionally (by the root programs, at least; some CAs marketing departments would prefer otherwise) not defined by the BRs; that=E2=80=99s something the CA defines, but is required to define. In RFC 3647, this is often tied to Section 4.4.5, which maps to Section 1.4 of the CA=E2=80=99s = CP/CPS, although in practice CAs split this definition up all over their CP/CPS. An example of a recent CP/CPS review, where I flagged concerns over how a CA expressed in their CP/CPS what acceptable uses were in Section 1.4, is https://bugzilla.mozilla.org/show_bug.cgi?id=3D1403453#c13 . Here, the CA arguably prohibited the use of their certificates in TLS servers altogether, which is pretty shocking, and why I flagged it. In practice, the CP/CPSes I review place restrictions that limit a certificate to TLS, and prohibit the use of the private key to sign other things. In general, that=E2=80=99s a good definition of =E2=80=9Cmisuse=E2=80=9D, but it does m= ean that using such certificates in other contexts (e.g. to sign documents) will cause 1.4 to be violated, which means anyone in the world will be able to request that certificate be revoked, at any time, and the CA have contractual obligations to do so if they wish to remain trusted. > Also, the changes to how PKI libraries validate TLS certificates, and the > expectations for the issuance and management of such certificates, are at > odds with the goals and objectives of interoperability being discussed. > > I'm not sure why. > > Having spent too much time banging my head against the OpenSSL API, I > have some depressing familiarity with it. Their certificate validation A= PI > doesn't care about extended key usage. Those checks have to be added by > the application. > > So... if we upgrade EAP implementations to use id-kp-eapOverLAN, then > only the EAP applications have to be updated. The common PKI libraries > don't change. I agree that this goes away if you use an explicit EKU; the problem I was describing exists only if the profile tries to require id-kp-serverAuth. > Reusing private key material across protocols and use cases does cause > issues, > > Such as? https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-felsc= h.pdf https://www.usenix.org/sites/default/files/conference/protected-files/secur= ity16_slides_aviram.pdf https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2015/08/21= /Tls13QuicAttacks.pdf I=E2=80=99m sure everyone=E2=80=99s got a favorite citation, but the TLS WG= spent so long on formal security proofs in part because of the number of issues that resulted from the negotiation and key reuse across TLS versions, which are functionally =E2=80=9Cdifferent=E2=80=9D protocols. > just like reusing root certificates across trust purposes does cause > issues. So using the TLS PKI is and always will be fraught with peril, an= d > the maintainers of those TLS PKIs will disregard "your" concerns (the > equipment, software, and users), because "your" use case is explicitly no= t > supported and not supportable. > > I disagree rather fundamentally. For one, it's not "my" use-case. It'= s > the use-case of literally billions of devices, and of the largest compani= es > on the planet. > > You're suggesting here that the root CAs will tell those people to "get > stuffed" with no repercussions. I don't see that happening. Ever. You=E2=80=99re right that we disagree. However, it=E2=80=99s important to n= ote: I didn=E2=80=99t say no repercussion. In these situations, the CA is between a rock and a hard place: they can follow their stated policies and contractual obligations, which generally means breaking their customer because either the CA or the customer did something wrong, or they can violate their stated policies and obligations and risk distrust by the vendors that trust them. This is the inherent challenge in any third-party operates CA: you can=E2=80=99t delegate trust. A good example of this is the use of underscores in domain names in certificates. Underscores are not part of the preferred name syntax, and thus are not conformant with RFC5280 for inclusion within a subjectAltName, even if they=E2=80=99re valid DNS labels (since DNS is 8-bits of goodness).= Since resolving libraries were generally more than =E2=80=9Cjust=E2=80=9D DNS and= didn=E2=80=99t enforce the preferred name syntax on inputs, the use of underscores in DNS hostnames slowly crept in to the ecosystem, with major operating systems like Windows allowing them and resolving such names. TLS CAs are obligated to follow 5280, and there were a few CAs that ignored this requirement of 5280, and issued such invalid and unauthorized certificates. Browsers declared that they must revoke these non-conforming certificates. Yet this broke high-profile customers like Verizon, CIBC, CVS Pharmacy, Discover, Citi, Intuit, and Ericsson. That=E2=80=99s a veritabl= e who=E2=80=99s who of healthcare, banking, and telecom - and yet they were still broken none the less, because the harm to them was outweighed by the harm caused by selective and arbitrary compliance and enforcement. Were they happy with their CA (and with root stores)? Oh no. Some of them definitely changed their CA after that, and many harsh and heated threats were sent to root store vendors. But, it happened. Those certificates were revoked. The solution for problems like this is to make sure you don=E2=80=99t overl= ap with the requirements of other consumers, and why using the separate EKU, which is the most common way to free yourself of those requirements, is the best bet. That said, it may not totally free you. For example, Cisco could contractually require every CA that Cisco trusts follows Cisco=E2=80=99s po= licies, and so if Cisco forbid something your implementation wanted to do or use, y=E2=80=99all would not be able to use the same set of CAs. That=E2=80=99s = the interoperability challenge I was referencing, and how to resolve that is arguably beyond the ken of the IETF. If the root CAs try something so stupid, it will be international news, > and they will get told in no uncertain terms to stop it. And they will. Hah, you and I live in very different worlds than how CAs are managed. I didn=E2=80=99t see much international news when the SHA-1 deprecation in = the TLS PKI reportedly threatened to leave entire countries unable to process payments, did you? Even stuff like https://blog.mozilla.org/security/2016/02/24/payment-processors-still-using= -weak-crypto/ got very little attention. Certainly, I think there=E2=80=99s still only a = handful of people who could name which CA surreptitiously backdated SHA-1 certificates for which payment processor company, in violation of their policies and requirements, seemingly in order to attract business from them (as the payment processor used a different CA, and that existing CA followed the rules). > These concerns aren't unique to EAP, by any means. But they're reasons > why using id-kp-serverAuth is going down a route of trouble, and just > because it's been done by some vendors doesn't mean it's good. > > Not "some vendors". All vendors. BILLIONS of devices. TRILLION > DOLLAR companies. > > In a fight between you and them, I'll bet on them. I understand where > you're coming from, but describing this practice as "done by some vendors= " > is drastically minimizing the situation. I=E2=80=99m not sure how this isn=E2=80=99t a full-throated support for the= broken and dangerous status quo. There=E2=80=99s a way forward here, and change is pos= sible. I fully acknowledge that customer satisfaction often triumphs over technical considerations, and customers are most satisfied when they have the least work to do. However, it is possible to change things, even in ways that may break backwards compatibility, and folks do it all the time. The context in this is largely around making it zero-config, which is entirely laudable goal, but inherently Something New and thus the absolute best opportunity to break things. > A transition plan is always challenging, and the IETF is generally a poor > venue for figuring out those logistics, because they're often rarely > technical. For example, RFC 7585 exists: implementations "just" need to > adopt it. Or, if the desire is to have an RFC describe what the end state > should be, it should focus on that: describing the end-state. I don't thi= nk > it should specify the intermediate states, because those are going to var= y > on a host of concerns, and worse, encourage folks to stop at the > intermediate state as being 'good enough'. One such example of an > intermediate state is using id-kp-serverAuth certificates, or trying to > make a public/private CA demarcation. Those are bad steps to take. > > Again, this isn't an "intermediate state". This is decades-long > existing practice, and existing standards. > I think part of the disconnect here is that you're not clear on just ho= w > entrenched this use-case is. You keep saying "some vendors" or describe = it > as an "intermediate state". It's simply not true, and that false > description is leading you to false conclusions. I agree that we have a disconnect, but the context here is from Owen=E2=80= =99s original message, and I get the feeling you have a different design or conclusion that you=E2=80=99ve not expressed but are operating on, or that = I=E2=80=99ve fundamentally misunderstood. That original discussion was in the context of public CAs. In the world of locally-configured or private CAs, I don=E2=80=99t have as strong opinions. However, if the objective is to get to an end state where EAP is =E2=80=9Cs= ecure by default=E2=80=9D and any EAP operator can =E2=80=9Cjust=E2=80=9D get a cert= ificate, then any discussion about id-kp-serverAuth isn=E2=80=99t the extant status quo. Further, the nice thing about private or locally configured certificates is they provide a very easy transition plan, because you know =E2=80=9Csomeone= =E2=80=9D generated the certificate and can generate the =E2=80=9Cright=E2=80=9D thin= g when it=E2=80=99s required by a client. The nice thing about EKUs being a SEQUENCE is with everything we=E2=80=99ve been discussing, it=E2=80=99s possible to support = both Old and New for private use simultaneously, while the zero-touch world can *only* use New. > I'm not as optimistic as you are for suggesting 'all' EAP > clients/supplicants are behaving and enforcing those extended key usages, > so that doesn't seem too unreasonable. For example, wpa_supplicant doesn'= t > seem to do so, in the versions used by ChromeOS, Android, or the current > tip of tree (using either the internal or the OpenSSL implementation), an= d > that seems like it probably covers quite a few devices/clients. > > Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth. > wpa_supplicant checks for it, too. See src/tls/tlsv1_client_read.c. The > requirements of RFC 5216 Section 5.3 are followed. Thanks for the pointer! Applying it post-validation is definitely an interesting strategy, given the operational considerations and issues like https://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf that can allow for EKUs to bleed across hierarchies. I had mistakenly looked on the validation side, since that=E2=80=99s where the identity validation occurs. However, that=E2=80=99s still not intrinsically at odds with the original m= essage to Owen, or with the design principles I=E2=80=99ve been trying to capture = in these replies, which is that if the desire to is to have zero-touch auth, you need to do one of the following: 1) Define a new, non-overlapping trust store (whether for id-kp-serverAuth or for id-kp-eapOverLan) with its own profile and policies or 2) Accept that any use of a shared or overlapping trust store will be subject to the agility requirements of the existing trust stores (read: OSes and browsers) #2 is almost always going to work out badly for users and deployments, which is why I=E2=80=99m so strongly discouraging it, even if it=E2=80=99s = technically viable, and so it=E2=80=99s best to accept the cost of #1 upfront rather th= an defer it. So id-kp-serverAuth is *entrenched*. It's not used sometimes by some > vendors. It's baked into existing standards and implementations. Everyo= ne > uses it all of the time. Everywhere. Always. And going back to the original message: is everyone always using public CAs? I got the impression that our experiences are similar: which is that it requires manual and explicit configuration, and there=E2=80=99s no =E2= =80=9Cout of the box=E2=80=9D trust store here, and that the use of public CAs is not a conc= ept that can MSP, because inherently, these are all manually configured.- I believe a good incentive to deploy the new behaviour has been discussed > here: ease of configuration of the end-user devices. > > Other SDOs like the Wi-Fi alliance are moving ahead with their own > requirements on certificates. CAs will support those requirements for th= e > simple reason that it makes them money. Sure, but Wi-Fi Alliance is also doing the thing I=E2=80=99ve been encourag= ing: defining their own trust store. A CA trusted for TLS today cannot comply with root program requirements and issue Passpoint certificates. The profiles are incompatible, which is fine, as long as you don=E2=80=99t have= trust overlap. And that=E2=80=99s true everywhere but Windows right now, or at le= ast when I last did the CP/CPS reviews three months ago. My issue with Owen=E2=80=99s original proposal, and hopefully it remains cl= ear here: overlapping the PKIs should be a non-goal. Distinguishing them at the EKU is fine; distinguishing them at the EKU so extant CAs can issue from extant trust hierarchies is problematic and should be a non-goal. At the same time, changing the EKU in order to change the profile, and having supplicants strictly enforce that profile, _is_ a good idea, in as much as it allows you to explicitly transition to a sensible and defined profile and make a clean break. --0000000000000b4e31059b9c70b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


> The question posed in that original message is what to do with extant = certificates and extant practices, such as going to CAs used for TLS and as= king for an id-kp-serverAuth cert, or supplicants looking for id-kp-serverA= uth, and whether to specify that. My answer to that is categorically "= no, don't do that".

=C2=A0 The use of id-kp-serverAuth is suggested in RFC 5216 Section 5.3:
=C2=A0 =C2=A0In the case of the EAP-TLS peer, this involves ensuring that t= he
=C2=A0 =C2=A0certificate presented by the EAP-TLS server was intended to be= used
=C2=A0 =C2=A0as a server certificate.=C2=A0 Implementations SHOULD use the = Extended Key
=C2=A0 =C2=A0Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure= that
=C2=A0 =C2=A0at least one of the following is true:

=C2=A0 =C2=A01) The certificate issuer included no Extended Key Usage ident= ifiers
=C2=A0 =C2=A0 =C2=A0 in the certificate.
=C2=A0 =C2=A02) The issuer included the anyExtendedKeyUsage identifier in t= he
=C2=A0 =C2=A0 =C2=A0 certificate (see Section 4.2.1.13 of [RFC3280]).
=C2=A0 =C2=A03) The issuer included the id-kp-serverAuth identifier in the<= br> =C2=A0 =C2=A0 =C2=A0 certificate (see Section 4.2.1.13 [RFC3280]).

=C2=A0 Realistically, we can't change these recommendations in an "= ;update EAP for TLS 1.3" document.

<= /div>
For EAP-TLS, that is, where you have the full fideli= ty of TLS, these are fine-ish requirements. They would be bad requirements = outside the context of TLS (e.g. signed assertions or other protocols).

However, if using the same = set or CAs that popular OSes use for TLS, it does mean that these CAs, and = their customers, will still be subject to the same agility requirements, an= d limited to the same profile as TLS. Because of this, there=E2=80=99s ampl= e reason to split further into the dedicated hierarchy and dedicated EKU.

For example, no CA that i= s =E2=80=9Cpublicly trusted=E2=80=9D for TLS will be able to issue a certif= icate with id-kp-serverAuth and also NAIRealm in the otherName, because the= y are contractually limited (and in some cases, legally restricted by their= local operating jurisdiction) from including other forms of subjectAltName= s. The use of distinct EKUs, however, would allow them to do so, because th= ose restrictions and regulations are largely specific to id-kp-serverAuth.<= /div>

> This is not specific to EAP, but part of the general problem of repurp= osing different trust hierarchies and different implementations, without ad= dressing or mitigating the ecosystem considerations.

=C2=A0 There are many OIDs assigned to extended key purpose:

https://www.= iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.= 2

=C2=A0 On quick inspection, most of those don't define their own PKI hi= erarchy.=C2=A0 So it would seem that most have the same problem.

Yup. I mentioned in the pri= or mail, but perhaps it wasn=E2=80=99t clear, that many of the PKI manageme= nt concepts from ITU-T don=E2=80=99t work in practice.

That is, while RFC 5280 et al provide the te= chnical flexibility for a wide variety of PKI approaches, as demonstrated t= hrough RFC 4158, and RFC 3647 provides an approach for structuring the poli= cy, the operational concerns that arise mean that the technological flexibi= lity isn=E2=80=99t usable or useful in practice. RFC 5280 envisaged that tw= o different applications that had two different policies (for example, a hy= pothetical Google Root store vs a hypothetical Microsoft Root store) would,= on a policy level, ensure that every CA=E2=80=99s 3647-policy was compatib= le with and audited against their requirements, and on a technical level, e= nsure that every certificate they ingested was mapped to a (Google || Micro= soft) specific set of policies contained in the=C2=A0user-initial-policy-set inputs of 6.1.1 of 5280, with the Root stor= e applying policyMappings against those trust anchors.

= However, that is not and has never been the c= ase, as applications and verifications don=E2=80=99t use the user-initial-p= olicy-set. The consequence of this is that, from an administrative perspect= ive, the policy OID is virtually entirely ignored, and more or less from th= e first deployment of v3 certificates, policy has been associated and impos= ed at the EKU level instead. That is, if a given EKU is present, then the i= ssuing CA is contractually and administratively subject to the Root Store= =E2=80=99s policies and expectations, because client software and libraries= does not and roughly had never used the user-initial-policy-set.

In more recent times, the differen= ces in profiles and expectations for those EKUs (such as timestampping vs e= mail vs TLS),=C2=A0and the challenges = in managing hierarchies that issue multiple different EKUs and ensuring the= hierarchy is adequately compliant with all the expectations, even when seg= mented by intermediate and EKU, has seen a shift into separating out the hi= erarchies such that a given hierarchy (root and all intermediates) ONLY iss= ue certain types of certificates. This makes the CP/CPS manageable for the = root store to consume, and manageable for the process of assessing and audi= ting.

I apologize for the= length of this, but it=E2=80=99s meant to underscore that the flexibility = afforded by 5280/3647 is not usable in practice, not as idealized in the ea= rly 90s when the PKI Gold Rush was going on and folks like the ABA were fig= uring out how to audit/assess (c.f. the PKI Assessment Guidelines that woul= d coevolve into/influence ISO 21188 and later WebTrust). The hyperfederated= models in 4158 work on a technical level, but not on a practical level, ce= rtainly not on an Internet level, and simplicity is preferred and encourage= d.

<= /div>
> For example, the use of such certificates outside of TLS can and will = lead to them being revoked, because one of the requirements for such certif= icates is that they be used in TLS, otherwise they're revoked.

=C2=A0 Based on personal knowledge, such revocation will take down a number= of banks world-wide.=C2=A0 And many other enterprises.=C2=A0 Which to me, = means it's not going to happen.

Folks used to say the same about certain prominent root = CAs: that they were =E2=80=9Ctoo big to fail=E2=80=9D. The reality is that = while I suspect you=E2=80=99re right that the CA is strongly incentivized n= ot to follow their own stated policies when those policies would cause harm= , in many cases, they are contractually or legally bound to do so; e.g. the= y=E2=80=99re required to follow their policies by the root stores they are = included in, and if they fail to do so, they are removed from those root st= ores. As removal from the root stores means things go from =E2=80=9Cone cus= tomer impacted=E2=80=9D to =E2=80=9Call customers impacted=E2=80=9D, or imp= act the viability of the business model of the CA, the root CA is strongly = incentivized to follow their policies over special favors for that customer= .

There are countless ex= amples of this in the TLS PKI, because allowing CAs to selectively ignore s= tated policies to appease certain customers is, at its core, indistinguisha= ble from malice or compromise from the point of view or those who trust tha= t CA. Major companies have had their certificates revoked even when it left= software or services non-functional. If there is any theme from the TLS PK= I for the past 5 years, it=E2=80=99s been =E2=80=9CI=E2=80=99m sorry, that= =E2=80=99s unfortunate, but for the greater good you MUST be broken because= you=E2=80=99re certificate does not conform.=E2=80=9D


=C2=A0 And how the heck is the CA going to find out?=C2=A0 They don't h= ave armies of people trolling SSIDs for "mis-use" of certificates= .

Perhaps it wasn= =E2=80=99t clear why I linked to that Atlassian issue in The Register, but = the point in doing so was to highlight that _anyone_ can report to the CA w= hen a customer is doing something problematic. For the set of =E2=80=9Cpubl= icly trusted=E2=80=9D CAs, the policies they are governed by require them t= o make available problem reporting mechanisms, to respond to those within 2= 4 hours, and if a violation, to revoke within 24 hours to five days.
<= div dir=3D"auto">
This is also why I kept emphas= izing the timebomb nature of it: your Wifi may totally work, until all of a= sudden someone decides to report it to the CA, which obligates the CA to r= evoke.

=C2=A0 Any user of such a certificate could point to RFC 5216, and rightly = claim that this use-case is explicitly allowed.

=C2=A0 Further, RFC 2549 defines id-kp-serverAuth as being for "TLS We= b server authentication".=C2=A0 But it doesn't mandate that certif= icates get revoked if they're used for another purpose.

=C2=A0 TBH, I'd like to see a pointer to an official CA policy saying t= hat such revocation is required.

As part of (Day Job), I review the policies of every CA our= software decides to trust, in detail. I also manage what our expectations = are for the CAs we trust.

A common set of expectations is the CA/Browser Forum=E2=80=99s Baseline R= equirements. Section 4.9.1.1 enshrines a number of common expectations of r= evocation, although both root stores and CAs are free to add more. For exam= ple, Microsoft=E2=80=99s policies and contracts, at https://aka.ms/rootcert, require prompt revocation if Micr= osoft=E2=80=99s directs this, under some circumstances.

Section 4.9.1.1 of the BRs requires revocat= ion for =E2=80=9Cmisuse=E2=80=9D. Misuse is intentionally (by the root prog= rams, at least; some CAs marketing departments would prefer otherwise) not = defined by the BRs; that=E2=80=99s something the CA defines, but is require= d to define. In RFC 3647, this is often tied to Section 4.4.5, which maps t= o Section 1.4 of the CA=E2=80=99s CP/CPS, although in practice CAs split th= is definition up all over their CP/CPS.

An example of a recent CP/CPS review, where I flagged conce= rns over how a CA expressed in their CP/CPS what acceptable uses were in Se= ction 1.4, is=C2=A0
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1403453#= c13 . Here, the CA arguably prohibited the use of their certificates in= TLS servers altogether, which is pretty shocking, and why I flagged it. In= practice, the CP/CPSes I review place restrictions that limit a certificat= e to TLS, and prohibit the use of the private key to sign other things. In = general, that=E2=80=99s a good definition of =E2=80=9Cmisuse=E2=80=9D, but = it does mean that using such certificates in other contexts (e.g. to sign d= ocuments) will cause 1.4 to be violated, which means anyone in the world wi= ll be able to request that certificate be revoked, at any time, and the CA = have contractual obligations to do so if they wish to remain trusted.
=

> Also, the changes to how PKI libraries validate TLS certificates, and = the expectations for the issuance and management of such certificates, are = at odds with the goals and objectives of interoperability being discussed.<= br>
=C2=A0 I'm not sure why.

=C2=A0 Having spent too much time banging my head against the OpenSSL API, = I have some depressing familiarity with it.=C2=A0 Their certificate validat= ion API doesn't care about extended key usage.=C2=A0 Those checks have = to be added by the application.

=C2=A0 So... if we upgrade EAP implementations to use id-kp-eapOverLAN, the= n only the EAP applications have to be updated.=C2=A0 The common PKI librar= ies don't change.

I agree that this goes away if you use an explicit EKU; the problem I = was describing exists only if the profile tries to require id-kp-serverAuth= .

> Reusing private key material across protocols and use cases does cause= issues,

=C2=A0 Such as?

I=E2=80=99m sure everyone=E2=80=99s got a= favorite citation, but the TLS WG spent so long on formal security proofs = in part because of the number of issues that resulted from the negotiation = and key reuse across TLS versions, which are functionally =E2=80=9Cdifferen= t=E2=80=9D protocols.

> just like reusing root certificates across trust purposes does cause i= ssues. So using the TLS PKI is and always will be fraught with peril, and t= he maintainers of those TLS PKIs will disregard "your" concerns (= the equipment, software, and users), because "your" use case is e= xplicitly not supported and not supportable.

=C2=A0 I disagree rather fundamentally.=C2=A0 For one, it's not "m= y" use-case.=C2=A0 It's the use-case of literally billions of devi= ces, and of the largest companies on the planet.

=C2=A0 You're suggesting here that the root CAs will tell those people = to "get stuffed" with no repercussions.=C2=A0 I don't see tha= t happening.=C2=A0 Ever.

You=E2=80=99re right that we disagree. However, it=E2=80=99s impo= rtant to note: I didn=E2=80=99t say no repercussion.

In these situations, the CA is between a rock = and a hard place: they can follow their stated policies and contractual obl= igations, which generally means breaking their customer because either the = CA or the customer did something wrong, or they can violate their stated po= licies and obligations and risk distrust by the vendors that trust them. Th= is is the inherent challenge in any third-party operates CA: you can=E2=80= =99t delegate trust.

A g= ood example of this is the use of underscores in domain names in certificat= es. Underscores are not part of the preferred name syntax, and thus are not= conformant with RFC5280 for inclusion within a subjectAltName, even if the= y=E2=80=99re valid DNS labels (since DNS is 8-bits of goodness). Since reso= lving libraries were generally more than =E2=80=9Cjust=E2=80=9D DNS and did= n=E2=80=99t enforce the preferred name syntax on inputs, the use of undersc= ores in DNS hostnames slowly crept in to the ecosystem, with major operatin= g systems like Windows allowing them and resolving such names.

TLS CAs are obligated to follow 5280= , and there were a few CAs that ignored this requirement of 5280, and issue= d such invalid and unauthorized certificates. Browsers declared that they m= ust revoke these non-conforming certificates. Yet this broke high-profile c= ustomers like Verizon, CIBC, CVS =C2=A0 Pharmacy, Discover, Citi, Intuit, a= nd Ericsson. That=E2=80=99s a veritable who=E2=80=99s who of healthcare, ba= nking, and telecom - and yet they were still broken none the less, because = the harm to them was outweighed by the harm caused by selective and arbitra= ry compliance and enforcement. Were they happy with their CA (and with root= stores)? Oh no. Some of them definitely changed their CA after that, and m= any harsh and heated threats were sent to root store vendors. But, it happe= ned. Those certificates were revoked.

The solution for problems like this is to make sure you don= =E2=80=99t overlap with the requirements of other consumers, and why using = the separate EKU, which is the most common way to free yourself of those re= quirements, is the best bet.

That said, it may not totally free you. For example, Cisco could contr= actually require every CA that Cisco trusts follows Cisco=E2=80=99s policie= s, and so if Cisco forbid something your implementation wanted to do or use= , y=E2=80=99all would not be able to use the same set of CAs. That=E2=80=99= s the interoperability challenge I was referencing, and how to resolve that= is arguably beyond the ken of the IETF.=C2=A0

<= /div>
=C2=A0 =C2=A0If the root CAs try something so stupid, it will be internatio= nal news, and they will get told in no uncertain terms to stop it.=C2=A0 An= d they will.

Hah,= you and I live in very different worlds than how CAs are managed.

I didn=E2=80=99t see much intern= ational news when the SHA-1 deprecation in the TLS PKI reportedly threatene= d to leave entire countries unable to process payments, did you? Even stuff= like=C2=A0
https://b= log.mozilla.org/security/2016/02/24/payment-processors-still-using-weak-cry= pto/ got very little attention. Certainly, I think there=E2=80=99s stil= l only a handful of people who could name which CA surreptitiously backdate= d SHA-1 certificates for which payment processor company, in violation of t= heir policies and requirements, seemingly in order to attract business from= them (as the payment processor used a different CA, and that existing CA f= ollowed the rules).

> These concerns aren't unique to EAP, by any means. But they're= reasons why using id-kp-serverAuth is going down a route of trouble, and j= ust because it's been done by some vendors doesn't mean it's go= od.

=C2=A0 Not "some vendors".=C2=A0 =C2=A0All vendors.=C2=A0 BILLION= S of devices.=C2=A0 TRILLION DOLLAR companies.

=C2=A0 In a fight between you and them, I'll bet on them.=C2=A0 I under= stand where you're coming from, but describing this practice as "d= one by some vendors" is drastically minimizing the situation.

I=E2=80=99m not sure how = this isn=E2=80=99t a full-throated support for the broken and dangerous sta= tus quo. There=E2=80=99s a way forward here, and change is possible. I full= y acknowledge that customer satisfaction often triumphs over technical cons= iderations, and customers are most satisfied when they have the least work = to do. However, it is possible to change things, even in ways that may brea= k backwards compatibility, and folks do it all the time.

The context in this is largely around maki= ng it zero-config, which is entirely laudable goal, but inherently Somethin= g New and thus the absolute best opportunity to break things.

> A transition plan is always challenging, and the IETF is generally a p= oor venue for figuring out those logistics, because they're often rarel= y technical. For example, RFC 7585 exists: implementations "just"= need to adopt it. Or, if the desire is to have an RFC describe what the en= d state should be, it should focus on that: describing the end-state. I don= 't think it should specify the intermediate states, because those are g= oing to vary on a host of concerns, and worse, encourage folks to stop at t= he intermediate state as being 'good enough'. One such example of a= n intermediate state is using id-kp-serverAuth certificates, or trying to m= ake a public/private CA demarcation. Those are bad steps to take.

=C2=A0 =C2=A0Again, this isn't an "intermediate state".=C2=A0= This is decades-long existing practice, and existing standards.

=C2=A0 I think part of the disconnect here is that you're not clear on = just how entrenched this use-case is.=C2=A0 You keep saying "some vend= ors" or describe it as an "intermediate state".=C2=A0 It'= ;s simply not true, and that false description is leading you to false conc= lusions.

I agree = that we have a disconnect, but the context here is from Owen=E2=80=99s orig= inal message, and I get the feeling you have a different design or conclusi= on that you=E2=80=99ve not expressed but are operating on, or that I=E2=80= =99ve fundamentally misunderstood.

That original discussion was in the context of public CAs. In th= e world of locally-configured or private CAs, I don=E2=80=99t have as stron= g opinions. However, if the objective is to get to an end state where EAP i= s =E2=80=9Csecure by default=E2=80=9D and any EAP operator can =E2=80=9Cjus= t=E2=80=9D get a certificate, then any discussion about id-kp-serverAuth is= n=E2=80=99t the extant status quo.

Further, the nice thing about private or locally configured cert= ificates is they provide a very easy transition plan, because you know =E2= =80=9Csomeone=E2=80=9D generated the certificate and can generate the =E2= =80=9Cright=E2=80=9D thing when it=E2=80=99s required by a client. The nice= thing about EKUs being a SEQUENCE is with everything we=E2=80=99ve been di= scussing, it=E2=80=99s possible to support both Old and New for private use= simultaneously, while the zero-touch world can *only* use New.

> I'm not as optimistic as you are for suggesting 'all' EAP = clients/supplicants are behaving and enforcing those extended key usages, s= o that doesn't seem too unreasonable. For example, wpa_supplicant doesn= 't seem to do so, in the versions used by ChromeOS, Android, or the cur= rent tip of tree (using either the internal or the OpenSSL implementation),= and that seems like it probably covers quite a few devices/clients.

=C2=A0 Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth.= =C2=A0 wpa_supplicant checks for it, too.=C2=A0 See src/tls/tlsv1_client_re= ad.c.=C2=A0 The requirements of RFC 5216 Section 5.3 are followed.

Thanks for the pointer! A= pplying it post-validation is definitely an interesting strategy, given the= operational considerations and issues like=C2=A0
https://trailofbits.fi= les.wordpress.com/2012/06/flame-md5.pdf that can allow for EKUs to blee= d across hierarchies. I had mistakenly looked on the validation side, since= that=E2=80=99s where the identity validation occurs.

However, that=E2=80=99s still not intrinsical= ly at odds with the original message to Owen, or with the design principles= I=E2=80=99ve been trying to capture in these replies, which is that if the= desire to is to have zero-touch auth, you need to do one of the following:=
1) Define a new, non-overlapping trust store (wheth= er for id-kp-serverAuth or for id-kp-eapOverLan) with its own profile and p= olicies or
2) Accept that any use of a shared or ove= rlapping trust store will be subject to the agility requirements of the exi= sting trust stores (read: OSes and browsers)

#2 is almost always going to work out badly for users = and deployments, which is why I=E2=80=99m so strongly discouraging it, even= if it=E2=80=99s technically viable, and so it=E2=80=99s best to accept the= cost of #1 upfront rather than defer it.

=
=C2=A0 So id-kp-serverAuth is *entrenched*.=C2=A0 It's not used sometim= es by some vendors.=C2=A0 It's baked into existing standards and implem= entations.=C2=A0 Everyone uses it all of the time.=C2=A0 Everywhere.=C2=A0 = Always.

And going= back to the original message: is everyone always using public CAs? I got t= he impression that our experiences are similar: which is that it requires m= anual and explicit configuration, and there=E2=80=99s no =E2=80=9Cout of th= e box=E2=80=9D trust store here, and that the use of public CAs is not a co= ncept that can MSP, because inherently, these are all manually configured.-=

I believe a good incen= tive to deploy the new behaviour has been discussed here: ease of configura= tion of the end-user devices.

=C2=A0 Other SDOs like the Wi-Fi alliance are moving ahead with their own r= equirements on certificates.=C2=A0 CAs will support those requirements for = the simple reason that it makes them money.
<= br>
Sure, but Wi-Fi Alliance is also doing the thing= I=E2=80=99ve been encouraging: defining their own trust store. A CA truste= d for TLS today cannot comply with root program requirements and issue Pass= point certificates. The profiles are incompatible, which is fine, as long a= s you don=E2=80=99t have trust overlap. And that=E2=80=99s true everywhere = but Windows right now, or at least when I last did the CP/CPS reviews three= months ago.

My issue wi= th Owen=E2=80=99s original proposal, and hopefully it remains clear here: o= verlapping the PKIs should be a non-goal. Distinguishing them at the EKU is= fine; distinguishing them at the EKU so extant CAs can issue from extant t= rust hierarchies is problematic and should be a non-goal. At the same time,= changing the EKU in order to change the profile, and having supplicants st= rictly enforce that profile, _is_ a good idea, in as much as it allows you = to explicitly transition to a sensible and defined profile and make a clean= break.
--0000000000000b4e31059b9c70b5-- From nobody Wed Jan 8 02:00:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251D212013F; Wed, 8 Jan 2020 02:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=D8tGQTNC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TRwPGZyB 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 7o93SwTGGm12; Wed, 8 Jan 2020 02:00:35 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22EF120018; Wed, 8 Jan 2020 02:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3457; q=dns/txt; s=iport; t=1578477634; x=1579687234; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AJoT9RmVKCIBJsYu/ea+Jr3ra3c//TOP1mrdek3EglQ=; b=D8tGQTNCnofeEIDKpOg8aDIv61PmM8YzHC+dmwzOs9Tz6Isgr9zuk6WW DpmPv1TFSA6aOrTXdBY2ENw2Bcvo1SbLGBwzAApeY0nvBDGeAk6MUtP5X iz1I5mowpgJfck7mESIiAob0Aa+HABKYKKzJeodxtrtnDNATMNz+HoiD9 U=; IronPort-PHdr: =?us-ascii?q?9a23=3A4FPByhBTU3beDEIv5WKiUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg93kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIfrnZjYSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAAA5pxVe/4ENJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoFAQELAYEkL1AFgUQgBAsqhAmDRgOLBoI6k1CEYoEugSQDVAk?= =?us-ascii?q?BAQEMAQEtAgEBhEACF4FSJDYHDgIDDQEBBAEBAQIBBQRthTcMhV8CAQMSER0?= =?us-ascii?q?BATcBDwIBCAQ7AwICAjAUEQIEDgUigwCBek0DLgGgWAKBOIhhdYEygn4BAQW?= =?us-ascii?q?FExiCDAmBNgGMGBqBQT+BOAwUgkw+hCKDNzKCLJBGhVeZDgqCNpYhG5phggy?= =?us-ascii?q?EEKMfAgQCBAUCDgEBBYFZByuBWHAVZQGCQVAYDY0Sg3OKU3SBKI0MAiYHghQ?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.69,409,1571702400"; d="scan'208,217";a="407030403" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jan 2020 10:00:30 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 008A0UET004469 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jan 2020 10:00:30 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 04:00:29 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 04:00:28 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 8 Jan 2020 05:00:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QqsovAtKq2wdwHgPe2eLYaup6+/lrfIo/DpY5U0DjbK66Ov8hTDP4e99FFL4StffTCEW+8y2Q38t9Azx7dsbCxJybj/nk9r6NIlzHgH+oXeyWbaDDPHJGOnQ8vojaGrJeS7FuaNIKDCETuSwVoOD2uz6tLVT8kASPDL93BBEOmWN3aHa1cIfo/tWy8a3ONA+V1W2/spSmLEHCoipmBEvymwhdO1TE/Uk/LxCeGoX9DM8w/0dchv2oDMw8PXnSy4kfsPEOYefRxhIbK6ixVA4U/7aouPK7xf5RgBRllqrw/65CLDyDLcQ4dFvVFGCBrl397VvLq0PGo9XImOWZzgCpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AJoT9RmVKCIBJsYu/ea+Jr3ra3c//TOP1mrdek3EglQ=; b=Cxf0U+t/e/TyjVQC/TOW6b/Dk1tOtqodkcQZvGFcPgh5cP9yokah8tbk/p00MsWSMSiBIjZdblDTYmUT+KVurjsJJziPRlsB0mWgvd3+Dfvx8ryePhaxrFn1YBkrucwfRG+PjPjWLWxS+QBbRdizB5TKBXCTTN8WqmnpMI9ONLOayA9TqptqOG58Gk0x2sboIZENacWP55nXMp/SIeNXIkFekjyu6uQqF84cJdPY/K5CD2wK2tPOROmFf/N+sGOWxxbnBit7LlIs/ox5qyaubciwUzFmSGfsb37bvmqDBT20rR4GC2klUtte1gQK96B2cUYx/nPX+DbQeSDH3bxPVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AJoT9RmVKCIBJsYu/ea+Jr3ra3c//TOP1mrdek3EglQ=; b=TRwPGZyBGs9rGKM5lref4qB7y+WC1Wl9bllMdu1B9AYyPtYqJqZ92/rTXsklvNtrNSu2oDJNwHgTj52rfOWMdbj5quhZLK/kduJxSCJUtj+mSlp2lLyPMgsFpksW+ZtfLfn7GDOm3RiE6sp8Fq6X5OsAFvNMbWCZ2ZIwi8kCOzc= Received: from DM6PR11MB3995.namprd11.prod.outlook.com (10.255.61.204) by DM6PR11MB4042.namprd11.prod.outlook.com (20.176.126.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 8 Jan 2020 10:00:26 +0000 Received: from DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5]) by DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5%7]) with mapi id 15.20.2623.008; Wed, 8 Jan 2020 10:00:25 +0000 From: "Eliot Lear (elear)" To: Ryan Sleevi CC: Alan DeKok , "spasm@ietf.org" , EMU WG Thread-Topic: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic Thread-Index: AdWxNKzqTmo8NKHtQwSIp+NEgFXHNACbMPUABHRvF7QAAZ7ogAABuFUAAAClZwAAAxLIAAACFEUAAAKfAIAACUx2AAAM8UWAAAPQxgA= Date: Wed, 8 Jan 2020 10:00:25 +0000 Message-ID: <5F6DD581-21D6-4304-824E-4846CA3BC335@cisco.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2001:420:c0c0:1006::184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10905223-fa24-497d-ab7e-08d794219571 x-ms-traffictypediagnostic: DM6PR11MB4042: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(39860400002)(376002)(199004)(189003)(91956017)(4326008)(6916009)(2616005)(6512007)(66446008)(64756008)(6486002)(86362001)(76116006)(66476007)(66946007)(66556008)(4744005)(5660300002)(478600001)(54906003)(8676002)(316002)(81166006)(8936002)(71200400001)(2906002)(6506007)(81156014)(36756003)(186003)(33656002)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB4042; H:DM6PR11MB3995.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TLMl5omEARbr9hdRqhJgPD8lwykSZ0+Iv+7iY0Ve/IZE1DhTtH+XbB3fnUoJE8GZ5aLiaIwd1IvMO9dzitoOOnAbmVHVJKKxk9zVDNAJj90l00u5iqMIlMtguV8yfmKncO6MlgHDjPNdlA5JWKFCyClOBhLHfxwILCqmCt+qfLkLHDTYPdCICnp2OcgjnOQNUoJOYibBh2TGwXQJkKw0eeV0VO40qgkBV329tLttOzGHc+7d+hIhb+soYVwHcwnhKafsQC1/LlB/26s8m9a3PHVBzdcBM7dQei8dXPTVoiSmeFD3jF/vtP/E7s6S2Jq+OJJDPnt4IAfpIbgOxnj7FghrI28FdkLFv3NY0Y1ax7bAUy5ehZB+nzLGZ+Y0KLNLYECKDiUCryofgB1pTZJtSleY8yoaVNLYLCNdWgtOS6I7r8wmrsneG7Wg5mNs2aSW x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_5F6DD58121D64304824E4846CA3BC335ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 10905223-fa24-497d-ab7e-08d794219571 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 10:00:25.6591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /3AuRP2hR126N2dYfC+03qyPn/4pJBflv37sLvTQ5GHfSIkq3bz23Pl0XkpGoMB2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4042 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 10:00:37 -0000 --_000_5F6DD58121D64304824E4846CA3BC335ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUnlhbiwNCg0KVGhpcyB0b3BpYyBzZWVtcyBsaWtlIGEgZ29vZCBvbmUgdG8ganVzdCBnZXQg b24gdGhlIHBob25lIGFuZCBzb3J0IHRocm91Z2gsIGJ1dCBJIGhhdmUgb25lIHF1ZXN0aW9uOg0K DQpPbiA4IEphbiAyMDIwLCBhdCAwOToxMSwgUnlhbiBTbGVldmkgPHJ5YW4taWV0ZkBzbGVldmku Y29tPG1haWx0bzpyeWFuLWlldGZAc2xlZXZpLmNvbT4+IHdyb3RlOg0KDQpIb3dldmVyLCBpZiB1 c2luZyB0aGUgc2FtZSBzZXQgb3IgQ0FzIHRoYXQgcG9wdWxhciBPU2VzIHVzZSBmb3IgVExTLCBp dCBkb2VzIG1lYW4gdGhhdCB0aGVzZSBDQXMsIGFuZCB0aGVpciBjdXN0b21lcnMsIHdpbGwgc3Rp bGwgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBhZ2lsaXR5IHJlcXVpcmVtZW50cywgYW5kIGxpbWl0 ZWQgdG8gdGhlIHNhbWUgcHJvZmlsZSBhcyBUTFMuIEJlY2F1c2Ugb2YgdGhpcywgdGhlcmXigJlz IGFtcGxlIHJlYXNvbiB0byBzcGxpdCBmdXJ0aGVyIGludG8gdGhlIGRlZGljYXRlZCBoaWVyYXJj aHkgYW5kIGRlZGljYXRlZCBFS1UuDQoNCklzIHRoZXJlIGFuIGV4YW1wbGUgb2YgYSBub24tRUFQ IHVzZSB3aGVyZSBzcGxpdHRpbmcgaW50byBhIG5ldyBoaWVyYXJjaHkgaGFzIGFjdHVhbGx5IHN1 Y2NlZWRlZD8NCg0KRWxpb3QNCg== --_000_5F6DD58121D64304824E4846CA3BC335ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIFJ5YW4sDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIHRvcGljIHNlZW1zIGxpa2UgYSBn b29kIG9uZSB0byBqdXN0IGdldCBvbiB0aGUgcGhvbmUgYW5kIHNvcnQgdGhyb3VnaCwgYnV0IEkg aGF2ZSBvbmUgcXVlc3Rpb246PGJyIGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gOCBKYW4gMjAy MCwgYXQgMDk6MTEsIFJ5YW4gU2xlZXZpICZsdDs8YSBocmVmPSJtYWlsdG86cnlhbi1pZXRmQHNs ZWV2aS5jb20iIGNsYXNzPSIiPnJ5YW4taWV0ZkBzbGVldmkuY29tPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0i Ij48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsg ZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Ib3dldmVyLA0KIGlmIHVzaW5n IHRoZSBzYW1lIHNldCBvciBDQXMgdGhhdCBwb3B1bGFyIE9TZXMgdXNlIGZvciBUTFMsIGl0IGRv ZXMgbWVhbiB0aGF0IHRoZXNlIENBcywgYW5kIHRoZWlyIGN1c3RvbWVycywgd2lsbCBzdGlsbCBi ZSBzdWJqZWN0IHRvIHRoZSBzYW1lIGFnaWxpdHkgcmVxdWlyZW1lbnRzLCBhbmQgbGltaXRlZCB0 byB0aGUgc2FtZSBwcm9maWxlIGFzIFRMUy4gQmVjYXVzZSBvZiB0aGlzLCB0aGVyZeKAmXMgYW1w bGUgcmVhc29uIHRvIHNwbGl0IGZ1cnRoZXINCiBpbnRvIHRoZSBkZWRpY2F0ZWQgaGllcmFyY2h5 IGFuZCBkZWRpY2F0ZWQgRUtVLjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklzIHRoZXJlIGFuIGV4YW1wbGUg b2YgYSBub24tRUFQIHVzZSB3aGVyZSBzcGxpdHRpbmcgaW50byBhIG5ldyBoaWVyYXJjaHkgaGFz IGFjdHVhbGx5IHN1Y2NlZWRlZD88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVsaW90PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5F6DD58121D64304824E4846CA3BC335ciscocom_-- From nobody Wed Jan 8 02:49:29 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F33D12006F for ; Wed, 8 Jan 2020 02:49:27 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=qNVgrEXb; dkim=pass (1024-bit key) header.d=primekey.com header.b=qNVgrEXb 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 3XhhLnvlxMqe for ; Wed, 8 Jan 2020 02:49:24 -0800 (PST) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674C1120018 for ; Wed, 8 Jan 2020 02:49:24 -0800 (PST) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 45B416AA008C for ; Wed, 8 Jan 2020 11:49:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1578480549; bh=Q3RPtHKeaUrczsxQgUJvKKkvNTpw57wdGqtd/B5x1S8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=qNVgrEXb/CDH7M3/JLYK0fWZzFtLxr2N59t4jCNONXiLlvNjKb6c9GgjllWkLkcWz hAL9Jp25b+TRRjkyp6mfq3RtkCg26LC6GjlcvPNCv4D6TIlJ1FZzeTxYxwC6EkdnpP /qeg6GZNw5H6PhG8JXaEWc/ii39nDwLDNpQDKN18= Received: from [192.168.3.139] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 2572C6AA0082 for ; Wed, 8 Jan 2020 11:49:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1578480549; bh=Q3RPtHKeaUrczsxQgUJvKKkvNTpw57wdGqtd/B5x1S8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=qNVgrEXb/CDH7M3/JLYK0fWZzFtLxr2N59t4jCNONXiLlvNjKb6c9GgjllWkLkcWz hAL9Jp25b+TRRjkyp6mfq3RtkCg26LC6GjlcvPNCv4D6TIlJ1FZzeTxYxwC6EkdnpP /qeg6GZNw5H6PhG8JXaEWc/ii39nDwLDNpQDKN18= To: spasm@ietf.org References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Wed, 8 Jan 2020 11:49:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 10:49:28 -0000 I support the adoption of both drafts for further work in the WG. My comments on the draft right now: 1. I oppose the usage of .well-known URLs in this context. I don't consider CMP end points being in the line of the definition of .well-known as specified in RFC5785. A CMP end point is not meta-data. If anything .well-known shold be used for discovering the active CMP end point urls (see point 2). 2. A single CMP end point url path does not work when servicing multiple CAs and use cases. Since real CMP end points are not "serve all everything they ask for", multiple configurations, access rights and profiles are needed. Today this is commonly implemented by different CMP url paths. It is not technically possible, within the scope of RFC4210, to merge all uses cases into a single url path. Any CMP profile should support multiple url-paths. 3. The multiple url paths defined in 7.1 for different operations is redundant for CMP, as this information is already in the CMP messages. CMP works very well with a single url path for all messages and establishing a new scheme will break interoperability, not foster imho. Regards, Tomas On 2020-01-07 16:00, Russ Housley wrote: > There are two CMP-related documents: > - draft-brockhaus-lamps-cmp-updates > - draft-brockhaus-lamps-lightweight-cmp-profile > > Please indicate whether you support adoption of zero, one, or both of these documents by the LAMPS WG. Please respond before January 22nd. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Wed Jan 8 03:22:32 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AC81200A4 for ; Wed, 8 Jan 2020 03:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 h9Q4tBWhBv3C for ; Wed, 8 Jan 2020 03:22:29 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60086.outbound.protection.outlook.com [40.107.6.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80966120091 for ; Wed, 8 Jan 2020 03:22:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GsrQXO5NVXekDvYPz9VycOg22Ki5sOr55YC21W5I9qQZOGtmJkhGj6IzqeOK40w4deaQS2ziqggAp5hyqiw3XjS3oVv/eIgqebH2ic3tyrdeiVdDVNScI7tQvwfscFMXWoh0B8zhmw8l4uRufW3iquDK386m9mPC9DXFop7Wav8sQWi0XREqz9KssxFlpknqU2z75e+QG0g7vMFVDl1S6xsRAhhwlNYJWFH9SZVmdHtI4dgF8uztwrtdZaV4KWY50u5kEjaf4yG4QMv3lWeeTy4W5KUBG0hnxsriMecFcxMeGhTxH6eheheb8Ta8mzdD8oZ6HT8DM3wMhSQU8zsSEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w593raoPGzolV2TfB1e8dFsPjF9DwPAH4HZbvKZLfEU=; b=WAgLDtfK6hrPFgCA6PLuK0UHXBzy8soHvuuTnHfkovVIwm6XuFKusyXsn3wonrgxpZbFAvY0miN0+bfl6noq8KSQTrFIt8L4B9f5OoC9LUYwlraRvQbS4YdQneKzbXP+vqVKUe59SZsIcWqbVVIjHFZcJ7lqiGCC7bwtS18Yk+rYdP2HMRiWpckXIl1LTxZeK6GHzfc2u61vvRuf+Q4p9gMXtL2p2n5isQw9Z5mMqOZPHWgQVLcLvb5yFLRX2x8Flazdt8AeCPiAegvPzAUMTUnATnPDMUU3AhNr/BQWnplHNaDJ2A4Foh9oh3n9v7ScYuT1KqZiKY20qWb2eYe0Lg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w593raoPGzolV2TfB1e8dFsPjF9DwPAH4HZbvKZLfEU=; b=Wafm/LJwjRpwo3u+7Iyszmy8EPDOZZpoNXWQWjvmClg1yodZzS1rKdWJE6pwfyzbTNa0j2buzmjJhkTI0Jax6bHeYtg46AVv/2VkKbnvQ0pGmVYJn3jKGBQIHq7heRlu/1K6vxhjYufcIPdSSOEwkc2vm+7aOwrNu+3gg5zLGFM= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2473.eurprd07.prod.outlook.com (10.168.125.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.7; Wed, 8 Jan 2020 11:22:27 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::cd13:3dbf:1517:c03c]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::cd13:3dbf:1517:c03c%10]) with mapi id 15.20.2623.008; Wed, 8 Jan 2020 11:22:27 +0000 From: Mohit Sethi M To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile Thread-Index: AQHVxhXnYB0uOyHDaUK+bxSA9eNMyw== Date: Wed, 8 Jan 2020 11:22:27 +0000 Message-ID: <34cfc6f8-8ee5-8206-734b-3b8c108349cc@ericsson.com> References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> In-Reply-To: <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:170:3760:cb5b:4d5a:74ce:4909] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 465c78f3-bd19-41ba-9cbe-08d7942d0ace x-ms-traffictypediagnostic: HE1PR0701MB2473: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(396003)(376002)(346002)(199004)(189003)(31696002)(15650500001)(110136005)(71200400001)(76116006)(31686004)(86362001)(186003)(36756003)(6506007)(316002)(53546011)(966005)(2616005)(2906002)(81166006)(81156014)(6512007)(5660300002)(66946007)(4744005)(8936002)(66476007)(66556008)(478600001)(66446008)(6486002)(64756008)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2473; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nIJaFPbWIF6Q6nIq9g8IHrysodRFKtHZYISU6Chxn8Wq7VkB7nVXxsBbgmkcX5kkzQy8zgIiHARxM/gXtVjbNunp1y+s5Mae+fCvXWYPwwbZQuQ1v/NbdfRI0KKWuIhGJ+4vi444kHU3i/rTBPMiT1y8vaBJjwEBHsy6P07OmepVhpSdv6c5xvbR1B40NYky1g0NX8Z5HI04nmckkmEVLs7Yz4DsbfTARqgAEEOOeZ7m097k8m65HxDcfZ1uihBmH1Np1lEj1IdnqokGh+7+eiXJyvBhoZyXE/mJpeKczZn+uqxzhTWmwIxzGeBDncjvoFYfyWKvizV9ZYBN3gCrL76cK5BaVXiwWnbTJdSnarJoK6aPfU5zwTazdhTgWVB9V9gC+O8/+VAoCmjGHjRRaqvh6JZK9cn7c8s7ZC6Rpas+i0Wo3YoU63ku0CJPNXNA1IpvNeqjxXVEGORZVmREVSIOi/MTJ7ePptJqI6/kTowristHT88wPPxZOGGAg0JJBdDvDS0QogshiY5GxQ0OJg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 465c78f3-bd19-41ba-9cbe-08d7942d0ace X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 11:22:27.0826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OkNcI7Yl0KEB+PirTiXF0E1BF8SJ1QQmJzpO3I8KNKwKTm5/hBTkghIcLJmppUVcWSH1Dse1DVqvcYL83Od2wtT8EZc2s32XyWqr1mf0PrA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2473 Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 11:22:32 -0000 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBib3RoIHRoZXNlIGRvY3VtZW50cyB3aXRoIHRoZSBw cmVmZXJlbmNlIG9mIA0KZmluaXNoaW5nIGRyYWZ0LWJyb2NraGF1cy1sYW1wcy1jbXAtdXBkYXRl cyBiZWZvcmUgZGVhbGluZyB3aXRoIHRoZSANCmxpZ2h0d2VpZ2h0IHByb2ZpbGUuDQoNCi0tTW9o aXQNCg0KT24gMS83LzIwIDU6MDAgUE0sIFJ1c3MgSG91c2xleSB3cm90ZToNCj4gVGhlcmUgYXJl IHR3byBDTVAtcmVsYXRlZCBkb2N1bWVudHM6DQo+ICAgIC0gZHJhZnQtYnJvY2toYXVzLWxhbXBz LWNtcC11cGRhdGVzDQo+ICAgIC0gZHJhZnQtYnJvY2toYXVzLWxhbXBzLWxpZ2h0d2VpZ2h0LWNt cC1wcm9maWxlDQo+DQo+IFBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBzdXBwb3J0IGFkb3B0 aW9uIG9mIHplcm8sIG9uZSwgb3IgYm90aCBvZiB0aGVzZSBkb2N1bWVudHMgYnkgdGhlIExBTVBT IFdHLiAgUGxlYXNlIHJlc3BvbmQgYmVmb3JlIEphbnVhcnkgMjJuZC4NCj4NCj4gUnVzcw0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTcGFz bSBtYWlsaW5nIGxpc3QNCj4gU3Bhc21AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcGFzbQ0KDQo= From nobody Wed Jan 8 03:27:02 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCEA120227; Wed, 8 Jan 2020 03:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 jnNjxEmAIiio; Wed, 8 Jan 2020 03:26:53 -0800 (PST) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C6512082C; Wed, 8 Jan 2020 03:26:52 -0800 (PST) Received: by mail-ed1-f53.google.com with SMTP id bx28so2227533edb.11; Wed, 08 Jan 2020 03:26:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fi95Jz2HShhbyNujaD57MW30TqLQehxo6Whqco1EZBs=; b=GLJgiUxl0VWNvHKTVVNS7wlDQIqlnvzuM6WoVfExE1u2A4wKlLVGiL3t/MVjJztP7C 4MOKDxeRz0ABcMPjnZJCcOksiYxAJ5UNWb6h0KKcUNDmFSdwW5uD5fF8LY9GITrdlmBx DudM+PtNb7C+PxkciF2pAnnWtRAlpDGzFI0U4FqzbBhBbaPMYOXKwkwBGebmqHpqD+nY PXeujDBDYx/QgTHiaZAULDAV2jFDtiL6jDWvTCMS4vANS2u7PictcbBEvA1C/jrKn/EI RFxpDstBc1c4n++Xzxg0hCyuTKWspOKj5bqNGrXByolpwPTiso8HUeV5pvBm2dJN6GtB C+uQ== X-Gm-Message-State: APjAAAU4MzPhWyrg4pRlqyRUShC4NkzYRkx7l+MTS2V8kZI3AdVFUVNp DbYmDoMfggfa9wY3f6yJtXxo9OUv X-Google-Smtp-Source: APXvYqwtYmsdOMpTnhOkISvXoCBSy+Q9yAJbhFCehsjWQIee+0yMcyjjjy9YKIu7s/UpJrRMo1LVQA== X-Received: by 2002:a50:eacb:: with SMTP id u11mr4872122edp.181.1578482811198; Wed, 08 Jan 2020 03:26:51 -0800 (PST) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com. [209.85.221.52]) by smtp.gmail.com with ESMTPSA id qw15sm51530ejb.92.2020.01.08.03.26.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 03:26:51 -0800 (PST) Received: by mail-wr1-f52.google.com with SMTP id c9so2949969wrw.8; Wed, 08 Jan 2020 03:26:50 -0800 (PST) X-Received: by 2002:a5d:530e:: with SMTP id e14mr3877908wrv.250.1578482810366; Wed, 08 Jan 2020 03:26:50 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <5F6DD581-21D6-4304-824E-4846CA3BC335@cisco.com> In-Reply-To: <5F6DD581-21D6-4304-824E-4846CA3BC335@cisco.com> From: Ryan Sleevi Date: Wed, 8 Jan 2020 06:26:39 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Eliot Lear (elear)" Cc: Alan DeKok , EMU WG , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000323148059b9f2ba5" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 11:27:00 -0000 --000000000000323148059b9f2ba5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) wrote: > Hi Ryan, > > This topic seems like a good one to just get on the phone and sort > through, but I have one question: > > On 8 Jan 2020, at 09:11, Ryan Sleevi wrote: > > However, if using the same set or CAs that popular OSes use for TLS, it > does mean that these CAs, and their customers, will still be subject to t= he > same agility requirements, and limited to the same profile as TLS. Becaus= e > of this, there=E2=80=99s ample reason to split further into the dedicated= hierarchy > and dedicated EKU. > > > Is there an example of a non-EAP use where splitting into a new hierarchy > has actually succeeded? > Document signing generally fits there, in that there are a number of CAs that only offer document signing/identity proofing without overlapping. As would, say, Cisco=E2=80=99s device/firmware signing model or the PKIs in us= e in the financial services/ATM markets. Relevant to EAP would be the aforementioned Passpoint model, which uses new and distinct CAs for that. There are definitely flaws with that (e.g. wanting said CAs to work with browsers), but there are parts of it that do work. There=E2=80=99s no technical reason to require the use of the same roots/sa= me hierarchy, and ample and adequate reason to distinguish: both from the perspective of a root store maintainer (ensuring certificates comply with policies) and as a certificate consumer (minimizing risk of misissuance, ala Flame) > --000000000000323148059b9f2ba5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) <elear@cisco.com> wrote:
Hi Ryan,

This topic seems like a good one to just get on the phone and sort thr= ough, but I have one question:

On 8 Jan 2020, at 09:11, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

However, if using the same set or CAs that popular OSes use for TLS, it does mean t= hat these CAs, and their customers, will still be subject to the same agili= ty requirements, and limited to the same profile as TLS. Because of this, t= here=E2=80=99s ample reason to split further into the dedicated hierarchy and dedicated EKU.

Is there an example of a non-EAP use where splitting into a new hierar= chy has actually succeeded?

<= /div>
Document signing generally fits there, in that there= are a number of CAs that only offer document signing/identity proofing wit= hout overlapping. As would, say, Cisco=E2=80=99s device/firmware signing mo= del or the PKIs in use in the financial services/ATM markets.

Relevant to EAP would be the aforemen= tioned Passpoint model, which uses new and distinct CAs for that. There are= definitely flaws with that (e.g. wanting said CAs to work with browsers), = but there are parts of it that do work.

There=E2=80=99s no technical reason to require the use of t= he same roots/same hierarchy, and ample and adequate reason to distinguish:= both from the perspective of a root store maintainer (ensuring certificate= s comply with policies) and as a certificate consumer (minimizing risk of m= isissuance, ala Flame)
--000000000000323148059b9f2ba5-- From nobody Wed Jan 8 03:29:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8921200A4; Wed, 8 Jan 2020 03:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=giInwTmx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PCrKsM4A 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 RojRRqBUdBii; Wed, 8 Jan 2020 03:29:51 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51061120018; Wed, 8 Jan 2020 03:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8745; q=dns/txt; s=iport; t=1578482991; x=1579692591; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vozHpV6buMrHkSU1kz58rzGw5MaQGyouVpPE5sfqc34=; b=giInwTmx0GrFDr97qnJCYSfa5PYXvrHQYQyswIC7ssxHS5IpFOwwpuXJ ozSwSOx/UmbGctsvdO33A/SUwCrAPguGjZePAkqg4yVG7Pz0CPIh3WymL n2EIN8df19BF0rp6zGpj8dIOXpKsTbz7+AgTpbfox6jDPS/X548D9RFRu c=; IronPort-PHdr: =?us-ascii?q?9a23=3AhjvwgRVxmhRdWqn9EdTDNLZ8Tq3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANWJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3GMlLTndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdBQB/vBVe/5pdJa1dCRwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF8gSUvUAWBRCAECyqECYNGA4sGlgqEYoJSA1QJAQEBDAEBLQI?= =?us-ascii?q?BAYRAAheBUiQ4EwIDDQEBBAEBAQIBBQRthTcMhV8CAQMSER0BATcBDwIBCD8?= =?us-ascii?q?DAgICMBQRAgQOBSKDAIF6TQMuAaEbAoE4iGF1gTKCfgEBBYURGIIMCYE2jBk?= =?us-ascii?q?agUE/gREnIIJMPoQfA4M3MoIskEaFV5kOCoI2liEbmmGCDIQQox8CBAIEBQI?= =?us-ascii?q?OAQEFgWkigVhwFWUBgkFQGA2NEgwXg1CKU3SBKI0MAiYHghQBAQ?= X-IronPort-AV: E=Sophos;i="5.69,409,1571702400"; d="scan'208,217";a="407085825" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jan 2020 11:29:50 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 008BToGH004672 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jan 2020 11:29:50 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 05:29:49 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 05:29:49 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 8 Jan 2020 05:29:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=II7njge986m/mJjfepEA7ERjq6RPoBmLfH6t62ANUx9zFmLJC0YAkWniMbeRVLjzo6lXed8gt0lyDz9V7bhLmrc66dP4KIe2YRKNr1R4PkhbcGN2WmtcKCvvU1pSLfWO4+vhRnIApf9oFR/QOvclB3UL9+3GlXwg/l3QRoQIK3H8vHuFw7XtIwOmPLsrqErhIyXadm08NYYE0BpM3cgdXKQTzbVDng8m1itc7AJMJFbTIZ9Z/7urs3CJcY/c5j/Z4IexZsd5Wn4Tuyn0JOfjhFiWcwoydVNWfU1bMJYw9RMrMuHFdHgVCq/Q6PXbuh5jIVQObsf5gDEysxLjMCb1pQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vozHpV6buMrHkSU1kz58rzGw5MaQGyouVpPE5sfqc34=; b=hxBTmcwYevvf2LdzyQyxbNHjYN+ogMmDjWjDJhQj1ZxPuYCtE6b6KZjDlzcUY6AtkxryOgeqxMY0Oyu44jQrk1R+mnK5exHsVksNOdVWe2AbxVOsRaWWSuseZF0hhv0mlVTZk5yKKTwQzjomEGc1ig31hxje3gqJ28NDpvKTiCIk3XPCQQhOWZ2xeR2aYCjpcipeIQA2iKn81F6V/k73RRM9KfjKfZnR8BKNkVkBkJjhvJ1U7pk9Ram8vptxCtw3lwiBafXvqAVR8lcTX6Rh5l2TNgbepw7fjGJq2APjtVx2rwbjyhc8oWnq3DWIqK6EyjpY+UtZfqGC/+HhgCu3og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vozHpV6buMrHkSU1kz58rzGw5MaQGyouVpPE5sfqc34=; b=PCrKsM4AvVdQ/lJ92tt/dWkTLzN101fLqFidgaziSTeFo5BSMBmp4A7wx4XSEz1HgqN1o09CmaFir+S7TVfQVYfkU/NgOYoZOuqAbc3lynybQo2meRcCM23FZux+UdZ5SQfosVJicn6huFRoofmxpSq+TrK9y9RAiH8vp2WelnE= Received: from DM6PR11MB3995.namprd11.prod.outlook.com (10.255.61.204) by DM6PR11MB3212.namprd11.prod.outlook.com (20.176.120.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Wed, 8 Jan 2020 11:29:48 +0000 Received: from DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5]) by DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5%7]) with mapi id 15.20.2623.008; Wed, 8 Jan 2020 11:29:48 +0000 From: "Eliot Lear (elear)" To: Ryan Sleevi CC: Alan DeKok , EMU WG , "spasm@ietf.org" Thread-Topic: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic Thread-Index: AdWxNKzqTmo8NKHtQwSIp+NEgFXHNACbMPUABHRvF7QAAZ7ogAABuFUAAAClZwAAAxLIAAACFEUAAAKfAIAACUx2AAAM8UWAAAPQxgAAAwMigAAAHASA Date: Wed, 8 Jan 2020 11:29:48 +0000 Message-ID: <0BE0A0F3-AC37-426E-B322-05DF59594069@cisco.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <5F6DD581-21D6-4304-824E-4846CA3BC335@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2001:420:c0c0:1006::184] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffea22bc-5a0d-4599-d88f-08d7942e1201 x-ms-traffictypediagnostic: DM6PR11MB3212: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(346002)(396003)(366004)(52314003)(189003)(199004)(316002)(53546011)(8676002)(186003)(2616005)(4326008)(54906003)(66946007)(66446008)(66476007)(91956017)(66556008)(64756008)(76116006)(6512007)(6916009)(71200400001)(8936002)(2906002)(33656002)(6486002)(81166006)(478600001)(5660300002)(6506007)(86362001)(81156014)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3212; H:DM6PR11MB3995.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rO5Jc34XbiRHehOKVxinuu4pEDd+LvmYtLyp4P3vs1lkvRMVdoW0+dxcO5cVOA4cO4oRrofNCnhkZEHoJWcOSdQWaz2afuVX4o+Z2AOrAEWOIPlrKtRev5hXeei6OQSz45O+Al2QoWCWkNy3W+6Uxg0vY9tUUle/xI1zJaqX9pxMrXjUt2bIYxvD6IkcOeWDMCVleCiWQBRArF97Nj9c5a+Ze7pvjxaqK9XzLEAOw6ZfXM7h1NkPmgpazIfO4OjEZJxFf+W1F7UgG3o2Hrz1Szs/W5PGmCm+0aSXa098N6PiQE4JvrzwuVdRQr2bP+IdvFpHAp9TdgYpPoIeuQ6aSMD7TdAjjuZ+4JF5iUJ+tD1hSnKj4xeoyJyy6VhkVSB1NoYqKDzGhZvLo7A9Q2Nsb08bqcevj7ASrjeFi88OpCiNXGLvlssPK0zjMvmBp6Fy92tTvoyIgCQ9DGGvjRaR5nZBLvIwKcjC1abfQpug2bQdW3IAK3bNjU/GhoeZiFZd x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0BE0A0F3AC37426EB32205DF59594069ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ffea22bc-5a0d-4599-d88f-08d7942e1201 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 11:29:48.6282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ym9GoDW684zmYKdgyJG+H7P+2mEaKNuUPcBhPfMxAoX1XZsWYSdFmcuX0alHQAsV X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3212 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 11:29:53 -0000 --_000_0BE0A0F3AC37426EB32205DF59594069ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBSeWFuLiAgQWZ0ZXIgSSBzZW50IHRoZSBub3RlIEkgdGhvdWdodCBhYm91dCBkb2N1 bWVudCBzaWduaW5nLiAgT3VyIFNVREkgbW9kZWwgYXQgQ2lzY28gSSB2aWV3IGFzIHNvbWV3aGF0 IGRpZmZlcmVudCwgYnV0IG1heSBiZSBjbG9zZXIgdG8gYXB0IHRvIEVBUCBhbnl3YXksIHNvIHdv cnRoIGRpc2N1c3NpbmcuDQoNCkVsaW90DQoNCk9uIDggSmFuIDIwMjAsIGF0IDEyOjI2LCBSeWFu IFNsZWV2aSA8cnlhbi1pZXRmQHNsZWV2aS5jb208bWFpbHRvOnJ5YW4taWV0ZkBzbGVldmkuY29t Pj4gd3JvdGU6DQoNCg0KDQpPbiBXZWQsIEphbiA4LCAyMDIwIGF0IDU6MDAgQU0gRWxpb3QgTGVh ciAoZWxlYXIpIDxlbGVhckBjaXNjby5jb208bWFpbHRvOmVsZWFyQGNpc2NvLmNvbT4+IHdyb3Rl Og0KSGkgUnlhbiwNCg0KVGhpcyB0b3BpYyBzZWVtcyBsaWtlIGEgZ29vZCBvbmUgdG8ganVzdCBn ZXQgb24gdGhlIHBob25lIGFuZCBzb3J0IHRocm91Z2gsIGJ1dCBJIGhhdmUgb25lIHF1ZXN0aW9u Og0KDQpPbiA4IEphbiAyMDIwLCBhdCAwOToxMSwgUnlhbiBTbGVldmkgPHJ5YW4taWV0ZkBzbGVl dmkuY29tPG1haWx0bzpyeWFuLWlldGZAc2xlZXZpLmNvbT4+IHdyb3RlOg0KDQpIb3dldmVyLCBp ZiB1c2luZyB0aGUgc2FtZSBzZXQgb3IgQ0FzIHRoYXQgcG9wdWxhciBPU2VzIHVzZSBmb3IgVExT LCBpdCBkb2VzIG1lYW4gdGhhdCB0aGVzZSBDQXMsIGFuZCB0aGVpciBjdXN0b21lcnMsIHdpbGwg c3RpbGwgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBhZ2lsaXR5IHJlcXVpcmVtZW50cywgYW5kIGxp bWl0ZWQgdG8gdGhlIHNhbWUgcHJvZmlsZSBhcyBUTFMuIEJlY2F1c2Ugb2YgdGhpcywgdGhlcmXi gJlzIGFtcGxlIHJlYXNvbiB0byBzcGxpdCBmdXJ0aGVyIGludG8gdGhlIGRlZGljYXRlZCBoaWVy YXJjaHkgYW5kIGRlZGljYXRlZCBFS1UuDQoNCklzIHRoZXJlIGFuIGV4YW1wbGUgb2YgYSBub24t RUFQIHVzZSB3aGVyZSBzcGxpdHRpbmcgaW50byBhIG5ldyBoaWVyYXJjaHkgaGFzIGFjdHVhbGx5 IHN1Y2NlZWRlZD8NCg0KRG9jdW1lbnQgc2lnbmluZyBnZW5lcmFsbHkgZml0cyB0aGVyZSwgaW4g dGhhdCB0aGVyZSBhcmUgYSBudW1iZXIgb2YgQ0FzIHRoYXQgb25seSBvZmZlciBkb2N1bWVudCBz aWduaW5nL2lkZW50aXR5IHByb29maW5nIHdpdGhvdXQgb3ZlcmxhcHBpbmcuIEFzIHdvdWxkLCBz YXksIENpc2Nv4oCZcyBkZXZpY2UvZmlybXdhcmUgc2lnbmluZyBtb2RlbCBvciB0aGUgUEtJcyBp biB1c2UgaW4gdGhlIGZpbmFuY2lhbCBzZXJ2aWNlcy9BVE0gbWFya2V0cy4NCg0KUmVsZXZhbnQg dG8gRUFQIHdvdWxkIGJlIHRoZSBhZm9yZW1lbnRpb25lZCBQYXNzcG9pbnQgbW9kZWwsIHdoaWNo IHVzZXMgbmV3IGFuZCBkaXN0aW5jdCBDQXMgZm9yIHRoYXQuIFRoZXJlIGFyZSBkZWZpbml0ZWx5 IGZsYXdzIHdpdGggdGhhdCAoZS5nLiB3YW50aW5nIHNhaWQgQ0FzIHRvIHdvcmsgd2l0aCBicm93 c2VycyksIGJ1dCB0aGVyZSBhcmUgcGFydHMgb2YgaXQgdGhhdCBkbyB3b3JrLg0KDQpUaGVyZeKA mXMgbm8gdGVjaG5pY2FsIHJlYXNvbiB0byByZXF1aXJlIHRoZSB1c2Ugb2YgdGhlIHNhbWUgcm9v dHMvc2FtZSBoaWVyYXJjaHksIGFuZCBhbXBsZSBhbmQgYWRlcXVhdGUgcmVhc29uIHRvIGRpc3Rp bmd1aXNoOiBib3RoIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGEgcm9vdCBzdG9yZSBtYWludGFp bmVyIChlbnN1cmluZyBjZXJ0aWZpY2F0ZXMgY29tcGx5IHdpdGggcG9saWNpZXMpIGFuZCBhcyBh IGNlcnRpZmljYXRlIGNvbnN1bWVyIChtaW5pbWl6aW5nIHJpc2sgb2YgbWlzaXNzdWFuY2UsIGFs YSBGbGFtZSkNCg0K --_000_0BE0A0F3AC37426EB32205DF59594069ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <04DA3A2543495141BEA03518A1D7E4C8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcywgUnlhbi4gJm5ic3A7QWZ0ZXIgSSBz ZW50IHRoZSBub3RlIEkgdGhvdWdodCBhYm91dCBkb2N1bWVudCBzaWduaW5nLiAmbmJzcDtPdXIg U1VESSBtb2RlbCBhdCBDaXNjbyBJIHZpZXcgYXMgc29tZXdoYXQgZGlmZmVyZW50LCBidXQgbWF5 IGJlIGNsb3NlciB0byBhcHQgdG8gRUFQIGFueXdheSwgc28gd29ydGggZGlzY3Vzc2luZy4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVsaW90PGJy IGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gOCBKYW4gMjAyMCwgYXQgMTI6MjYsIFJ5YW4gU2xl ZXZpICZsdDs8YSBocmVmPSJtYWlsdG86cnlhbi1pZXRmQHNsZWV2aS5jb20iIGNsYXNzPSIiPnJ5 YW4taWV0ZkBzbGVldmkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxl LWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+ T24gV2VkLCBKYW4gOCwgMjAyMCBhdCA1OjAwIEFNIEVsaW90IExlYXIgKGVsZWFyKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmVsZWFyQGNpc2NvLmNvbSIgY2xhc3M9IiI+ZWxlYXJAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13 aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiBy Z2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9 IiI+SGkgUnlhbiwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlRoaXMgdG9waWMgc2VlbXMgbGlrZSBhIGdvb2Qgb25lIHRvIGp1c3QgZ2V0IG9uIHRo ZSBwaG9uZSBhbmQgc29ydCB0aHJvdWdoLCBidXQgSSBoYXZlIG9uZSBxdWVzdGlvbjo8YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiA4IEphbiAyMDIwLCBhdCAwOToxMSwgUnlh biBTbGVldmkgJmx0OzxhIGhyZWY9Im1haWx0bzpyeWFuLWlldGZAc2xlZXZpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPnJ5YW4taWV0ZkBzbGVldmkuY29tPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5Ib3dldmVyLA0KIGlmIHVzaW5nIHRoZSBzYW1lIHNldCBvciBDQXMgdGhhdCBw b3B1bGFyIE9TZXMgdXNlIGZvciBUTFMsIGl0IGRvZXMgbWVhbiB0aGF0IHRoZXNlIENBcywgYW5k IHRoZWlyIGN1c3RvbWVycywgd2lsbCBzdGlsbCBiZSBzdWJqZWN0IHRvIHRoZSBzYW1lIGFnaWxp dHkgcmVxdWlyZW1lbnRzLCBhbmQgbGltaXRlZCB0byB0aGUgc2FtZSBwcm9maWxlIGFzIFRMUy4g QmVjYXVzZSBvZiB0aGlzLCB0aGVyZeKAmXMgYW1wbGUgcmVhc29uIHRvIHNwbGl0IGZ1cnRoZXIN CiBpbnRvIHRoZSBkZWRpY2F0ZWQgaGllcmFyY2h5IGFuZCBkZWRpY2F0ZWQgRUtVLjwvc3Bhbj48 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPklzIHRoZXJlIGFuIGV4YW1wbGUgb2YgYSBub24tRUFQIHVzZSB3aGVyZSBzcGxp dHRpbmcgaW50byBhIG5ldyBoaWVyYXJjaHkgaGFzIGFjdHVhbGx5IHN1Y2NlZWRlZD88L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPkRvY3VtZW50IHNpZ25pbmcg Z2VuZXJhbGx5IGZpdHMgdGhlcmUsIGluIHRoYXQgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIENBcyB0 aGF0IG9ubHkgb2ZmZXIgZG9jdW1lbnQgc2lnbmluZy9pZGVudGl0eSBwcm9vZmluZyB3aXRob3V0 IG92ZXJsYXBwaW5nLiBBcyB3b3VsZCwgc2F5LCBDaXNjb+KAmXMgZGV2aWNlL2Zpcm13YXJlIHNp Z25pbmcgbW9kZWwgb3IgdGhlIFBLSXMgaW4gdXNlIGluIHRoZSBmaW5hbmNpYWwNCiBzZXJ2aWNl cy9BVE0gbWFya2V0cy48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj5SZWxldmFudCB0byBFQVAgd291 bGQgYmUgdGhlIGFmb3JlbWVudGlvbmVkIFBhc3Nwb2ludCBtb2RlbCwgd2hpY2ggdXNlcyBuZXcg YW5kIGRpc3RpbmN0IENBcyBmb3IgdGhhdC4gVGhlcmUgYXJlIGRlZmluaXRlbHkgZmxhd3Mgd2l0 aCB0aGF0IChlLmcuIHdhbnRpbmcgc2FpZCBDQXMgdG8gd29yayB3aXRoIGJyb3dzZXJzKSwgYnV0 IHRoZXJlIGFyZSBwYXJ0cyBvZiBpdCB0aGF0IGRvIHdvcmsuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0 byIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9 IiI+VGhlcmXigJlzIG5vIHRlY2huaWNhbCByZWFzb24gdG8gcmVxdWlyZSB0aGUgdXNlIG9mIHRo ZSBzYW1lIHJvb3RzL3NhbWUgaGllcmFyY2h5LCBhbmQgYW1wbGUgYW5kIGFkZXF1YXRlIHJlYXNv biB0byBkaXN0aW5ndWlzaDogYm90aCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBhIHJvb3Qgc3Rv cmUgbWFpbnRhaW5lciAoZW5zdXJpbmcgY2VydGlmaWNhdGVzIGNvbXBseSB3aXRoIHBvbGljaWVz KSBhbmQgYXMNCiBhIGNlcnRpZmljYXRlIGNvbnN1bWVyIChtaW5pbWl6aW5nIHJpc2sgb2YgbWlz aXNzdWFuY2UsIGFsYSBGbGFtZSk8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0BE0A0F3AC37426EB32205DF59594069ciscocom_-- From nobody Wed Jan 8 05:14:53 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0325B1200F7; Wed, 8 Jan 2020 05:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 38P_2ddrDyqp; Wed, 8 Jan 2020 05:14:44 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04541200F4; Wed, 8 Jan 2020 05:14:43 -0800 (PST) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id A8D9D1A6; Wed, 8 Jan 2020 13:14:40 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Wed, 8 Jan 2020 08:14:38 -0500 Cc: EMU WG , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 13:14:47 -0000 On Jan 8, 2020, at 3:11 AM, Ryan Sleevi wrote: > However, if using the same set or CAs that popular OSes use for TLS, = it does mean that these CAs, and their customers, will still be subject = to the same agility requirements, and limited to the same profile as = TLS. Because of this, there=E2=80=99s ample reason to split further into = the dedicated hierarchy and dedicated EKU. We absolutely need a dedicated hierarchy. A major reason why EAP uses = id-kp-serverAuth is because no other hierarchy has been available. > For example, no CA that is =E2=80=9Cpublicly trusted=E2=80=9D for TLS = will be able to issue a certificate with id-kp-serverAuth and also = NAIRealm in the otherName, because they are contractually limited (and = in some cases, legally restricted by their local operating jurisdiction) = from including other forms of subjectAltNames. The use of distinct EKUs, = however, would allow them to do so, because those restrictions and = regulations are largely specific to id-kp-serverAuth. Except, of course, CAs don't really have a process to issue certs with = distinct EKUs. So they're impossible to get in practice. > Perhaps it wasn=E2=80=99t clear why I linked to that Atlassian issue = in The Register, but the point in doing so was to highlight that = _anyone_ can report to the CA when a customer is doing something = problematic. For the set of =E2=80=9Cpublicly trusted=E2=80=9D CAs, the = policies they are governed by require them to make available problem = reporting mechanisms, to respond to those within 24 hours, and if a = violation, to revoke within 24 hours to five days. >=20 > This is also why I kept emphasizing the timebomb nature of it: your = Wifi may totally work, until all of a sudden someone decides to report = it to the CA, which obligates the CA to revoke. There's a big difference between "my bank has some IT issues", and = "all of enterprise WiFi stops working, world-wide". That's my concern. = And, why I think existing practices will continue into the foreseeable = future. > Section 4.9.1.1 of the BRs requires revocation for =E2=80=9Cmisuse=E2=80= =9D. Misuse is intentionally (by the root programs, at least; some CAs = marketing departments would prefer otherwise) not defined by the BRs; = that=E2=80=99s something the CA defines, but is required to define. In = RFC 3647, this is often tied to Section 4.4.5, which maps to Section 1.4 = of the CA=E2=80=99s CP/CPS, although in practice CAs split this = definition up all over their CP/CPS. If mis-use isn't defined, then it's reasonable to argue that following = IETF standards isn't mis-use. > So... if we upgrade EAP implementations to use id-kp-eapOverLAN, = then only the EAP applications have to be updated. The common PKI = libraries don't change. >=20 > I agree that this goes away if you use an explicit EKU; the problem I = was describing exists only if the profile tries to require = id-kp-serverAuth. I don't see how. Validation of id-kp-serverAuth is the responsibility = of the application, not the TLS library. i.e. the TLS library exports = APIs which (a) do TLS, and (b) allow the application to selectively = validate certificates. It is inappropriate for a TLS library to enforce one EKU on all users = of TLS. And how would the library do that? It is entirely unaware of = the transport protocol (TCP / HTTPS vs EAP). > > Reusing private key material across protocols and use cases does = cause issues, >=20 > Such as? >=20 > = https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-fels= ch.pdf > = https://www.usenix.org/sites/default/files/conference/protected-files/secu= rity16_slides_aviram.pdf > = https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2015/08/2= 1/Tls13QuicAttacks.pdf On initial reading, none of those attacks are relevant here. The situation we have here is that we have a normal TLS "web server" = certificate which is being used for TLS. The transport protocol here is = EAP, not TCP. You seem to be claiming that there are security issues = with this use-case. I don't see how. i.e. we're not re-using the same private key material across disparate = encryption protocol. Which is what those papers discuss. We're using = TLS as TLS, in the same way that other people use TLS. It's 100% normal = TLS, with 100% the same certificate. The only thing that changes is the = transport layer which encapsulates the TLS protocol. I fail to see how using an EAP header is insecure, whereas using a TCP = header is fine. The only attack I'm aware of is an administrative one. = A TLS web admin can use the web certificate to set up an unauthorized = SSID. And, an EAP admin can use the EAP certificate to set up an = unauthorized web server. That's really it. > I=E2=80=99m sure everyone=E2=80=99s got a favorite citation, but the = TLS WG spent so long on formal security proofs in part because of the = number of issues that resulted from the negotiation and key reuse across = TLS versions, which are functionally =E2=80=9Cdifferent=E2=80=9D = protocols. But using the *same* TLS version across different transport protocols = is insecure? If so, why? > You=E2=80=99re right that we disagree. However, it=E2=80=99s important = to note: I didn=E2=80=99t say no repercussion. Sure. > In these situations, the CA is between a rock and a hard place: they = can follow their stated policies and contractual obligations, which = generally means breaking their customer because either the CA or the = customer did something wrong, or they can violate their stated policies = and obligations and risk distrust by the vendors that trust them. This = is the inherent challenge in any third-party operates CA: you can=E2=80=99= t delegate trust. I agree CAs can shut down individual use-cases if they desire. My = push-back is against the idea of turning off enterprise WiFi whole-sale, = world-wide. That's just not going to happen, no matter what the = policies of the CA. > I didn=E2=80=99t see much international news when the SHA-1 = deprecation in the TLS PKI reportedly threatened to leave entire = countries unable to process payments, did you? "My bank has IT issues due to stupid tech stuff" is completely = different from "Wi-Fi is broken world-wide". > In a fight between you and them, I'll bet on them. I understand = where you're coming from, but describing this practice as "done by some = vendors" is drastically minimizing the situation. >=20 > I=E2=80=99m not sure how this isn=E2=80=99t a full-throated support = for the broken and dangerous status quo. It's simple English. Stating that this *is* the status quo doesn't = mean I think it's a good idea. I've spent many messages agreeing it's = bad, and working on a better solution. It's not just possible to = describe my position as a "full-throated support for the broken and = dangerous status quo." That attitude is approaching ad hominem invective, and it's entirely = inappropriate. > I agree that we have a disconnect, but the context here is from = Owen=E2=80=99s original message, and I get the feeling you have a = different design or conclusion that you=E2=80=99ve not expressed but are = operating on, or that I=E2=80=99ve fundamentally misunderstood. The disconnect is largely that I don't think we can simply shut-down = Wi-Fi world-wide. Plus, you think that me describing the current system = means I'm supporting it. That's just not true. > That original discussion was in the context of public CAs. In the = world of locally-configured or private CAs, I don=E2=80=99t have as = strong opinions. However, if the objective is to get to an end state = where EAP is =E2=80=9Csecure by default=E2=80=9D and any EAP operator = can =E2=80=9Cjust=E2=80=9D get a certificate, then any discussion about = id-kp-serverAuth isn=E2=80=99t the extant status quo. I have no idea what that means. It reads like you're saying the use = of id-kp-serverAuth isn't the existing practice. Which it is. So... = why the disconnect? My recommendation for ~15 years for EAP has been that people should = use private CAs. It avoids all of the issues we're discussing here. > Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth. = wpa_supplicant checks for it, too. See src/tls/tlsv1_client_read.c. = The requirements of RFC 5216 Section 5.3 are followed. >=20 > Thanks for the pointer! Applying it post-validation is definitely an = interesting strategy, given the operational considerations and issues = like=20 > https://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf that can = allow for EKUs to bleed across hierarchies. I had mistakenly looked on = the validation side, since that=E2=80=99s where the identity validation = occurs. I think that's another disconnect. TLS libraries don't perform HTTPS = validation checks for all certificates. They can't, because they have = no idea what the underlying transport is. All the TLS library knows is = that it gets handed a TLS blob. The library does its TLS magic, and = hands decoded data to the application. All of the transport-specific validation happens in the application. = Because only the application knows what transport is being used. And = only the application can tie the two together. This is how TLS applications have been written for a very long time. = So I'm not sure why you describe checking id-kp-serverAuth as = "post-validation". It's not. It's just one step of many. The TLS = library does some checks, and the application does other checks. And = doing it this way isn't an "interesting strategy", it's the only = possible way to do it. it's been industry practice for decades, A think a good chunk of the disconnect here is simple unfamiliarity = with the subject space. > However, that=E2=80=99s still not intrinsically at odds with the = original message to Owen, or with the design principles I=E2=80=99ve = been trying to capture in these replies, which is that if the desire to = is to have zero-touch auth, you need to do one of the following: > 1) Define a new, non-overlapping trust store (whether for = id-kp-serverAuth or for id-kp-eapOverLan) with its own profile and = policies or > 2) Accept that any use of a shared or overlapping trust store will be = subject to the agility requirements of the existing trust stores (read: = OSes and browsers) >=20 > #2 is almost always going to work out badly for users and deployments, = which is why I=E2=80=99m so strongly discouraging it, even if it=E2=80=99s= technically viable, and so it=E2=80=99s best to accept the cost of #1 = upfront rather than defer it. I agree. > So id-kp-serverAuth is *entrenched*. It's not used sometimes by = some vendors. It's baked into existing standards and implementations. = Everyone uses it all of the time. Everywhere. Always. >=20 > And going back to the original message: is everyone always using = public CAs? I got the impression that our experiences are similar: which = is that it requires manual and explicit configuration, and there=E2=80=99s= no =E2=80=9Cout of the box=E2=80=9D trust store here, and that the use = of public CAs is not a concept that can MSP, because inherently, these = are all manually configured.- Many people use private CAs. Many use public CAs. *All* of them use = id-kp-serverAuth. Common EAP supplicants (MS / Apple / etc.) ship with = known root CAs. These root CAs are trusted by default for web browsing. = None are trusted by default for EAP. > My issue with Owen=E2=80=99s original proposal, and hopefully it = remains clear here: overlapping the PKIs should be a non-goal. = Distinguishing them at the EKU is fine; distinguishing them at the EKU = so extant CAs can issue from extant trust hierarchies is problematic and = should be a non-goal. At the same time, changing the EKU in order to = change the profile, and having supplicants strictly enforce that = profile, _is_ a good idea, in as much as it allows you to explicitly = transition to a sensible and defined profile and make a clean break. That's been my position from the beginning. Alan DeKok. From nobody Wed Jan 8 06:29:57 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2209F120044; Wed, 8 Jan 2020 06:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 fUgcLNkE5b1n; Wed, 8 Jan 2020 06:29:52 -0800 (PST) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6D012004C; Wed, 8 Jan 2020 06:29:52 -0800 (PST) Received: by mail-ed1-f49.google.com with SMTP id e10so2691736edv.9; Wed, 08 Jan 2020 06:29:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e5p7wD2zE/IpTTmXOZtEFPcimz9sNounaNNEBdFFrB0=; b=OVnojVb9wkMGRquJzlR9QfIKi8IPjpZvWGsb4hrTZ3i4qULaELN1gH6a25GmG181bt omqc7iQTJ1jIEyMbEzk+d3dtm/VoLvWitt8qNNSJrSmYdrxeOSqUs/CvlmezU8ja0vyn +yHWRhnA0xQV+NjAcc2YuGeY1gLXb2udkjfiVIJ6AuaKud3RFNHiMo+USeJ+89/wVfUN uCV/6HmQsZBb90fk0FOa6rFQDUwN/+er+d4VbQKjZW02w/u8CLZBztwDq72RvAIl2uOi nVLqgEl3vbUdn7BZr6WxP8WUp3HV7JJjr8oGtrSFl3ta+0WsZAeouh1lAhu72lQlq6Oz +6TA== X-Gm-Message-State: APjAAAXVlKP9hoabcybg1i94s8cGy7CFj5KyuWMSnk6WAbVuWM+vqrHS 2IKxdUdI+A9064gcOtR56G0Xsr8G X-Google-Smtp-Source: APXvYqxHgW2HpyNwxMyBk6QqRU48WZDIEGzio8tiQUHyRHRXW8RkM/LLmJLXZQjqEQDyicY50MnIBg== X-Received: by 2002:a17:906:6014:: with SMTP id o20mr5324452ejj.100.1578493790050; Wed, 08 Jan 2020 06:29:50 -0800 (PST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com. [209.85.221.43]) by smtp.gmail.com with ESMTPSA id dc5sm79833edb.61.2020.01.08.06.29.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 06:29:49 -0800 (PST) Received: by mail-wr1-f43.google.com with SMTP id c14so3589763wrn.7; Wed, 08 Jan 2020 06:29:49 -0800 (PST) X-Received: by 2002:adf:ebc1:: with SMTP id v1mr4731686wrn.351.1578493789350; Wed, 08 Jan 2020 06:29:49 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> In-Reply-To: <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> From: Ryan Sleevi Date: Wed, 8 Jan 2020 09:29:37 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Ryan Sleevi , EMU WG , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000098330c059ba1b951" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 14:29:55 -0000 --00000000000098330c059ba1b951 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2020 at 8:14 AM Alan DeKok wrote= : > Except, of course, CAs don't really have a process to issue certs with > distinct EKUs. So they're impossible to get in practice. > I'm not sure what your data to support this is, but this does not match the commercial space. While I think we're in agreement you "shouldn't" be using publicly trusted CAs, it's not at all true that they don't really have a process. Perhaps this was more true a decade ago, but the work on Delegated Credentials and Signed HTTP Exchanges - both which require custom certificate profiles for issuance, and both which are relatively recent and yet available from CAs. > If mis-use isn't defined, then it's reasonable to argue that following > IETF standards isn't mis-use. > I'm not sure how you reached this conclusion. I gave you an example of where misuse is defined to preclude such certificates, and that's but one of many examples if you read commercial CA's CP/CPSes. The argument you might be making is that "Well, they can change" - and sure, but that's just continuing to move the goalposts, when the high level message is the same: that overlaying with extant CAs, the original proposal, is a bad idea and full of sharp edges. > > So... if we upgrade EAP implementations to use id-kp-eapOverLAN, then > only the EAP applications have to be updated. The common PKI libraries > don't change. > > > > I agree that this goes away if you use an explicit EKU; the problem I > was describing exists only if the profile tries to require id-kp-serverAu= th. > > I don't see how. Validation of id-kp-serverAuth is the responsibility > of the application, not the TLS library. i.e. the TLS library exports AP= Is > which (a) do TLS, and (b) allow the application to selectively validate > certificates. > > It is inappropriate for a TLS library to enforce one EKU on all users o= f > TLS. And how would the library do that? It is entirely unaware of the > transport protocol (TCP / HTTPS vs EAP). > I'm guessing you may be more familiar with the embedded libraries that roll their own TLS stacks or build on OpenSSL? This isn't how many of the popular root stores and PKI libraries are implemented, which again goes back to Owen's original question, for "public" certificates and extant root stores - for example, the root stores and PKI/TLS libraries in a number of popular operating systems, such as Windows, macOS/iOS, Android, and ChromeOS. These libraries have the client say "I want it for TLS", and the validation library not only does validation for items like EKU, but that the certificate complies with the root store policies for such certificates. The root store policies may (as I mentioned previously) *also* have dependencies on the particular TLS library being used; that is, they're not designed to be used/operated outside of a given library. > The situation we have here is that we have a normal TLS "web server" > certificate which is being used for TLS. The transport protocol here is > EAP, not TCP. You seem to be claiming that there are security issues wit= h > this use-case. I don't see how. > I'm afraid we're quickly diverging again, because I'm worried this claim isn't being taken in the context it was made, so perhaps we should circle back to this once we're on the same page on the fundamentals? > > I=E2=80=99m sure everyone=E2=80=99s got a favorite citation, but the TL= S WG spent so > long on formal security proofs in part because of the number of issues th= at > resulted from the negotiation and key reuse across TLS versions, which ar= e > functionally =E2=80=9Cdifferent=E2=80=9D protocols. > > But using the *same* TLS version across different transport protocols i= s > insecure? I didn't say it was. > I agree CAs can shut down individual use-cases if they desire. My > push-back is against the idea of turning off enterprise WiFi whole-sale, > world-wide. That's just not going to happen, no matter what the policies > of the CA. > Great. I don't think anyone has suggested turning off enterprise WiFi, whole-scale, world-wide, or even anything remotely close to that, so I think we're good? > It's simple English. Stating that this *is* the status quo doesn't mea= n > I think it's a good idea. I've spent many messages agreeing it's bad, an= d > working on a better solution. It's not just possible to describe my > position as a "full-throated support for the broken and dangerous status > quo." > I think I've spent as many messages saying the same thing: let's work on a better solution. I've tried to articulate one several times, which doesn't involve "break WiFi world wide", so perhaps we can focus on that? > > I agree that we have a disconnect, but the context here is from Owen=E2= =80=99s > original message, and I get the feeling you have a different design or > conclusion that you=E2=80=99ve not expressed but are operating on, or tha= t I=E2=80=99ve > fundamentally misunderstood. > > The disconnect is largely that I don't think we can simply shut-down > Wi-Fi world-wide. Plus, you think that me describing the current system > means I'm supporting it. That's just not true. > I certainly haven't suggested we shut-down Wi-Fi world-wide. I have argued against specifying the extant behaviour, in as much as standards imply support, even informational. Even as tombstones of ideas that didn't work, they serve as attractive nuisances for implementors. > > That original discussion was in the context of public CAs. In the world > of locally-configured or private CAs, I don=E2=80=99t have as strong opin= ions. > However, if the objective is to get to an end state where EAP is =E2=80= =9Csecure by > default=E2=80=9D and any EAP operator can =E2=80=9Cjust=E2=80=9D get a ce= rtificate, then any > discussion about id-kp-serverAuth isn=E2=80=99t the extant status quo. > > I have no idea what that means. It reads like you're saying the use of > id-kp-serverAuth isn't the existing practice. Which it is. So... why th= e > disconnect? > Put simply: There's no "obtain a certificate from a public CA and it just works", where that certificate contains id-kp-serverAuth. I don't and haven't disagreed that people can and do use id-kp-serverAuth for private CAs, and I also don't doubt people obtain server certs from public CAs and then manually configure them, but there's no "it just works". If the goal is to specify "it just works", there's no reason or need to be constrained by id-kp-serverAuth. > My recommendation for ~15 years for EAP has been that people should use > private CAs. It avoids all of the issues we're discussing here. > We're in quite violent agreement :) > > Apple, Microsoft, and 3GPP all require the use of id-kp-serverAuth. > wpa_supplicant checks for it, too. See src/tls/tlsv1_client_read.c. The > requirements of RFC 5216 Section 5.3 are followed. > > > > Thanks for the pointer! Applying it post-validation is definitely an > interesting strategy, given the operational considerations and issues lik= e > > https://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf that can > allow for EKUs to bleed across hierarchies. I had mistakenly looked on th= e > validation side, since that=E2=80=99s where the identity validation occur= s. > > I think that's another disconnect. TLS libraries don't perform HTTPS > validation checks for all certificates. They can't, because they have no > idea what the underlying transport is. All the TLS library knows is that > it gets handed a TLS blob. The library does its TLS magic, and hands > decoded data to the application. > I think we have very different perspectives of the industry, and I suspect this is unfamiliarity with our divergent areas. I get the impression you're speaking more about embedded libraries and stuff like OpenSSL, and you're true. That's not an accurate reflection of the stacks in a number of operating systems - e.g. Windows, macOS/iOS, Linux Standard Base (via NSS), Android, or ChromeOS. These libraries and APIs, used to underpin much of the client TLS traffic (including browsers) are often abstracted APIs in which the library handles the transport as well as the verification, and they explicitly don't support disconnects. > > So id-kp-serverAuth is *entrenched*. It's not used sometimes by some > vendors. It's baked into existing standards and implementations. Everyo= ne > uses it all of the time. Everywhere. Always. > > > > And going back to the original message: is everyone always using public > CAs? I got the impression that our experiences are similar: which is that > it requires manual and explicit configuration, and there=E2=80=99s no =E2= =80=9Cout of the > box=E2=80=9D trust store here, and that the use of public CAs is not a co= ncept that > can MSP, because inherently, these are all manually configured.- > > Many people use private CAs. Many use public CAs. *All* of them use > id-kp-serverAuth. Common EAP supplicants (MS / Apple / etc.) ship with > known root CAs. These root CAs are trusted by default for web browsing. > None are trusted by default for EAP. > Right: we're in agreement, I believe? Getting "trusted by default for EAP" means disconnecting from id-kp-serverAuth, as part of, well, introducing the concept of "trusted by default for EAP". --00000000000098330c059ba1b951 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 8, 2020 at 8:14 AM Alan D= eKok <aland@deployingradius= .com> wrote:
=C2=A0 Except, of course, CAs don't really have a process to issue cert= s with distinct EKUs.=C2=A0 So they're impossible to get in practice.

I'm not sure what your data to suppo= rt this is, but this does not match the commercial space. While I think we&= #39;re in agreement you "shouldn't" be using publicly trusted= CAs, it's not at all true that they don't really have a process. P= erhaps this was more true a decade ago, but the work on Delegated Credentia= ls and Signed HTTP Exchanges - both which require custom certificate profil= es for issuance, and both which are relatively recent and yet available fro= m CAs.=C2=A0
=C2=A0
=C2=A0 If mis-use isn't defined, then it's reasonable to argue that= following IETF standards isn't mis-use.

I'm not sure how you reached this conclusion. I gave you an examp= le of where misuse is defined to preclude such certificates, and that's= but one of many examples if you read commercial CA's CP/CPSes. The arg= ument you might be making is that "Well, they can change" - and s= ure, but that's just continuing to move the goalposts, when the high le= vel message is the same: that overlaying with extant CAs, the original prop= osal, is a bad idea and full of sharp edges.
=C2=A0
>=C2=A0 =C2=A0So... if we upgrade EAP implementations to use id-kp-eapOv= erLAN, then only the EAP applications have to be updated.=C2=A0 The common = PKI libraries don't change.
>
> I agree that this goes away if you use an explicit EKU; the problem I = was describing exists only if the profile tries to require id-kp-serverAuth= .

=C2=A0 I don't see how.=C2=A0 Validation of id-kp-serverAuth is the res= ponsibility of the application, not the TLS library.=C2=A0 i.e. the TLS lib= rary exports APIs which (a) do TLS, and (b) allow the application to select= ively validate certificates.

=C2=A0 It is inappropriate for a TLS library to enforce one EKU on all user= s of TLS.=C2=A0 And how would the library do that?=C2=A0 It is entirely una= ware of the transport protocol (TCP / HTTPS vs EAP).
<= br>
I'm guessing you may be more familiar with the embedded l= ibraries that roll their own TLS stacks or build on OpenSSL?=C2=A0 This isn= 't how many of the popular root stores and PKI libraries are implemente= d, which again goes back to Owen's original question, for "public&= quot; certificates and extant root stores - for example, the root stores an= d PKI/TLS libraries in a number of popular operating systems, such as Windo= ws, macOS/iOS, Android, and ChromeOS.

These librar= ies have the client say "I want it for TLS", and the validation l= ibrary not only does validation for items like EKU, but that the certificat= e complies with the root store policies for such certificates. The root sto= re policies may (as I mentioned previously) *also* have dependencies on the= particular TLS library being used; that is, they're not designed to be= used/operated outside of a given library.
=C2=A0
=C2=A0 The situation we have here i= s that we have a normal TLS "web server" certificate which is bei= ng used for TLS.=C2=A0 The transport protocol here is EAP, not TCP.=C2=A0 Y= ou seem to be claiming that there are security issues with this use-case.= =C2=A0 I don't see how.

I'm afr= aid we're quickly diverging again, because I'm worried this claim i= sn't being taken in the context it was made, so perhaps we should circl= e back to this once we're on the same page on the fundamentals?
=C2=A0
> I=E2=80=99m sure everyone=E2=80=99s got a favorite citation, but the T= LS WG spent so long on formal security proofs in part because of the number= of issues that resulted from the negotiation and key reuse across TLS vers= ions, which are functionally =E2=80=9Cdifferent=E2=80=9D protocols.

=C2=A0 But using the *same* TLS version across different transport protocol= s is insecure?=C2=A0

I didn't say it w= as.
=C2=A0
=C2=A0 I agree CAs can shut down individual use-cases if they desire.=C2=A0= My push-back is against the idea of turning off enterprise WiFi whole-sale= , world-wide.=C2=A0 That's just not going to happen, no matter what the= policies of the CA.

Great. I don't= think anyone has suggested turning off enterprise WiFi, whole-scale, world= -wide, or even anything remotely close to that, so I think we're good?<= /div>
=C2=A0
=C2=A0 It's simple English.=C2=A0 Stating that this *is* the status quo= doesn't mean I think it's a good idea.=C2=A0 I've spent many m= essages agreeing it's bad, and working on a better solution.=C2=A0 It&#= 39;s not just possible to describe my position as a "full-throated sup= port for the broken and dangerous status quo."
I think I've spent as many messages saying the same thing:= let's work on a better solution. I've tried to articulate one seve= ral times, which doesn't involve "break WiFi world wide", so = perhaps we can focus on that?
=C2=A0
> I agree that we have a disconnect, but the context here is from Owen= =E2=80=99s original message, and I get the feeling you have a different des= ign or conclusion that you=E2=80=99ve not expressed but are operating on, o= r that I=E2=80=99ve fundamentally misunderstood.

=C2=A0 The disconnect is largely that I don't think we can simply shut-= down Wi-Fi world-wide.=C2=A0 Plus, you think that me describing the current= system means I'm supporting it.=C2=A0 That's just not true.

I certainly haven't suggested we shut-dow= n Wi-Fi world-wide. I have argued against specifying the extant behaviour, = in as much as standards imply support, even informational. Even as tombston= es of ideas that didn't work, they serve as attractive nuisances for im= plementors.
=C2=A0
> That original discussion was in the context of public CAs. In the worl= d of locally-configured or private CAs, I don=E2=80=99t have as strong opin= ions. However, if the objective is to get to an end state where EAP is =E2= =80=9Csecure by default=E2=80=9D and any EAP operator can =E2=80=9Cjust=E2= =80=9D get a certificate, then any discussion about id-kp-serverAuth isn=E2= =80=99t the extant status quo.

=C2=A0 I have no idea what that means.=C2=A0 It reads like you're sayin= g the use of id-kp-serverAuth isn't the existing practice.=C2=A0 Which = it is.=C2=A0 So... why the disconnect?

= Put simply: There's no "obtain a certificate from a public CA and = it just works", where that certificate contains id-kp-serverAuth. I do= n't and haven't disagreed that people can and do use id-kp-serverAu= th for private CAs, and I also don't doubt people obtain server certs f= rom public CAs and then manually configure them, but there's no "i= t just works". If the goal is to specify "it just works", th= ere's no reason or need to be constrained by id-kp-serverAuth.=C2=A0
=C2=A0
=C2=A0 My recommendation for ~15 years for EAP has been that people should = use private CAs.=C2=A0 It avoids all of the issues we're discussing her= e.

We're in quite violent agreement= :)
=C2=A0
>=C2=A0 =C2=A0Apple, Microsoft, and 3GPP all require the use of id-kp-se= rverAuth.=C2=A0 wpa_supplicant checks for it, too.=C2=A0 See src/tls/tlsv1_= client_read.c.=C2=A0 The requirements of RFC 5216 Section 5.3 are followed.=
>
> Thanks for the pointer! Applying it post-validation is definitely an i= nteresting strategy, given the operational considerations and issues like <= br> > https://trailofbits.files.wordpres= s.com/2012/06/flame-md5.pdf that can allow for EKUs to bleed across hie= rarchies. I had mistakenly looked on the validation side, since that=E2=80= =99s where the identity validation occurs.

=C2=A0 I think that's another disconnect.=C2=A0 TLS libraries don't= perform HTTPS validation checks for all certificates.=C2=A0 They can't= , because they have no idea what the underlying transport is.=C2=A0 All the= TLS library knows is that it gets handed a TLS blob.=C2=A0 The library doe= s its TLS magic, and hands decoded data to the application.

I think we have very different perspectives of the ind= ustry, and I suspect this is unfamiliarity with our divergent areas. I get = the impression you're speaking more about embedded libraries and stuff = like OpenSSL, and you're true. That's not an accurate reflection of= the stacks in a number of operating systems - e.g. Windows, macOS/iOS, Lin= ux Standard Base (via NSS), Android, or ChromeOS. These libraries and APIs,= used to underpin much of the client TLS traffic (including browsers) are o= ften abstracted APIs in which the library handles the transport as well as = the verification, and they explicitly don't support disconnects.
<= div>=C2=A0
>=C2= =A0 =C2=A0So id-kp-serverAuth is *entrenched*.=C2=A0 It's not used some= times by some vendors.=C2=A0 It's baked into existing standards and imp= lementations.=C2=A0 Everyone uses it all of the time.=C2=A0 Everywhere.=C2= =A0 Always.
>
> And going back to the original message: is everyone always using publi= c CAs? I got the impression that our experiences are similar: which is that= it requires manual and explicit configuration, and there=E2=80=99s no =E2= =80=9Cout of the box=E2=80=9D trust store here, and that the use of public = CAs is not a concept that can MSP, because inherently, these are all manual= ly configured.-

=C2=A0 Many people use private CAs.=C2=A0 Many use public CAs.=C2=A0 *All* = of them use id-kp-serverAuth.=C2=A0 Common EAP supplicants (MS / Apple / et= c.) ship with known root CAs.=C2=A0 These root CAs are trusted by default f= or web browsing.=C2=A0 None are trusted by default for EAP.

Right: we're in agreement, I believe? Getting &quo= t;trusted by default for EAP" means disconnecting from id-kp-serverAut= h, as part of, well, introducing the concept of "trusted by default fo= r EAP".
--00000000000098330c059ba1b951-- From nobody Wed Jan 8 07:38:24 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351BB12013D; Wed, 8 Jan 2020 07:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 L34sVuZg-T0Y; Wed, 8 Jan 2020 07:38:21 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0125912001A; Wed, 8 Jan 2020 07:38:21 -0800 (PST) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id C215777; Wed, 8 Jan 2020 15:38:17 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Wed, 8 Jan 2020 10:38:16 -0500 Cc: EMU WG , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <10F5CCFB-7DBD-40DF-9C65-BCD0EB8CB838@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 15:38:23 -0000 To clarify. we agree on the following: * id-kp-serverAuth is wrong to use for EAP * we should use something else, whatever that is The rest of the disagreement is (from what I see), bringing up = situations or use-cases which are unrelated to EAP, and therefore = confusing the issue. On Jan 8, 2020, at 9:29 AM, Ryan Sleevi wrote: > I'm not sure what your data to support this is, but this does not = match the commercial space. While I think we're in agreement you = "shouldn't" be using publicly trusted CAs, it's not at all true that = they don't really have a process. Perhaps this was more true a decade = ago, but the work on Delegated Credentials and Signed HTTP Exchanges - = both which require custom certificate profiles for issuance, and both = which are relatively recent and yet available from CAs.=20 I've looked, and haven't been able to find a process where I can get a = cert with id-kp-eapOverLan set. > If mis-use isn't defined, then it's reasonable to argue that = following IETF standards isn't mis-use. >=20 > I'm not sure how you reached this conclusion. I gave you an example of = where misuse is defined to preclude such certificates, Hmm... that wasn't clear at all. I can't find any policies which say = "certificates will be revoked if they're used for purposes other than = TLS web server". All of the text I see on revocation is about malware, = leak of private keys, etc. > I'm guessing you may be more familiar with the embedded libraries that = roll their own TLS stacks or build on OpenSSL? I'm familiar with application use-cases. Most EAP applications use = OpenSSL. As do RADIUS applications, web servers, DNS servers, etc. = They all operate the same way, Other systems implement things differently, of course. OS vendors are = locking down their cert stores to more stringently control access. This = includes limiting the API used by applications. What other PKI systems = do is irrelevant, because they don't implement the application = protocols. > [re: security issues with using TLS web server certs with EAP ] >=20 > I'm afraid we're quickly diverging again, because I'm worried this = claim isn't being taken in the context it was made, so perhaps we should = circle back to this once we're on the same page on the fundamentals? I was reacting to the following statement: > I will say that using TLS (id-kp-serverAuth) certificates, from the = intersection of CAs that are commonly trusted by operating systems and = browsers, is bad. It will create security issues, will create = interoperability issues, and will not help users. I asked *what* security issues there were, and what interoperability = issues existed when these certificates were used for EAP. I stated that = 15+ years of experience showed no issues. Your response was: > This is empirically false. The use of certain CA=E2=80=99s = certificates in wireless deployments has absolutely been a barrier to = compliance and improvements. I asked again for evidence, and got told: > Reusing private key material across protocols and use cases does cause = issues, With pointers to papers that shows private key usage across disparate = encryption methods. These papers are entirely irrelevant to the = use-case discussed here, i.e. these certs being used for EAP-TLS. So I don't know how I'm misunderstanding you. You claimed the = use-case was insecure, and it would cause interoperability issues.=20 Maybe you're referring to other use-cases. But if so, you're not = making that clear. I've been talking about EAP and WiFi. Other = use-cases aren't applicable here. > Great. I don't think anyone has suggested turning off enterprise WiFi, = whole-scale, world-wide, or even anything remotely close to that, so I = think we're good? Suggesting that CAs will revoke all certificates mis-using = id-kp-serverAuth *is* implying that enterprise WiFi will be disabled = world-wide. I explained in detail why I believe this correlation to be = true. > Put simply: There's no "obtain a certificate from a public CA and it = just works", where that certificate contains id-kp-serverAuth. The only required step is for supplicants to explicitly enable that CA = to be used for EAP. As I said earlier, the root CAs are all enabled for = the web, and none are enabled by default for EAP. > I don't and haven't disagreed that people can and do use = id-kp-serverAuth for private CAs, and I also don't doubt people obtain = server certs from public CAs and then manually configure them, but = there's no "it just works". If the goal is to specify "it just works", = there's no reason or need to be constrained by id-kp-serverAuth.=20 Which is what I've been saying for a long time. My goal to move to = something else is to get it to the point where it just works. > I think we have very different perspectives of the industry, and I = suspect this is unfamiliarity with our divergent areas. I get the = impression you're speaking more about embedded libraries and stuff like = OpenSSL, and you're true. That's not an accurate reflection of the = stacks in a number of operating systems - e.g. Windows, macOS/iOS, Linux = Standard Base (via NSS), Android, or ChromeOS. These libraries and APIs, = used to underpin much of the client TLS traffic (including browsers) are = often abstracted APIs in which the library handles the transport as well = as the verification, and they explicitly don't support disconnects. i.e. when you say "the library handles the transport as well as the = verification", this is manifestly not true for EAP. That's my point. = I'm trying to discuss EAP use-cases. Linux uses wpa_supplicant (or iwd), which *do* work the way I = described. The Apple supplicant code is also online, and last I = checked, also works this way. I don't know how the MS code works, but I = highly doubt that their crypto library implements EAP. I suspect that = they also have an EAP implementation which calls a TLS library to do the = TLS work. So I don't really care how OS vendors implement certificate checking = for HTTPS. It doesn't apply to EAP. Bringing up irrelevant issues is = just confusing and unhelpful. > Right: we're in agreement, I believe? Getting "trusted by default for = EAP" means disconnecting from id-kp-serverAuth, as part of, well, = introducing the concept of "trusted by default for EAP". Yes. Alan DeKok. From nobody Wed Jan 8 08:29:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702D0120837; Wed, 8 Jan 2020 08:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 j7wMf-LSKUR4; Wed, 8 Jan 2020 08:29:47 -0800 (PST) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE8F1208A3; Wed, 8 Jan 2020 08:29:46 -0800 (PST) Received: by mail-ed1-f45.google.com with SMTP id c26so3052088eds.8; Wed, 08 Jan 2020 08:29:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/K8b98+jjdPVVkpao27qaO6pRTTv/TQ/uFzB7qi7K7s=; b=d8zEXlkoEJ9si4KDvqIYFp5OafyGkWkelFGSmVk3OOH4Iv9ArGbBJBhV3O//7wIMPF irc+dfVdUo9z0lRekmLYDactjQSF8Yclm5BC97qASC/As4gkxNXp7CEWLDAB2qSWM7rb L+kAWz1ipjxZcuTgeWxazBNLQIULRmIxguO55ht25cK0KKawHCM9fpqyUvMLkwYQiwZy qkOotZawW0VtWNGt1f7jeeE3sEtzLNmFWKzRMySt1fl9Xvc1A39LTA6H/oeqFTH0zdLV zJobLqQFXRqVYBBqw5cOpmE5/Ld3jPa3wTNDIqoA4Jg0FZL9GnEYC1Re6+JBRYubI/Ue sw/A== X-Gm-Message-State: APjAAAWBVRGv7WUNcnIoJr1Gu5VqKc9TH3mIEj0b3AZsQzWD/zEbapE4 GXC/8h35H5RKHGJNDJ8FkKJtb3OH X-Google-Smtp-Source: APXvYqxnkKrrI2CH92iUsb3fynYU0e1xMBu8EvPi02EEHsSnkymPtT/V15tRTv+gZN4CZQHqzkmXxg== X-Received: by 2002:a05:6402:149a:: with SMTP id e26mr6478046edv.198.1578500984970; Wed, 08 Jan 2020 08:29:44 -0800 (PST) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com. [209.85.128.44]) by smtp.gmail.com with ESMTPSA id r24sm81531edp.15.2020.01.08.08.29.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 08:29:44 -0800 (PST) Received: by mail-wm1-f44.google.com with SMTP id a5so3170590wmb.0; Wed, 08 Jan 2020 08:29:44 -0800 (PST) X-Received: by 2002:a1c:1fc5:: with SMTP id f188mr5144515wmf.55.1578500983970; Wed, 08 Jan 2020 08:29:43 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <10F5CCFB-7DBD-40DF-9C65-BCD0EB8CB838@deployingradius.com> In-Reply-To: <10F5CCFB-7DBD-40DF-9C65-BCD0EB8CB838@deployingradius.com> From: Ryan Sleevi Date: Wed, 8 Jan 2020 11:29:32 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Ryan Sleevi , EMU WG , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006d6315059ba3669b" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 16:29:51 -0000 --0000000000006d6315059ba3669b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2020 at 10:38 AM Alan DeKok wrote: > The rest of the disagreement is (from what I see), bringing up > situations or use-cases which are unrelated to EAP, and therefore confusi= ng > the issue. > They're related to the proposal that started this thread, which I'm trying to focus the discussion on, and which may be why we keep finding misalignment. > On Jan 8, 2020, at 9:29 AM, Ryan Sleevi wrote: > > I'm not sure what your data to support this is, but this does not match > the commercial space. While I think we're in agreement you "shouldn't" be > using publicly trusted CAs, it's not at all true that they don't really > have a process. Perhaps this was more true a decade ago, but the work on > Delegated Credentials and Signed HTTP Exchanges - both which require cust= om > certificate profiles for issuance, and both which are relatively recent a= nd > yet available from CAs. > > I've looked, and haven't been able to find a process where I can get a > cert with id-kp-eapOverLan set. > Thanks. It seems like you meant process as "They won't sell it to me", and I meant process as "They can't sell it to me / Don't know how to sell it to me". > > If mis-use isn't defined, then it's reasonable to argue that followin= g > IETF standards isn't mis-use. > > > > I'm not sure how you reached this conclusion. I gave you an example of > where misuse is defined to preclude such certificates, > > Hmm... that wasn't clear at all. I can't find any policies which say > "certificates will be revoked if they're used for purposes other than TLS > web server". The CA must revoke if the certificate is misused; that's required by contract. The CA defines what misuse means. A number of CAs define misuse as "used for purposes other than TLS web server" Ergo, obtaining and using certificates with EAP means these certificates are at risk of revocation. > > I'm guessing you may be more familiar with the embedded libraries that > roll their own TLS stacks or build on OpenSSL? > > I'm familiar with application use-cases. Most EAP applications use > OpenSSL. As do RADIUS applications, web servers, DNS servers, etc. They > all operate the same way, > > Other systems implement things differently, of course. OS vendors are > locking down their cert stores to more stringently control access. This > includes limiting the API used by applications. What other PKI systems d= o > is irrelevant, because they don't implement the application protocols. > It's extremely relevant to the original proposal, at https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM, and to the subsequent follow-ups (e.g. https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ ) If you reject messages like that, then it's understandable you might disagree on the relevance. If you support the goal (of no-touch access), then it's still relevant in as much as there's plenty of academic literature on how you design those APIs (e.g. https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html ), but that's more of an implementation discussion. > > I will say that using TLS (id-kp-serverAuth) certificates, from the > intersection of CAs that are commonly trusted by operating systems and > browsers, is bad. It will create security issues, will create > interoperability issues, and will not help users. > > I asked *what* security issues there were, and what interoperability > issues existed when these certificates were used for EAP. I stated that > 15+ years of experience showed no issues. Your response was: > > > This is empirically false. The use of certain CA=E2=80=99s certificates= in > wireless deployments has absolutely been a barrier to compliance and > improvements. > > I asked again for evidence, and got told: > I didn't see interpret your reply as you've summarized, but your follow-up indicates that you disagree that it's a "security" issue if, for example, a CA decides to not revoke certain certificates or to keep issuing certain certificates, because that's seemingly seen as an interoperability issue. Again, this is in the context of using the same set of CAs for EAP and for TLS web server - I'm not speaking about other contexts here. In these contexts, the security issue is for the TLS clients trusting certificates from CAs that violate the policies. For example, continuing to issue SHA-1 certificates to support devices/clients that only trust SHA-1 certificates, from the same hierarchy used for TLS. The interoperability issues are indistinguishable from security issues in situations like this. > > Reusing private key material across protocols and use cases does cause > issues, > > With pointers to papers that shows private key usage across disparate > encryption methods. These papers are entirely irrelevant to the use-case > discussed here, i.e. these certs being used for EAP-TLS. > It looks like I should have spelled out a situation clearer: - Consider that TLS 1.2 had interoperability issues with wpa_supplicant versions and certain Cisco devices, due to confusion about the PRF algorithm used - This led Apple, Google, and Microsoft to not enable TLS 1.2 for their supplicants for quite some time, due to the ineroperability issues - These concerns were not applicable to the use of TLS web server authentication, and such clients were able (and long had enabled) TLS 1.2 support - As a consequence, if the EAP-TLS and TLS web server shared the same certificate, you can exercise some of those cross-protocol attacks - This similarly applies to TLS 1.2 (EAP) vs TLS 1.3 (web) deployments This is an example of how certs being used for EAP-TLS, indistinguishable from the Web hierarchy, leads to security issues. We may disagree on categorization (e.g. "It's a deployment issue with a site, not an inherent security issue"), but my objective is to try to prevent situations where deployment issues result in security issues. Hence the recommendation to make it *impossible* to reuse the same certificate across these different consumers and use cases. > > Great. I don't think anyone has suggested turning off enterprise WiFi, > whole-scale, world-wide, or even anything remotely close to that, so I > think we're good? > > Suggesting that CAs will revoke all certificates mis-using > id-kp-serverAuth *is* implying that enterprise WiFi will be disabled > world-wide. I explained in detail why I believe this correlation to be > true. > Thanks. I think this conclusion is based on a misunderstanding. I have not suggested CAs are going to know which certificates are used for EAP-TLS and proactively revoke those. As you've correctly noted, and I've agreed, they can't know. What I have suggested is that anyone, at any time, may be able to notify the CA of potential misuse (according to the CA's definition), thus requiring revocation. This creates an operational burden for those deployments, and creates an incentive for the CA to ignore their stated policies, which creates security issues for TLS clients (any CA ignoring their policies is, fundamentally, indistinguishable from a security issue). The way to mitigate that risk - of required revocation - involves clients and servers make sure the certificates they accept are not subjected to that. > > Put simply: There's no "obtain a certificate from a public CA and it > just works", where that certificate contains id-kp-serverAuth. > > The only required step is for supplicants to explicitly enable that CA > to be used for EAP. As I said earlier, the root CAs are all enabled for > the web, and none are enabled by default for EAP. > Yes, but I don't think that fits with the objectives of the original message, https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM and the followups, such as https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ My observations have been that the means of achieving that goal are problematic; that is, we _don't_ want to enable the extant root CAs for EAP by default, with the described mechanism. My comments MUST be taken in consideration as describing what that future world should look like and how to get there. So I don't really care how OS vendors implement certificate checking for > HTTPS. It doesn't apply to EAP. Bringing up irrelevant issues is just > confusing and unhelpful. Perhaps you missed replies like https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ tha= t brought that up? It sounds like much of our disagreement has just been on lacking the context from the overall thread and discussion (with others), and thus arriving at different conclusions based on that lack of context? --0000000000006d6315059ba3669b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 8, 2020 at 10:38 AM Alan = DeKok <aland@deployingradiu= s.com> wrote:
=C2=A0 The rest of the disagreement is (from what I see), bringing up situa= tions or use-cases which are unrelated to EAP, and therefore confusing the = issue.

They're related to the propo= sal that started this thread, which I'm trying to focus the discussion = on, and which may be why we keep finding misalignment.
=C2=A0
On Jan 8, 2020, at 9:29 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> I'm not sure what your data to support this is, but this does not = match the commercial space. While I think we're in agreement you "= shouldn't" be using publicly trusted CAs, it's not at all true= that they don't really have a process. Perhaps this was more true a de= cade ago, but the work on Delegated Credentials and Signed HTTP Exchanges -= both which require custom certificate profiles for issuance, and both whic= h are relatively recent and yet available from CAs.

=C2=A0 I've looked, and haven't been able to find a process where I= can get a cert with id-kp-eapOverLan set.

<= div>Thanks. It seems like you meant process as "They won't sell it= to me", and I meant process as "They can't sell it to me / D= on't know how to sell it to me".
=C2=A0
>=C2=A0 =C2=A0If mis-use isn't defined, then it's reasonable to = argue that following IETF standards isn't mis-use.
>
> I'm not sure how you reached this conclusion. I gave you an exampl= e of where misuse is defined to preclude such certificates,

=C2=A0 Hmm... that wasn't clear at all.=C2=A0 I can't find any poli= cies which say "certificates will be revoked if they're used for p= urposes other than TLS web server".=C2=A0

<= div>The CA must revoke if the certificate is misused; that's required b= y contract.
The CA defines what misuse means.
A number = of CAs define misuse as "used for purposes other than TLS web server&q= uot;
Ergo, obtaining and using certificates with EAP means these = certificates are at risk of revocation.
=C2=A0
> I'm guessing you may be more familiar with the embedded libraries = that roll their own TLS stacks or build on OpenSSL?

=C2=A0 I'm familiar with application use-cases.=C2=A0 Most EAP applicat= ions use OpenSSL.=C2=A0 As do RADIUS applications, web servers, DNS servers= , etc.=C2=A0 They all operate the same way,

=C2=A0 Other systems implement things differently, of course.=C2=A0 OS vend= ors are locking down their cert stores to more stringently control access.= =C2=A0 This includes limiting the API used by applications.=C2=A0 What othe= r PKI systems do is irrelevant, because they don't implement the applic= ation protocols.

It's extremely rel= evant to the original proposal, at=C2=A0https://mailarchive.ietf.o= rg/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM, and to the subsequent fo= llow-ups (e.g.=C2=A0https://mailarchive.ietf.org/arch/msg/spasm/E9= CpTnuCNqV9d-2hnB0c3fJ4NtQ=C2=A0)

If you reject= messages like that, then it's understandable you might disagree on the= relevance.
If you support the goal (of no-touch access), then it= 's still relevant in as much as there's plenty of academic literatu= re on how you design those APIs (e.g.=C2=A0https://crypto.stanford.e= du/~dabo/pubs/abstracts/ssl-client-bugs.html=C2=A0), but that's mor= e of an implementation discussion.
=C2=A0
> I will say that using TLS (id-kp-serverAuth) certificates, from the in= tersection of CAs that are commonly trusted by operating systems and browse= rs, is bad. It will create security issues, will create interoperability is= sues, and will not help users.

=C2=A0 I asked *what* security issues there were, and what interoperability= issues existed when these certificates were used for EAP.=C2=A0 I stated t= hat 15+ years of experience showed no issues.=C2=A0 Your response was:

> This is empirically false. The use of certain CA=E2=80=99s certificate= s in wireless deployments has absolutely been a barrier to compliance and i= mprovements.

=C2=A0 I asked again for evidence, and got told:

<= /div>
I didn't see interpret your reply as you've summarized, b= ut your follow-up indicates that you disagree that it's a "securit= y" issue if, for example, a CA decides to not revoke certain certifica= tes or to keep issuing certain certificates, because that's seemingly s= een as an interoperability issue. Again, this is in the context of using th= e same set of CAs for EAP and for TLS web server - I'm not speaking abo= ut other contexts here. In these contexts, the security issue is for the TL= S clients trusting certificates from CAs that violate the policies. For exa= mple, continuing to issue SHA-1 certificates to support devices/clients tha= t only trust SHA-1 certificates, from the same hierarchy used for TLS. The = interoperability issues are indistinguishable from security issues in situa= tions like this.
=C2=A0
> Reusing private key material across protocols and use cases does cause= issues,

=C2=A0 =C2=A0With pointers to papers that shows private key usage across di= sparate encryption methods.=C2=A0 These papers are entirely irrelevant to t= he use-case discussed here, i.e. these certs being used for EAP-TLS.

It looks like I should have spelled out a sit= uation clearer:
- Consider that TLS 1.2 had interoperability issu= es with wpa_supplicant versions and certain Cisco devices, due to confusion= about the PRF algorithm used
=C2=A0 - This led Apple, Google, an= d Microsoft to not enable TLS 1.2 for their supplicants for quite some time= , due to the ineroperability issues
=C2=A0 - These concerns were = not applicable to the use of TLS web server authentication, and such client= s were able (and long had enabled) TLS 1.2 support
=C2=A0 - As a = consequence, if the EAP-TLS and TLS web server shared the same certificate,= you can exercise some of those cross-protocol attacks
=C2=A0 - T= his similarly applies to TLS 1.2 (EAP) vs TLS 1.3 (web) deployments

This is an example of how certs being used for EAP-TLS, i= ndistinguishable from the Web hierarchy, leads to security issues. We may d= isagree on categorization (e.g. "It's a deployment issue with a si= te, not an inherent security issue"), but my objective is to try to pr= event situations where deployment issues result in security issues. Hence t= he recommendation to make it *impossible* to reuse the same certificate acr= oss these different consumers and use cases.
=C2=A0
> Great. I don't think anyone has suggested turning off enterprise W= iFi, whole-scale, world-wide, or even anything remotely close to that, so I= think we're good?

=C2=A0 Suggesting that CAs will revoke all certificates mis-using id-kp-ser= verAuth *is* implying that enterprise WiFi will be disabled world-wide.=C2= =A0 I explained in detail why I believe this correlation to be true.

Thanks. I think this conclusion is based on a= misunderstanding. I have not suggested CAs are going to know which certifi= cates are used for EAP-TLS and proactively revoke those. As you've corr= ectly noted, and I've agreed, they can't know. What I have suggeste= d is that anyone, at any time, may be able to notify the CA of potential mi= suse (according to the CA's definition), thus requiring revocation. Thi= s creates an operational burden for those deployments, and creates an incen= tive for the CA to ignore their stated policies, which creates security iss= ues for TLS clients (any CA ignoring their policies is, fundamentally, indi= stinguishable from a security issue).

The way to m= itigate that risk - of required revocation - involves clients and servers m= ake sure the certificates they accept are not subjected to that.
= =C2=A0
> Put simply: There's no "obtain a certificate from a public CA= and it just works", where that certificate contains id-kp-serverAuth.=

=C2=A0 The only required step is for supplicants to explicitly enable that = CA to be used for EAP.=C2=A0 As I said earlier, the root CAs are all enable= d for the web, and none are enabled by default for EAP.

Yes, but I don't think that fits with the objectives o= f the original message,=C2=A0=C2=A0https://mailarchive.ietf.org/ar= ch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM=C2=A0and the followups, such a= s=C2=A0https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2= hnB0c3fJ4NtQ

My observations have been that th= e means of achieving that goal are problematic; that is, we _don't_ wan= t to enable the extant root CAs for EAP by default, with the described mech= anism. My comments MUST be taken in consideration as describing what that f= uture world should look like and how to get there.

=C2=A0 So I don't really care how OS vendors implement certificate chec= king for HTTPS.=C2=A0 It doesn't apply to EAP.=C2=A0 Bringing up irrele= vant issues is just confusing and unhelpful.

Perhaps you missed replies like=C2=A0https://mailarchive.ietf.or= g/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ=C2=A0that brought that up?=

It sounds like much of our disagreement has just = been on lacking the context from the overall thread and discussion (with ot= hers), and thus arriving at different conclusions based on that lack of con= text?=C2=A0
--0000000000006d6315059ba3669b-- From nobody Wed Jan 8 10:05:32 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3880F120059; Wed, 8 Jan 2020 10:05:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <157850673005.22571.2917503256026347682@ietfa.amsl.com> Date: Wed, 08 Jan 2020 10:05:30 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 18:05:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information Authors : Tadahiko Ito Sean Turner Filename : draft-ietf-lamps-5480-ku-clarifications-00.txt Pages : 3 Date : 2020-01-08 Abstract: This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarifications-00 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 nobody Wed Jan 8 10:07:49 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3B1200F3; Wed, 8 Jan 2020 10:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aT7vLQ4kdLpL; Wed, 8 Jan 2020 10:07:41 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6930E120059; Wed, 8 Jan 2020 10:07:41 -0800 (PST) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 0469E545; Wed, 8 Jan 2020 18:07:37 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Wed, 8 Jan 2020 13:07:36 -0500 Cc: EMU WG , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1903C654-1AD4-4974-B090-93B569A03EC0@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <10F5CCFB-7DBD-40DF-9C65-BCD0EB8CB838@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 18:07:44 -0000 On Jan 8, 2020, at 11:29 AM, Ryan Sleevi wrote: > On Wed, Jan 8, 2020 at 10:38 AM Alan DeKok = wrote: > The rest of the disagreement is (from what I see), bringing up = situations or use-cases which are unrelated to EAP, and therefore = confusing the issue. >=20 > They're related to the proposal that started this thread, which I'm = trying to focus the discussion on, and which may be why we keep finding = misalignment. I'm not sure how that happened, but whatever. > Thanks. It seems like you meant process as "They won't sell it to me", = and I meant process as "They can't sell it to me / Don't know how to = sell it to me". I mean both. > Other systems implement things differently, of course. OS vendors = are locking down their cert stores to more stringently control access. = This includes limiting the API used by applications. What other PKI = systems do is irrelevant, because they don't implement the application = protocols. >=20 > It's extremely relevant to the original proposal, at = https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM, = and to the subsequent follow-ups (e.g. = https://mailarchive.ietf.org/arch/msg/spasm/E9CpTnuCNqV9d-2hnB0c3fJ4NtQ = ) >=20 > If you reject messages like that, then it's understandable you might = disagree on the relevance. I don't see how it's relevant, because EAP just isn't implemented like = that. I've asked for explanations, and gotten unsatisfactory answers. I also don't see why you would construe my comments as "rejecting" = those messages. I've taken great pains to explain my position clearly, = and in detail. I'm starting to wonder if this conversation can go anywhere. Why are = you putting negative motives on my behaviour? > I didn't see interpret your reply as you've summarized, but your = follow-up indicates that you disagree that it's a "security" issue if, = for example, a CA decides to not revoke certain certificates or to keep = issuing certain certificates, because that's seemingly seen as an = interoperability issue. Again, this is in the context of using the same = set of CAs for EAP and for TLS web server - I'm not speaking about other = contexts here. In these contexts, the security issue is for the TLS = clients trusting certificates from CAs that violate the policies. For = example, continuing to issue SHA-1 certificates to support = devices/clients that only trust SHA-1 certificates, from the same = hierarchy used for TLS. The interoperability issues are = indistinguishable from security issues in situations like this. It's a *procedural* issue, and a *policy* issue, IMHO. There is no = additional *security* issue. Even your examples below aren't EAP = specific. They apply to any uses of TLS. > It looks like I should have spelled out a situation clearer: > - Consider that TLS 1.2 had interoperability issues with = wpa_supplicant versions and certain Cisco devices, due to confusion = about the PRF algorithm used > - This led Apple, Google, and Microsoft to not enable TLS 1.2 for = their supplicants for quite some time, due to the ineroperability issues > - These concerns were not applicable to the use of TLS web server = authentication, and such clients were able (and long had enabled) TLS = 1.2 support > - As a consequence, if the EAP-TLS and TLS web server shared the = same certificate, you can exercise some of those cross-protocol attacks The same attack applies to any application using TLS, including HTTP. = And most people are aware enough to *not* use the same certificate for = multiple systems. Which means that this attack is (a) not specific to = EAP, and (b) only applicable in misconfigured systems. It helps to describe *precisely* what you're talking about. I've been = asking for many messages now exactly what you mean. Until now, I've = been getting the run-around. That's unproductive. > The only required step is for supplicants to explicitly enable that = CA to be used for EAP. As I said earlier, the root CAs are all enabled = for the web, and none are enabled by default for EAP. >=20 > Yes, but I don't think that fits with the objectives of the original = message, Please pay attention. That is the way things work NOW. There should be no confusion about = what OBJECTIVES I'm working towards, because I stated them clearly in = the message you're replying to. Such replies are unproductive. > It sounds like much of our disagreement has just been on lacking the = context from the overall thread and discussion (with others), and thus = arriving at different conclusions based on that lack of context?=20 And TBH, me asking for specific details, and getting answers which are = only tangentially related to the question. Alan DeKok. From nobody Wed Jan 8 10:12:03 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9C5120059 for ; Wed, 8 Jan 2020 10:12:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 itGANi1upJNC for ; Wed, 8 Jan 2020 10:12:00 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48263120019 for ; Wed, 8 Jan 2020 10:12:00 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id k6so3497005qki.5 for ; Wed, 08 Jan 2020 10:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=tL334DOxh3+LPvVfQ5ifFRM5F++2eB+Nci5fLD7dY1M=; b=LvmboZDlT2XeIrpbrIyMzwThcTZziYHHMU8rPUqj0kVPsMywiW0Oj988Xj70Ob7Mt0 r9jgFvNeP3IcsYwO3c+fYVUoJxhKWFqoppoeOriMH3Pec2c7fH+gm+DlceNjn6U99yVd xoT2/9RfEchTofAFy/Nz48wPU+yjBS/wweuFY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=tL334DOxh3+LPvVfQ5ifFRM5F++2eB+Nci5fLD7dY1M=; b=QFzm8OI4Mz58PNU1iw5vFlXAg3h5Ols0P9QP3A6i7TU45J+9NJihckCZufOtUM/CnU BHd8/QJxh7peTdKUIHZCBH9Z+EQbI48wCjDYwHjvDMGik7q6Y/64oxQR6vol/Kr+CFOR NHs565HtjWGjy1Wbqg2JttnB2eL7HhkQLY6ebdJ87+Zsyyv9JMvvCJDTXdI3jpFbai9j f7gAmBxDChxtVC8N1OusJAEHv2jAzKGjYraCRl/RbeMLEsS6kwSNMdIgXfBxu0MZTCy8 1jocvdYV8rcKTa+wFlfx3rBTZxzThOlRWOsXbv+EhEzyNzxekJqLFfqUJvDgJxYRrd0a ZJOA== X-Gm-Message-State: APjAAAVpvkBCMsBCD7DRyE6GNoefahlmu1iUE+b40CSWdudnyKK/2KCF W6hQ5HpFWOFxDN5+omboOS69ozmd2e4= X-Google-Smtp-Source: APXvYqydW6IKMwswj0YS+7Ddrnsk5EtGjIpkfu0qr2UF37tAgheIlumEURxmgJb77miGFCdfmLK1fg== X-Received: by 2002:ae9:c316:: with SMTP id n22mr5440710qkg.72.1578507119277; Wed, 08 Jan 2020 10:11:59 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id g62sm1703983qkd.25.2020.01.08.10.11.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 10:11:58 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 8 Jan 2020 13:11:58 -0500 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <157850673005.22571.2917503256026347682@ietfa.amsl.com> Message-Id: <68B18A62-8D37-4120-91ED-E892D54811AA@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 18:12:02 -0000 Hi! This is the initial version of the draft. Note it is identical to = draft-turner-5480-ku-clarifications except for the dates, WG is now = LAMPS and not TBD, and the dates. Since this is such a simple draft and I incorporated the only comment to = date, can I humbly request a WGLC ;) spt > On Jan 8, 2020, at 13:05, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information > Authors : Tadahiko Ito > Sean Turner > Filename : draft-ietf-lamps-5480-ku-clarifications-00.txt > Pages : 3 > Date : 2020-01-08 >=20 > Abstract: > This document updates RFC 5480 to specify semantics for the > keyEncipherment and dataEncipherment key usage bits when used in > certificates that support Elliptic Curve Cryptography. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-00 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarificati= ons-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Jan 8 11:51:13 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3412012A for ; Wed, 8 Jan 2020 11:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZjeE4wVbgeEe for ; Wed, 8 Jan 2020 11:51:10 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209F912003E for ; Wed, 8 Jan 2020 11:51:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7D9A4300567 for ; Wed, 8 Jan 2020 14:51:08 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rmAjZcC1us3N for ; Wed, 8 Jan 2020 14:51:07 -0500 (EST) Received: from [5.5.33.23] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 1DC863001CC for ; Wed, 8 Jan 2020 14:51:07 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 8 Jan 2020 14:51:07 -0500 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <157850673005.22571.2917503256026347682@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 19:51:12 -0000 This is a very short document, and it had some review prior to WG = adoption. So, now that the document has been adopted, I think it is = ready for WG Last Call. This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information" = . Please review the = document and send your comments to the list by 24 January 2020. The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications-0= 0/ Thanks, Russ & Tim= From nobody Wed Jan 8 12:00:06 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B9912080D; Wed, 8 Jan 2020 12:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fufzMmmPmvTq; Wed, 8 Jan 2020 12:00:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECD612003E; Wed, 8 Jan 2020 12:00:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4763A3897B; Wed, 8 Jan 2020 14:59:39 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 579FD71D; Wed, 8 Jan 2020 15:00:00 -0500 (EST) From: Michael Richardson To: "spasm\@ietf.org" , EMU WG In-Reply-To: <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 20:00:04 -0000 --=-=-= Content-Type: text/plain Alan DeKok wrote: alan> Many people use private CAs. Many use public CAs. *All* of them alan> use id-kp-serverAuth. Common EAP supplicants (MS / Apple / etc.) alan> ship with known root CAs. These root CAs are trusted by default alan> for web browsing. None are trusted by default for EAP. How can anyone be using public CAs for EAP, if none are trusted for EAP, and no public CAs issue certificates with id-kp-serverAuth? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4WNL8ACgkQgItw+93Q 3WWABgf+IYLGGlBWqHH8f5dBUUof0anr1C3Zkk6e6i2ravcAp21++bkJBwENMr4u FgAD8fWS6YczoAPRp/NXSzTw6MXYB9rCYorYl2ZW9lQkrVSiPDDeL0x/aeeMOduo TKORzfvnB+mGSbGAKjkImaZlX1In/gxAmFbnQ09+2ObPOZSw3A6yPQAjCLCWi0Xk srZezgxOKkHnjKQyGNM4hxexlqi/ZKovOWQ2eEgxo9MJ5EOkhYXBsO3sMiJ1GJ6T 2LpxUQelH6vXiMani9TRm4Dsv4+9fOFtZJs1kBsX0bNuLeEOZtzy5n6TccY+FJP3 CvF6twFKpVCRfBmtHf3c7iK/6G9iYQ== =ikYB -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 8 12:04:23 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF541201EA for ; Wed, 8 Jan 2020 12:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 dQ63JoFbX029 for ; Wed, 8 Jan 2020 12:04:20 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD7F12003E for ; Wed, 8 Jan 2020 12:04:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7E06FBE2E; Wed, 8 Jan 2020 20:04:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6b4cRweyiUu; Wed, 8 Jan 2020 20:04:16 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C03BABE20; Wed, 8 Jan 2020 20:04:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578513856; bh=5uFXL7YOsI+xI9UpJJjchmppkhV6JGuYxhb04SwKAOw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=zwZNEIowkJVS8HVPfwa+FR6EMHjcptQB1RKxRvd1ysUM1ARK/DsQ2EksI1VZ94iJV m/24baaNYdX9nZD2zdlK/OzSVvxUSJcsTUSOKdzHyyFks61ZF9+zKAmNqZC5BmRko7 k5Goj4eBNCWGk/T3bd/xoPc5VByFa30vaRN6HeqM= To: Russ Housley , LAMPS WG References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> Date: Wed, 8 Jan 2020 20:04:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dccvET1L5VfbGeBlsWC7KW2CHNcUQ8Ikn" Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 20:04:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dccvET1L5VfbGeBlsWC7KW2CHNcUQ8Ikn Content-Type: multipart/mixed; boundary="alN4iEUDbDHKs8Rj4zIsfZun7ia3zkw8U"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , LAMPS WG Message-ID: <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> In-Reply-To: --alN4iEUDbDHKs8Rj4zIsfZun7ia3zkw8U Content-Type: multipart/mixed; boundary="------------96E65CBDA4CEEFD6188DEAA4" Content-Language: en-US This is a multi-part message in MIME format. --------------96E65CBDA4CEEFD6188DEAA4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 08/01/2020 19:51, Russ Housley wrote: > This is a very short document, and it had some review prior to WG > adoption. So, now that the document has been adopted, I think it is > ready for WG Last Call. >=20 > This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve > Cryptogtaphy Subject Public Key Information" > . Please review the > document and send your comments to the list by 24 January 2020. I would support publication if someone tells me that they've done a survey (via e.g. zmap/zgrab or crt.sh) and found that there are zero or only a tiny percentage of issued certificates that conflict with the draft. If that happened already apologies and great! If not, shouldn't that be done before declaring success on WG last-call? >=20 > The datatracker page for the document is > https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarification= s-00/ That gets a 404, should be [1] I guess. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/= > > Thanks, Russ & Tim _______________________________________________=20 > Spasm mailing list Spasm@ietf.org=20 > https://www.ietf.org/mailman/listinfo/spasm >=20 --------------96E65CBDA4CEEFD6188DEAA4 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------96E65CBDA4CEEFD6188DEAA4-- --alN4iEUDbDHKs8Rj4zIsfZun7ia3zkw8U-- --dccvET1L5VfbGeBlsWC7KW2CHNcUQ8Ikn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4WNbsACgkQWrL68XsX K+o57w//Q7FfehFFpNiC629zdaDsJafsfR6GZ4lsYzu4u/RqaW+baNtthElHhiqn Tn+5eVLWFoBf8Mx6HyOtVVyNW6mh21WR2uWwsTZxfOP2ZmKnLwf6soxR8ZxiEGbU y7FyqHeSew2einQ/1NeP8INf1b5JHzQgjNMXX8dwIp2QqrEygcr2+LC7Nr2XWdEk VY56c2HMwhuCyhzfkWnHZo5DMr4OyJyYz/AxiWuUr6cF/rVYsvLT8annmVlSFwro 7PMzl8YW1b4jsDBIJsOzPP1Ab4mUK7m419dc7wYBe3AlHWbwKlZLzSZ0HwJ9TVKQ fUVGAliaGwsQLC2R3wsZjW3WeawzQD2AViJCeN3V/XxECZhja7ov5q+iZR9F3tsH MltEYGhjchnLF6XEGzZKpawXqtPR9Kfi/0GUTp0iQimnYcfldRgBPEyjOQePCQAh IVyI7I1rAoHpuasAuAv+3Bjx/23L2IIUr0BnXVpFv9UXHfS2gMz1gUClXJaLzHST CXEQdciQ1288AAnN4RM8qTf6/NgZcuWyIl/x2T44a7q8TqoqSlTxlbiQXcyExPfI kdNGSj/V1+BKO7EfydX/ZP3MKF4XaRQM0r58rqI+KVLEuSxOhmy1t4QUJTTJ+UaV zuGzwik9VPb2qHTKiowKlvDGZME02gZqelhiHnwe5gBCWZxY65g= =KKMT -----END PGP SIGNATURE----- --dccvET1L5VfbGeBlsWC7KW2CHNcUQ8Ikn-- From nobody Wed Jan 8 12:07:56 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E5E12021C for ; Wed, 8 Jan 2020 12:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 GdQyJRtfERKI for ; Wed, 8 Jan 2020 12:07:54 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E7B12020A for ; Wed, 8 Jan 2020 12:07:54 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 008JtFFx011916; Wed, 8 Jan 2020 20:07:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=6VvDWL4dpuGTZxNjxky42y8Nz8Tvr3SF3K8e+5ujUdE=; b=Dd3chqWfrtyac3P+TgtHxaARiOOct+0vE/Vd9MvS7T0OFDWrFiVqKLLlioYsM7go1tu6 vJQp89zfsRsFafVpWg1ttgJpZQtu+KbKK+VLSQ2FN7rjgQZ7krb8xB3rHwX4hozDTnf7 Py6h/rTQAzN4vg7WDfDdIAJ9OULTfCXvHH0FzLhfxPfTXahvioYG9FStidWQRnA7VsCF Al4Sbb+MMwaU0xAvomPK5J++ty/0yxzQiPRuYft9rwGYuIFQHh3XpF+XucRoVI2S7y1c q0H40XFMdwcVRFXsIpmt6RXiKDufbemEoxAH6P4ED1pARdQV1+N54ysjgS9eINH3MllA AQ== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2xd9fn30x2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Jan 2020 20:07:53 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 008K2mF5025560; Wed, 8 Jan 2020 15:07:52 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint7.akamai.com with ESMTP id 2xapx3s37e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 08 Jan 2020 15:07:48 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 15:07:35 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 8 Jan 2020 15:07:35 -0500 From: "Salz, Rich" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 Thread-Index: AQHVxl0AxgMW3OjLKk+J6wS9x7BWcqfhMc6A Date: Wed, 8 Jan 2020 20:07:35 +0000 Message-ID: <429AF257-5B4E-4CFD-9EC2-4AAFB38BD258@akamai.com> References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200104 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.48] Content-Type: text/plain; charset="utf-8" Content-ID: <77CAADFD678BD54C9BFE196398B79618@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-08_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=721 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001080157 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-08_06:2020-01-08, 2020-01-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 mlxlogscore=693 spamscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001080157 Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 20:07:55 -0000 PiAgICBUaGlzIGlzIHRoZSBMQU1QUyBXRyBMYXN0IENhbGwgZm9yICJDbGFyaWZpY2F0aW9ucyBm b3IgRWxsaXB0aWMgQ3VydmUgQ3J5cHRvZ3RhcGh5IFN1YmplY3QgUHVibGljIEtleSBJbmZvcm1h dGlvbiIgPGRyYWZ0LWlldGYtbGFtcHMtNTQ4MC1rdS1jbGFyaWZpY2F0aW9ucy0wMD4uICBQbGVh c2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0 IGJ5IDI0IEphbnVhcnkgMjAyMC4NCiANCkp1c3QgcmUtcmVhZCBpdC4gIFNoaXAgaXQgOikNCg0K From nobody Wed Jan 8 12:38:16 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9889612080D for ; Wed, 8 Jan 2020 12:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 o-56jdqrvHH0 for ; Wed, 8 Jan 2020 12:38:12 -0800 (PST) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E9112020A for ; Wed, 8 Jan 2020 12:38:12 -0800 (PST) Received: by mail-ed1-f48.google.com with SMTP id f8so3754880edv.2 for ; Wed, 08 Jan 2020 12:38:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AWDZ1iL86/R3/6VGgPHaNc778yrvMxKBbL82qLetDu4=; b=JJGplKIQBPE+ey4WXkkrv4WHWxF69TmuQupKPinTCQelZFZLsHm1xxaaXbxXsyZJ3y WbKQA92Nkx3MhIJ1pGeCdA4e2B5ZqG8scVMKWyZMLQd8UvaFpct53oCsOmvRWog2WGHk lvDpVvBiXmt61ATm2/PMIt22eDBFTJiqzdIciZHwUjPQILTFV9hQ1hAR4EL6nGmNXtZb 76DsBWP4QSdQuTfCSegb3L6rh0Md4F/AdrZRO1fIV2XaPjXeUlOx09UQfAV5RwPBxHrj mSNgPYPuRJ371a4HvCtuvtdLiwX0NsDLbli1Q54V/91m2t16j9rNNeGth6IhUBrbGjA4 pQlQ== X-Gm-Message-State: APjAAAUPgqtEHIDDqQRKgVJuqP3bxY2lp0WWKdDAHDCm2WXmBgCYUoTx n9XERf//PZ7tEA6O0HBBC43Mv+3Z X-Google-Smtp-Source: APXvYqzZUR5uelY0y5Hxv1c0QdlJMOGCbjktJ+Ax3vgdXvCN9Cv6JspNubmNdJU7R82vwF1ACsxpcA== X-Received: by 2002:a17:906:d7a6:: with SMTP id pk6mr6665589ejb.234.1578515890812; Wed, 08 Jan 2020 12:38:10 -0800 (PST) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com. [209.85.128.50]) by smtp.gmail.com with ESMTPSA id dd17sm111391edb.9.2020.01.08.12.38.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2020 12:38:10 -0800 (PST) Received: by mail-wm1-f50.google.com with SMTP id u2so332296wmc.3 for ; Wed, 08 Jan 2020 12:38:10 -0800 (PST) X-Received: by 2002:a1c:407:: with SMTP id 7mr487569wme.29.1578515890288; Wed, 08 Jan 2020 12:38:10 -0800 (PST) MIME-Version: 1.0 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> In-Reply-To: <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> From: Ryan Sleevi Date: Wed, 8 Jan 2020 15:37:59 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Farrell Cc: Russ Housley , LAMPS WG Content-Type: multipart/alternative; boundary="000000000000e9bfb9059ba6ded8" Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 20:38:15 -0000 --000000000000e9bfb9059ba6ded8 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 8, 2020 at 3:04 PM Stephen Farrell wrote: > > Hiya, > > On 08/01/2020 19:51, Russ Housley wrote: > > This is a very short document, and it had some review prior to WG > > adoption. So, now that the document has been adopted, I think it is > > ready for WG Last Call. > > > > This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve > > Cryptogtaphy Subject Public Key Information" > > . Please review the > > document and send your comments to the list by 24 January 2020. > I re-read it and support it. I would support publication if someone tells me that > they've done a survey (via e.g. zmap/zgrab or crt.sh) > and found that there are zero or only a tiny percentage > of issued certificates that conflict with the draft. > > If that happened already apologies and great! > > If not, shouldn't that be done before declaring success > on WG last-call? > Could you explain the objective? =) That is, part of the reason for this is to clarify whether or not it's expected or not. The suggestion was rather than the CABF profile to explicitly say it's not expected/allowed, to address this and clarify in the IETF whether the omission of elements from the extant MAY implies a MUST NOT. This is part of a broader effort in the CA/Browser Forum of clarifying that if things are not explicitly allowed, they should be interpreted as forbidden. In the context of ECDSA, is there a situation where those keyUsages makes sense and aligns with those key algorithms? Arguably, no, hence the draft to make it clear ;) That said, you can run a Censys query with the following: parsed.subject_key_info.key_algorithm.name: "ECDSA" and (parsed.extensions.key_usage.data_encipherment: true or parsed.extensions.key_usage.key_encipherment: true) https://censys.io/certificates?q=parsed.subject_key_info.key_algorithm.name%3A+%22ECDSA%22+and+%28parsed.extensions.key_usage.data_encipherment%3A+true+or+parsed.extensions.key_usage.key_encipherment%3A+true%29 For what it's worth, a number of PKI libraries will reject these certificates as invalid, which will not even allow the user to bypass the error, as they've interpreted the extant language as being what this draft codifies. The quick summary of those results, run just now: 46.36K Never Trusted 39.72K Expired 38.95K Unexpired 31.48K Self-Signed 1,628 CT 1,628 Google CT 1,217 CT PreCert 840 Leaf 828 EV 774 Previously Trusted 416 DV 299 OV 66 Currently Trusted 17.76K Freebox SA 14.03K Philips Hue 9,942 Caddy Self-Signed 5,927 CloudFlare, Inc. 2,261 Docker 1,551 Mesosphere, Inc. 968 Mesosphere Inc. 927 McAfee, Inc. 920 NoEnv 808 Jungheinrich AG 640 Gemalto 488 Bird Home Automation 477 GlobalSign nv-sa 449 Developer Certificate 406 A1A Car Wash 399 StartCom Ltd. 377 Entrust, Inc. 342 VirtuallyLive 274 SpectraLogic 248 DNSFilter --000000000000e9bfb9059ba6ded8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 8, 2020 at 3:04 PM Stephe= n Farrell <stephen.farrell@= cs.tcd.ie> wrote:

Hiya,

On 08/01/2020 19:51, Russ Housley wrote:
> This is a very short document, and it had some review prior to WG
> adoption.=C2=A0 So, now that the document has been adopted, I think it= is
> ready for WG Last Call.
>
> This is the LAMPS WG Last Call for "Clarifications for Elliptic C= urve
> Cryptogtaphy Subject Public Key Information"
> <draft-ietf-lamps-5480-ku-clarifications-00>.=C2=A0 Please revie= w the
> document and send your comments to the list by 24 January 2020.

I re-read it and support it.

I would support publication if someone tells me that
they've done a survey (via e.g. zmap/zgrab or crt.sh)
and found that there are zero or only a tiny percentage
of issued certificates that conflict with the draft.

If that happened already apologies and great!

If not, shouldn't that be done before declaring success
on WG last-call?

Could you explain the = objective? =3D)

That is, part of the reason for th= is is to clarify whether or not it's expected or not. The suggestion wa= s rather than the CABF profile to explicitly say it's not expected/allo= wed, to address this and clarify in the IETF whether the omission of elemen= ts from the extant MAY implies a MUST NOT.

This is= part of a broader effort in the CA/Browser Forum of clarifying that if thi= ngs are not explicitly allowed, they should be interpreted as forbidden. In= the context of ECDSA, is there a situation where those keyUsages makes sen= se and aligns with those key algorithms? Arguably, no, hence the draft to m= ake it clear ;)

That said, you can run a Censys qu= ery with the following:
parsed.subject_key_info.key_algorithm.name: "= ECDSA" and (parsed.extensions.key_usage.data_encipherment: true or par= sed.extensions.key_usage.key_encipherment: true)

For what it's worth, a number of PKI libraries will reject the= se certificates as invalid, which will not even allow the user to bypass th= e error, as they've interpreted the extant language as being what this = draft codifies.

The quick summary of those results= , run just now:
46.36K Never Trusted
39.72K Expired
38.95= K Unexpired
31.48K Self-Signed
1,628 CT
1,628 Google CT
1,2= 17 CT PreCert
840 Leaf
828 EV
774 Previously Trusted
416 D= V
299 OV
66 Currently Trusted

17.76K Freeb= ox SA
14.03K Philips Hue
9,942 Caddy Self-Signed
5,927 CloudFlare,= Inc.
2,261 Docker
1,551 Mesosphere, Inc.
968 Mesosphere Inc.
9= 27 McAfee, Inc.
920 NoEnv
808 Jungheinrich AG
640 Gemalto
488 B= ird Home Automation
477 GlobalSign nv-sa
449 Developer Certificate406 A1A Car Wash
399 StartCom Ltd.
377 Entrust, Inc.
342 Virtuall= yLive
274 SpectraLogic
248 DNSFilter
--000000000000e9bfb9059ba6ded8-- From nobody Wed Jan 8 12:48:05 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6890C12088C; Wed, 8 Jan 2020 12:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 083Xw-yeBls6; Wed, 8 Jan 2020 12:47:45 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED07120889; Wed, 8 Jan 2020 12:47:45 -0800 (PST) Received: from [192.168.20.209] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id CCB598D5; Wed, 8 Jan 2020 20:47:43 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: <6191.1578513600@localhost> Date: Wed, 8 Jan 2020 15:47:42 -0500 Cc: "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 20:47:58 -0000 On Jan 8, 2020, at 3:00 PM, Michael Richardson = wrote: >=20 >=20 > Alan DeKok wrote: > alan> Many people use private CAs. Many use public CAs. *All* of = them > alan> use id-kp-serverAuth. Common EAP supplicants (MS / Apple / = etc.) > alan> ship with known root CAs. These root CAs are trusted by = default > alan> for web browsing. None are trusted by default for EAP. >=20 > How can anyone be using public CAs for EAP, if none are trusted for = EAP, and no > public CAs issue certificates with id-kp-serverAuth? Every CA is manually enabled. Either by an end user, or by / on behalf of, an administrator. The goal I'd like to reach is some method to allow supplicants to = automatically trust and enable certificates for EAP. Alan DeKok. From nobody Fri Jan 10 11:20:25 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C491200B5 for ; Fri, 10 Jan 2020 11:20:23 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 zaYDxX3fzDfw for ; Fri, 10 Jan 2020 11:20:19 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690C912001E for ; Fri, 10 Jan 2020 11:20:19 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id v28so2580352edw.12 for ; Fri, 10 Jan 2020 11:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=39Ne0kqXIyTebkNDbxZeRPDXZlF/XDUa1tBQyZ2fzK4=; b=PzeMsnYU7KVSMb7eT+mrlbIk17z2AcNCc/fQ+Izzb0yNQkQQVlnuG+5PsugpLP80h1 NNGw9Q1yEh/VLnIWHjQadVAz0BVFaE0E7BpUsSUtwiHFlyNdmOuzlQuEW9KQrV607Dbz 3oEfPpsO7eijCZckso9muJRfUffPIqCEfvlB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=39Ne0kqXIyTebkNDbxZeRPDXZlF/XDUa1tBQyZ2fzK4=; b=HdD9fXblCbnlSOFYifRS38BSs1uL6C2E0t0D/x0gmziiwg4+yvLvwpuD2vQZRuUnkh /VISjT3Ie7TWWP92HMiPxX9P+zGz7oSHbG8ehX4C/I9qiBMzJn6+6rw2I48bPsCBQL8h 40ksxxpsYIT+iWopSB6EjVecH2+km/XnkpMld8pK5mMkQK4Dk0qE2OX/vMUAZV/P2eDG AHNmQC8PyQ/kR5DQYLz1fogHL7PJvuDUyRu4Aoe9jzstHm3XriNrLwsAiX9AEEoyWlsu fLz12IpRtOgjW9Z66bUyR8pU7UhGDcLgRdPTyW1ps+E+eW9ive2usEKpaJAHI6V/nJD8 NKXg== X-Gm-Message-State: APjAAAX5Oj92DXLipH6VZJd6oDBpmx98dOAFghtDhJDcugjqDgSdvrIZ hXq46Vpw5BGh4GH3dORm5UvL95LZpn4fAKVZn+zTOA== X-Google-Smtp-Source: APXvYqxeasr9/iwim8/T/ael4+9B4aR6Yl3Rn3sPjFRIg7Aw7VqGMfR4tWPQnHszjcgXrrwQTjrk0LMIdkYRHrPRN0I= X-Received: by 2002:a17:906:9603:: with SMTP id s3mr4726680ejx.116.1578684016991; Fri, 10 Jan 2020 11:20:16 -0800 (PST) MIME-Version: 1.0 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> In-Reply-To: Reply-To: cpu@letsencrypt.org From: Daniel McCarney Date: Fri, 10 Jan 2020 14:20:06 -0500 Message-ID: To: Ryan Sleevi Cc: Stephen Farrell , LAMPS WG , Russ Housley Content-Type: multipart/alternative; boundary="0000000000000bb927059bce040e" Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 19:20:23 -0000 --0000000000000bb927059bce040e Content-Type: text/plain; charset="UTF-8" Hi folks, I was curious about the high number of ECDSA certs with bad KU associated with the Caddy project in Ryan's Censys summary. I opened an issue with the project[0] and the primary author pointed out that he took the code at fault from the Go standard library's `generate_cert.go` utility. I've opened an issue[1] with the Go folks to get that fixed but in the process noticed that the tool sets the KeyUsage field incorrectly for both ECDSA and ED25519 subject public keys. This led me to notice that RFC 8410's section on "Key Usage bits"[2] is missing the "keyEncipherment and dataEncipherment usages MUST NOT be present" language that draft-ietf-lamps-5480-ku-clarifications-00 is adding to RFC 5480. Would the WG be interested in updating RFC 8410 with similar clarification? I believe the keyEncipherment and dataEncipherment key usages are equally inappropriate for these algorithms as for ECDSA but I'm open to schooling if I've made a mistake in my analysis. Thanks, [0]: https://github.com/caddyserver/caddy/issues/2969 [1]: https://github.com/golang/go/issues/36499 [2]: https://tools.ietf.org/html/rfc8410#section-5 On Wed, Jan 8, 2020 at 3:38 PM Ryan Sleevi wrote: > > > On Wed, Jan 8, 2020 at 3:04 PM Stephen Farrell > wrote: > >> >> Hiya, >> >> On 08/01/2020 19:51, Russ Housley wrote: >> > This is a very short document, and it had some review prior to WG >> > adoption. So, now that the document has been adopted, I think it is >> > ready for WG Last Call. >> > >> > This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve >> > Cryptogtaphy Subject Public Key Information" >> > . Please review the >> > document and send your comments to the list by 24 January 2020. >> > > I re-read it and support it. > > I would support publication if someone tells me that >> they've done a survey (via e.g. zmap/zgrab or crt.sh) >> and found that there are zero or only a tiny percentage >> of issued certificates that conflict with the draft. >> >> If that happened already apologies and great! >> >> If not, shouldn't that be done before declaring success >> on WG last-call? >> > > Could you explain the objective? =) > > That is, part of the reason for this is to clarify whether or not it's > expected or not. The suggestion was rather than the CABF profile to > explicitly say it's not expected/allowed, to address this and clarify in > the IETF whether the omission of elements from the extant MAY implies a > MUST NOT. > > This is part of a broader effort in the CA/Browser Forum of clarifying > that if things are not explicitly allowed, they should be interpreted as > forbidden. In the context of ECDSA, is there a situation where those > keyUsages makes sense and aligns with those key algorithms? Arguably, no, > hence the draft to make it clear ;) > > That said, you can run a Censys query with the following: > parsed.subject_key_info.key_algorithm.name > : "ECDSA" and > (parsed.extensions.key_usage.data_encipherment: true or > parsed.extensions.key_usage.key_encipherment: true) > > https://censys.io/certificates?q=parsed.subject_key_info.key_algorithm.name%3A+%22ECDSA%22+and+%28parsed.extensions.key_usage.data_encipherment%3A+true+or+parsed.extensions.key_usage.key_encipherment%3A+true%29 > > For what it's worth, a number of PKI libraries will reject these > certificates as invalid, which will not even allow the user to bypass the > error, as they've interpreted the extant language as being what this draft > codifies. > > The quick summary of those results, run just now: > 46.36K Never Trusted > 39.72K Expired > 38.95K Unexpired > 31.48K Self-Signed > 1,628 CT > 1,628 Google CT > 1,217 CT PreCert > 840 Leaf > 828 EV > 774 Previously Trusted > 416 DV > 299 OV > 66 Currently Trusted > > 17.76K Freebox SA > 14.03K Philips Hue > 9,942 Caddy Self-Signed > 5,927 CloudFlare, Inc. > 2,261 Docker > 1,551 Mesosphere, Inc. > 968 Mesosphere Inc. > 927 McAfee, Inc. > 920 NoEnv > 808 Jungheinrich AG > 640 Gemalto > 488 Bird Home Automation > 477 GlobalSign nv-sa > 449 Developer Certificate > 406 A1A Car Wash > 399 StartCom Ltd. > 377 Entrust, Inc. > 342 VirtuallyLive > 274 SpectraLogic > 248 DNSFilter > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000000bb927059bce040e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I was curious about the high number of EC= DSA certs with bad KU associated with the Caddy project in Ryan's Censy= s summary. I opened an issue with the project[0] and the primary author poi= nted out that he took the code at fault from the Go standard library's = `generate_cert.go` utility.=C2=A0I've opened an issue[1] with the Go fo= lks to get that fixed but in the process noticed that the tool sets the Key= Usage field incorrectly for both ECDSA and ED25519 subject public keys.
=
This led me to notice that RFC 8410's section on "Key Usage bi= ts"[2] is missing the "keyEncipherment and dataEncipherment usage= s MUST NOT be present" language that=C2=A0draft-ietf-lamps-5480-ku-cla= rifications-00 is adding to RFC 5480.

Would the WG be interested in = updating RFC 8410 with similar clarification? I believe the keyEncipherment= and dataEncipherment key usages are equally inappropriate for these algori= thms as for ECDSA but I'm open to schooling if I've made a mistake = in my analysis.

Thanks,

[0]:=C2=A0https://github.com/caddyserver/caddy/issu= es/2969
[1]:=C2=A0https://github.com/golang/go/issues/36499
[2]:=C2=A0https://tools.ietf.org/html/r= fc8410#section-5

On Wed, Jan 8, 2020 at 3:38 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:


On Wed, Jan 8, 2020 at 3:04 PM Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:

Hiya,

On 08/01/2020 19:51, Russ Housley wrote:
> This is a very short document, and it had some review prior to WG
> adoption.=C2=A0 So, now that the document has been adopted, I think it= is
> ready for WG Last Call.
>
> This is the LAMPS WG Last Call for "Clarifications for Elliptic C= urve
> Cryptogtaphy Subject Public Key Information"
> <draft-ietf-lamps-5480-ku-clarifications-00>.=C2=A0 Please revie= w the
> document and send your comments to the list by 24 January 2020.

I re-read it and support it.

I would support publication if someone tells me that
they've done a survey (via e.g. zmap/zgrab or crt.sh)
and found that there are zero or only a tiny percentage
of issued certificates that conflict with the draft.

If that happened already apologies and great!

If not, shouldn't that be done before declaring success
on WG last-call?

Could you explain the = objective? =3D)

That is, part of the reason for th= is is to clarify whether or not it's expected or not. The suggestion wa= s rather than the CABF profile to explicitly say it's not expected/allo= wed, to address this and clarify in the IETF whether the omission of elemen= ts from the extant MAY implies a MUST NOT.

This is= part of a broader effort in the CA/Browser Forum of clarifying that if thi= ngs are not explicitly allowed, they should be interpreted as forbidden. In= the context of ECDSA, is there a situation where those keyUsages makes sen= se and aligns with those key algorithms? Arguably, no, hence the draft to m= ake it clear ;)

That said, you can run a Censys qu= ery with the following:
parsed.subject_key_info.key_algorit= hm.name: "ECDSA" and (parsed.extensions.key_usage.data_enciph= erment: true or parsed.extensions.key_usage.key_encipherment: true)

For what it's worth, a nu= mber of PKI libraries will reject these certificates as invalid, which will= not even allow the user to bypass the error, as they've interpreted th= e extant language as being what this draft codifies.

The quick summary of those results, run just now:
46.36K Neve= r Trusted
39.72K Expired
38.95K Unexpired
31.48K Self-Signed1,628 CT
1,628 Google CT
1,217 CT PreCert
840 Leaf
828 EV=
774 Previously Trusted
416 DV
299 OV
66 Currently Trusted<= /div>

17.76K Freebox SA
14.03K Philips Hue
9,942 C= addy Self-Signed
5,927 CloudFlare, Inc.
2,261 Docker
1,551 Mesosph= ere, Inc.
968 Mesosphere Inc.
927 McAfee, Inc.
920 NoEnv
808 Ju= ngheinrich AG
640 Gemalto
488 Bird Home Automation
477 GlobalSign = nv-sa
449 Developer Certificate
406 A1A Car Wash
399 StartCom Ltd.=
377 Entrust, Inc.
342 VirtuallyLive
274 SpectraLogic
248 DNSFi= lter
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000000bb927059bce040e-- From nobody Fri Jan 10 13:12:53 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E212F1200CC for ; Fri, 10 Jan 2020 13:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 W2cyluHVQq4y for ; Fri, 10 Jan 2020 13:12:49 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB8412008C for ; Fri, 10 Jan 2020 13:12:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 679E1BE50; Fri, 10 Jan 2020 21:12:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McX16zNwOw6N; Fri, 10 Jan 2020 21:12:42 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A198BE47; Fri, 10 Jan 2020 21:12:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578690762; bh=p2g+JQ9omXDEtBeU/Fj6fgoGxH2EcSWNF8Lz8/ljBsY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=3QZ2yKG3QCHomTTf85ZEHmsDSIPcbT0J9a8ze8HxKcRAIimJJtr3YUILpl3m85a5a Vgj8xPJsgNN+9qqQ+CxhGcm4Q+OuPY/oqhLzpVT+JMtDAvq5zgnb3nK2oKdcP8B2gM DjvV0YF/O4A0jq/lo76uHSgA2IN5bN0PYhvZutAo= To: Ryan Sleevi Cc: LAMPS WG , Russ Housley References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <3f92d910-65fd-9d5a-3f96-89ca8399e9c5@cs.tcd.ie> Date: Fri, 10 Jan 2020 21:12:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZPW8X8OrHCqtqLteQk85Wn12lz9BTXpCP" Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 21:12:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZPW8X8OrHCqtqLteQk85Wn12lz9BTXpCP Content-Type: multipart/mixed; boundary="bZklvMW7fd3nEfhxMehzMaHGERgz8XPMi"; protected-headers="v1" From: Stephen Farrell To: Ryan Sleevi Cc: LAMPS WG , Russ Housley Message-ID: <3f92d910-65fd-9d5a-3f96-89ca8399e9c5@cs.tcd.ie> Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> In-Reply-To: --bZklvMW7fd3nEfhxMehzMaHGERgz8XPMi Content-Type: multipart/mixed; boundary="------------CA39CDFDD866D028FD1D8928" Content-Language: en-US This is a multi-part message in MIME format. --------------CA39CDFDD866D028FD1D8928 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Thanks for the censys link, was hoping someone else'd do the work to generate something like that:-) On 08/01/2020 20:37, Ryan Sleevi wrote: > Could you explain the objective? =3D) So those numbers, when compared to the overall number of ecdsa certs [1] seem to imply that some issuers get (or used get) this wrong for all or almost all their certs, (as Daniel's mail about caddy indicated) albeit the numbers for such issuers are quite small compared to the bigger issuers. "Freebox SA" for example issued 17.87K ecdsa certs according to [1] and 17.76K broken according to the numbers you posted. For me, that means that if we proceed with this then we're kinda breaking some smaller folks stuff in a sense. (Yeah, they broke it first, but still;-) I'd say attempting to let 'em know would be a fine thing, while also processing this draft. Again though, I'm not objecting to processing the draft, but if we're doing it so quickly and it may be perceived as causing breakage, (even if it's drawing attention to, rather than causing, breakage) then raising issues etc. (as Daniel did) seems like a better way to do this than just firing ahead at full-speed. Cheers, S. [1] https://censys.io/certificates?q=3Dparsed.subject_key_info.key_algorithm.= name%3A+%22ECDSA%22 --------------CA39CDFDD866D028FD1D8928 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------CA39CDFDD866D028FD1D8928-- --bZklvMW7fd3nEfhxMehzMaHGERgz8XPMi-- --ZPW8X8OrHCqtqLteQk85Wn12lz9BTXpCP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4Y6McACgkQWrL68XsX K+qbXg/+Kk4uPLxU1XEXgCn/FOJZQehcMFd9ngZdbziSOenUUSC9hLP9VJBqaa28 Dg64Kv41kBRe82w0Ir4CLJECmTPZVqEYWm2JZbVn6jUpo5ngDVZzbBDjh8qgggw6 BwAADoxXyshQ5B4egDrlFP+krT2XLlvwHhynoI2yWAcOp7nXcbjCR6RHuEErMSnM sZNvtwjdtU3vImpAJtglV/fn5aLZmM1vpWDfNG+B4BRdvB43wHxKXq+6qRzhAysG 0DbAd9PcZX0j+Kh7fa3d+Tp/o0Iz9x0CVa+lctutR98qD6cKYoecu5sqeZtFngcR l/FIknmuVeM5basOlnIblUvkJ68dRkV89G48vTBrxmuxF439JLPUpqBiK/YFcX/0 ogZHlw6lfWH13UQ7yO/MBafTaNKQ+UZG5iy3Hw/bx7Mb8kUsFxn6MNJlh8pZOkKe z8HYlHE/Iav3kqVNmQUA9+1+wcTacA+tNArNmqbX3e//NhgDjjQ0Xoa/hWoyXOQX napIu3PgUWYQ0w4iaintKwsKdXsTjfaXZ8prHU/3jI2AmKBBUKkj8zrwdaj3y7gf 3BlS1VE5spBYdKR4FvujTMV21DBPCgGfFrDRZYbIfQlt8qsL2wrk+1zZlwzrIXDQ QS1ZOl/hVEEuPp8+IDzVX2coIvVTFYS5OyXXPNylrecxT0PPhAA= =IZis -----END PGP SIGNATURE----- --ZPW8X8OrHCqtqLteQk85Wn12lz9BTXpCP-- From nobody Fri Jan 10 16:37:33 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A22120120 for ; Fri, 10 Jan 2020 16:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 4BKvGiUFjYEW for ; Fri, 10 Jan 2020 16:37:29 -0800 (PST) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE50E120047 for ; Fri, 10 Jan 2020 16:37:28 -0800 (PST) Received: by mail-qk1-x741.google.com with SMTP id 21so3722841qky.4 for ; Fri, 10 Jan 2020 16:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5aWyBKL29XfYX6GIKooX/Bmm0kNdXX4C6yT9sxa9SUo=; b=NswrYfHzgDm+IEJ1vGokAi02EFXlmaOtCiNpkg1Y2X7L+0dMZqq8B+RHXulTGGL1wu 6alB607Kw5t+wd/0UqgU2fr0MLH8YJatUl554NqXeXtawIy6s087/tyDER5ltvRkxMBl RcsOjW9LAlTkQ2F9FltmmUdhXoOI6XonTDWlQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5aWyBKL29XfYX6GIKooX/Bmm0kNdXX4C6yT9sxa9SUo=; b=sVt89K91w9WWpyVxllYhJE8mW9CLZjVu6qRHSXrfoQUi5ySdZB5mTuCg93QupIuGCh pdPdGBnM1KM5agj+HGi4QzmvbzUhS86z/KyJdfmGwCqsDA49w2KN8AIB4QtTjYPZjdna GVRT62pxS2TEO7viHcWoLi0cnhxDRaoAyNUK5T5adGX4yGTjD0alMp+91tSWW2fcE/x7 KdjsLY3Y/QHqkn2cB0oBHBEmp3wYufwACjDC2UY3B9MKOCyNmVajVgioB5RIOAOp6tYg bTO4lBmHvow2YDOWVz3vfOPsJBLBf0Be5S1dixDjrEQZ+g0NkIeahQ145NjAbBUyuKdo 5OTw== X-Gm-Message-State: APjAAAVDq8VwRXkAM5MzB1dlwJ+wZ8NlgNuSFBAMG561Q/A0N6n+BlxY oaOE3/bHlfvtWi6CGQaQFiLeuA== X-Google-Smtp-Source: APXvYqyJmT6JfOGGgeZ/hlnHJybK+hOXcEkSqHH6/SKzrbdkmBq4DewmYd8NhcmMci2HIf2KHo+PFg== X-Received: by 2002:a37:52d5:: with SMTP id g204mr6111667qkb.215.1578703047955; Fri, 10 Jan 2020 16:37:27 -0800 (PST) Received: from [5.5.33.40] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id a24sm1630823qkl.82.2020.01.10.16.37.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2020 16:37:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Fri, 10 Jan 2020 17:49:00 -0500 Cc: Ryan Sleevi , LAMPS WG , Russ Housley , Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: <2758763B-38BC-4CEE-B501-CC87DF46DB33@sn3rd.com> References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> To: cpu@letsencrypt.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 00:37:32 -0000 I wouldn=E2=80=99t mind taking that on, but I=E2=80=99d really rather do = it in another draft. spt > On Jan 10, 2020, at 14:20, Daniel McCarney = wrote: >=20 > Hi folks, >=20 > I was curious about the high number of ECDSA certs with bad KU = associated with the Caddy project in Ryan's Censys summary. I opened an = issue with the project[0] and the primary author pointed out that he = took the code at fault from the Go standard library's `generate_cert.go` = utility. I've opened an issue[1] with the Go folks to get that fixed but = in the process noticed that the tool sets the KeyUsage field incorrectly = for both ECDSA and ED25519 subject public keys. >=20 > This led me to notice that RFC 8410's section on "Key Usage bits"[2] = is missing the "keyEncipherment and dataEncipherment usages MUST NOT be = present" language that draft-ietf-lamps-5480-ku-clarifications-00 is = adding to RFC 5480. >=20 > Would the WG be interested in updating RFC 8410 with similar = clarification? I believe the keyEncipherment and dataEncipherment key = usages are equally inappropriate for these algorithms as for ECDSA but = I'm open to schooling if I've made a mistake in my analysis. >=20 > Thanks, >=20 > [0]: https://github.com/caddyserver/caddy/issues/2969 > [1]: https://github.com/golang/go/issues/36499 > [2]: https://tools.ietf.org/html/rfc8410#section-5 >=20 > On Wed, Jan 8, 2020 at 3:38 PM Ryan Sleevi = wrote: >=20 >=20 > On Wed, Jan 8, 2020 at 3:04 PM Stephen Farrell = wrote: >=20 > Hiya, >=20 > On 08/01/2020 19:51, Russ Housley wrote: > > This is a very short document, and it had some review prior to WG > > adoption. So, now that the document has been adopted, I think it is > > ready for WG Last Call. > >=20 > > This is the LAMPS WG Last Call for "Clarifications for Elliptic = Curve > > Cryptogtaphy Subject Public Key Information" > > . Please review the > > document and send your comments to the list by 24 January 2020. >=20 > I re-read it and support it. >=20 > I would support publication if someone tells me that > they've done a survey (via e.g. zmap/zgrab or crt.sh) > and found that there are zero or only a tiny percentage > of issued certificates that conflict with the draft. >=20 > If that happened already apologies and great! >=20 > If not, shouldn't that be done before declaring success > on WG last-call? >=20 > Could you explain the objective? =3D) >=20 > That is, part of the reason for this is to clarify whether or not it's = expected or not. The suggestion was rather than the CABF profile to = explicitly say it's not expected/allowed, to address this and clarify in = the IETF whether the omission of elements from the extant MAY implies a = MUST NOT. >=20 > This is part of a broader effort in the CA/Browser Forum of clarifying = that if things are not explicitly allowed, they should be interpreted as = forbidden. In the context of ECDSA, is there a situation where those = keyUsages makes sense and aligns with those key algorithms? Arguably, = no, hence the draft to make it clear ;) >=20 > That said, you can run a Censys query with the following: > parsed.subject_key_info.key_algorithm.name: "ECDSA" and = (parsed.extensions.key_usage.data_encipherment: true or = parsed.extensions.key_usage.key_encipherment: true) > = https://censys.io/certificates?q=3Dparsed.subject_key_info.key_algorithm.n= ame%3A+%22ECDSA%22+and+%28parsed.extensions.key_usage.data_encipherment%3A= +true+or+parsed.extensions.key_usage.key_encipherment%3A+true%29 >=20 > For what it's worth, a number of PKI libraries will reject these = certificates as invalid, which will not even allow the user to bypass = the error, as they've interpreted the extant language as being what this = draft codifies. >=20 > The quick summary of those results, run just now: > 46.36K Never Trusted > 39.72K Expired > 38.95K Unexpired > 31.48K Self-Signed > 1,628 CT > 1,628 Google CT > 1,217 CT PreCert > 840 Leaf > 828 EV > 774 Previously Trusted > 416 DV > 299 OV > 66 Currently Trusted >=20 > 17.76K Freebox SA > 14.03K Philips Hue > 9,942 Caddy Self-Signed > 5,927 CloudFlare, Inc. > 2,261 Docker > 1,551 Mesosphere, Inc. > 968 Mesosphere Inc. > 927 McAfee, Inc. > 920 NoEnv > 808 Jungheinrich AG > 640 Gemalto > 488 Bird Home Automation > 477 GlobalSign nv-sa > 449 Developer Certificate > 406 A1A Car Wash > 399 StartCom Ltd. > 377 Entrust, Inc. > 342 VirtuallyLive > 274 SpectraLogic > 248 DNSFilter > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jan 10 18:50:02 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA8112002E for ; Fri, 10 Jan 2020 18:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dzsQnKErmlBH for ; Fri, 10 Jan 2020 18:49:59 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC56E120018 for ; Fri, 10 Jan 2020 18:49:59 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id n21so4146043ioo.10 for ; Fri, 10 Jan 2020 18:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=7CT+zHDOVa+uuKtChoAbE4cdGdcLwwRxUdQL5XCt97A=; b=A0naxG2B/m77MbeVnR4RDKiv70Xn90hl3eHuNgSKYMVKlvZdO30gs1eWySbMIOOX9G ysC/0VpHdHBZvFnLiaV5SYEQk4JYb4+aZQq8u5827tixhP4qqv+2wQkI44AHdGHrwW+Q FTD8BAdb0TJ9o7ZMlXTWiI++ogYY+OynzC/bkcTnwq5Iol/lCkM/C0JwJAoAiyYBsaqR +gM2daj15hLbWtR9vH4v6+NS1Eue+fCpDruW2UbRlBzEPxjhsgTUO/Ae4tEJrLSX+CZk jp6V29sGxZeNO2ryt+MRjsFICQLLammfqCe813bzJA9vZCq4WiASJXDtNtIuFbJY7iwm NUdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=7CT+zHDOVa+uuKtChoAbE4cdGdcLwwRxUdQL5XCt97A=; b=d9v00WLfx/XS47WFaWdDI0xcXWcwx6J+/0155DZI35hAxISaJqA30YiV6FaeODmeIK QJRCnm9PJuUcMyht1ggpPiUSXdrlh6bi5b2/TgwnzJzVUYHTvjtJumMHZe3ZeP9rUnIO wP89pEN6SHmSAj3TlMVbwbir0LH7+dP110bBLivbEKZ4ISHVD3m/BqCIMmT2Z8GuZCIN aNDHFRDFyIjsi/jAYf5c4qNqg55jrxZkMSWrOkf0TUud/0t2sLoTJJrLHubrwzGPXkr6 /RgCYCPEEzwtwCJuT6lCcmhPLVv7JQ9bLubbqYotZnAbvCqJHrtfWVWRhgTFGjaBlV/9 fxnA== X-Gm-Message-State: APjAAAUXyFGbIjPlFKByx5afpPLbcJvkRhWAvhmFPiQrtDqncnB5rVBl RanQx/WWfdfVpqR4MxlmbqB5Xxn03KBI3dqb0EQ= X-Google-Smtp-Source: APXvYqzokvGmvOXppC5FPwYKUBV+EnJHVvYU9jttkh6z8T0qkeO3iMlveOExugUQVV89aeJHfyQrJJ80j7OcJWobyTI= X-Received: by 2002:a6b:8f41:: with SMTP id r62mr5115922iod.140.1578710998950; Fri, 10 Jan 2020 18:49:58 -0800 (PST) MIME-Version: 1.0 From: Tadahiko Ito Date: Sat, 11 Jan 2020 11:49:47 +0900 Message-ID: To: Stephen Farrell Cc: LAMPS WG , Russ Housley , Ryan Sleevi Content-Type: multipart/alternative; boundary="0000000000004ba9c4059bd44cb6" Archived-At: Subject: [lamps] Subject: Re: LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 02:50:01 -0000 --0000000000004ba9c4059bd44cb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi There were some certificates which use ECDSA with KU for encryption. I believe we need to reduce that number. Some people may worry about influence of that draft, but reduction approach should depends on each PKI=E2=80=99s policy manager. Policy manager still has right not to take that draft. However, technically right usage should be clear, so the IETF should say Must NOT. #I believe it is good to (at least) restrict newly issued certificates. >I'd say attempting to let 'em know would be a fine thing, >while also processing this draft. you are right. WGLC should be good chance to attempt. I am currently thinking about to send message to some issuer who has issued many or has many currently valid one. However, if someone sugest any other effective way I would like to take that. Regards Tadahiko Ito --0000000000004ba9c4059bd44cb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi


There were some certificates whic= h use ECDSA with KU for encryption.

I believe we need to reduce that = number.

Some people may worry about influ= ence of that draft, but

reduction approach should depends= on each PKI=E2=80=99s policy ma= nager.

Policy manager still has right no= t to take that draft.=C2=A0

However, technically right usage should be clear, so the IETF should say Must NOT.

#I believe it is good to (at least) restrict newly issued certificates.


>I'd say attempting to let= 'em know would be a fine thing,

>while also processing this dr= aft.


you are right. WGLC should be goo= d chance to attempt.

I am curr= ently thinking about to send message to some issuer who has issued many or = has many currently valid one.
However, if someone sugest any o= ther effective way I would like to take that.=C2=A0


Regards Tadahiko Ito

--0000000000004ba9c4059bd44cb6-- From nobody Sat Jan 11 07:19:50 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8217912007A for ; Sat, 11 Jan 2020 07:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 qiH-GU6QEjRB for ; Sat, 11 Jan 2020 07:19:43 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885A1120045 for ; Sat, 11 Jan 2020 07:19:42 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id cy15so4424260edb.4 for ; Sat, 11 Jan 2020 07:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=Prwkq6ikFJi9QSU3VtpqAYxFkWf1hB/PVRifXXPVW14=; b=T77QkovPMU1rRGh1jP3DQLN4hbhaeZ5n0yc78nGnzC1inHk/bcOPzMztrHErxH6tAS DMQgFgqO50m4sXoiD/gvsHuy61x0a1WyIv0J31LvSni1VrFy0t9gOT/kbSSXpsCw2eAO /BMIHmJlPjzkUNWuVPlAyjbqijbBho2aOztdw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=Prwkq6ikFJi9QSU3VtpqAYxFkWf1hB/PVRifXXPVW14=; b=T17AuIoId+Af2RP+iF4/O+ymw+xuqAWzC0/BAYVE+GMP9IpCTlDO1xkCoaPU+qjwGI 29ucdXHe/LqI0Slm4IVRI7ujX/R4pzQ4tLZqNWe7KusJqjr7M0p3p6uGVuX9RKnrBIxV aGnZRR4odiGV9dqkM4jdYFz5JPjEF9tZKVyIdS8nJ78CRwoq4aGzD7gD6EjHgQ8qUGOs 6u5EQ68kuO+27cEaA4jmLpPc/auCDHZvfY67FnS6E2rxrLn58A5mbfur7YM5c31/+MWy wUfXB/Y7XpGWiT2PNSn0aVecNgFNhuZFrwUiosIKP8C++bi92dCimGXfCtzL4LdNRx6S GhXA== X-Gm-Message-State: APjAAAUeIkErmVRC4vkIBbXOsZ78CxzNmlcgIQn9kNvQDG+IvlwTPY1g JEiNsv1HSYJXAdRxDErdzLpfK+3T6QIJ6Ha/+zTf+cgZ X-Google-Smtp-Source: APXvYqxLtRbxg65AcLEW5ykdTmFeg0TYtj9CtaJzojYYkIhId2n++Kd+qVfB5KJVuYhGiH8I6R2B7JtOjKLKOczukAA= X-Received: by 2002:a17:906:c40d:: with SMTP id u13mr8499336ejz.178.1578755980862; Sat, 11 Jan 2020 07:19:40 -0800 (PST) MIME-Version: 1.0 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> <25634a41-e5d8-20c4-a0b6-ed3744820b6d@cs.tcd.ie> <2758763B-38BC-4CEE-B501-CC87DF46DB33@sn3rd.com> In-Reply-To: <2758763B-38BC-4CEE-B501-CC87DF46DB33@sn3rd.com> Reply-To: cpu@letsencrypt.org From: Daniel McCarney Date: Sat, 11 Jan 2020 10:19:30 -0500 Message-ID: To: Sean Turner Cc: Ryan Sleevi , LAMPS WG , Russ Housley , Stephen Farrell Content-Type: multipart/alternative; boundary="0000000000006d3e6c059bdec520" Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 15:19:48 -0000 --0000000000006d3e6c059bdec520 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to a separate draft. On Fri, Jan 10, 2020 at 7:37 PM Sean Turner wrote: > I wouldn=E2=80=99t mind taking that on, but I=E2=80=99d really rather do = it in another > draft. > > spt > > > On Jan 10, 2020, at 14:20, Daniel McCarney wrote: > > > > Hi folks, > > > > I was curious about the high number of ECDSA certs with bad KU > associated with the Caddy project in Ryan's Censys summary. I opened an > issue with the project[0] and the primary author pointed out that he took > the code at fault from the Go standard library's `generate_cert.go` > utility. I've opened an issue[1] with the Go folks to get that fixed but = in > the process noticed that the tool sets the KeyUsage field incorrectly for > both ECDSA and ED25519 subject public keys. > > > > This led me to notice that RFC 8410's section on "Key Usage bits"[2] is > missing the "keyEncipherment and dataEncipherment usages MUST NOT be > present" language that draft-ietf-lamps-5480-ku-clarifications-00 is addi= ng > to RFC 5480. > > > > Would the WG be interested in updating RFC 8410 with similar > clarification? I believe the keyEncipherment and dataEncipherment key > usages are equally inappropriate for these algorithms as for ECDSA but I'= m > open to schooling if I've made a mistake in my analysis. > > > > Thanks, > > > > [0]: https://github.com/caddyserver/caddy/issues/2969 > > [1]: https://github.com/golang/go/issues/36499 > > [2]: https://tools.ietf.org/html/rfc8410#section-5 > > > > On Wed, Jan 8, 2020 at 3:38 PM Ryan Sleevi wrote= : > > > > > > On Wed, Jan 8, 2020 at 3:04 PM Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > > > > Hiya, > > > > On 08/01/2020 19:51, Russ Housley wrote: > > > This is a very short document, and it had some review prior to WG > > > adoption. So, now that the document has been adopted, I think it is > > > ready for WG Last Call. > > > > > > This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve > > > Cryptogtaphy Subject Public Key Information" > > > . Please review the > > > document and send your comments to the list by 24 January 2020. > > > > I re-read it and support it. > > > > I would support publication if someone tells me that > > they've done a survey (via e.g. zmap/zgrab or crt.sh) > > and found that there are zero or only a tiny percentage > > of issued certificates that conflict with the draft. > > > > If that happened already apologies and great! > > > > If not, shouldn't that be done before declaring success > > on WG last-call? > > > > Could you explain the objective? =3D) > > > > That is, part of the reason for this is to clarify whether or not it's > expected or not. The suggestion was rather than the CABF profile to > explicitly say it's not expected/allowed, to address this and clarify in > the IETF whether the omission of elements from the extant MAY implies a > MUST NOT. > > > > This is part of a broader effort in the CA/Browser Forum of clarifying > that if things are not explicitly allowed, they should be interpreted as > forbidden. In the context of ECDSA, is there a situation where those > keyUsages makes sense and aligns with those key algorithms? Arguably, no, > hence the draft to make it clear ;) > > > > That said, you can run a Censys query with the following: > > parsed.subject_key_info.key_algorithm.name: "ECDSA" and > (parsed.extensions.key_usage.data_encipherment: true or > parsed.extensions.key_usage.key_encipherment: true) > > > https://censys.io/certificates?q=3Dparsed.subject_key_info.key_algorithm.= name%3A+%22ECDSA%22+and+%28parsed.extensions.key_usage.data_encipherment%3A= +true+or+parsed.extensions.key_usage.key_encipherment%3A+true%29 > > > > For what it's worth, a number of PKI libraries will reject these > certificates as invalid, which will not even allow the user to bypass the > error, as they've interpreted the extant language as being what this draf= t > codifies. > > > > The quick summary of those results, run just now: > > 46.36K Never Trusted > > 39.72K Expired > > 38.95K Unexpired > > 31.48K Self-Signed > > 1,628 CT > > 1,628 Google CT > > 1,217 CT PreCert > > 840 Leaf > > 828 EV > > 774 Previously Trusted > > 416 DV > > 299 OV > > 66 Currently Trusted > > > > 17.76K Freebox SA > > 14.03K Philips Hue > > 9,942 Caddy Self-Signed > > 5,927 CloudFlare, Inc. > > 2,261 Docker > > 1,551 Mesosphere, Inc. > > 968 Mesosphere Inc. > > 927 McAfee, Inc. > > 920 NoEnv > > 808 Jungheinrich AG > > 640 Gemalto > > 488 Bird Home Automation > > 477 GlobalSign nv-sa > > 449 Developer Certificate > > 406 A1A Car Wash > > 399 StartCom Ltd. > > 377 Entrust, Inc. > > 342 VirtuallyLive > > 274 SpectraLogic > > 248 DNSFilter > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > --0000000000006d3e6c059bdec520 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to a separate draft.

On Fri, Jan 10, 2020 at 7:37 PM= Sean Turner <sean@sn3rd.com> w= rote:
I wouldn= =E2=80=99t mind taking that on, but I=E2=80=99d really rather do it in anot= her draft.

spt

> On Jan 10, 2020, at 14:20, Daniel McCarney <cpu@letsencrypt.org> wrote:
>
> Hi folks,
>
> I was curious about the high number of ECDSA certs with bad KU associa= ted with the Caddy project in Ryan's Censys summary. I opened an issue = with the project[0] and the primary author pointed out that he took the cod= e at fault from the Go standard library's `generate_cert.go` utility. I= 've opened an issue[1] with the Go folks to get that fixed but in the p= rocess noticed that the tool sets the KeyUsage field incorrectly for both E= CDSA and ED25519 subject public keys.
>
> This led me to notice that RFC 8410's section on "Key Usage b= its"[2] is missing the "keyEncipherment and dataEncipherment usag= es MUST NOT be present" language that draft-ietf-lamps-5480-ku-clarifi= cations-00 is adding to RFC 5480.
>
> Would the WG be interested in updating RFC 8410 with similar clarifica= tion? I believe the keyEncipherment and dataEncipherment key usages are equ= ally inappropriate for these algorithms as for ECDSA but I'm open to sc= hooling if I've made a mistake in my analysis.
>
> Thanks,
>
> [0]: https://github.com/caddyserver/caddy/issu= es/2969
> [1]: https://github.com/golang/go/issues/36499
> [2]: https://tools.ietf.org/html/rfc8410#section-5=
>
> On Wed, Jan 8, 2020 at 3:38 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>
>
> On Wed, Jan 8, 2020 at 3:04 PM Stephen Farrell <stephen.farrell@cs.tcd.ie&g= t; wrote:
>
> Hiya,
>
> On 08/01/2020 19:51, Russ Housley wrote:
> > This is a very short document, and it had some review prior to WG=
> > adoption.=C2=A0 So, now that the document has been adopted, I thi= nk it is
> > ready for WG Last Call.
> >
> > This is the LAMPS WG Last Call for "Clarifications for Ellip= tic Curve
> > Cryptogtaphy Subject Public Key Information"
> > <draft-ietf-lamps-5480-ku-clarifications-00>.=C2=A0 Please = review the
> > document and send your comments to the list by 24 January 2020. >
> I re-read it and support it.
>
> I would support publication if someone tells me that
> they've done a survey (via e.g. zmap/zgrab or crt.sh)
> and found that there are zero or only a tiny percentage
> of issued certificates that conflict with the draft.
>
> If that happened already apologies and great!
>
> If not, shouldn't that be done before declaring success
> on WG last-call?
>
> Could you explain the objective? =3D)
>
> That is, part of the reason for this is to clarify whether or not it&#= 39;s expected or not. The suggestion was rather than the CABF profile to ex= plicitly say it's not expected/allowed, to address this and clarify in = the IETF whether the omission of elements from the extant MAY implies a MUS= T NOT.
>
> This is part of a broader effort in the CA/Browser Forum of clarifying= that if things are not explicitly allowed, they should be interpreted as f= orbidden. In the context of ECDSA, is there a situation where those keyUsag= es makes sense and aligns with those key algorithms? Arguably, no, hence th= e draft to make it clear ;)
>
> That said, you can run a Censys query with the following:
> parsed.subject_key_info.key_algorithm.name= : "ECDSA" and (parsed.extensions.key_usage.data_encipherment: tru= e or parsed.extensions.key_usage.key_encipherment: true)
> https://censys.io/certificates?q= =3Dparsed.subject_key_info.key_algorithm.name%3A+%22ECDSA%22+and+%28parsed.= extensions.key_usage.data_encipherment%3A+true+or+parsed.extensions.key_usa= ge.key_encipherment%3A+true%29
>
> For what it's worth, a number of PKI libraries will reject these c= ertificates as invalid, which will not even allow the user to bypass the er= ror, as they've interpreted the extant language as being what this draf= t codifies.
>
> The quick summary of those results, run just now:
> 46.36K=C2=A0 =C2=A0 =C2=A0 =C2=A0 Never Trusted
> 39.72K=C2=A0 =C2=A0 =C2=A0 =C2=A0 Expired
> 38.95K=C2=A0 =C2=A0 =C2=A0 =C2=A0 Unexpired
> 31.48K=C2=A0 =C2=A0 =C2=A0 =C2=A0 Self-Signed
> 1,628 CT
> 1,628 Google CT
> 1,217 CT PreCert
> 840=C2=A0 =C2=A0Leaf
> 828=C2=A0 =C2=A0EV
> 774=C2=A0 =C2=A0Previously Trusted
> 416=C2=A0 =C2=A0DV
> 299=C2=A0 =C2=A0OV
> 66=C2=A0 =C2=A0 Currently Trusted
>
> 17.76K=C2=A0 =C2=A0 =C2=A0 =C2=A0 Freebox SA
> 14.03K=C2=A0 =C2=A0 =C2=A0 =C2=A0 Philips Hue
> 9,942 Caddy Self-Signed
> 5,927 CloudFlare, Inc.
> 2,261 Docker
> 1,551 Mesosphere, Inc.
> 968=C2=A0 =C2=A0Mesosphere Inc.
> 927=C2=A0 =C2=A0McAfee, Inc.
> 920=C2=A0 =C2=A0NoEnv
> 808=C2=A0 =C2=A0Jungheinrich AG
> 640=C2=A0 =C2=A0Gemalto
> 488=C2=A0 =C2=A0Bird Home Automation
> 477=C2=A0 =C2=A0GlobalSign nv-sa
> 449=C2=A0 =C2=A0Developer Certificate
> 406=C2=A0 =C2=A0A1A Car Wash
> 399=C2=A0 =C2=A0StartCom Ltd.
> 377=C2=A0 =C2=A0Entrust, Inc.
> 342=C2=A0 =C2=A0VirtuallyLive
> 274=C2=A0 =C2=A0SpectraLogic
> 248=C2=A0 =C2=A0DNSFilter
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org=
> https://www.ietf.org/mailman/listinfo/spasm
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org=
> https://www.ietf.org/mailman/listinfo/spasm

--0000000000006d3e6c059bdec520-- From nobody Tue Jan 14 14:06:19 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7296C120059 for ; Tue, 14 Jan 2020 14:06:18 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=FYX8R5Ce; dkim=pass (1024-bit key) header.d=digicert.com header.b=XkW4aJZk 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 0USFqzc6NvhI for ; Tue, 14 Jan 2020 14:06:13 -0800 (PST) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A3B120113 for ; Tue, 14 Jan 2020 14:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1579039572; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eJUa6j69SxLLXb/cYFprLEmtoFndVXJ/Cbx1NroPXFg=; b=FYX8R5Ceqebl73Tg6m/UhHoCqU4QmwhOUCHyyhj2xovJJrdHkWyBnaceHn69tAHpLcq6+R zP21VYSfS2wZtVCu1z63zrj805qkke/uPy00006gU6nXVvZdUscNmJqZQqJrbjXHfzXQqR nxPdTwlhPsdyGit4fhWPWBFRk/PIM84= Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-186-mqZ52SYeMk-PzafdTN5HPA-1; Tue, 14 Jan 2020 17:06:10 -0500 X-MC-Unique: mqZ52SYeMk-PzafdTN5HPA-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KbfqG6eDlCpLXiH+mc9dsFy5vUzxMF/aPTZd+Dj45Ys9T14wxAldgTTsitAGUftGBKaQZGyx/ZfuNmZBBNMt1eMJVRNp+yw6W8jgXPpzF2333ODdE4ONzfNURiVyg+RU6QIh4ZQUqhEw5SZMM6g5DZiinxHoqpiZGjX45sK6KJ7BDlCK6zrnkO45SpNifF/CnhWYBfkdX+Cbo40gmyEJdfZtnh4N71P2J2SND2ZGkOgyUukQbvNK9L2I0DxQyMNJcqoCCuH6qupJS4JY+LjDhqTJglOkKLG+Xbwm38FukcCw6tcbGI9Vbio7xxepLY7r8zjbUatIaOI84Xj1v36gfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eJUa6j69SxLLXb/cYFprLEmtoFndVXJ/Cbx1NroPXFg=; b=WvPkWiQ/1RU/04/wnPZMjGs50uK2OQkOFQFof13ie1zZZ5UjfrrsXfbUH8KJEV4jA26daoE1bVaHMTVz2rE/2o6mawaeTm59+Ddq1+opK4PtFdOqdwRlPzG/964LsMBUBO6dxLJPvCof0pzFrCIvpSSzj65+bxsZ6/ApRGhOSr5oWRxSIhLJMy4typ1ziu90R+MPUpA0i/yEOKkgJbzuab+Jqb9b0aMm8TdOsU4Lu/7CYL7xJmSPCLoalhxi6LHLu/O0WBEjkjjGH0ZZ1I4QnZx4EPvvwvuYaMH13rxdeuJpjFv6ltSAIfDIe1KttsS7UIueF0Q1LiHPhO+RG8yrYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eJUa6j69SxLLXb/cYFprLEmtoFndVXJ/Cbx1NroPXFg=; b=XkW4aJZkK5bzuLUKo2YWzEM1PLLsjsyxkMfP+01mglVI/36z70+o6zDeEcouOVvWjQcvlrQOflBCDU4TwtWYPlOvYCTbhM2jm4EjSXF3ZlEx3SLjoJl+3Z0mwQMSAIqsawJ+KBhS4c+OeWE8rVxAb1gQnyytdEGLW6Gb1+Wd1MY= Received: from BN8PR14MB3059.namprd14.prod.outlook.com (20.179.138.155) by BN8PR14MB2850.namprd14.prod.outlook.com (20.179.139.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Tue, 14 Jan 2020 22:06:07 +0000 Received: from BN8PR14MB3059.namprd14.prod.outlook.com ([fe80::1c00:c58b:a419:ebe5]) by BN8PR14MB3059.namprd14.prod.outlook.com ([fe80::1c00:c58b:a419:ebe5%7]) with mapi id 15.20.2623.015; Tue, 14 Jan 2020 22:06:07 +0000 From: Tim Hollebeek To: Tim Hollebeek , SPASM Thread-Topic: Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect Thread-Index: AdW3SgT7TzvannoqRPuIFXJ92Hzy6QT3LQ7Q Date: Tue, 14 Jan 2020 22:06:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [118.238.219.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a6e9d73f-fff3-4c40-93f3-08d7993df502 x-ms-traffictypediagnostic: BN8PR14MB2850: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:873; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(199004)(189003)(64756008)(44832011)(86362001)(66476007)(8936002)(2906002)(66446008)(110136005)(8676002)(81156014)(76116006)(81166006)(66946007)(66556008)(66616009)(5660300002)(4744005)(33656002)(15650500001)(498600001)(71200400001)(7696005)(6506007)(55016002)(9686003)(53546011)(26005)(52536014)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR14MB2850; H:BN8PR14MB3059.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8oD98oXl6O/uIoB6WLlr7eqWF+zZiFyMxvfsy2sE28KiIRhBySddgh21/cZjarvEm7i6DQGqZMiVQ4gf+F5NMJeNoSf2zWUNv3IGJ6nL1nEfQZfEh1jXfNEA6BPHO6zONksbO6NavNDQWp5sHrsnjFy1ROUPQ7izqYWdpDrr1OqkXoxy8EWKXOkNp9iAs5qwXAFjPXHr5a+SQbH48X7McKapScpUD1AL5BziT9atMzzEuiuOHbi8bFPyGRn/PnZx0y2h1kySvMmQtfqNj9Tep6Dme3YOCSqa29z/63ybqCpbkhtfqxfQ6IJfFE5mCRMoAvELomR8HyK498tcEqRGgpBUMFOnbFIGc9UGUDlHTZ3GuyG6j3XchyzMfAe0gFNf+Sv2IOYKuH2SRcGY6kNJrYwAWVM+lBzDLT7AB4Xkg2Fd9B3TjIu4kNWoseUnPD9N Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0BBB_01D5CB72.34EFF8F0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6e9d73f-fff3-4c40-93f3-08d7993df502 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 22:06:07.8186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aM1j3sJmKdNeIy0iSgO2/HNlwFD0pDwNAqD4X9+GAbi/4BT6urVlKvx94geWAomi4GjJdEUO34xWO/4GHutOQyRutQgDPtES9UU3yHSX0Tw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR14MB2850 Archived-At: Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 22:06:18 -0000 ------=_NextPart_000_0BBB_01D5CB72.34EFF8F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0BBC_01D5CB72.34EFF8F0" ------=_NextPart_001_0BBC_01D5CB72.34EFF8F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reminder: This call for adoption closes soon. -Tim From: Spasm On Behalf Of Tim Hollebeek Sent: Saturday, December 21, 2019 12:29 AM To: SPASM Subject: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect Please indicate whether you support adoption of Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January 17th. -Tim ------=_NextPart_001_0BBC_01D5CB72.34EFF8F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reminder: This call for adoption closes = soon.

 

-Tim

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Tim = Hollebeek
Sent: Saturday, December 21, 2019 12:29 = AM
To: SPASM <spasm@ietf.org>
Subject: [lamps] = Call for Adoption of = draft-housley-lamps-cms-update-alg-id-protect

<= p class=3DMsoNormal> 

 

Please = indicate whether you support adoption of Call for Adoption of = draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January = 17th.

 

-Tim

------=_NextPart_001_0BBC_01D5CB72.34EFF8F0-- ------=_NextPart_000_0BBB_01D5CB72.34EFF8F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAwMTE0MjIwNTQ1WjAvBgkqhkiG9w0BCQQxIgQg8qC33DHMxx/oF3aziQEVM01FYLJL 4Tt+Azf09++gwKkwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAGFgFPaW62cNZEdVMHArBl+7QssjRwRN2104xTan5Yi1dUHcWSXN2yjnrRCsWXNhnoxKEZud jtewJ+ntiYrxsSFwetF/deNhSMjUUyUgofjkY4m1jjv/7M+3t6U+Bc1H3hnGOY/sOzaX2VhnWFxf t0+qWMywB+AXYmBmQBSQMlgNPLohe2LgOlYA0ovHxZnZMrM5XSLeq/tB36/e9DiMXtGtC5fhuRfH wus+1phHpul+3G86mjjLcwlfS8RiUlPchnvU/rp7zoeNN1R16d4Xcw/qx23hvOLfixu6d9KuD670 SA/xi7IyjFvfV3dJfFphw5ROuIaZJsOKvfY1qyKoVM8AAAAAAAA= ------=_NextPart_000_0BBB_01D5CB72.34EFF8F0-- From nobody Wed Jan 15 06:26:05 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192E5120033 for ; Wed, 15 Jan 2020 06:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 SH4D4ao_7KZm for ; Wed, 15 Jan 2020 06:25:21 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80083.outbound.protection.outlook.com [40.107.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADABF120025 for ; Wed, 15 Jan 2020 06:25:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oJXH77u25m4EginBF8NcB7p0ja7Hm/r/W44zujEIi+5rKjfUe7RmnrmC8FbfBS4fDCe150Vw4Ujl3Oc/joRGqP5eEJGQj8RygtqyyAfd+ud7bxuD8om1LITSGB6oYO/e9pleggbgGw+UPiASmkaCWmRSCXHlxrzGu41+mNhczgLr+tkfIuz+Cc7/iAgimRAZ3YnnBK9gpqGZC6IsyEPdPA3ay1gMXTf9c2uo47Cse+LA7SBZxqz2L+op27MlgTpf/74GwTyaIy2S3sOGdd3Nc+Ubb3zgz+z1HgBASb9U+mNV25Pp4VsUFAizWlyq3nMz2nntHAHWZiUWlmwLu+InRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RzN5MhFo5/5VzwGyI5r4w7mumJD7nPX7+Lhp0fZQhLE=; b=a+i5ao8y4X2AD6wWXP3KdOzLYsUv6GGs9cAEcvHrw0PPby7/TpYUnrC2mPcM7Rq9nYeHcZqGoNjH72IlbGesx+U8QBCeYXqTtgkhDWg+P83WNkOD21Sb9ek/RPB6pA+n2TqmJ4Wkn3ncQKUiTGsSkBPNCLEzKrHLyATFf5S5BPk5lhYmm70sacCH3y6kb/jY36tBq3RhaSWyWuO1ACskm2Hjc6uUFcQ7FF4tmqqdn/I9wns4zvVEGzKe1H3BS0mH1k7H3xG6bmJ4TNBSwb9ARn1/I3DtzPi8s4fVDjqmylUqgc6dFwKXfbv7T7ICzCR6CEiWH7t5lJmTEkrIhfI9qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RzN5MhFo5/5VzwGyI5r4w7mumJD7nPX7+Lhp0fZQhLE=; b=JQnEG2ulPXknWCXWDg7UN/XLuZU4StHqFeySHMhMwkYJiSHSkeNux+XzBvx5Tp4J6+BY4Yqc7aWGiC5IIfm2Jlyi+PW77nnURuEBiondEhKma+VcLKNUkZkHGQHb1xeWKVe2goCz/pwxXQ382ty+IK59UB6EjFidi0PDwDK3Q2k= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB3665.EURPRD10.PROD.OUTLOOK.COM (10.186.173.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 15 Jan 2020 14:25:17 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a059:85c0:8cba:4b1b]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a059:85c0:8cba:4b1b%6]) with mapi id 15.20.2623.018; Wed, 15 Jan 2020 14:25:17 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson , LAMPS WG CC: "steffen.fries@siemens.com" Thread-Topic: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile Thread-Index: AQHVxWtJYB0uOyHDaUK+bxSA9eNMy6ffqTKAgAurkbA= Date: Wed, 15 Jan 2020 14:25:16 +0000 Message-ID: References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> <32139.1578429337@localhost> In-Reply-To: <32139.1578429337@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [195.145.170.190] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8bba61af-fbfc-4e59-8588-08d799c6be3a x-ms-traffictypediagnostic: AM0PR10MB3665:|AM0PR10MB3665: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(396003)(39860400002)(346002)(199004)(189003)(107886003)(26005)(86362001)(186003)(33656002)(8936002)(4326008)(71200400001)(7696005)(6506007)(15974865002)(52536014)(9686003)(316002)(81166006)(110136005)(55016002)(478600001)(966005)(66946007)(8676002)(76116006)(66476007)(66556008)(64756008)(81156014)(5660300002)(66446008)(2906002)(15650500001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB3665; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ks45Jz5bj2rWp6pztI30kN/PlPgvy/tKZrnnXlzSja5hr10CFSVRmF045GOox6P4SMPSYhISq6hpLVG+/jAHs1hpPo1W4TmoNaDuXQMO4EIq2UgsV0J2ZhRA/PFnbDKLTjsEbMV3dV5fVhb6Z7VNcX7B5FWR94G+eVLRIsdwxYAPhe9vONwqnHL6RBspHGSdCAJeiBnRmGCR+U8aLX8S8N+zhFZzW9gMs4nz9pxGg1RfUOSYrGKWBJtysw36HWcolXWZ8DyHtQIGTXaYf4zq8NrXTNGMwkWlozYOcpjITq+SiWcX6JT271yhVxmPb7MH2Vn0XJ7yI09sZkJydt1kY7Tdzf3bBYDe1qBIkY3rvLjBahbih/iZEls52Wl+veDnkLaS2QDVHmDmPvyMAKjNtK92D8y2Di64WXnHMcYBN1fJIJMrLTrU4MQCM+1aOhGmLijDFS+y5QxvFEsGHBidIK1SrxWK088UDHDca0OziIX5mqGFOKXqRf0H7RrP1l0/92aEywClI1rAXkp9IVBqFg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bba61af-fbfc-4e59-8588-08d799c6be3a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 14:25:16.8229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uP3e7hlJd+Rw3vaHIGFKJI3/aQFjoFkCtU/28gDdttbeSy/RqsE73zjdFyS5PtwCVyhrKD4skfLo+kvOoHEeOUri10YTtTfd3YznHCs4jbg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3665 Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 14:25:26 -0000 Michael, Thank you for you detailed feedback and comments. Below you find my feedbac= k to your comments. (Sorry for my late response...) > Von: Spasm Im Auftrag von Michael Richardson >=20 > I support adopting > - draft-brockhaus-lamps-cmp-updates [Bro] Thank you for your support! >=20 > with the following (non-blocking) comments: > * I find that section 3 lacks motivation for why it is making these cha= nges. [Bro] The idea is that New Section 1.1 provides the motivation for the chan= ges. The other sections should only contain the technical changes. Does New= Section 1.1 is not descriptive enough? > * why is "The following updates were made since RFC 4210:" in the past > tense? [Bro] Actually I took Jim Schaad's RFC 6402 'Updates CMC' as of blueprint. = He put it a bit different like "The following updates were made by RFC 6402= .". I am not a native speaker, so I am not sure about the correct tense to = use here. Should I say "The following updates are made in draft-brockhaus-l= amps-cmp-updates:" and replace the draft-... with the RFC number after the = release? But I am happy for any concrete suggestions on how to put it best. > * > Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA an= d > a CMC RA. As the functionality of a CA and RA is not specific to > whether use CMC or CMP as certificate management protocol, the same > OIDs SHALL be used for a cmpCA and a cmpRA. >=20 > I believe that I might need a little bit of convincing here on reusing cm= pRA. [Bro] My first approach was to specify new OIDs for cmpCA and cmpRA, but du= ring the discussion at IETF106 Sean Turner suggested to reuse the OIDs alre= ady specified for CMC here. As the EKU OIDs specify for which purpose the p= ublic key may be used, I see no much differences between the usage of a pub= lic key for CMC and for CMP from a key usage perspective. Therefore, I took= Sean's suggestion and tried to express the idea in this Note. =20 > I want to think about this a bit.... the last two paragraphs of 3.2 hint = at my not > well formed concerns. > As such this document would seem to update RFC6402 as well. [Bro] You are right, the issue with undefined validation dates is an issue = for all certificates used for PKI management entities. So you may be right,= that this is also relevant for CMC or EST. I personally see it as a matter= of course to use limited validity for those certificates used on PKI manag= ement entities. Therefore it is only a Note her.=20 >=20 > I do wonder if 4210bis might be better a better idea rather than > replacing/updated so much "EncryptedValue -> EncryptedKey". [Bro] The idea was not to write a 4210bis but to have only very limited upd= ates to CMP together with a concrete profiling. Reworking the complete 4210= RFC would be much more effort and would need much more community support.= =20 >=20 > - draft-brockhaus-lamps-lightweight-cmp-profile >=20 > This is the document I'm more interested in. > At 64 pages, I wonder about "lightweight" ;-) [Bro] You are right, 64 pages does not look lightweight. Lightweight refers= more to the very limited number of mandatory use cases as specified in sec= tion 3.3.1. This is on the EE only the initialization and update and on the RA the forw= arding with and without changing the original message.=20 > I believe that a two paragraph > summary of Appendix D and E would be worthwhile. [Bro] I thought the very brief summary in section 2.3 is sufficient and for= more details one would anyhow look into RFC4210. But I can add a detailed = summary to section 2.3, if you think it is helpful. > How much of 4210 could we just throw out in a 4210bis? [Bro] For the use in automated certificate management in a machine-to-machi= ne communication environment we do not need many feature specified in CMP a= nd CRMF. That is why I wrote the profile to specify what to use and what no= t.=20 I also see the value of a 4210bis and throw away all what is not needed, bu= t I can not say what features of CMP are needed for other use case. Therefo= re Profiling is an approach we can do focusing on our uses cases and 4210bi= s is the bigger approach where we have to take all existing uses cases into= account. This is something a bigger group of people would have to contribu= te. > s/IPSec/IPsec/ {it's the brown M&M of rfc4301} >=20 > section 2.6 says: > "Chapter 2", so I think the references are all dangling. > XML2rfc deals with tis for you, so I'm guessing you aren't using here? [Bro] You are right, I will change this to and Section x.=20 BTW: Should I always use Section instead of Chapter in this document?=20 In later sections I referred to the top-level structure as Chapters and sub= sections as Section. >=20 > I find this statement: > HTTP transfer is RESOMMENDED to use for all PKI entities, but there > is no transport specified as mandatory to be flexible for devices > with special constrained to choose whatever transport is suitable. >=20 > (aside from the typo), difficult to take in a profile. > RECOMMENDED is a synonym for SHOULD, and usually needs to have some > explanation of when another answer is appropriate. > If you want to be open to COAP, then let's just say that. [Bro] You are right, I see HTTP transfer as the most important transport op= tion as it is already specified in RFC6712. But I also see devices and uses= cases where HTTP transfer will not be possible. In offline scenarios we wo= uld need some file based transport, in constrained environments CoAP is use= d instead of HTTP, and in any other environment for example the last mile t= o the EE is bridged with some wireless protocol like NFC or what so ever. T= he advantage of CMP is to have no requirements regarding transport but reli= ability. There is also some explanation at the beginning of section 7 on this.=20 The CMP messages are designed to be self-contained, such that in principle any transport can be used. HTTP SHOULD be used for online transport while file-based transport MAY be used in case offline transport is required. In case HTTP transport is not desired or possible, CMP messages MAY also be piggybacked on any other reliable transport protocol, e.g., CoAP [RFC7252]. Is this more what you were looking for? Should I also add some more description in section 3.4?. > I'm glad that section 7.1 makes the URL clear. > I think that lower case 'cmp' would be more consistent with other .well-k= nown > uses. [Bro] Good to hear that you like it. There was further feedback from Tomas = Gustavsson regarding the URIs and I see his concern regarding endpoints for= different CAs and different types of certificates to be request as valid. = As it is seems to be easy to spot the message type from the header of the C= MP message (except for central key generation and general messages, there y= ou need to look into the type field in the body too), there is no real tech= nical need for the second half of the URL. On the other hand an 'arbitraryL= able' as also specified in EST section 3.2.2 could be used to specify the C= A or CA profile to be used.=20 Actually, I am not finally sure on what the best solution would be and I ap= preciate all thoughts on this. Let us continue this discussion in response = to the email from Tomas to have the discussion regarding this topic in one = thread. >=20 > 7.2 should say TLS 1.2 or greater/newer, rather than saying 1.2 or 1.3. >=20 > Both the HTTP and HTTPS usage might need to be clear if support for > HTTP/2 and/or QUIC is expected to be supported. Constrained environments > want to know what they can skip. [Bro] Thank you for this hint. I will talk to Steffen Fries, he is more exp= ert in this. =20 >=20 >=20 > 7.5. CoAP transport > ... > Such specification is out of scope of this document and would need to > be specifies in a separate document. >=20 > I think that it's not that hard to specify this. [Bro] In the first version of this document I also had CoAP in scope. But a= fter synchronization with Jim Schaad and the ACE WG, we decided to have thi= s out of scope of this draft to have a more clear focus on LAMPS and to cir= cumvent overlaps with ACE. We have more practical experiences with HTTP and only some experiences with= CoAP transfer (see https://github.com/siemens/embeddedCMP). I am open to t= ake CoAP transfer back into scope, but I would need someone with more CoAP = experiences to properly write this section. Hendrik Brockhaus Siemens AG Corporate Technology Research in Digitalization and Automation Security Architecture CT RDA CST SEA-DE Otto-Hahn-Ring 6 81739 Muenchen, Germany=20 Tel.: +49 89 636-633672 Mobile: +49 174 1517765 mailto:hendrik.brockhaus@siemens.com www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann= Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive= Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Ne= ike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Ge= rmany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB= 6684; WEEE-Reg.-No. DE 23691322 From nobody Wed Jan 15 06:26:09 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5C612003E for ; Wed, 15 Jan 2020 06:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 creBa7gFbH5P for ; Wed, 15 Jan 2020 06:25:28 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80089.outbound.protection.outlook.com [40.107.8.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAF4120025 for ; Wed, 15 Jan 2020 06:25:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nk43jObB7DlT5/vSNMCJAaAQLy02886Wfk3sCllreeLY+su99OMQdecU0nlUZN/7noQxI+/2F4H/gJMrNoq41GTsgZicLCKSk1tyqVSH5xGgWI95eaMjrwpVUPVjSXZhBBHQZsaGQgY9yN+E1CEZ0IxeS7FU/ojZUOL6QMNTS5JLtcUKGoYq/wYC/DIgtiajHX1XZff2xRKAJ364Ck9w/GiCgVxnrR8a7jvYCzSpKvIjggulYVD4kAs6IwAyvm2u9Cf3M3CdWq/GHHrg655+GTOUfzMvwPr6Sq8PTY/FKzmbfW5owWLavWq9OOfNAvOxeWlLHfWzpMMCD2gpTVzj4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2H6ao+1HpntdVcvmRXdISn6/dPGyIxHBP3AkG4uye1A=; b=NmokzkZc7f0Yo47kLENaDguT02qHT5vANL3WefTHBkEnhhd97V3m84hV7xzpuJQ+ZYJ+8HIGC6C+QIPcPvN4HSq5IhCS2EcbmApwvsVwzfNyOF6De/w3MkyXSynyKmPCbL8Tymjcwa4JoPWLyKxtjN7TozxRGo0wrPZo07Ff0RtXoxSPTAn5874yF9Cd/hHT/LURGLO4a92xyKBB1NK7k28ROSL08OuKMNZvT2AbJkUd2YqLFWPvuAfkhX4kVbv6edPyaMJmaNA6mGirMD8UcAl7yGjkaxWpfiE4Ds+6gooUWA98S9FOTnU6WaQ/3yLdlaJIX2W7U1U7CEGtUoYogA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2H6ao+1HpntdVcvmRXdISn6/dPGyIxHBP3AkG4uye1A=; b=W5JGyoGLAu+WBdBVQbpl0HQ18ErLI82MdwZl8ARqc9ZPWDSU35dN/ah0C4bwlooB+9ki+S7FLtrAcpzEScpOl6OGQkfSXORS0wV2XGd0Kvvwn8eXWkkyI8Gbtg3Ws+4QcFXtgRpjrp7SbgjEwDq9mwfPx9abc+/q1BCQwTGowjo= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB3665.EURPRD10.PROD.OUTLOOK.COM (10.186.173.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 15 Jan 2020 14:25:26 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a059:85c0:8cba:4b1b]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a059:85c0:8cba:4b1b%6]) with mapi id 15.20.2623.018; Wed, 15 Jan 2020 14:25:26 +0000 From: "Brockhaus, Hendrik" To: Tomas Gustavsson , "spasm@ietf.org" , Michael Richardson Thread-Topic: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile Thread-Index: AQHVxWtJYB0uOyHDaUK+bxSA9eNMy6fgl7kAgAr1GoA= Date: Wed, 15 Jan 2020 14:25:25 +0000 Message-ID: References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [195.145.170.190] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2c086357-2218-44e2-fa19-08d799c6c3a1 x-ms-traffictypediagnostic: AM0PR10MB3665: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(4636009)(136003)(366004)(376002)(396003)(39860400002)(346002)(199004)(189003)(26005)(86362001)(186003)(33656002)(8936002)(66574012)(71200400001)(7696005)(6506007)(52536014)(9686003)(316002)(53546011)(81166006)(110136005)(55016002)(478600001)(966005)(66946007)(8676002)(76116006)(66476007)(66556008)(64756008)(81156014)(5660300002)(66446008)(45080400002)(2906002)(15650500001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB3665; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: j0mGYCDPW5tB2AQVxNowidGJpVAZ9Q96kQE6eZOyZwKjI74VDAhVsZLi/aRvjskTEVLJmgue+YAThMeyt9pjtzjf6VJyqmVo19BWawma5QXlEPhrK9cWBFFURhr6OhosWBoluoqtrsegj3Hg4Jo4scFMjRgr6asfrRr6MGvV9lRMx7PdqA4HJGeMvF2Jiz+rh9cQqqyhE7xm6pywEKOM6aqVFLo/aqyImN1EcqQ+ujkf0XPumGtNDXpOto5dPIEr916KVS7huK4InJrU610P3BxGpk9o6Lp4K4gBifUI9Y+eq35hPZuyYNZuotGoxYkglGCgeIZyVKwOM5ppaK+1ucI7/kAHrNl84wG2eY3yWODMhnvryFgkZHThDYTQ1B9l+OjfJoGEqdGK2ZkxEwGkp6VH7/b+6ZdokyCgTrt7FonoLZZxnpFqdnTsvX3EXxzRsLQSCU/FiCjbKjQaVX3QR1zxwwEMPXbiRdLtRDaRUoJYwdfpUakjvfedeisZLT2i71CMIsf9yF/i0n9vPrIuPnHkSkXYRWin5Nzm6T110dPPJd6ws0bgf74gZN/NGe4Vu9CUBfbVOcWcV3H/VFQUn3xbVBlwKR7YP5T6R2CTNTX3X7jV3ItxcC6EGnwarLND x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c086357-2218-44e2-fa19-08d799c6c3a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 14:25:26.0132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CYyH6ZHV4RznOeivvuAxJggPla+B5vOp2JrgjgwMWwAnJDascX4YFut5ZMAQxJbErYNWnyl4hV+pnxv5gI/zC7zOCZiMgoZOu8aWBvAvMkY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3665 Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 14:25:33 -0000 Tomas Many thanks for your feedback and support. My comments are inline below. > Von: Spasm Im Auftrag von Tomas Gustavsson >=20 > I support the adoption of both drafts for further work in the WG. [Bro] Thanks, and many thanks for your review and discussion we had already= . >=20 > My comments on the draft right now: >=20 > 1. I oppose the usage of .well-known URLs in this context. I don't consid= er CMP > end points being in the line of the definition of ..well-known as specifi= ed in > RFC5785. A CMP end point is not meta-data. > If anything .well-known shold be used for discovering the active CMP end = point > urls (see point 2). [Bro] Currently I saw the concept of .well-known URIs in EST and BRSKI. As = far as I understand your concerns, the concept of .well-known URIs should o= nly be used to offer meta-data on the services provided by, e.g., an RA. Su= ch meta-data could than be the list of supported use cases according Sch=FC= ppler the lightweight CMP profile and the list of supported CAs or certific= ate profiles. The format for such meta-data must be specified then too, I g= uess. Is this what you meant? Michael Richardson also gave feedback to the .well-known URIs I specified i= n section 7.1. @Michael, may be you can also bring in your opinion in this tread. Are there further opinions on this? Does anyone has expertise on the requested meta-data approach? >=20 > 2. A single CMP end point url path does not work when servicing multiple = CAs > and use cases. Since real CMP end points are not "serve all everything th= ey ask > for", multiple configurations, access rights and profiles are needed. Tod= ay this > is commonly implemented by different CMP url paths. It is not technically > possible, within the scope of RFC4210, to merge all uses cases into a sin= gle url > path. Any CMP profile should support multiple url-paths. [Bro] I found section 3.2.2 in RFC7030. " 3.2.2. HTTP URIs for Control [...] An EST server MAY provide service for multiple CAs as indicated by an OPTIONAL additional path segment between the registered application name and the operation path. To avoid conflict, the CA label MUST NOT be the same as any defined operation path segment. The EST server MUST provide services regardless of whether the additional path segment is present. The following are three example valid URIs: 1. https://www.example.com/.well-known/est/cacerts 2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts 3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts In this specification, the distinction between enroll and renew/rekey is explicitly indicated by the HTTP URI. When requesting /fullcmc operations, CMC [RFC5272] uses the same messages for certificate renewal and certificate rekey. An EST server can provide additional services using other URIs." What do you think of this approach using an "arbitraryLable" to identify th= e CA or certificate profile that is to be addressed? Would that solve your = problem? >=20 > 3. The multiple url paths defined in 7.1 for different operations is redu= ndant for > CMP, as this information is already in the CMP messages. > CMP works very well with a single url path for all messages and establish= ing a > new scheme will break interoperability, not foster imho. [Bro] Yes, CMP messages types can be easily identified from the body type. = Together with the transactionId of the message headers, the client and serv= er can easily identify the intended uses case. As an example, the paths specified in section 7.1 not directly map with one= specific CMP body type. For example /initialization is a sequence of ir (E= E->RA) and ip (RA->EE) and optionally certConf (EE->RA) and pkiconf (RA->EE= ). In case of an error the error message is sent to terminate the transacti= on. All messages are bundled in a transaction identified by the transaction= Id in the message header. So ir and certConf will both be sent to .well-kno= wn/cmp/initialization. But there is some overlap with /serverkeygen, that uses the same body types= . To spot that this is different, one has to dig quite deep into the certif= icate request to figure out that there is no public key in it.=20 Also the different use cases using support messages cannot be differentiate= d purely by evaluating the body type. Also the infoType field of the genm m= essage body must be taken into account. Actually, I am not decided whether to only specify a .well-known/cmp URI an= d identify the rest from the body type and the transactionId, etc., or a .w= ell-known/cmp/optionalArbitraryLable/path where 'path' clearly identifies t= he use case from the Lightweight CMP Profile and the optional lable directl= y identifies the addressed CA or certificate profile. @Tomas, Michael, what do you think? Are there further opinions on this? >=20 > Regards, > Tomas >=20 >=20 > On 2020-01-07 16:00, Russ Housley wrote: > > There are two CMP-related documents: > > - draft-brockhaus-lamps-cmp-updates > > - draft-brockhaus-lamps-lightweight-cmp-profile > > > > Please indicate whether you support adoption of zero, one, or both of t= hese > documents by the LAMPS WG. Please respond before January 22nd. > > > > Russ > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > > ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik.bro > ck > > > haus%40siemens.com%7Cb6b051019f8247ba2b1908d79428757f%7C38ae3bcd9 > 5794f > > > d4addab42e1495d55a%7C1%7C0%7C637140773796808073&sdata=3Dp7nIO > 8qmA5aH > > ibPuzzxT0ZU7%2BtEum8xK984W87WisLI%3D&reserved=3D0 > > >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik.brockha > us%40siemens.com%7Cb6b051019f8247ba2b1908d79428757f%7C38ae3bcd957 > 94fd4addab42e1495d55a%7C1%7C0%7C637140773796808073&sdata=3Dp7 > nIO8qmA5aHibPuzzxT0ZU7%2BtEum8xK984W87WisLI%3D&reserved=3D0 From nobody Wed Jan 15 06:35:12 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E61120090 for ; Wed, 15 Jan 2020 06:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QzSj1YMsTgE1 for ; Wed, 15 Jan 2020 06:34:35 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2C2120033 for ; Wed, 15 Jan 2020 06:34:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E04CF3897B; Wed, 15 Jan 2020 09:34:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 851C2124A; Wed, 15 Jan 2020 09:34:34 -0500 (EST) From: Michael Richardson To: Tim Hollebeek cc: SPASM In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 14:34:41 -0000 --=-=-= Content-Type: text/plain I have read draft-housley-lamps-cms-update-alg-id-protect, and as I understand it, it simply removes a degree of freedom to select non-identical message digest algorithms. Where there were two choices, they are now constrained to be the same choice. The signal for one of the choices was already protected in a signature, while the other was not. (RFC8366 and BRSKI makes use of 5652 format vouchers, so this matters to me. I am unaware of any ability to choose different algorithms, nor would I want to) I support adopting this document. I am not fond of "patch" documents, but it seems too soon to consider RFC5652bis. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4fIvoACgkQgItw+93Q 3WWrpAf/VL0zK/CfcD0TirOQFt1N5y/Nv95eSUl93NdsXBsUq7PkALtBoewkcbVt tEZpZIkUgCDaRQqTYwoZnHOeYIAsR9WBs0MCyzfUoE4YuD09+sBMH0RQAWGhxrui kQEud0BhpwGuQcuu4hw538BdRslBiBJ1wORuVzsLw1VgEDqI9jKD8MqmrsQOAEMs Nkut/gNwKsN5zshKcqJ/Hux9IlrTlI25tkcAcl92uikEanU4GWpwDXTr0pEnacEx FW1od2L//Rk7YxYGn1lLiKULXQmWSb6p/tquRBUH92BR9JKQHJZJXpn7IFq/D7lO MDtWiZ4QcK6ID1aBnn67zSx8V0zF0w== =bMIo -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 10:40:50 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E441208FF for ; Wed, 15 Jan 2020 10:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NuQYSucibFrR for ; Wed, 15 Jan 2020 10:40:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8FB1208D4 for ; Wed, 15 Jan 2020 10:40:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15B2D3897D; Wed, 15 Jan 2020 13:40:16 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CD45C12A1; Wed, 15 Jan 2020 13:40:42 -0500 (EST) From: Michael Richardson To: "Brockhaus\, Hendrik" cc: LAMPS WG , "steffen.fries\@siemens.com" In-Reply-To: References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> <32139.1578429337@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 18:40:48 -0000 --=-=-= Content-Type: text/plain Brockhaus, Hendrik wrote: >> Von: Spasm Im Auftrag von Michael Richardson >> >> I support adopting - draft-brockhaus-lamps-cmp-updates > [Bro] Thank you for your support! >> >> with the following (non-blocking) comments: * I find that section 3 >> lacks motivation for why it is making these changes. > [Bro] The idea is that New Section 1.1 provides the motivation for the > changes. The other sections should only contain the technical > changes. Does New Section 1.1 is not descriptive enough? lamps-cmp-updates hasn't got a section 1.1 lamps-industrial-cmp-profile-00 has a 1.1, but I didn't read that. lamps-leightweight-cmp-profile hasn't got a 1.1, but a 2.1. I think that your numbering of sections is not what you think it is :-) > the correct tense to use here. Should I say "The following updates are > made in draft-brockhaus-lamps-cmp-updates:" and replace the I think so. >> s/IPSec/IPsec/ {it's the brown M&M of rfc4301} >> >> section 2.6 says: "Chapter 2", so I think the references are all >> dangling. XML2rfc deals with tis for you, so I'm guessing you aren't >> using here? > [Bro] You are right, I will change this to and Section x. BTW: > Should I always use Section instead of Chapter in this document? In > later sections I referred to the top-level structure as Chapters and > subsections as Section. The xref will usually expand as Section x.y.z. > There is also some explanation at the beginning of section 7 on this. > The CMP messages are designed to be self-contained, such that in > principle any transport can be used. HTTP SHOULD be used for online > transport while file-based transport MAY be used in case offline > transport is required. In case HTTP transport is not desired or > possible, CMP messages MAY also be piggybacked on any other reliable > transport protocol, e.g., CoAP [RFC7252]. > Is this more what you were looking for? Should I also add some more > description in section 3.4?. Works for me. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4fXKoACgkQgItw+93Q 3WXfPQf/afCNiGVXdH5d7Fpv8A/faqFGThe6u+Xel3odzpaeppcX6xamu83E2AgD 6Ni/TOTjgqE8WJmnNL9dCQqSAdJqu7uyHwJgpKp22LOmwi5nLX7Fxol3hAdBVJDG wmO73MviWzU1k9+e70OkGqkjnQbQ6SN3Cj0t923nF/Dxuj8rs8Cy51VMMFpzx6Dd RxXgyhK9tI9JGfw1ujrMpRwBPSOuzr3mtbjasDW2cYRQNdKnAZWa1yzFGoIwMeHY htaodkEEiQ1AhZdItbP5Q23w0tpvi1T1cXgWwnN6/M+oIa7F1n0w+cYaRAQHimMf ITMTk5IaWJMcpuL4fbiouFUB62qlJA== =hLhE -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 19:20:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F83120803 for ; Wed, 15 Jan 2020 19:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com 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 sz7YNSyw7Qxo for ; Wed, 15 Jan 2020 19:20:49 -0800 (PST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DE2120058 for ; Wed, 15 Jan 2020 19:20:49 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id l14so8436432qvu.12 for ; Wed, 15 Jan 2020 19:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1MWfLDma2zJZHjkwuUX6wnlO3L5ZhwyWP4OombtJMy0=; b=SUhusf+oo2BBpGxG72hIqEC2u64EhMickN3l6OgE+s8OGLLm7zJ2lq/cCjWjVT5UKU 4AzQuMnr5uA5Pp1SPtyeRYNkBwvVDDs75rXwKTQ5/58uD0d3K5MP7LVFnvuXEI5ziYEy 1BdBXNdjWg9BpgooJP7wncuiSUFW09592vdzomOK8M9Rv+X5D02vp2lPTrsByIDCaxfa sQV0F09MmXbOgtvfvSYPxNpTF5b7Mpr7NQuA/86ta2Vn2xE8AaZz60hyFHN4Z7sPtGLb rDslkVfkKSOLhVrXZX6wgx9/XYwEFW4FpecZeOgd1IuAM3lulHG4bKur25x4PvP377gy gzrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1MWfLDma2zJZHjkwuUX6wnlO3L5ZhwyWP4OombtJMy0=; b=Bc1SaGi8/jqY0bX3cZth0vpCEBfr3yMukDefxQ6EcXLie8e5LmKzjry71868PreMgH wBZq4thrqZrzXzkSy6l+86KMgwLkgkjPlqX7zrKWrvgb7eGzJFejG7SPoRh1sXJE8Csg HEh9mokcM1WdCWfwCPG2jA/083fIOcGdq+fCddjLJdxC8n9SItnQSeO56w8uh7+KCA0G ixNog5huIq/QaxqxpIMwLMaUAQWMctsW8vQDNosbfJ850XMsYiM+EeAVYgjDQAWYzoz/ a+QKB+wpmeV/QbbPmjEHdTeuYVi8PJyfnfEYbTEgN7IRjYJ5pG+vyGy2YHMUsR5uzbP2 puuA== X-Gm-Message-State: APjAAAU4MgyLzWT2IRfMrTJvnjfQNA4pm8ZTxP4NX5ok+kDX2y1lEWV/ hC3GbIcOjIrKL7VqzbJaIUAlXrdOu6Gz0skV2Lup4Q== X-Google-Smtp-Source: APXvYqzmbSJenMBkad+bhIZBGPklDYGvsOFsC858BP6V/qmvhXi4rAQ+PUtAwQdwf7IJ2KKuPCsO7cPWUNFIfRmIXQY= X-Received: by 2002:a0c:eed2:: with SMTP id h18mr603761qvs.184.1579144848386; Wed, 15 Jan 2020 19:20:48 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> In-Reply-To: From: Joseph Salowey Date: Wed, 15 Jan 2020 19:20:37 -0800 Message-ID: To: Alan DeKok Cc: Michael Richardson , "spasm@ietf.org" , EMU WG Content-Type: multipart/alternative; boundary="000000000000bcbff5059c394fbb" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 03:20:52 -0000 --000000000000bcbff5059c394fbb Content-Type: text/plain; charset="UTF-8" There has been a lot of discussion on this thread, but I do not see anything actionable for the EAP-TLS 1.3 specification. Joe On Wed, Jan 8, 2020 at 12:48 PM Alan DeKok wrote: > On Jan 8, 2020, at 3:00 PM, Michael Richardson > wrote: > > > > > > Alan DeKok wrote: > > alan> Many people use private CAs. Many use public CAs. *All* of > them > > alan> use id-kp-serverAuth. Common EAP supplicants (MS / Apple / > etc.) > > alan> ship with known root CAs. These root CAs are trusted by default > > alan> for web browsing. None are trusted by default for EAP. > > > > How can anyone be using public CAs for EAP, if none are trusted for EAP, > and no > > public CAs issue certificates with id-kp-serverAuth? > > Every CA is manually enabled. > > Either by an end user, or by / on behalf of, an administrator. > > The goal I'd like to reach is some method to allow supplicants to > automatically trust and enable certificates for EAP. > > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --000000000000bcbff5059c394fbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There has been a lot of discussion on thi= s thread, but I do not see anything actionable for the EAP-TLS 1.3 specific= ation.=C2=A0=C2=A0

Joe

On Wed, Jan 8, 2= 020 at 12:48 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jan 8, 2020, at 3:00 PM, Michael Richardson &l= t;mcr+ietf@san= delman.ca> wrote:
>
>
> Alan DeKok <aland@deployingradius.com> wrote:
>=C2=A0 =C2=A0 alan> Many people use private CAs.=C2=A0 Many use publ= ic CAs.=C2=A0 *All* of them
>=C2=A0 =C2=A0 alan> use id-kp-serverAuth.=C2=A0 Common EAP supplican= ts (MS / Apple / etc.)
>=C2=A0 =C2=A0 alan> ship with known root CAs.=C2=A0 These root CAs a= re trusted by default
>=C2=A0 =C2=A0 alan> for web browsing.=C2=A0 None are trusted by defa= ult for EAP.
>
> How can anyone be using public CAs for EAP, if none are trusted for EA= P, and no
> public CAs issue certificates with id-kp-serverAuth?

=C2=A0 Every CA is manually enabled.

=C2=A0 Either by an end user, or by / on behalf of, an administrator.

=C2=A0 The goal I'd like to reach is some method to allow supplicants t= o automatically trust and enable certificates for EAP.

=C2=A0 Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--000000000000bcbff5059c394fbb-- From nobody Wed Jan 15 20:07:32 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB2D120855; Wed, 15 Jan 2020 20:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EozK5G9qKxBZ; Wed, 15 Jan 2020 20:07:24 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A7012002F; Wed, 15 Jan 2020 20:07:23 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00G47GIU009898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jan 2020 23:07:18 -0500 Date: Wed, 15 Jan 2020 20:07:15 -0800 From: Benjamin Kaduk To: Joseph Salowey Cc: Alan DeKok , "spasm@ietf.org" , Michael Richardson , EMU WG Message-ID: <20200116040715.GC80030@kduck.mit.edu> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 04:07:26 -0000 A couple things that stand out to me from having basically read the whole thread in one go (this is not intended to be an exhaustive list of open questions): It was implied but not fully clear to me, that Ryan thinks that someone so inclined could, right now, go around trying to connect to wifi using EAP authentication, grab a packet capture of the remote server using its id-kp-serverAuth certificate for authenticating the TLS-over-EAP connection, and report that certificate to its issuing CA as "misuse" requiring prompt revocation, at least for several major CAs. It's quite probably that I missed them as they went by, but specific links to specific CA policy documents that would classify such certificate usage as "misuse" (requiring revocation) would help clarify things, at least for me. Is there anything better for implementations to actually do (as distinct from what we write down as recommendations) than to start setting up a parallel (purpose-specific) PKI now and trusting that in parallel with what they're currently doing, with the hope of being able to have a flag day many years down the line when the new PKI becomes the only thing that's trusted? -Ben On Wed, Jan 15, 2020 at 07:20:37PM -0800, Joseph Salowey wrote: > There has been a lot of discussion on this thread, but I do not see > anything actionable for the EAP-TLS 1.3 specification. > > Joe > > On Wed, Jan 8, 2020 at 12:48 PM Alan DeKok > wrote: > > > On Jan 8, 2020, at 3:00 PM, Michael Richardson > > wrote: > > > > > > > > > Alan DeKok wrote: > > > alan> Many people use private CAs. Many use public CAs. *All* of > > them > > > alan> use id-kp-serverAuth. Common EAP supplicants (MS / Apple / > > etc.) > > > alan> ship with known root CAs. These root CAs are trusted by default > > > alan> for web browsing. None are trusted by default for EAP. > > > > > > How can anyone be using public CAs for EAP, if none are trusted for EAP, > > and no > > > public CAs issue certificates with id-kp-serverAuth? > > > > Every CA is manually enabled. > > > > Either by an end user, or by / on behalf of, an administrator. > > > > The goal I'd like to reach is some method to allow supplicants to > > automatically trust and enable certificates for EAP. > > > > Alan DeKok. > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Jan 16 02:24:09 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B1D120072 for ; Thu, 16 Jan 2020 02:24:07 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=p6NRIHqy; dkim=pass (1024-bit key) header.d=primekey.com header.b=p6NRIHqy 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 WjdFhoo97aJd for ; Thu, 16 Jan 2020 02:24:03 -0800 (PST) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A5E120048 for ; Thu, 16 Jan 2020 02:24:02 -0800 (PST) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 9BA7E6AA0093; Thu, 16 Jan 2020 11:23:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1579170227; bh=DqGn8HtKOCI7Bx7Fvnk/JiU/9OkemTEj3kcxeCmrvPw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=p6NRIHqy02JRu9iVeKgWmLK02ngsMlS9F6pSc4LwIJSF+Dw+ytMBbzIMiHIrD5xF5 3GkBKz1oqN13r7ZMVlQ+3T1344XuuPAFGGnKrHQ5EkG9nmmak3pjmW7xKv7UKx+QG5 Uf5PKnrG3px3TaYD+eqEwvVsfos05A/fHdkb8+I8= Received: from [192.168.3.139] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 7A8B36AA0092; Thu, 16 Jan 2020 11:23:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1579170227; bh=DqGn8HtKOCI7Bx7Fvnk/JiU/9OkemTEj3kcxeCmrvPw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=p6NRIHqy02JRu9iVeKgWmLK02ngsMlS9F6pSc4LwIJSF+Dw+ytMBbzIMiHIrD5xF5 3GkBKz1oqN13r7ZMVlQ+3T1344XuuPAFGGnKrHQ5EkG9nmmak3pjmW7xKv7UKx+QG5 Uf5PKnrG3px3TaYD+eqEwvVsfos05A/fHdkb8+I8= To: "Brockhaus, Hendrik" , "spasm@ietf.org" , Michael Richardson References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Thu, 16 Jan 2020 11:23:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 10:24:08 -0000 On 2020-01-15 15:25, Brockhaus, Hendrik wrote: > Tomas > > Many thanks for your feedback and support. > My comments are inline below. > >> Von: Spasm Im Auftrag von Tomas Gustavsson >> >> I support the adoption of both drafts for further work in the WG. > [Bro] Thanks, and many thanks for your review and discussion we had already. > >> >> My comments on the draft right now: >> >> 1. I oppose the usage of .well-known URLs in this context. I don't consider CMP >> end points being in the line of the definition of ..well-known as specified in >> RFC5785. A CMP end point is not meta-data. >> If anything .well-known shold be used for discovering the active CMP end point >> urls (see point 2). > [Bro] Currently I saw the concept of .well-known URIs in EST and BRSKI. As far as I understand your concerns, the concept of .well-known URIs should only be used to offer meta-data on the services provided by, e.g., an RA. Such meta-data could than be the list of supported use cases according Schüppler the lightweight CMP profile and the list of supported CAs or certificate profiles. The format for such meta-data must be specified then too, I guess. Is this what you meant? Yes. I admit to have limited experience of good usage of .well-known though. > Michael Richardson also gave feedback to the .well-known URIs I specified in section 7.1. > @Michael, may be you can also bring in your opinion in this tread. > > Are there further opinions on this? > Does anyone has expertise on the requested meta-data approach? > >> >> 2. A single CMP end point url path does not work when servicing multiple CAs >> and use cases. Since real CMP end points are not "serve all everything they ask >> for", multiple configurations, access rights and profiles are needed. Today this >> is commonly implemented by different CMP url paths. It is not technically >> possible, within the scope of RFC4210, to merge all uses cases into a single url >> path. Any CMP profile should support multiple url-paths. > [Bro] I found section 3.2.2 in RFC7030. > " 3.2.2. HTTP URIs for Control > > [...] > > An EST server MAY provide service for multiple CAs as indicated by an > OPTIONAL additional path segment between the registered application > name and the operation path. To avoid conflict, the CA label MUST > NOT be the same as any defined operation path segment. The EST > server MUST provide services regardless of whether the additional > path segment is present. The following are three example valid URIs: > > 1. https://www.example.com/.well-known/est/cacerts > > 2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts > > 3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts > > In this specification, the distinction between enroll and renew/rekey > is explicitly indicated by the HTTP URI. When requesting /fullcmc > operations, CMC [RFC5272] uses the same messages for certificate > renewal and certificate rekey. > > An EST server can provide additional services using other URIs." > > What do you think of this approach using an "arbitraryLable" to identify the CA or certificate profile that is to be addressed? Would that solve your problem? Yes the arbitraryLabel is the approach we use currently, both for EST and for CMP in fact. I think that works well. > >> >> 3. The multiple url paths defined in 7.1 for different operations is redundant for >> CMP, as this information is already in the CMP messages. >> CMP works very well with a single url path for all messages and establishing a >> new scheme will break interoperability, not foster imho. > [Bro] Yes, CMP messages types can be easily identified from the body type. Together with the transactionId of the message headers, the client and server can easily identify the intended uses case. > As an example, the paths specified in section 7.1 not directly map with one specific CMP body type. For example /initialization is a sequence of ir (EE->RA) and ip (RA->EE) and optionally certConf (EE->RA) and pkiconf (RA->EE). In case of an error the error message is sent to terminate the transaction. All messages are bundled in a transaction identified by the transactionId in the message header. So ir and certConf will both be sent to .well-known/cmp/initialization. > But there is some overlap with /serverkeygen, that uses the same body types. To spot that this is different, one has to dig quite deep into the certificate request to figure out that there is no public key in it. > Also the different use cases using support messages cannot be differentiated purely by evaluating the body type. Also the infoType field of the genm message body must be taken into account. > > Actually, I am not decided whether to only specify a .well-known/cmp URI and identify the rest from the body type and the transactionId, etc., or a .well-known/cmp/optionalArbitraryLable/path where 'path' clearly identifies the use case from the Lightweight CMP Profile and the optional lable directly identifies the addressed CA or certificate profile. > > @Tomas, Michael, what do you think? Thanks. It was not clear (to me) the full meaning of the label paths described. Do you mean that multiple messages could be bundled? Or just that each path would enforce a specific work-flow? I.e. server key gen is not allowed in /initialization for example? > Are there further opinions on this? > >> >> Regards, >> Tomas >> >> >> On 2020-01-07 16:00, Russ Housley wrote: >>> There are two CMP-related documents: >>> - draft-brockhaus-lamps-cmp-updates >>> - draft-brockhaus-lamps-lightweight-cmp-profile >>> >>> Please indicate whether you support adoption of zero, one, or both of these >> documents by the LAMPS WG. Please respond before January 22nd. >>> >>> Russ >>> >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >>> >> ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.bro >> ck >>> >> haus%40siemens.com%7Cb6b051019f8247ba2b1908d79428757f%7C38ae3bcd9 >> 5794f >>> >> d4addab42e1495d55a%7C1%7C0%7C637140773796808073&sdata=p7nIO >> 8qmA5aH >>> ibPuzzxT0ZU7%2BtEum8xK984W87WisLI%3D&reserved=0 >>> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf. >> org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockha >> us%40siemens.com%7Cb6b051019f8247ba2b1908d79428757f%7C38ae3bcd957 >> 94fd4addab42e1495d55a%7C1%7C0%7C637140773796808073&sdata=p7 >> nIO8qmA5aHibPuzzxT0ZU7%2BtEum8xK984W87WisLI%3D&reserved=0 From nobody Thu Jan 16 12:56:53 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FCF12008D; Thu, 16 Jan 2020 12:56: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HwkQQlnRsazY; Thu, 16 Jan 2020 12:56:42 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853CC120026; Thu, 16 Jan 2020 12:56:42 -0800 (PST) Received: from [192.168.20.221] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id 58107D8D; Thu, 16 Jan 2020 20:56:39 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: <20200116040715.GC80030@kduck.mit.edu> Date: Thu, 16 Jan 2020 15:56:37 -0500 Cc: Joseph Salowey , "spasm@ietf.org" , Michael Richardson , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <07F783A9-96C0-4E75-91AB-898F9EDF028D@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 20:56:45 -0000 On Jan 15, 2020, at 11:07 PM, Benjamin Kaduk wrote: > Is there anything better for implementations to actually do (as = distinct > from what we write down as recommendations) than to start setting up a > parallel (purpose-specific) PKI now and trusting that in parallel with = what > they're currently doing, with the hope of being able to have a flag = day > many years down the line when the new PKI becomes the only thing = that's > trusted? I don't think so. It's common practice to use private CAs. Usually, self-signed ones. One major driver for private CAs was initially that EAP supplicant = implementations did not cache the server certificate. So if the = supplicant trusted a root CA, it trusted *all* certificates issued by = that root CA. Which was a major security issue. Supplicants now cache the server certificate, even if they trust the = root CA. This lets them warn the user if the server certificate = changes. But this process also means that the user is warned on normal = certificate expiration / replacement. There is currently no guidance to = implementations as to what should be done here. Alan DeKok. From nobody Thu Jan 16 13:02:19 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE0712009C; Thu, 16 Jan 2020 13:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=FuuWH6r2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BIPo3KOD 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 V_Wr-Q_aRbx1; Thu, 16 Jan 2020 13:02:06 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22C61200B4; Thu, 16 Jan 2020 13:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3755; q=dns/txt; s=iport; t=1579208526; x=1580418126; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wkA5ZoFEnBi0db+Uz+y9DFIB/DMRQW27FcwWZglHAqI=; b=FuuWH6r2Qw2j3OLe+JAUMx9zuDrv5esj+jTcbZbWX2ZTgekEaJ6uCLJZ RKuhcIvkuGYeNrLSObTA2hS9Zaz9wBkiQaBuBRYIPDP8DK/mo7/DnTxIt Sz/UuQ41OIYW2eHyU0kykJF8ak2SrL4BBb24uEzS/O6h9a5M1lef0a0pS s=; IronPort-PHdr: =?us-ascii?q?9a23=3ASKy9LBc/5p37MTspF9qAdnBhlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKZD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/Yig3Fd5qX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AABvziBe/4YNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWcHAQELAYEkL1AFgTwIIAQLKodWA4Rahh+WC4RigS6BJANUCQE?= =?us-ascii?q?BAQwBAS0CAQGEQAKCAiQ0CQ4CAw0BAQQBAQECAQUEbYU3DIVfAgQSLgEBNwE?= =?us-ascii?q?PAgEIBDsHMhQRAgQOBSKDBIF+TQMuAaFKAoE5iGGCJ4J/AQEFhSkYgg0JgTY?= =?us-ascii?q?BjBsagUE/gREnIIJMPoQzg1iCLJYvmSEKgjmWMBuacIINhBGjQgIEAgQFAg4?= =?us-ascii?q?BAQWBUjmBWHAVZQGCQVAYDYgBg3OKU3SBKYoAAiYCBYE1XwEB?= X-IronPort-AV: E=Sophos;i="5.70,327,1574121600"; d="scan'208,217";a="406880613" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jan 2020 21:02:05 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 00GL24w2030434 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jan 2020 21:02:04 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 Jan 2020 15:02:03 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 Jan 2020 15:02:02 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 16 Jan 2020 15:02:02 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BJaj4H6Wc8Ka2NBAWnz7ksedneT2LXiEHR8mI+08BHjE1/+85q1qhIbhnePE0H4wcTqiWk4LOW84JM5KZIQCBNiC28MDDyTZxkOiD5fEkGpzxxMFHruXko6nztN1DQ6M9ivrhzj94WB5A1pp9O3STMlIU/F8R9FpD438ypFG3YV8SITiPLhQeK0hku5GqAeThZbzfClrXtqakRpeUvCM16Wz3YY6IJD+7exi6UxpEK39zKSbE3xU+Vrwj00dxyczc/oDCLFW2n4gAqv/mEaOQM8J4+5R0DRoNErzx376S2r9p35oP+WAlz42rWh7B7gGZdtyZyvmtHJ6Aqkh7V098A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i3W2Z6FH41FMhct7iAbLWXjDqNJ78XLjiuBRWST4kN4=; b=ZfSrc3EvpiqebA3CUfg9xJfDgIn6g3JDQCeptq+SG9O+ZtXXOvHoa7SiffEp2RrSr/oON6W5f1VFGNvWvD9BYpA6Mpd1lD1gF6uEeDGCcuOlLi6SmGsjF3jTCoPV/OR46UMm2cbyvyFGu1jwIbDB8EvBhCfTWrwRGkFNOzkRwWIm44YnCSSCoIhUVkHePB6i2F5zK431rcLqysehw0pqwJ4F1XrfLSwBGx5Tb/qfOpllJQRDiJyvwUrSuid0Lfqt5/l35NDSik++BOiH8jTGs3ImuSLQLmw+CTfI7t2T9TzKa8ukGTM7jmB5427L+w9wHvvUMkeUDEOPUtXR6kuQQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i3W2Z6FH41FMhct7iAbLWXjDqNJ78XLjiuBRWST4kN4=; b=BIPo3KOD6uxzHGHoBfI4uPLt4SD50xC1GoFRPLhwq2+6Wd6MdQGW7CIOPnoCufEDM6093pg6ohvo9MXvnlcvOcfyK00nY/dfUHlJlHLUDG3w6bfDzOhg2KvrC/sSnceZpmx7k1PFoIpMAhT3BEpkzommxC1hhK+MbkzSg3aj0bQ= Received: from DM6PR11MB3995.namprd11.prod.outlook.com (10.255.61.204) by DM6PR11MB3770.namprd11.prod.outlook.com (20.178.231.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Thu, 16 Jan 2020 21:02:01 +0000 Received: from DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5]) by DM6PR11MB3995.namprd11.prod.outlook.com ([fe80::594a:23a:5e3:34e5%7]) with mapi id 15.20.2644.015; Thu, 16 Jan 2020 21:02:01 +0000 From: "Eliot Lear (elear)" To: Ryan Sleevi CC: Alan DeKok , "spasm@ietf.org" , EMU WG Thread-Topic: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic Thread-Index: AdWxNKzqTmo8NKHtQwSIp+NEgFXHNACbMPUABHRvF7QAAZ7ogAABuFUAAAClZwAAAxLIAAACFEUAAAKfAIAACUx2AAAM8UWAAAqZWwAAAp5ngAACZccAAAHKXAABm9jfAA== Date: Thu, 16 Jan 2020 21:02:01 +0000 Message-ID: <48C23DF2-C578-482B-BCC3-69AABDAF983F@cisco.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <10F5CCFB-7DBD-40DF-9C65-BCD0EB8CB838@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-originating-ip: [2001:420:c0c0:1006::84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bbcdff21-8d7f-4b0e-0e44-08d79ac75523 x-ms-traffictypediagnostic: DM6PR11MB3770: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(376002)(396003)(39860400002)(136003)(189003)(199004)(66446008)(66556008)(2616005)(81166006)(81156014)(53546011)(6506007)(8676002)(64756008)(478600001)(6486002)(33656002)(86362001)(5660300002)(71200400001)(2906002)(54906003)(316002)(91956017)(76116006)(4326008)(6916009)(186003)(6512007)(8936002)(36756003)(66476007)(4744005)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3770; H:DM6PR11MB3995.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ws41OLRnvfu4wGPDyVtYK3rGFLajWwHoXPFFc21wRbZqLamzQWEunwccAoVfChj4WtuV7ADJY1kqVqoGnH4gNseJkyl4uwaxzbHy8EmXOL9GdKb+HVM5olXHO0Wps7+PXdtEP50eSHXfWTSPwNgVmifTQQvbm2ZPM1ECbsQt+AR640x7oFK9veqMit7OPchR5t4jfOh4JL6PWbaIf//GKuS4GgC0y0oJ7ccwdSzWEfUwt6PRmlBlMDuEA8eAydaT/7FyV+yyTfMkyY96UW7hjb1zEXjd8kKuBqgY7HhZhFNClU5rgnwPbqXiX3MpEoQWh6kHXRHVNJ4ID0+Jp5ejZz47Eu92J2wfz9xMk28D2lJvba4e61qn7LSvV0nWObhwZzAFg86YTIgi8eJRQDNP85iEC+IHVf+gf0aPg2WrCCuS9it3g01uklxhw8tcPvB6 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_48C23DF2C578482BBCC369AABDAF983Fciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bbcdff21-8d7f-4b0e-0e44-08d79ac75523 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2020 21:02:01.2585 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 97xcrO8jBFHlEDXNxNPhX6r+51MCSFNAJ8NOFOkHRApBVzZCxp9riHvGfk4BSXmI X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3770 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 21:02:12 -0000 --_000_48C23DF2C578482BBCC369AABDAF983Fciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 8 Jan 2020, at 17:29, Ryan Sleevi > wrote: The CA must revoke if the certificate is misused; that's required by contra= ct. The CA defines what misuse means. A number of CAs define misuse as "used for purposes other than TLS web serv= er" Ergo, obtaining and using certificates with EAP means these certificates ar= e at risk of revocation. Ok not for nothing but this is getting silly. If a CA actually revoked a c= ert for someone using it for EAP, would they also have to revoke for someon= e using it for SMTP, XMPP, and IMAP? Has that ever happened? Eliot --_000_48C23DF2C578482BBCC369AABDAF983Fciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

On 8 Jan 2020, at 17:29, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:


The CA must revoke if the certificate is misused; that's required by contra= ct.
The CA defines what misuse means.
A number of CAs define misuse as "used for purposes other than TLS web= server"
Ergo, obtaining and using certificates with EAP means these certificates ar= e at risk of revocation.

Ok not for nothing but this is getting silly.  If a CA= actually revoked a cert for someone using it for EAP, would they also have= to revoke for someone using it for SMTP, XMPP, and IMAP?  Has that ev= er happened?

Eliot
--_000_48C23DF2C578482BBCC369AABDAF983Fciscocom_-- From nobody Thu Jan 16 14:52:37 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB541200B1; Thu, 16 Jan 2020 14:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 p6FM1Xzg7VEC; Thu, 16 Jan 2020 14:52:34 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF677120099; Thu, 16 Jan 2020 14:52:33 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 752F9962; Thu, 16 Jan 2020 22:52:31 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: <48C23DF2-C578-482B-BCC3-69AABDAF983F@cisco.com> Date: Thu, 16 Jan 2020 17:52:29 -0500 Cc: Ryan Sleevi , "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <10F5CCFB-7DBD-40DF-9C65-BCD0EB8CB838@deployingradius.com> <48C23DF2-C578-482B-BCC3-69AABDAF983F@cisco.com> To: "Eliot Lear (elear)" X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 22:52:36 -0000 On Jan 16, 2020, at 4:02 PM, Eliot Lear (elear) wrote: >=20 > Ok not for nothing but this is getting silly. Yes. > If a CA actually revoked a cert for someone using it for EAP, would = they also have to revoke for someone using it for SMTP, XMPP, and IMAP? That is apparently the claim. > Has that ever happened? I have no idea. Perhaps we should try? $ openssl s_client -connect smtp.mozilla.org:587 -starttls smtp > = mozilla.crt $ openssl x509 -text -in mozilla.crt ... X509v3 Subject Alternative Name: DNS:smtp1.mdc1.mozilla.com, = DNS:smtp1.private.mdc1.mozilla.com, DNS:smtp1.private.mdc2.mozilla.com, = DNS:smtp.mozilla.com, DNS:smtp.mozilla.org, DNS:smtp1.mdc2.mozilla.com X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client = Authentication ... Yup. *Everyone* uses id-kp-serverAuth. For *everything*. Should we report this mis-use? If so, why? If not, why not? At this point, it might be simplest to just update 2459: ... id-kp-serverAuth OBJECT IDENTIFIER ::=3D {id-kp 1} -- TLS Web server authentication ... new ID: delete the word "Web". Alan DeKok. From nobody Thu Jan 16 23:29:29 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BD0120273 for ; Thu, 16 Jan 2020 23:29:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 beeRyOX10REe for ; Thu, 16 Jan 2020 23:29:23 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2075.outbound.protection.outlook.com [40.107.21.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D18F120236 for ; Thu, 16 Jan 2020 23:29:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jdb0LN6iJaG6w8tCwuTqjgCvSxic1mHcaPWOffWRj/Uv7vOa3v4ZAAAOWbxSVljZ1MWxAzIFJq9B1qsItKgWGPArlMRW/HhwCqgpXuR5YQJBSbSCNAsj/io1ODI+UNHlkjzNNVCXyuAFxch5/04k1xoR1UV/9QjaEjz021oFwIvBQf8R+OtNVCuGXr811ITcbyzzmm3QsO+nWA/UsGpmoGukE3NoEog9/gIzarf1KG7jlIWVhNIsj/WYsUzWV35koyXsQyI+slSiiQ5Fp77eimFl+p5SUmu0XD33yDpPeQNyVcKSMKcW/lONipwuo3SIFKjTeZxwCxIhypbjbUYzHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uVhbgeCNqado2jEaBs/ZKd0QVyyWvotBl6mevQabeaw=; b=Qt/kKLOVj8dqRjnTx+WpIYD6aIIiFjCXBUoTzy4le9sTZYayIXpVy+8Rh2X6ckJVYQZ+gZiVIlL5l9bSEr5rOvf3pm8JKjI9IikKtIyJbYEUzbLill8bP2HycSq+pjCnz++MlC5ylmhCydX9iKxFrhsjrprIYkRqPB7gQBW7mcdqqMf5srDQybdJDdrE9rPDc1V+aAC2DMDLfRMaurnfwh8JZlot7/7vAQGqHrBRLxRnRbhATAmLN/rp3/HhhgLl7DZUuyzdv9J5f6+lLhtdUq5uZP1yv9V3czaCMkKdPNbOVkzmCgq/PNYWZRrm8sLnL7vf9+X9pOl9DCsczGzVmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uVhbgeCNqado2jEaBs/ZKd0QVyyWvotBl6mevQabeaw=; b=foJ1YGWV+g4csyxxbQBmXV9DUL4b2bnYvkZQqVPKt73p2qOIRVgVVfyXVpM/LZL/F753NVNnwhNaqum4FjBfn9c6SN99KRFU+QdIk9KBe2slSEx2S9cROGanGp7SW+OnVtTYXxCF0GIca8GfHcaQ1AtgPf0l6RHKXBeJbqoL5Tw= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2211.EURPRD10.PROD.OUTLOOK.COM (20.177.109.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 17 Jan 2020 07:29:19 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a059:85c0:8cba:4b1b]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a059:85c0:8cba:4b1b%6]) with mapi id 15.20.2644.015; Fri, 17 Jan 2020 07:29:19 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson CC: LAMPS WG , "steffen.fries@siemens.com" Thread-Topic: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile Thread-Index: AQHVxWtJYB0uOyHDaUK+bxSA9eNMy6ffqTKAgAurkbCAAMb6AIACZWnw Date: Fri, 17 Jan 2020 07:29:19 +0000 Message-ID: References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> <32139.1578429337@localhost> <29986.1579113642@localhost> In-Reply-To: <29986.1579113642@localhost> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [195.145.170.173] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1b0f939a-5928-4461-b522-08d79b1ef77d x-ms-traffictypediagnostic: AM0PR10MB2211:|AM0PR10MB2211: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(396003)(346002)(376002)(199004)(189003)(54906003)(76116006)(71200400001)(316002)(66476007)(66946007)(107886003)(64756008)(4326008)(66446008)(9686003)(66556008)(55016002)(478600001)(8676002)(5660300002)(52536014)(8936002)(81166006)(81156014)(6506007)(2906002)(186003)(33656002)(86362001)(7696005)(15650500001)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2211; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BCwbUj7A5nwupMC1/T2o32tfZSxGHbLdCale6REaNpVAlyoZyFgZlJZEt3LJedm2vy/BbvZR558kvPoJlINNMoXFUXbaOq8XO92YxMuJWNMvult0WEYYQILyh/hTboiZhbyFSp+lmnwoSLfmDaIRI/tGK9XVvTm9L6tJx7MyktBdSqPp/DcKOMhGpHU1Wr/H7jj3tRPcXXBEpuiDpSPGs6sIPNv7JbwNUhIdyFF9LHwoCoaVfnnhLJoel6uWoLeOF6iPVuS61gZ+hPWrEroOYJaG2+9jp990nbtT6zvQSLKRBsoItOWOtGohDDblAoubTQJH8r6HO0lQr+SdoM2XstLjv3dPoarLp2FGkCuMKT9np8lvqHVlR9bDRd7KxWFAva6fsiljRDGrWUo7nlM4a5xq7h4BtJzd2s0n7RVQ4uJ7gGAnI5+YBddWfr3KO1Pf Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b0f939a-5928-4461-b522-08d79b1ef77d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 07:29:19.8500 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8jDh36GOHO/NEnc1CfVlEsCUZoGrZC080zXJP/h7grTkV3Ck6/IqDGAVcGkam0PSzssRafpKy1NO05wyLP/jpcQU0F5qlfqXNwf0E07os4s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2211 Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 07:29:28 -0000 > Von: Spasm Im Auftrag von Michael Richardson >=20 > Brockhaus, Hendrik wrote: > >> Von: Spasm Im Auftrag von Michael > Richardson > >> > >> I support adopting - draft-brockhaus-lamps-cmp-updates > > [Bro] Thank you for your support! >=20 > >> > >> with the following (non-blocking) comments: * I find that section = 3 > >> lacks motivation for why it is making these changes. >=20 > > [Bro] The idea is that New Section 1.1 provides the motivation for = the > > changes. The other sections should only contain the technical > > changes. Does New Section 1.1 is not descriptive enough? >=20 > lamps-cmp-updates hasn't got a section 1.1 > lamps-industrial-cmp-profile-00 has a 1.1, but I didn't read that. > lamps-leightweight-cmp-profile hasn't got a 1.1, but a 2.1. > I think that your numbering of sections is not what you think it is :-) [Bro] Sorry for the confusion! What I was referring to was draft-brockhaus-lamps-cmp-updates-02 section 3.= 1 with the title " New Section 1.1. - Changes since RFC 4210". >=20 > > the correct tense to use here. Should I say "The following updates = are > > made in draft-brockhaus-lamps-cmp-updates:" and replace the >=20 > I think so. [Bro] Thanks, I will change it accordingly. >=20 >=20 > >> s/IPSec/IPsec/ {it's the brown M&M of rfc4301} > >> > >> section 2.6 says: "Chapter 2", so I think the references are all > >> dangling. XML2rfc deals with tis for you, so I'm guessing you are= n't > >> using here? > > [Bro] You are right, I will change this to and Section x. B= TW: > > Should I always use Section instead of Chapter in this document? I= n > > later sections I referred to the top-level structure as Chapters an= d > > subsections as Section. >=20 > The xref will usually expand as Section x.y.z. [Bro] So I will always use the term 'section' and not 'chapter'. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works - > =3D IPv6 IoT consulting =3D- =20 Hendrik Brockhaus Siemens AG Corporate Technology Research in Digitalization and Automation Security Architecture mailto:hendrik.brockhaus@siemens.com From nobody Fri Jan 17 02:40:56 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55542120119 for ; Fri, 17 Jan 2020 02:40:54 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com 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 icOr-KjG6gpN for ; Fri, 17 Jan 2020 02:40:49 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20605.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::605]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39108120047 for ; Fri, 17 Jan 2020 02:40:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DCQGQv6VF0XpIAPwhJzUkWnLE9WSrSPJO6RD+4Cl5DJDVoMgtIcvd+ZwcZ4vmDjERjlLaK7jtalPDk534KfgyJW7FWR/nQoWSWqDMn9Bxx70e9Kex/ZsnPS3k0Wkj+Bc4X4AHG3+Mk16VFLWXaHLu/p6n6+DYxie8xsiFg2I2oTT8fYTFVbg+dGlVAorVONcYpScDxXfu0FHrVwc/ecSHjfvVKDYLZ6WkHANVksmUQ4xT/+G6CeWKsNvVk4oZT7+Di4aAbJPz6v9ih682lCZh7FxSi1iCeUsLTgd6kCQf7ygS/ehYEnCcwasUjYqzBTTF7Ss4uCqxZLjQmpGrketIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4HkzvbC81GVKJQ6zVLbaiEuPxDsUZstQij1HWUWYw+0=; b=CLxu7i4XDY5a4hRo7AP8YLT3YAgiMLHLIObD+6yqKDDKZQW7TUAd5uSDsYyYXOPwLMCZELyDZt6Vv7YK30mUJpGqsR4EXQR+dMvPfuCHIcUHyElvTiAA8QoXqGK6862Ji3HYZc/lntrr4A60pcTI2yNyj6VVH6U/OVSs4QAhVh3Q51l2QrDkWQ6M1MfzbhWQ36iISAE99WDidQ0vlCDb4SBegSPMu/AoSryyKK+IJze+pDnuwvAkhoQGiC8kfa4gxDCfDko7dtlm6vGim6f2+KXE7emp+BNd/xIAf/DWwm+vx3Y7Qn95GKTBSYTTU5V/rRnFzDv4hE9XHiYKtLy9nQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4HkzvbC81GVKJQ6zVLbaiEuPxDsUZstQij1HWUWYw+0=; b=K4wMZ9l46lBXZFEXWeFjAXSqyWS+nbJDOuTlwAEeJF22be8l+Yzi4Bc+wxRT++ZRazyJVyP1Gc2gpISgbq6Tax1zgHN0ujp2GZof9XK0cXAaH5TF0BxK28DwCNzwVAw68G1D3BL75Fmn3YlXr4bTa74dU/oJ65ExtiTxCK5FQ0M= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB3682.EURPRD10.PROD.OUTLOOK.COM (10.186.175.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Fri, 17 Jan 2020 10:40:47 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a059:85c0:8cba:4b1b]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a059:85c0:8cba:4b1b%6]) with mapi id 15.20.2644.015; Fri, 17 Jan 2020 10:40:47 +0000 From: "Brockhaus, Hendrik" To: Tomas Gustavsson , "spasm@ietf.org" , Michael Richardson Thread-Topic: AW: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile Thread-Index: AQHVxWtJYB0uOyHDaUK+bxSA9eNMy6fgl7kAgAr1GoCAAZZ3gIABk/6A Date: Fri, 17 Jan 2020 10:40:47 +0000 Message-ID: References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [195.145.170.173] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 18833540-8d87-4b75-5479-08d79b39b670 x-ms-traffictypediagnostic: AM0PR10MB3682: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(4636009)(366004)(376002)(346002)(39860400002)(396003)(136003)(199004)(189003)(8676002)(8936002)(5660300002)(81166006)(81156014)(15974865002)(71200400001)(33656002)(2906002)(45080400002)(9686003)(86362001)(55016002)(966005)(478600001)(52536014)(66946007)(66446008)(64756008)(66556008)(66476007)(186003)(6506007)(53546011)(110136005)(7696005)(26005)(76116006)(66574012)(15650500001)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB3682; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ARjiV4Ljui5bLPET/QUMO8PU5pIqukcOi/RheA0U6udQgz4Gia2gli+schCJ7tQ+3C8+TzqHSF6OTXHv0bmSQKOhYwnUTtnOGCrBYz1mEVFml0vaVDG3fxI2c917NJmEbj1vcGofTQIISwaQqYbp85eGLFk1bn5rF7rZwWTc+Qy/HM7DrzwkRbe3sHV2QdWi4ck6bclsU55hi6Thyg1jQExkeSaGZ0NWlbYn7N51TCk64CfBZ7Okx4RXMhbfkySVPsBq1HNM83WAWCByDslH+hvRiotVf8mE7HhqnkHWIFX5FYRFjFo0zLo+IOykiqXWvo7jyHalrBdcfkwr6Meyrohxk7jorUVUzaB0ZuXJ0PVoON3KRj6khbSU5sc/N/foczAWU6zssCcaz0ez9VWZIfvqDxBKfmb1wk+eTV4VmXzFXxkN4uPm6o+rc6Uk7ka9eTocBg6eq04MvoZzuTwLV4TofFWP9hh14Nc0StJ45HMWbdC3gjLStulOSy05/fSzDyvdoEwU/kjzWf2XOc9vhHHGPFYP5iWV30ZG4GcEcnp8OIbsXb3tJYjExItAdauQTP2c+wM/1M9k9raFaOknOxE+ZVN+wjv88LEWSoV4vLcemThXDoe0zFgBaiYgiqGY x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18833540-8d87-4b75-5479-08d79b39b670 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 10:40:47.1371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0CpAzfzokLqiLqPon0B6XxQNH5pYE7eOEyHQoZuHXU32cIVmKws8woAXMrKaWumSE0tA/TaH+ESLefDfeSzwfCVLliARMON/MwzDfe64jlY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3682 Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 10:40:54 -0000 PiBWb246IFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPg0K PiANCj4gT24gMjAyMC0wMS0xNSAxNToyNSwgQnJvY2toYXVzLCBIZW5kcmlrIHdyb3RlOg0KPiA+ DQo+ID4+IFZvbjogU3Bhc20gPHNwYXNtLWJvdW5jZXNAaWV0Zi5vcmc+IEltIEF1ZnRyYWcgdm9u IFRvbWFzIEd1c3RhdnNzb24NCj4gPj4NCj4gPj4gMS4gSSBvcHBvc2UgdGhlIHVzYWdlIG9mIC53 ZWxsLWtub3duIFVSTHMgaW4gdGhpcyBjb250ZXh0LiBJIGRvbid0DQo+ID4+IGNvbnNpZGVyIENN UCBlbmQgcG9pbnRzIGJlaW5nIGluIHRoZSBsaW5lIG9mIHRoZSBkZWZpbml0aW9uIG9mDQo+ID4+ IC4ud2VsbC1rbm93biBhcyBzcGVjaWZpZWQgaW4gUkZDNTc4NS4gQSBDTVAgZW5kIHBvaW50IGlz IG5vdCBtZXRhLWRhdGEuDQo+ID4+IElmIGFueXRoaW5nIC53ZWxsLWtub3duIHNob2xkIGJlIHVz ZWQgZm9yIGRpc2NvdmVyaW5nIHRoZSBhY3RpdmUgQ01QDQo+ID4+IGVuZCBwb2ludCB1cmxzIChz ZWUgcG9pbnQgMikuDQo+ID4gW0Jyb10gQ3VycmVudGx5IEkgc2F3IHRoZSBjb25jZXB0IG9mIC53 ZWxsLWtub3duIFVSSXMgaW4gRVNUIGFuZCBCUlNLSS4gQXMgZmFyDQo+IGFzIEkgdW5kZXJzdGFu ZCB5b3VyIGNvbmNlcm5zLCB0aGUgY29uY2VwdCBvZiAud2VsbC1rbm93biBVUklzIHNob3VsZCBv bmx5IGJlDQo+IHVzZWQgdG8gb2ZmZXIgbWV0YS1kYXRhIG9uIHRoZSBzZXJ2aWNlcyBwcm92aWRl ZCBieSwgZS5nLiwgYW4gUkEuIFN1Y2ggbWV0YS0NCj4gZGF0YSBjb3VsZCB0aGFuIGJlIHRoZSBs aXN0IG9mIHN1cHBvcnRlZCB1c2UgY2FzZXMgYWNjb3JkaW5nIFNjaMO8cHBsZXIgdGhlDQo+IGxp Z2h0d2VpZ2h0IENNUCBwcm9maWxlIGFuZCB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQgQ0FzIG9yIGNl cnRpZmljYXRlIHByb2ZpbGVzLiBUaGUNCj4gZm9ybWF0IGZvciBzdWNoIG1ldGEtZGF0YSBtdXN0 IGJlIHNwZWNpZmllZCB0aGVuIHRvbywgSSBndWVzcy4gSXMgdGhpcyB3aGF0IHlvdQ0KPiBtZWFu dD8NCj4gDQo+IFllcy4gSSBhZG1pdCB0byBoYXZlIGxpbWl0ZWQgZXhwZXJpZW5jZSBvZiBnb29k IHVzYWdlIG9mIC53ZWxsLWtub3duIHRob3VnaC4NCltCcm9dIEBNaWNoYWVsLCBjYW4geW91IGp1 bXAgaW4/DQoNCj4gDQo+ID4gTWljaGFlbCBSaWNoYXJkc29uIGFsc28gZ2F2ZSBmZWVkYmFjayB0 byB0aGUgLndlbGwta25vd24gVVJJcyBJIHNwZWNpZmllZCBpbg0KPiBzZWN0aW9uIDcuMS4NCj4g PiBATWljaGFlbCwgbWF5IGJlIHlvdSBjYW4gYWxzbyBicmluZyBpbiB5b3VyIG9waW5pb24gaW4g dGhpcyB0cmVhZC4NCj4gPg0KPiA+IEFyZSB0aGVyZSBmdXJ0aGVyIG9waW5pb25zIG9uIHRoaXM/ DQo+ID4gRG9lcyBhbnlvbmUgaGFzIGV4cGVydGlzZSBvbiB0aGUgcmVxdWVzdGVkIG1ldGEtZGF0 YSBhcHByb2FjaD8NCj4gPg0KPiA+Pg0KPiA+PiAyLiBBIHNpbmdsZSBDTVAgZW5kIHBvaW50IHVy bCBwYXRoIGRvZXMgbm90IHdvcmsgd2hlbiBzZXJ2aWNpbmcNCj4gPj4gbXVsdGlwbGUgQ0FzIGFu ZCB1c2UgY2FzZXMuIFNpbmNlIHJlYWwgQ01QIGVuZCBwb2ludHMgYXJlIG5vdCAic2VydmUNCj4g Pj4gYWxsIGV2ZXJ5dGhpbmcgdGhleSBhc2sgZm9yIiwgbXVsdGlwbGUgY29uZmlndXJhdGlvbnMs IGFjY2VzcyByaWdodHMNCj4gPj4gYW5kIHByb2ZpbGVzIGFyZSBuZWVkZWQuIFRvZGF5IHRoaXMg aXMgY29tbW9ubHkgaW1wbGVtZW50ZWQgYnkNCj4gPj4gZGlmZmVyZW50IENNUCB1cmwgcGF0aHMu IEl0IGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSwgd2l0aGluIHRoZQ0KPiA+PiBzY29wZSBv ZiBSRkM0MjEwLCB0byBtZXJnZSBhbGwgdXNlcyBjYXNlcyBpbnRvIGEgc2luZ2xlIHVybCBwYXRo LiBBbnkgQ01QDQo+IHByb2ZpbGUgc2hvdWxkIHN1cHBvcnQgbXVsdGlwbGUgdXJsLXBhdGhzLg0K PiA+IFtCcm9dIEkgZm91bmQgc2VjdGlvbiAzLjIuMiBpbiBSRkM3MDMwLg0KPiA+ICIgMy4yLjIu ICBIVFRQIFVSSXMgZm9yIENvbnRyb2wNCj4gPg0KPiA+IFsuLi5dDQo+ID4NCj4gPiAgICBBbiBF U1Qgc2VydmVyIE1BWSBwcm92aWRlIHNlcnZpY2UgZm9yIG11bHRpcGxlIENBcyBhcyBpbmRpY2F0 ZWQgYnkgYW4NCj4gPiAgICBPUFRJT05BTCBhZGRpdGlvbmFsIHBhdGggc2VnbWVudCBiZXR3ZWVu IHRoZSByZWdpc3RlcmVkIGFwcGxpY2F0aW9uDQo+ID4gICAgbmFtZSBhbmQgdGhlIG9wZXJhdGlv biBwYXRoLiAgVG8gYXZvaWQgY29uZmxpY3QsIHRoZSBDQSBsYWJlbCBNVVNUDQo+ID4gICAgTk9U IGJlIHRoZSBzYW1lIGFzIGFueSBkZWZpbmVkIG9wZXJhdGlvbiBwYXRoIHNlZ21lbnQuICBUaGUg RVNUDQo+ID4gICAgc2VydmVyIE1VU1QgcHJvdmlkZSBzZXJ2aWNlcyByZWdhcmRsZXNzIG9mIHdo ZXRoZXIgdGhlIGFkZGl0aW9uYWwNCj4gPiAgICBwYXRoIHNlZ21lbnQgaXMgcHJlc2VudC4gIFRo ZSBmb2xsb3dpbmcgYXJlIHRocmVlIGV4YW1wbGUgdmFsaWQgVVJJczoNCj4gPg0KDQpbQnJvXSBT b3JyeSBhYm91dCB0aGUgcmVmb3JtYXR0aW5nIG9mIHRoZSBVUkxTLiBNeSBvZmZpY2UgbWFpbCBj bGllbnQgaXMgZG9pbmcgc3VjaCB0aGluZ3MgZm9yIHNlY3VyaXR5IHJlYXNvbnMuLi4uDQpJIGRl bGV0ZWQgdGhlIGVudW1lcmF0aW9uIGZyb20gdGhpcyBlbWFpbC4NCg0KPiA+DQo+ID4gICAgSW4g dGhpcyBzcGVjaWZpY2F0aW9uLCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBlbnJvbGwgYW5kIHJl bmV3L3Jla2V5DQo+ID4gICAgaXMgZXhwbGljaXRseSBpbmRpY2F0ZWQgYnkgdGhlIEhUVFAgVVJJ LiAgV2hlbiByZXF1ZXN0aW5nIC9mdWxsY21jDQo+ID4gICAgb3BlcmF0aW9ucywgQ01DIFtSRkM1 MjcyXSB1c2VzIHRoZSBzYW1lIG1lc3NhZ2VzIGZvciBjZXJ0aWZpY2F0ZQ0KPiA+ICAgIHJlbmV3 YWwgYW5kIGNlcnRpZmljYXRlIHJla2V5Lg0KPiA+DQo+ID4gICAgQW4gRVNUIHNlcnZlciBjYW4g cHJvdmlkZSBhZGRpdGlvbmFsIHNlcnZpY2VzIHVzaW5nIG90aGVyIFVSSXMuIg0KPiA+DQo+ID4g V2hhdCBkbyB5b3UgdGhpbmsgb2YgdGhpcyBhcHByb2FjaCB1c2luZyBhbiAiYXJiaXRyYXJ5TGFi bGUiIHRvIGlkZW50aWZ5IHRoZQ0KPiBDQSBvciBjZXJ0aWZpY2F0ZSBwcm9maWxlIHRoYXQgaXMg dG8gYmUgYWRkcmVzc2VkPyBXb3VsZCB0aGF0IHNvbHZlIHlvdXINCj4gcHJvYmxlbT8NCj4gDQo+ IFllcyB0aGUgYXJiaXRyYXJ5TGFiZWwgaXMgdGhlIGFwcHJvYWNoIHdlIHVzZSBjdXJyZW50bHks IGJvdGggZm9yIEVTVCBhbmQgZm9yDQo+IENNUCBpbiBmYWN0LiBJIHRoaW5rIHRoYXQgd29ya3Mg d2VsbC4NCltCcm9dIE9LLCB0aGF0IGlzIGdyZWF0LiBJIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCBh Y2NvcmRpbmdseS4NCg0KPiANCj4gPg0KPiA+Pg0KPiA+PiAzLiBUaGUgbXVsdGlwbGUgdXJsIHBh dGhzIGRlZmluZWQgaW4gNy4xIGZvciBkaWZmZXJlbnQgb3BlcmF0aW9ucyBpcw0KPiA+PiByZWR1 bmRhbnQgZm9yIENNUCwgYXMgdGhpcyBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGluIHRoZSBDTVAg bWVzc2FnZXMuDQo+ID4+IENNUCB3b3JrcyB2ZXJ5IHdlbGwgd2l0aCBhIHNpbmdsZSB1cmwgcGF0 aCBmb3IgYWxsIG1lc3NhZ2VzIGFuZA0KPiA+PiBlc3RhYmxpc2hpbmcgYSBuZXcgc2NoZW1lIHdp bGwgYnJlYWsgaW50ZXJvcGVyYWJpbGl0eSwgbm90IGZvc3RlciBpbWhvLg0KPiA+IFtCcm9dIFll cywgQ01QIG1lc3NhZ2VzIHR5cGVzIGNhbiBiZSBlYXNpbHkgaWRlbnRpZmllZCBmcm9tIHRoZSBi b2R5IHR5cGUuDQo+IFRvZ2V0aGVyIHdpdGggdGhlIHRyYW5zYWN0aW9uSWQgb2YgdGhlIG1lc3Nh Z2UgaGVhZGVycywgdGhlIGNsaWVudCBhbmQgc2VydmVyDQo+IGNhbiBlYXNpbHkgaWRlbnRpZnkg dGhlIGludGVuZGVkIHVzZXMgY2FzZS4NCj4gPiBBcyBhbiBleGFtcGxlLCB0aGUgcGF0aHMgc3Bl Y2lmaWVkIGluIHNlY3Rpb24gNy4xIG5vdCBkaXJlY3RseSBtYXAgd2l0aCBvbmUNCj4gc3BlY2lm aWMgQ01QIGJvZHkgdHlwZS4gRm9yIGV4YW1wbGUgL2luaXRpYWxpemF0aW9uIGlzIGEgc2VxdWVu Y2Ugb2YgaXIgKEVFLT5SQSkNCj4gYW5kIGlwIChSQS0+RUUpIGFuZCBvcHRpb25hbGx5IGNlcnRD b25mIChFRS0+UkEpIGFuZCBwa2ljb25mIChSQS0+RUUpLiBJbiBjYXNlDQo+IG9mIGFuIGVycm9y IHRoZSBlcnJvciBtZXNzYWdlIGlzIHNlbnQgdG8gdGVybWluYXRlIHRoZSB0cmFuc2FjdGlvbi4g QWxsDQo+IG1lc3NhZ2VzIGFyZSBidW5kbGVkIGluIGEgdHJhbnNhY3Rpb24gaWRlbnRpZmllZCBi eSB0aGUgdHJhbnNhY3Rpb25JZCBpbiB0aGUNCj4gbWVzc2FnZSBoZWFkZXIuIFNvIGlyIGFuZCBj ZXJ0Q29uZiB3aWxsIGJvdGggYmUgc2VudCB0byAud2VsbC0NCj4ga25vd24vY21wL2luaXRpYWxp emF0aW9uLg0KPiA+IEJ1dCB0aGVyZSBpcyBzb21lIG92ZXJsYXAgd2l0aCAvc2VydmVya2V5Z2Vu LCB0aGF0IHVzZXMgdGhlIHNhbWUgYm9keSB0eXBlcy4NCj4gVG8gc3BvdCB0aGF0IHRoaXMgaXMg ZGlmZmVyZW50LCBvbmUgaGFzIHRvIGRpZyBxdWl0ZSBkZWVwIGludG8gdGhlIGNlcnRpZmljYXRl DQo+IHJlcXVlc3QgdG8gZmlndXJlIG91dCB0aGF0IHRoZXJlIGlzIG5vIHB1YmxpYyBrZXkgaW4g aXQuDQo+ID4gQWxzbyB0aGUgZGlmZmVyZW50IHVzZSBjYXNlcyB1c2luZyBzdXBwb3J0IG1lc3Nh Z2VzIGNhbm5vdCBiZSBkaWZmZXJlbnRpYXRlZA0KPiBwdXJlbHkgYnkgZXZhbHVhdGluZyB0aGUg Ym9keSB0eXBlLiBBbHNvIHRoZSBpbmZvVHlwZSBmaWVsZCBvZiB0aGUgZ2VubQ0KPiBtZXNzYWdl IGJvZHkgbXVzdCBiZSB0YWtlbiBpbnRvIGFjY291bnQuDQo+ID4NCj4gPiBBY3R1YWxseSwgSSBh bSBub3QgZGVjaWRlZCB3aGV0aGVyIHRvIG9ubHkgc3BlY2lmeSBhIC53ZWxsLWtub3duL2NtcCBV UkkgYW5kDQo+IGlkZW50aWZ5IHRoZSByZXN0IGZyb20gdGhlIGJvZHkgdHlwZSBhbmQgdGhlIHRy YW5zYWN0aW9uSWQsIGV0Yy4sIG9yIGEgLndlbGwtDQo+IGtub3duL2NtcC9vcHRpb25hbEFyYml0 cmFyeUxhYmxlL3BhdGggd2hlcmUgJ3BhdGgnIGNsZWFybHkgaWRlbnRpZmllcyB0aGUgdXNlDQo+ IGNhc2UgZnJvbSB0aGUgTGlnaHR3ZWlnaHQgQ01QIFByb2ZpbGUgYW5kIHRoZSBvcHRpb25hbCBs YWJsZSBkaXJlY3RseSBpZGVudGlmaWVzDQo+IHRoZSBhZGRyZXNzZWQgQ0Egb3IgY2VydGlmaWNh dGUgcHJvZmlsZS4NCj4gPg0KPiA+IEBUb21hcywgTWljaGFlbCwgd2hhdCBkbyB5b3UgdGhpbms/ DQo+IA0KPiBUaGFua3MuIEl0IHdhcyBub3QgY2xlYXIgKHRvIG1lKSB0aGUgZnVsbCBtZWFuaW5n IG9mIHRoZSBsYWJlbCBwYXRocyBkZXNjcmliZWQuDQo+IERvIHlvdSBtZWFuIHRoYXQgbXVsdGlw bGUgbWVzc2FnZXMgY291bGQgYmUgYnVuZGxlZD8gT3IganVzdCB0aGF0IGVhY2ggcGF0aA0KPiB3 b3VsZCBlbmZvcmNlIGEgc3BlY2lmaWMgd29yay1mbG93PyBJLmUuIHNlcnZlciBrZXkgZ2VuIGlz IG5vdCBhbGxvd2VkIGluDQo+IC9pbml0aWFsaXphdGlvbiBmb3IgZXhhbXBsZT8NCltCcm9dIFll cywgdGhlIGxhc3QgcGFydCBvZiB0aGUgcGF0aCBzaG91bGQgaW5kaWNhdGUgb25lIHNwZWNpZmlj IHdvcmstZmxvdy4NCg0KPiANCj4gPiBBcmUgdGhlcmUgZnVydGhlciBvcGluaW9ucyBvbiB0aGlz Pw0KPiA+DQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+IFRvbWFzDQo+ID4+DQo+ID4+DQo+ID4+ IE9uIDIwMjAtMDEtMDcgMTY6MDAsIFJ1c3MgSG91c2xleSB3cm90ZToNCj4gPj4+IFRoZXJlIGFy ZSB0d28gQ01QLXJlbGF0ZWQgZG9jdW1lbnRzOg0KPiA+Pj4gICAtIGRyYWZ0LWJyb2NraGF1cy1s YW1wcy1jbXAtdXBkYXRlcw0KPiA+Pj4gICAtIGRyYWZ0LWJyb2NraGF1cy1sYW1wcy1saWdodHdl aWdodC1jbXAtcHJvZmlsZQ0KPiA+Pj4NCj4gPj4+IFBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlv dSBzdXBwb3J0IGFkb3B0aW9uIG9mIHplcm8sIG9uZSwgb3IgYm90aA0KPiA+Pj4gb2YgdGhlc2UN Cj4gPj4gZG9jdW1lbnRzIGJ5IHRoZSBMQU1QUyBXRy4gIFBsZWFzZSByZXNwb25kIGJlZm9yZSBK YW51YXJ5IDIybmQuDQo+ID4+Pg0KPiA+Pj4gUnVzcw0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBTcGFzbSBtYWlsaW5n IGxpc3QNCj4gPj4+IFNwYXNtQGlldGYub3JnDQo+ID4+PiBodHRwczovL2V1cjAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+ID4+Pg0K PiA+Pg0KPiBpZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwYXNtJmFtcDtkYXRhPTAy JTdDMDElN0NoZW5kcmlrLmJybw0KPiA+PiBjaw0KPiA+Pj4NCj4gPj4NCj4gaGF1cyU0MHNpZW1l bnMuY29tJTdDYjZiMDUxMDE5ZjgyNDdiYTJiMTkwOGQ3OTQyODc1N2YlN0MzOGFlM2JjZDkNCj4g Pj4gNTc5NGYNCj4gPj4+DQo+ID4+DQo+IGQ0YWRkYWI0MmUxNDk1ZDU1YSU3QzElN0MwJTdDNjM3 MTQwNzczNzk2ODA4MDczJmFtcDtzZGF0YT1wN25JTw0KPiA+PiA4cW1BNWFIDQo+ID4+PiBpYlB1 enp4VDBaVTclMkJ0RXVtOHhLOTg0Vzg3V2lzTEklM0QmYW1wO3Jlc2VydmVkPTANCj4gPj4+DQo+ ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+IFNwYXNtIG1haWxpbmcgbGlzdA0KPiA+PiBTcGFzbUBpZXRmLm9yZw0KPiA+Pg0KPiBo dHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ3d3cuaWV0Zi4NCj4gPj4NCj4gb3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3Bh c20mYW1wO2RhdGE9MDIlN0MwMSU3Q2hlbmRyaWsuYnJvY2toYQ0KPiA+Pg0KPiB1cyU0MHNpZW1l bnMuY29tJTdDYjZiMDUxMDE5ZjgyNDdiYTJiMTkwOGQ3OTQyODc1N2YlN0MzOGFlM2JjZDk1Nw0K PiA+Pg0KPiA5NGZkNGFkZGFiNDJlMTQ5NWQ1NWElN0MxJTdDMCU3QzYzNzE0MDc3Mzc5NjgwODA3 MyZhbXA7c2RhdGE9cDcNCj4gPj4gbklPOHFtQTVhSGliUHV6enhUMFpVNyUyQnRFdW04eEs5ODRX ODdXaXNMSSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQoNCkhlbmRyaWsgQnJvY2toYXVzDQpTaWVtZW5z IEFHDQpDb3Jwb3JhdGUgVGVjaG5vbG9neQ0KUmVzZWFyY2ggaW4gRGlnaXRhbGl6YXRpb24gYW5k IEF1dG9tYXRpb24NClNlY3VyaXR5IEFyY2hpdGVjdHVyZQ0KbWFpbHRvOmhlbmRyaWsuYnJvY2to YXVzQHNpZW1lbnMuY29tDQoNCnd3dy5zaWVtZW5zLmNvbS9pbmdlbnVpdHlmb3JsaWZlDQoNClNp ZW1lbnMgQWt0aWVuZ2VzZWxsc2NoYWZ0OiBDaGFpcm1hbiBvZiB0aGUgU3VwZXJ2aXNvcnkgQm9h cmQ6IEppbSBIYWdlbWFubiBTbmFiZTsgTWFuYWdpbmcgQm9hcmQ6IEpvZSBLYWVzZXIsIENoYWly bWFuLCBQcmVzaWRlbnQgYW5kIENoaWVmIEV4ZWN1dGl2ZSBPZmZpY2VyOyBSb2xhbmQgQnVzY2gs IExpc2EgRGF2aXMsIEtsYXVzIEhlbG1yaWNoLCBKYW5pbmEgS3VnZWwsIENlZHJpayBOZWlrZSwg TWljaGFlbCBTZW4sIFJhbGYgUC4gVGhvbWFzOyBSZWdpc3RlcmVkIG9mZmljZXM6IEJlcmxpbiBh bmQgTXVuaWNoLCBHZXJtYW55OyBDb21tZXJjaWFsIHJlZ2lzdHJpZXM6IEJlcmxpbiBDaGFybG90 dGVuYnVyZywgSFJCIDEyMzAwLCBNdW5pY2gsIEhSQiA2Njg0OyBXRUVFLVJlZy4tTm8uIERFIDIz NjkxMzIyDQoNCg== From nobody Fri Jan 17 06:53:34 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9049120098; Fri, 17 Jan 2020 06:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 69_1qq-zaLd6; Fri, 17 Jan 2020 06:53:26 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2078.outbound.protection.outlook.com [40.107.22.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9ED4120074; Fri, 17 Jan 2020 06:53:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BGcr1lHzaBqsR1UK9KA/bSUiqsBK49/CDfYmjIqWPztp8f60B7iw4/nvaZWa1cbuhYjyuq20HJtLwr2z7JV0lNQP/cxOMbvAy3JUmthWdgSiRVkK57BcxFp3zBqP+qRL5uia0tbA81l5eRgZ8NIewskUpRECIc8X9FKzJk/k4BOFI6naPUxfXbSYQV0GdYWQ1j5H3SHuApiEKBGuLinF3sniujdCZnzajiSMjaAULXFdZ46jhWLvkO70HTb/vQqQuZ/gp4+URHcwuxsT1M8VC1Kq9RA79UQUkyCWaRtqx+1yEHVe7mlr610pV52xDk/poqvVEwMHJNCralfqqAGDww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=84E9C1xBDdm0ebFzJqA8qSyKzb3/7xh0NGGMISV/27A=; b=c9XwWmNGK2cMgRlvRnY4d9oPRtB+8Dj1IBzvUuSOluqEnNQ4gkTjxzCRF29PcNo2cbrlaXnrjaljwF9FPLWseZpLCjp62JS+S6SWwtkmuvz7hH79ldeL8NhRNiQX27/9ebCdTaOHGmSeS/jOhgCGS81zirl3I5sd7YDQLJToOZseul64tZ5/Y99hKbYv2niS5YqRpd4pUDDSyx+GfcF/gPD0Ttq+Xbv4q83glaOOpYqk7r/hE01sV4GaQreKP3Vwy0DsxG5rb3SjpTo9skl66PBiVusnOqjpJZRlPbEYZF4Z0yHnMHiCztcvToLMKV0xsLcKm/lvfCKwSBP8hP92eg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=84E9C1xBDdm0ebFzJqA8qSyKzb3/7xh0NGGMISV/27A=; b=rVPJ8k32QvCxaegHu5uTAV7DNunmEA/dqBXMztnTdtvGYHWhHRXWLCzXAUq+SCmBlxcrC7xcNzUgjVMk/Z/VjEYIdJBddzP+oWbQG5hOYw5Z+DU5/qNmbcF+18qh9KUPMqmK2gHKpNkC+UFTJ8oKY9m3dHfVOeR5K29kztciiNU= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2236.eurprd07.prod.outlook.com (10.168.31.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.10; Fri, 17 Jan 2020 14:53:23 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::cd13:3dbf:1517:c03c]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::cd13:3dbf:1517:c03c%10]) with mapi id 15.20.2644.015; Fri, 17 Jan 2020 14:53:23 +0000 From: Mohit Sethi M To: Benjamin Kaduk , Joseph Salowey CC: "spasm@ietf.org" , EMU WG Thread-Topic: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic Thread-Index: AQHVzUXdmB8wOza2UEWNwHm3m8C1QQ== Date: Fri, 17 Jan 2020 14:53:23 +0000 Message-ID: <7e2a5d26-0ef1-5ca1-3ea6-34cac0293f0a@ericsson.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> In-Reply-To: <20200116040715.GC80030@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:170:2d00:80d1:e927:2542:2834] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7ab3d706-b871-476d-b7f2-08d79b5d0037 x-ms-traffictypediagnostic: HE1PR0701MB2236: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(136003)(376002)(346002)(189003)(199004)(86362001)(6506007)(53546011)(36756003)(76116006)(31696002)(81166006)(8676002)(4744005)(110136005)(81156014)(66946007)(66446008)(66476007)(66556008)(64756008)(5660300002)(54906003)(316002)(71200400001)(31686004)(2906002)(8936002)(6486002)(478600001)(6512007)(2616005)(186003)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2236; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ksk6vsrA8pCV4RblPwO5pQWKYV5LTz49Gkpzifxo/doz+gPPJ9LnyLqKWnRTQhy/UDXFE6ppFtSzQt4x+wx8x3Y95khXT6b3EJQn67keg95Yu8C7ZMkQw0aulI+lz8c8dqBIAA5PzkI6ZxIhMk37KVFslc8W/zE/4Dwjf9bBiUitErBe8rEcjmCp9m46I7z5/W6F9lR52VWCOaOLYixoGWf3DqJjzQoMt66oJ873XKMuhBdGurquUkcYKg2iph4N5knGVhWdOviBsVU8xf1sr1fEZ+HfBEeZFEwC4XTAB6aaT6HnZvAZq+JQUtMNFeYQpmfhZJtgxRY97Xv5VFrzVnOVmCB8b1IDVzIYHiGbw2cUSYGa5HGeMv+iIVGE5Bj8iZsvCVtbyPBGFnjUbJBQ16VNMrLMrySvVdgeGEamZ5+IiRnOE/lLhy6nS+FfvoWg x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <36E4C3CE5D15A444BAB4B62009908F37@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ab3d706-b871-476d-b7f2-08d79b5d0037 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 14:53:23.3160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: N2pECWXk9roObWj1xyAir5G8kELa6FC8cNrPVAqdV7NkfGbeXzhGRezS84Mwt1Zle0sczRrty6TD3gxikGjG/sKLatSmp2OVMe82XE2aYf8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2236 Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 14:53:28 -0000 T24gMS8xNi8yMCA2OjA3IEFNLCBCZW5qYW1pbiBLYWR1ayB3cm90ZToNCj4gSXMgdGhlcmUgYW55 dGhpbmcgYmV0dGVyIGZvciBpbXBsZW1lbnRhdGlvbnMgdG8gYWN0dWFsbHkgZG8gKGFzIGRpc3Rp bmN0DQo+IGZyb20gd2hhdCB3ZSB3cml0ZSBkb3duIGFzIHJlY29tbWVuZGF0aW9ucykgdGhhbiB0 byBzdGFydCBzZXR0aW5nIHVwIGENCj4gcGFyYWxsZWwgKHB1cnBvc2Utc3BlY2lmaWMpIFBLSSBu b3cgYW5kIHRydXN0aW5nIHRoYXQgaW4gcGFyYWxsZWwgd2l0aCB3aGF0DQo+IHRoZXkncmUgY3Vy cmVudGx5IGRvaW5nLCB3aXRoIHRoZSBob3BlIG9mIGJlaW5nIGFibGUgdG8gaGF2ZSBhIGZsYWcg ZGF5DQo+IG1hbnkgeWVhcnMgZG93biB0aGUgbGluZSB3aGVuIHRoZSBuZXcgUEtJIGJlY29tZXMg dGhlIG9ubHkgdGhpbmcgdGhhdCdzDQo+IHRydXN0ZWQ/DQpUaGlzIHNlZW1zIGxpa2UgYSByZWFz b25hYmxlIHdheSBmb3J3YXJkIHRvIG1lLg0KDQotLU1vaGl0DQoNCg== From nobody Fri Jan 17 07:37:07 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014F2120842 for ; Fri, 17 Jan 2020 07:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cjG9l-DAPpdJ for ; Fri, 17 Jan 2020 07:37:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75094120835 for ; Fri, 17 Jan 2020 07:37:01 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 823D53897D; Fri, 17 Jan 2020 10:36:31 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C48955D4; Fri, 17 Jan 2020 10:36:59 -0500 (EST) From: Michael Richardson To: "spasm\@ietf.org" , "Brockhaus\, Hendrik" cc: Tomas Gustavsson In-Reply-To: References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 15:37:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brockhaus, Hendrik wrote: >> On 2020-01-15 15:25, Brockhaus, Hendrik wrote: >> > >> >> Von: Spasm Im Auftrag von Tomas Gustavss= on >> >> >> >> 1. I oppose the usage of .well-known URLs in this context. I don't >> >> consider CMP end points being in the line of the definition of >> >> ..well-known as specified in RFC5785. A CMP end point is not meta= -data. >> >> If anything .well-known shold be used for discovering the active = CMP >> >> end point urls (see point 2). >> [Bro] Currently I saw the concept of .well-known URIs in EST and BRS= KI. As far >> as I understand your concerns, the concept of .well-known URIs shoul= d only be >> used to offer meta-data on the services provided by, e.g., an RA. Su= ch meta- >> data could than be the list of supported use cases according Sch=C3= =BCppler the >> lightweight CMP profile and the list of supported CAs or certificate= profiles. The >> format for such meta-data must be specified then too, I guess. Is th= is what you >> meant? >> Yes. I admit to have limited experience of good usage of .well-known >> though. > [Bro] @Michael, can you jump in? {Your non-Usenet non-quoting style makes it very difficult to deal with your thread. Please consider getting a standard MUA} .well-known URIs are not just for meta-data about where the service is. RFC7030, for instance, puts all of it's end points there. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4h1JsACgkQgItw+93Q 3WXHfgf+OrCEEGkh9yeB+ir3f5pQr1Qa3rph7cq1ZjSGHnkrX3iVy+ALkxnNJE8y 3+tnrvGR62x/f91LwSFp8AXKcphZuDJBsw2vcRI1WVUqPKSoirEmLqwK4RDg04pQ j6JvhkWYdTlODjSml71F9glcyX1PM+62z9XhUAJ1OtcJM9cM0E+LXsNF4OyDIo0s rMq9wwLaKppyunhjygbmCA1+2eoPaHTgNiASu9Hg+AaBHuxyTKPaCgCjI5To/s8+ YGT604YaC7OUbZCNxPGynUWO8NRMwMQjb3CVv0jouNFoDdu/Hg10ypqQpRVEB5N9 mMaWrRF1ekteBvUGQcjq8Brmg4bhxw== =Zppb -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 17 09:33:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37211208AF; Fri, 17 Jan 2020 09:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 I0jPJ2ewylI9; Fri, 17 Jan 2020 09:33:55 -0800 (PST) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB3C12087A; Fri, 17 Jan 2020 09:33:50 -0800 (PST) Received: by mail-ed1-f51.google.com with SMTP id r21so23012490edq.0; Fri, 17 Jan 2020 09:33:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xvTmTFSNdd1ho6Wfc/Wkx9jPb4hE3qhH+FBQuv5NIj0=; b=MAP0qTOCyeUd0Bpv8sx/iT6ubfG1ZgZoAZBxe5PvMBlgc9KI/8R317oTseXuK9cous /cxVTPCA36Z0sqoF+fxsnSxBOVn5qWOTmU79xNRTP+PiGyU+OMo6MLC5umplQPEw51wH 98X1Uz5C+gT/54GQRZB8YrpN8Q6q/9S3/Y3KaAfr4IMyzlPaUhGSDVlVAyqYigxzZ0RA F4rVZ87CjcGx6dO6ht9x+uqUd6njfzKna0vR8SA3Vzj0m90ifTr8A7U0eNKG9QTB47xY VzHktNokRlsfK2VN2wmjtMAoF55YBcssC++lwgXbajhgIcuWLiakyxkEozt5FXg8akH7 JWsQ== X-Gm-Message-State: APjAAAXxJMq/LVVEYGPtFBcwmxxK1tazcd00CNlvLYlM18amT4K3Khk0 SVBeOURwbo1uy4i1y/TtyrGARrPR X-Google-Smtp-Source: APXvYqzD3OFgBQKxiTkDrDrYhlz/Y31PyRw31HiCUlQ3nzGpX2/7PedP6ryJ0cepFpdY2dujKjOhRQ== X-Received: by 2002:a05:6402:c0f:: with SMTP id co15mr5205132edb.200.1579282428657; Fri, 17 Jan 2020 09:33:48 -0800 (PST) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com. [209.85.128.44]) by smtp.gmail.com with ESMTPSA id r23sm1026599edx.24.2020.01.17.09.33.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jan 2020 09:33:48 -0800 (PST) Received: by mail-wm1-f44.google.com with SMTP id t14so8434389wmi.5; Fri, 17 Jan 2020 09:33:47 -0800 (PST) X-Received: by 2002:a1c:9c4c:: with SMTP id f73mr5549058wme.125.1579282427511; Fri, 17 Jan 2020 09:33:47 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> In-Reply-To: <20200116040715.GC80030@kduck.mit.edu> From: Ryan Sleevi Date: Fri, 17 Jan 2020 12:33:36 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Benjamin Kaduk Cc: Joseph Salowey , "spasm@ietf.org" , Michael Richardson , EMU WG , Alan DeKok Content-Type: multipart/alternative; boundary="000000000000178c93059c5958d7" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 17:33:58 -0000 --000000000000178c93059c5958d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 15, 2020 at 11:07 PM Benjamin Kaduk wrote: > A couple things that stand out to me from having basically read the whole > thread in one go (this is not intended to be an exhaustive list of open > questions): > > It was implied but not fully clear to me, that Ryan thinks that someone s= o > inclined could, right now, go around trying to connect to wifi using EAP > authentication, grab a packet capture of the remote server using its > id-kp-serverAuth certificate for authenticating the TLS-over-EAP > connection, and report that certificate to its issuing CA as "misuse" > requiring prompt revocation, at least for several major CAs. It's quite > probably that I missed them as they went by, but specific links to specif= ic > CA policy documents that would classify such certificate usage as "misuse= " > (requiring revocation) would help clarify things, at least for me. > While I think people are missing the forest for the tree, here's an example CP/CPS from a CA: https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/ori= ginal/CPS%20OV%20SSL_v%201.10_April%202019.pdf 1.4.2 Prohibited certificate uses > Any usage of a certificate other than the usage explicitly allowed in the > CPS, is prohibited. > 1.4.1 Appropriate certificate uses > Certificates may be used in applications that satisfy at least the > following conditions: > =E2=80=A2 Manage properly the public and private keys, > =E2=80=A2 Certificates and associated public keys are used in compliance = with > their declared > purpose, confirmed by CERTSIGN, > =E2=80=A2 Have built-in mechanisms of certificate status verification, > certification path creation > and validation control (signature availability, expiration date etc.), > =E2=80=A2 Provides relevant information regarding certificates and their = status > for users. It's already been flagged, for the CA to fix in their next CP/CPS update ( https://bugzilla.mozilla.org/show_bug.cgi?id=3D1403453 ), that they're conflating requirements on Relying Party applications (i.e. those that verify certificates) and Subscriber applications (i.e. those that serve certificates). Does your RADIUS endpoint support and use OCSP stapling and disable WiFi if the certificate is expired? No? Then it's a potential violation of this CP/CPS. Now, folks might be unhappy with that, thinking certSIGN isn't a "major" CA. Here's DigiCert's CPS - https://www.digicert.com/wp-content/uploads/2019/11/DigiCert_CPS_v420.pdf . 4.9.1 states that: > DigiCert may revoke a certificate within 24 hours and will revoke a > Certificate within 5 days if one or more of the following occurs: ... > 3. The Subscriber or the cross-certified CA breached a material obligatio= n > under the CP, this CPS, or the relevant agreement; DigiCert's Subscriber Agreement (the relevant agreement) is at https://www.digicert.com/legal-repository/Subscriber-Agreement.pdf and, in Section 2.2, makes reference to their Certificate Terms Of Use - https://www.digicert.com/legal-repository/Certificate-Terms-of-Use.pdf This Terms of Use has gems like (in Section 12) > Customer will use passwords that > are randomly generated with at least 16 characters containing uppercase > letters, lowercase letters, numbers, and symbols > to transport Private Keys. Customer will only allow Customer=E2=80=99s em= ployees, > agents, and contractors to access or use Private > Keys if the employee, agent, or contractor has undergone a background > check by Customer (to the extent allowed by law) > and has training or experience in PKI and other information security > fields. And in Section 16: > Customer will only use a TLS/SSL Certificate on the servers accessible > at the domain names listed in the issued Certificate Remind me how an EAP-TLS/RADIUS server is accessible at that domain name? And if someone points their domain name to my server, would that require revocation? Or in Section 17: > DigiCert may revoke a Certificate without notice for the reasons stated i= n > the CPS, including if DigiCert reasonably believes > that: > ... f. the Certificate was used without authorization, outside of its intended > purpose or used to sign Suspect Code; > id-kp-serverAuth sure does seem to mean "WWW server", since RFC 5280 states= : > id-kp-serverAuth OBJECT IDENTIFIER ::=3D { id-kp 1 } > -- TLS WWW server authentication This may seem pedantic and overbroad (OK, it definitely is), but that's the entire meta-point here. There's two parts of discussion from the thread: 1) What do extant clients do, today, in the verification of certificates used in EAP-TLS 2) What should future clients do, 'tomorrow', to make this easier to use and secure, ideally by default. Much of the answer was around #2, which is "Don't try to glom on to something existing, you need to build your own thing", as well as "Some of the answers in #1 are problematic and you should try and discourage them" In the hopes it makes it more accessible, imagine a situation where both Ben and I need gears (widgets, sprockets, take your pick). Ben needs gears that are 4cm in diameter and capable of being used in temperatures from 0-20 degrees Celsius. I need gears that are 4cm in diameter and capable of being used in temperatures from 0-30 degrees Celsius. We both get our gears from a single supplier: Cogswell's Cogs Ben has a bunch of spare gears around for my equipment, and realizes he can just use my gears in his equipment, and everything just works. Our requirements are seen as compatible. That's convenient! However, when Ben approaches Cogswell's Cogs, to sign a supply agreement, it's important that the contract doesn't say "Ben will get 100 of whatever gears Ryan gets". Instead, Ben should say "Ben will get 100 gears that are 4cm in diameter and capable of being used in temperatures from 0-20 degrees Celsius": what Ben actually requires. That's because I may (read: will) change my gears to be 5cm in the future, and be used in temperatures from 15-45 degrees Celsius, and those won't work anymore for Ben. However, if Ben's contract says "I'll have what Ryan's having", then that's what he's going to get, and sad times will be had. I certainly won't have much sympathy for Ben, when Ben comes asking that I change my equipment back to how it used to be, because Ben's needs are different than my needs, and it's entirely Ben's fault for not specifying his contract based on what he required, rather than what I was getting. Similarly, it'd be a bad idea to give instructions to say "Ryan's gears work with Ben's equipment", especially when my specs can and will change. They can even end up completely incompatible. For example, Ben might require durable, long-lived gears, because Ben's equipment goes into hard to reach places that are difficult to service, and thus that they may be made of metal. My gears might be made of metal now, but that's expensive for the machining and milling, and I may be planning to switch to plastic, as part of ensuring they're mass-market affordable and easily replaceable. To connect it back to the discussion: The discussion about revocation, and what a CA's CP/CPS says is or isn't allowed for a usage, matters, because browsers require CAs promptly revoke those certificates in 24 hours/5 days for situations when they specify bad requirements. Can problematic CAs fix their CP/CPS to allow this? Yes. But you've still got a host of other expectations/requirements that can and will diverge, over time. In the specific context of thinking about "#2" - what a touch-free future looks like - having it use the same root store as Web browsers is the anti-pattern, because the requirements are different. It's like Ben saying "I want Ryan's gears", rather than thinking about "I need gears that are 4cm in diameter, capable of being used in temperatures from 0-20 degrees Celsius, and durable enough to be used in hard to reach places" - and finding someone who can and will manufacture those for you. You might end up using Cogwell's Cogs, just like I do, and it might be that, for a time, our gears are produced on the same production line - but your requirements and my requirements aren't intertwined. > Is there anything better for implementations to actually do (as distinct > from what we write down as recommendations) than to start setting up a > parallel (purpose-specific) PKI now and trusting that in parallel with wh= at > they're currently doing, with the hope of being able to have a flag day > many years down the line when the new PKI becomes the only thing that's > trusted? > There's no doubt the status quo is "Everything is manually configured" and "It's inconsistent what is validated". The goal is to get to #2, "It just works" - Define your requirements (the certificate profile) - Define your policies (what do you expect CAs to verify, and how do they verify) - Provide a way to distinguish "new certificates" from "The old and manual cruft" - for example, an explicit EKU - Pick your poison.... er, CAs... for the new root store (e.g. as WiFi Alliance has done, or Wireless Power Consortium has done, or plenty of vendors have done) - Have CAs issue certificates with both EKUs (old and new) in the leaf. It's a SEQUENCE for a reason. - Have supplicants configured that - If new EKU is present, look in built-in store - If old EKU is present, require manual configuration This gets you half-way to #2: things can just work if you pick one of the new-CAs with new-EKUs, and otherwise require manual configuration for old-EKUs At that point, supplicant vendors can slowly phase out support for 'old EKU= ' - If the certificate is manually generated by the wifi server, it is 'easy' to just generate certificates with the new EKU (potentially with *both* new and old EKUs) - If the certificate is coming from a "Web PKI" CA, it intentionally 'breaks' / makes this case difficult. Similarly, RADIUS/EAP-TLS servers can require, when certificates are being installed, that the 'new' EKU be present (potentially alongside the 'old' EKU), and that the certificate conforms with the 'new' profile. At some point, down the line, you can explicitly prohibit the new root store from issuing with id-kp-serverAuth. Supplicants will all be looking for/requiring the new EKU. Your RADIUS/EAP-TLS servers will all be requiring the new EKU to be configured. But when, where, and how you cross that rubicon is up to y'all, and that's the only flag day involved: when to turn off the old. --000000000000178c93059c5958d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 15, 2020 at 11:07 PM Benjamin= Kaduk <kaduk@mit.edu> wrote:
A couple things that stand out to me from having basically read = the whole
thread in one go (this is not intended to be an exhaustive list of open
questions):

It was implied but not fully clear to me, that Ryan thinks that someone so<= br> inclined could, right now, go around trying to connect to wifi using EAP authentication, grab a packet capture of the remote server using its
id-kp-serverAuth certificate for authenticating the TLS-over-EAP
connection, and report that certificate to its issuing CA as "misuse&q= uot;
requiring prompt revocation, at least for several major CAs.=C2=A0 It's= quite
probably that I missed them as they went by, but specific links to specific=
CA policy documents that would classify such certificate usage as "mis= use"
(requiring revocation) would help clarify things, at least for me.

While I think people are missing the forest for= the tree, here's an example CP/CPS from a CA:

1.4.2 Prohibited certificate uses
Any usage of a c= ertificate other than the usage explicitly allowed in the CPS, is prohibite= d.=C2=A0
1.4.1 Appropriate certificate uses
Certificates may be used = in applications that satisfy at least the following conditions:
=E2=80= =A2 Manage properly the public and private keys,
=E2=80=A2 Certificates = and associated public keys are used in compliance with their declared
pu= rpose, confirmed by CERTSIGN,
=E2=80=A2 Have built-in mechanisms of cert= ificate status verification, certification path creation
and validation = control (signature availability, expiration date etc.),
=E2=80=A2 Provid= es relevant information regarding certificates and their status for users.<= /blockquote>

It's already been flagged, for the CA t= o fix in their next CP/CPS update (=C2=A0https://bugzilla.mozilla.org/show_bug.cgi?= id=3D1403453=C2=A0), that they're conflating requirements on Relyin= g Party applications (i.e. those that verify certificates) and Subscriber a= pplications (i.e. those that serve certificates). Does your RADIUS endpoint= support and use OCSP stapling and disable WiFi if the certificate is expir= ed? No? Then it's a potential violation of this CP/CPS.

This Terms of Use has gems like= (in Section 12)
=C2= =A0Customer will use passwords that
are randomly generated with at least= 16 characters containing uppercase letters, lowercase letters, numbers, an= d symbols
to transport Private Keys. Customer will only allow Customer= =E2=80=99s employees, agents, and contractors to access or use Private
K= eys if the employee, agent, or contractor has undergone a background check = by Customer (to the extent allowed by law)
and has training or experienc= e in PKI and other information security fields.

=
And in Section 16:
=C2=A0 Customer will only use a TLS/SSL Certificate on the servers acce= ssible at the domain names listed in the issued Certificate=C2=A0

Remind me how an EAP-TLS/RADIUS server is accessible= at that domain name? And if someone points their domain name to my server,= would that require revocation?

Or in Section 17:<= /div>
DigiCert may revoke = a Certificate without notice for the reasons stated in the CPS, including i= f DigiCert reasonably believes
that:
...=C2=A0
f. the Certificate was used without authoriza= tion, outside of its intended purpose or used to sign Suspect Code;

id-kp-serverAuth sure does seem to mean "= WWW server", since RFC 5280 states:
=C2=A0 =C2=A0id-kp-serverAuth =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 OBJECT IDENTIFIER ::=3D { id-kp 1 }
=C2=A0 =C2=A0-- TL= S WWW server authentication

This may seem p= edantic and overbroad (OK, it definitely is), but that's the entire met= a-point here.

There's two parts of discussion = from the thread:
1) What do extant clients do, today, in the veri= fication of certificates used in EAP-TLS
2) What should future cl= ients do, 'tomorrow', to make this easier to use and secure, ideall= y by default.

Much of the answer was around #2, wh= ich is "Don't try to glom on to something existing, you need to bu= ild your own thing", as well as "Some of the answers in #1 are pr= oblematic and you should try and discourage them"

=
In the hopes it makes it more accessible, imagine a situation where bo= th Ben and I need gears (widgets, sprockets, take your pick).
Ben= needs gears that are 4cm in diameter and capable of being used in temperat= ures from 0-20 degrees Celsius.
I need gears that are 4cm in diam= eter and capable of being used in temperatures from 0-30 degrees Celsius.
We both get our gears from a single supplier: Cogswell's Cogs<= /div>

Ben has a bunch of spare gears around for my equip= ment, and realizes he can just use my gears in his equipment, and everythin= g just works. Our requirements are seen as compatible. That's convenien= t! However, when Ben approaches Cogswell's Cogs, to sign a supply agree= ment, it's important that the contract doesn't say "Ben will g= et 100 of whatever gears Ryan gets". Instead, Ben should say "Ben= will get 100 gears that are 4cm in diameter and capable of being used in t= emperatures from 0-20 degrees Celsius": what Ben actually requires.

That's because I may (read: will) change my gear= s to be 5cm in the future, and be used in temperatures from 15-45 degrees C= elsius, and those won't work anymore for Ben. However, if Ben's con= tract says "I'll have what Ryan's having", then that'= s what he's going to get, and sad times will be had. I certainly won= 9;t have much sympathy for Ben, when Ben comes asking that I change my equi= pment back to how it used to be, because Ben's needs are different than= my needs, and it's entirely Ben's fault for not specifying his con= tract based on what he required, rather than what I was getting.
=
Similarly, it'd be a bad idea to give instructions to sa= y "Ryan's gears work with Ben's equipment", especially wh= en my specs can and will change. They can even end up completely incompatib= le. For example, Ben might require durable, long-lived gears, because Ben&#= 39;s equipment goes into hard to reach places that are difficult to service= , and thus that they may be made of metal. My gears might be made of metal = now, but that's expensive for the machining and milling, and I may be p= lanning to switch to plastic, as part of ensuring they're mass-market a= ffordable and easily replaceable.=C2=A0

To connect= it back to the discussion: The discussion about revocation, and what a CA&= #39;s CP/CPS says is or isn't allowed for a usage, matters, because bro= wsers require CAs promptly revoke those certificates in 24 hours/5 days for= situations when they specify bad requirements. Can problematic CAs fix the= ir CP/CPS to allow this? Yes. But you've still got a host of other expe= ctations/requirements that can and will diverge, over time.

<= /div>
In the specific context of thinking about "#2" - what a= touch-free future looks like - having it use the same root store as Web br= owsers is the anti-pattern, because the requirements are different. It'= s like Ben saying "I want Ryan's gears", rather than thinking= about "I need gears that are 4cm in diameter, capable of being used i= n temperatures from 0-20 degrees Celsius, and durable enough to be used in = hard to reach places" - and finding someone who can and will manufactu= re those for you. You might end up using Cogwell's Cogs, just like I do= , and it might be that, for a time, our gears are produced on the same prod= uction line - but your requirements and my requirements aren't intertwi= ned.
=C2=A0
Is there anything better for implementations to actually do (as distinct from what we write down as recommendations) than to start setting up a
parallel (purpose-specific) PKI now and trusting that in parallel with what=
they're currently doing, with the hope of being able to have a flag day=
many years down the line when the new PKI becomes the only thing that's=
trusted?

There's no doubt the statu= s quo is "Everything is manually configured" and "It's i= nconsistent what is validated". The goal is to get to #2, "It jus= t works"

- Define your requirements (the cert= ificate profile)
- Define your policies (what do you expect CAs t= o verify, and how do they verify)
- Provide a way to distinguish = "new certificates" from "The old and manual cruft" - fo= r example, an explicit EKU
- Pick your poison.... er, CAs... for = the new root store (e.g. as WiFi Alliance has done, or Wireless Power Conso= rtium has done, or plenty of vendors have done)
- Have CAs issue = certificates with both EKUs (old and new) in the leaf. It's a SEQUENCE = for a reason.
- Have supplicants configured that
=C2=A0= =C2=A0- If new EKU is present, look in built-in store
=C2=A0 =C2= =A0- If old EKU is present, require manual configuration

This gets you half-way to #2: things can just work if you pick one o= f the new-CAs with new-EKUs, and otherwise require manual configuration for= old-EKUs

At that point, supplicant vendors can sl= owly phase out support for 'old EKU'
- If the certificate= is manually generated by the wifi server, it is 'easy' to just gen= erate certificates with the new EKU (potentially with *both* new and old EK= Us)
- If the certificate is coming from a "Web PKI" CA,= it intentionally 'breaks' / makes this case difficult.
<= br>
Similarly, RADIUS/EAP-TLS servers can require, when certifica= tes are being installed, that the 'new' EKU be present (potentially= alongside the 'old' EKU), and that the certificate conforms with t= he 'new' profile.

At some point, down the = line, you can explicitly prohibit the new root store from issuing with id-k= p-serverAuth. Supplicants will all be looking for/requiring the new EKU. Yo= ur RADIUS/EAP-TLS servers will all be requiring the new EKU to be configure= d. But when, where, and how you cross that rubicon is up to y'all, and = that's the only flag day involved: when to turn off the old.
=
--000000000000178c93059c5958d7-- From nobody Fri Jan 17 10:29:48 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E841B120043; Fri, 17 Jan 2020 10:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7h9MfE0IHloL; Fri, 17 Jan 2020 10:29:39 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDB2120025; Fri, 17 Jan 2020 10:29:38 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E2363897D; Fri, 17 Jan 2020 13:29:09 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8F0E05D4; Fri, 17 Jan 2020 13:29:37 -0500 (EST) From: Michael Richardson To: "spasm\@ietf.org" , EMU WG In-Reply-To: References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <10F5CCFB-7DBD-40DF-9C65-BCD0EB8CB838@deployin gradius.com> <48C23DF2-C578-482B-BCC3-69AABDAF983F@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:29:42 -0000 --=-=-= Content-Type: text/plain Alan DeKok wrote: > Perhaps we should try? > $ openssl s_client -connect smtp.mozilla.org:587 -starttls smtp > mozilla.crt > $ openssl x509 -text -in mozilla.crt You omitted an important part of that output, which is the name of the CA, which I include below. It could be that the CSP permits SMTP, or SUBMISSION service. Ryan has suggested that CAs could put EAP-TLS (or EAP-TEAP) into their CSP, and that also seems like an out. Certainly, some of the excitement for ACME/Letsencrypt with DNS-01 challenge is that it makes it easy to get a certificate for a non-HTTP thing. I think we need to fix the lawyers, not the protocol. The detail: Issuer: C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA Subject: C = US, ST = California, L = Mountain View, O = Mozilla Corporation, OU = WebOps, CN = smtp.mozilla.org But, let's do some more tests: dooku-[/var/tmp](2.6.5) mcr 10051 %host letsencrypt.org letsencrypt.org has address 162.243.166.170 letsencrypt.org has IPv6 address 2604:a880:400:d1::89c:7001 letsencrypt.org mail is handled by 5 alt2.aspmx.l.google.com. dooku-[/var/tmp](2.6.5) mcr 10052 %echo QUIT | openssl s_client -connect alt2.aspmx.l.google.com:25 -starttls smtp >| letsencrypt.crt dooku-[/var/tmp](2.6.5) mcr 10053 %openssl x509 -text -in letsencrypt.crt| grep Issuer Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1 CA Issuers - URI:http://pki.goog/gsr2/GTS1O1.crt What do CA's do? dooku-[/var/tmp](2.6.5) mcr 10054 %host digicert.com digicert.com has address 45.60.121.229 digicert.com has address 45.60.131.229 digicert.com mail is handled by 20 us-smtp-inbound-2.mimecast.com. dooku-[/var/tmp](2.6.5) mcr 10055 %echo QUIT | openssl s_client -connect us-smtp-inbound-2.mimecast.com:25 -starttls smtp >| digicert-smtp.crt depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2 dooku-[/var/tmp](2.6.5) mcr 10056 %openssl x509 -text -in digicert-smtp.crt| grep Issuer Issuer: C = US, O = DigiCert Inc, CN = DigiCert Global CA G2 CA Issuers - URI:http://cacerts.digicert.com/DigiCertGlobalCAG2.crt What's that quote about doctor's fixing themselves? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4h/REACgkQgItw+93Q 3WXGugf/eBSrfB/tfnB0ZAGdmtm0DS6IpW65poaDmMSyfGN38kwpIYd58gPKskZH yuKeEqEnlQmo26a1nE47xkTSfZr387P+SmylXinTEIN14DnWQ+ErvrPBjCkBrBgM FLHVApIiMb9nWA6UlLjUl4qE8ufjByA33Pt7ahn3Ydz5FXF1fLtlqOxOtVFePxY9 EzMowJrBipRvZqrFvcvQF5mQLJRmokZTWdZ9OHH00jymDsLmdbluB8fUXl93dRiD NEv9/VlgyUsNIAokAUb/ZOfIi+f1q5NqOo94Y0OJypA7Nx1D28Fp0+Mv+ma5x21l JM1FNsMs4Ekp0l/nKhEM6lo7FS6DnA== =fYSY -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 17 10:40:30 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1A912007C; Fri, 17 Jan 2020 10:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 S2afZbqzVza7; Fri, 17 Jan 2020 10:40:23 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A63120025; Fri, 17 Jan 2020 10:40:23 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 7685138AE; Fri, 17 Jan 2020 18:40:20 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: <3821.1579285777@localhost> Date: Fri, 17 Jan 2020 13:40:18 -0500 Cc: "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <0C1CC4B9-9E38-4656-B2FB-5DE3C671015A@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <10F5CCFB-7DBD-40DF-9C65-BCD0EB8CB838@deployin gradius.com> <48C23DF2-C578-482B-BCC3-69AABDAF983F@cisco.com> <3821.1579285777@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:40:29 -0000 On Jan 17, 2020, at 1:29 PM, Michael Richardson = wrote: > You omitted an important part of that output, which is the name of the = CA, > which I include below. Sure. > It could be that the CSP permits SMTP, or SUBMISSION service. > Ryan has suggested that CAs could put EAP-TLS (or EAP-TEAP) into their = CSP, > and that also seems like an out. I agree. > Certainly, some of the excitement for ACME/Letsencrypt with DNS-01 = challenge > is that it makes it easy to get a certificate for a non-HTTP thing. >=20 > I think we need to fix the lawyers, not the protocol. That is likely the best approach. At this point, use of = id-kp-serverAuth is wide-spread *outside* of HTTP. EAP / RADIUS is not = unique in it's mis-use of that OID. As such, this discussion should more productively focussed on non-HTTP = mis-uses of id-kp-serverAuth. Which means pretty much everything using = TLS. Alan DeKok. From nobody Fri Jan 17 11:39:34 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878C91200CD; Fri, 17 Jan 2020 11:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 KDsyOGHEWvws; Fri, 17 Jan 2020 11:39:23 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43D11200A4; Fri, 17 Jan 2020 11:39:22 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 0FB2EC9C; Fri, 17 Jan 2020 19:39:19 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Fri, 17 Jan 2020 14:39:17 -0500 Cc: Benjamin Kaduk , Joseph Salowey , "spasm@ietf.org" , Michael Richardson , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 19:39:24 -0000 On Jan 17, 2020, at 12:33 PM, Ryan Sleevi wrote: > Does your RADIUS endpoint support and use OCSP stapling and disable = WiFi if the certificate is expired? No? Then it's a potential violation = of this CP/CPS. I'm not sure how a RADIUS server will disable WiFi. They are = entirely separate systems. > And in Section 16: > Customer will only use a TLS/SSL Certificate on the servers = accessible at the domain names listed in the issued Certificate=20 >=20 > Remind me how an EAP-TLS/RADIUS server is accessible at that domain = name? The RADIUS server has a domain name, which is commonly used in the = certificate. If that is insufficient for the CAs purposes, then we should also = acknowledge that the revocation requirement likely also applies to SMTP, = XMPP, DNS over TLS, and IMAP. i.e. *all* non-WWW protocols which use = TLS. We should not single-out EAP / RADIUS as mis-using the certificates in = this manner. The mis-use of these certificates in other protocols is = orders of magnitude larger than the EAP / RADIUS problem. > There's two parts of discussion from the thread: > 1) What do extant clients do, today, in the verification of = certificates used in EAP-TLS EAP supplicants follow RFC 5216 Section 5.3. > 2) What should future clients do, 'tomorrow', to make this easier to = use and secure, ideally by default. > Much of the answer was around #2, which is "Don't try to glom on to = something existing, you need to build your own thing", True. > as well as "Some of the answers in #1 are problematic and you should = try and discourage them" There were *allegations* of problems. > To connect it back to the discussion: The discussion about revocation, = and what a CA's CP/CPS says is or isn't allowed for a usage, matters, = because browsers require CAs promptly revoke those certificates in 24 = hours/5 days for situations when they specify bad requirements. Can = problematic CAs fix their CP/CPS to allow this? Yes. But you've still = got a host of other expectations/requirements that can and will diverge, = over time. If I was mean, I would write scripts to troll the net for mis-use of = certificates in SMTP, XMPP, IMAP, VPNs, etc. Then, make the script = auto-submit notices to the relevant CAs. That process is simple to do, = and by the above rules, would require the CAs to revoke the relevant = certs. i.e. certs which affect a high percentage of daily internet traffic. If that scenario were to play out, I suspect that CAs would very = quickly stop revoking the relevant certs. A straight-forward approach = to enforcing the rules would be over-ruled by simple practicalities: = Turning off big chunks of the Internet is a non-starter. As Michael Richardson pointed out, then solution here is likely to fix = the rules, not the protocols. > In the specific context of thinking about "#2" - what a touch-free = future looks like - having it use the same root store as Web browsers is = the anti-pattern, because the requirements are different. And therefore we need a different root store for *each* of EAP, = RADIUS, SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc. Note that we need = *different* stores for EAP and RADIUS, because RADIUS server are = reachable on port 2083 as RADIUS over TLS, *and* they implement TLS over = EAP, which in turn carried over RADIUS. Different use-cases, different = root stores. There may be significant push-back against that many root stores. > There's no doubt the status quo is "Everything is manually configured" = and "It's inconsistent what is validated". The goal is to get to #2, "It = just works" >=20 > - Define your requirements (the certificate profile) > - Define your policies (what do you expect CAs to verify, and how do = they verify) > - Provide a way to distinguish "new certificates" from "The old and = manual cruft" - for example, an explicit EKU > - Pick your poison.... er, CAs... for the new root store (e.g. as WiFi = Alliance has done, or Wireless Power Consortium has done, or plenty of = vendors have done) > - Have CAs issue certificates with both EKUs (old and new) in the = leaf. It's a SEQUENCE for a reason. > - Have supplicants configured that > - If new EKU is present, look in built-in store > - If old EKU is present, require manual configuration >=20 > This gets you half-way to #2: things can just work if you pick one of = the new-CAs with new-EKUs, and otherwise require manual configuration = for old-EKUs That's good, but insufficient. There is a lot more verification that = EAP supplicants need to do before automatically trusting a root CA. I suspect that most CAs already know that their customers mis-use = certs for non-WWW purposes. EAP / RADIUS is just a minor (almost = insignificant) part of this problem. I also suspect most CAs operate = based on the hope that no one notices, and then requires them to revoke = many, many, certificates. Alan DeKok. From nobody Fri Jan 17 14:19:46 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4085012006B; Fri, 17 Jan 2020 14:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vSl_FTD4no0D; Fri, 17 Jan 2020 14:19:41 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A8A120041; Fri, 17 Jan 2020 14:19:40 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 00C443897D; Fri, 17 Jan 2020 17:19:10 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 71CC45D4; Fri, 17 Jan 2020 17:19:39 -0500 (EST) From: Michael Richardson To: "spasm\@ietf.org" , EMU WG X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:19:44 -0000 --=-=-= Content-Type: text/plain {I've intentionally broken the thread, and I'm restarting the discussion. Please forgive the length} Alan DeKok wrote: >> Certainly, some of the excitement for ACME/Letsencrypt with DNS-01 challenge >> is that it makes it easy to get a certificate for a non-HTTP thing. >> >> I think we need to fix the lawyers, not the protocol. > That is likely the best approach. At this point, use of > id-kp-serverAuth is wide-spread *outside* of HTTP. EAP / RADIUS is not > unique in it's mis-use of that OID. I went back to your message at: https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM to be sure what the state of the art is today: } a) the current practice in TLS-based EAP methods is to use certificates with } "id-kp-serverAuth" OID set for Extended Key Usage. } b) many supplicants check for this OID, and refuse to perform authentication } if it is missing } c) supplicants do not check DNS names or any other field in the certificates } d) as a result of this lack of verification, supplicants ship with all known } CAs disabled for TLS-based EAP methods" [c] is a problem that we partly want to fix. [a] LetsEncrypt and other ACME mechanism technically work to get certificates from public CAs that can be used for this. These certificates can, and *ARE* being used for SMTP, XMPP, as well as HTTPS. Using these certificates for things other than HTTPS might violate the CSP of the CAs involved, one would have to read the relevant CSPs. At least one CA is using a certificate that would appear to be a "stock" HTTPS certificate on an SMTP server. I know dozens of places that have wildcard certificates (which all bind to the same private key, which I really rather hate) which are then used for all manner of things. I think I've seen certificates being advertised for use in email servers, but I'd have to go back and be sure. Let's go back to the start with goals and requirements. 0) there is nothing broken with manual provisioning of private CAs to be used in Enterprise-WPA (EAP-TLS, etc.) uses of EAP/802.1X. This can continue as is. The server certificate needs to have id-kp-serverAuth OID set in order to be trustable by comododity clients as deployed today. There is very little use of additional OIDs, even those some have been defined. Clients do not insist upon them, and *as a result*, it is technically possible to use certificates issued by public CAs here. 1) we have some protocols that do autonomic onboarding of devices. BRSKI is one such protocol. Not the first, but the most public and most cross-vertical one. But probably it won't be the last one! **BRSKI does not require that the domain owner have a public CA** In fact, BRSKI provides a mechanism that permit a devices to autonomically develop trust in a private CA via the pinned voucher artifact. One can proceed to do EST/RFC7030 if one wants after and get the local list of of private CAcerts. In some wired situations it is also possible to use *JUST* EST/RFC7030 for enrollment, if the client(pledge) is willing to trust the certificate of the server, such as because it comes via public trust. I will note that EST uses HTTPS, and having a name from a public CA could not reasonably break any CSP. While the CAFORUM rules forbid certificates for private names (foobar.corp, foobar.internal), and it also forbids issuance for RFC1918 addresses, it currently permits certificates for public names (foo.example.com), even if those addresses have AAAA only IP addresses, and it currently makes no statement about ULA AAAA addresses in public names. Whether this is a loophole of intention or omission, I don't know. (I have running code) There are a number of industrial uses for EST/RFC7030 where the interest is in validating the IDevID of the pledge in order to detect counterfeit products. It is not apparent how this (EST-only) can be done over WiFi in an autonomic way, and thus this is one of the places for BRSKI protocols like BRSKI-TEAP. But, again BRSKI does not require a public CA/name. 2) BRSKI (-like) protocols suggest that the domain owner (the Registrar) be connected to a private CA to issue LDevID. There is a desire to simplify this requirement in order to make use of ACME based systems to replace the local Registrar/CA. (see draft-friel-acme-integrations, and also draft-moriarty-acme-client and draft-moriarty-acme-overview ) It is certainly the case that use of LetsEncrypt via ACME is a significant carrot. For smaller operator (including residential and SOHO), there is SIGNIFICANT interest. draft-moriarty-acme-client writes: 3. End User Client Certificates A client certificate used to authenticate an end user may be used for mutual authentication in TLS, ***EAP-TLS***, or messaging. The client (to be very very very clear: not a consensus document at this point!!!!) [See followup message, I don't want to distract this thread too much] 3) If the Registrar (which is probably also the EAP-TLS/EAP-TEAP authenticator end-point) has a certificate from a public CA, (and this is pinned in an RFC8366 voucher), then there become a few challenges due to a desire to: a) change / rekeying the public key. Pinning the CA+DN rather than the EE cert can solve this, at the cost of adding complexity to the pledge. b) being able to change from CA X to Y, which means that only the DN can be pinned. In effect, the rfc822Name! Note that the voucher is typically only evaluated at onboarding time. In an online (nonced) process, then that happens mere seconds after the voucher is issued, and the changes in (a) and (b) do not matter much. During the EST process, the pledge can get trust anchors with which to validate the Registrar/Authentication-Server. The specific CA which is currently being used can be returned. It matters little whether it is public or private. {I personally do not think that running a private CA is that big a deal if you are willing to write a hundred lines of code to manage it. It certainly is a pain if you expect the operator to use openssl command line! (But, then I'm regularly told that my solutions are too complex for regular people)} The trust anchor will get used regularly to do EAP/WPA operations from the device. The ability to validate the certificate is not affected by the (a) change above. The problem is that as currently described, we do not say to pin the DN. So *ANY* name from that CA will be valid for that connection. In the case of public CA, then this means that the client would connect to any network that has an EE from the same CA. That's way too easy to spoof. Hell, it can occur easily by non-malicious actors: just two offices or houses within WIFI distance. And as described above, there is currently no validation of the DN by current clients, nor is there validation of extensions. The (b) switch is probably, in my opinion, not tractable easily. RFC7030's /cacerts (section 4.1.3) returns the certificates (plural) are returned. If the (b) switch could be coordinated enough in advance to permit normal RFC7030 renewals to get the Y trust anchor that could work. =============== So, it seems that we ought to: a) suggest that EAP-TLS (and EAP-TEAP) clients should include the DN (rfc822Name) of the certificate that they should be talking to. b) we should perhaps have an OID extension in the CA certificate (trust anchor) that says if the CA will use the id-kp-eapOverLAN bit or not. (or other extensions) If so, then the client should insist that the resulting extension be present. Maybe there is another way to do this that would be easier, but this makes sense to me. c) We may want to Update RFC7030 /cacerts to say something about creating an expiry/retry time in the certs-only CMC Simple PKI Repsonse. I don't see a date in a RFC5652 Signed-Only certs-only container that could be used to cause pledges to get the /cacerts earlier than the expiry time of the CA. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4iMvsACgkQgItw+93Q 3WW0igf9HkWCzhAL0YGY30YxRtX5niDiyOsmsWGHJtmoSxM59dVkCMxMu5VlReJh ydFw1rZhJBglWIFFRTl7VXwyx4yMfjNhwvJD9/QYAHeX/6EFleII2cfmQ/wPO3/T BqpGpEimwQWSBcENMNqagAD6/MD6r0smlb2izex27buJDSK9FSopwsZW0pSf5/Vu ogE0EtXmqg5sYBU+4aOu0F6F2PoJYqYE56fS3Hv5lT2b84ZMW50nOZCjs58rJslo jhB4qDL1XhZmQdrhHDuOGC30bIUefMHz9v+jegGjqyZKcxbC/G1tmhLsKlh8PU2N LsyWoQ4PHo1Pq9fYPfNid6HK/3/UMA== =nQQS -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 17 14:30:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FAD12008D; Fri, 17 Jan 2020 14:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 A2SsNVH0V9EJ; Fri, 17 Jan 2020 14:30:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E0712006B; Fri, 17 Jan 2020 14:30:31 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2D47F3897D; Fri, 17 Jan 2020 17:30:02 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A096C5D4; Fri, 17 Jan 2020 17:30:30 -0500 (EST) From: Michael Richardson To: "spasm\@ietf.org" , EMU WG In-Reply-To: References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:30:37 -0000 --=-=-= Content-Type: text/plain Ryan Sleevi wrote: > While I think people are missing the forest for the tree, here's an > example CP/CPS from a CA: > https://www.certsign.ro/media/document/ZytpRDNNUTFHR01Ra2MxVUx4REdQZz09/original/CPS%20OV%20SSL_v%201.10_April%202019.pdf certsign.ro uses a Fortinet.com certificate on their SMTP server. Does Fortinet.com's CSP permit SMTP usage? The certificate does not have the serverAuth bit set. > Customer will only use a TLS/SSL Certificate on the servers > accessible at the domain names listed in the issued Certificate > Remind me how an EAP-TLS/RADIUS server is accessible at that domain > name? And if someone points their domain name to my server, would that > require revocation? "accessible" is not defined. maybe CAFORUM needs to write port 443 from now on? If you were part of eduroam, and you uses ryan-ietf@sleevi.com as your identity, then the roaming mechanism would connect eventually to your Radius server using that name. Thus, it is accessible. Your gear analogy is understood, but for many of us, we see the specs as having been designed by lawyers rather than engineers in order to maximize profit and minimize interoperability. I'm not arguing we are right. It just feels like needless and wastefully restrictive attempts to create market verticals. > In the specific context of thinking about "#2" - what a touch-free > future looks like - having it use the same root store as Web browsers > is the anti-pattern, because the requirements are different. And yet, almost every single thing out there would like to be connected to by a browser. They can't, so we have an app-per-thing, and/or no-security. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4iNYYACgkQgItw+93Q 3WUKUQf7B8hEFEaC34TFatk38gYEmKkldj1u1tPg+mQPPqiM/OC//HbXoHaWJHAW 1apj5hh7tVHuSJ/p/P8HoNzUK3lC9ZQxQZnBucgSa6/gxDJWTgm6OXkgEbS4fyoR h+B4pwjGGZb6MRidNPOV0mqd8yJ4ITbvoOA/t6bLsopeq57b+7d3410ifiJJceWo wL/PbjnNFoUC/E5tZYPCrXL//8s9MFUq9sZf1fVJgDPX483DRafVwo9g1HrSsCaQ iYVKeg4GVFZKocrnbEsoOf8i6yYWt3vQT4J281k3i71FZUFQdUxGFK+ghULUOU8G vKkQXLYO7ZrIUvnFeb2UXmcrG6rzbQ== =i0pU -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 17 14:33:17 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5EC12008D; Fri, 17 Jan 2020 14:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CNkvxwcaDT4B; Fri, 17 Jan 2020 14:33:14 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522E7120026; Fri, 17 Jan 2020 14:33:14 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id ED6843B7; Fri, 17 Jan 2020 22:33:11 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: <26119.1579299579@localhost> Date: Fri, 17 Jan 2020 17:33:10 -0500 Cc: "spasm@ietf.org" , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <26119.1579299579@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] Using public CA infrastructure for autonomic bootstrapping over EAP. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:33:17 -0000 On Jan 17, 2020, at 5:19 PM, Michael Richardson = wrote: > } c) supplicants do not check DNS names or any other field in the = certificates > } d) as a result of this lack of verification, supplicants ship with = all known > } CAs disabled for TLS-based EAP methods" For (d), CAs are disabled also because of protocols like EAP-TTLS with = embedded PAP. If the supplicant trusted a root CA, then it would trust = any certificate signed by that CA, and expose the users clear-text = password to anyone. Supplicants now check: * for a named SSID * the CA is manually enabled for that SSID * the server certificate is known (pre-configured or downloaded and = cached) All of those conditions have to be met before EAP is performed. > [c] is a problem that we partly want to fix. Yes. > Let's go back to the start with goals and requirements. >=20 > 0) there is nothing broken with manual provisioning of private CAs to = be used > in Enterprise-WPA (EAP-TLS, etc.) uses of EAP/802.1X. This can = continue > as is. The server certificate needs to have id-kp-serverAuth OID = set in > order to be trustable by comododity clients as deployed today. > There is very little use of additional OIDs, even those some have = been defined. > Clients do not insist upon them, and *as a result*, it is = technically > possible to use certificates issued by public CAs here. Yes. I've omitted BSRKI comments. I have less to contribute there > So, it seems that we ought to: > a) suggest that EAP-TLS (and EAP-TEAP) clients should include the DN > (rfc822Name) of the certificate that they should be talking to. I'm not clear on "include". > b) we should perhaps have an OID extension in the CA certificate = (trust > anchor) that says if the CA will use the id-kp-eapOverLAN bit or = not. > (or other extensions) > If so, then the client should insist that the resulting extension = be present. > Maybe there is another way to do this that would be easier, but = this > makes sense to me. There may be other ways. Taken to the extreme, each use-case for TLS = should have its own OID. I don't know that there's a good solution here. On a related note, Stefan Winter had a proposal for a standard = configuration for EAP: https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-02 That would seem to solve all of the provisioning problem. There are = still verification problems. I suspect we need to clearly separate the two situations, i.e.: 1) a supplicant magically has the information it needs to authenticate. = What does that information look like? What's in the certs? 2) a supplicant is unconfigured, how is it possible to get the = supplicant to state (1) above? Is the information available in state = (1) helpful for provisioning? Alan DeKok. From nobody Fri Jan 17 14:40:47 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0228E12006B; Fri, 17 Jan 2020 14:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QQ7aCk_ua_W7; Fri, 17 Jan 2020 14:40:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674F612004C; Fri, 17 Jan 2020 14:40:37 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A443D3897D; Fri, 17 Jan 2020 17:40:08 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 339975D4; Fri, 17 Jan 2020 17:40:37 -0500 (EST) From: Michael Richardson to: "spasm\@ietf.org" , EMU WG In-Reply-To: <26119.1579299579@localhost> References: <26119.1579299579@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [lamps] using public CAs for IDevID and device certificates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 22:40:41 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > 3. End User Client Certificates > A client certificate used to authenticate an end user may be used for > mutual authentication in TLS, ***EAP-TLS***, or messaging. The client > (to be very very very clear: not a consensus document at this point!!!!) > [See followup message, I don't want to distract this thread too much] It would also be very nice to be use LetsEncrypt for device certificates, and draft-moriarty-acme-client speaks to some of this, but given 90-day LetsEncrypt expiry, that won't fly. (I have running code that deals with the factory processing) Having an IDevID on a thing (router, appliance, home router) with a public CA trust path means that one connect to it from a stock browser/smartphone without error. Yes, that implies the thing has a name (the name is in the certificate), and that the name is resolvable by the browser, at least locally. That's possible, particularly given IPv6 ULA AAAA RR for home routers, but also using local DNS mechanisms. (again, I have running code) It is, sadly, not feasible to buy certificates from a public CA, as the current CAFORUM 2yr (25 month) limit won't work for most supply chain logistics. The CAFORUM has been discussing 13 month limits, with noises for even shorter terms. I read the lists for awhile, but I don't know if 13 months went to a vote yet. Okay, I thought: no problem, just get an Enterprise sub-CA with a nameconstraint limiting issued certificates. That was a thing at one point. Surely, I can then control the expiry dates myself? There was even a CVE about windows-server not validating the name constrained correctly a decade ago. I did persue this anyway about a year ago with a few CAs. Only one of them actually could spell "Enterprise CA"!! It's just not offered, as a result, I think of the newer CAFORUM rules. I am sad, but I understand why it happened. yes, Enterprise CAs were in order O($10K-USD), but spread over 100K+ product instances, that's not a huge cost. I was offered a hosted sub-CA. If I wanted it to have a public trust anchor, the price was $450/certificate. (Yes, I got the decimal place right. I did ask for confirmation here twice. I was expecting $4.50/certificate, with some minimal commitment, given that it would have a PathNameConstraint). That's for a 25 month certificate, which I thought, maybe is long enough for the step after proof-of-concept. With BRSKI ANIMA/ACP, selling into Operators and Enterprises, using a private CA for the IDevID is just barely acceptable, as those operators can just probably configure new trust anchors into the Registrar. Maybe. With good enough software. Maybe we can come up with some additional mechanism, maybe involving SRV and/or TLSA records. This probably won't fly into the residential or SOHO space, thus the interest in either having a public trust anchor for IDevID signing, or... CREATING A NEW SET OF semi-public CAs. Honestly, this project would be simple compared to what I've seen of the US Federal cross-CA system :-) I wrote two documents in December which I'd appreciate feedback on: 1) Operational Considerations for Manufacturer Authorized Signing Authority draft-richardson-anima-masa-considerations-01 This is about the private CA used to sign the IDevID. 2) Operational Considerations for BRSKI Registrar draft-richardson-anima-registrar-considerations-01 This is about the private CA that the operator is expected to run. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4iN+QACgkQgItw+93Q 3WV9NwgAqHYj75eMjgV7FzqSWgbwDH01m2K9B55tGNN3joma745lWxbRym6/OIdI +gC9jwG6Kd31aMlM+rsdKFhjGn5DhTpbRPyRxLEyjiog7kJUnxgNSKJmNnLXnlyP v+x/svaeTGVNbg+iZrNpXGahlZQbSYH9qObYg/DP+wJFsVzsKyKAw/6Q0qISAE7j qbyWqducogQuZqoOoFDRaBqFZ9r3a/AfXevuk/RPvAfjECx0tagAsux9NfC9RyCZ qB2CHSv7W84RHBzXvwnBi4VNWLv2vsXMp1aZOXgyHyWWzgqvKgllCp/bt77VKsZ2 qJigMSWinCrBCISoFnarV8KC8WRM1Q== =3QY1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 17 19:47:42 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24C11200B8; Fri, 17 Jan 2020 19:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 595kqj6u3_j9; Fri, 17 Jan 2020 19:47:37 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E771200B1; Fri, 17 Jan 2020 19:47:37 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00I3lWAI008156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 22:47:35 -0500 Date: Fri, 17 Jan 2020 19:47:32 -0800 From: Benjamin Kaduk To: Michael Richardson Cc: "spasm@ietf.org" , EMU WG Message-ID: <20200118034732.GZ80030@kduck.mit.edu> References: <26119.1579299579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26119.1579299579@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP. X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 03:47:41 -0000 Hi Michael, You mention in a couple places that EAP server certificate should be identifying an rfc822Name DN, and I think I'm confused about what you mean. (I suspect I'm seeing "rfc822Name" and jumping to what ACP does, which is wrong.) Could you walk through an example of what that would look like to help un-confuse me? Thanks, Ben On Fri, Jan 17, 2020 at 05:19:39PM -0500, Michael Richardson wrote: > > {I've intentionally broken the thread, and I'm restarting the discussion. > Please forgive the length} > > Alan DeKok wrote: > >> Certainly, some of the excitement for ACME/Letsencrypt with DNS-01 challenge > >> is that it makes it easy to get a certificate for a non-HTTP thing. > >> > >> I think we need to fix the lawyers, not the protocol. > > > That is likely the best approach. At this point, use of > > id-kp-serverAuth is wide-spread *outside* of HTTP. EAP / RADIUS is not > > unique in it's mis-use of that OID. > > I went back to your message at: > https://mailarchive.ietf.org/arch/msg/spasm/S4tO5yE_HP9CC6qd8WudY9Ln3oM > > to be sure what the state of the art is today: > } a) the current practice in TLS-based EAP methods is to use certificates with > } "id-kp-serverAuth" OID set for Extended Key Usage. > } b) many supplicants check for this OID, and refuse to perform authentication > } if it is missing > } c) supplicants do not check DNS names or any other field in the certificates > } d) as a result of this lack of verification, supplicants ship with all known > } CAs disabled for TLS-based EAP methods" > > [c] is a problem that we partly want to fix. > [a] LetsEncrypt and other ACME mechanism technically work to get certificates > from public CAs that can be used for this. > > These certificates can, and *ARE* being used for SMTP, XMPP, as well as HTTPS. > Using these certificates for things other than HTTPS might violate the CSP of > the CAs involved, one would have to read the relevant CSPs. > At least one CA is using a certificate that would appear to be a "stock" > HTTPS certificate on an SMTP server. > I know dozens of places that have wildcard certificates (which all bind to > the same private key, which I really rather hate) which are then used for all > manner of things. > I think I've seen certificates being advertised for use in email servers, but > I'd have to go back and be sure. > > Let's go back to the start with goals and requirements. > > 0) there is nothing broken with manual provisioning of private CAs to be used > in Enterprise-WPA (EAP-TLS, etc.) uses of EAP/802.1X. This can continue > as is. The server certificate needs to have id-kp-serverAuth OID set in > order to be trustable by comododity clients as deployed today. > There is very little use of additional OIDs, even those some have been defined. > Clients do not insist upon them, and *as a result*, it is technically > possible to use certificates issued by public CAs here. > > 1) we have some protocols that do autonomic onboarding of devices. > BRSKI is one such protocol. Not the first, but the most public and most > cross-vertical one. But probably it won't be the last one! > > **BRSKI does not require that the domain owner have a public CA** > > In fact, BRSKI provides a mechanism that permit a devices to autonomically > develop trust in a private CA via the pinned voucher artifact. > One can proceed to do EST/RFC7030 if one wants after and get the local > list of of private CAcerts. > > In some wired situations it is also possible to use *JUST* EST/RFC7030 for > enrollment, if the client(pledge) is willing to trust the certificate of > the server, such as because it comes via public trust. I will note that > EST uses HTTPS, and having a name from a public CA could not reasonably > break any CSP. > > While the CAFORUM rules forbid certificates for private names > (foobar.corp, foobar.internal), and it also forbids issuance for RFC1918 > addresses, it currently permits certificates for public names (foo.example.com), even > if those addresses have AAAA only IP addresses, and it currently makes no > statement about ULA AAAA addresses in public names. > Whether this is a loophole of intention or omission, I don't know. > (I have running code) > > There are a number of industrial uses for EST/RFC7030 where the interest > is in validating the IDevID of the pledge in order to detect counterfeit > products. > It is not apparent how this (EST-only) can be done over WiFi in an > autonomic way, and thus this is one of the places for BRSKI protocols like > BRSKI-TEAP. But, again BRSKI does not require a public CA/name. > > 2) BRSKI (-like) protocols suggest that the domain owner (the Registrar) be > connected to a private CA to issue LDevID. There is a desire to simplify > this requirement in order to make use of ACME based systems to replace the > local Registrar/CA. (see draft-friel-acme-integrations, and also > draft-moriarty-acme-client and draft-moriarty-acme-overview ) > > It is certainly the case that use of LetsEncrypt via ACME is a significant > carrot. For smaller operator (including residential and SOHO), there is > SIGNIFICANT interest. > > draft-moriarty-acme-client writes: > 3. End User Client Certificates > > A client certificate used to authenticate an end user may be used for > mutual authentication in TLS, ***EAP-TLS***, or messaging. The client > > (to be very very very clear: not a consensus document at this point!!!!) > [See followup message, I don't want to distract this thread too much] > > 3) If the Registrar (which is probably also the EAP-TLS/EAP-TEAP > authenticator end-point) has a certificate from a public CA, (and this is > pinned in an RFC8366 voucher), then there become a few challenges due to a desire to: > > a) change / rekeying the public key. > Pinning the CA+DN rather than the EE cert can solve this, at the cost > of adding complexity to the pledge. > > b) being able to change from CA X to Y, which means that only the DN can > be pinned. In effect, the rfc822Name! > > Note that the voucher is typically only evaluated at onboarding time. > In an online (nonced) process, then that happens mere seconds after the > voucher is issued, and the changes in (a) and (b) do not matter much. > > During the EST process, the pledge can get trust anchors with which to validate > the Registrar/Authentication-Server. The specific CA which is currently > being used can be returned. It matters little whether it is public or > private. > > {I personally do not think that running a private CA is that big a deal if > you are willing to write a hundred lines of code to manage it. It > certainly is a pain if you expect the operator to use openssl command line! > (But, then I'm regularly told that my solutions are too complex for regular people)} > > The trust anchor will get used regularly to do EAP/WPA operations from the device. > The ability to validate the certificate is not affected by the (a) change > above. > > The problem is that as currently described, we do not say to pin the DN. > So *ANY* name from that CA will be valid for that connection. In the case > of public CA, then this means that the client would connect to any network > that has an EE from the same CA. That's way too easy to spoof. Hell, it > can occur easily by non-malicious actors: just two offices or houses > within WIFI distance. > > And as described above, there is currently no validation of the DN by > current clients, nor is there validation of extensions. > > The (b) switch is probably, in my opinion, not tractable easily. > RFC7030's /cacerts (section 4.1.3) returns the certificates (plural) are > returned. If the (b) switch could be coordinated enough in advance to > permit normal RFC7030 renewals to get the Y trust anchor that could work. > > =============== > > So, it seems that we ought to: > a) suggest that EAP-TLS (and EAP-TEAP) clients should include the DN > (rfc822Name) of the certificate that they should be talking to. > > b) we should perhaps have an OID extension in the CA certificate (trust > anchor) that says if the CA will use the id-kp-eapOverLAN bit or not. > (or other extensions) > If so, then the client should insist that the resulting extension be present. > Maybe there is another way to do this that would be easier, but this > makes sense to me. > > c) We may want to Update RFC7030 /cacerts to say something about creating > an expiry/retry time in the certs-only CMC Simple PKI Repsonse. > I don't see a date in a RFC5652 Signed-Only certs-only container that > could be used to cause pledges to get the /cacerts earlier than the > expiry time of the CA. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jan 17 21:34:52 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4563C12007A; Fri, 17 Jan 2020 21:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=EdjGeIjI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OR6jnlb5 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 FWs22m64hQEo; Fri, 17 Jan 2020 21:34:48 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EC8120058; Fri, 17 Jan 2020 21:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6417; q=dns/txt; s=iport; t=1579325688; x=1580535288; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LYL4YvstfqzvExiFO9cgY89Gl+btX43/rz4pyNGk/LU=; b=EdjGeIjIVHxn+9WwR54Q6qsDaj8TYYFH2wkX3w8CAOreew8HYFTEdGen 7CEAvQH1mpthbcEO2EYLfQKZ1UPk7LkP1wiOtkAvS7UJlgcmEm8t5Heze Ld8vuzi/7u9Wc3WSKf8U7FfRXO4NEqzN1yw8cV2/CJvG3eLPU0gJkHJYh o=; IronPort-PHdr: =?us-ascii?q?9a23=3A7UgETB+8Tf9iE/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcmLE0z2KNbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAAAClyJe/4YNJK1cCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBe4FUKScFbFggBAsqh1cDinqCX5gOglIDVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGEQAKCCiQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAgE?= =?us-ascii?q?BARAoBgEBJQcLAQQHBAIBCBEEAQEBGQICARAnCx0IAgQBDQUIDAcHgwWCSgM?= =?us-ascii?q?OIAECDKBxAoE5iGGCJ4J/AQEFhQMYggwDBoE2jBQagUE/gRFHgkw+gmQBAYE?= =?us-ascii?q?5DgYYXAKCYoIsjVI7iEaCIZVmdgqCOZZLmnKCDYQRiD6bBQIEAgQFAg4BAQW?= =?us-ascii?q?BaSKBWHAVO4JsUBgNWIcpgScBCYJChRSFP3SBKT+JPAImAgWBNV8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,333,1574121600"; d="scan'208";a="408065524" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jan 2020 05:34:46 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 00I5Yk19004581 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 18 Jan 2020 05:34:46 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Jan 2020 23:34:46 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 17 Jan 2020 23:34:45 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 18 Jan 2020 00:34:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ONtiCw3OwVKR8f2wny6gcl4bQZVvJ73Ejc07NK3rXsw2z/0+FYi+d0LAQcSd5QUWl5NIH2MObCwUOX0QUoChFRgUAf5EpkXV5R8Wi53Z+w0bSgwcYELZJAUsnWaAysOcDDY5ahx6e0A8KmY3ao+W1Bj8tKmg76Oe3kz/b42KspjASo+tn8XaMEIKCz9KnAh9VI0SqpYOEoszIQBJhb8glXzMw2kkrb+0G9bGCbCys9dW3dZzv46cmBz+ECXcNBH8nirSTWpQpwahoWaJbbOkvhY7xcDngiJqJ9h4F26yE4Tx/izXJAk5cMEeuYZngNwMk6gkT4xT8nPNrKgAHW+/pQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YBk5pfrNKdeS5K4XqGvE1+Nd3fmWWZy4fVa1ijw+jRw=; b=Yw7FPeNnWSg9uoT5IEcNY1nH2KwGjLKrqtJxidf5dVBFfOhGcBPlGUk9J0Y94VJPIhRTiRpMXV2tHsf9PnnLf1ru1ENOmAmaiAWTmdD5a9MzYohmMDNrfcgwj0ej2d1ERxujbiZmTecHqo34gCNTDY8JroQEFElCD2CBBDdDEXy0oXhVnyAnUUIxLfgbmls0DEF+5nVpELn/yJ8jbEz9RYBs6ww7Hmhl2M4faIxkg5lTWag9cBp3vpqnxI4N3NwxjXahZ1EMEIXza5jXFoqF595qoowQcmQ05xw3YIsDL+Wn46k0sZkbdCen1ZvMA8QP0/fhk0H0/adq4TylI+dhyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YBk5pfrNKdeS5K4XqGvE1+Nd3fmWWZy4fVa1ijw+jRw=; b=OR6jnlb5g6CoTTAigmxXR+koKjwW5/v9GqF/5iyCNHGwhKKNOXrOn1Lbu011otLwSaz9OobmX99JiDQi4ufYgReWmO8BeagE97MRMi7bv3YR5H3MlkB2jSwA50ZN69YTiKo+2yn4XXxY3cr1TbH6qboC4SSOqFXHiaNXDC2c7yA= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3902.namprd11.prod.outlook.com (10.255.180.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Sat, 18 Jan 2020 05:34:44 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::d1b8:3e63:ead8:10c9]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::d1b8:3e63:ead8:10c9%7]) with mapi id 15.20.2644.023; Sat, 18 Jan 2020 05:34:43 +0000 From: "Owen Friel (ofriel)" To: Alan DeKok , Ryan Sleevi CC: "spasm@ietf.org" , Michael Richardson , Joseph Salowey , Benjamin Kaduk , EMU WG Thread-Topic: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic Thread-Index: AQHVzVxYUeAcsaweXEq7AjaKWLDt+qfvQOOAgACiFiA= Date: Sat, 18 Jan 2020 05:34:43 +0000 Message-ID: References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:c0cc:1002::ec] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf749187-371d-477c-a2dd-08d79bd81f74 x-ms-traffictypediagnostic: MN2PR11MB3902: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2089; x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(396003)(376002)(136003)(366004)(199004)(189003)(81156014)(71200400001)(81166006)(478600001)(966005)(186003)(7696005)(4326008)(8676002)(53546011)(6506007)(52536014)(316002)(86362001)(5660300002)(76116006)(66574012)(33656002)(66556008)(64756008)(8936002)(110136005)(54906003)(55016002)(9686003)(66946007)(2906002)(66476007)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3902; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SAEl8Ci6ecDk7CMHrbQKDlS9bQ/dSR4beumg9JwzuKCFpr6nufvuaIoQR5Ui+gAw7x5hDWMCUuwksPptlpkTY048vCUg2/qGY2ldaRXUZT7Is0pGUTXH2Aiv1jkh99rwpNYPrAeVxcxJZOf0zm4ZpwW2m4P5nqCMqG3tBzxdkdxqBXbOsMIwd/XjFl8xxl7wRBjQoZyxW4L0qoHfu1+JaVP6n1XVNrnB8Lox3IIrQOb7jtVkZdi7lvF7qI4VWTU/i48AJygRy2GNowM0KDXPmG0p9UFopTM1H7utHsxVggPMtwERY5dVqogZHeQJWv0pt/Z0LqXSH4iqsuXTz0YCLUuIH50ynZ28cLvzdCMNvawKX1bbK/FkH5HbFW0YmBhCzy2ZKZYJ7D+hcwz9hMn9MI0hIOTXcuijzekBMeLF9epiLcBz7jNzNRaoaVuWSYERW1bJ7HnRvt9m9dZFGYCyG70VoVCAwPsfR8bK+77yqlW+qazcckvKjIEl/DIUDr0B5UFUVv5yS89b/sulIEIz6g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cf749187-371d-477c-a2dd-08d79bd81f74 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2020 05:34:43.3406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ICmIgygPNVPr/AC73Z5UPbeOXMzo5IcBibopIeFPcxp9eRSErWHEsXDMCM0kk0N3OJ+inoEkKHFmA3dlGYvLyg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3902 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 05:34:51 -0000 If the PKI community as a whole (vendors, standards bodies, consortia, CAs)= has managed to engineer a situation where, according to the strict letter = of the law, CAs would have no choice but to revoke operators identity certi= ficates for many of their services if Alan was actually mean and wrote his = script, which would cause widespread outages, then, quoting Charles Dickens= , "the law is a ass", and I'm with Alan and Richard and the law (the CP/CPS= ) should probably change. > -----Original Message----- > From: Spasm On Behalf Of Alan DeKok > Sent: 17 January 2020 19:39 > To: Ryan Sleevi > Cc: spasm@ietf.org; Michael Richardson ; Joseph > Salowey ; Benjamin Kaduk ; EMU WG > > Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert valida= tion > logic >=20 >=20 > On Jan 17, 2020, at 12:33 PM, Ryan Sleevi wrote: > > Does your RADIUS endpoint support and use OCSP stapling and disable Wi= Fi if > the certificate is expired? No? Then it's a potential violation of this C= P/CPS. >=20 > I'm not sure how a RADIUS server will disable WiFi. They are entirely= separate > systems. >=20 > > And in Section 16: > > Customer will only use a TLS/SSL Certificate on the servers accessibl= e at the > domain names listed in the issued Certificate > > > > Remind me how an EAP-TLS/RADIUS server is accessible at that domain nam= e? >=20 > The RADIUS server has a domain name, which is commonly used in the > certificate. >=20 > If that is insufficient for the CAs purposes, then we should also ackno= wledge > that the revocation requirement likely also applies to SMTP, XMPP, DNS ov= er > TLS, and IMAP. i.e. *all* non-WWW protocols which use TLS. >=20 > We should not single-out EAP / RADIUS as mis-using the certificates in t= his > manner. The mis-use of these certificates in other protocols is orders o= f > magnitude larger than the EAP / RADIUS problem. >=20 > > There's two parts of discussion from the thread: > > 1) What do extant clients do, today, in the verification of certificate= s used in > EAP-TLS >=20 > EAP supplicants follow RFC 5216 Section 5.3. >=20 > > 2) What should future clients do, 'tomorrow', to make this easier to us= e and > secure, ideally by default. > > Much of the answer was around #2, which is "Don't try to glom on to > something existing, you need to build your own thing", >=20 > True. >=20 > > as well as "Some of the answers in #1 are problematic and you should tr= y and > discourage them" >=20 > There were *allegations* of problems. >=20 > > To connect it back to the discussion: The discussion about revocation, = and > what a CA's CP/CPS says is or isn't allowed for a usage, matters, because > browsers require CAs promptly revoke those certificates in 24 hours/5 day= s for > situations when they specify bad requirements. Can problematic CAs fix th= eir > CP/CPS to allow this? Yes. But you've still got a host of other > expectations/requirements that can and will diverge, over time. >=20 > If I was mean, I would write scripts to troll the net for mis-use of ce= rtificates in > SMTP, XMPP, IMAP, VPNs, etc. Then, make the script auto-submit notices t= o the > relevant CAs. That process is simple to do, and by the above rules, woul= d > require the CAs to revoke the relevant certs. >=20 > i.e. certs which affect a high percentage of daily internet traffic. >=20 > If that scenario were to play out, I suspect that CAs would very quickl= y stop > revoking the relevant certs. A straight-forward approach to enforcing th= e rules > would be over-ruled by simple practicalities: Turning off big chunks of = the > Internet is a non-starter. >=20 > As Michael Richardson pointed out, then solution here is likely to fix = the rules, > not the protocols. >=20 > > In the specific context of thinking about "#2" - what a touch-free futu= re looks > like - having it use the same root store as Web browsers is the anti-patt= ern, > because the requirements are different. >=20 > And therefore we need a different root store for *each* of EAP, RADIUS, > SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc. Note that we need *different* > stores for EAP and RADIUS, because RADIUS server are reachable on port 20= 83 > as RADIUS over TLS, *and* they implement TLS over EAP, which in turn carr= ied > over RADIUS. Different use-cases, different root stores. >=20 > There may be significant push-back against that many root stores. >=20 > > There's no doubt the status quo is "Everything is manually configured" = and "It's > inconsistent what is validated". The goal is to get to #2, "It just works= " > > > > - Define your requirements (the certificate profile) > > - Define your policies (what do you expect CAs to verify, and how do th= ey > verify) > > - Provide a way to distinguish "new certificates" from "The old and man= ual > cruft" - for example, an explicit EKU > > - Pick your poison.... er, CAs... for the new root store (e.g. as WiFi = Alliance has > done, or Wireless Power Consortium has done, or plenty of vendors have do= ne) > > - Have CAs issue certificates with both EKUs (old and new) in the leaf.= It's a > SEQUENCE for a reason. > > - Have supplicants configured that > > - If new EKU is present, look in built-in store > > - If old EKU is present, require manual configuration > > > > This gets you half-way to #2: things can just work if you pick one of t= he new- > CAs with new-EKUs, and otherwise require manual configuration for old-EKU= s >=20 > That's good, but insufficient. There is a lot more verification that E= AP > supplicants need to do before automatically trusting a root CA. >=20 > I suspect that most CAs already know that their customers mis-use certs= for > non-WWW purposes. EAP / RADIUS is just a minor (almost insignificant) pa= rt of > this problem. I also suspect most CAs operate based on the hope that no = one > notices, and then requires them to revoke many, many, certificates. >=20 > Alan DeKok. >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Jan 17 23:21:16 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314B2120058; Fri, 17 Jan 2020 23:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 Dffxec0B5kFw; Fri, 17 Jan 2020 23:21:07 -0800 (PST) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AC11200C5; Fri, 17 Jan 2020 23:21:06 -0800 (PST) Received: by mail-ed1-f54.google.com with SMTP id j17so24462453edp.3; Fri, 17 Jan 2020 23:21:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=49iJgavE2dWVzjY76roWXr15JoGYBhn0prqRDvAIQOQ=; b=NKVdsxtlYc6Tgkf1tJaHwULSNyE35zsEuS9rxdvIVwIw2nz83KdIxNPL+mF6qIQ5pg pIujeBTz6yU8ypcWNvWHJNckAAuur3PK0ryxMD3GgdfhkWTgpLrq8goeW9g+SdM2cIQ+ yEtef4duRleNdMHIH740xFrVyzlk1LmpEosnlYkwTZLyzhjwWVBHjRjp/l3bgzW3Ohsh 2EMOkh1+0yaVSPFBK4ftojGGMjYcc2HKki4de5ywLgxPFQey0tukHL7rhVdwkmQ3xfH9 1lGAxAeX9Sez0YKcU+Tj6Y49DAm5UyqHypd0Q7fjdAab/4YeZX7M8x737+KWDdjmeSDB NAOg== X-Gm-Message-State: APjAAAViNF8yz/95soIB2KvHlRgNU6nFpNTepKeFpnvyB52EMYRhcRgn EG6jQzXNROPnY2acKctqdNE/IABB X-Google-Smtp-Source: APXvYqxAL4RYhUK57PziOzeIOsMrwVkNtU3rdqiR8rRwSEIdQS4UNzPLrcM+gtFfkJ7c3qaWUcvf1Q== X-Received: by 2002:aa7:d3cb:: with SMTP id o11mr7894607edr.145.1579332064665; Fri, 17 Jan 2020 23:21:04 -0800 (PST) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com. [209.85.128.49]) by smtp.gmail.com with ESMTPSA id pv11sm825274ejb.75.2020.01.17.23.21.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jan 2020 23:21:03 -0800 (PST) Received: by mail-wm1-f49.google.com with SMTP id a5so9505818wmb.0; Fri, 17 Jan 2020 23:21:03 -0800 (PST) X-Received: by 2002:a05:600c:149:: with SMTP id w9mr7964832wmm.132.1579332063136; Fri, 17 Jan 2020 23:21:03 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> In-Reply-To: From: Ryan Sleevi Date: Sat, 18 Jan 2020 02:20:52 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Owen Friel (ofriel)" Cc: Alan DeKok , Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009b31b4059c64e613" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 07:21:09 -0000 --0000000000009b31b4059c64e613 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Or... just stop using those certs/roots already? We=E2=80=99ve already iden= tified that there is absolutely zero reason to do so in the extant status quo, because it still requires manual configuration. You get no benefits and clearly downsides, so just... don=E2=80=99t do that? Any complaints about h= ow that existing PKI is managed is just a complaint that it doesn=E2=80=99t fit you= r purposes and doesn=E2=80=99t do what you want, which is fine: that=E2=80=99= s the entire point. If you don=E2=80=99t like CAs being required to do what they say, and be he= ld accountable to stated policies, then sure, let them issue whatever they want and decide unilaterally what the risks are. Of course, then you=E2=80= =99ll end up with situations like CAs issuing certificates with duplicate serial numbers, with one of the duplicates being a CA certificate used for active MITM of user connections, and the issuing CA complaining that revoking would be disruptive for those other holders with the same serial number. Which is a real thing that happened, and indistinguishable from a policy perspective to Alan=E2=80=99s example. Or you can deal with the commiserate= legal risks involved in selectively enforcing when you agree or disagree with the CA=E2=80=99s risk assessment and what is =E2=80=9Creasonable=E2=80=9D, with= the CA who issues certificates used for MITM lamenting it=E2=80=99s =E2=80=9Cunfair=E2=80=9D = and =E2=80=9Cinconsistent=E2=80=9D that they aren=E2=80=99t allowed to declare there is no risk for those certifica= tes, while other CAs get to declare there=E2=80=99s no risk for EAP-TLS, despite= their policies stating they don=E2=80=99t allow it. If you don=E2=80=99t want to deal with those problems, which are messy and = complex, then yes, manually configure your certs, and don=E2=80=99t manually configu= re ones that expose you to all of this. Problem solved, and no need for Dickens. I can appreciate that, if you=E2=80=99re not involved with managing a PKI o= r trust store, it would seem undesirable to actually enforce standards and contracts and policies as they were written, especially when inconvenient. Yet documents like RFC 3647 exist precisely because the world is not a technocratic utopia, trust is a hard problem, and it exists in a world where there are messy and complex legal problems. If you want to use want to use PKI, and you want to do more than just require explicit manual configuration, then you have to deal with all of that and more. You can pretend it doesn=E2=80=99t exist, but you can=E2=80=99t escape that reality= . DigiNotar is an example, but one of dozens at this point. Manual configuration lets you localize that to things you control, and so that=E2=80=99s an eminently rea= sonable status quo. On Sat, Jan 18, 2020 at 12:34 AM Owen Friel (ofriel) wrote: > If the PKI community as a whole (vendors, standards bodies, consortia, > CAs) has managed to engineer a situation where, according to the strict > letter of the law, CAs would have no choice but to revoke operators > identity certificates for many of their services if Alan was actually mea= n > and wrote his script, which would cause widespread outages, then, quoting > Charles Dickens, "the law is a ass", and I'm with Alan and Richard and th= e > law (the CP/CPS) should probably change. > > > -----Original Message----- > > From: Spasm On Behalf Of Alan DeKok > > Sent: 17 January 2020 19:39 > > To: Ryan Sleevi > > Cc: spasm@ietf.org; Michael Richardson ; Joseph > > Salowey ; Benjamin Kaduk ; EMU WG > > > > Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert > validation > > logic > > > > > > On Jan 17, 2020, at 12:33 PM, Ryan Sleevi wrote: > > > Does your RADIUS endpoint support and use OCSP stapling and disable > WiFi if > > the certificate is expired? No? Then it's a potential violation of this > CP/CPS. > > > > I'm not sure how a RADIUS server will disable WiFi. They are > entirely separate > > systems. > > > > > And in Section 16: > > > Customer will only use a TLS/SSL Certificate on the servers > accessible at the > > domain names listed in the issued Certificate > > > > > > Remind me how an EAP-TLS/RADIUS server is accessible at that domain > name? > > > > The RADIUS server has a domain name, which is commonly used in the > > certificate. > > > > If that is insufficient for the CAs purposes, then we should also > acknowledge > > that the revocation requirement likely also applies to SMTP, XMPP, DNS > over > > TLS, and IMAP. i.e. *all* non-WWW protocols which use TLS. > > > > We should not single-out EAP / RADIUS as mis-using the certificates in > this > > manner. The mis-use of these certificates in other protocols is orders > of > > magnitude larger than the EAP / RADIUS problem. > > > > > There's two parts of discussion from the thread: > > > 1) What do extant clients do, today, in the verification of > certificates used in > > EAP-TLS > > > > EAP supplicants follow RFC 5216 Section 5.3. > > > > > 2) What should future clients do, 'tomorrow', to make this easier to > use and > > secure, ideally by default. > > > Much of the answer was around #2, which is "Don't try to glom on to > > something existing, you need to build your own thing", > > > > True. > > > > > as well as "Some of the answers in #1 are problematic and you should > try and > > discourage them" > > > > There were *allegations* of problems. > > > > > To connect it back to the discussion: The discussion about revocation= , > and > > what a CA's CP/CPS says is or isn't allowed for a usage, matters, becau= se > > browsers require CAs promptly revoke those certificates in 24 hours/5 > days for > > situations when they specify bad requirements. Can problematic CAs fix > their > > CP/CPS to allow this? Yes. But you've still got a host of other > > expectations/requirements that can and will diverge, over time. > > > > If I was mean, I would write scripts to troll the net for mis-use of > certificates in > > SMTP, XMPP, IMAP, VPNs, etc. Then, make the script auto-submit notices > to the > > relevant CAs. That process is simple to do, and by the above rules, > would > > require the CAs to revoke the relevant certs. > > > > i.e. certs which affect a high percentage of daily internet traffic. > > > > If that scenario were to play out, I suspect that CAs would very > quickly stop > > revoking the relevant certs. A straight-forward approach to enforcing > the rules > > would be over-ruled by simple practicalities: Turning off big chunks o= f > the > > Internet is a non-starter. > > > > As Michael Richardson pointed out, then solution here is likely to fi= x > the rules, > > not the protocols. > > > > > In the specific context of thinking about "#2" - what a touch-free > future looks > > like - having it use the same root store as Web browsers is the > anti-pattern, > > because the requirements are different. > > > > And therefore we need a different root store for *each* of EAP, RADIU= S, > > SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc. Note that we need *differen= t* > > stores for EAP and RADIUS, because RADIUS server are reachable on port > 2083 > > as RADIUS over TLS, *and* they implement TLS over EAP, which in turn > carried > > over RADIUS. Different use-cases, different root stores. > > > > There may be significant push-back against that many root stores. > > > > > There's no doubt the status quo is "Everything is manually configured= " > and "It's > > inconsistent what is validated". The goal is to get to #2, "It just > works" > > > > > > - Define your requirements (the certificate profile) > > > - Define your policies (what do you expect CAs to verify, and how do > they > > verify) > > > - Provide a way to distinguish "new certificates" from "The old and > manual > > cruft" - for example, an explicit EKU > > > - Pick your poison.... er, CAs... for the new root store (e.g. as WiF= i > Alliance has > > done, or Wireless Power Consortium has done, or plenty of vendors have > done) > > > - Have CAs issue certificates with both EKUs (old and new) in the > leaf. It's a > > SEQUENCE for a reason. > > > - Have supplicants configured that > > > - If new EKU is present, look in built-in store > > > - If old EKU is present, require manual configuration > > > > > > This gets you half-way to #2: things can just work if you pick one of > the new- > > CAs with new-EKUs, and otherwise require manual configuration for > old-EKUs > > > > That's good, but insufficient. There is a lot more verification that > EAP > > supplicants need to do before automatically trusting a root CA. > > > > I suspect that most CAs already know that their customers mis-use > certs for > > non-WWW purposes. EAP / RADIUS is just a minor (almost insignificant) > part of > > this problem. I also suspect most CAs operate based on the hope that n= o > one > > notices, and then requires them to revoke many, many, certificates. > > > > Alan DeKok. > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > --0000000000009b31b4059c64e613 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Or... just stop using those certs/roots already? We= =E2=80=99ve already identified that there is absolutely zero reason to do s= o in the extant status quo, because it still requires manual configuration.= You get no benefits and clearly downsides, so just... don=E2=80=99t do tha= t? Any complaints about how that existing PKI is managed is just a complain= t that it doesn=E2=80=99t fit your purposes and doesn=E2=80=99t do what you= want, which is fine: that=E2=80=99s the entire point.

If you don=E2=80=99t like CAs being re= quired to do what they say, and be held accountable to stated policies, the= n sure, let them issue whatever they want and decide unilaterally what the = risks are. Of course, then you=E2=80=99ll end up with situations like CAs i= ssuing certificates with duplicate serial numbers, with one of the duplicat= es being a CA certificate used for active MITM of user connections, and the= issuing CA complaining that revoking would be disruptive for those other h= olders with the same serial number. Which is a real thing that happened, an= d indistinguishable from a policy perspective to Alan=E2=80=99s example. Or= you can deal with the commiserate legal risks involved in selectively enfo= rcing when you agree or disagree with the CA=E2=80=99s risk assessment and = what is =E2=80=9Creasonable=E2=80=9D, with the CA who issues certificates u= sed for MITM lamenting it=E2=80=99s =E2=80=9Cunfair=E2=80=9D and =E2=80=9Ci= nconsistent=E2=80=9D that they aren=E2=80=99t allowed to declare there is n= o risk for those certificates, while other CAs get to declare there=E2=80= =99s no risk for EAP-TLS, despite their policies stating they don=E2=80=99t= allow it.

If you don=E2= =80=99t want to deal with those problems, which are messy and complex, then= yes, manually configure your certs, and don=E2=80=99t manually configure o= nes that expose you to all of this. Problem solved, and no need for Dickens= .

I can appreciate that,= if you=E2=80=99re not involved with managing a PKI or trust store, it woul= d seem undesirable to actually enforce standards and contracts and policies= as they were written, especially when inconvenient. Yet documents like RFC= 3647 exist precisely because the world is not a technocratic utopia, trust= is a hard problem, and it exists in a world where there are messy and comp= lex legal problems. If you want to use want to use PKI, and you want to do = more than just require explicit manual configuration, then you have to deal= with all of that and more. You can pretend it doesn=E2=80=99t exist, but y= ou can=E2=80=99t escape that reality. DigiNotar is an example, but one of d= ozens at this point. Manual configuration lets you localize that to things = you control, and so that=E2=80=99s an eminently reasonable status quo.

On Sat, Jan 18, 2020 at 12:3= 4 AM Owen Friel (ofriel) <ofriel@cis= co.com> wrote:
If the PKI community as a whole (vendors, standards bodi= es, consortia, CAs) has managed to engineer a situation where, according to= the strict letter of the law, CAs would have no choice but to revoke opera= tors identity certificates for many of their services if Alan was actually = mean and wrote his script, which would cause widespread outages, then, quot= ing Charles Dickens, "the law is a ass", and I'm with Alan an= d Richard and the law (the CP/CPS) should probably change.

> -----Original Message-----
> From: Spasm <spasm-bounces@ietf.org> On Behalf Of Alan DeKok
> Sent: 17 January 2020 19:39
> To: Ryan Sleevi <ryan-ietf@sleevi.com>
> Cc: spasm@ietf.org= ; Michael Richardson <mcr+ietf@sandelman.ca>; Joseph
> Salowey <joe@s= alowey.net>; Benjamin Kaduk <kaduk@mit.edu>; EMU WG
> <emu@ietf.org= >
> Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert val= idation
> logic
>
>
> On Jan 17, 2020, at 12:33 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> >=C2=A0 Does your RADIUS endpoint support and use OCSP stapling and= disable WiFi if
> the certificate is expired? No? Then it's a potential violation of= this CP/CPS.
>
>=C2=A0 =C2=A0 I'm not sure how a RADIUS server will disable WiFi.= =C2=A0 They are entirely separate
> systems.
>
> > And in Section 16:
> >=C2=A0 =C2=A0Customer will only use a TLS/SSL Certificate on the s= ervers accessible at the
> domain names listed in the issued Certificate
> >
> > Remind me how an EAP-TLS/RADIUS server is accessible at that doma= in name?
>
>=C2=A0 =C2=A0The RADIUS server has a domain name, which is commonly use= d in the
> certificate.
>
>=C2=A0 =C2=A0If that is insufficient for the CAs purposes, then we shou= ld also acknowledge
> that the revocation requirement likely also applies to SMTP, XMPP, DNS= over
> TLS, and IMAP.=C2=A0 i.e. *all* non-WWW protocols which use TLS.
>
>=C2=A0 We should not single-out EAP / RADIUS as mis-using the certifica= tes in this
> manner.=C2=A0 The mis-use of these certificates in other protocols is = orders of
> magnitude larger than the EAP / RADIUS problem.
>
> > There's two parts of discussion from the thread:
> > 1) What do extant clients do, today, in the verification of certi= ficates used in
> EAP-TLS
>
>=C2=A0 =C2=A0EAP supplicants follow RFC 5216 Section 5.3.
>
> > 2) What should future clients do, 'tomorrow', to make thi= s easier to use and
> secure, ideally by default.
> > Much of the answer was around #2, which is "Don't try to= glom on to
> something existing, you need to build your own thing",
>
>=C2=A0 =C2=A0True.
>
> > as well as "Some of the answers in #1 are problematic and yo= u should try and
> discourage them"
>
>=C2=A0 =C2=A0There were *allegations* of problems.
>
> > To connect it back to the discussion: The discussion about revoca= tion, and
> what a CA's CP/CPS says is or isn't allowed for a usage, matte= rs, because
> browsers require CAs promptly revoke those certificates in 24 hours/5 = days for
> situations when they specify bad requirements. Can problematic CAs fix= their
> CP/CPS to allow this? Yes. But you've still got a host of other > expectations/requirements that can and will diverge, over time.
>
>=C2=A0 =C2=A0If I was mean, I would write scripts to troll the net for = mis-use of certificates in
> SMTP, XMPP, IMAP, VPNs, etc.=C2=A0 Then, make the script auto-submit n= otices to the
> relevant CAs.=C2=A0 That process is simple to do, and by the above rul= es, would
> require the CAs to revoke the relevant certs.
>
>=C2=A0 =C2=A0i.e. certs which affect a high percentage of daily interne= t traffic.
>
>=C2=A0 =C2=A0If that scenario were to play out, I suspect that CAs woul= d very quickly stop
> revoking the relevant certs.=C2=A0 A straight-forward approach to enfo= rcing the rules
> would be over-ruled by simple practicalities:=C2=A0 Turning off big ch= unks of the
> Internet is a non-starter.
>
>=C2=A0 =C2=A0As Michael Richardson pointed out, then solution here is l= ikely to fix the rules,
> not the protocols.
>
> > In the specific context of thinking about "#2" - what a= touch-free future looks
> like - having it use the same root store as Web browsers is the anti-p= attern,
> because the requirements are different.
>
>=C2=A0 =C2=A0And therefore we need a different root store for *each* of= EAP, RADIUS,
> SMTP, XMPP, IMAP, DNS over TLS, VPNs, etc.=C2=A0 Note that we need *di= fferent*
> stores for EAP and RADIUS, because RADIUS server are reachable on port= 2083
> as RADIUS over TLS, *and* they implement TLS over EAP, which in turn c= arried
> over RADIUS.=C2=A0 Different use-cases, different root stores.
>
>=C2=A0 =C2=A0There may be significant push-back against that many root = stores.
>
> > There's no doubt the status quo is "Everything is manual= ly configured" and "It's
> inconsistent what is validated". The goal is to get to #2, "= It just works"
> >
> > - Define your requirements (the certificate profile)
> > - Define your policies (what do you expect CAs to verify, and how= do they
> verify)
> > - Provide a way to distinguish "new certificates" from = "The old and manual
> cruft" - for example, an explicit EKU
> > - Pick your poison.... er, CAs... for the new root store (e.g. as= WiFi Alliance has
> done, or Wireless Power Consortium has done, or plenty of vendors have= done)
> > - Have CAs issue certificates with both EKUs (old and new) in the= leaf. It's a
> SEQUENCE for a reason.
> > - Have supplicants configured that
> >=C2=A0 =C2=A0 - If new EKU is present, look in built-in store
> >=C2=A0 =C2=A0 - If old EKU is present, require manual configuratio= n
> >
> > This gets you half-way to #2: things can just work if you pick on= e of the new-
> CAs with new-EKUs, and otherwise require manual configuration for old-= EKUs
>
>=C2=A0 =C2=A0That's good, but insufficient.=C2=A0 There is a lot mo= re verification that EAP
> supplicants need to do before automatically trusting a root CA.
>
>=C2=A0 =C2=A0I suspect that most CAs already know that their customers = mis-use certs for
> non-WWW purposes.=C2=A0 EAP / RADIUS is just a minor (almost insignifi= cant) part of
> this problem.=C2=A0 I also suspect most CAs operate based on the hope = that no one
> notices, and then requires them to revoke many, many, certificates. >
>=C2=A0 =C2=A0Alan DeKok.
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org=
> https://www.ietf.org/mailman/listinfo/spasm
--0000000000009b31b4059c64e613-- From nobody Sat Jan 18 05:05:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91F712001E; Sat, 18 Jan 2020 05:05:19 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 L8ZM3Mu--S7S; Sat, 18 Jan 2020 05:05:14 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1E01200C1; Sat, 18 Jan 2020 05:05:14 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id E1A74650; Sat, 18 Jan 2020 13:05:10 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Sat, 18 Jan 2020 08:05:09 -0500 Cc: "Owen Friel (ofriel)" , Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 13:05:20 -0000 On Jan 18, 2020, at 2:20 AM, Ryan Sleevi wrote: >=20 > Or... just stop using those certs/roots already? We=E2=80=99ve already = identified that there is absolutely zero reason to do so in the extant = status quo, because it still requires manual configuration. ... for EAP. And only for EAP. That comment doesn't apply to SMTP, XMPP, IMAP, DNS over TLS, VPNs, = RADIUS over TLS, etc.. SMTP servers mis-use "WWW" certificates = precisely *because* it requires zero client configuration. It leverages = an existing trust store to increase security. And that's a good thing. As noted by Michael, CAs are using certificates in a way that violates = their own policy. The mis-use problem is therefore larger, and worse, = than the minor issue of EAP *sometimes* using WWW certs. My previous messages explained that the common practice for EAP is to = use private CAs. For the reasons you outlined above, and more. Pretty = much everyone in the EAP community was convinced of this 15+ years ago. = It has been standard / recommended practices for 15+ years. Finally, there are reasons to use public CAs for EAP. I have = customers who do this today, for internal corporate policy reasons. = I've recommended that they don't do it, but their internal "security" = team over-rules me. The rest of your comments are trying to convince people of things that = they're already convinced of. We already know this, we already agree = (mostly). The disagreement is this: your underlying assumption is that these are = the rules, and they have to be followed. I believe that this is the = IETF, and that we make the rules. If we need to change the rules, then = we just do so. And the Internet community has to follow. There are details as to which rules apply where, and to who. But as = the IETF, we are entirely within our purview to allow the use of = id-kp-serverAuth in EAP, SMTP, etc.. Or, to come up with a new scheme = that replaces id-kp-serverAuth. If the rules have to be applied strictly, then you have been made = aware that the CAs you pointed to are violating their own policies. = Therefore, you are under a moral obligation to report this mis-use to = them. Failure to do so is a tacit admission that you are not applying = the rules in practice. While at the same time, claiming that the rules = have to be stringently followed. Alan DeKok. From nobody Sat Jan 18 05:55:54 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A19C12001B; Sat, 18 Jan 2020 05:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 fvh3FT4IrSqU; Sat, 18 Jan 2020 05:55:51 -0800 (PST) Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39E1120013; Sat, 18 Jan 2020 05:55:50 -0800 (PST) Received: by mail-ed1-f44.google.com with SMTP id r21so25057643edq.0; Sat, 18 Jan 2020 05:55:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6iZMViH8RsQBgsh/7mJ02/OgLNa/Ze+xqJDUTtVpG5o=; b=jpUcEDaUueuW3ubd39XPIpX5f4mTBAx6xUFBp3KEifrryQne7BDcXpOdl7BYUARlLl BxgzraT8VCvgOuw8AD1rM2XayBQZ3W4R7Mj180AzZBvAGRRdrhTPCIt6NsQgz2cilbDS /BHPpbp13EeAyIjJ9zfWBPDrGYrxmGkQ9exlE1VmgU+KrJAmInQeNJ6jlckLb4mneKki eDPVgRp3fQ9t6V5dvO1siP4be8uuMDz3tkfP00d+oDrKaGBry+XdNwoPfMvvfz6H6sx2 /GklWYYsKB/J9Xns+kryJENED1T43XQlrk14pVOEvVUDQ0yRv4lGCkek58JUsW938Z/B 1sXQ== X-Gm-Message-State: APjAAAUs3g3aOESX1yHEg0+Q/4RK8fGc3//gTrD3PslE8OxLeGmFBCuc kmsVUXuRQvnWxm2ZlNGk/rmQqcpS X-Google-Smtp-Source: APXvYqxaYyNWTSC3RZey9JMEY9hw4wmYkYjZf3hvAG9+nYwuhSd9xT3GTMFYkDr6S0uaZZaItNq6zg== X-Received: by 2002:a05:6402:153:: with SMTP id s19mr8892359edu.149.1579355748997; Sat, 18 Jan 2020 05:55:48 -0800 (PST) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com. [209.85.128.44]) by smtp.gmail.com with ESMTPSA id n2sm862385ejd.86.2020.01.18.05.55.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jan 2020 05:55:47 -0800 (PST) Received: by mail-wm1-f44.google.com with SMTP id u2so10315960wmc.3; Sat, 18 Jan 2020 05:55:47 -0800 (PST) X-Received: by 2002:a1c:ddd7:: with SMTP id u206mr10247438wmg.159.1579355747165; Sat, 18 Jan 2020 05:55:47 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> In-Reply-To: <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> From: Ryan Sleevi Date: Sat, 18 Jan 2020 08:55:32 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000048ad90059c6a6af7" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 13:55:53 -0000 --00000000000048ad90059c6a6af7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok wrote: > As noted by Michael, CAs are using certificates in a way that violates > their own policy. Um, no. I largely didn=E2=80=99t respond to Michael=E2=80=99s email because= it missed the mark rather substantially, and I suspect folks still haven=E2=80=99t actual= ly read the CP/CPSes or done the work. As I explain again, later on, this is fixating on a branch on a tree and ignoring the forest in which it is in. I provided the example to illustrate the broader problem, but apparently I picked too distracting an example. > > Finally, there are reasons to use public CAs for EAP. I have customers > who do this today, for internal corporate policy reasons. I've recommend= ed > that they don't do it, but their internal "security" team over-rules me. Right. These people are wrong and their reasons bas :) For example, a certain CA, no longer in business, vociferously opposed the deployment of Certificate Transparency and the forbidding of issuance to non-qualified domain names (e.g. =E2=80=9Cmail=E2=80=9D and =E2=80=9Cintran= et=E2=80=9D and the like). More than half of their business selling their premium ($2000+/cert) EV certificates was selling them to enterprises they had convinced required EV certificates, and they were opposed to anything that would disrupt or diminish that practice. Yet it=E2=80=99s obviously laughable to believe som= eone validated unique control, via DNS on the public internet, of the name =E2=80=9Cmail=E2=80=9D - effectively a TLD. I mention this anecdote because I=E2=80=99m quite familiar with corporate s= ecurity teams requiring things, =E2=80=9Cfor reasons=E2=80=9D (typically, an effect= ive sales/marketing team), but that doesn=E2=80=99t make it any more correct. T= his is where supplicants and servers refusing such certificates is not unreasonable as a means of signaling technically that which is operationally true. The rest of your comments are trying to convince people of things that > they're already convinced of. We already know this, we already agree > (mostly). > > The disagreement is this: your underlying assumption is that these are > the rules, and they have to be followed. I believe that this is the IETF= , > and that we make the rules. If we need to change the rules, then we just > do so. And the Internet community has to follow. No. The root store operators make the rules. Standards that align with their needs are the standards they use and apply. Nothing you say or do has any impact without implementor, and if you go against the grain of where implementors are going or already at, they are useless standards that will be ignored. It would similarly be a mistake to think =E2=80=9CAh, but I control an SMTP= server, I am thus an implementor and empowered=E2=80=9D. You are indeed an implemen= tor... for your root store. And if existing contracts and requirements prevent a CA from serving your needs from the same hierarchy they are serving other root store needs, which they increasingly will, then again, there=E2=80=99s= no real power unless you define your own root store. When a vendor, be it Apple or Microsoft or Mozilla or Google, says a CA in their root store needs to do something, they need to do it. If you don=E2= =80=99t like that, which the email clearly demonstrates, there isn=E2=80=99t a heck= ler=E2=80=99s veto via the IETF: you instead need to create your own root store to do the things you want or like. Attempting to change those policies via the IETF, without understanding why they exist, just leads to IETF standards being ignored because they are not useful nor aligned with the needs of consumers= . Put differently: This is as explicitly an area of policy, not technology. As tempting as it may seem to focus on individual problems and say =E2=80= =9CAh, but those could be addressed by technology and more standards,=E2=80=9D without appreciating the broader and big picture, which is inherently policy, the work on the technology is doomed. There are details as to which rules apply where, and to who. But as the > IETF, we are entirely within our purview to allow the use of > id-kp-serverAuth in EAP, SMTP, etc.. Or, to come up with a new scheme th= at > replaces id-kp-serverAuth. Yes, and the latter is more relevant than the former. You=E2=80=99re seemingly fixated on the detail of the EKU, without acknowle= dging that the EKU is merely a technical example of the broader point of how requirements and policies work and flow, and how certificate consumers, even when used over the same transport substrate (TLS), have substantially different operational considerations. Those operational considerations impact the design of the PKI and thus the selection of the roots, and why multiple root stores, with their own policies and expectations, is the natural end-point. We don=E2=80=99t expect IETF to be the One Standards Org for everything, su= ch a railway gauge tolerances and fire resistant building material codes and maximum reflectivity of space equipment. Those are both beyond our ken and our focus. The same is true for PKI: there does not need to be one set of Policy to Rule Them All, and it=E2=80=99s ok to have many policies, each wr= itten by different constituents to reflect their needs. The important thing, that I keep trying to emphasize, is that separate policies are best technically accounted for at different roots. Yes, the dream of PKI was one root per organization and a grand and global mesh network of policy, and so we have all this technical complexity in specs like RFC 5280 to accomplish that. But the technology does not work, in the real world, and in fact makes it more difficult and risky, rather than less. So just use separate PKIs, built to common profiles when applicable/relevant, and move on. What happens in other PKIs shouldn=E2=80= =99t affect you or be relevant, much like ISO standardizing how food processing equipment should be inspected is not really relevant here. --00000000000048ad90059c6a6af7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok <aland@deployingradius.com> wrote:
=C2=A0 As noted by Michael, CAs are using certificates in a way that violat= es their own policy.=C2=A0

Um, no. I largely didn=E2=80=99t respond to Michael=E2=80=99s em= ail because it missed the mark rather substantially, and I suspect folks st= ill haven=E2=80=99t actually read the CP/CPSes or done the work.

As I explain again, later on, this= is fixating on a branch on a tree and ignoring the forest in which it is i= n. I provided the example to illustrate the broader problem, but apparently= I picked too distracting an example.

=C2=A0 Finally, there are reasons to use public CAs for EAP.=C2=A0 I have c= ustomers who do this today, for internal corporate policy reasons.=C2=A0 I&= #39;ve recommended that they don't do it, but their internal "secu= rity" team over-rules me.

Right. These people are wrong and their reasons bas :)
<= div dir=3D"auto">
For example, a certain CA, no = longer in business, vociferously opposed the deployment of Certificate Tran= sparency and the forbidding of issuance to non-qualified domain names (e.g.= =E2=80=9Cmail=E2=80=9D and =E2=80=9Cintranet=E2=80=9D and the like). More = than half of their business selling their premium ($2000+/cert) EV certific= ates was selling them to enterprises they had convinced required EV certifi= cates, and they were opposed to anything that would disrupt or diminish tha= t practice. Yet it=E2=80=99s obviously laughable to believe someone validat= ed unique control, via DNS on the public internet, of the name =E2=80=9Cmai= l=E2=80=9D - effectively a TLD.

I mention this anecdote because I=E2=80=99m quite familiar with c= orporate security teams requiring things, =E2=80=9Cfor reasons=E2=80=9D (ty= pically, an effective sales/marketing team), but that doesn=E2=80=99t make = it any more correct. This is where supplicants and servers refusing such ce= rtificates is not unreasonable as a means of signaling technically that whi= ch is operationally true.

=C2=A0 The rest of your comments are trying to convince people of things th= at they're already convinced of.=C2=A0 We already know this, we already= agree (mostly).

=C2=A0 The disagreement is this: your underlying assumption is that these a= re the rules, and they have to be followed.=C2=A0 I believe that this is th= e IETF, and that we make the rules.=C2=A0 If we need to change the rules, t= hen we just do so.=C2=A0 And the Internet community has to follow.

No. The root store operat= ors make the rules. Standards that align with their needs are the standards= they use and apply.

Not= hing you say or do has any impact without implementor, and if you go agains= t the grain of where implementors are going or already at, they are useless= standards that will be ignored.

It would similarly be a mistake to think =E2=80=9CAh, but I contr= ol an SMTP server, I am thus an implementor and empowered=E2=80=9D. You are= indeed an implementor... for your root store. And if existing contracts an= d requirements prevent a CA from serving your needs from the same hierarchy= they are serving other root store needs, which they increasingly will, the= n again, there=E2=80=99s no real power unless you define your own root stor= e.

When a vendor, be it = Apple or Microsoft or Mozilla or Google, says a CA in their root store need= s to do something, they need to do it. If you don=E2=80=99t like that, whic= h the email clearly demonstrates, there isn=E2=80=99t a heckler=E2=80=99s v= eto via the IETF: you instead need to create your own root store to do the = things you want or like. Attempting to change those policies via the IETF, = without understanding why they exist, just leads to IETF standards being ig= nored because they are not useful nor aligned with the needs of consumers.<= /div>

Put differently: This is= as explicitly an area of policy, not technology. As tempting as it may see= m to focus on individual problems and say =E2=80=9CAh, but those could be a= ddressed by technology and more standards,=E2=80=9D without appreciating th= e broader and big picture, which is inherently policy, the work on the tech= nology is doomed.

=C2=A0 There are details as to which rules apply where, and to who.=C2=A0 B= ut as the IETF, we are entirely within our purview to allow the use of id-k= p-serverAuth in EAP, SMTP, etc..=C2=A0 Or, to come up with a new scheme tha= t replaces id-kp-serverAuth.

Yes, and the latter is more relevant than the former.

You=E2=80=99re seemingly fixated = on the detail of the EKU, without acknowledging that the EKU is merely a te= chnical example of the broader point of how requirements and policies work = and flow, and how certificate consumers, even when used over the same trans= port substrate (TLS), have substantially different operational consideratio= ns. Those operational considerations impact the design of the PKI and thus = the selection of the roots, and why multiple root stores, with their own po= licies and expectations, is the natural end-point.
<= br>
We don=E2=80=99t expect IETF to be the One Stand= ards Org for everything, such a railway gauge tolerances and fire resistant= building material codes and maximum reflectivity of space equipment. Those= are both beyond our ken and our focus. The same is true for PKI: there doe= s not need to be one set of Policy to Rule Them All, and it=E2=80=99s ok to= have many policies, each written by different constituents to reflect thei= r needs.

The important t= hing, that I keep trying to emphasize, is that separate policies are best t= echnically accounted for at different roots. Yes, the dream of PKI was one = root per organization and a grand and global mesh network of policy, and so= we have all this technical complexity in specs like RFC 5280 to accomplish= that. But the technology does not work, in the real world, and in fact mak= es it more difficult and risky, rather than less. So just use separate PKIs= , built to common profiles when applicable/relevant, and move on. What happ= ens in other PKIs shouldn=E2=80=99t affect you or be relevant, much like IS= O standardizing how food processing equipment should be inspected is not re= ally relevant here.


=
--00000000000048ad90059c6a6af7-- From nobody Sat Jan 18 06:15:08 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FCD12003F for ; Sat, 18 Jan 2020 06:15:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 NRxzpYeWYFhx for ; Sat, 18 Jan 2020 06:15:03 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58AE4120013 for ; Sat, 18 Jan 2020 06:15:03 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id soZxiW2kVuMO5sosQiVD3t; Sat, 18 Jan 2020 14:15:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1579356902; bh=B16BW/KtBo4gbjmFiT2o0upefNfQfyrsuCfrLrkAOyw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=lGlLkaQpCCBUJTJdYEeFxGvV07XMQBHJuYmUgQoAZCuR18a6FA3xiUmugsX21hmN/ t0yRBQ3uvt9PM1kim/nRPo7TWGLsUMTiD8LWn6a97fnDn0JTcEcKytdZoZ746hm4B4 ZsQoVsL12ywtrz6KqFhzmwIxqbXmZouYu1zTnYhMMjZY4ZUyAp6H8izg9JwuqDUII0 4XzjZFtx9SkuxjM5sWe0o1pvLwOfAL66nSUHJSpUtBXO1D29PtTsnZhVkh54+G7Vzj m9xfAEOHHUnfIJ1HHsvGY+UXdOpgaJ5llVYudWgQSMWZlDJG/1oS+Q6VYQi3kcC0EQ ebb7PZ6qmcYBA== Received: from [IPv6:2601:187:4000:6316:2175:831:bb6d:d76c] ([IPv6:2601:187:4000:6316:2175:831:bb6d:d76c]) by resomta-ch2-16v.sys.comcast.net with ESMTPSA id sosOix6kV3TL0sosPic2W8; Sat, 18 Jan 2020 14:15:02 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "David B. Nelson" In-Reply-To: Date: Sat, 18 Jan 2020 09:15:00 -0500 Cc: Alan DeKok , EMU WG , "spasm@ietf.org" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <6B9DF061-36C5-426B-8403-91972B40A05E@comcast.net> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 14:15:05 -0000 On Jan 18, 2020, at 8:55 AM, Ryan Sleevi wrote: >=20 > No. The root store operators make the rules. Standards that align with = their needs are the standards they use and apply. >=20 > Nothing you say or do has any impact without implementor, and if you = go against the grain of where implementors are going or already at, they = are useless standards that will be ignored. >=20 > It would similarly be a mistake to think =E2=80=9CAh, but I control an = SMTP server, I am thus an implementor and empowered=E2=80=9D. You are = indeed an implementor... for your root store. And if existing contracts = and requirements prevent a CA from serving your needs from the same = hierarchy they are serving other root store needs, which they = increasingly will, then again, there=E2=80=99s no real power unless you = define your own root store. >=20 > When a vendor, be it Apple or Microsoft or Mozilla or Google, says a = CA in their root store needs to do something, they need to do it. If you = don=E2=80=99t like that, which the email clearly demonstrates, there = isn=E2=80=99t a heckler=E2=80=99s veto via the IETF: you instead need to = create your own root store to do the things you want or like. Attempting = to change those policies via the IETF, without understanding why they = exist, just leads to IETF standards being ignored because they are not = useful nor aligned with the needs of consumers. >=20 > Put differently: This is as explicitly an area of policy, not = technology. As tempting as it may seem to focus on individual problems = and say =E2=80=9CAh, but those could be addressed by technology and more = standards,=E2=80=9D without appreciating the broader and big picture, = which is inherently policy, the work on the technology is doomed. I don=E2=80=99t =E2=80=9Chave a dog in this fight=E2=80=9D, being = retired for several years now. However, I=E2=80=99ve been following = this thread out of interest. I=E2=80=99ve long held that the problems = with deployment and interoperability of PKI are in the business domain, = not the technical domain. It=E2=80=99s interesting, and perhaps a bit = disappointing, to see that it still the case. And now, back to your = regular programming=E2=80=A6 Regards, Dave Nelson From nobody Sat Jan 18 06:22:09 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C49B120033; Sat, 18 Jan 2020 06:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 8w9sTXFqLvak; Sat, 18 Jan 2020 06:22:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE31120013; Sat, 18 Jan 2020 06:21:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 26F27BE7C; Sat, 18 Jan 2020 14:21:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ghj-YJvwlb08; Sat, 18 Jan 2020 14:21:55 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5AE52BE7B; Sat, 18 Jan 2020 14:21:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579357315; bh=x70hP/7h+FgdkTmWXfF/efFFt+Z8lwjLNQCEjyuwXHo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PZqidbU6fBau3vcmVvx1UrXUxuatQ1OcGtEy9ofOpeLXjADhyJv//Tz2mk2jVzRie /9DrO0JtPFYj/z5WjTpBf0lh3e3mL4EdYHHL+LalzfLWOdLh5uUvV5mJdGYDPcQVl6 eKIfZ6JoIDV64cuiOZOmm1YMTGuZrScV1Qahlbrw= To: Ryan Sleevi , Alan DeKok Cc: "Owen Friel (ofriel)" , EMU WG , Michael Richardson , "spasm@ietf.org" , Benjamin Kaduk , Joseph Salowey References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <3f964440-37d4-a08e-3d86-10ea712e99ca@cs.tcd.ie> Date: Sat, 18 Jan 2020 14:21:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------00DDBA1DA5F75C1F8DE259A3" Content-Language: en-US Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 14:22:02 -0000 This is a multi-part message in MIME format. --------------00DDBA1DA5F75C1F8DE259A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hiya, On 18/01/2020 13:55, Ryan Sleevi wrote: > No. The root store operators make the rules. Standards that align with > their needs are the standards they use and apply. > > Nothing you say or do has any impact without implementor, and if you go > against the grain of where implementors are going or already at, they are > useless standards that will be ignored. > > It would similarly be a mistake to think “Ah, but I control an SMTP server, > I am thus an implementor and empowered”. You are indeed an implementor... > for your root store. And if existing contracts and requirements prevent a > CA from serving your needs from the same hierarchy they are serving other > root store needs, which they increasingly will, then again, there’s no real > power unless you define your own root store. I have to say that comes across as fairly arrogant. I guess that's by the by, but it makes me happy that I don't need to play in the CAB forum space:-) [I'm sure it wasn't meant to be arrogant, and it has been a long thread which can lead to irritability, but that's how it struck me.] I've no real axe to grind here (definitely not wrt EAP), but, as a private key holder I do use web PKI CAs for email servers as well as for web servers. Turning that off would disimprove security for the Internet without (IMO) any real justification as to it producing a real improvement in the web PKI. (I do control the domains.) I don't buy that mentions of diginotar or equivalent misissuance problems are really relevant myself. That, and I've always considered CP/CPS as legal window dressing, initially for the benefit of CAs but judging from the above, now apparently mostly for the benefit of web PKI root store maintainers (aka browsers). So yeah, count me amongst those who'd suggest fixing the policy to match what's better for the Internet is the right approach, even if it's not an approach that might get traction in CAB forum. S. --------------00DDBA1DA5F75C1F8DE259A3 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =YzQY -----END PGP PUBLIC KEY BLOCK----- --------------00DDBA1DA5F75C1F8DE259A3-- From nobody Sat Jan 18 06:43:21 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8E12002E; Sat, 18 Jan 2020 06:43:15 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TwZgR48ZS2fx; Sat, 18 Jan 2020 06:43:13 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F009C120013; Sat, 18 Jan 2020 06:43:12 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id B4AF4692; Sat, 18 Jan 2020 14:43:09 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Sat, 18 Jan 2020 09:43:08 -0500 Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 14:43:16 -0000 On Jan 18, 2020, at 8:55 AM, Ryan Sleevi wrote: > On Sat, Jan 18, 2020 at 8:05 AM Alan DeKok = wrote: > As noted by Michael, CAs are using certificates in a way that = violates their own policy.=20 >=20 > Um, no. I largely didn=E2=80=99t respond to Michael=E2=80=99s email = because it missed the mark rather substantially, In what way? It seems pretty black and white to me. Your claim is that non-WWW use = of these certs violates the policies of a particular CA. Michael showed = that the same CA was using certs for non-WWW purposes. You can't have it both ways. Either your claims are true, and the CA = should revoke the cert it's using for SMTP. Or, your claims are false, = and the CA's policy is *not* to revoke certs when used for non-WWW = purposes. This is really the major disconnect here. You're making fairly = serious claims, and have little or no evidence to back them up. You = just can't say that Michael's email "missed the mark rather = substantially", and expect everyone to believe that naked assertion. To put it another way, there are multiple people who read your = statements as meaning one thing, but when pressed, you claim that you = meant something else entirely. > and I suspect folks still haven=E2=80=99t actually read the CP/CPSes = or done the work. Those policies can best be described as "opaque". There is no clear = statement that "using certs with id-kp-serverAuth in non-WWW protocols = is grounds for revocation". > No. The root store operators make the rules. Standards that align with = their needs are the standards they use and apply. Then this is an issue of warring standards bodies. Each one thinks = that they're in charge. Their requirements conflict. So *someone* has = to win. The IETF has defined id-kp-serverAuth as "TLS WWW", *and* suggested = it's use in non-WWW protocols. This is a conflict that the IETF has to = fix. Separately, people have discovered that using WWW certificates in = non-WWW protocols is cheap, easy, and solves a need. The failure here = is both that CAs make it difficult to get non-WWW certificates, and = implementors make it difficult to use different root stores. > When a vendor, be it Apple or Microsoft or Mozilla or Google, says a = CA in their root store needs to do something, they need to do it. If you = don=E2=80=99t like that, which the email clearly demonstrates, there = isn=E2=80=99t a heckler=E2=80=99s veto via the IETF: you instead need to = create your own root store to do the things you want or like. Attempting = to change those policies via the IETF, without understanding why they = exist, just leads to IETF standards being ignored because they are not = useful nor aligned with the needs of consumers. If everyone finds it useful to violate CA policies, then we need to = find a way to fix that. I suggest that fixing CA policies is likely = simpler than fixing millions (or billions) of implementations. > You=E2=80=99re seemingly fixated on the detail of the EKU, without = acknowledging that the EKU is merely a technical example of the broader = point of how requirements and policies work and flow, and how = certificate consumers, even when used over the same transport substrate = (TLS), have substantially different operational considerations. Those = operational considerations impact the design of the PKI and thus the = selection of the roots, and why multiple root stores, with their own = policies and expectations, is the natural end-point. I'm fixated on the EKU because it is a concrete example to pin an = argument on. We can have a vague discussion about generic policies, but = that would be unproductive. > The important thing, that I keep trying to emphasize, is that separate = policies are best technically accounted for at different roots. Yes, the = dream of PKI was one root per organization and a grand and global mesh = network of policy, and so we have all this technical complexity in specs = like RFC 5280 to accomplish that. But the technology does not work, in = the real world, and in fact makes it more difficult and risky, rather = than less. So just use separate PKIs, built to common profiles when = applicable/relevant, and move on. What happens in other PKIs shouldn=E2=80= =99t affect you or be relevant, much like ISO standardizing how food = processing equipment should be inspected is not really relevant here. Where can I get a certificate with id-kp-eapOverLAN? Or where can I = get a cert designed for use with STMP, XMPP, etc.? If the answer is "nowhere", then that's a problem. The CAs have = neglected their responsibilities to the customers. And in the failure = of the CAs to do things properly, customers use what works: use = id-kp-serverAuth. If the CAs don't like that, they have only themselves to blame. Alan DeKok. From nobody Sat Jan 18 07:15:05 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94238120013; Sat, 18 Jan 2020 07:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 jpgCeFFtphgM; Sat, 18 Jan 2020 07:14:55 -0800 (PST) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AEC120019; Sat, 18 Jan 2020 07:14:55 -0800 (PST) Received: by mail-ed1-f53.google.com with SMTP id m8so25172414edi.13; Sat, 18 Jan 2020 07:14:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e4fTcdOAXwB9Tce3qS3zmGZC/QQgWRTLSPy/InbfQXA=; b=KSOM+QTq3RbLP7QgJlEvfkLzFs9GVFmfxLdtzY/6hCuF3rBnrkc5YfFxfIkO3+Cmlq gUK+TUmvd/+rZtqdzEQRfntoDhDLRaokZrpHIL0vzWp4UqL9uwT45PQJIgNdD41swxLc 7xxrqtJ+vPn2Ky9vROsR0yuvuRi8L3ou+9p12d5wlNiEZBQy1LejcH1aaiY87Efkk2Ps PR4eEVYKzksAFDYugOoSqVk3TkZamwjGjdQNiZyj3DqG4l58l30zZgyHom3yjpc7Ok9F pIgRLocn6DDyZZf44Y/FOozOgjujLIanMs2aLMEezaYUYq1J06v66jUTgYQLWzBKExPH AtJQ== X-Gm-Message-State: APjAAAX7lU/wJKQuSdteFTp1K7hHZlY1C1/WMF1tBJUf3GtGDg8jAfkv 3lM5Zn+IOMPb4rKP/+ITlaFEmdVP X-Google-Smtp-Source: APXvYqxuBWOzi6ntdKoEzRDFEHRou2qQbRISQK9mK2SwJpuPWyAGKf9I9doxxT5lvwju4JLi+Z2GZg== X-Received: by 2002:a17:907:11cc:: with SMTP id va12mr12637224ejb.164.1579360493281; Sat, 18 Jan 2020 07:14:53 -0800 (PST) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com. [209.85.221.52]) by smtp.gmail.com with ESMTPSA id s16sm1155039edy.51.2020.01.18.07.14.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jan 2020 07:14:52 -0800 (PST) Received: by mail-wr1-f52.google.com with SMTP id q6so25283471wro.9; Sat, 18 Jan 2020 07:14:52 -0800 (PST) X-Received: by 2002:adf:ff8a:: with SMTP id j10mr8756630wrr.312.1579360492336; Sat, 18 Jan 2020 07:14:52 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <3f964440-37d4-a08e-3d86-10ea712e99ca@cs.tcd.ie> In-Reply-To: <3f964440-37d4-a08e-3d86-10ea712e99ca@cs.tcd.ie> From: Ryan Sleevi Date: Sat, 18 Jan 2020 10:14:41 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Farrell Cc: Alan DeKok , Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001e3cbb059c6b85ec" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 15:14:57 -0000 --0000000000001e3cbb059c6b85ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 18, 2020 at 9:22 AM Stephen Farrell wrote: > > Hiya, > > On 18/01/2020 13:55, Ryan Sleevi wrote: > > No. The root store operators make the rules. Standards that align with > > their needs are the standards they use and apply. > > > > Nothing you say or do has any impact without implementor, and if you go > > against the grain of where implementors are going or already at, they a= re > > useless standards that will be ignored. > > > > It would similarly be a mistake to think =E2=80=9CAh, but I control an = SMTP > server, > > I am thus an implementor and empowered=E2=80=9D. You are indeed an impl= ementor... > > for your root store. And if existing contracts and requirements prevent= a > > CA from serving your needs from the same hierarchy they are serving oth= er > > root store needs, which they increasingly will, then again, there=E2=80= =99s no > real > > power unless you define your own root store. > > I have to say that comes across as fairly arrogant. I guess > that's by the by, but it makes me happy that I don't need > to play in the CAB forum space:-) [I'm sure it wasn't meant > to be arrogant, and it has been a long thread which can > lead to irritability, but that's how it struck me.] It certainly was not meant that way. It is the essence of =E2=80=9Crough consensus and running code=E2=80=9D. St= andards that describe idealized states, that don=E2=80=99t reflect reality, are standard= s that aren=E2=80=99t valuable. Similarly, when we talk standards that do things l= ike deprecate insecure crypto or older protocol versions, we know there isn=E2= =80=99t an IETF Enforcement Bureau that makes sure all of the =E2=80=9C-diediedie= =E2=80=9D drafts are observed and implemented In a timely fashion. That=E2=80=99s what makes= jokes like RFC 6919 so endearing and funny, because we know that it better reflects our unfortunate realities than 2119. I've no real axe to grind here (definitely not wrt EAP), > but, as a private key holder I do use web PKI CAs for > email servers as well as for web servers. Turning that > off would disimprove security for the Internet without > (IMO) any real justification as to it producing a real > improvement in the web PKI. (I do control the domains.) > I don't buy that mentions of diginotar or equivalent > misissuance problems are really relevant myself. They are relevant in that they require they all be treated the same, for legal, policy, and other non-technical reasons, even when it=E2=80=99s understandably undesirable. I don=E2=80=99t disagree that there=E2=80=99s ample need for robust TLS iss= uance, and I agree that there=E2=80=99s ample ill-definition about what =E2=80=9CWWW aut= hentication=E2=80=9D means and contains. Some CPSes are more explicit, some less, about what they allow. Supposedly, every time you=E2=80=99re getting a cert, you=E2=80= =99re carefully reviewing all of these agreements as part of your selection of which CA to use ;) That, and I've always considered CP/CPS as legal window > dressing, initially for the benefit of CAs but judging > from the above, now apparently mostly for the benefit of > web PKI root store maintainers (aka browsers). I mean, this is why RFC 3647 exists. It exists for CAs to shift liability to Relying Parties (=E2=80=9CWe told you we do this stupid thing, right her= e=E2=80=9D), and for Root Stores to shift liability to CAs (=E2=80=9CYou told us you would d= o this, right here=E2=80=9D). CAs like to use it to further try to defend against a= ny risk of distrust (=E2=80=9CWe told you we would do a stupid thing, and you trust= ed us anyway, so you can=E2=80=99t distrust us for doing a stupid thing=E2=80=9D) There are CPSes that don=E2=80=99t include problematic clauses regarding EK= Us, for sure, or which explicitly state how it=E2=80=99s interpreted in their PKI. = That particular example is not meant to be a =E2=80=9Cuniversal example=E2=80=9D= of something forbidden, but to highlight how even if one relying party would like to ignore the CPS, when there are multiple constituencies, that doesn=E2=80=99= t work. The only way you sort through those is to make sure the only two parties are you and the CA - aka defining a root store. --0000000000001e3cbb059c6b85ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jan 18, 2020 at 9:22 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wro= te:

Hiya,

On 18/01/2020 13:55, Ryan Sleevi wrote:
> No. The root store operators make the rules. Standards that align with=
> their needs are the standards they use and apply.
>
> Nothing you say or do has any impact without implementor, and if you g= o
> against the grain of where implementors are going or already at, they = are
> useless standards that will be ignored.
>
> It would similarly be a mistake to think =E2=80=9CAh, but I control an= SMTP server,
> I am thus an implementor and empowered=E2=80=9D. You are indeed an imp= lementor...
> for your root store. And if existing contracts and requirements preven= t a
> CA from serving your needs from the same hierarchy they are serving ot= her
> root store needs, which they increasingly will, then again, there=E2= =80=99s no real
> power unless you define your own root store.

I have to say that comes across as fairly arrogant. I guess
that's by the by, but it makes me happy that I don't need
to play in the CAB forum space:-) [I'm sure it wasn't meant
to be arrogant, and it has been a long thread which can
lead to irritability, but that's how it struck me.]

It certainly was not meant that way.=

It is the essence of = =E2=80=9Crough consensus and running code=E2=80=9D. Standards that describe= idealized states, that don=E2=80=99t reflect reality, are standards that a= ren=E2=80=99t valuable. Similarly, when we talk standards that do things li= ke deprecate insecure crypto or older protocol versions, we know there isn= =E2=80=99t an IETF Enforcement Bureau that makes sure all of the =E2=80=9C-= diediedie=E2=80=9D drafts are observed and implemented In a timely fashion.= That=E2=80=99s what makes jokes like RFC 6919 so endearing and funny, beca= use we know that it better reflects our unfortunate realities than 2119.

I've no real axe to grind here (definitely not wrt EAP),
but, as a private key holder I do use web PKI CAs for
email servers as well as for web servers. Turning that
off would disimprove security for the Internet without
(IMO) any real justification as to it producing a real
improvement in the web PKI. (I do control the domains.)
I don't buy that mentions of diginotar or equivalent
misissuance problems are really relevant myself.

They are relevant in that they require they= all be treated the same, for legal, policy, and other non-technical reason= s, even when it=E2=80=99s understandably undesirable.

I don=E2=80=99t disagree that there=E2=80=99s= ample need for robust TLS issuance, and I agree that there=E2=80=99s ample= ill-definition about what =E2=80=9CWWW authentication=E2=80=9D means and c= ontains. Some CPSes are more explicit, some less, about what they allow. Su= pposedly, every time you=E2=80=99re getting a cert, you=E2=80=99re carefull= y reviewing all of these agreements as part of your selection of which CA t= o use ;)

That, and I've always considered CP/CPS as legal window
dressing, initially for the benefit of CAs but judging
from the above, now apparently mostly for the benefit of
web PKI root store maintainers (aka browsers).

I mean, this is why RFC 3647 exists. It exist= s for CAs to shift liability to Relying Parties (=E2=80=9CWe told you we do= this stupid thing, right here=E2=80=9D), and for Root Stores to shift liab= ility to CAs (=E2=80=9CYou told us you would do this, right here=E2=80=9D).= CAs like to use it to further try to defend against any risk of distrust (= =E2=80=9CWe told you we would do a stupid thing, and you trusted us anyway,= so you can=E2=80=99t distrust us for doing a stupid thing=E2=80=9D)
<= div dir=3D"auto">
There are CPSes that don=E2=80= =99t include problematic clauses regarding EKUs, for sure, or which explici= tly state how it=E2=80=99s interpreted in their PKI. That particular exampl= e is not meant to be a =E2=80=9Cuniversal example=E2=80=9D of something for= bidden, but to highlight how even if one relying party would like to ignore= the CPS, when there are multiple constituencies, that doesn=E2=80=99t work= . The only way you sort through those is to make sure the only two parties = are you and the CA - aka defining a root store.
--0000000000001e3cbb059c6b85ec-- From nobody Sat Jan 18 07:28:57 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8712001A; Sat, 18 Jan 2020 07:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ovSzz9Z_RVHe; Sat, 18 Jan 2020 07:28:49 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B416F120013; Sat, 18 Jan 2020 07:28:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F59ABE7B; Sat, 18 Jan 2020 15:28:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_wb_ZqssB_b; Sat, 18 Jan 2020 15:28:44 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 839BFBE77; Sat, 18 Jan 2020 15:28:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1579361324; bh=OkhBfdUnF3I7xbwk9q5naUY4NZIiRi5aWGHxwMvMk1s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LZFBkUJ85xz/PxiY9KqMcMCNcIUls4lLcSK6TPLr5UApTpt4pd3yLcvaKyMt0zckZ ezl4XDv6S5sP1M1ox81bz7oc2QJyaBn601e+EB0Ej0c7/JIkanCmNyjDXU7W7tHV2t DdMZGjbGpSoKjTdIwi6ebKGHCHpK+We+rRA4Xois= To: Ryan Sleevi Cc: Alan DeKok , Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" References: <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <3f964440-37d4-a08e-3d86-10ea712e99ca@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <1ede2312-82b2-0437-a7c5-57a733df078d@cs.tcd.ie> Date: Sat, 18 Jan 2020 15:28:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------100D51BC5C6D3CD05058E33F" Content-Language: en-US Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 15:28:51 -0000 This is a multi-part message in MIME format. --------------100D51BC5C6D3CD05058E33F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hiya, On 18/01/2020 15:14, Ryan Sleevi wrote: > The only way you sort through those is to make sure the only two parties > are you and the CA - aka defining a root store. I disagree. PKI inherently has 3 parties involved. Ignoring any one or two of them is what I think leads to the kind of silliness that results in us even mentioning possible mass revocation because of an ill-defined OID. Heartbleed might just about have justified that, this very much does not. I do fully agree with you that the idea that end entities ever read a CP/CPS is about as realistic as "click yes to accept cookies" or other similar things being meaningful. Sadly, such legal nonsense does seem to be required but we ought not let it drive what we do - in this case, IMO the blindingly obviously correct thing to do is to recognise the reality of the use of the OID and regularise that. But if that's not going to happen, then the 2nd best (and 99.999% just as good) thing to do is to happily continue to ignore the supposed problem. Cheers, S. --------------100D51BC5C6D3CD05058E33F Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =YzQY -----END PGP PUBLIC KEY BLOCK----- --------------100D51BC5C6D3CD05058E33F-- From nobody Sat Jan 18 08:18:08 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9639120077; Sat, 18 Jan 2020 08:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 L1l8T_ka2WM1; Sat, 18 Jan 2020 08:17:45 -0800 (PST) Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C4912002F; Sat, 18 Jan 2020 08:17:45 -0800 (PST) Received: by mail-ed1-f65.google.com with SMTP id cy15so25329999edb.4; Sat, 18 Jan 2020 08:17:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lT6yHtPjjLheuHqornadbl2oGZ2zL94f63Ha/2IZT+4=; b=lKCu9Jh1zAuXN4+xhtNz7M1ENapmDr8CtPta7J69KxrZU43+bkm1rDxwtlo5YNgiol CLLTf+7C0sM/fxFi6o6Z2+UUTG+WRFNKWAgy2Y9HgQettkKgQsEY8l3TPNiRqWVqlwCl tXQcmEunuDEJu0Z7STFha07b2m8l3KpfbYeZtRvbAMJlrq7l+/ek8TtXPqD1WlRMJqIk VUbcvik2ySDUjqHwwpoLl6eOvw/sv76c+YyRkEjxP850/k88nP/akXz6Ed1HglIpCm2J VDEKbFYWE7wIh7AkUWaqaILVVhQZX1KgtzIM1nNWFLnqmf/YjZeZ2XA2uovCh7++zZAO ehmw== X-Gm-Message-State: APjAAAXH/T8VPDuQ5IAZreVIcyQAV4mXzAmJnWpFxJHAu+YANDlsva1f Y56VUfVF0isThU92qtjluey8Ruvx X-Google-Smtp-Source: APXvYqxblYRX2IOsYdnSAK6pVMpj0FPvWUsLlyGPLp6a6ulbQJG2ghYGVdfJzC05QKEs2iC2SEuwAw== X-Received: by 2002:aa7:c2cb:: with SMTP id m11mr9947793edp.89.1579364263375; Sat, 18 Jan 2020 08:17:43 -0800 (PST) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com. [209.85.221.49]) by smtp.gmail.com with ESMTPSA id g4sm1111332edl.6.2020.01.18.08.17.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jan 2020 08:17:42 -0800 (PST) Received: by mail-wr1-f49.google.com with SMTP id z3so25485917wru.3; Sat, 18 Jan 2020 08:17:42 -0800 (PST) X-Received: by 2002:a5d:51cc:: with SMTP id n12mr9260026wrv.177.1579364261719; Sat, 18 Jan 2020 08:17:41 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> In-Reply-To: <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> From: Ryan Sleevi Date: Sat, 18 Jan 2020 11:10:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ca778b059c6c65a1" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 16:17:48 -0000 --000000000000ca778b059c6c65a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 18, 2020 at 9:43 AM Alan DeKok wrote: > On Jan 18, 2020, at 8:55 AM, Ryan Sleevi wrote: > > Um, no. I largely didn=E2=80=99t respond to Michael=E2=80=99s email bec= ause it missed > the mark rather substantially, > > In what way? Which CAs (plural) are you referring to? The CertSign example given - the stronger of the restrictive CPSes - uses a cert from a CA not subject to these (or any) requirements. That is, it=E2=80=99s an untrusted root. Certificates from other services were examined, but without a similar analysis of the issuing CA, which is the point. You can=E2=80=99t claim mul= tiple CAs, when there was a smattering of examples without any evidence of an analysis of the relevant CP/CPS. If the point was a singular CA seeming to violate their CP/CPS (that is, DigiCert), then yes, absolutely, you can go submit a CA problem report and the CA is obligated to respond in 24 hours with their analysis to your problem report. It=E2=80=99s the same procedure if, for example, you ever h= andled a private key for a certificate issued by DigiCert and had not had a background check conducted and/or conducted a background check on anyone you have access to. > and I suspect folks still haven=E2=80=99t actually read the CP/CPSes or d= one the > work. > > Those policies can best be described as "opaque". There is no clear > statement that "using certs with id-kp-serverAuth in non-WWW protocols is > grounds for revocation". I whole heartedly agree! To continue to connect it back to the original discussion, so that thread is not lost: if your use case (for example, EAP-TLS) wants to allow subjectivity and flexibility in how statements like this are interpreted, then you have to make sure other stakeholders are not also involved. That=E2=80=99s all. Obviously, CAs can (and do) paint themselves in corners of absurdity, much in the same way specs can end up with internal contradictions and inconsistencies. In order to untangle those bits, everyone has to agree. And it=E2=80=99s easier to get agreement among just two or three than it is= around two dozen, especially when contracts and agreements are involved. As it ties back to the original discussion, it=E2=80=99s not _just_ agreeme= nts on the CP/CPS you need to worry about, but things like profiles and transition timelines and acceptable practices. The more stakeholders you continually add, the harder it is to find agreement or interoperability. The joy of PKI is that the solution is simple: disparate policies, enshrined by disparate hierarchies, since multiple policies for a single hierarchy doesn=E2=80=99t= work in practice. The IETF has defined id-kp-serverAuth as "TLS WWW", *and* suggested it's > use in non-WWW protocols. This is a conflict that the IETF has to fix. Agreed. However, and this is where it=E2=80=99s messy: the IETF getting its house i= n order here does not resolve conflicts Once and For All. That=E2=80=99s because, f= or better or worse, the certificatePolicies extension doesn=E2=80=99t work, an= d so EKU has (and this was debated in PKIX even before 5280 replaced 3280) become synonymous with policy, at least by implementors. The best analogy I can think of is comparing to the X.501 DN attributes. X.501 defines their syntax, and tries to define the semantics, but in the absence of the global DIT, what a given attribute means and how it=E2=80=99= s validated depends on the context and issues. That is, the value of an Organization field, or an OrganizationIdentifier, is going to depend on which PKI it is used in. The same is true for EKU, for better or for worse. If everyone finds it useful to violate CA policies, then we need to find > a way to fix that. I suggest that fixing CA policies is likely simpler > than fixing millions (or billions) of implementations. Oh, I agree whole heartedly there. I'm fixated on the EKU because it is a concrete example to pin an > argument on. We can have a vague discussion about generic policies, but > that would be unproductive. The entire point is the generic policies being why it=E2=80=99s important t= o separate things, and why it=E2=80=99s problematic to just assume one cert c= an or should work everywhere. What you=E2=80=99re calling unproductive is the ess= ence and totality of the message, and perhaps that=E2=80=99s why I similarly find it unproductive to fixate on the single field and ignore the overall point. Where can I get a certificate with id-kp-eapOverLAN? Or where can I get > a cert designed for use with STMP, XMPP, etc.? https://wiki.xmpp.org/web/XMPP_Server_Certificates https://xmpp.org/about/xsf/records/proposals/intermediate-certificate-autho= rity If the answer is "nowhere", then that's a problem. The CAs have > neglected their responsibilities to the customers. This is the problem with ignoring the broader message. =E2=80=9CThe CAs=E2= =80=9D is a term without useful meaning. Everyone can be a CA. You can be a CA. I can be a CA. Anyone who wants can issue certificates. There=E2=80=99s no set of enti= ties blessed in some special power which only they can mint certificates, and thus their choices not to do so somehow be a sign of neglect. If you mean =E2=80=9CThe CAs=E2=80=9D as the organizations operating key ma= terial in certain root stores, then many (most?) will happily issue you whatever certificates you want, from a hierarchy dedicated to your needs. I don=E2= =80=99t even need to provide advertising links, just pick your favorite vendor and ask them about =E2=80=9Cprivate=E2=80=9D or =E2=80=9Centerprise=E2=80=9D CA= offerings. Want id-kp-eapOverLan? Sure, plenty will happily do that for you, for a price. Don=E2=80=99t like the price? Run your own CA and issue them yoursel= f. There=E2=80=99s zero cost, and plenty of open-source tools to make =E2=80= =9Crun your own CA=E2=80=9D be a single line on a command-shell. Now, it may be that when you CAs, what you mean is =E2=80=9CI can=E2=80=99t= get a certificate from the set of organizations that operate private keys/trust anchors, trusted for this purpose in a default install of my operating system / browser / insert X here, and which chains to that public key=E2=80= =9D. That is, you can=E2=80=99t get one of these certs chaining to the same root= . Some might, but you=E2=80=99re right, that=E2=80=99s much more rare. And that=E2= =80=99s a feature, not a bug or neglect, because you should be using separate hierarchies if you have different needs. If you=E2=80=99re willing to accept id-kp-serverAuth, and willing to accept= that the interpretations and expectations will be dictated by the root store(s) recognizing that EKU, that as a Subscriber the timelines for changes will be dictated by those root stores, that as a Relying Party the profile will be dictated by those root stores, then yes, by all means, go ahead with that. Just know that, as a Subscriber and/or as a Relying Party, you can=E2= =80=99t complain when things change, if profiles are made incompatible, or if things change too soon. I=E2=80=99m not saying you absolutely cannot and should not use id-kp-serve= rAuth issued by CAs in common root stores. You just have to be aware that it=E2= =80=99s specifying your needs as =E2=80=9CI=E2=80=99ll have 100 of whatever Ryan or= ders for gears=E2=80=9D, and being prepared to accept that and make it work. --000000000000ca778b059c6c65a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div>
On Sat, Jan 18, 2020 at 9:43 AM A= lan DeKok <aland@deployingradius.com> wrote:
On Jan= 18, 2020, at 8:55 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> Um, no. I largely didn=E2=80=99t respond to Michael=E2=80=99s email be= cause it missed the mark rather substantially,

=C2=A0 In what way?

Which CAs (plural) are you referring to? The CertSign example= given - the stronger of the restrictive CPSes - uses a cert from a CA not = subject to these (or any) requirements. That is, it=E2=80=99s an untrusted = root.

Certificates= from other services were examined, but without a similar analysis of the i= ssuing CA, which is the point. You can=E2=80=99t claim multiple CAs, when t= here was a smattering of examples without any evidence of an analysis of th= e relevant CP/CPS.

If th= e point was a singular CA seeming to violate their CP/CPS (that is, DigiCer= t), then yes, absolutely, you can go submit a CA problem report and the CA = is obligated to respond in 24 hours with their analysis to your problem rep= ort. It=E2=80=99s the same procedure if, for example, you ever handled a pr= ivate key for a certificate issued by DigiCert and had not had a background= check conducted and/or conducted a background check on anyone you have acc= ess to.

> and I suspect folks still haven=E2=80=99t actually= read the CP/CPSes or done the work.

=C2=A0 Those policies can best be described as "opaque".=C2=A0 Th= ere is no clear statement that "using certs with id-kp-serverAuth in n= on-WWW protocols is grounds for revocation".

I whole heartedly agree! To continue to co= nnect it back to the original discussion, so that thread is not lost: if yo= ur use case (for example, EAP-TLS) wants to allow subjectivity and flexibil= ity in how statements like this are interpreted, then you have to make sure= other stakeholders are not also involved. That=E2=80=99s all.

Obviously, CAs can (and do) paint th= emselves in corners of absurdity, much in the same way specs can end up wit= h internal contradictions and inconsistencies. In order to untangle those b= its, everyone has to agree. And it=E2=80=99s easier to get agreement among = just two or three than it is around two dozen, especially when contracts an= d agreements are involved.

As it ties back to the original discussion, it=E2=80=99s not _just_ agre= ements on the CP/CPS you need to worry about, but things like profiles and = transition timelines and acceptable practices. The more stakeholders you co= ntinually add, the harder it is to find agreement or interoperability. The = joy of PKI is that the solution is simple: disparate policies, enshrined by= disparate hierarchies, since multiple policies for a single hierarchy does= n=E2=80=99t work in practice.

The IETF has defined id-kp-serverAuth as "TLS WWW", *and* su= ggested it's use in non-WWW protocols.=C2=A0 This is a conflict that th= e IETF has to fix.

Agreed.

However, and t= his is where it=E2=80=99s messy: the IETF getting its house in order here d= oes not resolve conflicts Once and For All. That=E2=80=99s because, for bet= ter or worse, the certificatePolicies extension doesn=E2=80=99t work, and s= o EKU has (and this was debated in PKIX even before 5280 replaced 3280) bec= ome synonymous with policy, at least by implementors.

The best analogy I can think of is comparing = to the X.501 DN attributes. X.501 defines their syntax, and tries to define= the semantics, but in the absence of the global DIT, what a given attribut= e means and how it=E2=80=99s validated depends on the context and issues. T= hat is, the value of an Organization field, or an OrganizationIdentifier, i= s going to depend on which PKI it is used in. The same is true for EKU, for= better or for worse.

=C2=A0 If everyone finds it useful to violate CA policies, then we need to = find a way to fix that.=C2=A0 I suggest that fixing CA policies is likely s= impler than fixing millions (or billions) of implementations.
<= div dir=3D"auto">
Oh, I agree whole heartedly th= ere.

=C2=A0 I'm fixated on the EKU because it is a concrete example to pin a= n argument on.=C2=A0 We can have a vague discussion about generic policies,= but that would be unproductive.

The entire point is the generic policies being why it=E2=80= =99s important to separate things, and why it=E2=80=99s problematic to just= assume one cert can or should work everywhere. What you=E2=80=99re calling= unproductive is the essence and totality of the message, and perhaps that= =E2=80=99s why I similarly find it unproductive to fixate on the single fie= ld and ignore the overall point.

=C2=A0 Where can I get a certificate with id-kp-eapOverLAN?=C2=A0 O= r where can I get a cert designed for use with STMP, XMPP, etc.?

=C2=A0 If the answer is "nowhere", then that's a problem.=C2= =A0 The CAs have neglected their responsibilities to the customers.

This is the problem wit= h ignoring the broader message. =E2=80=9CThe CAs=E2=80=9D is a term without= useful meaning. Everyone can be a CA. You can be a CA. I can be a CA. Anyo= ne who wants can issue certificates. There=E2=80=99s no set of entities ble= ssed in some special power which only they can mint certificates, and thus = their choices not to do so somehow be a sign of neglect.

If you mean =E2=80=9CThe CAs=E2=80=9D as t= he organizations operating key material in certain root stores, then many (= most?) will happily issue you whatever certificates you want, from a hierar= chy dedicated to your needs. I don=E2=80=99t even need to provide advertisi= ng links, just pick your favorite vendor and ask them about =E2=80=9Cprivat= e=E2=80=9D or =E2=80=9Centerprise=E2=80=9D CA offerings.

Want id-kp-eapOverLan? Sure, plenty will h= appily do that for you, for a price. Don=E2=80=99t like the price? Run your= own CA and issue them yourself. There=E2=80=99s zero cost, and plenty of o= pen-source tools to make =E2=80=9Crun your own CA=E2=80=9D be a single line= on a command-shell.

Now= , it may be that when you CAs, what you mean is =E2=80=9CI can=E2=80=99t ge= t a certificate from the set of organizations that operate private keys/tru= st anchors, trusted for this purpose in a default install of my operating s= ystem / browser / insert X here, and which chains to that public key=E2=80= =9D. That is, you can=E2=80=99t get one of these certs chaining to the same= root. Some might, but you=E2=80=99re right, that=E2=80=99s much more rare.= And that=E2=80=99s a feature, not a bug or neglect, because you should be = using separate hierarchies if you have different needs.

If you=E2=80=99re willing to accept id-kp-s= erverAuth, and willing to accept that the interpretations and expectations = will be dictated by the root store(s) recognizing that EKU, that as a Subsc= riber the timelines for changes will be dictated by those root stores, that= as a Relying Party the profile will be dictated by those root stores, then= yes, by all means, go ahead with that. Just know that, as a Subscriber and= /or as a Relying Party, you can=E2=80=99t complain when things change, if p= rofiles are made incompatible, or if things change too soon.

I=E2=80=99m not saying you absolutely= cannot and should not use id-kp-serverAuth issued by CAs in common root st= ores. You just have to be aware that it=E2=80=99s specifying your needs as = =E2=80=9CI=E2=80=99ll have 100 of whatever Ryan orders for gears=E2=80=9D, = and being prepared to accept that and make it work.
--000000000000ca778b059c6c65a1-- From nobody Sat Jan 18 11:23:55 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6000912003E; Sat, 18 Jan 2020 11:23:48 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 u0WlhnP6Hm8y; Sat, 18 Jan 2020 11:23:45 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2B5120019; Sat, 18 Jan 2020 11:23:45 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id C22727AD; Sat, 18 Jan 2020 19:23:41 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Sat, 18 Jan 2020 14:23:40 -0500 Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 19:23:48 -0000 On Jan 18, 2020, at 11:10 AM, Ryan Sleevi wrote: > If the point was a singular CA seeming to violate their CP/CPS (that = is, DigiCert), then yes, absolutely, you can go submit a CA problem = report and the CA is obligated to respond in 24 hours with their = analysis to your problem report.=20 I would recommend putting policies into practice. I disagree with those policies, so I don't feel responsible for = putting them into practice. > > Those policies can best be described as "opaque". There is no = clear statement that "using certs with id-kp-serverAuth in non-WWW = protocols is grounds for revocation". >=20 > I whole heartedly agree! To continue to connect it back to the = original discussion, so that thread is not lost: if your use case (for = example, EAP-TLS) wants to allow subjectivity and flexibility in how = statements like this are interpreted, then you have to make sure other = stakeholders are not also involved. That=E2=80=99s all. I don't understand the relevance of that statement. The concern is that *existing* CAs have policies which prevent EAP-TLS = admins from using their certificates. These policies apply to pretty = much all non-WWW protocols. The implication above is that these people = can just start their own CAs. That's nice, but doesn't solve the problem. > Where can I get a certificate with id-kp-eapOverLAN? Or where can I = get a cert designed for use with STMP, XMPP, etc.? >=20 > https://wiki.xmpp.org/web/XMPP_Server_Certificates > = https://xmpp.org/about/xsf/records/proposals/intermediate-certificate-auth= ority XMPP. Not id-kp-eapOverLAN. And not SMTP, not RADIUS over TLS Not = DNS over TLS, and so on. > This is the problem with ignoring the broader message. =E2=80=9CThe = CAs=E2=80=9D is a term without useful meaning. Everyone can be a CA. You = can be a CA. I can be a CA. Anyone who wants can issue certificates. = There=E2=80=99s no set of entities blessed in some special power which = only they can mint certificates, and thus their choices not to do so = somehow be a sign of neglect. That is mostly true, but unhelpful. Windows doesn't ship with "Billy = bob's tackle shop & CA" root certificates. Neither does Linux, OSX, = etc. Your statement here is just a rephrasing of "use a private CA", = and "manually configure things". The root CAs that ship on modern OS distributions *are* blessed with a = special power. Only they can mint certificates which are = *automatically* trusted by most applications on the OS. > Want id-kp-eapOverLan? Sure, plenty will happily do that for you, for = a price. Don=E2=80=99t like the price? Run your own CA and issue them = yourself. There=E2=80=99s zero cost, and plenty of open-source tools to = make =E2=80=9Crun your own CA=E2=80=9D be a single line on a = command-shell. Windows actually *forbids* id-kp-eapOverLAN from being used by the = well-known root CAs: = https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-= server-2012-r2-and-2012/jj200219(v%3Dws.11) ... You must deploy a private CA rather than obtain server certificates from = a third party public CA. In addition, the certificate template that you = use to issue the certificates must contain the RADIUS EKU extension. = This extension is id-kp-eapOverLAN and the object identifier (OID) for = this EKU is 1.3.6.1.5.5.7.3.14. This EKU extension can only be = configured on a private CA and is used by Windows 8 to determine whether = a private CA issued the certificate. ... This use-case would also seem to be outside of the scope envisioned by = RFC 4334, which applies to client certificates. > Now, it may be that when you CAs, what you mean is =E2=80=9CI can=E2=80=99= t get a certificate from the set of organizations that operate private = keys/trust anchors, trusted for this purpose in a default install of my = operating system / browser / insert X here, and which chains to that = public key=E2=80=9D. That is, you can=E2=80=99t get one of these certs = chaining to the same root. Some might, but you=E2=80=99re right, = that=E2=80=99s much more rare. And that=E2=80=99s a feature, not a bug = or neglect, because you should be using separate hierarchies if you have = different needs. That statement is a decade too late. Alan DeKok. From nobody Sat Jan 18 11:56:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4124A120074; Sat, 18 Jan 2020 11:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 lgzwVoBqdIgT; Sat, 18 Jan 2020 11:56:50 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E28120019; Sat, 18 Jan 2020 11:56:50 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00IJqb84030902; Sat, 18 Jan 2020 19:56:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=rIjTEfEVJJr0xRfOnBGMqnberqjxwiR7Zl9yAxP1PW8=; b=nNlFk7TmxV/Ee4t8cRCX8s2IOyhktcbChK4gSRyo0gwBlxw5oGBang6V9hhdJePbPV3D hJc3xUym/Aom0I7y6ypFyjH21jGsImIRrT1ZP9lqVptR/UVQH1Ycq1X7P6YBfluMO815 G4bIYWKARbIwYCxfb87/rVWfFj8iafkvVS6So1/ggA4Jk9gpvVVJMf8nH6uFH7XfI786 ueMQmgcxLM8Qq5ghLFhNQh4GBFY5lfQAKmmYJSarI+TgA7C6D22MD0GFPKCx1hmU509B 3L7GsAZuTWXPoy1BrXK23q5wD4HGWQrwOKaAk0e/dMv7bpJKdonBs/0Y9ucTTCdet/E1 7A== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2xkyjqh4q6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jan 2020 19:56:50 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 00IJmMuR030014; Sat, 18 Jan 2020 11:56:49 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xm0vbg7r3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 18 Jan 2020 11:56:49 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 18 Jan 2020 14:56:48 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Sat, 18 Jan 2020 14:56:48 -0500 From: "Salz, Rich" To: Ryan Sleevi CC: EMU WG , "spasm@ietf.org" Thread-Topic: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic Thread-Index: AQHVxXm0e7J5rDEf+EOqsfcXsBtB+affyfIAgAAFKwCAABiWAIAAEKMAgAAU+ICAAEpjAIAAZ4qAgABUywCAAHFCAIAADVQAgAtuGYCAAA0IgIACc58AgAAjHoCAAKZdgIAAHagAgABgMYCAAA4UAIAADUwAgAAYVYCAADYNAP//tW+A Date: Sat, 18 Jan 2020 19:56:47 +0000 Message-ID: References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> In-Reply-To: <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.80] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001180164 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-18_07:2020-01-16, 2020-01-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 mlxscore=0 mlxlogscore=996 phishscore=0 malwarescore=0 impostorscore=0 clxscore=1011 bulkscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001180164 Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 19:56:52 -0000 PiBUaGVyZeKAmXMgbm8gc2V0IG9mIGVudGl0aWVzIGJsZXNzZWQgaW4gc29tZSBzcGVjaWFsIHBv d2VyIHdoaWNoIG9ubHkgdGhleSBjYW4gbWludCBjZXJ0aWZpY2F0ZXMNCg0KVGhhbmsgeW91IGZv ciBpbmplY3Rpbmcgc29tZSBtdWNoLW5lZWRlZCBodW1vciBpbnRvIHRoaXMgdGhyZWFkLiAgVGhh dCdzIHRoZSBmdW5uaWVzdCBmLS0taW5nIHRoaW5nIEkndmUgcmVhZCBmcm9tIHlvdSBpbiBhIGxv bmcgdGltZS4NCiANCg0K From nobody Sat Jan 18 13:11:33 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11F1120019; Sat, 18 Jan 2020 13:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 jhYgKu9a1s3n; Sat, 18 Jan 2020 13:11:25 -0800 (PST) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F115120074; Sat, 18 Jan 2020 13:11:25 -0800 (PST) Received: by mail-ed1-f43.google.com with SMTP id b8so25814774edx.7; Sat, 18 Jan 2020 13:11:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WRefz/pczOuDH44plo2AiYWL70WXXEqt0vl7y//msMk=; b=FrH+NprwIkAVaRe6w+vSm6AHas2zI3IOsv/QQFXeIZ7lKcjEHFOveaKfWMK1AMavdA Y3Y7SOJK2euSFssQh0PZd1AGOTLp75ZPCanwujDpZVQ0MyZWS3MlKEkeyG6FSRq9mJ0y d3VEOOFEyP3OgWAle+yYIST5W5O7wAhJYRy+FMovLi8CN5Z3p6YOBKhFE87gxaGXk4y9 UCFufYhf81loQw31yAVdkCB9h8YQb20LQc2yTtNIWcDgjMKVn+UX8erJUrpwFod7XFvt Ls0Z55QsWdOfdj7I68lIsf+5Xhtow4ouwcrfCvOhTIK1qEGgqcO1/NoefkKRlwAyzaPY E3Sw== X-Gm-Message-State: APjAAAVjASYQWaX9pgQibK6HQn/x6nrWiqgmmFCMXa6avGNmQxid/FsX ybfDDufdIEsNGyPAw5p08pKDLttg67c= X-Google-Smtp-Source: APXvYqy6zpMvVzT7MFAMRSlXw+3LjbzOHtFBDVok36XM4lMvjF8CwFgDSpn1Qk3t0LiHeMyZofjCmw== X-Received: by 2002:a05:6402:1d9a:: with SMTP id dk26mr10921026edb.37.1579381883302; Sat, 18 Jan 2020 13:11:23 -0800 (PST) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com. [209.85.128.42]) by smtp.gmail.com with ESMTPSA id o1sm1162958edr.14.2020.01.18.13.11.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jan 2020 13:11:22 -0800 (PST) Received: by mail-wm1-f42.google.com with SMTP id a5so10712781wmb.0; Sat, 18 Jan 2020 13:11:22 -0800 (PST) X-Received: by 2002:a05:600c:149:: with SMTP id w9mr10617395wmm.132.1579381882379; Sat, 18 Jan 2020 13:11:22 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> In-Reply-To: <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> From: Ryan Sleevi Date: Sat, 18 Jan 2020 16:11:11 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000106385059c7080e5" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 21:11:27 -0000 --000000000000106385059c7080e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 18, 2020 at 2:23 PM Alan DeKok wrote: > > Where can I get a certificate with id-kp-eapOverLAN? Or where can I > get a cert designed for use with STMP, XMPP, etc.? > > > > https://wiki.xmpp.org/web/XMPP_Server_Certificates > > > https://xmpp.org/about/xsf/records/proposals/intermediate-certificate-aut= hority > > XMPP. Not id-kp-eapOverLAN. And not SMTP, not RADIUS over TLS Not DN= S > over TLS, and so on. You=E2=80=99re conflating several things, as well as seemingly shifting the= goal posts here. Perhaps it=E2=80=99s just a poor expression of the problem, as = you see it, in which case, it might help to be clearer. _Some_ CAs forbid their certificates from being used with web servers. _Some_ CAs forbid their certificates from being used with SMTP, or DNS over TLS, or XMPP. If those CAs certificates are used for those purposes, they need to be revoked if the CA obtains evidence of this. If the CA doesn=E2=80=99t like that, they can change their policies - altho= ugh in many cases, how they=E2=80=99ve forbidden things do not retroactively permi= t it. If the Subscriber doesn=E2=80=99t like this, they can choose another CA. If the software developer doesn=E2=80=99t like this, they can trust differe= nt CAs. Can=E2=80=99t get eapOverLan from a TLS CA? Ok. That=E2=80=99s not a bug, t= hat=E2=80=99s not a misdesign, that=E2=80=99s how it works and is supposed to work. The CA you=E2=80=99d like to use has a policy that forbids using your certi= ficates that way? Find a different CA. Run your own internal CA. These aren=E2=80= =99t difficult or unreasonable things. > This is the problem with ignoring the broader message. =E2=80=9CThe CAs= =E2=80=9D is a > term without useful meaning. Everyone can be a CA. You can be a CA. I can > be a CA. Anyone who wants can issue certificates. There=E2=80=99s no set = of > entities blessed in some special power which only they can mint > certificates, and thus their choices not to do so somehow be a sign of > neglect. > > That is mostly true, but unhelpful. Windows doesn't ship with "Billy > bob's tackle shop & CA" root certificates. Neither does Linux, OSX, etc. > Your statement here is just a rephrasing of "use a private CA", and > "manually configure things". Yes, exactly, which is why I=E2=80=99m not sure the objection. This is why I tried to cleanly separate out the problems, which seem to keep getting conflated. The problem of =E2=80=9Cwhat does it mean today=E2= =80=9D and =E2=80=9Cwhat does it mean in a future where nothing has to be manually configured=E2=80= =9D are different problems, and it=E2=80=99s unreasonable to keep demanding that th= e second be solved when addressing the first. The root CAs that ship on modern OS distributions *are* blessed with a > special power. Only they can mint certificates which are *automatically* > trusted by most applications on the OS. For certain purposes, according to certain policies. If you don=E2=80=99t like those policies, or you want more purposes, do you= r own thing. The same modern OS distributions provide that capability for applications to do so, to allow the application vendor to select their trust store, and It Just Works. Can=E2=80=99t find someone who does what you want? That=E2=80=99s not a pro= blem: you can do it yourself. In discussing the second problem, there is absolutely zero reason to use anything existing. None whatsoever. It=E2=80=99s completely unreasonable to be complaining =E2=80=9CCA X won=E2= =80=99t let me use certificates for this purpose=E2=80=9D if you=E2=80=99re not addressing tha= t with CA X. And it=E2=80=99s completely unreasonable to complain that Root stores intended = for use case Y cannot be used with use case Z. Hammers make lousy screwdrivers, even if they are both =E2=80=9Ctools one uses when building furniture=E2=80= =9D > Want id-kp-eapOverLan? Sure, plenty will happily do that for you, for a > price. Don=E2=80=99t like the price? Run your own CA and issue them yours= elf. > There=E2=80=99s zero cost, and plenty of open-source tools to make =E2=80= =9Crun your own > CA=E2=80=9D be a single line on a command-shell. > > Windows actually *forbids* id-kp-eapOverLAN from being used by the > well-known root CAs: > > > https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows= -server-2012-r2-and-2012/jj200219(v%3Dws.11) > > ... > You must deploy a private CA rather than obtain server certificates from = a > third party public CA. In addition, the certificate template that you use > to issue the certificates must contain the RADIUS EKU extension. This > extension is id-kp-eapOverLAN and the object identifier (OID) for this EK= U > is 1.3.6.1.5.5.7.3.14. This EKU extension can only be configured on a > private CA and is used by Windows 8 to determine whether a private CA > issued the certificate. > ... > > This use-case would also seem to be outside of the scope envisioned by > RFC 4334, which applies to client certificates. Fantastic! That=E2=80=99s exactly what I=E2=80=99m saying more folks should= do for the =E2=80=9Ccurrent=E2=80=9D. That=E2=80=99s a feature, not a bug. --000000000000106385059c7080e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jan 18, 2020 at 2:23 PM Alan DeKok <aland@deployingradius.com> wrote:
>=C2=A0 =C2=A0Where can I get a certificate with id-kp-eapOverLAN?=C2=A0= Or where can I get a cert designed for use with STMP, XMPP, etc.?
>
> https://wiki.xmpp.org/web/XMPP_Server_Certifi= cates
> https://xmpp.org= /about/xsf/records/proposals/intermediate-certificate-authority

=C2=A0 XMPP.=C2=A0 Not id-kp-eapOverLAN.=C2=A0 And not SMTP, not RADIUS ove= r TLS=C2=A0 Not DNS over TLS, and so on.

=
You=E2=80=99re conflating several things, as well a= s seemingly shifting the goal posts here. Perhaps it=E2=80=99s just a poor = expression of the problem, as you see it, in which case, it might help to b= e clearer.

_Some_ CAs fo= rbid their certificates from being used with web servers.

_Some_ CAs forbid their certificates from= being used with SMTP, or DNS over TLS, or XMPP.
If those CAs certificates are used for those purpo= ses, they need to be revoked if the CA obtains evidence of this.

If the CA doesn=E2=80=99t like tha= t, they can change their policies - although in many cases, how they=E2=80= =99ve forbidden things do not retroactively permit it.

If the Subscriber doesn=E2=80=99t like this,= they can choose another CA.

If the software developer doesn=E2=80=99t like this, they can trust di= fferent CAs.

Can=E2=80= =99t get eapOverLan from a TLS CA? Ok. That=E2=80=99s not a bug, that=E2=80= =99s not a misdesign, that=E2=80=99s how it works and is supposed to work.<= /div>

The CA you=E2=80=99d lik= e to use has a policy that forbids using your certificates that way? Find a= different CA. Run your own internal CA. These aren=E2=80=99t difficult or = unreasonable things.

> This is the problem with ignoring the broader message. =E2=80=9CThe CA= s=E2=80=9D is a term without useful meaning. Everyone can be a CA. You can = be a CA. I can be a CA. Anyone who wants can issue certificates. There=E2= =80=99s no set of entities blessed in some special power which only they ca= n mint certificates, and thus their choices not to do so somehow be a sign = of neglect.

=C2=A0 That is mostly true, but unhelpful.=C2=A0 Windows doesn't ship w= ith "Billy bob's tackle shop & CA" root certificates.=C2= =A0 Neither does Linux, OSX, etc.=C2=A0 Your statement here is just a rephr= asing of "use a private CA", and "manually configure things&= quot;.

Yes, exact= ly, which is why I=E2=80=99m not sure the objection.

This is why I tried to cleanly separate out th= e problems, which seem to keep getting conflated. The problem of =E2=80=9Cw= hat does it mean today=E2=80=9D and =E2=80=9Cwhat does it mean in a future = where nothing has to be manually configured=E2=80=9D are different problems= , and it=E2=80=99s unreasonable to keep demanding that the second be solved= when addressing the first.

=C2=A0 The root CAs that ship on modern OS distributions *are* blessed with= a special power.=C2=A0 Only they can mint certificates which are *automati= cally* trusted by most applications on the OS.

For certain purposes, according to certain po= licies.

If you don=E2=80= =99t like those policies, or you want more purposes, do your own thing. The= same modern OS distributions provide that capability for applications to d= o so, to allow the application vendor to select their trust store, and It J= ust Works.

Can=E2=80=99t= find someone who does what you want? That=E2=80=99s not a problem: you can= do it yourself. In discussing the second problem, there is absolutely zero= reason to use anything existing. None whatsoever.
<= br>
It=E2=80=99s completely unreasonable to be compl= aining =E2=80=9CCA X won=E2=80=99t let me use certificates for this purpose= =E2=80=9D if you=E2=80=99re not addressing that with CA X. And it=E2=80=99s= completely unreasonable to complain that Root stores intended for use case= Y cannot be used with use case Z. Hammers make lousy screwdrivers, even if= they are both =E2=80=9Ctools one uses when building furniture=E2=80=9D

> Want id-kp-eapOverLan? Sure, plenty will happily do that for you, for = a price. Don=E2=80=99t like the price? Run your own CA and issue them yours= elf. There=E2=80=99s zero cost, and plenty of open-source tools to make =E2= =80=9Crun your own CA=E2=80=9D be a single line on a command-shell.

=C2=A0 Windows actually *forbids* id-kp-eapOverLAN from being used by the w= ell-known root CAs:

https://docs.microsoft.com/en-us/previous-versions/windows= /it-pro/windows-server-2012-r2-and-2012/jj200219(v%3Dws.11)

...
You must deploy a private CA rather than obtain server certificates from a = third party public CA. In addition, the certificate template that you use t= o issue the certificates must contain the RADIUS EKU extension. This extens= ion is id-kp-eapOverLAN and the object identifier (OID) for this EKU is 1.3= .6.1.5.5.7.3.14. This EKU extension can only be configured on a private CA = and is used by Windows 8 to determine whether a private CA issued the certi= ficate.
...

=C2=A0 This use-case would also seem to be outside of the scope envisioned = by RFC 4334, which applies to client certificates.

Fantastic! That=E2=80=99s exactly what I= =E2=80=99m saying more folks should do for the =E2=80=9Ccurrent=E2=80=9D. T= hat=E2=80=99s a feature, not a bug.
--000000000000106385059c7080e5-- From nobody Sat Jan 18 14:58:17 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531C1120168; Sat, 18 Jan 2020 14:58:09 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ks9mX1IGfSFr; Sat, 18 Jan 2020 14:58:06 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1AF120130; Sat, 18 Jan 2020 14:58:06 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id E5E6164E; Sat, 18 Jan 2020 22:58:03 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Sat, 18 Jan 2020 17:58:02 -0500 Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 22:58:16 -0000 On Jan 18, 2020, at 4:11 PM, Ryan Sleevi wrote: >=20 > You=E2=80=99re conflating several things, as well as seemingly = shifting the goal posts here. Perhaps it=E2=80=99s just a poor = expression of the problem, as you see it, in which case, it might help = to be clearer. I'm trying to solve the problem of bootstrapping. I agree that = various CAs have various rules. I agree that anyone can run their own = private CA, and do whatever they want. I've been doing that, and = recommending it, for ~20 years. > Can=E2=80=99t get eapOverLan from a TLS CA? Ok. That=E2=80=99s not a = bug, that=E2=80=99s not a misdesign, that=E2=80=99s how it works and is = supposed to work. Where you say "TLS CA", you mean "WWW CA". All these other = applications use TLS, too. In practice, that WWW CA design translates into "CAs which are = included with OS distributions". Which means "CA trivially usable by = applications". ALL applications. Not just the browser. Is it any surprise that *all* applications ended up leveraging that = functionality? When the CA *isn't* included with the OS distribution, it means that = CA *cannot* be used to bootstrap TLS-enabled applications. Each = application (not just EAP) MUST be manually configured with the CA. The alternative is to ask the application to naively trust a CA it = doesn't know, and a CA which isn't included with the OS distribution. I = don't think that will happen. It's easy for a browser vendor to tell a CA "issue certs our customers = can use". It's much, much, harder for anyone else to do the same thing. > > That is mostly true, but unhelpful. Windows doesn't ship with = "Billy bob's tackle shop & CA" root certificates. Neither does Linux, = OSX, etc. Your statement here is just a rephrasing of "use a private = CA", and "manually configure things". >=20 > Yes, exactly, which is why I=E2=80=99m not sure the objection. It's less of an objection than a statement that we're back to the = initial conclusion: use a private CA, manually configure, and ignore the = root CAs shipped with the OS distribution. How does that help with the bootstrapping problem? > If you don=E2=80=99t like those policies, or you want more purposes, = do your own thing. The same modern OS distributions provide that = capability for applications to do so, to allow the application vendor to = select their trust store, and It Just Works. >=20 > Can=E2=80=99t find someone who does what you want? That=E2=80=99s not = a problem: you can do it yourself. In discussing the second problem, = there is absolutely zero reason to use anything existing. None = whatsoever. I'm happy to use a new PKI. But we *cannot* and *must not* rely on = every application to "do it yourself". There must be a trust anchor = shipped with OS distributions, that applications can leverage. > It=E2=80=99s completely unreasonable to be complaining =E2=80=9CCA X = won=E2=80=99t let me use certificates for this purpose=E2=80=9D if = you=E2=80=99re not addressing that with CA X. And it=E2=80=99s = completely unreasonable to complain that Root stores intended for use = case Y cannot be used with use case Z. Hammers make lousy screwdrivers, = even if they are both =E2=80=9Ctools one uses when building furniture=E2=80= =9D Sure. So how does *my* application get Microsoft, Apple, etc. to ship = a new PKI? Answer: even Microsoft and Apple can't do it for their own = applications. They just leverage the pre-existing WWW PKI. If trillion dollar companies can't deploy a new PKI for their own = applications, it's entirely unreasonable to ask that of a minor cog like = me. Alan DeKok. From nobody Sat Jan 18 15:30:28 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31962120043; Sat, 18 Jan 2020 15:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 3a_H5Cmt9vc7; Sat, 18 Jan 2020 15:30:24 -0800 (PST) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A3A120025; Sat, 18 Jan 2020 15:30:24 -0800 (PST) Received: by mail-ed1-f53.google.com with SMTP id i16so25984096edr.5; Sat, 18 Jan 2020 15:30:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jdosa3tNDntkTvxnwQehtYNgl3waojzh5COKi88WATM=; b=pNcIIUB7Ja9jdW/BLGFcljL5PI5IRiv5lDM4Lrmeav5kONrNYpGlovtaIT9/F/R2nn He3kk44EgRMfkAr7oL0fmraT/f2TI61JW2qIYv535eq+PW7UHx41+Jv/sJKzPZukABOp +L2ECcna4Azu1BEZl6Sy4ri76UC7ENltTu9zYPHkALdzPOlzZWFcRcz6xAZY1iM4o1cC R4awQf93bnZFjtfKZhuXmdjCS2kBlc5VBdWYwy1DFeNTZ4eXEe099fxiFUeMXA1QKCZn lg+FnfFg8DKclkaBWOx+9GtBf25XecrwY7cYWUcpXBF37NAUzAuVbD90gAImaHS1M6xq x9vg== X-Gm-Message-State: APjAAAVT/22c8E5iZzFvtafC3E6DPa50v298gyW+BkPFqCDjj9J5tPb+ fLJwGyxxdhx/PYhIfzLvpVfY1Ycb X-Google-Smtp-Source: APXvYqzO8B9QDt6MTZiPsyOFX1PyHuZLxndKcn067XHcieVGIQVgCrWWgW4lKEHzn/UXJUGolOEiMw== X-Received: by 2002:aa7:d4d2:: with SMTP id t18mr10725920edr.223.1579390222699; Sat, 18 Jan 2020 15:30:22 -0800 (PST) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com. [209.85.128.51]) by smtp.gmail.com with ESMTPSA id va15sm935970ejb.18.2020.01.18.15.30.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jan 2020 15:30:22 -0800 (PST) Received: by mail-wm1-f51.google.com with SMTP id 20so11116608wmj.4; Sat, 18 Jan 2020 15:30:21 -0800 (PST) X-Received: by 2002:a1c:ddd7:: with SMTP id u206mr12133465wmg.159.1579390221578; Sat, 18 Jan 2020 15:30:21 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> In-Reply-To: <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> From: Ryan Sleevi Date: Sat, 18 Jan 2020 18:30:10 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001e7923059c7271ec" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 23:30:26 -0000 --0000000000001e7923059c7271ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jan 18, 2020 at 5:58 PM Alan DeKok wrote: > I'm trying to solve the problem of bootstrapping. I agree that various > CAs have various rules. I agree that anyone can run their own private CA= , > and do whatever they want. I've been doing that, and recommending it, fo= r > ~20 years. Great. Let=E2=80=99s focus on one problem at a time to make sure it=E2=80= =99s easier to follow along. Earlier in the thread you seemed fixated on the first problem, so it=E2=80=99s unclear when/where/how shifted to the second. When the CA *isn't* included with the OS distribution, it means that CA > *cannot* be used to bootstrap TLS-enabled applications. Each application > (not just EAP) MUST be manually configured with the CA. This isn=E2=80=99t true, if you mean that the end user needs to manually co= nfigure. Modern OSes allow the application vendor - such as the supplicant vendor - to explicitly configure. The alternative is to ask the application to naively trust a CA it > doesn't know, and a CA which isn't included with the OS distribution. I > don't think that will happen. The alternative is the application ships it=E2=80=99s own root store. Which applications have been doing for 20+ years and which modern OSes make even easier. It's easy for a browser vendor to tell a CA "issue certs our customers > can use". It's much, much, harder for anyone else to do the same thing. Not really? CAs are plenty happy to sell whatever folks want. Look at stuff like the drone PKI being developed. What other application developers can=E2=80=99t do - and this is intentiona= l - is to get their certs and profiles for the same roots, even if they=E2=80=99re= the same issuing organization. It's less of an objection than a statement that we're back to the initial > conclusion: use a private CA, manually configure, and ignore the root CAs > shipped with the OS distribution. > > How does that help with the bootstrapping problem? I already gave that answer several times. Define your profile and policies, pick (different) roots, and ship them in your software. It=E2=80=99s mistak= en to suggest that you HAVE to use the same roots as the OS. I'm happy to use a new PKI. But we *cannot* and *must not* rely on every > application to "do it yourself". There must be a trust anchor shipped wi= th > OS distributions, that applications can leverage. No, there doesn=E2=80=99t. That=E2=80=99s an unreasonable demand, because i= t=E2=80=99s insisting that advocates of the problem don=E2=80=99t want to actually do the work in= volved in developing a solution for the problem. There=E2=80=99s absolutely no rea= son to require that it be shipped as part of the OS. Plenty of PKIs exist without requiring that, and modern OSes make it easier. Now, it may be that OSes do this, in the future, but that only happens by first building the profile and policies. Because that=E2=80=99s all an OS r= oot store is: a set of CAs known to meet particular profiles and policies. Anyone can define that. > It=E2=80=99s completely unreasonable to be complaining =E2=80=9CCA X won= =E2=80=99t let me use > certificates for this purpose=E2=80=9D if you=E2=80=99re not addressing t= hat with CA X. And > it=E2=80=99s completely unreasonable to complain that Root stores intende= d for use > case Y cannot be used with use case Z. Hammers make lousy screwdrivers, > even if they are both =E2=80=9Ctools one uses when building furniture=E2= =80=9D > > Sure. So how does *my* application get Microsoft, Apple, etc. to ship = a > new PKI? Provide a problem statement and a solution that=E2=80=99s compelling enough= for them to use? Fixating on the =E2=80=9Cnew PKI=E2=80=9D or =E2=80=9Cmust be = shipped in the OS=E2=80=9D is completely unreasonable expectation, especially when even the _existing_ PKI doesn=E2=80=99t solve the bootstrap problem unless you convince the OS.= There=E2=80=99s zero advantages to using extant PKI, and ample downside, and you can move quicker and ship things by just doing the work. --0000000000001e7923059c7271ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jan 18, 2020 at 5:58 PM Alan DeKok <aland@deployingradius.com> wrote:
=C2=A0 I'm trying to solve the problem of bootstrapping.=C2=A0 I agree = that various CAs have various rules.=C2=A0 I agree that anyone can run thei= r own private CA, and do whatever they want.=C2=A0 I've been doing that= , and recommending it, for ~20 years.

Great. Let=E2=80=99s focus on one problem at a time to= make sure it=E2=80=99s easier to follow along. Earlier in the thread you s= eemed fixated on the first problem, so it=E2=80=99s unclear when/where/how = shifted to the second.

=C2=A0 When the CA *isn't* included with the OS distribution, it means = that CA *cannot* be used to bootstrap TLS-enabled applications.=C2=A0 Each = application (not just EAP) MUST be manually configured with the CA.

This isn=E2=80=99t true,= if you mean that the end user needs to manually configure. Modern OSes all= ow the application vendor - such as the supplicant vendor - to explicitly c= onfigure.

=C2=A0 The alternative is to ask the application to naively trust a CA it d= oesn't know, and a CA which isn't included with the OS distribution= .=C2=A0 I don't think that will happen.
<= br>
The alternative is the application ships it=E2= =80=99s own root store. Which applications have been doing for 20+ years an= d which modern OSes make even easier.

=C2=A0 It's easy for a browser vendor to tell a CA "issue certs ou= r customers can use".=C2=A0 It's much, much, harder for anyone els= e to do the same thing.

Not really? CAs are plenty happy to sell whatever folks want. Look a= t stuff like the drone PKI being developed.

What other application developers can=E2=80=99t do - an= d this is intentional - is to get their certs and profiles for the same roo= ts, even if they=E2=80=99re the same issuing organization.

=C2=A0 It's less of an = objection than a statement that we're back to the initial conclusion: u= se a private CA, manually configure, and ignore the root CAs shipped with t= he OS distribution.

=C2=A0 How does that help with the bootstrapping problem?

I already gave that answer several= times. Define your profile and policies, pick (different) roots, and ship = them in your software. It=E2=80=99s mistaken to suggest that you HAVE to us= e the same roots as the OS.

=C2=A0 I'm happy to use a new PKI.=C2=A0 But we *canno= t* and *must not* rely on every application to "do it yourself".= =C2=A0 There must be a trust anchor shipped with OS distributions, that app= lications can leverage.

No, there doesn=E2=80=99t. That=E2=80=99s an unreasonable demand, be= cause it=E2=80=99s insisting that advocates of the problem don=E2=80=99t wa= nt to actually do the work involved in developing a solution for the proble= m. There=E2=80=99s absolutely no reason to require that it be shipped as pa= rt of the OS. Plenty of PKIs exist without requiring that, and modern OSes = make it easier.

Now, it = may be that OSes do this, in the future, but that only happens by first bui= lding the profile and policies. Because that=E2=80=99s all an OS root store= is: a set of CAs known to meet particular profiles and policies. Anyone ca= n define that.

> It=E2=80=99s completely unreasonable to be complaining =E2=80=9CCA X w= on=E2=80=99t let me use certificates for this purpose=E2=80=9D if you=E2=80= =99re not addressing that with CA X. And it=E2=80=99s completely unreasonab= le to complain that Root stores intended for use case Y cannot be used with= use case Z. Hammers make lousy screwdrivers, even if they are both =E2=80= =9Ctools one uses when building furniture=E2=80=9D

=C2=A0 Sure.=C2=A0 So how does *my* application get Microsoft, Apple, etc. = to ship a new PKI?

Provide a problem statement and a solution that=E2=80=99s compelling enou= gh for them to use? Fixating on the =E2=80=9Cnew PKI=E2=80=9D or =E2=80=9Cm= ust be shipped in the OS=E2=80=9D is completely unreasonable expectation, e= specially when even the _existing_ PKI doesn=E2=80=99t solve the bootstrap = problem unless you convince the OS. There=E2=80=99s zero advantages to usin= g extant PKI, and ample downside, and you can move quicker and ship things = by just doing the work.

--0000000000001e7923059c7271ec-- From nobody Sun Jan 19 07:07:46 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF3E12006B; Sun, 19 Jan 2020 07:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6DfsaEkIy-uV; Sun, 19 Jan 2020 07:07:37 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A425120044; Sun, 19 Jan 2020 07:07:36 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 93C5A5F8; Sun, 19 Jan 2020 15:07:33 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Sun, 19 Jan 2020 10:07:31 -0500 Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 15:07:40 -0000 On Jan 18, 2020, at 6:30 PM, Ryan Sleevi wrote: > Great. Let=E2=80=99s focus on one problem at a time to make sure = it=E2=80=99s easier to follow along. Earlier in the thread you seemed = fixated on the first problem, so it=E2=80=99s unclear when/where/how = shifted to the second. Perhaps less "fixated" than "trying to achieve a common understanding. It's best to understand the current situation before designing any = solution. > The alternative is the application ships it=E2=80=99s own root store. = Which applications have been doing for 20+ years and which modern OSes = make even easier. The question here is *what* root store? It's easy for browsers to = ship root stores. The WWW root stores are well known.=20 What root store is already widely known, and trusted for EAP? > Not really? CAs are plenty happy to sell whatever folks want. Look at = stuff like the drone PKI being developed. CAs are in *theory* happy to sell things. In practice, it's difficult = to get non-WWW certificates. > I already gave that answer several times. Define your profile and = policies, pick (different) roots, and ship them in your software. It=E2=80= =99s mistaken to suggest that you HAVE to use the same roots as the OS. I think you're operating from a WWW perspective. That use-case is = very different from EAP. In WWW, 99% of the TLS-enabled traffic is from = the server to the client. The client doesn't know what the information = is, and doesn't really care. Even secret information like passwords = sent to a web server are generated by / on that web server. So a client = can verify (a) the password was created for a proven server using a = trusted CA, and next time (b) prove it's the same server, so it's OK to = send over the password. EAP is completely different. I have *my* password. It's secret, and = I made it. I want to be sure that I give it *only* to the site which is = authorized. This means that I don't really care that a root CA is = trusted. That root CA might sign certificates for 1000 companies. I = want to have my password only to one company; the correct one. I want = the client supplicant to *not* hand my password to the other ones. I = have no DNS to leverage, either. To put it another way, in WWW, the server has data that the client = wants. In EAP, the client has data (passwords) that the server wants. = The trust models are very different. The goal then is to get to the point where a supplicant can verify = that the server cert is signed by a trusted CA, *and* that it's the = server cert that the client wants. Shipping a trusted root CA on the supplicant OS is the *only* way to = do this. > No, there doesn=E2=80=99t. That=E2=80=99s an unreasonable demand, = because it=E2=80=99s insisting that advocates of the problem don=E2=80=99t= want to actually do the work involved in developing a solution for the = problem. There=E2=80=99s absolutely no reason to require that it be = shipped as part of the OS. Plenty of PKIs exist without requiring that, = and modern OSes make it easier. See above. This isn't just "ship a root CA with an EAP / RADIUS server". That's = a trivial problem to solve. If you want to use a RADIUS server, it may = be OK to trust the CAs included with that product. The same goes for = browsers. But what are the poor end users going to do with their EAP = supplicants? Pretty much *zero* of them have ever downloaded a = supplicant "application". So that route is completely off of the table. Instead the supplicant is shipped with the OS. Therefore, any root CAs = needed by the supplicant MUST be included with the OS. It really is that simple. In conclusion, we need a new PKI, and the root CAs must be included = with OS distributions. But the OS vendors won't do that until we define = the requirements, solution, and transition path. Alan DeKok. From nobody Sun Jan 19 08:22:20 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D741200D5; Sun, 19 Jan 2020 08:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 AHyuTqDpFdDV; Sun, 19 Jan 2020 08:22:01 -0800 (PST) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3CA120013; Sun, 19 Jan 2020 08:22:00 -0800 (PST) Received: by mail-ed1-f43.google.com with SMTP id m8so27156051edi.13; Sun, 19 Jan 2020 08:22:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UtpS7eZBoVG3V5c/Iv5wJzEk/MlTXY3XJNqbjQPfqkQ=; b=iDIoxeemtWOyL/mxCbJBzfm6J5Yo/3hGFG2f6mMI17HbmWw7xmc5iuTg5AVaaltWiJ ZSxWSTTgoXteKxNJVoSVLtoyBcP90lutKIspkEMEp0HAPlGGNSmVvrUrbtbE3QMtlG1D 2um+1hWQ5awn8y6rjiF+g2ESIjjH85Z2cSeoUKeFeOWltpvK9TZ8fbH269O6AUYManlr WtEqG8XcBBOJTQw9ifKMoCoS5OeAtmTXvsqJ9S7HyFQ/3D2x9awtauDKaVx5R4YqBJzw uyBJmqb6QC0N+fOINUowsMgNa8EGPcW1j05a5+0YXIBKOmTeGU3mF+R+SehR72zkJD+b F2bw== X-Gm-Message-State: APjAAAWCwBHbKguHJhV8RBNkbsr4XibzeqtX+VJIUQbrE1Z/sihhJYs3 o5ylGvgzytWdnIGZGTbft0Zb6iFe X-Google-Smtp-Source: APXvYqyt5EEn/VJ4smd5m2LopgjEljf7o/R+2UuGZTY8R0AmF8q2bqghZQAmq7xcjQtn0b8MX5YXLw== X-Received: by 2002:a05:6402:3132:: with SMTP id dd18mr13926153edb.118.1579450918673; Sun, 19 Jan 2020 08:21:58 -0800 (PST) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com. [209.85.128.42]) by smtp.gmail.com with ESMTPSA id l26sm965624ejr.23.2020.01.19.08.21.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jan 2020 08:21:58 -0800 (PST) Received: by mail-wm1-f42.google.com with SMTP id p17so12298531wma.1; Sun, 19 Jan 2020 08:21:58 -0800 (PST) X-Received: by 2002:a7b:c775:: with SMTP id x21mr14855641wmk.59.1579450917841; Sun, 19 Jan 2020 08:21:57 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> In-Reply-To: <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> From: Ryan Sleevi Date: Sun, 19 Jan 2020 10:54:35 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e5efd6059c809206" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 16:22:03 -0000 --000000000000e5efd6059c809206 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we=E2=80=99re in more agreement than disagreement here, but I think= part of your analysis missed the mark. On Sun, Jan 19, 2020 at 10:07 AM Alan DeKok wrote: > The question here is *what* root store? It's easy for browsers to ship > root stores. The WWW root stores are well known. > > What root store is already widely known, and trusted for EAP? There isn=E2=80=99t one today, which is exactly why you have no need to use anything existing. You define your certificate profile. You define your certificate policies - what information they validate and how they validate. The root store is the result of defining those two, and then allowing CAs interested in that set to apply and be evaluated against that. There=E2=80= =99s nothing extant, as we=E2=80=99ve agreed multiple times, because everyone ma= nually configures. There=E2=80=99s zero need to use any existing CAs. If the concern is =E2=80= =9COur root store is initially empty=E2=80=9D, well then yes, it matches the status quo= today: there is no root store. Rome wasn=E2=80=99t built in a day, and figuring ou= t who should be in that store takes time. There=E2=80=99s no doubt a dozen CAs th= at would happily issue, if they knew what the expected profile and policies were, and would stand up dedicated roots. Of course, the CAs are only going to do that if there are users: those who will buy or rely on those certificates. So you need to convince supplicants that a zero-touch world is worth it, AND that it can be as secure as manual configuration. Supplicant vendors - whether they are open-source or operating system - are taking on the work to manage and police that root store. To ensure that the CAs included follow the profiles, policies, and practices. So you have to convince them that it=E2=80=99s worthwhile for their users. If this sounds like a lot of work: Yes. It is. Yet organizations like the WiFi Alliance or the Wireless Power Consortium or the USB-IF have all managed to do so, to varying degrees of success. I think you're operating from a WWW perspective. That use-case is very > different from EAP. In WWW, 99% of the TLS-enabled traffic is from the > server to the client. The client doesn't know what the information is, a= nd > doesn't really care. Even secret information like passwords sent to a we= b > server are generated by / on that web server. So a client can verify (a) > the password was created for a proven server using a trusted CA, and next > time (b) prove it's the same server, so it's OK to send over the password= . > > EAP is completely different. I have *my* password. It's secret, and I > made it. I want to be sure that I give it *only* to the site which is > authorized. This means that I don't really care that a root CA is > trusted. That root CA might sign certificates for 1000 companies. I wan= t > to have my password only to one company; the correct one. I want the > client supplicant to *not* hand my password to the other ones. I have no > DNS to leverage, either. > > To put it another way, in WWW, the server has data that the client > wants. In EAP, the client has data (passwords) that the server wants. T= he > trust models are very different. They are not at all different. In both cases, the client has a principal it wants to validate: in RFC 6125, this is the reference name. This is the name in your credential in the case of EAP, the name of the host in the URL in WWW. The client wants to make sure it=E2=80=99s talking to the entity au= thorized for that name. You can manually preconfigured exactly that entity. In EAP, this is incredibly easy to do when you=E2=80=99re provisioning the client credentia= l to also provision the peer identity. This is the existing flow. The long-term goal seems to be to want to indirect that, so that explicitly provisioning credentials is not necessary. In that model, you need a third-party, the CA, to vet and validate the identity, so your EAP server can attest it. Rather than having to rely on a preconfigured identity, you want to make sure the reference name matches the names presented in the certificate. The trust model is _identical_ to WWW, as you describe it. If the argument is that the only information that needs validation is a DNS name, and that it=E2=80=99s profile is similar to, or could be identical to= , TLS, then you still have the burden of demonstrating the operational considerations are the same before you make the case to reuse the existing. For example, the payment terminal example I mentioned used the same policies and profiles, but the operational consideration was these devices are not field upgradable and only support certificates from a limited number of CAs. The lack of updates and the lack of agility were an insurmountable gulf of difference from the constraints of operating systems (patches) and browsers (regular updates), and so these devices need separate PKIs, which ANSI X-9 is happy to oblige: https://x9.org/asc-x9-launches-new-security-study-groups-on-public-key-infr= astructure-pki-and-transport-layer-security-tls/ If this future world is a world where the provisioning of certificates is only done via ACME, and manual configuration is =E2=80=9Cunsupported=E2=80= =9D (even if technically capable, it=E2=80=99s in the =E2=80=9Cmay break you at any time= if you decide to do this=E2=80=9D level of support), and your profiles are explicitly sho= rt-lives to help ensure this, then yes, it=E2=80=99s reasonable to talk about overla= p. > Shipping a trusted root CA on the supplicant OS is the *only* way to do > this. This is not true. Shipping the trusted root CA list in the supplicant _software_ totally works. Conflating the supplicant with the OS is continuing to muddy the waters. Instead the supplicant is shipped with the OS. Therefore, any root CAs > needed by the supplicant MUST be included with the OS. > > It really is that simple. This may seem like splitting hairs, but it=E2=80=99s a _profound_ distincti= on if you=E2=80=99ve ever managed PKIs on operating systems, as this is not true. Shipping a CA list in the supplicant shipped in the OS !=3D shipping a CA list in the OS. They are very different models of managing and configuring that should not be conflated. Android has plenty of OS components that ship their own root stores, separate from the root store it provides as part of its public API contract. We only need the former, not the latter. It sounds like this has circled back into =E2=80=9CHow do we get Apple/Microsoft/Google/whomever to have their supplicants trust a set of CAs by default=E2=80=9D, and the steps outlined above continue to be it. Fo= r Google/Android/ChromeOS, I=E2=80=99m not going to want to conflate the TLS = PKI and the EAP PKI if they have different operational considerations (e.g. the ease of replacement of certs and the ability to respond to CA incidents), different profile considerations (the information being attested), and different policy considerations (how that information is validated). The advocates of such a solution need to do the work in defining the profiles and policies and presenting that as the use case for why. To the OS vendor, managing these profiles and policies is a non-trivial undertaking involving a host of folks: Legal (for contracts and CP/CPS review), Engineering, Project/Program Management (it=E2=80=99s a lot of wor= k to review several thousand CAs a year, let alone the 60-70 organizations in the root store), Release Management, etc. There has to be a value proposition here, because the convenient part of the much maligned manual configuration is that it outsourced all the risk the OS vendor might be taking on, and instead allows it to be the customer=E2=80=99s problem. That= may seem unfair and non-ideal, but that=E2=80=99s where the risk/value calculus= is right now, and to get vendors to change, you need to present a compelling value case that demonstrably minimizes risk. Trust is hard and expensive = =F0=9F=A4=B7 In conclusion, we need a new PKI, and the root CAs must be included with > OS distributions. But the OS vendors won't do that until we define the > requirements, solution, and transition path. The transition path has been repeatedly defined, so that=E2=80=99s 1/3 of t= he way there =F0=9F=91=8D --000000000000e5efd6059c809206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we=E2=80=99re in more agreement than disagre= ement here, but I think part of your analysis missed the mark.
<= div>
On= Sun, Jan 19, 2020 at 10:07 AM Alan DeKok <aland@deployingradius.com> wrote:
=C2=A0 The question here is *what* root store?=C2=A0 It's easy for brow= sers to ship root stores.=C2=A0 The WWW root stores are well known.

=C2=A0 What root store is already widely known, and trusted for EAP?

There isn=E2=80=99t one= today, which is exactly why you have no need to use anything existing.

You define your certificate= profile.
You define your certificate policies - wha= t information they validate and how they validate.
<= br>
The root store is the result of defining those t= wo, and then allowing CAs interested in that set to apply and be evaluated = against that. There=E2=80=99s nothing extant, as we=E2=80=99ve agreed multi= ple times, because everyone manually configures.
There=E2=80=99s zero need to use any existing CAs.= If the concern is =E2=80=9COur root store is initially empty=E2=80=9D, wel= l then yes, it matches the status quo today: there is no root store. Rome w= asn=E2=80=99t built in a day, and figuring out who should be in that store = takes time. There=E2=80=99s no doubt a dozen CAs that would happily issue, = if they knew what the expected profile and policies were, and would stand u= p dedicated roots.

Of co= urse, the CAs are only going to do that if there are users: those who will = buy or rely on those certificates. So you need to convince supplicants that= a zero-touch world is worth it, AND that it can be as secure as manual con= figuration.

Supplicant v= endors - whether they are open-source or operating system - are taking on t= he work to manage and police that root store. To ensure that the CAs includ= ed follow the profiles, policies, and practices. So you have to convince th= em that it=E2=80=99s worthwhile for their users.
If this sounds like a lot of work: Yes. It is. Yet= organizations like the WiFi Alliance or the Wireless Power Consortium or t= he USB-IF have all managed to do so, to varying degrees of success.

=C2=A0 I think you're operat= ing from a WWW perspective.=C2=A0 That use-case is very different from EAP.= =C2=A0 In WWW, 99% of the TLS-enabled traffic is from the server to the cli= ent.=C2=A0 The client doesn't know what the information is, and doesn&#= 39;t really care.=C2=A0 Even secret information like passwords sent to a we= b server are generated by / on that web server.=C2=A0 So a client can verif= y (a) the password was created for a proven server using a trusted CA, and = next time (b) prove it's the same server, so it's OK to send over t= he password.

=C2=A0 EAP is completely different.=C2=A0 I have *my* password.=C2=A0 It= 9;s secret, and I made it.=C2=A0 I want to be sure that I give it *only* to= the site which is authorized.=C2=A0 This means that I don't really car= e that a root CA is trusted.=C2=A0 That root CA might sign certificates for= 1000 companies.=C2=A0 I want to have my password only to one company; the = correct one.=C2=A0 I want the client supplicant to *not* hand my password t= o the other ones.=C2=A0 I have no DNS to leverage, either.

=C2=A0 To put it another way, in WWW, the server has data that the client w= ants.=C2=A0 In EAP, the client has data (passwords) that the server wants.= =C2=A0 The trust models are very different.
<= br>
They are not at all different. In both cases, th= e client has a principal it wants to validate: in RFC 6125, this is the ref= erence name. This is the name in your credential in the case of EAP, the na= me of the host in the URL in WWW. The client wants to make sure it=E2=80=99= s talking to the entity authorized for that name.
You can manually preconfigured exactly that entit= y. In EAP, this is incredibly easy to do when you=E2=80=99re provisioning t= he client credential to also provision the peer identity. This is the exist= ing flow.

The long-term = goal seems to be to want to indirect that, so that explicitly provisioning = credentials is not necessary. In that model, you need a third-party, the CA= , to vet and validate the identity, so your EAP server can attest it. Rathe= r than having to rely on a preconfigured identity, you want to make sure th= e reference name matches the names presented in the certificate.

The trust model is _identical_ to = WWW, as you describe it.

If the argument is that the only information that needs validation is a DN= S name, and that it=E2=80=99s profile is similar to, or could be identical = to, TLS, then you still have the burden of demonstrating the operational co= nsiderations are the same before you make the case to reuse the existing. F= or example, the payment terminal example I mentioned used the same policies= and profiles, but the operational consideration was these devices are not = field upgradable and only support certificates from a limited number of CAs= . The lack of updates and the lack of agility were an insurmountable gulf o= f difference from the constraints of operating systems (patches) and browse= rs (regular updates), and so these devices need separate PKIs, which ANSI X= -9 is happy to oblige:=C2=A0
https://x9.org/asc-x9-launches-new-security-study-groups= -on-public-key-infrastructure-pki-and-transport-layer-security-tls/

If this future world is a w= orld where the provisioning of certificates is only done via ACME, and manu= al configuration is =E2=80=9Cunsupported=E2=80=9D (even if technically capa= ble, it=E2=80=99s in the =E2=80=9Cmay break you at any time if you decide t= o do this=E2=80=9D level of support), and your profiles are explicitly shor= t-lives to help ensure this, then yes, it=E2=80=99s reasonable to talk abou= t overlap.


=C2=A0 Shipping a trusted root CA on the supplicant OS is the *only* way to= do this.

This is= not true.

Shipping the = trusted root CA list in the supplicant _software_ totally works. Conflating= the supplicant with the OS is continuing to muddy the waters.

=C2=A0 Instead the supplicant is shipped with the OS. Therefore, any root C= As needed by the supplicant MUST be included with the OS.

=C2=A0 It really is that simple.

This may seem like splitting hairs, but it=E2=80=99s a _pro= found_ distinction if you=E2=80=99ve ever managed PKIs on operating systems= , as this is not true. Shipping a CA list in the supplicant shipped in the = OS !=3D shipping a CA list in the OS. They are very different models of man= aging and configuring that should not be conflated. Android has plenty of O= S components that ship their own root stores, separate from the root store = it provides as part of its public API contract. We only need the former, no= t the latter.

It sounds = like this has circled back into =E2=80=9CHow do we get Apple/Microsoft/Goog= le/whomever to have their supplicants trust a set of CAs by default=E2=80= =9D, and the steps outlined above continue to be it. For Google/Android/Chr= omeOS, I=E2=80=99m not going to want to conflate the TLS PKI and the EAP PK= I if they have different operational considerations (e.g. the ease of repla= cement of certs and the ability to respond to CA incidents), different prof= ile considerations (the information being attested), and different policy c= onsiderations (how that information is validated). The advocates of such a = solution need to do the work in defining the profiles and policies and pres= enting that as the use case for why.

To the OS vendor, managing these profiles and policies is a no= n-trivial undertaking involving a host of folks: Legal (for contracts and C= P/CPS review), Engineering, Project/Program Management (it=E2=80=99s a lot = of work to review several thousand CAs a year, let alone the 60-70 organiza= tions in the root store), Release Management, etc. There has to be a value = proposition here, because the convenient part of the much maligned manual c= onfiguration is that it outsourced all the risk the OS vendor might be taki= ng on, and instead allows it to be the customer=E2=80=99s problem. That may= seem unfair and non-ideal, but that=E2=80=99s where the risk/value calculu= s is right now, and to get vendors to change, you need to present a compell= ing value case that demonstrably minimizes risk. Trust is hard and expensiv= e =F0=9F=A4=B7

=C2=A0 In conclusion, we need a new PKI, and the root CAs must be included = with OS distributions.=C2=A0 But the OS vendors won't do that until we = define the requirements, solution, and transition path.

The transition path has been repeate= dly defined, so that=E2=80=99s 1/3 of the way there =F0=9F=91=8D
--000000000000e5efd6059c809206-- From nobody Sun Jan 19 08:26:50 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7CB12001A for ; Sun, 19 Jan 2020 08:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 gZEIHIjFwhfw for ; Sun, 19 Jan 2020 08:26:41 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C80120013 for ; Sun, 19 Jan 2020 08:26:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C3C4C300B46 for ; Sun, 19 Jan 2020 11:26:39 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mSpeXQ5auvht for ; Sun, 19 Jan 2020 11:26:36 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 6D1A33001CB; Sun, 19 Jan 2020 11:26:36 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> Date: Sun, 19 Jan 2020 11:26:36 -0500 Cc: Ryan Sleevi , EMU WG , "spasm@ietf.org" , Ben Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <666A5BF7-29A2-4CD3-97CB-DAD8B96EC040@vigilsec.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 16:26:45 -0000 It seems to me that RFC 4334 offers a way for an enterprise to assert = that the certificate is intended to be used with a particular SSID. = This seems better than a self-signed certificate with just a domain = name. I understand that CA/B Forum does not allow these extensions and = attributes, but as already highlighted in thi discussion, these = certificates are not part of the Web PKI. Russ > On Jan 19, 2020, at 10:07 AM, Alan DeKok = wrote: >=20 > On Jan 18, 2020, at 6:30 PM, Ryan Sleevi wrote: >> Great. Let=E2=80=99s focus on one problem at a time to make sure = it=E2=80=99s easier to follow along. Earlier in the thread you seemed = fixated on the first problem, so it=E2=80=99s unclear when/where/how = shifted to the second. >=20 > Perhaps less "fixated" than "trying to achieve a common = understanding. >=20 > It's best to understand the current situation before designing any = solution. >=20 >> The alternative is the application ships it=E2=80=99s own root store. = Which applications have been doing for 20+ years and which modern OSes = make even easier. >=20 > The question here is *what* root store? It's easy for browsers to = ship root stores. The WWW root stores are well known.=20 >=20 > What root store is already widely known, and trusted for EAP? >=20 >> Not really? CAs are plenty happy to sell whatever folks want. Look at = stuff like the drone PKI being developed. >=20 > CAs are in *theory* happy to sell things. In practice, it's = difficult to get non-WWW certificates. >=20 >> I already gave that answer several times. Define your profile and = policies, pick (different) roots, and ship them in your software. It=E2=80= =99s mistaken to suggest that you HAVE to use the same roots as the OS. >=20 > I think you're operating from a WWW perspective. That use-case is = very different from EAP. In WWW, 99% of the TLS-enabled traffic is from = the server to the client. The client doesn't know what the information = is, and doesn't really care. Even secret information like passwords = sent to a web server are generated by / on that web server. So a client = can verify (a) the password was created for a proven server using a = trusted CA, and next time (b) prove it's the same server, so it's OK to = send over the password. >=20 > EAP is completely different. I have *my* password. It's secret, and = I made it. I want to be sure that I give it *only* to the site which is = authorized. This means that I don't really care that a root CA is = trusted. That root CA might sign certificates for 1000 companies. I = want to have my password only to one company; the correct one. I want = the client supplicant to *not* hand my password to the other ones. I = have no DNS to leverage, either. >=20 > To put it another way, in WWW, the server has data that the client = wants. In EAP, the client has data (passwords) that the server wants. = The trust models are very different. >=20 > The goal then is to get to the point where a supplicant can verify = that the server cert is signed by a trusted CA, *and* that it's the = server cert that the client wants. >=20 > Shipping a trusted root CA on the supplicant OS is the *only* way to = do this. >=20 >> No, there doesn=E2=80=99t. That=E2=80=99s an unreasonable demand, = because it=E2=80=99s insisting that advocates of the problem don=E2=80=99t= want to actually do the work involved in developing a solution for the = problem. There=E2=80=99s absolutely no reason to require that it be = shipped as part of the OS. Plenty of PKIs exist without requiring that, = and modern OSes make it easier. >=20 > See above. >=20 > This isn't just "ship a root CA with an EAP / RADIUS server". That's = a trivial problem to solve. If you want to use a RADIUS server, it may = be OK to trust the CAs included with that product. The same goes for = browsers. >=20 > But what are the poor end users going to do with their EAP = supplicants? Pretty much *zero* of them have ever downloaded a = supplicant "application". So that route is completely off of the table. >=20 > Instead the supplicant is shipped with the OS. Therefore, any root = CAs needed by the supplicant MUST be included with the OS. >=20 > It really is that simple. >=20 > In conclusion, we need a new PKI, and the root CAs must be included = with OS distributions. But the OS vendors won't do that until we define = the requirements, solution, and transition path. >=20 > Alan DeKok. >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From nobody Sun Jan 19 08:42:14 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8725D120033; Sun, 19 Jan 2020 08:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7IGg0nhv-xxl; Sun, 19 Jan 2020 08:42:05 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1958F120013; Sun, 19 Jan 2020 08:42:05 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 13A6CA8B; Sun, 19 Jan 2020 16:42:01 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Sun, 19 Jan 2020 11:42:00 -0500 Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 16:42:08 -0000 On Jan 19, 2020, at 10:54 AM, Ryan Sleevi wrote: > There=E2=80=99s zero need to use any existing CAs. I agree. > Of course, the CAs are only going to do that if there are users: those = who will buy or rely on those certificates. So you need to convince = supplicants that a zero-touch world is worth it, AND that it can be as = secure as manual configuration. First the solution needs to be defined. > Supplicant vendors - whether they are open-source or operating system = - are taking on the work to manage and police that root store. They "are" doing this? I don't see that. > They are not at all different. In both cases, the client has a = principal it wants to validate: in RFC 6125, this is the reference name. = This is the name in your credential in the case of EAP, the name of the = host in the URL in WWW. The client wants to make sure it=E2=80=99s = talking to the entity authorized for that name. >=20 > You can manually preconfigured exactly that entity. In EAP, this is = incredibly easy to do when you=E2=80=99re provisioning the client = credential to also provision the peer identity. This is the existing = flow. I agree that they're similar, I'm not sure that they're identical. > This may seem like splitting hairs, but it=E2=80=99s a _profound_ = distinction if you=E2=80=99ve ever managed PKIs on operating systems, as = this is not true. Shipping a CA list in the supplicant shipped in the OS = !=3D shipping a CA list in the OS. They are very different models of = managing and configuring that should not be conflated. Android has = plenty of OS components that ship their own root stores, separate from = the root store it provides as part of its public API contract. We only = need the former, not the latter. What matters is that the product the user ends up with has the CAs = preconfigured for EAP. The internal corporate structure is (to me) = irrelevant. > It sounds like this has circled back into =E2=80=9CHow do we get = Apple/Microsoft/Google/whomever to have their supplicants trust a set of = CAs by default=E2=80=9D, and the steps outlined above continue to be it. = For Google/Android/ChromeOS, I=E2=80=99m not going to want to conflate = the TLS PKI and the EAP PKI if they have different operational = considerations (e.g. the ease of replacement of certs and the ability to = respond to CA incidents), different profile considerations (the = information being attested), and different policy considerations (how = that information is validated). The advocates of such a solution need to = do the work in defining the profiles and policies and presenting that as = the use case for why. Sure. > To the OS vendor, managing these profiles and policies is a = non-trivial undertaking involving a host of folks: Legal (for contracts = and CP/CPS review), Engineering, Project/Program Management (it=E2=80=99s = a lot of work to review several thousand CAs a year, let alone the 60-70 = organizations in the root store), Release Management, etc. There has to = be a value proposition here, because the convenient part of the much = maligned manual configuration is that it outsourced all the risk the OS = vendor might be taking on, and instead allows it to be the customer=E2=80=99= s problem. That may seem unfair and non-ideal, but that=E2=80=99s where = the risk/value calculus is right now, and to get vendors to change, you = need to present a compelling value case that demonstrably minimizes = risk. Trust is hard and expensive =F0=9F=A4=B7 There have been attempts to simplify supplicant configuration with a = standard XML format. The vendors expressed zero interest. And that's a = *lot* easier to do than adding a new root store. Alan DeKok. From nobody Sun Jan 19 08:54:07 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6956E12002E; Sun, 19 Jan 2020 08:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jFP96Y19x_Mu; Sun, 19 Jan 2020 08:54:04 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC1C120013; Sun, 19 Jan 2020 08:54:04 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id b15so22102088lfc.4; Sun, 19 Jan 2020 08:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YBLlXESBsiEssbhFQzJSQKbgAqpRYKRrE3A/TxRCjmA=; b=U3Ib0mnfm3/jIbLlhrNwaSa1FEC61HlVrc6bl+MmhOqIcE/poD3QcuWxFHBvnMa51Z GwK89X/Fx6FKOxwO/JZV6y9j0cOfjrsnzxPe6JCjTdyE9M237IinEWCrHUmjqbh8q20B FJd7bMXqfTA4wKBBtR/objVhiWlzN+wjTUVwyiTPqBTTDopWRZHN15XulrY5QGA/iT4j 3i/lSOw9JrRSotB8D+JTcySOmQsbGkPbN13dvWKOUobnXWCOG0AY0DuAaQZh/oXTPghl iuaEzLYrDPBjKysnCCdFKxLtO/nXRxw0UGQA4r4kG+ikv3IJuntwf6b5ThyFGgeeV943 IO4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YBLlXESBsiEssbhFQzJSQKbgAqpRYKRrE3A/TxRCjmA=; b=Q3bJdZFLimmsx9iufoPX5R3GIYRVOhJokD2xbMJIj+q3Wn1VEUcl0JfP6FBsmRFplb QOf1Gd4fp/KMWx5pz5SRsPSyLshRO8pSbm/AJldFl29HPgQtei9OpX9k/HCeNg4ymCo0 2RQiMHcaC31KuwbAKzjDCaGql8Or2TKobkfgTqe99d403GAW0faHRt5ai/ws/AN+R2CU ZCpdMQTUr46FtPKfX62uuMBqzVTvN3flRc7UoLxFtWyNtpVr6E4SHb2cLtTdjsY2af3e ipCIwq75jtCc1D7MuHU20hLVdykLhJ/1Jt17lY5V3EsQFXTcYVgYeWr7tsYUimUvs8tr RU4g== X-Gm-Message-State: APjAAAX5nr0lnVKHKpkwXvHnYJ4tqJNzmcfv2kBF92oL8c7M1Mo1/oZL xXCCxRlGxvf6Xp2Le7qyVjie3wWC8FjXBGfgyKY= X-Google-Smtp-Source: APXvYqw9Xyzi4JkaECxZYTau67b/GrkDtdurprUTNiffgAJCIQHi2TLWv/BhCwEBD7RVdWFPatkv6o23SYABv4uXpwc= X-Received: by 2002:a19:5057:: with SMTP id z23mr11114829lfj.132.1579452842350; Sun, 19 Jan 2020 08:54:02 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <666A5BF7-29A2-4CD3-97CB-DAD8B96EC040@vigilsec.com> In-Reply-To: <666A5BF7-29A2-4CD3-97CB-DAD8B96EC040@vigilsec.com> From: Peter Bowen Date: Sun, 19 Jan 2020 08:53:50 -0800 Message-ID: To: Russ Housley Cc: Alan DeKok , Ryan Sleevi , "spasm@ietf.org" , EMU WG , Ben Kaduk Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 16:54:06 -0000 On Sun, Jan 19, 2020 at 8:26 AM Russ Housley wrote: > > It seems to me that RFC 4334 offers a way for an enterprise to assert that the certificate is intended to be used with a particular SSID. This seems better than a self-signed certificate with just a domain name. > > I understand that CA/B Forum does not allow these extensions and attributes, but as already highlighted in this discussion, these certificates are not part of the Web PKI. I don't think it is that straight forward. The operating system vendors that ship supplicants heavily overlap with the ones who set the CA/Browser Forum requirements. They are also the ones who require CAs in their OS trust stores follow the CA/BF requirements. The CA/BF has made it clear over the last year or two they are willing to include other (non-WWW) types of certificates as permitted in their requirements, but look to IETF and other organizations to set the technical standards. For RFC 4334, we have a technical standard (good!). However 4334 calls out that "SSIDs may not be unique". This makes it very tricky to use a shared root setup, as it does not provide any guidance on who gets to have a certificate for the SSID "Guest". This is analogous to the issue of unqualified hostnames mentioned earlier in this discussion (who gets a TLS certificate for "mail"?) How are CAs trusted by supplicants expected to decide who gets a certificate for a given SSID? Thanks, Peter From nobody Sun Jan 19 09:12:50 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C954120033; Sun, 19 Jan 2020 09:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 Euw-lNYkSdoS; Sun, 19 Jan 2020 09:12:40 -0800 (PST) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F9A12001A; Sun, 19 Jan 2020 09:12:39 -0800 (PST) Received: by mail-ed1-f49.google.com with SMTP id f8so27255391edv.2; Sun, 19 Jan 2020 09:12:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=leFMXR0DxLeOiZ7kK47F7Wplv0pmIGr5Gc/Chl+DeiI=; b=q96F+XofwbqSKQWXX2N9ybp7liGhUU9uWtQ+4Ta7U4S9t2c9HDKOpV43x5Ov/Mw6qi GbUEC43Qb0QFXdO3nTQ/v5DYzyj3TsJzbwDUCLhnv8p4rE+uhsF22fkulZmL52eUEFnO E9yT6RcxVVIZOqGWpzN/9gskuiFe6H2moyo32KXev9CgABShCxiQoz+lNU4dAkr4mnuz Xi7Dg1NP79yUHpBT3tFOfToEKG71vYWenZ1qXXRKxXQDMedGZ2TEsbDi0xAUASaijjRa 9icDjnybct2bJi4jLt9NQqSFEipHkI78zQkJUnCV4GvWzUICzqiZ/UQSi7akKDB4HClU JMSw== X-Gm-Message-State: APjAAAX5rFUVUKMkFUNtPqBHaMo+zr/LeOuuQ7uMMQvn9KSr3oB6zEp6 dJwFRPMmdst0SVSrf848/SH9a2dw X-Google-Smtp-Source: APXvYqwPTYEoX1+k5QaFMnwdNtUzmBV9b2FLKFlrTxaPVtdYBj4UbDe2Vjjdp/hATqDdvNKmS/DGXg== X-Received: by 2002:aa7:c611:: with SMTP id h17mr13654263edq.155.1579453958111; Sun, 19 Jan 2020 09:12:38 -0800 (PST) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com. [209.85.128.45]) by smtp.gmail.com with ESMTPSA id r24sm1269587edp.15.2020.01.19.09.12.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jan 2020 09:12:37 -0800 (PST) Received: by mail-wm1-f45.google.com with SMTP id u2so12349052wmc.3; Sun, 19 Jan 2020 09:12:37 -0800 (PST) X-Received: by 2002:a05:600c:246:: with SMTP id 6mr15050305wmj.122.1579453957101; Sun, 19 Jan 2020 09:12:37 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> In-Reply-To: <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> From: Ryan Sleevi Date: Sun, 19 Jan 2020 12:12:25 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000d5f4b059c81487b" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 17:12:42 -0000 --0000000000000d5f4b059c81487b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 19, 2020 at 11:42 AM Alan DeKok wrote: > > Supplicant vendors - whether they are open-source or operating system - > are taking on the work to manage and police that root store. > > They "are" doing this? I don't see that. This was trying to describe the world in which the second problem was solved. They =E2=80=9Cwould be=E2=80=9D, which is why the message later cla= rified how to justify the risk/value proposition. > They are not at all different. In both cases, the client has a principal > it wants to validate: in RFC 6125, this is the reference name. This is th= e > name in your credential in the case of EAP, the name of the host in the U= RL > in WWW. The client wants to make sure it=E2=80=99s talking to the entity = authorized > for that name. > > > > You can manually preconfigured exactly that entity. In EAP, this is > incredibly easy to do when you=E2=80=99re provisioning the client credent= ial to > also provision the peer identity. This is the existing flow. > > I agree that they're similar, I'm not sure that they're identical. This is why advocates need to define the profile and policies :) Figuring our what information is needed is essential to figuring out the similarities and differences. > This may seem like splitting hairs, but it=E2=80=99s a _profound_ distinc= tion if > you=E2=80=99ve ever managed PKIs on operating systems, as this is not tru= e. > Shipping a CA list in the supplicant shipped in the OS !=3D shipping a CA > list in the OS. They are very different models of managing and configurin= g > that should not be conflated. Android has plenty of OS components that sh= ip > their own root stores, separate from the root store it provides as part o= f > its public API contract. We only need the former, not the latter. > > What matters is that the product the user ends up with has the CAs > preconfigured for EAP. The internal corporate structure is (to me) > irrelevant. Don=E2=80=99t conflate technical requirements with corporate structure. You= =E2=80=99re insisting on a precise technical requirement, and I=E2=80=99m explaining to= you why you=E2=80=99re using the term wrong, and in a way that meaningfully detract= s and profoundly conflates things. There=E2=80=99s a tremendous amount of differe= nce in cost and engineering between the two approaches, and so it=E2=80=99s import= ant to be clear the requirement - which is the less expensive one. There have been attempts to simplify supplicant configuration with a > standard XML format. The vendors expressed zero interest. And that's a > *lot* easier to do than adding a new root store. I=E2=80=99m not sure how this is relevant? It seems we=E2=80=99re in agreement that the status quo is manual configura= tion, it seems we=E2=80=99re in agreement that there=E2=80=99s no technical or proce= dural reason to use the set of publicly trusted CAs for TLS (it doesn=E2=80=99t get you aut= omatic recognition, it does increase your risk surface), and it seems we=E2=80=99r= e in agreement that defining a unified store is a lot of work with an unclear value proposition that justifies that work. > Going back to the original mail, there=E2=80=99s nothing to be gained fro= m trying to repurpose extant stores, and best practice remains manual configuration. If folks want more than that, they need to define what they want and how it=E2=80=99s validated, and figure out what CAs do that. All of this was pa= rt of that first reply, so are we just in agreement? --0000000000000d5f4b059c81487b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jan 19, 2020 at 11:42 AM Alan DeKok <aland@deployingradius.com> wrote:<= /div>
> Supplicant vendors - whether they are open-source or operating system = - are taking on the work to manage and police that root store.

=C2=A0 They "are" doing this?=C2=A0 I don't see that.

This was trying to descr= ibe the world in which the second problem was solved. They =E2=80=9Cwould b= e=E2=80=9D, which is why the message later clarified how to justify the ris= k/value proposition.=C2=A0

> They are not at all different. In both cases, the client has a princip= al it wants to validate: in RFC 6125, this is the reference name. This is t= he name in your credential in the case of EAP, the name of the host in the = URL in WWW. The client wants to make sure it=E2=80=99s talking to the entit= y authorized for that name.
>
> You can manually preconfigured exactly that entity. In EAP, this is in= credibly easy to do when you=E2=80=99re provisioning the client credential = to also provision the peer identity. This is the existing flow.

=C2=A0 I agree that they're similar, I'm not sure that they're = identical.

This i= s why advocates need to define the profile and policies :) Figuring our wha= t information is needed is essential to figuring out the similarities and d= ifferences.

> This may seem like splitting hairs, but it=E2=80=99s a _profound_ dist= inction if you=E2=80=99ve ever managed PKIs on operating systems, as this i= s not true. Shipping a CA list in the supplicant shipped in the OS !=3D shi= pping a CA list in the OS. They are very different models of managing and c= onfiguring that should not be conflated. Android has plenty of OS component= s that ship their own root stores, separate from the root store it provides= as part of its public API contract. We only need the former, not the latte= r.

=C2=A0 What matters is that the product the user ends up with has the CAs p= reconfigured for EAP.=C2=A0 The internal corporate structure is (to me) irr= elevant.

Don=E2= =80=99t conflate technical requirements with corporate structure. You=E2=80= =99re insisting on a precise technical requirement, and I=E2=80=99m explain= ing to you why you=E2=80=99re using the term wrong, and in a way that meani= ngfully detracts and profoundly conflates things. There=E2=80=99s a tremend= ous amount of difference in cost and engineering between the two approaches= , and so it=E2=80=99s important to be clear the requirement - which is the = less expensive one.

=C2=A0 There have been attempts to simplify supplicant configurati= on with a standard XML format.=C2=A0 The vendors expressed zero interest.= =C2=A0 And that's a *lot* easier to do than adding a new root store.

I=E2=80=99m not sur= e how this is relevant?

= It seems we=E2=80=99re in agreement that the status quo is manual configura= tion, it seems we=E2=80=99re in agreement that there=E2=80=99s no technical= or procedural reason to use the set of publicly trusted CAs for TLS (it do= esn=E2=80=99t get you automatic recognition, it does increase your risk sur= face), and it seems we=E2=80=99re in agreement that defining a unified stor= e is a lot of work with an unclear value proposition that justifies that wo= rk.
Going back to the original mail, there=E2=80=99s nothing to be ga= ined from trying to repurpose extant stores, and best practice remains manu= al configuration. If folks want more than that, they need to define what th= ey want and how it=E2=80=99s validated, and figure out what CAs do that. Al= l of this was part of that first reply, so are we just in agreement?
--0000000000000d5f4b059c81487b-- From nobody Mon Jan 20 05:54:08 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7B120129; Mon, 20 Jan 2020 05:54: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 etofAydCmriP; Mon, 20 Jan 2020 05:53:56 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE0512013A; Mon, 20 Jan 2020 05:53:55 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 901057D8; Mon, 20 Jan 2020 13:53:52 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Mon, 20 Jan 2020 08:53:50 -0500 Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 13:54:02 -0000 On Jan 19, 2020, at 12:12 PM, Ryan Sleevi wrote: >=20 > > What matters is that the product the user ends up with has the CAs = preconfigured for EAP. The internal corporate structure is (to me) = irrelevant. >=20 > Don=E2=80=99t conflate technical requirements with corporate = structure. You=E2=80=99re insisting on a precise technical requirement, = and I=E2=80=99m explaining to you why you=E2=80=99re using the term = wrong, and in a way that meaningfully detracts and profoundly conflates = things. There=E2=80=99s a tremendous amount of difference in cost and = engineering between the two approaches, and so it=E2=80=99s important to = be clear the requirement - which is the less expensive one. I fully understand that applications can easily ship root CAs. We can = therefore agree that the root CAs MUST be distributed with the software. But, precisely *zero* end users download their supplicant software. = The supplicant software comes with the OS. Which means that the root = CAs must be distributed with the OS.=20 While, there are commercial supplicant products, these products are = overwhelmingly used by the enterprise, on computers owned by the = enterprise, and managed by the enterprise systems. They have zero = impact on the average user. So whatever "product" the end-user buys already has the supplicant = software pre-installed. Which means distributed with the OS. There = isn't even an option I've seen in iOS or Android to replace the = supplicant software. It's possible to download a supplicant = *configuration* for one SSID, but that isn't standardized (see XML = format below). And when you're downloading the supplicant = configuration, it's just a manual configuration with fewer steps. = There's no *automatic* way to trust an EAP / RADIUS server and get on = the net. This is really the main point of disagreement. Your position is that = it's easy, and it's just not. The same goes for root CAs. While it's superficially true that = someone can start "Billy Bobs Tackle Shop & CA", no one has any reason = to *use* that CA. Saying "you can start a CA" and by implication have = people *use* it, is no more realistic than me saying "you write = software, Bill Gates wrote software, there's nothing preventing you from = being as rich as he is." It's theoretically true, but false in practice. In practice, an SDO like the Wifi Alliance, 3G / 4G / 5G groups can = demand their members put root CAs into devices. That can even demand = that the CAs follow certain policies. I have no such power. So it's unhelpful to say "just start your own = CA!" > There have been attempts to simplify supplicant configuration with a = standard XML format. The vendors expressed zero interest. And that's a = *lot* easier to do than adding a new root store. >=20 > I=E2=80=99m not sure how this is relevant? It demonstrates that vendors have shown little interest in making WiFi = easier to use for their end users. This decision is likely to have an = impact on these efforts. > It seems we=E2=80=99re in agreement that the status quo is manual = configuration, it seems we=E2=80=99re in agreement that there=E2=80=99s = no technical or procedural reason to use the set of publicly trusted CAs = for TLS (it doesn=E2=80=99t get you automatic recognition, it does = increase your risk surface), and it seems we=E2=80=99re in agreement = that defining a unified store is a lot of work with an unclear value = proposition that justifies that work. > Going back to the original mail, there=E2=80=99s nothing to be gained = from trying to repurpose extant stores, and best practice remains manual = configuration. If folks want more than that, they need to define what = they want and how it=E2=80=99s validated, and figure out what CAs do = that. All of this was part of that first reply, so are we just in = agreement? We are in agreement on most of that. We are in disagreement that = people can just use other CAs. Let's use a concrete example. Right now, when I add a new IMAP server = to my phone / laptop, the process is largely this: * choose IMAP configuration * add host name of IMAP server * maybe get a certificate pop-up if the CA being used isn't already = trusted, OR a pop-up saying it's trusted * add user name * add password Lo and behold, it works. Note that I did *not* download any software. = The only things I need are (a) already on my computer, and (b) in my = brain. The workflow I want to see for WiFi is this: * select an SSID * maybe get a certificate pop-up if the CA being used isn't already = trusted, OR a pop-up saying it's trusted * add user name * add password With your proposed work flow, this is just impossible. It's really = just manual configuration with fewer steps. It still requires extra = software / configuration / whatever to be downloaded. And that's the = situation I'm trying to avoid. Alan DeKok. From nobody Mon Jan 20 06:29:34 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FF8120147; Mon, 20 Jan 2020 06:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 8fFF2hjtfk2E; Mon, 20 Jan 2020 06:29:28 -0800 (PST) Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE121200BA; Mon, 20 Jan 2020 06:29:27 -0800 (PST) Received: by mail-ed1-f54.google.com with SMTP id v28so29611500edw.12; Mon, 20 Jan 2020 06:29:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YT5xljKCX2hNimmC/cQZt2E8UQ7/keILxO5xzBebp9s=; b=UGv0NNmZTXzfM+4MX4bI134dAWe6rK7Rz++LFoRUmf75xkyZiCv7nsKnnPq+FHaXWU FOUsPeN9L7YTS7h/hq0dBOunWqJn+MfP5sQSon+nxXfKOX8MHVCHvhIdr2Y/3au1EcgI 9mzV+Ias6FUDr9as5jajZ+equcwKeTo+CFA4AECYJgEDDo9fmaEVVWs4xMU8rn+Pc5fp EUSryS2Mc9CEupGPBPT52Kn+f07Sr2Tse4ObNt7Q2MxyrwYx75r5OHMIU+mKcIP8N+Kb Z2cWucENwdVAwV7j7ZuYeJFUueQU6P9XEUn6qPqRMZeJndE47kF/WHo15jQAeTLC8LVB we5Q== X-Gm-Message-State: APjAAAUGyqTaZNwIYSSvZXExXp8eCxdNxSofFZCt8CpspnZUZEInr7xf ZSW2K/3jvmi/zj26NbTipbmP7AyX X-Google-Smtp-Source: APXvYqwcXcs9SEH6dXlg1qCojZAU1g3rt02Jm/1an8LkfpAfiSv8DNNpNikpKT22+kEXXz4+9T0Vrg== X-Received: by 2002:a17:906:b7c4:: with SMTP id fy4mr20560092ejb.139.1579530566034; Mon, 20 Jan 2020 06:29:26 -0800 (PST) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com. [209.85.221.53]) by smtp.gmail.com with ESMTPSA id s11sm1113180ejx.90.2020.01.20.06.29.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2020 06:29:25 -0800 (PST) Received: by mail-wr1-f53.google.com with SMTP id z7so29737065wrl.13; Mon, 20 Jan 2020 06:29:25 -0800 (PST) X-Received: by 2002:a5d:51cc:: with SMTP id n12mr18737416wrv.177.1579530564806; Mon, 20 Jan 2020 06:29:24 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> In-Reply-To: <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> From: Ryan Sleevi Date: Mon, 20 Jan 2020 09:29:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Ryan Sleevi , Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003a30e6059c931e55" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 14:29:32 -0000 --0000000000003a30e6059c931e55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2020 at 8:53 AM Alan DeKok wrote: > I fully understand that applications can easily ship root CAs. We can > therefore agree that the root CAs MUST be distributed with the software. > > But, precisely *zero* end users download their supplicant software. Th= e > supplicant software comes with the OS. Which means that the root CAs mus= t > be distributed with the OS. > I tried to address this in my previous message, but it looks like that may not have come across clearly. It might seem like there's a distinction without a difference to say "must ship with the supplicant which ships with the OS" and "must ship with the OS", but going back to Owen's original message, there's a profound difference in the two. As this thread itself demonstrates, there's ample confusion on "distributed with the OS" and what trust purposes it's good for - policies, practices, operational procedures - and continuing to insist "distributed with the OS" is to continue to further that confusion. As I hoped my previous message conveyed, but it looks like it may not have been clear for you, I'm not dismissive that for supplicants distributed by the OS vendor, you (eventually) need to convince that OS vendor to distribute roots with their supplicants, and from the end-user perspective, a default install of that OS "just works". However, it's a very meaningful distinction in the context of root stores, even if it may not be for supplicant authors, to highlight the need to distribute roots _with the supplicant_, not the OS. This is not a corporate distinction, but it is meaningful to how solutions are engineered and the problem space, and that's why it does a great disservice to dismiss that distinction. > The same goes for root CAs. While it's superficially true that someone > can start "Billy Bobs Tackle Shop & CA", no one has any reason to *use* > that CA. Saying "you can start a CA" and by implication have people *use= * > it, is no more realistic than me saying "you write software, Bill Gates > wrote software, there's nothing preventing you from being as rich as he > is." This is again shifting the discussion. If you don't believe it is, then certainly, how you're communicating is not coming across clearly. As I've mentioned several times, anyone can issue certificates, which is all that matters for manual configuration. There's no need for anyone special or blessed - it's just manual configuration. If you'd like to go to automatic configuration, then you need to define policies and practices for issuance and verification. Anyone who can comply with those can become a CA. The usefulness of "Billy Bob's Tackle Shop & CA" is dictated by those who need a CA - the supplicants - and how well Billy Bob complies with the policies and practices. You're absolutely correct that if you don't define those, then _no one_ can become a CA. There's no reason to believe that Billy Bob is more or less qualified than an extant CA unless and until you define those. And, of course, once you define those, the usefuless of Billy Bob - how likely his CA-slash-tackle-shop is to be included - is dictated by those defining the root store. That's where the SDOs come in to place. > > There have been attempts to simplify supplicant configuration with a > standard XML format. The vendors expressed zero interest. And that's a > *lot* easier to do than adding a new root store. > > > > I=E2=80=99m not sure how this is relevant? > > It demonstrates that vendors have shown little interest in making WiFi > easier to use for their end users. This decision is likely to have an > impact on these efforts. > Then why are we wasting electrons discussing how to do it? If you believe it's a doomed effort from the start, why bother replying? The nice thing about the transition plan I've outlined several times is you don't need the OS vendors to all adopt apriori for it to be useful. Other supplicant vendors can go ahead, define their policies and practices, select their CAs, and build their root store. If it provides something useful - i.e. users do find it easier and the security tradeoffs are appropriately mitigated, such as by taking the many concerns I've expressed on this thread into consideration - then vendors may eventually come around. As I mentioned several times, there's a risk/benefit calculus at play, and advocates of the idea of a common trust store need to make a compelling case as to how to mitigate those risks. With your proposed work flow, this is just impossible. It's really just > manual configuration with fewer steps. It still requires extra software = / > configuration / whatever to be downloaded. I'm afraid you've considerably misunderstood the proposal then, as I've tried to express several times. I'm well aware the end goal is that on a 'stock' install of your OS of choice, everything just works. I've outlined several times a plan to get to that - and which does not involve shipping roots in the OS, but roots in the supplicant that comes with the OS. The distinction is quite meaningful for the reasons outlined throughout this thread, even if the end user experience is "it just works" --0000000000003a30e6059c931e55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 20, 2020 at 8:53 AM Alan = DeKok <aland@deployingradiu= s.com> wrote:
=C2=A0 I fully understand that applications can easily ship root CAs.= =C2=A0 We can therefore agree that the root CAs MUST be distributed with th= e software.

=C2=A0 But, precisely *zero* end users download their supplicant software.= =C2=A0 The supplicant software comes with the OS.=C2=A0 Which means that th= e root CAs must be distributed with the OS.

I tried to address this in my previous message, but it looks like tha= t may not have come across clearly. It might seem like there's a distin= ction without a difference to say "must ship with the supplicant which= ships with the OS" and "must ship with the OS", but going b= ack to Owen's original message, there's a profound difference in th= e two. As this thread itself demonstrates, there's ample confusion on &= quot;distributed with the OS" and what trust purposes it's good fo= r - policies, practices, operational procedures - and continuing to insist = "distributed with the OS" is to continue to further that confusio= n.

As I hoped my previous message conveyed, but it= looks like it may not have been clear for you, I'm not dismissive that= for supplicants distributed by the OS vendor, you (eventually) need to con= vince that OS vendor to distribute roots with their supplicants, and from t= he end-user perspective, a default install of that OS "just works"= ;. However, it's a very meaningful distinction in the context of root s= tores, even if it may not be for supplicant authors, to highlight the need = to distribute roots _with the supplicant_, not the OS. This is not a corpor= ate distinction, but it is meaningful to how solutions are engineered and t= he problem space, and that's why it does a great disservice to dismiss = that distinction.
=C2=A0
=C2=A0 The same goes for root CAs.=C2=A0 While it's superficially true = that someone can start "Billy Bobs Tackle Shop & CA", no one = has any reason to *use* that CA.=C2=A0 Saying "you can start a CA"= ; and by implication have people *use* it, is no more realistic than me say= ing "you write software, Bill Gates wrote software, there's nothin= g preventing you from being as rich as he is."=C2=A0
=
This is again shifting the discussion. If you don't beli= eve it is, then certainly, how you're communicating is not coming acros= s clearly.

As I've mentioned several times, an= yone can issue certificates, which is all that matters for manual configura= tion. There's no need for anyone special or blessed - it's just man= ual configuration.

If you'd like to go to auto= matic configuration, then you need to define policies and practices for iss= uance and verification. Anyone who can comply with those can become a CA. T= he usefulness of "Billy Bob's Tackle Shop & CA" is dictat= ed by those who need a CA - the supplicants - and how well Billy Bob compli= es with the policies and practices. You're absolutely correct that if y= ou don't define those, then _no one_ can become a CA. There's no re= ason to believe that Billy Bob is more or less qualified than an extant CA = unless and until you define those. And, of course, once you define those, t= he usefuless of Billy Bob - how likely his CA-slash-tackle-shop is to be in= cluded - is dictated by those defining the root store. That's where the= SDOs come in to place.=C2=A0
=C2=A0
>=C2=A0 =C2=A0There have been attempts to simplify supplicant configurat= ion with a standard XML format.=C2=A0 The vendors expressed zero interest.= =C2=A0 And that's a *lot* easier to do than adding a new root store. >
> I=E2=80=99m not sure how this is relevant?

=C2=A0 It demonstrates that vendors have shown little interest in making Wi= Fi easier to use for their end users.=C2=A0 This decision is likely to have= an impact on these efforts.

Then why a= re we wasting electrons discussing how to do it? If you believe it's a = doomed effort from the start, why bother replying?

The nice thing about the transition plan I've outlined several times i= s you don't need the OS vendors to all adopt apriori for it to be usefu= l. Other supplicant vendors can go ahead, define their policies and practic= es, select their CAs, and build their root store. If it provides something = useful - i.e. users do find it easier and the security tradeoffs are approp= riately mitigated, such as by taking the many concerns I've expressed o= n this thread into consideration - then vendors may eventually come around.= As I mentioned several times, there's a risk/benefit calculus at play,= and advocates of the idea of a common trust store need to make a compellin= g case as to how to mitigate those risks.

=C2=A0 With your proposed work flow, this is just impossible.=C2=A0 It'= s really just manual configuration with fewer steps.=C2=A0 It still require= s extra software / configuration / whatever to be downloaded.
<= div>
I'm afraid you've considerably misunderstood the= proposal then, as I've tried to express several times. I'm well aw= are the end goal is that on a 'stock' install of your OS of choice,= everything just works. I've outlined several times a plan to get to th= at - and which does not involve shipping roots in the OS, but roots in the = supplicant that comes with the OS. The distinction is quite meaningful for = the reasons outlined throughout this thread, even if the end user experienc= e is "it just works"=C2=A0
--0000000000003a30e6059c931e55-- From nobody Mon Jan 20 07:13:39 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D400C12007A for ; Mon, 20 Jan 2020 07:13:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 uP1tXX2L2_rp for ; Mon, 20 Jan 2020 07:13:28 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4047F12008A for ; Mon, 20 Jan 2020 07:13:28 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id tYW0ibl1zRHmItYk2iEyIf; Mon, 20 Jan 2020 15:13:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1579533206; bh=QsS3JG8v26+ST63dmFgNwesXA+I0dURoNg23HZjgkG0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=IvhLweHM1aVF3HASz1wDTSOLDi2787XjSOG3CCgV6pfssCpIEKwzQZNM/l0Yz7Z6f K0mIv0vtow93n9qO7WptmfsQtXuagRc9i2znIxznhn1dI2/pGhLO7yHB/0gFoULAFa VN+WNo6Dw06rTjkD47qj4g64UVM/AXU7ZTY2OLLJmF5v1EHEjDY32vNbL7CXDPJfhK vH/V0w+uNMStSbULy4skRJ99FW8MBZEqPiUdJrYMTdiSNgInsQ3aGotm9q9jJ8c95E BGoMLU7mwW298N95Otg495EyRXw/7WDeUkRtnu0WoUkV4LfEIR9IXw5R1NVtXHv1e+ 8QZXZlSVwqfig== Received: from [IPv6:2601:187:4000:6316:719e:cb1:222b:ed6c] ([IPv6:2601:187:4000:6316:719e:cb1:222b:ed6c]) by resomta-ch2-19v.sys.comcast.net with ESMTPSA id tYk0imzc3LNectYk1i5dhh; Mon, 20 Jan 2020 15:13:25 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "David B. Nelson" In-Reply-To: Date: Mon, 20 Jan 2020 10:13:24 -0500 Cc: Alan DeKok , EMU WG , "spasm@ietf.org" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <399CEA71-241C-4E34-833F-5777051A188D@comcast.net> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 15:13:33 -0000 On Jan 20, 2020, at 9:29 AM, Ryan Sleevi wrote: >=20 > I'm well aware the end goal is that on a 'stock' install of your OS of = choice, everything just works. I've outlined several times a plan to get = to that - and which does not involve shipping roots in the OS, but roots = in the supplicant that comes with the OS. The distinction is quite = meaningful for the reasons outlined throughout this thread, even if the = end user experience is "it just works=E2=80=9D=20 I think the distinction you=E2=80=99re trying to make between the OS and = supplicants is very much an =E2=80=9Cinside baseball=E2=80=9D view. = Modern OSes rely on a number of support components to deliver core = functionality. The OS is more than the kernel, GUI, CLI and browser. = =46rom an end user perspective, all the OS-vendor shipped support = components and utilities *are* the OS. It=E2=80=99s not a useful = distinction from a User Experience perspective that the supplicant code = is or is not written by the same company as the kernel (and I suspect = often it is). It=E2=80=99s shipped as part of the product. The arguments about the differentiated policies for use of certificates = and trust of CAs is probably technically sound. I think the notion that = supplicant components can ship with a separate root CA store from that = used for the browser is perhaps workable. However, it=E2=80=99s still = the OS vendor that must include this configuration for it to =E2=80=9Cjust= work out o the box=E2=80=9D. For that reason, I think the claim that = it=E2=80=99s not the OS which must support the appropriate CAs is a = distinction without a difference, and perhaps a red herring. Regards, Dave Nelson > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From nobody Mon Jan 20 07:44:30 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D166612013D; Mon, 20 Jan 2020 07:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 LIlFSGjWZR9Y; Mon, 20 Jan 2020 07:44:22 -0800 (PST) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C9A12007A; Mon, 20 Jan 2020 07:44:22 -0800 (PST) Received: by mail-ed1-f45.google.com with SMTP id b8so29900389edx.7; Mon, 20 Jan 2020 07:44:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4vfz96+Yue++rYtcbogTYfflJhtGPOZLPEjhOIqKAq0=; b=dUC3swlcyKARSWLE+f0wRo8lxtAo1XQLggmfkJBXPfXuI4cITI6p9BjjxaWJpOanxR nz1Te1BJdmsDdKyJSrw8xU6lz4K7J0b6aCpGWFbDmQAygsQ7/17rImH8KTmOkAjp0qqE WBeqVAVUWXQ4UjqeM+3n/etu9XD2QFsJPlhhDK0CBDlRCRMYHVUuYzhhuWL1Ke8Ittvn O9PdxxUDmNDHBNnsyAOp4a/rnF36ZAwuIyQU2n27NJielDT4chI3MmBlD8+ZvZZYNISg lU6QEHEW6zvZMHzDqtJMjVQrrjp6TdOxFpE5Ihqf7ViTE5vEuwLVIq7UcpaA/7rPfPiK sOzw== X-Gm-Message-State: APjAAAXzNr5OTXG5tbTG0d3AZmAP5PC6M0Hq7E53S/xMdIiJ9bnLK78r 8PCkJxn7T/1LYM5BI9a5pRuwSImO X-Google-Smtp-Source: APXvYqzTRo1nA7xpKqqNkwfqsFyi/JI/vKvwlJfHVGX/szRbTDI5QESxfUr/FpI8WlU0MKW7tc/8tw== X-Received: by 2002:a05:6402:6c7:: with SMTP id n7mr17478735edy.177.1579535060874; Mon, 20 Jan 2020 07:44:20 -0800 (PST) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com. [209.85.221.41]) by smtp.gmail.com with ESMTPSA id j19sm1303503edr.54.2020.01.20.07.44.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2020 07:44:19 -0800 (PST) Received: by mail-wr1-f41.google.com with SMTP id d16so30077901wre.10; Mon, 20 Jan 2020 07:44:19 -0800 (PST) X-Received: by 2002:a5d:51cc:: with SMTP id n12mr104183wrv.177.1579535059387; Mon, 20 Jan 2020 07:44:19 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <399CEA71-241C-4E34-833F-5777051A188D@comcast.net> In-Reply-To: <399CEA71-241C-4E34-833F-5777051A188D@comcast.net> From: Ryan Sleevi Date: Mon, 20 Jan 2020 10:44:08 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "David B. Nelson" Cc: Alan DeKok , Benjamin Kaduk , EMU WG , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000200894059c942a1a" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 15:44:29 -0000 --000000000000200894059c942a1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2020 at 10:13 AM David B. Nelson wrote: > The arguments about the differentiated policies for use of certificates > and trust of CAs is probably technically sound. I think the notion that > supplicant components can ship with a separate root CA store from that us= ed > for the browser is perhaps workable. However, it=E2=80=99s still the OS = vendor > that must include this configuration for it to =E2=80=9Cjust work out o t= he box=E2=80=9D. > For that reason, I think the claim that it=E2=80=99s not the OS which mus= t support > the appropriate CAs is a distinction without a difference, and perhaps a > red herring. It=E2=80=99s a distinction that cuts to the heart of the original proposal,= echo=E2=80=99d several times on this thread: Can=E2=80=99t we just use the TLS CAs shipped= by the OS today for this, ideally so that OS vendors don=E2=80=99t have any added = work. In that context, it=E2=80=99s essential to make the distinction that while = the end-user experience is indistinguishable, the engineering involved - and the work of standards here - is meaningfully different. If we conflate the two or think =E2=80=9Clet=E2=80=99s just use what we have=E2=80=9D, then th= e world of zero touch will not happen. That=E2=80=99s why it=E2=80=99s essential to focus on the = notion of defining a new root store, one that doesn=E2=80=99t have to be generally av= ailable to software running on that OS, limited for a particular purpose, so that we can enumerate the necessary profiles and practices. It=E2=80=99s also essential to understanding that this solution isn=E2=80= =99t gated on a first-mover problem, as had also been suggested, where everything is doomed unless and until the OS moves. There=E2=80=99s considerable work that can -= and should - be done, which makes it easier to bring about the second solution (=E2=80=9Czero-touch=E2=80=9D), by making sure that the first problem (=E2= =80=9Cwhat SHOULD you do=E2=80=9D) adequately focuses on making a transition possible. > --000000000000200894059c942a1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 20, 2020 at 10:13 AM David B. Nelson <d.b.nelson@comcast.net> wrote:
The arguments about the differentiated policies for use of certificates and= trust of CAs is probably technically sound.=C2=A0 I think the notion that = supplicant components can ship with a separate root CA store from that used= for the browser is perhaps workable.=C2=A0 However, it=E2=80=99s still the= OS vendor that must include this configuration for it to =E2=80=9Cjust wor= k out o the box=E2=80=9D.=C2=A0 For that reason, I think the claim that it= =E2=80=99s not the OS which must support the appropriate CAs is a distincti= on without a difference, and perhaps a red herring.

It=E2=80=99s a distinction that cuts to = the heart of the original proposal, echo=E2=80=99d several times on this th= read: Can=E2=80=99t we just use the TLS CAs shipped by the OS today for thi= s, ideally so that OS vendors don=E2=80=99t have any added work.

In that context, it=E2=80=99s esse= ntial to make the distinction that while the end-user experience is indisti= nguishable, the engineering involved - and the work of standards here - is = meaningfully different. If we conflate the two or think =E2=80=9Clet=E2=80= =99s just use what we have=E2=80=9D, then the world of zero touch will not = happen. That=E2=80=99s why it=E2=80=99s essential to focus on the notion of= defining a new root store, one that doesn=E2=80=99t have to be generally a= vailable to software running on that OS, limited for a particular purpose, = so that we can enumerate the necessary profiles and practices.

It=E2=80=99s also essential to under= standing that this solution isn=E2=80=99t gated on a first-mover problem, a= s had also been suggested, where everything is doomed unless and until the = OS moves. There=E2=80=99s considerable work that can - and should - be done= , which makes it easier to bring about the second solution (=E2=80=9Czero-t= ouch=E2=80=9D), by making sure that the first problem (=E2=80=9Cwhat SHOULD= you do=E2=80=9D) adequately focuses on making a transition possible.
=
--000000000000200894059c942a1a-- From nobody Mon Jan 20 08:19:47 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D604C12089F; Mon, 20 Jan 2020 08:19:45 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AMURqBtqEXQq; Mon, 20 Jan 2020 08:19:32 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955B51208A1; Mon, 20 Jan 2020 08:19:26 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id C1FDCC3A; Mon, 20 Jan 2020 16:19:22 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Mon, 20 Jan 2020 11:19:21 -0500 Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 16:19:46 -0000 On Jan 20, 2020, at 9:29 AM, Ryan Sleevi wrote: > As I hoped my previous message conveyed, but it looks like it may not = have been clear for you, I'm not dismissive that for supplicants = distributed by the OS vendor, you (eventually) need to convince that OS = vendor to distribute roots with their supplicants, and from the end-user = perspective, a default install of that OS "just works". However, it's a = very meaningful distinction in the context of root stores, even if it = may not be for supplicant authors, to highlight the need to distribute = roots _with the supplicant_, not the OS. This is not a corporate = distinction, but it is meaningful to how solutions are engineered and = the problem space, and that's why it does a great disservice to dismiss = that distinction. We'll have to disagree here. That distinction is entirely a technical = detail which is irrelevant to the end user. It doesn't matter to the = standards bodies, either. The distinction doesn't even matter in the content of root stores. = The vendor downloads N root CAs, and places them into files / DBs in the = product. Whether those files from from A and go to B, or come from C = and go to D is *entirely* irrelevant to the end product. Whether it's = Department A that downloads the roots CAs or Department B is also = irrelevant. Whether we have to convince "the OS vendor", or just "the supplicant = division in the OS vendor" is largely the same thing. > The same goes for root CAs. While it's superficially true that = someone can start "Billy Bobs Tackle Shop & CA", no one has any reason = to *use* that CA. Saying "you can start a CA" and by implication have = people *use* it, is no more realistic than me saying "you write = software, Bill Gates wrote software, there's nothing preventing you from = being as rich as he is."=20 >=20 > This is again shifting the discussion. If you don't believe it is, = then certainly, how you're communicating is not coming across clearly. It's not shifting the discussion. It's directly addressing your = point, as clearly as I can make it. > As I've mentioned several times, anyone can issue certificates, which = is all that matters for manual configuration. There's no need for anyone = special or blessed - it's just manual configuration. The issue, as I've mentioned several times, is that's where we are = today. There's no need to bring up current behaviour as an option - we = know it's an option. We're trying to fix it. > If you'd like to go to automatic configuration, then you need to = define policies and practices for issuance and verification. Anyone who = can comply with those can become a CA. The usefulness of "Billy Bob's = Tackle Shop & CA" is dictated by those who need a CA - the supplicants - = and how well Billy Bob complies with the policies and practices. You're = absolutely correct that if you don't define those, then _no one_ can = become a CA. There's no reason to believe that Billy Bob is more or less = qualified than an extant CA unless and until you define those. And, of = course, once you define those, the usefuless of Billy Bob - how likely = his CA-slash-tackle-shop is to be included - is dictated by those = defining the root store. That's where the SDOs come in to place.=20 Which is largely what I was saying. So I think we're in agreement = here. But again, this doesn't *help*. I can't get my CA shipped with vendor = products, and nothing you've said convinces me that it's possible. > Then why are we wasting electrons discussing how to do it? If you = believe it's a doomed effort from the start, why bother replying? I never said it was "doomed". I was trying to suggest that there we = need to have clear benefits, and a clear path to implementing the = benefits. > The nice thing about the transition plan I've outlined several times = is you don't need the OS vendors to all adopt apriori for it to be = useful. Other supplicant vendors can go ahead, define their policies and = practices, select their CAs, and build their root store. And not a single person will download and use the new supplicant = software. Making it 100% useless. Any "supplicant division" of an OS vendor will require high-level = signify before massively changing user workflow. So in the end, it *is* = the "OS vendor" who has to be convinced. > I'm afraid you've considerably misunderstood the proposal then, as = I've tried to express several times. I'm well aware the end goal is that = on a 'stock' install of your OS of choice, everything just works. I've = outlined several times a plan to get to that - and which does not = involve shipping roots in the OS, but roots in the supplicant that comes = with the OS. The distinction is quite meaningful for the reasons = outlined throughout this thread, even if the end user experience is "it = just works"=20 When I do RADIUS stuff, I say "the vendor has to do X". It's never = been useful to say "Bob in engineering department X has to do it". The = distinction you're making is 100% irrelevant. If this distinction is necessary and important, why has every other WG = avoided doing it? i think we're at an impass. We agree on the end goal, but disagree = fundamentally on some major points. Alan DeKok. From nobody Mon Jan 20 08:22:32 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB991208B1; Mon, 20 Jan 2020 08:22:25 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BdQpZNYb_KyM; Mon, 20 Jan 2020 08:22:19 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA981208AE; Mon, 20 Jan 2020 08:22:19 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 451DE17D2; Mon, 20 Jan 2020 16:22:17 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> Date: Mon, 20 Jan 2020 11:22:15 -0500 Cc: "Owen Friel (ofriel)" , EMU WG , Michael Richardson , "spasm@ietf.org" , Benjamin Kaduk , Joseph Salowey Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 16:22:26 -0000 On Jan 20, 2020, at 11:19 AM, Alan DeKok = wrote: >=20 > Any "supplicant division" of an OS vendor will require high-level = signify before massively changing user workflow. So in the end, it *is* = the "OS vendor" who has to be convinced. Please read "sign-off", not "signify". :( Alan DeKok. From nobody Mon Jan 20 08:29:01 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471BB1208E3; Mon, 20 Jan 2020 08:29:00 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9CbcKpmOMpRk; Mon, 20 Jan 2020 08:28:57 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3449F1208DD; Mon, 20 Jan 2020 08:28:57 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 08C421202; Mon, 20 Jan 2020 16:28:54 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Mon, 20 Jan 2020 11:28:53 -0500 Cc: "David B. Nelson" , Benjamin Kaduk , EMU WG , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4B3EC1F1-9CAB-4E87-8F0E-53BDCDADD096@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <399CEA71-241C-4E34-833F-5777051A188D@comcast.net> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 16:29:00 -0000 On Jan 20, 2020, at 10:44 AM, Ryan Sleevi wrote: > It=E2=80=99s a distinction that cuts to the heart of the original = proposal, echo=E2=80=99d several times on this thread: Can=E2=80=99t we = just use the TLS CAs shipped by the OS today for this, ideally so that = OS vendors don=E2=80=99t have any added work. There has been consensus already that it's wrong to use the existing = TLS CAs > In that context, it=E2=80=99s essential to make the distinction that = while the end-user experience is indistinguishable, the engineering = involved - and the work of standards here - is meaningfully different. = If we conflate the two or think =E2=80=9Clet=E2=80=99s just use what we = have=E2=80=9D, then the world of zero touch will not happen. That=E2=80=99= s why it=E2=80=99s essential to focus on the notion of defining a new = root store, one that doesn=E2=80=99t have to be generally available to = software running on that OS, limited for a particular purpose, so that = we can enumerate the necessary profiles and practices. I agree. > It=E2=80=99s also essential to understanding that this solution = isn=E2=80=99t gated on a first-mover problem, as had also been = suggested, where everything is doomed unless and until the OS moves. = There=E2=80=99s considerable work that can - and should - be done, which = makes it easier to bring about the second solution (=E2=80=9Czero-touch=E2= =80=9D), by making sure that the first problem (=E2=80=9Cwhat SHOULD you = do=E2=80=9D) adequately focuses on making a transition possible. I don't think "doomed". I think *required*. i.e. the end goal *is* = to have it "just work" out of the box. I think we may be arguing semantics, and avoiding some common points. I *do* agree that we can define new CAs just for EAP today. I do = agree that these CAs can be used by supplicants that exist today, via = manual configuration. However, I do also believe that we will not get new behaviour without = changing the supplicant implementations. So the intermediate step of = just using a "new CA" has near-zero benefits to the end user. And, if the new CA must be configured manually, then that step is no = different than what we have today. Which means that this intermediate = step further has near-zero benefits. That's why I'm focussed on the end goal: updating the root CAs *and* = supplicant implementations at the same time. And, making sure that all = of these updates ship with the product that the consumer buys. The = intermediate steps gain nothing. Alan DeKok. From nobody Mon Jan 20 08:52:17 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88247120914; Mon, 20 Jan 2020 08:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 1mwNlfRVCEyG; Mon, 20 Jan 2020 08:52:03 -0800 (PST) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D9B120915; Mon, 20 Jan 2020 08:51:58 -0800 (PST) Received: by mail-ed1-f48.google.com with SMTP id v28so108104edw.12; Mon, 20 Jan 2020 08:51:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ObbakONNpKBu3/0Kxoh6riOH5osQffPn2UYOUaw12aY=; b=VhJKyTk0fMYk4wshF/m7wZ1d7FdZXP+F23nc+6IlzP9rFHsLfoRU1JrtF3TQ1mIZuU 5xo3ZXRXY9cnHxJCva03EKKOflVE20wwM+kGRR3hGfTBtbesovREP6VX5q2XHWJt/LUO 0cgN1k5iMd2Nw+EPJ6OVwFOsK/AF41ovDxsB0RfSyYbKoo7U92/U5nQm6i12BUK7iHd8 cwLau0xo0SPJyPsKC7Y1rG/vPibiTqEIzyFi3Ten6enslOOwA2DSqRr1fiuihVLzXYoc WhzQeErERdpbHwcaH11rxeiJUvm29V24XjybAnFdfnaH8ATEJ6lL0MChTAoKofVnhTb5 dpUg== X-Gm-Message-State: APjAAAVWx/wxyA+JNOxQ00/GrvoKKikCM/WTM/5pkTtkou2M5WjA93qp ZGItPjh0hGV42hSaantAKqvfphjl X-Google-Smtp-Source: APXvYqyC4fSCWkUxrNEXnyTNMMNSGC1n5UrteE4BGAMUv64Jzkmn7QevVpJwoBaJ3810SLtGtfBp2Q== X-Received: by 2002:a17:906:4816:: with SMTP id w22mr326880ejq.196.1579539116284; Mon, 20 Jan 2020 08:51:56 -0800 (PST) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com. [209.85.128.53]) by smtp.gmail.com with ESMTPSA id cb20sm1430999edb.1.2020.01.20.08.51.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2020 08:51:55 -0800 (PST) Received: by mail-wm1-f53.google.com with SMTP id a5so46089wmb.0; Mon, 20 Jan 2020 08:51:55 -0800 (PST) X-Received: by 2002:a1c:ddd7:: with SMTP id u206mr230430wmg.159.1579539115479; Mon, 20 Jan 2020 08:51:55 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> In-Reply-To: <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> From: Ryan Sleevi Date: Mon, 20 Jan 2020 11:51:44 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e3190b059c951b60" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 16:52:16 -0000 --000000000000e3190b059c951b60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok wrote: > The distinction doesn't even matter in the content of root stores. The > vendor downloads N root CAs, and places them into files / DBs in the > product. Whether those files from from A and go to B, or come from C and > go to D is *entirely* irrelevant to the end product. Whether it's > Department A that downloads the roots CAs or Department B is also > irrelevant. This is not at all how root stores work or have worked for ages, and I suspect this lack of familiarity may be the cause of the significant confusion demonstrated here. There isn=E2=80=99t =E2=80=9Ca=E2=80=9D root store on any modern OS. Even i= f you factor Linux with the LSB, there are multiple root stores. Multiple independent root stores are maintained for separate purposes, with their own policies and profiles, administered not only by different parts of the organization, but also against different standards and with different industry bodies. This basic understanding of how modern PKI works is essential to understanding how to make productive contributions in this space, because it shapes how the profiles are developed, how the policies are administered, and how one makes progress convincing the right stakeholders of the vision. Whether we have to convince "the OS vendor", or just "the supplicant > division in the OS vendor" is largely the same thing. It isn=E2=80=99t, and there=E2=80=99s been zero evidence to support that co= nclusion, but I can tell reality isn=E2=80=99t that convincing :) But again, this doesn't *help*. I can't get my CA shipped with vendor > products, and nothing you've said convinces me that it's possible. You can=E2=80=99t get your non-existent CA that issues against undefined pr= ofiles and undefined practices included, and you=E2=80=99re lamenting that? I mean= , there=E2=80=99s no place I can go buy a unicorn burger, but I=E2=80=99m not= exactly sending letters to McDonald=E2=80=99s complaining about this. The path to getting it shipped with vendor products involves, as I=E2=80=99= ve said repeatedly: define the profile and define the policies. That makes it even possible for Billy Bob to issue in the first place, and to assess how well Billy Bob does issue, and that=E2=80=99s the path forward. Lamenting that y= ou can=E2=80=99t get a unicorn burger today doesn=E2=80=99t move the discussion further. And not a single person will download and use the new supplicant > software. Making it 100% useless. This sort of fatalism is doomed to be unproductive. Fixating on the OS vendor as an excuse to not do the work just means won=E2=80=99t get done. Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You have paths forward. When I do RADIUS stuff, I say "the vendor has to do X". It's never been > useful to say "Bob in engineering department X has to do it". The > distinction you're making is 100% irrelevant. You=E2=80=99re confusing =E2=80=9Ceveryone at the vendor needs to move thei= r car=E2=80=9D with =E2=80=9CBob needs to move his car=E2=80=9D. You=E2=80=99re doomed to failure if you kee= p insisting everyone at the company needs to move their car, when all you need is Bob to move and not block your car in. The distinction you keep insisting on is like asking =E2=80=9CYou must inve= st $10 million=E2=80=9D, when all you need is $10. Yes, if you had $10 million, yo= u would have your $10. Continually saying =E2=80=9Cbut I really need the money=E2= =80=9D rather than =E2=80=9CI just need $10=E2=80=9D leads to impasses. This is not about which department is involved. The distinction is about the scope of trust. Saying shipped in the OS, both in the context of this thread and more generally, is presuming a broad scope and maintained interfaces for third-parties, neither of which you need. Not recognizing that a =E2=80=9Croot store=E2=80=9D on a modern OS is merely an abstraction= over disparate trust bits is meaningful, particularly when not addressing what the =E2=80= =9Ctrust bits=E2=80=9D should be or how they=E2=80=99re maintained. A good example of this is HotSpot 2.0. It works, it=E2=80=99s not part of t= he root stores on Windows or Android, yet it uses its own roots and policies and practices and works out of the box. To any developer on those platforms, it=E2=80=99s not part of the OS, yet to the user, it just works. The IETF primarily targets those developers, not the end-user, and it=E2=80= =99s essential to understand why and how it works to understand what work is needed to make something similar for EAP. Dismissing that as organizational structure just means dismissing the requirements and means to success, in which case, you=E2=80=99re going to be as unsatisfied as my appetite for a = fresh unicorn burger. > --000000000000e3190b059c951b60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok <aland@deployingradius.com> wrote:<= /div>
=C2=A0 The distinction doesn't even matter in the content of root store= s.=C2=A0 The vendor downloads N root CAs, and places them into files / DBs = in the product.=C2=A0 Whether those files from from A and go to B, or come = from C and go to D is *entirely* irrelevant to the end product.=C2=A0 Wheth= er it's Department A that downloads the roots CAs or Department B is al= so irrelevant.

Th= is is not at all how root stores work or have worked for ages, and I suspec= t this lack of familiarity may be the cause of the significant confusion de= monstrated here.

There i= sn=E2=80=99t =E2=80=9Ca=E2=80=9D root store on any modern OS. Even if you f= actor Linux with the LSB, there are multiple root stores. Multiple independ= ent root stores are maintained for separate purposes, with their own polici= es and profiles, administered not only by different parts of the organizati= on, but also against different standards and with different industry bodies= .

This basic understandi= ng of how modern PKI works is essential to understanding how to make produc= tive contributions in this space, because it shapes how the profiles are de= veloped, how the policies are administered, and how one makes progress conv= incing the right stakeholders of the vision.

=C2=A0 Whether we have to convince "the OS vendor", or just "= ;the supplicant division in the OS vendor" is largely the same thing.<= /blockquote>

It isn=E2=80=99t,= and there=E2=80=99s been zero evidence to support that conclusion, but I c= an tell reality isn=E2=80=99t that convincing :)
=C2=A0 But again, this doesn't *help*.=C2=A0 I can't get my CA ship= ped with vendor products, and nothing you've said convinces me that it&= #39;s possible.

Y= ou can=E2=80=99t get your non-existent CA that issues against undefined pro= files and undefined practices included, and you=E2=80=99re lamenting that? = I mean, there=E2=80=99s no place I can go buy a unicorn burger, but I=E2=80= =99m not exactly sending letters to McDonald=E2=80=99s complaining about th= is.

The path to getting = it shipped with vendor products involves, as I=E2=80=99ve said repeatedly: = define the profile and define the policies. That makes it even possible for= Billy Bob to issue in the first place, and to assess how well Billy Bob do= es issue, and that=E2=80=99s the path forward. Lamenting that you can=E2=80= =99t get a unicorn burger today doesn=E2=80=99t move the discussion further= .

=C2=A0 And not a single person will download and use the new supplicant sof= tware.=C2=A0 Making it 100% useless.

This sort of fatalism is doomed to be unproductive. Fix= ating on the OS vendor as an excuse to not do the work just means won=E2=80= =99t get done.

Is Cisco = a supplicant vendor? Is=C2=A0Jouni Malinen= a supplicant vendor? You have paths forward.

=C2=A0 =C2=A0When I do RADIUS stuff, I say "the vendor has to do X&quo= t;.=C2=A0 It's never been useful to say "Bob in engineering depart= ment X has to do it".=C2=A0 The distinction you're making is 100% = irrelevant.

You= =E2=80=99re confusing =E2=80=9Ceveryone at the vendor needs to move their c= ar=E2=80=9D with =E2=80=9CBob needs to move his car=E2=80=9D. You=E2=80=99r= e doomed to failure if you keep insisting everyone at the company needs to = move their car, when all you need is Bob to move and not block your car in.=

The distinction you kee= p insisting on is like asking =E2=80=9CYou must invest $10 million=E2=80=9D= , when all you need is $10. Yes, if you had $10 million, you would have you= r $10. Continually saying =E2=80=9Cbut I really need the money=E2=80=9D rat= her than =E2=80=9CI just need $10=E2=80=9D leads to impasses.

This is not about which department is= involved. The distinction is about the scope of trust. Saying shipped in t= he OS, both in the context of this thread and more generally, is presuming = a broad scope and maintained interfaces for third-parties, neither of which= you need. Not recognizing that a =E2=80=9Croot store=E2=80=9D on a modern = OS is merely an abstraction over disparate trust bits is meaningful, partic= ularly when not addressing what the =E2=80=9Ctrust bits=E2=80=9D should be = or how they=E2=80=99re maintained.

A good example of this is HotSpot 2.0. It works, it=E2=80=99s no= t part of the root stores on Windows or Android, yet it uses its own roots = and policies and practices and works out of the box. To any developer on th= ose platforms, it=E2=80=99s not part of the OS, yet to the user, it just wo= rks.

The IETF primarily = targets those developers, not the end-user, and it=E2=80=99s essential to u= nderstand why and how it works to understand what work is needed to make so= mething similar for EAP. Dismissing that as organizational structure just m= eans dismissing the requirements and means to success, in which case, you= =E2=80=99re going to be as unsatisfied as my appetite for a fresh unicorn b= urger.
--000000000000e3190b059c951b60-- From nobody Mon Jan 20 09:22:18 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEB61209AF; Mon, 20 Jan 2020 09:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 u66RudJSPwRK; Mon, 20 Jan 2020 09:22:12 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C0E1209EC; Mon, 20 Jan 2020 09:22:12 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8EA473897E; Mon, 20 Jan 2020 12:21:40 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6456C5F5; Mon, 20 Jan 2020 12:22:11 -0500 (EST) From: Michael Richardson To: EMU WG , "spasm\@ietf.org" In-Reply-To: <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 17:22:17 -0000 --=-=-= Content-Type: text/plain Alan DeKok wrote: > While, there are commercial supplicant products, these products are > overwhelmingly used by the enterprise, on computers owned by the > enterprise, and managed by the enterprise systems. They have zero > impact on the average user. Today. But, since a goal here was for IoT devices, this changes things: 1) Enterprises want to manage IoT device onboarding, and they overwhelmingly want to use EAP/1x. 2) IoT devices don't have users and can't even load a non-standard XML configuration. > In practice, an SDO like the Wifi Alliance, 3G / 4G / 5G groups can > demand their members put root CAs into devices. That can even demand > that the CAs follow certain policies. > I have no such power. So it's unhelpful to say "just start your own > CA!" Well, even if you were the Wifi Alliance, you'd also have a mindshare/bootstrap problem. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4l4cMACgkQgItw+93Q 3WXm+wf7BjspjXJM5N1EQ/xI57zl3TtjlsjHrr3YZucXldWmOv6cOM6I1SWIfT88 Un2emKmBo5Xu+pGmJizw8Ip9jWL0pk63I9MH0NL/MwFcV781aJEYbI38o9M41kB0 GgkAMgQFbtfpP2AYRMN6/hTPr27B/OhKd2WzcZ0uSDv9a7Vw/NvWj5WlhOY4mS6C p7bD6KVG8uJzVJsNZ+GK2BroOIFw3g1vVoGLIikloN2kqy4rOZwYeUzEIOAef/jQ 2Ztc0+yx2Lxy1lwqok7vHPGfS9fMPbggA9UlO2fEP7j4LAH+XF1xL4hHxuWilSy7 742t8rPDW/LSiQpjfMOSi/TSaC5xaA== =V5R6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jan 20 09:28:40 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFCA120255 for ; Mon, 20 Jan 2020 09:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 udn9sB1zk9iE for ; Mon, 20 Jan 2020 09:28:35 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8C8120019 for ; Mon, 20 Jan 2020 09:28:35 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id taGmioMU3jvfetaqoinI7U; Mon, 20 Jan 2020 17:28:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1579541314; bh=QBE9c8pdZmgRR9Yip24H1PuCjTAt1+zjFMjthfFvgVU=; h=Received:Received:From:Message-Id:Content-Type:Mime-Version: Subject:Date:To; b=oPp/eojVKzefUqAZnsGPUyBre6ET0jSWsC8BYqz7LI0kMsrYWUnuJkPertPUGsuUV IvPAOuaaIvroEuqlhINQx5p+iQPdy1l8aids4DO6In2XxFYa20+wLuAGR+ROrZ0sOr 0D8nGeA/9Z34J9afkyO6/E2D4BcL1AdbTIb2mqc+9KGY6r0LP+1WePyVTibOv8Y86H 1NvKWtzYAfQv8/oSmcDFGTnCax0NpwPRfKLNZO/8tXsuNVPrOyXMdqJ+SXrwsDruE0 hdNbWTteCbUT2sRfxui5QShekzxASnBd8CcS7qxv2fn+cTQCgW7xIcoHbtIcEGaHdI xcEim4Ojl+5Fw== Received: from [IPv6:2601:187:4000:6316:1cfb:cbcc:4e89:b6ef] ([IPv6:2601:187:4000:6316:1cfb:cbcc:4e89:b6ef]) by resomta-ch2-08v.sys.comcast.net with ESMTPSA id taqniuOrLay2utaqniokQT; Mon, 20 Jan 2020 17:28:34 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit From: "David B. Nelson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B493F452-3D73-47DA-B6BD-835DDEAFC25B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 20 Jan 2020 12:28:32 -0500 In-Reply-To: Cc: Alan DeKok , EMU WG , "spasm@ietf.org" , Benjamin Kaduk To: Ryan Sleevi References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 17:28:39 -0000 --Apple-Mail=_B493F452-3D73-47DA-B6BD-835DDEAFC25B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 20, 2020, at 11:51 AM, Ryan Sleevi wrote: >=20 > Whether we have to convince "the OS vendor", or just "the supplicant = division in the OS vendor" is largely the same thing. >=20 > It isn=E2=80=99t, and there=E2=80=99s been zero evidence to support = that conclusion, but I can tell reality isn=E2=80=99t that convincing :) I have to disagree with that. There are exceptions to very rule, of = course, but I have never downloaded, installed and configured a = supplicant on any of my computing devices. I=E2=80=99m a highly = technical end-user (long time IETF and IEEE contributor). > This is not about which department is involved. The distinction is = about the scope of trust. Saying shipped in the OS, both in the context = of this thread and more generally, is presuming a broad scope and = maintained interfaces for third-parties, neither of which you need. Not = recognizing that a =E2=80=9Croot store=E2=80=9D on a modern OS is merely = an abstraction over disparate trust bits is meaningful, particularly = when not addressing what the =E2=80=9Ctrust bits=E2=80=9D should be or = how they=E2=80=99re maintained. And *that* is an artifact of the way vendors have chosen to ship their = OS products. I think what you=E2=80=99re saying is that large industry = software providers aren=E2=80=99t going to change their behavior just = because it inconveniences users (customers). Maybe that=E2=80=99s true. = However, it=E2=80=99s an organizational and implementation argument, = not a technical one. > The IETF primarily targets those developers, not the end-user, and = it=E2=80=99s essential to understand why and how it works to understand = what work is needed to make something similar for EAP. Dismissing that = as organizational structure just means dismissing the requirements and = means to success, in which case, you=E2=80=99re going to be as = unsatisfied as my appetite for a fresh unicorn burger. Sure. Standards are voluntary. All *good* standards start with clear = and accurate Use Cases and User Stories. The =E2=80=9Dusers=E2=80=9D = have to include end-users, not just developers. Technical standards are = successful when they solve end-user, market driven problems. Standards = that seek (primarily or secondarily) to preserve =E2=80=9Cthe way = we=E2=80=99ve always done it=E2=80=9D among the vendor base, are not = very useful, IMHO. We all seem to agree that change is required. Where we disagree is how = change is implemented and who has to make it. I=E2=80=99m not a = unicorn-seeking idealist, but if the rationale behind a particular path = to change is suboptimal because of vendor intransigence, then that needs = to be very clearly documented for all stakeholders to see. Regards, Dave Nelson --Apple-Mail=_B493F452-3D73-47DA-B6BD-835DDEAFC25B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jan 20, 2020, at 11:51 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

  Whether we have to convince "the OS vendor", or just "the = supplicant division in the OS vendor" is largely the same = thing.

It isn=E2=80=99t, and there=E2=80=99s been zero = evidence to support that conclusion, but I can tell reality isn=E2=80=99t = that convincing :)

I have to disagree with that.  There are = exceptions to very rule, of course, but I have never downloaded, = installed and configured a supplicant on any of my computing devices. =  I=E2=80=99m a highly technical end-user (long time IETF and IEEE = contributor).

This is not about which department is involved. The = distinction is about the scope of trust. Saying shipped in the OS, both = in the context of this thread and more generally, is presuming a broad = scope and maintained interfaces for third-parties, neither of which you = need. Not recognizing that a =E2=80=9Croot store=E2=80=9D on a modern OS = is merely an abstraction over disparate trust bits is meaningful, = particularly when not addressing what the =E2=80=9Ctrust bits=E2=80=9D = should be or how they=E2=80=99re = maintained.

And *that* is an artifact of the way vendors have = chosen to ship their OS products.  I think what you=E2=80=99re = saying is that large industry software providers aren=E2=80=99t going to = change their behavior just because it inconveniences users (customers). =  Maybe that=E2=80=99s true.  However, it=E2=80=99s an = organizational and implementation argument, not a technical = one.

The IETF primarily targets those developers, not the = end-user, and it=E2=80=99s essential to understand why and how it works = to understand what work is needed to make something similar for EAP. = Dismissing that as organizational structure just means dismissing the = requirements and means to success, in which case, you=E2=80=99re going = to be as unsatisfied as my appetite for a fresh unicorn = burger.

Sure.=  Standards are voluntary.  All *good* standards start with = clear and accurate Use Cases and User Stories.  The =E2=80=9Dusers=E2= =80=9D have to include end-users, not just developers. Technical = standards are successful when they solve end-user, market driven = problems.  Standards that seek (primarily or secondarily) to = preserve =E2=80=9Cthe way we=E2=80=99ve always done it=E2=80=9D among = the vendor base, are not very useful, IMHO.

We all seem to agree that change is required. =  Where we disagree is how change is implemented and who has to make = it.  I=E2=80=99m not a unicorn-seeking idealist, but if the = rationale behind a particular path to change is suboptimal because of = vendor intransigence, then that needs to be very clearly documented for = all stakeholders to see.

Regards,

Dave = Nelson

= --Apple-Mail=_B493F452-3D73-47DA-B6BD-835DDEAFC25B-- From nobody Mon Jan 20 10:09:13 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80B9120A63; Mon, 20 Jan 2020 10:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 XGS9hKn8Vy95; Mon, 20 Jan 2020 10:09:02 -0800 (PST) Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5507120871; Mon, 20 Jan 2020 10:09:01 -0800 (PST) Received: by mail-ed1-f42.google.com with SMTP id l8so411957edw.1; Mon, 20 Jan 2020 10:09:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hrG8SgQ1PoyST2KiroqNbAG533N7Mt/eZf3E98SvqwY=; b=OMAsRwknikKUBx3K5o0APB08GqkcqUX5vzZL/NgLpf6jB1C01koPKTvdAZykpB5C+7 dhVuh6wHYVntWQTOTkpKBqJm9HEZok955F/oX7QkEihSkaEhtwiuYQrmpFFkNn3E26Si O7Y9V/073VCZqElUBkZhjOlMf3u3LxYdIc/MUZfsq45dtGY2+rRJ6/zbvAzik1sSGGkf M5nGfNLB8o6nJ9BFBbuthU1YlHC8k5JSU5JSMUI3UpYgFZAxv/SiMASp0O6OHdP515Oy LLMFN24B1KpDJ0R6lviYuOrZOJUS7R6S4WXg5Bs+rYJ3gQ/9c7bAAgi3NWtbNBAhvq8W nOjA== X-Gm-Message-State: APjAAAWhQR79S3paRdErCuyXI07LCl2pg+9+bNTKy8nkWfth4kY7UwF0 4+N3GciLxLYIT4shK1vmSPF68HQb X-Google-Smtp-Source: APXvYqzZ3MElT4LU6nhfU2wA6OKLP0aNF4fhWprK60ETrkRBfEGTYsLBDKYexNbs/mWz+TZbEt4Utg== X-Received: by 2002:a05:6402:1b84:: with SMTP id cc4mr280731edb.383.1579543740062; Mon, 20 Jan 2020 10:09:00 -0800 (PST) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com. [209.85.128.54]) by smtp.gmail.com with ESMTPSA id v2sm1431955edx.92.2020.01.20.10.08.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2020 10:08:59 -0800 (PST) Received: by mail-wm1-f54.google.com with SMTP id p9so266142wmc.2; Mon, 20 Jan 2020 10:08:59 -0800 (PST) X-Received: by 2002:a1c:9c4c:: with SMTP id f73mr100911wme.125.1579543739248; Mon, 20 Jan 2020 10:08:59 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> In-Reply-To: From: Ryan Sleevi Date: Mon, 20 Jan 2020 13:08:47 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "David B. Nelson" Cc: Alan DeKok , Benjamin Kaduk , EMU WG , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007c34e5059c962fcf" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 18:09:06 -0000 --0000000000007c34e5059c962fcf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2020 at 12:28 PM David B. Nelson wrote: > On Jan 20, 2020, at 11:51 AM, Ryan Sleevi wrote: > > > Whether we have to convince "the OS vendor", or just "the supplicant >> division in the OS vendor" is largely the same thing. > > > It isn=E2=80=99t, and there=E2=80=99s been zero evidence to support that = conclusion, but I > can tell reality isn=E2=80=99t that convincing :) > > > I have to disagree with that. There are exceptions to very rule, of > course, but I have never downloaded, installed and configured a supplican= t > on any of my computing devices. I=E2=80=99m a highly technical end-user = (long time > IETF and IEEE contributor). > How is this related? This isn=E2=80=99t about downloading third-party suppl= icant software, this is about scoping the problem and the solution. Shipping as part of the OS, as a root store, is several magnitudes more work than shipping as part of a supplicant that is part of that OS, and which itself is exponentionally more work - and risk, both technical and legal - to requiring manual configuration. In the context of the original post, it=E2=80=99s about using a hammer as a screwdriver, when we all seemingly agree a screwdriver is the right tool. This is not about which department is involved. The distinction is about > the scope of trust. Saying shipped in the OS, both in the context of this > thread and more generally, is presuming a broad scope and maintained > interfaces for third-parties, neither of which you need. Not recognizing > that a =E2=80=9Croot store=E2=80=9D on a modern OS is merely an abstracti= on over disparate > trust bits is meaningful, particularly when not addressing what the =E2= =80=9Ctrust > bits=E2=80=9D should be or how they=E2=80=99re maintained. > > > And *that* is an artifact of the way vendors have chosen to ship their OS > products. I think what you=E2=80=99re saying is that large industry soft= ware > providers aren=E2=80=99t going to change their behavior just because it > inconveniences users (customers). > You=E2=80=99re right that organizations are not going to take on more techn= ical complexity, more security risk across their products, and more legal risk to the organization, =E2=80=9Cjust=E2=80=9D because some folks are inconven= ienced. Especially when that fraction of inconvenienced folk represent a remarkable minority of their user base. That=E2=80=99s why advocates _have_ to demonst= rate value AND demonstrate solutions that understands those complexities and risks and mitigates them appropriately. Ignoring those needs is bound to get half-assed solutions that get ignored. Maybe that=E2=80=99s true. However, it=E2=80=99s an organizational and imp= lementation > argument, not a technical one. > This isn=E2=80=99t correct either. The point - going back to the very origi= nal reply - is that the primary means of mitigating those risks and complexities is of a technical nature. It=E2=80=99s absolutely true that le= gal risks, for example, are not easily expressed as technical solutions, but this design and selection of root stores, and the risks involved, very much depends on technical decisions that are made. If folks want to ignore those concerns, it=E2=80=99s at their peril, but different technical decisions am= plify or mitigate those concerns. Hence, again, back to profiles and their corresponding policies. Sure. Standards are voluntary. All *good* standards start with clear and > accurate Use Cases and User Stories. The =E2=80=9Dusers=E2=80=9D have to= include > end-users, not just developers. Technical standards are successful when > they solve end-user, market driven problems. Standards that seek > (primarily or secondarily) to preserve =E2=80=9Cthe way we=E2=80=99ve alw= ays done it=E2=80=9D among > the vendor base, are not very useful, IMHO. > > Sure, but standards that exist to ignore the problems of constituents, and then lament no one adopts them, are not very useful. There isn=E2=80=99t disagreement on the benefit to users, but there=E2=80=99s clearly not an understanding how the entire discussion of PKI is a risk-shifting design, and has been since its very inception as a framework outside of the scope of X.500 DIT authorization. Standards that shift all risk onto the vendor are almost certainly doomed, even if it=E2=80=99s incredibly convenient for end-users to have someone el= se bear the burden. That=E2=80=99s why it=E2=80=99s essential for _good_ and _usefu= l_ standards to understand how the technical decisions affect the implementation risks and costs, so that they actually have a shot at adoption. If the rationale behind a standard is to write checks that get debited out of someone else= =E2=80=99s account, then it needs to be clearly documented for all stakeholders to see= . I=E2=80=99d like to avoid that scenario, which is why I keep trying to emph= asize designs that have a chance at achieving the end-goal, are incrementally deployable, and which can demonstrate real value to vendors. Trying to make it one size fits all, and with existing solutions, is simply doomed, if only because the market has realized the substantial and non-trivial hidden costs of that. Centralizing configuration, which the whole idea of a root store is about, centralizes risk, and it=E2=80=99s essential that the risk = be both managed and not bleed into unrelated areas if you want to convince vendors to take on that risk. --0000000000007c34e5059c962fcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 20, 2020 at 12:28 PM David B. Nelson <d.b.nelson@comcast.net> wrote:
On Jan 20, 2020, at 11:51 AM, Ryan Sleevi <= ryan-ietf@sleevi.= com> wrote:

=C2=A0 Whether we have to convince "the OS vendor", or just "= ;the supplicant division in the OS vendor" is largely the same thing.<= /blockquote>

It isn=E2=80=99t,= and there=E2=80=99s been zero evidence to support that conclusion, but I c= an tell reality isn=E2=80=99t that convincing :)

I have to disagree with that.=C2=A0 There are= exceptions to very rule, of course, but I have never downloaded, installed= and configured a supplicant on any of my computing devices.=C2=A0 I=E2=80= =99m a highly technical end-user (long time IETF and IEEE contributor).

Ho= w is this related? This isn=E2=80=99t about downloading third-party supplic= ant software, this is about scoping the problem and the solution. Shipping = as part of the OS, as a root store, is several magnitudes more work than sh= ipping as part of a supplicant that is part of that OS, and which itself is= exponentionally more work - and risk, both technical and legal - to requir= ing manual configuration.

In the context of the original post, it=E2=80=99s about using a hammer as= a screwdriver, when we all seemingly agree a screwdriver is the right tool= .

This is not = about which department is involved. The distinction is about the scope of t= rust. Saying shipped in the OS, both in the context of this thread and more= generally, is presuming a broad scope and maintained interfaces for third-= parties, neither of which you need. Not recognizing that a =E2=80=9Croot st= ore=E2=80=9D on a modern OS is merely an abstraction over disparate trust b= its is meaningful, particularly when not addressing what the =E2=80=9Ctrust= bits=E2=80=9D should be or how they=E2=80=99re maintained.

And *that* is an artifact of the way ven= dors have chosen to ship their OS products.=C2=A0 I think what you=E2=80=99= re saying is that large industry software providers aren=E2=80=99t going to= change their behavior just because it inconveniences users (customers). = =C2=A0

You=E2=80=99re right that organizations are not going to take on = more technical complexity, more security risk across their products, and mo= re legal risk to the organization, =E2=80=9Cjust=E2=80=9D because some folk= s are inconvenienced. Especially when that fraction of inconvenienced folk = represent a remarkable minority of their user base. That=E2=80=99s why advo= cates _have_ to demonstrate value AND demonstrate solutions that understand= s those complexities and risks and mitigates them appropriately. Ignoring t= hose needs is bound to get half-assed solutions that get ignored.

Maybe that=E2=80=99s= true.=C2=A0 However, it=E2=80=99s an organizational and implementation arg= ument, not a technical one.

This isn=E2=80=99t correct either. The point -= going back to the very original reply - is that the primary means of mitig= ating those risks and complexities is of a technical nature. It=E2=80=99s a= bsolutely true that legal risks, for example, are not easily expressed as t= echnical solutions, but this design and selection of root stores, and the r= isks involved, very much depends on technical decisions that are made. If f= olks want to ignore those concerns, it=E2=80=99s at their peril, but differ= ent technical decisions amplify or mitigate those concerns. Hence, again, b= ack to profiles and their corresponding policies.
Sure.=C2=A0 Standards are voluntary.=C2=A0 Al= l *good* standards start with clear and accurate Use Cases and User Stories= .=C2=A0 The =E2=80=9Dusers=E2=80=9D have to include end-users, not just dev= elopers. Technical standards are successful when they solve end-user, marke= t driven problems.=C2=A0 Standards that seek (primarily or secondarily) to = preserve =E2=80=9Cthe way we=E2=80=99ve always done it=E2=80=9D among the v= endor base, are not very useful, IMHO.
=

Sure, but standa= rds that exist to ignore the problems of constituents, and then lament no o= ne adopts them, are not very useful. There isn=E2=80=99t disagreement on th= e benefit to users, but there=E2=80=99s clearly not an understanding how th= e entire discussion of PKI is a risk-shifting design, and has been since it= s very inception as a framework outside of the scope of X.500 DIT authoriza= tion.

Standards that shi= ft all risk onto the vendor are almost certainly doomed, even if it=E2=80= =99s incredibly convenient for end-users to have someone else bear the burd= en. That=E2=80=99s why it=E2=80=99s essential for _good_ and _useful_ stand= ards to understand how the technical decisions affect the implementation ri= sks and costs, so that they actually have a shot at adoption. If the ration= ale behind a standard is to write checks that get debited out of someone el= se=E2=80=99s account, then it needs to be clearly documented for all stakeh= olders to see.

I=E2=80= =99d like to avoid that scenario, which is why I keep trying to emphasize d= esigns that have a chance at achieving the end-goal, are incrementally depl= oyable, and which can demonstrate real value to vendors. Trying to make it = one size fits all, and with existing solutions, is simply doomed, if only b= ecause the market has realized the substantial and non-trivial hidden costs= of that. Centralizing configuration, which the whole idea of a root store = is about, centralizes risk, and it=E2=80=99s essential that the risk be bot= h managed and not bleed into unrelated areas if you want to convince vendor= s to take on that risk.
--0000000000007c34e5059c962fcf-- From nobody Mon Jan 20 12:31:40 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F3312086C; Mon, 20 Jan 2020 12:31:28 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pYpGaR2oc-41; Mon, 20 Jan 2020 12:31:23 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E2312082A; Mon, 20 Jan 2020 12:31:22 -0800 (PST) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 7E481383F; Mon, 20 Jan 2020 20:31:18 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Mon, 20 Jan 2020 15:31:17 -0500 Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5D696B14-1C74-4073-8785-3515FFAEC2BA@deployingradius.com> References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 20:31:35 -0000 On Jan 20, 2020, at 11:51 AM, Ryan Sleevi wrote: > On Mon, Jan 20, 2020 at 11:19 AM Alan DeKok = wrote: > The distinction doesn't even matter in the content of root stores. = The vendor downloads N root CAs, and places them into files / DBs in the = product. Whether those files from from A and go to B, or come from C = and go to D is *entirely* irrelevant to the end product. Whether it's = Department A that downloads the roots CAs or Department B is also = irrelevant. >=20 > This is not at all how root stores work or have worked for ages, and I = suspect this lack of familiarity may be the cause of the significant = confusion demonstrated here. In a word: no. > There isn=E2=80=99t =E2=80=9Ca=E2=80=9D root store on any modern OS. = Even if you factor Linux with the LSB, there are multiple root stores. = Multiple independent root stores are maintained for separate purposes, = with their own policies and profiles, administered not only by different = parts of the organization, but also against different standards and with = different industry bodies. So in a message where I explicitly say that CAs go to multiple places, = your conclusion is that I believe there's only one root store? > This basic understanding of how modern PKI works is essential to = understanding how to make productive contributions in this space, = because it shapes how the profiles are developed, how the policies are = administered, and how one makes progress convincing the right = stakeholders of the vision. I could say the same thing about previous misconceptions in how EAP is = implemented. > Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? = You have paths forward. Cisco: yes. Jouni: No. wpa_supplicant / hostap is just a collection of source code in a git = tree. It includes no CAs. And if it did, people would ignore them. = Any open source author has minimal influence on how their end product is = used. I know this from 20+ years of experience. You seem to think you can convince me if you just repeat often enough = "but you can define your own CA!" I know this. I don't care. It's = irrelevant, for reasons I've explain. > When I do RADIUS stuff, I say "the vendor has to do X". It's never = been useful to say "Bob in engineering department X has to do it". The = distinction you're making is 100% irrelevant. >=20 > You=E2=80=99re confusing =E2=80=9Ceveryone at the vendor needs to move = their car=E2=80=9D with =E2=80=9CBob needs to move his car=E2=80=9D. = You=E2=80=99re doomed to failure if you keep insisting everyone at the = company needs to move their car, when all you need is Bob to move and = not block your car in. That is absolutely not the conclusion you can draw from what I said. = When I say "the customer sees one end product, and therefore I don't = care which group does the update", I do NOT mean "every individual = department which works on the OS has to be updated in order to get this = new EAP functionality". To be frank, this insinuation uncalled for. You're implying that I'm = an idiot who "keeps insisting everyone at the company needs to" do the = update. That is absolutely not true, and you should apologize for = saying something so outlandish. > The IETF primarily targets those developers, not the end-user, and = it=E2=80=99s essential to understand why and how it works to understand = what work is needed to make something similar for EAP.=20 In a word: no. In a longer phrase: you're essentially claiming that the entire IETF = process (which does NOT do this) is wrong, and doesn't work. Since we're not making progress, I'll stop. Alan DeKok. From nobody Mon Jan 20 13:03:58 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FDC12022C; Mon, 20 Jan 2020 13:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 fFc6dFZk0LhP; Mon, 20 Jan 2020 13:03:52 -0800 (PST) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1265312013D; Mon, 20 Jan 2020 13:03:52 -0800 (PST) Received: by mail-ed1-f47.google.com with SMTP id v28so787535edw.12; Mon, 20 Jan 2020 13:03:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=exFs/hxCNhwJTN+nFE60DnmyJFs+mZXSWea051+e2gA=; b=I+KurPEbmWBE8P+Iq2DOZsgC09HPEgmjfz2Qt/YFMI7vsgmq7V1CfOPLDtSJwQdF4E qmmuObvx1s7PH/CzyVKIS613OQraFh2KhDXQxWTygHyaW2P8HU8utmbcXDjA1NMP4LTV dmwa9bq65XhobolkxKTWZ/bdu3HuQgF4DLtJsrLXGqqlHXF1sOvtFiHcEms8VQs+dBb7 uRLmP4Tky/NwiQeVI7PeiYHCuqsa7V8NbxYeXI0+PsLF37ntDxyHaYzYjtGKWWVAS4OA CsGQRUY0Rdw/iniFzvCJ6f4daJDNZS1N0QYTCBrZxozfAKhb0+98qESLBFP+Nju/cPPC /jLw== X-Gm-Message-State: APjAAAWKeVftkm9QGnsy+tNdiG84m9TB9tRWnTMHDvUZYyU+Pid+USlQ 6OND5GU5CTkACdkOtu/pruf7ptEy X-Google-Smtp-Source: APXvYqz3rQAyIwI5JdI8Wptrfz/u5KVsE7mLKInfcGoSZMaRwuT849lxJW6oWQgjM0duhcpLmAWXKw== X-Received: by 2002:a50:f982:: with SMTP id q2mr963986edn.55.1579554230254; Mon, 20 Jan 2020 13:03:50 -0800 (PST) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com. [209.85.128.53]) by smtp.gmail.com with ESMTPSA id j3sm1370597edb.50.2020.01.20.13.03.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2020 13:03:50 -0800 (PST) Received: by mail-wm1-f53.google.com with SMTP id p17so793996wma.1; Mon, 20 Jan 2020 13:03:49 -0800 (PST) X-Received: by 2002:a1c:9c4c:: with SMTP id f73mr639445wme.125.1579554229631; Mon, 20 Jan 2020 13:03:49 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <4B648503-5B4D-4512-8692-94820388B894@deployingradius.com> <5D696B14-1C74-4073-8785-3515FFAEC2BA@deployingradius.com> In-Reply-To: <5D696B14-1C74-4073-8785-3515FFAEC2BA@deployingradius.com> From: Ryan Sleevi Date: Mon, 20 Jan 2020 15:58:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan DeKok Cc: Benjamin Kaduk , EMU WG , Joseph Salowey , Michael Richardson , "Owen Friel (ofriel)" , Ryan Sleevi , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c2c0ef059c98a0bd" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 21:03:57 -0000 --000000000000c2c0ef059c98a0bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2020 at 3:31 PM Alan DeKok wrote: > > Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? You > have paths forward. > > Cisco: yes. Jouni: No. > > wpa_supplicant / hostap is just a collection of source code in a git > tree. It includes no CAs. And if it did, people would ignore them. Any > open source author has minimal influence on how their end product is used= . > I know this from 20+ years of experience. I=E2=80=99m afraid this is quite disconnected from reality, then. The premi= ere root store on more devices than any other is the Mozilla Root Store, developed as part of the open-source NSS package, shipped in virtually every mainstream Linux/BSD distro, and used in wide swaths beside that (e.g. curl, server programming languages, IoT, cars, thermostats) The decisions made by Mozilla - to add or remove CAs for given purposes, like TLS or S/MIME - reverberate on a host of ecosystems, for better and for worse. The reason for that adoption is on the strength of the profiles and policies, and addressing a real need, which are the things not being addressed here for EAP. There=E2=80=99s nothing that prevents a =E2=80=9CLike-Mozilla-but-for-EAP= =E2=80=9D root store being developed. Like all root stores, it requires defining your profiles for how the information is expressed, the practices for how clients validate and use that information, and the policies for how CAs appropriately vet and validate that information. The first two - profiles and practices - are excellent candidates for standardization efforts. The latter, policies, is as the name suggests, more about policy and left to industry efforts. The technical decisions in the profiles and practices affect the policies - some decisions create more work, some less, such as the discussions around EKUs. The choice to implement, as an OS/supplicant vendor, is about evaluating the risk of the policies. How much do the technical decisions expose users to risk vs mitigate risks of misconfiguration? How can those policies be customized or adjusted to the needs of the vendor, and what interoperability risks exist when they are so customized? If you=E2=80=99re= talking PKI, it=E2=80=99s inherently risk management, which is managing the policie= s to support the technologies. We generally don=E2=80=99t hear, for example, the SSH community remarking o= n a lack of an out-of-the-box PKI that just works for all their hosts. That=E2=80=99= s because the policies, and the needs of constituents, aren=E2=80=99t really = aligned with that sort of global model. Local PKIs - whether TOFU or local SSH PKIs - better balance the risk. Today, that calculus is largely true for EAP, at least from the POV of supplicant implementors. If you want to convince otherwise, it=E2=80=99s about defining those profiles and policies that can= show that different calculus. That is absolutely not the conclusion you can draw from what I said. > When I say "the customer sees one end product, and therefore I don't care > which group does the update", I do NOT mean "every individual department > which works on the OS has to be updated in order to get this new EAP > functionality". This is not what I said either. The notion of =E2=80=9Cadd to the OS root store=E2=80=9D has impact on ever= y OS component, which needs to be evaluated holistically. The decision _impacts_ them, from a risk management standpoint, even when it doesn=E2=80=99t need to and shou= ldn=E2=80=99t. That=E2=80=99s everyone having to move their car, or asking for $10 million= . You don=E2=80=99t need impact on every OS component. You only care about EA= P, clearly. Thats why it=E2=80=99s important to be precise on what is needed - something _just_ for EAP. That=E2=80=99s only needing Bob to move his car, = or asking for $10. So when talking about what this hypothetical root store should be, it needs to be clear that it=E2=80=99s only for EAP, and saying =E2=80=9Cadded to th= e OS=E2=80=9D is far more than EAP, with far more impact than needed or intended. It leads to confusion, such as in the original message, around concepts like =E2=80=9Cp= ublic CAs=E2=80=9D, which only hurts the conversation. Plenty of folks have been confused, for example, ingesting the Mozilla source files without realizing it is three separate root stores, each with their own policies, management, and constraints, some of which are not expressed purely in a single file. That this happens often, or messages like Owen highlight =E2=80=9Cpublic CA= s=E2=80=9D without qualification, are the same reason it=E2=80=99s important to be cle= ar we=E2=80=99re talking about a _new_ root store for a _new_ purpose, and thus nothing extant has any bearing whatsoever on this store. --000000000000c2c0ef059c98a0bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 20, 2020 at 3:31 PM Alan DeKok <aland@deployingradius.com> wrote:
> Is Cisco a supplicant vendor? Is Jouni Malinen a supplicant vendor? Yo= u have paths forward.

=C2=A0 Cisco: yes.=C2=A0 Jouni: No.

=C2=A0 wpa_supplicant / hostap is just a collection of source code in a git= tree.=C2=A0 It includes no CAs.=C2=A0 And if it did, people would ignore t= hem.=C2=A0 Any open source author has minimal influence on how their end pr= oduct is used.=C2=A0 I know this from 20+ years of experience.
=

I=E2=80=99m afraid this is qu= ite disconnected from reality, then. The premiere root store on more device= s than any other is the Mozilla Root Store, developed as part of the open-s= ource NSS package, shipped in virtually every mainstream Linux/BSD distro, = and used in wide swaths beside that (e.g. curl, server programming language= s, IoT, cars, thermostats)

The decisions made by Mozilla - to add or remove CAs for given purposes,= like TLS or S/MIME - reverberate on a host of ecosystems, for better and f= or worse. The reason for that adoption is on the strength of the profiles a= nd policies, and addressing a real need, which are the things not being add= ressed here for EAP.

The= re=E2=80=99s nothing that prevents a =E2=80=9CLike-Mozilla-but-for-EAP=E2= =80=9D root store being developed. Like all root stores, it requires defini= ng your profiles for how the information is expressed, the practices for ho= w clients validate and use that information, and the policies for how CAs a= ppropriately vet and validate that information. The first two - profiles an= d practices - are excellent candidates for standardization efforts. The lat= ter, policies, is as the name suggests, more about policy and left to indus= try efforts. The technical decisions in the profiles and practices affect t= he policies - some decisions create more work, some less, such as the discu= ssions around EKUs.

The = choice to implement, as an OS/supplicant vendor, is about evaluating the ri= sk of the policies. How much do the technical decisions expose users to ris= k vs mitigate risks of misconfiguration? How can those policies be customiz= ed or adjusted to the needs of the vendor, and what interoperability risks = exist when they are so customized? If you=E2=80=99re talking PKI, it=E2=80= =99s inherently risk management, which is managing the policies to support = the technologies.

We gen= erally don=E2=80=99t hear, for example, the SSH community remarking on a la= ck of an out-of-the-box PKI that just works for all their hosts. That=E2=80= =99s because the policies, and the needs of constituents, aren=E2=80=99t re= ally aligned with that sort of global model. Local PKIs - whether TOFU or l= ocal SSH PKIs - better balance the risk. Today, that calculus is largely tr= ue for EAP, at least from the POV of supplicant implementors. If you want t= o convince otherwise, it=E2=80=99s about defining those profiles and polici= es that can show that different calculus.

=
=C2=A0 That is absolutely not the conclusion you can draw from what I said.= =C2=A0 When I say "the customer sees one end product, and therefore I = don't care which group does the update", I do NOT mean "every= individual department which works on the OS has to be updated in order to = get this new EAP functionality".

This is not what I said either.

The notion of =E2=80=9Cadd to the OS root stor= e=E2=80=9D has impact on every OS component, which needs to be evaluated ho= listically. The decision _impacts_ them, from a risk management standpoint,= even when it doesn=E2=80=99t need to and shouldn=E2=80=99t. That=E2=80=99s= everyone having to move their car, or asking for $10 million.

You don=E2=80=99t need impact on eve= ry OS component. You only care about EAP, clearly. Thats why it=E2=80=99s i= mportant to be precise on what is needed - something _just_ for EAP. That= =E2=80=99s only needing Bob to move his car, or asking for $10.

So when talking about what this hyp= othetical root store should be, it needs to be clear that it=E2=80=99s only= for EAP, and saying =E2=80=9Cadded to the OS=E2=80=9D is far more than EAP= , with far more impact than needed or intended. It leads to confusion, such= as in the original message, around concepts like =E2=80=9Cpublic CAs=E2=80= =9D, which only hurts the conversation. Plenty of folks have been confused,= for example, ingesting the Mozilla source files without realizing it is th= ree separate root stores, each with their own policies, management, and con= straints, some of which are not expressed purely in a single file. That thi= s happens often, or messages like Owen highlight =E2=80=9Cpublic CAs=E2=80= =9D without qualification, are the same reason it=E2=80=99s important to be= clear we=E2=80=99re talking about a _new_ root store for a _new_ purpose, = and thus nothing extant has any bearing whatsoever on this store.
--000000000000c2c0ef059c98a0bd-- From nobody Mon Jan 20 14:44:56 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAE6120045; Mon, 20 Jan 2020 14:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 0a1GYliVjVwP; Mon, 20 Jan 2020 14:44:52 -0800 (PST) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9EF120018; Mon, 20 Jan 2020 14:44:52 -0800 (PST) Received: by mail-oi1-f178.google.com with SMTP id i1so814365oie.8; Mon, 20 Jan 2020 14:44:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=22S+HhUj+r326LtAsIYdTCYY+iEvIaxXDExhRnccdXE=; b=tguf8gWWFafblKP/RQXlhA8AyCAK5cL5FyT+cndx/6AkTyax17v0hxwnfUgQ6Qs+Ea HeuqGSLULvVlKFFg+8Tv95Y7s6iOueHrfT85HY/1yyGr+OKvY+ntMKrnB8iu3UUsAeG+ bQJPfM/F9i9N+KE9YVQyjommR2w2WUAbUPeXBshNxYyUbals3qAI0LKJ8xMDvcH/0nFJ t5DbiW+FsptFLu0l09U7dnhSgcji4n179GeNLZKSxKKbBfPiauqRHHVpiwfoiWPZ29m2 uOhayNLhPHabKZeY8t9pSNm86Lh3pzdj4iI7snqGcjBAmsxcq828Fgc4BWaP8GLM/j01 ZpQw== X-Gm-Message-State: APjAAAX2Va/kC0JC/AxOJvZPok9D/dwGoJS+JwfEGNgqpnudTGtJqgTy nBAbesaEjFl+AH4cbpuYEC8XPRuLgPII135fUadBKqZB X-Google-Smtp-Source: APXvYqz1UxqYSKs86sqrQwC1cb2Nxbl0j//MoRySxh5tRrAsbJ3A0lx4Fa/Vn8PUqfdIZtVOZ2qz6w514/8PFkb6eoM= X-Received: by 2002:aca:3241:: with SMTP id y62mr843463oiy.31.1579560291134; Mon, 20 Jan 2020 14:44:51 -0800 (PST) MIME-Version: 1.0 References: <6CEB4C89-B749-4A65-A25A-A12830ED8A62@deployingradius.com> <00453E78-D991-4B4D-A138-5788FACC47C2@deployingradius.com> <316CC74D-667B-4A1E-AD48-A702DF705423@deployingradius.com> <6191.1578513600@localhost> <20200116040715.GC80030@kduck.mit.edu> <55CE7F32-B5DE-44F5-AE06-72BE12FA05FF@deployingradius.com> <7F591857-4B7B-41BD-B101-6C40BE527644@deployingradius.com> <9AADAAD6-0A66-4198-AFBF-DBC2D87DBFA0@deployingradius.com> <07C710A5-3B2A-4D15-8BB7-AB5A8B5EF5D1@deployingradius.com> <7C85D468-1D28-4C3A-BC3E-C42374933B51@deployingradius.com> <5ED33CB8-4C56-4117-A001-C2EB056CA80B@deployingradius.com> <22430B86-2680-4E50-AF12-A200FD051E8D@deployingradius.com> <5879.1579540931@localhost> In-Reply-To: <5879.1579540931@localhost> From: Phillip Hallam-Baker Date: Mon, 20 Jan 2020 17:44:39 -0500 Message-ID: To: Michael Richardson Cc: EMU WG , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000df123059c9a0aaf" Archived-At: Subject: Re: [lamps] [Emu] EAP/EMU recommendations for client cert validation logic X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 22:44:54 -0000 --0000000000000df123059c9a0aaf Content-Type: text/plain; charset="UTF-8" On Mon, Jan 20, 2020 at 12:22 PM Michael Richardson wrote: > > Alan DeKok wrote: > > While, there are commercial supplicant products, these products are > > overwhelmingly used by the enterprise, on computers owned by the > > enterprise, and managed by the enterprise systems. They have zero > > impact on the average user. > > Today. > But, since a goal here was for IoT devices, this changes things: > > 1) Enterprises want to manage IoT device onboarding, and they > overwhelmingly > want to use EAP/1x. > > 2) IoT devices don't have users and can't even load a non-standard XML > configuration. > I think it best that we focus on meeting the needs of customers rather than engaging in the spec lawyer-ing seen earlier in the thread. We already have the EU and the US House and Senate looking at the PKI world as one example of what they believe to be a 'Big Tech' agenda set against the little guy. And not just on the left. Most of the people I have been talking to are Republicans or staffers thereof. So no, let us not suggest that we can find some wording in some CA's CPS that enables us to force them to revoke certificates that are clearly not being abused. And certainly not on the basis of some arbitrary interpretation of a CPS. Such would likely prove a career-limiting move. Let us instead focus on the onboarding problem Michael poses, because that goes to the heart of the matter in my view. Enterprises want to onboard devices with as little manual intervention as is possible. They are currently using the WebPKI roots of trust because that is expedient. This exposes them to real risks which is precisely the reason why the product that was the focus of much of my early VeriSign work was OnSite which is designed to provide enterprises with their own separate PKI for their exclusive use. The reason I have been delving into threshold cryptography and writing the Mathematical Mesh is precisely to support that set of use cases for both personal and enterprise use. What I call connecting a device to a personal Mesh is essentially a PKI driven onboarding process in which the device may be connected by means of one of the following types of identifier * Unique device ID passed to the customer during procurement (most enterprise suppliers provide MAC addresses of the devices that are shipped.) * QR Code printed on the device during manufacture, scanned by customer. * Ad hoc credentials generated by customer-installed application. The device that is onboarded acquires: 1) The ultimate root of trust for that connection context 2) A set of device keys for Encryption, Authentication and Signature to use within that connection context 3) A connection statement credentialing the device keys under the connection context The use of threshold techniques allows the usual concerns about use of manufacturer provided vs centrally generated key pairs to be finessed by providing all the advantages of both. The disadvantages only appear if both the admin device and the device being connected are compromised by the same party. The reason I have moved to a new syntax for this PKI (JSON) is that in my trust model, every user, every enterprise is their own root of trust. It is much easier to design a completely new PKI than to attempt to impose that restriction on PKIX or SAML. I can easily spit out X.509 certs as needed but these are products of the enterprise PKI, they are not the primary accreditation trust path. The traditional approach used to engineer this in OnSite is about as well as can be achieved using 1990s technology when the machines were severely limited in their CPU capabilities and processing RSA path math took seconds. Automating the device and service management processes is a necessary precondition for using client side PKI, and security policy and thus making effective use of DNSSEC. The key difference in my new approach is that under the OnSite approach, enterprises that outsourced their PKI to VRSN were handing over the keys to their kingdom. Using threshold, that is no longer necessary. --0000000000000df123059c9a0aaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 20, 2020 at 12:22 PM Michael Richardson= <mcr+ietf@= sandelman.ca> wrote:

Alan DeKok <aland@deployingradius.com> wrote:
=C2=A0 =C2=A0 > While, there are commercial supplicant products, these p= roducts are
=C2=A0 =C2=A0 > overwhelmingly used by the enterprise, on computers owne= d by the
=C2=A0 =C2=A0 > enterprise, and managed by the enterprise systems.=C2=A0= They have zero
=C2=A0 =C2=A0 > impact on the average user.

Today.
But, since a goal here was for IoT devices, this changes things:

1) Enterprises want to manage IoT device onboarding, and they overwhelmingl= y
=C2=A0 =C2=A0want to use EAP/1x.

2) IoT devices don't have users and can't even load a non-standard = XML
=C2=A0 =C2=A0configuration.

I think it best that we focus = on meeting the needs of customers rather than engaging in the spec lawyer-i= ng seen earlier in the thread.

We already have the EU and the US House and Senate looking at the PKI= world as one example of what they believe to be a 'Big Tech' agend= a set against the little guy. And not just on the left. Most of the people = I have been talking to are Republicans or staffers thereof.

So no, let us not suggest that we can fi= nd some wording in some CA's CPS that enables us to force them to revok= e certificates that are clearly not being abused. And certainly not on the = basis of some arbitrary interpretation of a CPS. Such would likely prove a = career-limiting move.

Let us instea= d focus on the onboarding problem Michael poses, because that goes to the h= eart of the matter in my view. Enterprises want to onboard devices with as = little manual intervention as is possible. They are currently using the Web= PKI roots of trust because that is expedient. This exposes them to real ris= ks which is precisely the reason why the product that was the focus of much= of my early VeriSign work was OnSite which is designed to provide enterpri= ses with their own separate PKI for their exclusive use.

The reason I have been delving= into threshold cryptography and writing the Mathematical Mesh is precisely= to support that set of use cases for both personal and enterprise use. Wha= t I call connecting a device to a personal Mesh is essentially a PKI driven= onboarding process in which the device may be connected by means of one of= the following types of identifier

* Unique device ID passed to the customer during procurement (mo= st enterprise suppliers provide MAC addresses of the devices that are shipp= ed.)

=
* QR Code printed on= the device during manufacture, scanned by customer.

* Ad hoc credentials generated by customer-inst= alled application.

The de= vice that is onboarded acquires:

1) The ultimate root of trust for that connection context
2)=C2=A0 A set of device= keys for Encryption, Authentication and Signature to use within=20 that connection context
3) A connection statement credentialing the device keys under th= e connection context

The use of threshold techniques allows the = usual concerns about use of manufacturer provided vs centrally generated ke= y pairs to be finessed by providing all the advantages of both. The disadva= ntages only appear if both the admin device and the device being connected = are compromised by the same party.


The reason I have moved to a n= ew syntax for this PKI (JSON) is that in my trust model, every user, every = enterprise is their own root of trust. It is much easier to design a comple= tely new PKI than to attempt to impose that restriction on PKIX or SAML. I = can easily spit out X.509 certs as needed but these are products of the ent= erprise PKI, they are not the primary accreditation trust path.

The traditional approach used to eng= ineer this in OnSite is about as well as can be achieved using 1990s techno= logy when the machines were severely limited in their CPU capabilities and = processing RSA path math took seconds.


Automating the device and service management processes is a necess= ary precondition for using client side PKI, and security policy and thus ma= king effective use of DNSSEC.

The key difference in my new approach is that= under the OnSite approach, enterprises that outsourced their PKI to VRSN w= ere handing over the keys to their kingdom. Using threshold, that is no lon= ger necessary.
=

--0000000000000df123059c9a0aaf-- From nobody Tue Jan 21 02:40:18 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3D12085B for ; Tue, 21 Jan 2020 02:40:16 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=SIz3L1ia; dkim=pass (1024-bit key) header.d=digicert.com header.b=FzLeLieu 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 I1uD3O8ZvjJK for ; Tue, 21 Jan 2020 02:40:14 -0800 (PST) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1686112083A for ; Tue, 21 Jan 2020 02:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1579603212; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eyDX864L8oY+no2HjToFN564EiBLVpVrGzBOxu+cKSM=; b=SIz3L1ia7uNyN9qoTjEQmTYinl8jp8Q44CQbRpzuK702BySJ/l/7MuaSfrBfzjSSUx7zph nvD0DxbAZ0c653ePGuOUZ5G3KUbFOR7AERKGC8w/irSUnTCgLKhtZSFD2mXgTM8/WuJz+w 1CymIfE/RZDxmmQ2b88OG1cSBceTOU0= Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-321-3zgqhm_sPk6dx_XrDgYVbA-1; Tue, 21 Jan 2020 05:40:11 -0500 X-MC-Unique: 3zgqhm_sPk6dx_XrDgYVbA-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cEecWgNOX4ZCzpVF/2sYn2ct3+5C3YmR4BMxqfVz74uZISctafERkmdAEVHAFJFVnKNZfF4otqEGqXJrcIiBi0WyvS2Y0azkzRphza5rbgdJu2vfEYpFGZW2CaLPYCjqYSrT8vp/yQAy6B8+wggSj0968XJjPFRZEHht27IPzy8IJIClgLIrl2OW5lvKe6QFn4xIKf11xo/xbZqvnTkCwUM2YTGN4efmMw4H3fkjjZ+SOlC2wP+1xscpmSKwr2u1cWicnjyxYp7QQ5gQYMrDueMNBdhII2I02DdIVm5pHY9vH8kymWchVTnaMt2COPst9Z4oVV7JuRjXKJ/niLeeBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eyDX864L8oY+no2HjToFN564EiBLVpVrGzBOxu+cKSM=; b=fG6JactXX53hNrLHbji3d87aFwJldZl5g30MAD5iUMa4CE24sHSHR4FxLDNHvMu08e83jEZGlCoB5dpO76BSbyt7vMw0mihuTc2+HwqXlKPB4vsDCyia5VjcaCOJ7o6xVQFnOUeijaVV4O1k/IPd4Fa/57VP0/8PYxCIBmbqCwkxWDMnGydxqqqAa+yqT8bQtqD1nzddSWXxwD3g0Iy1Udbre3jo+kIpRMawyt3VNSYQuq2jzv43cfCtinyKp6d47SCWkLowHp7gnA7S/17vu8xsO+APPUrKoifFjzrlFOUiZjUZ6kLWH6aczErXiWQ1qP+WE41VveAOYxTVY2Xs3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eyDX864L8oY+no2HjToFN564EiBLVpVrGzBOxu+cKSM=; b=FzLeLieuyGuk8Q12SlMv1vzsFF9MsHmpOHuYRwOzNgGrxwo8V4vU8yOK4hJMXDcjY+lKuBbMUECOF54BSTuqo+SIFjfsqvZ4xurh/hO6BeExnvkZnxRsyOxIezjZf4tv+Intk0A3lK7SjsXrC8l9+4z/kKTL5qI0xJIJzjXqzuY= Received: from BN8PR14MB3059.namprd14.prod.outlook.com (20.179.138.155) by BN8PR14MB3329.namprd14.prod.outlook.com (10.255.235.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Tue, 21 Jan 2020 10:40:08 +0000 Received: from BN8PR14MB3059.namprd14.prod.outlook.com ([fe80::1c00:c58b:a419:ebe5]) by BN8PR14MB3059.namprd14.prod.outlook.com ([fe80::1c00:c58b:a419:ebe5%7]) with mapi id 15.20.2644.027; Tue, 21 Jan 2020 10:40:08 +0000 From: Tim Hollebeek To: SPASM Thread-Topic: Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect Thread-Index: AdW3SgT7TzvannoqRPuIFXJ92Hzy6QY/Nv9Q Date: Tue, 21 Jan 2020 10:40:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [195.238.226.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89b34c53-e89b-4bd1-3600-08d79e5e4931 x-ms-traffictypediagnostic: BN8PR14MB3329: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(39850400004)(346002)(136003)(199004)(189003)(81156014)(86362001)(44832011)(66946007)(66476007)(316002)(66446008)(9686003)(66556008)(66616009)(76116006)(64756008)(478600001)(8676002)(33656002)(71200400001)(52536014)(2906002)(53546011)(6916009)(6506007)(4744005)(55016002)(8936002)(15650500001)(186003)(81166006)(5660300002)(26005)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR14MB3329; H:BN8PR14MB3059.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LcM7NQQbAPstvV7RIYc4Acv/wcPAVMv01U1qdYWGaFWYxmQ4Q2FfFhazGDGyVgVcGsiTnWK/BYP76YdGzQZI15ggm/AMnd70dq/KV+FtYz1q/+j6KI664ED0VW16qYkB1oFTluHzvHHSmHP1tPWVn4w0aCY5937ujXecwH9pXeMBVQW2RdONLaLc2K9cpKwaET4vOlL9v6tys0lotZDBIdI2MQ8gnUXxdYi1Pl0k6pPLpkk57mB7RAi51k+rJ677OA8G9Uam6casN0+XSbIvNY7N+zRaomhbE4qxdlCiCw+xdFGB9Wd5hJlgdWD9SigS9eGBMy8yzp0Lvsj8vRqPbiK8Jj54zP6fG6jsnG7b7E3wTtQv1pcJyw7qjzSRPFqg60cVctzJAd/veWxnALAJ/dLAWxPP0f6crIRpDcfRce9FmmbHCPqkjauZtcM04FCF x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CF_01D5D04F.7AA7D1B0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89b34c53-e89b-4bd1-3600-08d79e5e4931 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 10:40:08.7341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1l+ozK++4ogLNFfDnPmhA0y7Ve7Vx22+VpER32mh+YM9Rp+aT5C6Df5uM9hWC/r0sY0xm3ZkUfFZIXj27nb8aCP3SaWgJl6oKXM0X5MNxcM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR14MB3329 Archived-At: Subject: Re: [lamps] Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 10:40:17 -0000 ------=_NextPart_000_00CF_01D5D04F.7AA7D1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D0_01D5D04F.7AA7D1B0" ------=_NextPart_001_00D0_01D5D04F.7AA7D1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There appears to be widespread support for adoption of this draft and no opposition. Furthermore, several members are willing to review the document. I'll update the status as adopted. -Tim From: Tim Hollebeek Sent: Friday, December 20, 2019 4:29 PM To: SPASM Subject: Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect Please indicate whether you support adoption of Call for Adoption of draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January 17th. -Tim ------=_NextPart_001_00D0_01D5D04F.7AA7D1B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There appears to be widespread support for adoption of = this draft and no opposition.  Furthermore, several members are = willing to review the document.  I’ll update the status as = adopted.

 

-Tim

 

From: Tim = Hollebeek
Sent: Friday, December 20, 2019 4:29 = PM
To: SPASM <spasm@ietf.org>
Subject: Call = for Adoption of = draft-housley-lamps-cms-update-alg-id-protect

<= p class=3DMsoNormal> 

 

Please = indicate whether you support adoption of Call for Adoption of = draft-housley-lamps-cms-update-alg-id-protect by the LAMPS WG by January = 17th.

 

-Tim

------=_NextPart_001_00D0_01D5D04F.7AA7D1B0-- ------=_NextPart_000_00CF_01D5D04F.7AA7D1B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPSzCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggU6MIIEIqADAgECAhAOLtaO DEKPFOthtF40d6wTMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQTAeFw0xNzExMjgwMDAwMDBaFw0yMjAyMjUxMjAwMDBaMFYxCzAJBgNV BAYTAlVTMQ0wCwYDVQQIEwRVdGFoMQ0wCwYDVQQHEwRMZWhpMREwDwYDVQQKEwhEaWdpQ2VydDEW MBQGA1UEAxMNVGltIEhvbGxlYmVlazCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMpR MhL0Xd3sJ+QKOx/ibLbylihkkOQQCJdWoY/iPNsWSzNRA19bc9ikVSjUacpDKSX+0zSqfPDTlt9U ujX5x7R71/IDBh+6Wv4doBUI+rH49nD0INjpzQ1h3sVztLSxw43Ep6Q0XirWZS5x8a4ZqlawSzKL HQK5HQ0y4ngj7Dyoyf0zOPMjtu924b65UuZkiLSnoPz7ZHkE5AXLS1V5D9ot9L3V8bUNNgViQ8X5 r/omUXHPLA/MK2HwpbY+jjDwmpBa1qb8AMquAxo6cQmz1yx59Nb8VZEN4ZCTm3eufJLX0U9B+nI8 9q7gKEHnGiR9FyDdUTCp86ggh7GNSFljlf0CAwEAAaOCAfMwggHvMB8GA1UdIwQYMBaAFOcCI4AA T9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBSOoGF/cZwFXpgZhKanaJLhaL/c3jAMBgNVHRMBAf8E AjAAMCUGA1UdEQQeMByBGnRpbS5ob2xsZWJlZWtAZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEC MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCY4vD35xUwefy0nSTvptoJ 8VnCS9+/FICUJej4Vyy/nn+iDRXTrlGlvge9VOLR7SooIxsHFzvU1bGEy8oke36x9KZVq1eYA480 NG+1W8kGRx3Ru/My63+veelCqzXB7Mcu0Cr4yVBkOOCIkH4OQ1uWeemHMRBKnur/gr2gyg8pWJHE G/7+Sx4DwY5+EdToRWZ673FCsGp7EfUM9StRIak0YPK+1RpT5sHLwrPaFB867p//vfAupTF7nzcL 3LYaqfXEIHvvI/FepFIstELoVutOglsqIVhAnjOdlnKE9gkcvRI6lbJd9Uqng8Q7ngD/GvmhXI+E RCE61qyghEIu0dmvMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsF ADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1 MTIwMDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFz c3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRst BYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW 8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N /17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT 5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGw kp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB /wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0 LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGz BgNVHSAEggGqMIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy5kaWdpY2VydC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAA bwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0 AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIA dAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0 AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIA aQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsF AAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8 Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNo e82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m 7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+ q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCA68wggOrAgEBMHkwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMAkG BSsOAwIaBQCgggILMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIw MDEyMTEwMzk0NVowIwYJKoZIhvcNAQkEMRYEFFb2LtY0Ai3aShFOljKJ78Ts/pw9MIGIBgkrBgEE AYI3EAQxezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQ Di7WjgxCjxTrYbReNHesEzCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHesEzCBkwYJKoZIhvcNAQkP MYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjAHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASCAQCr+4tDj1CFKYz3RCN0zwez 80d/17SWKBh8Q65LrKsHq0NOSzG091iaV7/JHXIfIFyTwJmBm6E5dIDD3mZsvnd5WKhlJmoTHday ZYLa2ENkNAmF4TNpVODXc+x4+XJdCjDgZN93/ke16aLOSa6CtGU8uAkUT0PP0JUrWODTrE1Z4mFy abMtqyLpySbFuoj2II/CPRtp1YRzGreR4VU2EAYHEEQnMecgquESNgxT9QFIp+2hIG+p3TJb2IUK Q+xSj0VuW4OH6ixArSwUYGJ4iDv/ZPkLMlLDq57QgMZjGeXvrc4MMbBr1f/vzZep7hJ/D3lAEAuG CXHSzm+Tn7MIhivtAAAAAAAA ------=_NextPart_000_00CF_01D5D04F.7AA7D1B0-- From nobody Tue Jan 21 11:12:35 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D285112097E for ; Tue, 21 Jan 2020 11:12:33 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 qMDwkVn4TKeB for ; Tue, 21 Jan 2020 11:12:28 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7887E120990 for ; Tue, 21 Jan 2020 11:12:28 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00LJ91OX012244 for ; Tue, 21 Jan 2020 19:12:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=eWx3+iulDd0M/A4BE3BP/kLaHkEGvAUaXXXOcEHtFAg=; b=WJ3i262hDAxvJVt3Ps5u2NvHnqryPW2wVVZKc7D+duu1zjLY85/QVyqGXwr7dB9ruOQ5 cwd70gxkruulaZ01Kl68hAA4mjRCVwFKOIIT94ksdXpLh45UZsknocyWRxxKw4VC4b7M FGSf9BaUEH1vOwJsS+yoOfKhxhm3Hf5+y8cbzPvdsgdnrpCEgLKI3w800gSaCcdhQoEE 2HiZJHgBV4UHx9dowD3q0VqtnmNn+pV3YRHDVQxQudL3Wlwbv86MY1JK3uXFlvfFzeug lUe9zR3VX8P52X5YboewN8Bkby3tt7sLI67vdqcBTxlBeczS/QDCRyAHKWSZIo2vqvkg sw== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2xkyudayac-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 Jan 2020 19:12:27 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 00LJ6Xt2003291 for ; Tue, 21 Jan 2020 14:12:26 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint6.akamai.com with ESMTP id 2xkx7yc40r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 21 Jan 2020 14:12:26 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 21 Jan 2020 14:12:25 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 21 Jan 2020 14:12:25 -0500 From: "Salz, Rich" To: "spasm@ietf.org" Thread-Topic: Comment on "backward compatibility" section of draft-housley-lamps-cms-update-alg-id-protect Thread-Index: AQHV0I63ssuo8SBdzk+VJ7tAHJulsw== Date: Tue, 21 Jan 2020 19:12:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.225] Content-Type: multipart/alternative; boundary="_000_FD980DBB9D35479886D197ED2A5662ABakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-21_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001210143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.634 definitions=2020-01-21_06:2020-01-21, 2020-01-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 bulkscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001210143 Archived-At: Subject: [lamps] Comment on "backward compatibility" section of draft-housley-lamps-cms-update-alg-id-protect X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 19:12:34 -0000 --_000_FD980DBB9D35479886D197ED2A5662ABakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVzcG9uZGluZyB0byBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaG91c2xleS1s YW1wcy1jbXMtdXBkYXRlLWFsZy1pZC1wcm90ZWN0LTAwI3NlY3Rpb24tMy40DQoNCk9wZW5TU0wg aW5jbHVkZXMgYSBDTVMgQVBJIGFuZCBjb21tYW5kLWxpbmUgcHJvZ3JhbS4gIFRoZSBjb21tYW5k LWxpbmUgcHJvZ3JhbSBkb2VzIE5PVCBhbGxvdyBkaWZmZXJlbnQgZGlnZXN0cyB0byBiZSB1c2Vk IGZvciBjb250ZW50IGFuZCBzaWduZWQgYXR0cmlidXRlcywgYW5kIG5vYm9keSBzZWVtcyB0byBo YXZlIGV2ZXIgcmVxdWVzdGVkIHN1cHBvcnQgZm9yIGl0LiAgV2hpbGUgSSBoYXZlbuKAmXQgZm9s bG93ZWQgdGhlIEFQSSBhbGwgdGhlIHdheSB0aHJvdWdoLCBpdCBzZWVtcyB0aGF0IHRoZSBBUEkg ZG9lc27igJl0IGFsbG93IHRoaXMgZWl0aGVyIGFzIGl0IG9ubHkgYXNzb2NpYXRlcyBvbmUg4oCc WC41MDnigJ0gc2lnbmluZyBvYmplY3QgcGVyIENNUyBvYmplY3QuDQoNCg0K --_000_FD980DBB9D35479886D197ED2A5662ABakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <5035DD9886E45043BDD1941EA64CD4C0@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5SZXNwb25kaW5nIHRvIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1ob3VzbGV5LWxhbXBzLWNtcy11cGRhdGUtYWxnLWlkLXByb3RlY3QtMDAj c2VjdGlvbi0zLjQiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhvdXNsZXkt bGFtcHMtY21zLXVwZGF0ZS1hbGctaWQtcHJvdGVjdC0wMCNzZWN0aW9uLTMuNDwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk9wZW5TU0wgaW5jbHVkZXMgYSBD TVMgQVBJIGFuZCBjb21tYW5kLWxpbmUgcHJvZ3JhbS4mbmJzcDsgVGhlIGNvbW1hbmQtbGluZSBw cm9ncmFtIGRvZXMgTk9UIGFsbG93IGRpZmZlcmVudCBkaWdlc3RzIHRvIGJlIHVzZWQgZm9yIGNv bnRlbnQgYW5kIHNpZ25lZCBhdHRyaWJ1dGVzLCBhbmQgbm9ib2R5IHNlZW1zIHRvIGhhdmUgZXZl ciByZXF1ZXN0ZWQgc3VwcG9ydA0KIGZvciBpdC4mbmJzcDsgV2hpbGUgSSBoYXZlbuKAmXQgZm9s bG93ZWQgdGhlIEFQSSBhbGwgdGhlIHdheSB0aHJvdWdoLCBpdCBzZWVtcyB0aGF0IHRoZSBBUEkg ZG9lc27igJl0IGFsbG93IHRoaXMgZWl0aGVyIGFzIGl0IG9ubHkgYXNzb2NpYXRlcyBvbmUg4oCc WC41MDnigJ0gc2lnbmluZyBvYmplY3QgcGVyIENNUyBvYmplY3QuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FD980DBB9D35479886D197ED2A5662ABakamaicom_-- From nobody Wed Jan 22 10:12:04 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D03120807; Wed, 22 Jan 2020 10:11:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <157971671291.12230.10434088529161933945@ietfa.amsl.com> Date: Wed, 22 Jan 2020 10:11:53 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 18:11:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection Author : Russ Housley Filename : draft-ietf-lamps-cms-update-alg-id-protect-00.txt Pages : 8 Date : 2020-01-21 Abstract: This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers are adequately protected. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-protect-00 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 nobody Fri Jan 24 10:08:12 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A1E1209AD for ; Fri, 24 Jan 2020 10:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 O5QXL5B5tHVC for ; Fri, 24 Jan 2020 10:08:09 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE86120841 for ; Fri, 24 Jan 2020 10:07:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5DEC1300A0D for ; Fri, 24 Jan 2020 12:53:56 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mOD6vvXfLjBD for ; Fri, 24 Jan 2020 12:53:55 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 01B1A300670 for ; Fri, 24 Jan 2020 12:53:54 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 24 Jan 2020 13:07:55 -0500 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> To: LAMPS WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 18:08:11 -0000 Thanks for the discussion. I see consensus for publication. I will = begin preparing a document shepherd write-up. Russ > On Jan 8, 2020, at 2:51 PM, Russ Housley wrote: >=20 > This is a very short document, and it had some review prior to WG = adoption. So, now that the document has been adopted, I think it is = ready for WG Last Call. >=20 > This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information" = . Please review the = document and send your comments to the list by 24 January 2020. >=20 > The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications-0= 0/ >=20 > Thanks, > Russ & Tim From nobody Sat Jan 25 19:02:29 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CD61200A3 for ; Sat, 25 Jan 2020 19:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hBqGYzdNJSew for ; Sat, 25 Jan 2020 19:02:25 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8C912009C for ; Sat, 25 Jan 2020 19:02:25 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00Q32LTv011191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 25 Jan 2020 22:02:23 -0500 Date: Sat, 25 Jan 2020 19:02:21 -0800 From: Benjamin Kaduk To: spasm@ietf.org Message-ID: <20200126030221.GL77560@kduck.mit.edu> References: <20200122153848.C8D0BF40713@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200122153848.C8D0BF40713@rfc-editor.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [lamps] Fwd: [Technical Errata Reported] RFC5958 (5962) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 03:02:28 -0000 This RFC was AD-sponsored, so the recipient list for incoming errata was pretty small. Forwarding it on to a broader audience for increased visibility... -Ben On Wed, Jan 22, 2020 at 07:38:48AM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC5958, > "Asymmetric Key Packages". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5962 > > -------------------------------------- > Type: Technical > Reported by: Kevin Braun > > Section: Appendix A > > Original Text > ------------- > PrivateKeyAlgorithms ALGORITHM ::= { > ... -- Extensible > } > > KeyEncryptionAlgorithms ALGORITHM ::= { > ... -- Extensible > } > > Corrected Text > -------------- > PrivateKeyAlgorithms PUBLIC-KEY ::= { > ... -- Extensible > } > > KeyEncryptionAlgorithms CONTENT-ENCRYPTION ::= { > ... -- Extensible > } > > Notes > ----- > The above given information object sets are used in defining types PrivateKeyAlgorithmIdentifier and EncryptionAlgorithmIdentifier: > > PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier > { PUBLIC-KEY, > { PrivateKeyAlgorithms } } > > EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier > { CONTENT-ENCRYPTION, > { KeyEncryptionAlgorithms } } > > The parameterized type AlgorithmIdentifier has two parameters, one an information object class and the other an information object set. The information object set must be contain objects of the given class, or else the table constraint in AlgorithmIdentifier will not be valid. This requirement is not met as PrivateKeyAlgorithms and KeyEncryptionAlgorithms are currently defined, and therefore the definition is not valid according to ITU-T X.682. > > An alternative correction would be to change the type definitions to specify "ALGORITHM" in the invocation of the parameterized type AlgorithmIdentifier. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5958 (draft-turner-asymmetrickeyformat-05) > -------------------------------------- > Title : Asymmetric Key Packages > Publication Date : August 2010 > Author(s) : S. Turner > Category : PROPOSED STANDARD > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG > From nobody Sun Jan 26 10:15:30 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CDA1200A1 for ; Sun, 26 Jan 2020 10:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=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 qGALendx1bav for ; Sun, 26 Jan 2020 10:15:25 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2E3120013 for ; Sun, 26 Jan 2020 10:15:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D901E300B1B for ; Sun, 26 Jan 2020 13:01:23 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nHwfrPE3JIBH for ; Sun, 26 Jan 2020 13:01:22 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 7F4733004C0 for ; Sun, 26 Jan 2020 13:01:22 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_74ACAF57-65C8-402D-B10C-4E4E940A9ADB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 26 Jan 2020 13:15:22 -0500 References: <95B24D0F-3C0D-4A48-8F4E-5CACB5E4AE9D@vigilsec.com> <61262E5A-4ED3-43CE-B2E0-921D86934389@vigilsec.com> <7ABF535D-2B9A-4B7E-97B2-156DB40B41B4@vigilsec.com> <1B84479C-38A8-4E61-93FC-A7718C28AD11@vigilsec.com> <1BC022C3-D306-4102-B63A-C9E9722F1DC7@vigilsec.com> To: LAMPS WG In-Reply-To: Message-Id: <32417EF3-7D75-48B9-88B4-D14F4E4CE179@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Section 3.5 of draft-ietf-lamps-cms-update-alg-id-protect X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 18:15:28 -0000 --Apple-Mail=_74ACAF57-65C8-402D-B10C-4E4E940A9ADB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I got some private email suggesting a different approach to the = Timestamp compatibility section. The concern is that a TSA could be = using SHA-384 with but the original content = signer could be using SHA-256 and . This would lead to a timestamp something like: =20 > { > contentType id-signedData, > content (SignedData){ > =E2=80=A6 > encapContentInfo { > contentType id-ct-TSTInfo, > content (DER(TSTInfo)){ > =E2=80=A6 > messageImprint { > hashAlgorithm { algorithm id-sha256 } > hashedMessage =E2=80=A6 > } > =E2=80=A6 > }) > } > =E2=80=A6 > signerInfos { > { > =E2=80=A6 > digestAlgorithm { algorithm id-sha384 } > =E2=80=A6 > signatureAlgorithm { algorithm ecdsa-with-SHA384 } > =E2=80=A6 > } > } > } > } If it=E2=80=99s no longer allowed, the concern is that a lot of = timestamps that are valid today will become invalidate. The person that highlighted this concern offered alternative text: > In the context of a timestamp token [RFC3161], the value of > TimeStampToken.content MUST use same digest algorithm to compute = the > digest of the encapContentInfo eContent OCTET STRING and the > message-digest attribute for the TSA SignerInfo value. No = requirement > is placed on a TSA to ensure that the TSA digest algorithm for the > token matches the digest algorithm identifier for the = MessageImprint > value embedded within the TSTTokenInfo. What do others think? Russ= --Apple-Mail=_74ACAF57-65C8-402D-B10C-4E4E940A9ADB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = got some private email suggesting a different approach to the Timestamp = compatibility section.  The concern is that a TSA could be = using SHA-384 with <any signature algorithm> but the original = content signer could be using SHA-256 and <any signature = algorithm>.

This = would lead to a timestamp something like:
 

{

  contentType id-signedData,

  content (SignedData){

    =E2=80=A6
    encapContentInfo {
      contentType id-ct-TSTInfo,
      content (DER(TSTInfo)){

        =E2=80=A6

        messageImprint = {

          = hashAlgorithm { algorithm id-sha256 }

          = hashedMessage =E2=80=A6

        }

        =E2=80=A6

      })

    }

    =E2=80=A6

    signerInfos {

      {

        =E2=80=A6

        digestAlgorithm { = algorithm id-sha384 }

        =E2=80=A6

        signatureAlgorithm = { algorithm ecdsa-with-SHA384 }

        =E2=80=A6

      }

    }

  }

}


If it=E2=80=99s no longer allowed, the = concern is that a lot of timestamps that are valid today will become = invalidate.

The person that = highlighted this concern offered alternative text:

   In the context of a timestamp = token [RFC3161], the value of

   TimeStampToken.content MUST use same digest = algorithm to compute the

   digest = of the encapContentInfo eContent OCTET STRING and = the

  =  message-digest attribute for the TSA SignerInfo value. No = requirement

   is = placed on a TSA to ensure that the TSA digest algorithm for = the

   token = matches the digest algorithm identifier for the = MessageImprint

   value = embedded within the TSTTokenInfo.



What do others = think?

Russ
= --Apple-Mail=_74ACAF57-65C8-402D-B10C-4E4E940A9ADB-- From nobody Wed Jan 29 09:07:38 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B76F120849; Wed, 29 Jan 2020 09:07:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158031765324.2852.14336914598644481876.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2020 09:07:33 -0800 Archived-At: Subject: [lamps] The LAMPS WG has placed draft-brockhaus-lamps-cmp-updates in state "Adopted by a WG" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 17:07:33 -0000 The LAMPS WG has placed draft-brockhaus-lamps-cmp-updates in state Adopted by a WG (entered by Russ Housley) The document is available at https://datatracker.ietf.org/doc/draft-brockhaus-lamps-cmp-updates/ From nobody Wed Jan 29 09:08:48 2020 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0B4120893; Wed, 29 Jan 2020 09:08:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158031772430.2711.15072088870347053666.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2020 09:08:44 -0800 Archived-At: Subject: [lamps] The LAMPS WG has placed draft-brockhaus-lamps-lightweight-cmp-profile in state "Adopted by a WG" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 17:08:44 -0000 The LAMPS WG has placed draft-brockhaus-lamps-lightweight-cmp-profile in state Adopted by a WG (entered by Russ Housley) The document is available at https://datatracker.ietf.org/doc/draft-brockhaus-lamps-lightweight-cmp-profile/ From nobody Wed Jan 29 09:08:56 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E219A12088A for ; Wed, 29 Jan 2020 09:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Gwp2uee5KP6z for ; Wed, 29 Jan 2020 09:08:53 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09243120889 for ; Wed, 29 Jan 2020 09:08:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8CA7C300B20 for ; Wed, 29 Jan 2020 11:42:11 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q4o3Tdwnsj-4 for ; Wed, 29 Jan 2020 11:42:10 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id AE769300512 for ; Wed, 29 Jan 2020 11:42:10 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 Jan 2020 12:08:51 -0500 References: <157429966624.922.6336772483106473689.idtracker@ietfa.amsl.com> <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> To: LAMPS WG In-Reply-To: <7442575F-61A0-43DF-B674-D1E9F8287317@vigilsec.com> Message-Id: <0994915D-09DD-4977-B74C-A95F7380F641@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Call For Adoption of cmp-updates and lightweight-cmp-profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 17:08:55 -0000 Both of these documents are adopted. I am very pleased to see the = discussion of the content has started. As a matter of priority, the LAMPS WG will complete the cmp-updates = document first, but both documents will be worked in parallel. Russ > On Jan 7, 2020, at 10:00 AM, Russ Housley = wrote: >=20 > There are two CMP-related documents: > - draft-brockhaus-lamps-cmp-updates > - draft-brockhaus-lamps-lightweight-cmp-profile >=20 > Please indicate whether you support adoption of zero, one, or both of = these documents by the LAMPS WG. Please respond before January 22nd. >=20 > Russ >=20 From nobody Fri Jan 31 14:07:40 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C241201E3; Fri, 31 Jan 2020 14:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fskSojvC-0Kq; Fri, 31 Jan 2020 14:07:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E16120BC1; Fri, 31 Jan 2020 14:07:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6461EF4071A; Fri, 31 Jan 2020 14:07:21 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200131220721.6461EF4071A@rfc-editor.org> Date: Fri, 31 Jan 2020 14:07:21 -0800 (PST) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8702_on_Use_of_the_SHAKE_One-Way_Hash_Func?= =?utf-8?q?tions_in_the_Cryptographic_Message_Syntax_=28CMS=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 22:07:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8702 Title: Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) Author: P. Kampanakis, Q. Dang Status: Standards Track Stream: IETF Date: January 2020 Mailbox: pkampana@cisco.com, quynh.dang@nist.gov Pages: 16 Updates: RFC 3370 I-D Tag: draft-ietf-lamps-cms-shakes-18.txt URL: https://www.rfc-editor.org/info/rfc8702 DOI: 10.17487/RFC8702 This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC