From i-barreira@izenpe.net Wed May 2 00:05:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C36421E809A for ; Wed, 2 May 2012 00:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9zfSeYpoHC3 for ; Wed, 2 May 2012 00:05:05 -0700 (PDT) Received: from correo.euskaltel.es (ektmail1mta2.euskaltel.es [212.55.8.13]) by ietfa.amsl.com (Postfix) with ESMTP id C8FD921F85AF for ; Wed, 2 May 2012 00:05:03 -0700 (PDT) Received: from ejlp023.ejgv ([195.77.108.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0M3D00ITPVOCUW20@ektmail1mta2.euskaltel.es> for pkix@ietf.org; Wed, 02 May 2012 09:05:01 +0200 (CEST) Received: from AFE03.ejsarea.net (afe03 [10.200.192.20]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id q4274upS004424; Wed, 02 May 2012 09:04:56 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by AFE03.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 02 May 2012 09:05:00 +0200 Date: Wed, 02 May 2012 09:05:00 +0200 From: i-barreira@izenpe.net In-reply-to: <002101cd26e7$0255ca10$07015e30$@eu> To: era@x500.eu, pkix@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B05276C64@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/related; boundary="Boundary_(ID_jMrgJjm3P28N1lOoqSfDcQ)"; type="multipart/alternative" Content-class: urn:content-classes:message Thread-topic: [pkix] License fee for running a PKI Thread-index: Ac0m5v7mGAZcWKB6TjOkQnLvKB1SVABStP9g X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <002101cd26e7$0255ca10$07015e30$@eu> X-OriginalArrivalTime: 02 May 2012 07:05:00.0969 (UTC) FILETIME=[E4241190:01CD2831] Subject: Re: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 07:05:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jMrgJjm3P28N1lOoqSfDcQ) Content-type: multipart/alternative; boundary="Boundary_(ID_n0ZqY2UxFT4HjWwTkPwKMg)" --Boundary_(ID_n0ZqY2UxFT4HjWwTkPwKMg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable AFAIK, not in the EU. =20 =20 I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 =20 =20 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. =20 De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de = Erik Andersen Enviado el: lunes, 30 de abril de 2012 17:36 Para: PKIX Asunto: [pkix] License fee for running a PKI =20 Hi Folks, =20 I have received questions for which I need help to answer. The question = is as follows=20 =20 - Is that any government requires payment of fees by electronic = signature service providers =20 - If this is the case, what is the frequency of payment and above what = is the amount =20 I believe that the first question is: Are there examples where a PKI = service provider needs to pay a license fee to the government? =20 Any help is highly appreciated. =20 Erik=20 =20 --Boundary_(ID_n0ZqY2UxFT4HjWwTkPwKMg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

AFAIK, not in the EU.

 

<= o:p> 

I= =F1igo Barreira<= br>Responsable del =C1rea t=E9cnica
i-barreira@izenpe.net

9= 45067705

 

ERNE! Baliteke mezu honen zatiren bat edo = mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko = helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) = eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene = informacion privilegiada o confidencial a la que solo tiene derecho a = acceder el destinatario. Si usted lo recibe por error le agradeceriamos = que no hiciera uso de la informacion y que se pusiese en contacto con el = remitente.<= /o:p>

 

De: = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de = Erik Andersen
Enviado el: lunes, 30 de abril de 2012 = 17:36
Para: PKIX
Asunto: [pkix] License fee for = running a PKI

 

Hi Folks,

 

I have received questions for which I need help to answer. = The question is as follows

 

- Is that any government = requires payment of fees by electronic signature service = providers

 

- If this is the case, what is the frequency of payment and = above what is the amount

 

I believe that the first question = is: Are there examples where a PKI service provider needs to pay a = license fee to the government?

 

Any help is highly = appreciated.

 

Erik

 

= --Boundary_(ID_n0ZqY2UxFT4HjWwTkPwKMg)-- --Boundary_(ID_jMrgJjm3P28N1lOoqSfDcQ) Content-id: Content-type: image/png; name=image001.png Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.png Content-description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAkkAAABvCAIAAAB3iMNhAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAASlZJREFUeF7tXQd4HNXVndned7XqvViSZcm9yLiC7RgwNtWAA0looSUhBUJI QjUtTk8I+UO3DQSMjQEbN9yrbElWsXrvva2k7bNl5j9vV5ZFM8Je2RDe++z9dmfmvXlzZjVn7333 nssKgsB8/eZEF55h3AwjYRgMgH9442IYOcNgH17x3r8Lh0m/ZBftNRIoigZFg/6l0OcGfYp+jlNY JyNXfG2WYkfDbV5e6Lc7KlsGdxY1HK5rKWjocnJ2xmxj5DKG9zAMyzAiRvAwUilj5xi1gnFyjFTG eD2MyLfL42FkUobjGKWCcXCMjPaiaNDvBv1Loc8N+jwcHTsYDXqFPD0uaGZs3NWzkiZFG0PVCrFI dHa6+2puy2vo3phTtvFkZVePOUynzkgwZiYnxwWLtHIDy/JiMetyE8tPLmPdboEXWJYR5HLW6RQY lpVJsIXxeLFNUCpZh4NsFIsE2ouiQb8b9C+FPjfo8/Ar2QHWUb/d1tlrzaprruswt1sHNFrNbTPT blswaWpc2Fno7Wzc1tRvfetQ4Yu7i9Qa8YqpKddMTZmTFqeR4NcWbRQBigBFgCJAEbigCMB6OlLV vr2k7uPcSpPd8ZPFk++7dFZ8iPYLJ/Gl3La/ouFX/z3Y0Wv5xbJZP1g4aZzxi/tf0CujJ6MIUAQo AhSB7zwCzf3mV/YU/mdfXnhYyJ9XzrlmeurnIfkCbnN5mN9/tO+F3afunJ9+/2UzZyScze77zoNM AaAIUAQoAhSBi4BAcXP3K0fL1h48efe8SU/fssSokI2cxGe5DVGNd7+8fd3BvH/df9MDi9JZEidC G0WAIkARoAhQBL6JCKzPKb/31Y/vWjDt5TuuGDm/z4aaPLclZ93+ovd+e8vPF2VQYvsm3kk6J4oA RYAiQBE4jcAds9M/eODGd46XP78950u5bX9l4592ZP3nZ9etmj6eQkcRoAhQBCgCFIFvPgJXT0v+ /fK5j288sKe6eXi2Z+y2xr7BX7y2Y2VG3I/npX3zL4bOkCJAEaAIUAQoAn4EfnXljGvSU+7524eN Xf3+LUPcxvP8S3tOdbvFD96wUCYVU7woAhQBigBFgCLwbUFAJZf8+a6lvEL63NYTbg/iRk5zW3Zt x2t78x5dMWPaWbPhvi3XSedJEaAIUAQoAt8pBMaH65+6Yd4bh/Nz63uGuM3DCxvza0KD1DdmUm/k d+rLQC+WIkARoAj87yDwo4WTJsdE/emT40Pc1mNzfpBbsWxmcqyBJmj/79xmeiUUAYoAReA7hYCc FX9/Yfq2E5Vmp4ustxW29pp6rCumJo8WBbeHqalg6uuZ+hqmvo6pryVvqqtH250eRxGgCFAEKAIU gTFA4ObMCQwv7K5oIbnbD75zcEt+TcUff6yQjSKKZNDiWvM009PA8HJGyjMeXxYchnF65NNmMA/+ zqf9TxtFgCJAEaAIfLMQQP2cxh6ryW4XeN7LeyVSqZtzyRRyvOK91+th0RiRb5fk07u8vl2sl/ec Wy+xRCpnhHC9IVwvH2tN4omPvj4jJZJw28yn3o4O02z92fWjuQ+ubR/ya551qFVKGSO4Ga8YEv+M FJUAxAzXO6h77Q12yuzhcewe3mrj7Dy/v7xOyogUMklUsGFKbOjewpp+jnN7RIvS4iQ8o9LKInVK zu1tNNkTQpQnqjpru3qlUtHl0yZEqqVHG1qrG828IATrFAvSIkM1qtHMkx5DEaAIUAQoAn4EPsiv eS+7orStx+L0eJwO1NcUJAzr4XiJVOQWC1Iv6/EIYjzTWVZwCWKW9Uh5qSByOQWpgvWwgtiNYpys IBHE596LlcnlUqlep8pMCnvkiktTojRjdHd++c6+A5WNxCdZ2TEwOzpqlKeRoU6bRKLQGRhWyar1 YolaItcwSi0jUko1WqbPPnKcqq7+LUW1LsGjlqvUWvmJ2u5nP86q7jOvz6mWyFWMSGRUqd4rrLzp Xx+jV7+DeyentKDR9H5upc3NdNtdN/xrA7a/erC022pXaFivIEjB/bRRBCgCFAGKwOgQQIHNm1/e fuOfN2w+VlzZ0tPW2dPlcHV53N2Dli6X0MN5ujxcd7+1y8t0u9zdNmuX3d3N8V1eV0/fYBcv6na6 ujhHt8XR7eLPq5db6OwdbDLbMInXd5Ze8vjrj24/6hJIsH7AW2ZCbGOfU4Qq2TbOEWL8ijpvw6fn nC4YaazT4ZXxTpeTFcMp6ea8Lnxk3S5G/SmHpEQQBm12NSv6/szklZNTiuo6V1+7kPe6p40LvT0z 5f5LM0L1Up1CUd7S2tFnlqGwm8DwIiEyXHPdrJTfXD7zkrio9cfKgsTiX62Y+aPM9JtmJRvko/Ca BhwqOiBFgCJAEfgWInCkplV9+5r39+SSpSIlnIJeUhoajIKa0goF4/UyYjGD5zacYR5YZnDBiRmx r2asy8XoNAznYsSgBvSCUcGTctPn3MvjZfQaxolhlYzcY/I417y2O+P3r1WbLAHHNTRE7bDbRaR4 6IA5wmAc5QnkSgUpP6pQil3wMcoFrxh4yMUyfBRQ99v22WHkKFQqIoT0QXGNSMrMSQzlHF67xc3x /IAdxMqIJbKfXj3rxSNFGplUIfASN8/yEouD7OowWydE6txyRVNXv83psnFueCZHOU96GEWAIkAR +C4jsD6natFj77i8DBNsYFRKQlRgJgmWkWCdiAhpKRWM3UF24ZkOhyQITyIl5OfmUGyaQIcDnHgf oF42B6PGuUSMBIMLTJC2tqpt2u9eKu40BfY2GZUK1MMGP+M6FU7XaG1DF7lUhsMrCSRx8WLg4WG8 bkYiuMD/n44jwSe32836DM8/vJ/9n3uW4o3g5neeqrl37Z6fvHugvt86YLX+aNbktgFHSYtJLpcw SqGso2vdkVP3vLkjMSRo9rjY9o6uhzYee+DNQy/sLTT56JA2igBFgCJAETgLAltO1f7m9S08lpDA ZLDPQGyw2ziOQZS7CKaYwMCQwmMcZANDAgfgQS6W4nlNLDZYaTiM58eyl4SYiXqVvdN+2ZP/bekP pPXGC5yE2J5ShpG4Ry+zJZFJGSejkEkFD+sVS8U8iyARr0gCY1culjCiT9lV+CCTyvRa1eotWdfO Sk01BuFm8DLm6ksy3rz7yg13X5UUpOFcLjfPPLZs7t/25Mrwk4EXJ+h1105Pe+GHl6+56VIcL1fK X7/jynX3Xf7oiswQ3AnaKAIUAYoAReDLETjZ0v3wO/t6BznGoGBgMLjceBDDiGHgQoOlAW6TSAif +W04qZTwHLb4Q9xJpCTLSC9IL5w9XNff27v87+8H9H6S6EYRXKm4YO9ozTaGd3KCl/C8AHcm70Xo DOhXEMhH8qNACwTPNOyQidiS1p681t4nVwzFT3o8vFjkHj4Isah9DmdqhEYiEo5XNklYiUohjwnS qfAjwtc8do9aRZfZAnrr6WAUAYrA/ygCHoH/KLesrrEDJgiDStMeD7HY8AqbDOQFryN57yFsBwbA Rthn8ECC3rARy29gPmy8YL1gJmpVJSdrcxo6AndDwNt+PUmXMPqUNMmM6bKISM4+yFo5iZPz2hwe h13sdLEDNiEhgUn6lGqXVCLVKqRbT1bwHuHVrOK/78t783jloM2JcJ0XDxT+ZfdJBFIGBSlEWPNj mFvmT7HbPSqpWAnQQZmnm1ot++OO4y/uK1qfVdpt+dyCXuDwoCNRBCgCFIFvOwLtfZaDBc2MSMZI fL7HoYWizz/jTxfo/OKnv3/rhekF/57qiQ/3Bw55Mm3W7uZVN67+4Kkf3jAtZbRDnyrgOmolXgWA E8QkukOEYEmsTCYmiiZMHAmG3eUZdHD9VnuP2Sng14DHo1bK4oO0DT2DLp73ePn0qFCs2ukVKr1S xnn5mnZTYri+x+oI16mUsJF9rbitu3PQLhZEMoVoSnSoTkHTAEZ7o+hxFAGKwHcNgQM1LUueeZf4 HhHxCH8jzDL4JPEGj2hYZtiO9+A8/8IbHrMw0eC4gxMS3ki8R7vwvewusUzW8OIvYvUBeLznNnXP Xb2etTt51e3Pb/r1qptmjZrbvmtfFnq9FAGKAEXg24CAIPB/3JX76Kt7GQNYTSAeSDgYsa4GJoOL EhElWHLDchoYDvGK8EPCVEAsCYiN5ANIGCwzwVrx+y0RhcG5P9sLrj6/uxJhfYQCfb1IUgE/dC7/ Qh05l5twJzkXsr6RKfa5XsPnwgxxrj7zusduvyMzADSU29Q2b/U7IkbGMi6OEDltFAGKAEWAIvBt RsDh5suasHCFOHYZieZ3cYTYsIqGFTUHQtwhlAgCAxWxjMnB9FuZzh6G8zB9g0hzZvrNjMXOWJ2M aYAZsDAdVkaOyEHXmV5YvMJooENE8yM9gIwsYWx2ZsBKuvf1Mw4X09NPBuzuZ+wcM2hlzDYyFI7H BIZ7gV+RKgfWOTNDCSOTnKhuDQj2LBLoiE/SxqtuXfPeozeuykwNyLh0EIoARYAiQBG4KAggEfiq v27MLqkn6djgMHAPgjXAQ4RXENmPXGwpY7YyCuk1C6atSI9PDg0TWAQxIP4c2WD+kD3E+kmru3r3 VzVt3JFLtqkUQ8YZLDB0B1/6B0RgRG9/9ITEe+ZNzEwOV0hUAtHyQgbb0IAsK7E57SebetceLGqt qmUiw0nWAfoi6hDjsKBYDHh6hmbrtUtmbrlv+fnjltvUMnf1BtbOC6obHt+y+vZrpwTAGDz/adER KAIUAYoAReDcEBh0uK7/50cHT1YzOoRB+kL54Q+02gnVgZncSHTj5s9M2Xz/1eEa9VefQmCu/dtH H2efIj5GJfhPIA5MGFtwNrrcRqVk3S+vuyZ9VAVk/rQv/3drd/kSw92ELP0hmohV8c/QZmO8yitn x+166OavntVXHZHb1Dd39VoRwwlIO4cbdowaLsFFAjLPqxEcvDzPC17fv/Maa3Sd/WdEbXIEvIyu xzf3KDvngRTnyPmRpEy42mmjCFAE/rcQwHqbC6oiImRnnU7QBhuB2KA/gnUyzrny0qnbf75yVMQG ZFhm68PXP7zqMkKKMLnAE/60bs4drpbnP3fvKIkNI/32ezN2PvEDpt9JolcwFAYBpflTyDFDtZoR rJCwCtDdcPIMghex0uZ0gzvHotncnl0VzRtO1mwsqG7sM5/9FOCsL+OtTgf3fn7duyfK3swuP9nU 5/J+Nb15BOFYXY/5rE9wkGV1d38XXMyfa302bkd5y5bCxnePVxyu6RwLcL5yzD6rM6+ho7C5K7+x s23AimRBdLFy7n44xL+q2d0eCxzlvrajuHnXqfrhHg09ls25de+frPmgtMHs9EDJ7GjDWS8QIp9I YvyqM9L9FAGKwMVHAH5ARILwPkmt4QRt/PnCf2h3Th8X9ddVC/VYRRvROgZt3WZ754AdT8JOi717 0IbfviPbU9fMv3beJLJ+hkASf1q3zb7nydsSQnUjDxu0uzoG7N0Wu/+1a9BuR1DJiLZsQuKfHljG mJxDHk6sAp6ZITnuU0efF5TDudvM18jd/lpnrG437cipcjrcDa1997+15+x9TzWbaroGvvAY3ut1 OJx7ShqOV7WzrFc0Ivvty8Z0ssLRyqZPy6R89liRiN1Z3Fjc3P35QQQkpyNjQcVuKak9WHGGGL7W 5Z/nwV1m54Gq9uyGjr/tztmLUnss2z5ge2pb9sHytrOPbOFcL+4vOFRDFmb7nEKf0/pRbgXsc387 WNW0u7JWLhHvK2z61678+h77q3uLzjKgyeo8UX9x2P08AaTdKQLfOQTwS9QvqeHPxfYnaCOD2+2R KmT3L5mZYNQPY1LR3vvsjtx7Xt9x76u77n5t172vk3/3vbbzyQ+PFLee0XjUyKU3Zo6XoMwLFKRg /FlsC6amTI4MHh4HysDrskp/sW7f3a9+ct+ru+7BUK+Q10c2Hny/oBq/noePfGTprEmTEhkU2flM CjlhQcRKBuonNGqvMeLHnnzq+S2HV82flB51Zq6B+kK0DliR+Xb/ZZPnj49ds+Xoz5bOhKn0YW5N YUtvhE6tkon3V7TsKqmNC9GrxLKf/ndPTYfpsvT4xr6BD/KqBjh3Yojeny2nk0mnJ4T32byT40KW TojrHrRvzqssazdNjgn1er2Hq1uza9ttnKekpa+4tXd8hMHs4t84VCBiJZMiDQqp9HB12yflDRzn jTJowGcYEDbQ7uKmo9VtNZ29U2NCgvXqDdllBQ2dGTHhYt8Barl0QqQxTK0+UtH4k0XT4biu7eoP 16vbzJbOQWe/3XmsprW0rRf3YmtxHVSegzXKwubujwuq+51cfIiupd9W0tp9qKplamzYiYbOnPp2 EnDrZrYUVhe19iSGojyfpKyj/8O8ig6LQyWDNCe/rajmWE17lEGrhWvb10K1innJUbMSIvrM9ilx EVEGdZ/N9cax4vHhQVPjQs9yjwYcrvdzKsJ16imxYbnVHV1ms5uVTk4I1/pqz5Y0d6eGByN0aPq4 yDUfHF0+PaW4u/uq9IR3TlScau2JNGhw7QXNnTmN7Sdq26bFhX9UUPXXHTmzk6PNTuf2wvpTTZ2T 4sJpAdpA/Y3QcSgCAUTA6fZuOFHRDPVhSG2Rspo+kS24fAQmKcz47x8vQ7kV/+mK2nrufWnL24dL auo7qtpNNW0dVc291c3dla3dR8tqD5R1XDMzzaAasvDkEtGJqub23gFCQFbnYzctnZEU5h/H6Xb/ 7eOch97eV1TTikEqW/tqWtur2kzVrR0na9o/zq9XKWQzkyIkRMSSNJgmu3IrSdikv8CNf4bEOcmk xgbfOifj/NFoG7S9cahIRBLPBRSkO/8Bv2AEhVxa2Nzz5MfHb/i/j+5aPBNHHChv6rU5OI9n66l6 VGhDBrdepXrqg+MiCVYrxWqFvMVk+aCgTiWXbS2oyhrhDHS6vEj9hjWFQf59IE+ukFV3mtZlVZjd 3rezKixu70sHC9vNtl2ldbW91rYBW6IhKCJEufZEaVl7T259e7RRZ/bwWELzz3J3WeuWUw06tcKG 7wIrXpdVolaonYL373vyRl7Ga8cqEsODUyOC9pY17ipowK78ut7dJfUbcyoq2vvzm3v/vPukQa9c e6wMuwbsrgidNqe2s7LN9EFu6dvZJSFBpPje3z/JaewdDNEoe6xOvVLR3NMP2sD2pz/ICtFqTzZ0 bjpZbXF7QGlegX05q+wz/r8KMKiYjQsmC78JwZofzkjjEF901hauVV4+McmABVuGidBr2gfMYoHt s1pPd2Lz6rq2F9c+8eGRmxdmiNRSKS8ARqlE3GtxbC2pxWF/2HXSw/KNXeb1x4vDdBqNVCEXifvs HH4clHda3s6uGJOvCx2UIkAROE8EiBik72lOPH6++jV4ZIJIXK6kSKNmhHDw/+0vOVHfRXyMBi1j UJE1OY2MMagZgwYRGNUVtX/Zmzs8lzCtJj40iJiDWJ9QiqaMixjeVdza9+bxMgEx/VoZ1LOYIBWj 1TAgRZTI0ao4u/3/9uTWdw8MHz9zXIwvYRxZd5IzM0SMCfSxvkAG5dzgYH2aW0gE8IyVTxI/F3Ry 0ezYyO/PmJDV2Fbd278xrzqvsaugpePjkgqHy33FxPhIvWoXIlYZZl5y5KyEYIvFFqSQ/vCS9MtS YuFJ8y8yobFiVpCyuF9Hqto5QXTdtNSnr5u79lARFqUmxQVfOTEuRKO+NDUmOdxQ3WXKCNdNjw9F hdnSlj6T2dnYPRCr1y9Lj1XKyLoiCuVsPVV99fTolTPGTRsXU9LUtyWr4lR9W/uA88VD2cNYVnaa Kto6l8GCxiqXx9vvJBn7cPdZHA6pVHLZhLjp0eFqlfzGScmNbcSruSA5Jik0BHexpm+g085dnpqw fEI8AmAYr/TGmWkoFz4x1jg9LooXRB0D5u0FLcF62Y0zUzKTwnud9jidZnZCRJBacrCoAabtyPuZ 29gG1g/RDgU1sWLvSEerh/cWtfbtLmnsRaTviCaWoDA8+ZwWrbv3smk/XTwpKUjr3y8SC5Aua+q3 Ls8Y99PFU+wDVt7jMcglizPiUAk9v7bd6RvqhsnjV05LOV7eOTEmZPb46CijNjM+fHyckefdB6vq zu0bR3tRBCgCY4uAIOCZ4JP59eVTw1/kD+VjWZPL+UkpftM37ihs3Jhbvb+igezF2ptfi4QczJJX HA+m0auOFJ/5M5eKWZnSF9BIzC+JUXsm6KO139yA/DYilI9z4aHD+tLAfeclYvmi1g4TftYPX7VB haB/n8olSbMbMcPTKQiBwAclbsBtyN1mXGMUS+LkXLEG3ZyUyJsvSVs4Lur/duWzvOyni2f+etms N398NeS4fvPegT6HEI4gGQDGimRyKQgsNFiFjwmhIYMCB3Paf6kQZsbTWiqS9NmcCcFqCDUDRJ6V WLzexGAdUgr1CrlMxEvEknCtauOJmr8fLtGgBLpIesn42FVz0188lP/UtmN+zy/IY9BsnxZPSMuo kjf2D85MTrhr4aQ756cXPHbXMLK7SlumxAXPSAjHFjEnUfrKrqo1ChaVDTQajUwiEbGRGgM2aoOV +Pr8cW/W3qo6vUqOSeK8GfEx5FwCo1WwMfhlxDBvZVf8N6dEJVEaNZqipq65afHYGKLVqFn50er2 f+wpQd6IUacY+tnlm0froL2m154YHDz8VZIpZaSE63Bjmazy5o+Lapq6PhWqg+IK7Omgo3ijPiZY oyZC4KR5eNGcCQl3zJ10w4wkOArc+L0AB0X74D935bFSXieXOwUmLAhfXlau12CVzu3xSiS8WCp6 aV/p+3mVBq1OTKoX0kYRoAh84xDAX70MqWOCmNAG0fiHQwyp1iQHIK+0+drVb928eu0Nz6794ZqN 9XVtREAEaWqIfoROL0LPkNwNtRHyz4E/e9PpYDTy+BWLPHiWIaCx3wEvpA1xiKebAxyGHANkbaMj hkLyHDriPUbDeW1Eo9lNCloPNbHLF40y5Cw9PUO7nWHVqI4aIEBleGD6cgBUSm7EuQM0OhlGjB/5 HrdCSp7MB6pap8SFJ0UoecGVGKSXK8QbcstmxcXdPD0BhgsOcHi8bt7rcXlqGwfwMa+tOUIm9/lM fU0QcQ6R3emKVMuKajvhIjORSNTBUIm81+5wcW6bA1GWYthkfeaBZ7Zm/fPG+UsmJ3V2dOO3waUp 0W/8aOmxivbGASK1jCW34BDt4fIGl9tbUNcapVX0W7kYoy4p2NB1Opgzp6qlsrntmtMamzK5t7+f TDKnspGz2bycEwSJ1MBBX4yl1cFUtvSX1fU+tHRGmFFts7nABzZfqTmyjotPLndFZ9/JqpaV05LT EoNaBhxLp8e+l008mQW1La3dvXvLaq6YGL18crzV2o+YkeFbUNrcgV9BMxPOeACsNpz2zC2SsOL7 l0598dbvzYgJGXnjCPIItP2ir4qXd3k9nOK0291ud+CLmlfTdP2MlDkJEVavC6UbLD3kunANWDwG pKwgFHf0lHV2/3j2pJgg5GMG8DtCh6IIUAQChgBsAKeHY1iiy+Ez3XyEhOUJu1Mil4ZEaUPHhRkT w4JjDHHRoRGJhoT4yPAQfXx8eESCMTYyJDoyJCohOD4+VBVmiI8dWlEjjwKvN0ynDooKDUsKU0WF GKRnao0ZJLKI2IjQZCN6RYQZEmIjwxP18THhEeHG2PiQ0JRQY1Q4nvZnrlBGMpAYjy80f3iGKJoq 2OUB80k68Az15W5f//iWp8ckd7uhz7p6S3aDyQSv748WpP904USTy3P7S9s9Hs+9Syddlprw8zf3 hQYpTtX2PHT1PGQC/n7ToZfvuOpYQ8f6I4Xjw0NeuW2JjEhZk4Z8rJ1ljYgMWTQ+7p0TVf89WTbY 5zz+9K39LndeVduUhIiPSxquSI9DTOOs5KR+c899Gw4vTkq0elwTgoNq+00VnabbF2TcNmuCxFcE vN/tuevlHbDrkmJ0v7xsckWr+S+7822841dXzbt5UhwO+Ki4ds22Y9FaTb8NBeTY7Q+svH39ToSQ ZEQbZiXGKKXyjHBtfb+ta8Dxw9mpf9ya/7trZzyxLaegpjUyWJkOmhGYG6ZPSTDKkZX3l70nf3nF LCUj+iC/9rX9pWnRxi6bdcO9V72UVb6toCI5WJ8YGjw3OfL57cdTooJyansfW5G5LIOYdCab/cO8 2snREZnJZ75kO2vbXAP262Z+RaL9/oomsVR+WfIZUhz+bm0rqBHJJFdNTPRTaHWf45Oi8sVpyb98 d2daWEhbv+OBZVNPNQ88/L3JLQ772p35D14166H3DlyaluR1uT7Ir8yIi95fVH/42R+qAvZFDNgf Nh2IIvAdR2DQ6brhHx8dQO62b4WecUA9REaMpEHz9ZdO/fBn1110fGr6LKkP/AtuOlIE/NMzvHLO xF0P3nj+M0SeWObqtazdzqtu+cPGx26++VullUzUNb/tGpg+CdHdpY3Hazuevm7O+d9ROgJFgCLw HUdgwOZc/rdNx4uhuaUc0i8mdbSlcC5dOyd9SyCY4zwRruo1p937d1SyJhEufoXlQM8wt6l13up3 sd5GVpPGaL3tPFE4S/dvO7F5Be9fPjm5v6Jrb0nLorSosQOKjkwRoAh8hxAQsTKwBUQ54DvCijvC IH1BkoiVDNxq1nnBKcdaILgWkxzDGcpJ2To7x6t+9Oz7v7kFMXvnNWXa+WsisKWwpr7TOislfEEy 5baviR09nCJAEfgiBJBGffXfNx8rrEOgo281yxcAiXCSQfPVcyZ+fNpuwyL6J+VIR3KK5V7GJWGk WACDqD/CT7BKh6B0xup2hml0109J8p8Eays5TZ3VbYPY5fHwN89I1qqGCq01mayHq1pxIhHEQDwQ uvIP6CXvhwZEdU98RE6CFyrMNV29T711gLhJFSKSePclMzyf25vb1DF79dus3cWrbnpm85O3rpxO ue188KR9KQIUAYrARUZgwM5d+/fNRwprScoamMPjC2iE6TZoXjFn4rbT3Nbv4OY8v6GqspmwDgvf Hewc/MPB/qAPD+P0RCbEtP/zfv/1mJ3c3Wt3vL+3kJR/4xxF/3l48mn5iLdyq27/2yafor+/u28d X4BcpF/I0ReuibQEF9yP/txdMaNRkHQCEqH9pTM8Hxxzmzpnr37LH4c4Vrnb5zM/2pciQBGgCFAE vh4CJECQ/CepZiA2f7lthEwzipECHVqF3KCC5YQMARVRMIE5BjkkBHeQfGoJkfxnJSGqM8GQIhZW GawxKemiVJOc69NNDSUn+BiROixXkkFAXQocpiQH+0YTySW3Xj770TuueGTV8j/cd80vr188JFCL 5IFPzzBwsrW4HuQAIDNLLj5vpf6vh3/gjg5UPsRnZ9TQPQC54cDNk45EEaAIUATGHgEUAiC52/78 M5AFUaD3UZFnwHZG3gFRipemxJAoSn+pUhKjLxCbDDtgbnkh1e+869IJw9NFMhD0K3zyXTIoVTpH PBtTwg0TooNJZhuGwumQmo0z4r0IryLG6poYEf7E8kuev37+H1bO+f0VmbcunMxAXmqIaT81Q3HA Qq/9udtSVPseq9xtQHOqyXTfm7sf25w1DBMSqE81dfk/muzcw5uP/Pj1Hf6Pg07u8a0nHn4vq91E BKJAXD99d/997+xr7hvKqHJ5+A3ZtY29Q3nK339l97bCutxGIgtyFpbbUVy/Kb9mlKV2HG7vrzYf e+iDw797/1hVe//Zvox+O35EO1HX8WpWmcVFy8eM/d8wPQNFgCLwOQSQuy1B7jbqAMBmIsXSUIwU 615iRimt6+jrsp95ND1xzbxFs1OZ5rahlG0UzrbaSM410le7e5YszvzJkunDw3db7U3dZiypEepi +P0VZyRLIOr78PLZUqTQdQyQmt1IBkfWNjK4rRzTZZHo5Y+vnJsWZcRQPpUIpqC+mXAqaNJfd9s/ Q8yWyHAFpiE5HHaJL3ebV3DuMTGArHZ+Z3ntg1fM8Iq5B7ceIezl4H767t5txU3+i/jt1sPLp8fP TYn9wb8Jvb18sCgkSD0x0fjvA4X4BXD/mzsXp4y7Zcq4n67b5j8e6W5N3abWfvIDpM3haWzunD8l Lsao3FfU9Elh9ZcBkxEdMjHaKDmdrXx2/HaXVIdIRB/95NrV182PCzV82cH7SlvX5pRy/Kdsu1i9 JjM6yi9JTBtFgCJAEbjACMBqcyF3GzYTBB4RHkki7N3ESOK4botl04lTw/PRyGX7H/rRvx+/c2pG 3LSUuGlpUdPGx01LjZk6If7x+6/Z+ouroec+fHBxc2tRYxMxB8FJbsnmvKEHuP+AOxdM3vLrm5ct mTEtPWpaasK0CZF4nTEp5raVc7Ofvuum2WfsPxy87kAJI0iJQBdkt4Zn6LMShqJTzhsygeF8uiQK lmEdCqK8Ffh2orEpVK2JNwb98frF2SVEa1giEUfodUoI3zMMZOb1jHJGZOSPL53c63U299p6zI67 Z6TeOC1ZJBV3DFp7+l0LJkcumJiogWv4dAsOUpS2NePTh1lFV88bHySSmjjPa9mlGwpQIc5p8XBP bT/61pFyHABl5K1F9e/mVJocriijXiSwb+VU/WzDXovjS7WGEQ60s7Bp1ZzJ6G6EOpaULe80Pbbl KESTsQVG+Xs5Tc9tOV7bP1De1vWfT0rKWgax/bWjFc/sPGF2C0atMsKoPtna84+9eS8cKnphT37g MaUjUgQoAhSBL0GAFYsUUgXDQ1zflwMA7Qssm8Eg06o9Ds8/9xU195wR50O0x88WTip8+q6C5+4o ePaegmfvLHjux4XP3PnsdXNRDGT4DD0253+zqiAcxSgV4EgmXF1wtKC0zTJyCldNSdr50HUFz95b 8OxtBc/eV/Dc7Xmr737zx8v8moXD7d9ZlbmFZUyYdsiBOTxDqHOxGmfANLeUYDWf3aZQYsJj0SCN D5FHqU9bxCBTW5yCWipZNStFpSSKkU19VqNRKfaZU4la9e6KZhkr1qgVKBkDkSeocjyz6pLbXtq2 4oUPf79i8fD0UkNDyhsGcONQO+bWSybuLGk8XtaSFhUUHSxDZdnfbjoyPiTkUFX9uydLUWTvF2s/ jtAr86tb3jl8qtpkgT94UXLcz9bvHB4N0lkuLz9clhrDtlndoQZ5vcla2NaHwzrN9kVpSeuPlByu 6vmkquW93MIFE+PtVhfczvHBsjCNYv3xytKWrkiN9jfv7D5R077+0CnBI6TGhH6SV7fuRNVYoErH pAhQBCgCX4iA4OWdI+tuo142xCE1auJp1Cjr61p/+Oq2yk7yZBtlQ5XRx98/sOtICaNTE1sQdbdh CBrU0594JbtxaGlplEN9VFzz8zVvk3GcTiKX7K+77Z+hv+52wNbbHFjH8623OTjpUMmwUU5y1Ifx ZE3Pv2w46HXwWKjEOiUCaXyVexRysdynVUiGk0gFkdcnPEkaZEdQj62x17FkQvx1k1L+cyCbKHX6 2qVpUW4JW9lhNlmsiUatyytKjNDNT4tdlJxQ3tQXqpB/P3P82ntWvH6w3OkWvj9v6uK0eI1GIVap orTK6UnhvEwYgHzn6YYiaq8cLjpc2+U+XWtWLfe6Ge/RmuZfv71ve2Hd3ITwUIMqWCOqbOtJNKiN aqXI45kcGzY9KuLyjJSYEPWftp8I1ytMDqtepe60OhUqcWZ86IzIsIggzYnffX/USNEDKQIUAYrA eSPgz90mdbf9Va09ZFkLz1iSwe2GsOTRUzVL12zacLwCJbZtLvywR/AJeRzjDakBgDdkg2BzeWAb bCmtm/3cf1/ddpLRKocMQSSDIypSKkXFsTlPrPvte0fKOgcHHBycZHhAk9GIGrtvKDIOKIzvtzlR pvK2V3fc8NibDFZ51Kqhutv+mEz/DH3tU6VMzgMJ5KvjiuD0JGLRYxQnGaxTOTxO6GxinlY7q/f5 bz1uVGEg3Bam1nSYYYqSjbUd3QuSovs5j8XjtnAeXHKjyfb2gbJHrph13+JJTq+wq6Jx+GIzonX/ 3nti9rgEbBEkgsvjdjggR4xCbB5BKuNZFuVoZLwgJfn5ZHSxIChFzFtZpRuPl6cHh8AsHB5KBA+y 282jPoCPOsHCkUFQTLbdPjv9uqkpvQ7nkx8ebWzrSYkIt7tsGVHGJ5bP2lXcuO5oCQro+O4jvi3S XyyZ8esrMv9884IYg9IliEyc9w87cm+dk6yE1DNtFAGKAEXggiGAGjd43qIOFlazYCIgWAMPW7zH PwToI4RSpWzt6r31Xx+u+OvmhzYdeGZH9l925qzZnfeH7Tlrtp9csyt3za6Tz+/I+fWmQzf8bfP1 T73diLg/NQwqX3UbPDgRIQmOVMoJ1THCnzfuWfj8unvX7nlm6/E1u/P/gKH25K/Znr1me94fduX8 cVfe0x8cv+eNXQueWff2zhNMmGFoViBT1MTB9IZniDfETRmYBmMQQ/nrbh9ctWBy+oga4YE5A577 MkVBU9egw721sDbJYFiUQcq+NPcPNvcMzk2ODter9lQ1upzuwgYUlHbfsSCjrMt0sr6ztLVDJZEt nTAuq75VKRHVdfVXtffdNDfNIB9aaxTEkl9tOvLUtZfEG7WlTQMyiRixMCjDPT8t8Uhlq0xgNmSX XzI+ZlxU8JHKpmWTk04196JYTk1377hwQ1JYyMuHTt42b6rMZ0SGaVWoKJ0UpveX20Z9GTfL7Cys cXj4HWX1UTptR99gZkrk4fI2u5uZGhfW1G+WyST9DrdRr0SJ0Zmx4TaPs8XE4UtT3zsIi6/XbCtq 62wdsE+LC2vrs0WjHM8YFX4N1E2i41AEKAL/Kwig1jIqJzd1jKi7jUsDvWHpByH+/sI3kClh+Y62 /vyatsMVzfvyqw8U1B8srT1QWn8wv/ZgYe3B8sb80oaWHgsKdJGD/b0wgr/AGx6VMAqJfcKC5BwW Z3l925HShgPF9QdP1R7Iqz9YXHOgouFgXu2BU3VHK+sqmjodoC4s+yEV4cxQECXxjeCPniQEzKbE GgNUd9uOuts+bvvgMLhtwhhwm0YukQni4yRGn31gyVSlL4AQV6FVKeONGtBJUoguu767y2x/6MoZ KDwdE6Sp7BgURMKKKUmJodowgyq3uqPTbr9mRuqkiDM1XLDKBSfm92eOE6NcjUQcqlPrldKmXvPM hLCYIFVBY69CJdw3fwpuJYqtpUQYvIIoyqhbkBJV0ABD3B1u0MSG6ELIIF/Q4oy6um5Lh8mCVdAr 0uOD9JqSzr4pMSFQpEHh2kNlLbC1l00ZNyEyqLS9M0itXTlj/N5TzR0WS5RelxCq0ysUUrEINdwG 7Z66voH5ydH/K3819DooAhSBbzoCTo/3vRM+boMmFkjIH1cPhyRyzuD98xfjhg0HllIjU9sXcgJ7 juRZg2YgLywj1UpR2hRdNPJP9YI5CCej33+I1TI8XmFoYVj0QowJHJXohS1YkEP1NFgKGAEHY50J r8QsIQ7K070wFHIAxL5oSf8M5QxnT40Nv3VO+vlD3DZoe/VQEWt38qpVz216/Ps3jZmeJByPQWrF cMEwn1uWxO/4W5+NQ5FPvXJoxc/OeeBHVPsKZJO9FgeW54JHZMj7txMpzBEYACizg1NiAU8i6bY4 gkg4CuFRn9Q+yRTEXcbxA04Osi8oYsp5PMO1Oj8PpcsrWB2c8TT59docIWplv80VpJah0hsGCoKR TvIZHCKRVCuXWJ0eq5OLQDl238zwBbByTi8v4nh3xOl62ed/w+gIFAGKAEXg7AgQPcm/vX/sFPQk 1UNGEknNlpGcMz+TEesNWdg+loKDkRTL9hI+w7oMnpL4iF1EJSsQvUClpPr2aM71WcXL87nRuU3t s1f/1xdLwrgD5un8ohlF6lTDxIb9ON8wseFjsFo+TGz4qJJLhomN7NUqP09s/kFGNtwRg1ruT8gI 0yJ0fyhnwO8ORJlo//EGhVyjlINKz0JsOEwmZoeJDR9BbHgFsZFXjdxPbGh6pRLEhjcahWSI2Hwz w2R0SgWOp8R2Pl9Q2pciQBH4ugigsrEES1kIpCAE5lvDgkWFjGxYUXg8IjDeH7uBjcgtI0nTPvML lbJ9ESJnqnUHpBcMxNGey8GwKk/AcgBgEvpzt5VyCKbQRhGgCFAEKALfagQQm+jyuHyaW6frbuPh jjUzVN+G/QQRENCbP8wEFEjSuhmiNumnOiTwovlrYY/sBbfhBeglOGUBywHgfJpbyN12OHDttFEE KAIUAYrAtxqBM7nb/lUul4+34L9SKkScOzg0TARbjYQ4wmMn9qV120lQPnxNUOoi6WtYbxvRC0pa YD5IJ2ORyN8Ldt5Y9MIEGD5QWda4WqwoQiIaM1bCJB2LVtk5uCm3eltJ3TvHKrMbPpXoZ3MJdT02 x1mlF5Ez0WFzmuAIHtE8Xh7b/RvsLne/jesZcJGw10+3TgfXZMLC6tCRgiD0OFwNJnIoDjQ7Xd0O F+qvm5zYcEamBGH9/Xau1+myOhG/SdLgkLHRMmButTpIsgZZwBNMdkfbgGV4DmOBGx2TIkARoAic AwK+3G0nI/ISywySHP5Ua9CSzRERGfz3m+cnhgQRxyM8lk43Y7ER7X9oP+JZhyBvWHLogkxq8BzW 5/CoxAFwZvpTrYnsMhIAPIQOETwyaCHj+HvhgKFeThJMYR7RC9dAtLXcRBvF3wvPan8vWIrDMyRR l6JAWVgC4wAVix97ZvXzm/f9YNGUtIjgc4Dy7F26zdaD5W1vHC4OM+pDg6Tjgg3Dxxe39a7NKkiL CEI29BcOggXNP+zI33iiKKuibXpyvBaxN772jz0Fpe2+wEWR6JqXNufU9ZS39QVr5RF6zfA45W39 T3x05HB5bV2PZU5yFHzQW4vrX9iRl1XdHIxoxmDtC3sLP86rO1rf+sqB4nC1MjkiyN+33eFY/dHx /Iau9cdLK9oG5qfE5rf0rD9U/EFeRWOPeW5KdJ/d+caJ0tcOFNf2WifHhijHdKEy4PeDDkgRoAj8 TyPAeb3v51Y3QuRd7ltygpmFgA5ieykgUn+iormt34w1sPBgfTgCHYw6nYjR4FUqsvisA6nARgcH GY3qUJ0mCKF5MpkValhiiZgV9GqVXq0MD9FGRoSGaJQSVrBayDIetJkNKnmQVmM0kF4GvVonl8Jq 4WE4CXgRh6sVocGKUIM+SKPRKcRWuxupx0NZBERz6/QMBXlSjOEHczLO//60DXJvHDolfuzRp57f mrVyzsSMqMBzW6hWNT7a0G6x/X7ZjAnhwTB8sqpbId4RpVea7K7y9u4ZceF+bsMuiO6LRCLl6QjJ rcW1p2ra3rh7uVcie/VQ/tWTSQXY6u7BVw+cNCqV81KjwW3rDhZt/tl1i9JjRhIbDrvlpQ//dfvl d8ydtLuivs/mFouE7YW1z69csGr2hOggLUJL5qVEXTUlYWJEcKfZmpkcGQEZGF/TSaXLJyd9b0Kc ye5B6tv0BNxE0dVTUlbOHH/Huo9vWzjJKFfOGxe9KjNtY3ZFnFGD0c7/TtARKAIUAYpAQBCAt+md rNLmThNJr8ZjlVRx85L3DmeIUfPbKy8pa+zgnK5rZ46/anpqWrghOTrkj9fPnzQ+esuBEhEv+sHC CTfNnRhjUMcFGyclRfxgzrQu62Brc++4SOPjKy9bkhY3NdY4NSJ4bkL0nd+bcbKxs6+9JypI+9iq Sy9Li0kI0k6IDJ2ZGHHdnAytUlVUA21lFrJQ9yyZnhRqjDEaMsJDr5uXGmEIKiivJ15Q4of0Bc2T GcL5aZ0QG35LYHIABl89VIwTMAyHUt8BAfYLBnG4ebeHh4AW9r15smJHUf3ekvqdpU1yZIGJpOzp gEaIFL9xpLSwpXd4CN7J8D4pMKNcVtbSjjfwFubUdk6PjY4I1vs1QeBK3VhYuSG3qsdiH+7Y7eTE MmmcjrDOgtSklh5zTUdvuF53sqFzU245bPXhI7Nr24JVikkxZzLn/LvqekyNPb0Lx0fivQEF91jm YFXL1NhILebDMv02x1vZ5UkRxoQQw1ihRselCFAEKALngACK3CDKH88pv5IIAkMQ2e/LvEacf0ZC hFKu4FyejScqHn1rz7ObjsHAsrj5t6HNz3smRBtunT+lsq13Q1bprtLa1w8UuAT+sRsug3aVQa6a Fh9W1NDxyIajj7x38IF/b3FwnjsWTmTsHo1ckRxqzClvXLP5+F8/Ob763cOv7MlZNWc8HJsKiWjV 3Axeym7KrdxZUvVW7qnjZV1PXjdPq9OQqBY/vfln6GtfqmH/tXEgcfJDnDYmFW6GJkTG9sfiP7Pp UEyI3uly7Str8V/W8JzFLHtTZnJaxBm2WDIpQSRyv7jvZFZ9cxAWMxnmYEUjFkTnpMbZOZcfjWsz M7RiWWlbz9sniE6/vyERTQcvs68p4UD2egfc/MmG9n6b/VSr6e87h7T5uwat5W2mqfER/tLjZ5rA FLf0aVWyxFC9f+Oeypa3jhaj3JHvhwBjcbqrugYHOLdf5Zk2igBFgCLwTUHAFxVAJkOqWnsZ8nNc RFa2kFktSBFcQDQWeZ4bNCul4jW3Xf69ifF3vLR134lSOCohqaGUKVOiQn64cMrtcyb+ZGlm96Al v74bGcZilq/pGjhW1eC12wU4vjg+q645GDW7BbgrmdYecwWU5XmvlyfBmdnVbYNWm1Qk0kilSoUi WKm6MTP99rnTHlg8My5Eu6OkXuVXmBo5Q6LW7zM0A9R8DlmMJhf7tIvHppH0aaJlhTMoRdJ5KXGX jY/9yWWTOYRw8EM6yTgxlsQykyKj/enPvgapkd8tuyQ9KmTJxOQwJVlLK2zo+eRU7TvHimB0Q5oL W359xdSrJietmpnW3DvQT+qmkxahVvdZSWlTtD6HRyoWq8QiENX1M9Oeum7u5pyhMm913WaO9c5N /axuSL/VkV3dcmk6cYGi5Ta27z5V+5urLpkUHerfEmvUPXZVJqr0HK5qRWjJ2KBGR6UIUAQoAueA AHSKySPX14jko08lC2lt5BGPD2A6kFBcTNhzty7tHbDe9df3G8rq/OLFkDjusVn251a+uTV73bbD /91y/L3s0rKWbpAQj6wCAX42sJwvzFJJHG68XGDEPE8UmMVihJ9YOGbQzJjtYlakUcncgtsjCFDJ OFbZtHZ7zrqPj6/7OHv93uysqmabg6hHDk1veIZE4DlQpdb8dbchteJxk2y/MWq82GGD7eQlNo5S MjUmaElGItjb6+IEr0cqYRv7Lf0AhWFQKc2M6gwjWnywfkl6YlZZS2w44bb7Fk95dMWcmSkRc1Mi E/xGlY9ZOqwcFCaDTucx6BUis5NF0Ad2najtjA1BBQAdIlPcXg/E/lHqHNuxrHqwoi01MmiEbPLQ iQdcnFytmne67NDGo5W3LZycfnoxEoJbsEFVUjEv8tq8nE+KmTaKAEWAIvDNQIDkbkN5hCWZ2kgD gMUGYiPv4WZyG5Qq1isYDfq37l8xPzUa0d4rF8741R1X3LAkg5GzVV19iDS5aX76ghnjMqelz5ge 8+KtyxKjtAwrkYskGgUp6U1YkAiaCDoUKmMhRo+4SUdUkObBK+bevjzztuXzV10xY8Mvr23tQ+wl D5GU/Mb2KyYlXzM7bc701IkTYp68+XvXTkuzEocktKl82eL+GRIpL19geiCav+62+LHfPfX8+ydu mJeRER34WBLME4tktQPmOUlRKpk0WKP6887c7Jp2nUYRrFOignZmYtRrh8rsEnZCqP5v2wuRcTEu bChkEX3fOFH+0sEiKc89fcOl+KhTQhNEYXF71ChvHRcmEYn+ceDU2zlF7b3W++ZPhILJMCzzJ0Y9 ueHI7oqmlDDNnfMmxQZrW3ttbxwt3Zxf/fBVs5NCdb0Wx6HKhp8vnYFBRoKJXzyHyjtTQnXjwoYc kqjyUN3Ul93UdqS4dda4GIeHe/lI8SsHi4L1ypump2pPyzcH4o7QMSgCFAGKwHkhgJymt7NKWrpN PrFHFAQQ+7T2EdOPOH0xXF/1PSb8Lm8csBU19jldFkEkQY6Vzemt7uriXCwezr0WZ7ABQQZimVa+ 7Vjl+8eLvWJ2gBVKWzrqOk1OlEUjCeCKeou1rLWzvc8cGmLIiIs4VN9idjslrEStkRwoqV9/pNSF 0H+JtKSxs6bfFKRXgHP1Wump1r6X9ubaHXZCtyRJHDalb4bgNo7LiA37fmBiSfrXHiph7byguv7x LU/ffu2UlPMCdXSdYWjB9Tv6PIY+hx3u2i8bGy7BAY4LQorGF7UBDpEgZ3ZYOI7ITBKb/Gs32IAk DdDXD7GyuIQvTlz42gPTDhQBigBFIGAIIGf3+n98dPBkNWK+SYUvEnbOktwylCcluiQektmGH/T+ jOZhtxMIBmnaaMj15uAahNkD7X+BlAzFMfjJT6RJEJ8CfUhf3RyMAFpCDpxYOjk85OGb5v1nW042 oh9J4gGelUpGzDFyBTkYvXCu4ROR/G+kHeCRDulkeCZPz9BmY7zKKy+J3/XgTeePRW5T39zVa325 2yqlE8pbF6QReeivc6KzEBu5NSz7ZcSGvSOJDR9hY50bsaEvbvswmeHuUWL7OveQHksRoAhcIARO 5277lP5hGHl4X91tFYM0NX/Ktn/9CUGTkCOB8QTOA7EhSQB2HZFORvEUosJIDtNqhpS6QGz4SAb0 kmRwyHGB9hDfADr0cO22wfeyyluQ5a3zFR3FgCA2xPRD+gujkSe+lFGdPhf8pejlcAzV3R6eISYj WBUBW2/z192Ws1DSlMvowtEF+vLR01AEKAIUgTFCQCyRGBFhD28kaAYGFmgJDklYLghHgJ1EFJN9 phXcV4g19+tMgsnAW6SSM9bAsJzm7+WjQOz6fC+Si+ZjL/RSKHptzp0FUMswE+L098Kw4D//uUjF li8/1/AMwWq8oAWbBqKdrrvtxsllAVvFC8TM6BgUAYoARYAicA4IoFxarAEeP58gMsI0QFSkchvS en11t7G25q9r46+gDQaCFYVXHDxcC/vr9gIpkgoDiHw8j3ORyuDu1NAzwRbncO3DXfx1tyGRiZIz Y5i7fc5THHRyZpt/nYs2igBFgCJAEfhqBBRSySXjExnU3iLpSb4MbkTtI9GNlLc+XZ7tTNK0L/gA 1pW/xOhQDvW59fJlMZ/buVDzzOFFrdQFk2K++gpHdYTYp+tMEDiTZzaqjhfkoN2lTQdrIK9MnaUX BG56EooAReB/AoHMuPDk2HBiq4G0EIII3oLFBrMM3kWwF2wsYiT507qRhQ0lZV+NbKzMwZIjhbkR CXlhe2Eh0CnEx4VfmvTZbONzvSFYGPRzmxvFwL9xbUZc2JS4z6phBXCWPll/2igCFAGKwP8UAjEh mvmpsUPK/SQAxPekIwndvuiSM54wxFv4Fbn8G/0Z39joP/JC9mIYh+XhKzMDdxvI5MWPPfXU8xsP 3roYdQCMgRt6aKR9VS2QH8lv7DbZuWiD5qUjFSaHU6VQnGru7LPZLS7vidr2uq6BlIigN7KKtBIF 0qsPVzSnRpKZFHf0CQIfqVM/8Obhg9UNW0saY3XqYJ3q9azSF3bn67W6xGDNwcr2t44WbSlscri9 EyKD0HdLcdXLB4pYqRQyoChP8+qRitcP5aukssTT+WoYuY/jf/n2riNlnXqVPMaoWX+i7B978hAu Oikq2OJintxyZE9JU2lH95Ha9l2lzROjQjSI86GNIkARoAh8GxCQS8RYYdtW2ODhvIxCSvyECNZH RAnxPUKZBBabb+NwWjcuCiYdiezHAajWjdRn6PRfqF4IP3Fw8hD9x7+4IVDotpudrx06hZR1JEWL TLZAlYX71PSa+war2vu2FNTvLK5r6TXXNHR63WxxS+vOkrqcus6C2lYHLxyra0Sfl3YXn2xoqe42 t5jM/iFO1XXkljfjzZPXzbpsUnJeQxPkibfm1Tis3IPLL3l6y2Hs2llaVdPdd/v8tKO1TYNOx66i OruTf3TF/Gc2HcDeY5XdFW3dP14ydUthdWHjmepxv1q/Y8GEcb+/bta0pPBtxXV9Zvufb1y48ViZ yeo2WxzHqtpumTEhp7Jtaky4x+Eoae0PFOJ0HIoARYAicAEQuHJSys1zJ5HqaHD3+UMW/YH7IDZE LRIhR7gf4ZzER59bEmSGjGxSRG1E3e0L0AtZdAjX77P++cbFAYTF7XSLBEaEBHSpTD+I5IYxaOND DW0Wp0orqOSS/cXti2fFZSYH9dk5o0zBu4XWfm5eQkSITn2sqS0zOabVYms3mTNihmQbYUTzPsnj ML3qrQP5f73pCo1Mktvac7yhd/vxSrUv2FSpVC6fkgqLUCGSmm0ejUExe1x8agRURaJqBu0Hqmpq 2/q35tU5iL7LmZRtqUpz2yXjQzQKuYit6bCkhhrC9ZpFE6M/PFku14umRxvjItXJMUGZcRGhQSqR aGzKto4B2nRIigBFgCIABFQy8R9XLVo0P4PpMpMFNhhhJIONI5VIhypowzhDWpuCpHWjyhiW2URS X+j/iLrbCDkhxXHGoBep8e07F+zIrq67b7nsF1dOC+CN6+I4qRz5bQyTGmc4UdIWwKGHh5qSGNVm GpgdnSCTSrZUVq2YME7OSvPru8JD9Danq2XApFaIp0ZF/nNH/m2zx7tcfF5j+7SkqKHuyJdmHXh/ yyufXDktaUFypM3JoYbez5dOfOLGuTt/RQxYq82G9G2ILoN/3Iju4VgF0vWIb9mqRAKiTHzvorTn rp/32q2XT4sJhYiJX9rYbrcNz5BlUKSWdOnutSnVagF71AqvF3n5yD/kkPvh5b9WrvlYoEjHpAhQ BCgCXw+BCL38wEM3PXDHUsY8QNbebA6SduZE0rTPVhuZ1o062qSCtutTtbBh52HtDaq8hN4+l2qN ZPDz6YW0bkicICWO8f7nqVtfu3PZ17u2rzr6YH5jmtFIuG16dOSp7p6vOv5c9mskIq+Tjw/VRqmD OrqtIBHI/3ea7BFKmU6pUIvVKpl8TnrsgYKmS8ZHIWyTF0kHbM6/7MlFARo5L9ZLNGYH39RnWT4x rarLppTIJ0YHQ30/v7EH9bIxIa1Y6wanMV6ZCFrMLIovFFT3HqhsHXAwMQbVpWmJW0415TWYNkFG ze54L7fqT/tz0MugVj7/cV5tv7l1wDopMaKh25LT3FnRNbhyerzJ7ZGSEuxeidfndRazHmq3ncud p30oAhSBi4/AizctfOf3d4YrZYS9LDAVfKJZsORgM5E1Nl9aNzHp4LeUD6VaI8AQASYw6ZCChew3 EtkvJd3PvxeCFxGxSVTsSQDnlPTYw0/f/ZP5gbTY/IifaG5OiQ8Rr1692up2bjxQfsWM5Cj9mRIz gbotKo08NUxnVKvSEkLGhxlgZoUoFRNjQ8NQpDUmOFqvQh0CvU49MyHMYNSmBmsNKpmL45PDjBqd NCbMKIiZ7sHBwubOorbOEJ3q0tTYlkHbrqLqWXERyRFBvJjJiA4J0SrVcnVKuOFkTUu9ydRmGvzz LYsQABITpPYy3h2FtRkxwVOiQuwer4KRpEUal4xP2F9dn1/XnhIRPCchomvQ/HFB7T2XzYSGMu8R gvRqFMRRq6RJQahFKkoJN+pxP2ijCFAEKALfQgQmRQfftWhy7SCqXjK8y84hYBKx/ojydyPWH7qR UM9yMV5wHjK4kSfgk+kiq3Qc44WXEit2EH7E8TD1zq8XySXnJWIBK0hpUaEPLJ/z8h3LUk/XyAwg ribO++C6XfcvnYnMNqG2Z2DKU28/tWLmI1fNCeA5LvxQv99yZEVG0ryUQCUAXvgroGekCFAEKAJj gkBNjym7obeipat90AqigRdSIpK4vW6ZWObi3VIWviovbA+s7Xh53y7BLRPJXF63VCzBFpLRjQUg +LTOqZeIlUil3rSwsJQw3YK0pFDNWAWfr8sqveuFzQ0vP0S4DWURbn91R7NpYM8jt2oRM/qtbW9l l82MjUyPDnwyw7cWEjpxigBFgCLwHUJgyfPvWThX7jO3kfU2hUxy9+Kp1R3964+WfasxWDktNTXC 8K2+BDp5igBFgCJAETg3BDZmlx8ra37ixsvQfSgyfkFqzPLpKf/cm1PT/S1O51LLEf1xLuXZzg1H 2osiQBGgCFAEviEI9Frsf92StXR6yvfSiXbXEBMoJOL7Fk23DLrePHCKyhN/Q24VnQZFgCJAEaAI jBKB57edKG/vf/SaTKWvjs8ZK2decuTvbpjzwpGigpZvsek2ShToYRQBigBFgCLwP4PArpLmf+7M eeyWS+emDgkuf8qD99AVM5emR899dn2TmSRN00YRoAhQBCgCFIFvOAINXf33vfjBylkTH142e3iq n12devXOayeFG9MfeWFfdec3/Hro9CgCFAGKAEXgO47AyfreBX/dlJIUuf6nK0ZmIn+W20LUspPP 3rF8etrSX7+4evOxfkiQ0UYRoAhQBCgCFIFvGAJWzvP89uzMR/41JTzoowdv1KDo+IhG8tu+cMJ/ 3Z33u7X7p2ZE/uMHSzMTIuRiWiP0G3Zj6XQoAhQBisB3EgFopxyuaX1u0+FDpQ1Prlz05M3zSPTI p9uXchsO+6S06U9bj6H62vXTk6+ZPn52amRMkPY7iSS9aIoARYAiQBG4+Ah0Wux5DR1bsyveya2Z Gq57ctX3rpwc/4XTOhu3oYPF6V5/tGhDVml5tyVep5oyLnparCE5NjJMrlAoJR6PRyxCoRxi+4lE Iq/HI5FJ3ZxbKvPvkvh28SKR2OvxSmQSN+eSymS0F0WDfjfoXwp9btDn4WjYQSqTujh3l9lZ2dZT 0dZb2Nxd3d0/MVx/95Lp189KN6q+VEjrK7jNz4fQyy9s7Dla3ZTT0NljcXAOHjnSXqmb9/AsL2XI 4B7WzfIiiUjK826PiJfwEhGLQjEelCeHUBnP8x6RR8yLJSIx7UXRoN8N+pdCnxv0eThadvBC09kj 0cnFWrV0dmLM3KSIzNTomCDN2a3IUXGbfwivIPTbnLDknE6XVRAkDO9mWGKasSxexLzgFolkjIDg ExkPjWkWB8Ceg0UnZgU32ShwIjGq0dFeFA363aB/KfS5QZ+Ho2cHrUislktUcmmQWgm7aTS+0a/B baMZjh5DEaAIUAQoAhSBi44AVV+86LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+ C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQ BCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAE AowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG67 6LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiK AEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoA RSDACPw/jRlMVUNEDuMAAAAASUVORK5CYII= --Boundary_(ID_jMrgJjm3P28N1lOoqSfDcQ)-- From i-barreira@izenpe.net Wed May 2 02:17:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DE421F89F2 for ; Wed, 2 May 2012 02:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjupzvZkQTl2 for ; Wed, 2 May 2012 02:17:21 -0700 (PDT) Received: from correo.euskaltel.es (ektmail2mta2.euskaltel.es [212.55.8.119]) by ietfa.amsl.com (Postfix) with ESMTP id 85B0F21F89F1 for ; Wed, 2 May 2012 02:17:21 -0700 (PDT) Received: from ejlp024.ejgv ([194.30.48.247]) by ektmail2mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0M3E0040C1SPY580@ektmail2mta2.euskaltel.es> for pkix@ietf.org; Wed, 02 May 2012 11:17:13 +0200 (MEST) Received: from afe01.ejsarea.net (afe01 [10.200.192.14]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id q429HG59003641; Wed, 02 May 2012 11:17:16 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe01.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 02 May 2012 11:17:13 +0200 Date: Wed, 02 May 2012 11:17:12 +0200 From: i-barreira@izenpe.net In-reply-to: <4F9F7273.8040200@lockstep.com.au> To: swilson@lockstep.com.au, pkix@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B05276D42@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-class: urn:content-classes:message Thread-topic: [pkix] License fee for running a PKI Thread-index: Ac0nWiii/1hvgwF3S8WlYevHAT+KSwA6gSzg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <201204301803.q3UI3gPO021732@fs4113.wdf.sap.corp> <4F9F1C8F.5080405@e-net.lt> <4F9F7273.8040200@lockstep.com.au> X-OriginalArrivalTime: 02 May 2012 09:17:13.0303 (UTC) FILETIME=[5C2E2E70:01CD2844] Subject: Re: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 09:17:23 -0000 -----Mensaje original----- De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de Stephen Wilson Enviado el: martes, 01 de mayo de 2012 7:20 Para: pkix@ietf.org Asunto: Re: [pkix] License fee for running a PKI Yes, in Europe, for all parties to fully enjoy the protections of qualified e-signatures laws, the CAs have to be accredited under a recognised scheme like "tScheme". Well, not always and not in every EU country I thought the same thing applied in the very first digital signatures regime in Utah? I thought CAs there had to be licensed, and part of that was audit by a recognised accounting firm? A similar scheme technically applies in Hong Kong where the CA Recognition Authority is supposed to accredit CAs under the E-Tansactions Ordinance. I say "technically" because participation in CARO and all similay systems even in Europe is weak. There are costs involved and the cost-benefit remains uncertain while usage of certificates in open commerce remains low. On the other hand, use of certificates in closed commerce is healthy but does not require independent homolugation because specific contracts apply. If there is cause for government endorsement of digital certificates, then it follows that a conformance assessment regime is necessary, and there would generally be costs associated with participating. Costs of doing business, just like the need for banks, medical establishments, airplane manufacturers and so on to be audited under all sorts of rules. Cheers, Steve Wilson Lockstep http://lockstep.com.au From hallam@gmail.com Wed May 2 19:45:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12E21E802A for ; Wed, 2 May 2012 19:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA3G0f31Hewa for ; Wed, 2 May 2012 19:45:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F41C21E8018 for ; Wed, 2 May 2012 19:45:21 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2103140obb.31 for ; Wed, 02 May 2012 19:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DocDiMB9uAKh19qw5h76QqA+hcsyHFm9+JpO4Qdie2E=; b=07rBqC2trp6kQvf4jfVoVA2myqP93lVm1KUtPK4sgwFaNjRtqpNAccJYWrxAF1p5mV ksM+16GLByylFUwctdlUX3oQv7iS9J7kzqUMCxcNxS8Eo+cy9K5FNMU4NNIl+owHcals 5BOLj5fjIEtZpsc1CYVv0TrEfmzNqPacYMeyPweO3LiDZ19T8KrNqsZlZYvDKR7vgPwd n/qAVot9H8+yvfiU+KOt7uT6u9lev7CDlpSElebPAaGKva5mhGeSGxYn+jTx0XI5hUfz pIo65Q57HJd9xB7/AUUKevlDrJsBA7RUsxJALyhEEEtTqlZcVAZSHCvXSJ4fET6oHVU7 0UxA== MIME-Version: 1.0 Received: by 10.182.174.71 with SMTP id bq7mr650050obc.29.1336013120848; Wed, 02 May 2012 19:45:20 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Wed, 2 May 2012 19:45:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 May 2012 22:45:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] TLS Security Policy Specification X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 02:45:22 -0000 On Mon, Apr 30, 2012 at 10:48 AM, Adam Langley wrote: > On Fri, Apr 27, 2012 at 2:48 PM, Phillip Hallam-Baker wrote: >> The approach is slightly broader in principle but as the draft >> explains, stapling is the only feature for which a certificate based >> security policy is currently relevant. > > Generally, looks good to me. > > For the minVersion, using x to mean TLS 1.(x-1) seems unnecessarily > complex. Why not have x mean TLS 1.x? (i.e. 0 -> TLS 1.0, 1 -> TLS 1.1 > etc?) The problem is that TLS 1.0 has a version ID of 3,1 because 3,0 was taken for SSL. OK so if we never update the major version number it doesn't matter. But if we did we would have a new policy oid for TLS 2.0 and that would probably start from identifier {4,0} > I think the following client behaviour needs to be specified: > > 1) what happens when minVersion is greater than what I support? Should > I abort, or carry on as best I can? You MUST conclude that there is a policy violation because the site has said it will support the higher version and it isn't doing that. What action you then take would be for client policy. I would recommend abort in that case as it is really very rare for a version number to go backwards like that... but it is not a compatibility issue so it is for the client policy to decide. > 2) what happens when extensions contains a value that I don't know > about? Should I ignore it? Ignore it. I will make that explicit. The only thing that the policy says is that the extension will be offered. If you don't understand the extension you MUST NOT ask for it anyway as it would probably break you anyway. -- Website: http://hallambaker.com/ From internet-drafts@ietf.org Sun May 6 10:57:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D7721F853F; Sun, 6 May 2012 10:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cVY7TE5gR7x; Sun, 6 May 2012 10:57:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2516F21F84DF; Sun, 6 May 2012 10:57:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120506175753.17999.97069.idtracker@ietfa.amsl.com> Date: Sun, 06 May 2012 10:57:53 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-17.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 17:57:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Internet X.509 Public Key Infrastructure -- HTTP Transpo= rt for CMP Author(s) : Tomi Kause Martin Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-17.txt Pages : 14 Date : 2012-05-06 This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols= -17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-= 17.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/ From internet-drafts@ietf.org Mon May 7 08:17:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F6021F8613; Mon, 7 May 2012 08:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKFA6c4saE5k; Mon, 7 May 2012 08:17:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C107B21F85AC; Mon, 7 May 2012 08:17:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507151754.11014.72797.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 08:17:54 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-18.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 15:17:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Internet X.509 Public Key Infrastructure -- HTTP Transpo= rt for CMP Author(s) : Tomi Kause Martin Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-18.txt Pages : 15 Date : 2012-05-07 This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols= -18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-= 18.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/ From turners@ieca.com Mon May 7 09:32:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8821321F8664 for ; Mon, 7 May 2012 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.222 X-Spam-Level: X-Spam-Status: No, score=-102.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHT4Uyjfg0eA for ; Mon, 7 May 2012 09:32:59 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.21.22]) by ietfa.amsl.com (Postfix) with ESMTP id C0D2621F866A for ; Mon, 7 May 2012 09:32:55 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 706B2550689BD; Mon, 7 May 2012 11:32:55 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 64EE255068980 for ; Mon, 7 May 2012 11:32:55 -0500 (CDT) Received: from [71.191.4.188] (port=43282 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SRQrn-0007Ay-1B for pkix@ietf.org; Mon, 07 May 2012 11:32:55 -0500 Message-ID: <4FA7F936.5040305@ieca.com> Date: Mon, 07 May 2012 12:32:54 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20120507151754.11014.72797.idtracker@ietfa.amsl.com> In-Reply-To: <20120507151754.11014.72797.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-71-191-4-188.washdc.east.verizon.net (thunderfish.local) [71.191.4.188]:43282 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-18.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 16:32:59 -0000 The last two versions of this draft were produced as a result of the APPSDIR review. spt On 5/7/12 11:17 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP > Author(s) : Tomi Kause > Martin Peylo > Filename : draft-ietf-pkix-cmp-transport-protocols-18.txt > Pages : 15 > Date : 2012-05-07 > > This document describes how to layer the Certificate Management > Protocol over HTTP. It is the "CMPtrans" document referenced in RFC > 4210 and therefore updates the reference given therein. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-18.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-18.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From iesg-secretary@ietf.org Mon May 7 10:02:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3295D21F85ED; Mon, 7 May 2012 10:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwUwdIa3YcXs; Mon, 7 May 2012 10:02:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50F421F843E; Mon, 7 May 2012 10:02:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120507170250.4232.83847.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2012 10:02:50 -0700 Cc: pkix@ietf.org Subject: [pkix] Last Call: (Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP) to Proposed Standard X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 17:02:51 -0000 The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/ballot/ No IPR declarations have been submitted directly on this I-D. From housseine@rejouan.com Thu May 10 12:56:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B377D21F86CF for ; Thu, 10 May 2012 12:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR1B5CdH3TSU for ; Thu, 10 May 2012 12:56:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9021F85FC for ; Thu, 10 May 2012 12:56:21 -0700 (PDT) Received: from oxusltgw05.schlund.de (oxusltgw05.lxa.perfora.net [172.19.206.7]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MUYX5-1ScIcR11gx-00RPCW; Thu, 10 May 2012 15:56:20 -0400 Date: Thu, 10 May 2012 15:56:20 -0400 (EDT) From: "housseine@rejouan.com" To: pkix@ietf.org Message-ID: <958574276.250849.1336679780234.JavaMail.open-xchange@email.1and1.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_250848_775883135.1336679780179" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v6.20.0-Rev36 X-Provags-ID: V02:K0:oxSmZOicAVayTgxjjQk1jbwGKMrKoFuzutHXEOIAKGn ynV9pfb78bS9OePVkWu+TS2Yk+hxbm6ARmSu+CxoGeeNacyee0 tPY2lEsYZ7kVDWAq2iDHHIPxHlqloskxyn3q/1J3Eo27Y8U6V5 IlbSdsYjN/Ucd8hFcSIcvw2ucqYXNokg9n/h3nWD/Kd2gOOkHr 7BsPN6J3ulDvFR7NffkqG7LRpevRc1uFHQIP1rPAlHjpkG54/S JQfmFtkf4NaR3thPMgxJAHwt0Juk4nfUWVPVxkjCHzA4A5y9rn Vr1f4FSgndo1441cA4oFmsaexDQoyq+5dLSog+WHotw0LXyPut v/QgcEfSKvvDbDM9I5T0MvZr3j8tgQRO8bY1j3KbiiVTPWsNHe wjUYywd4e29liNIdcWFFdbqqriR1Ijnb5wo5HVbyLY2L5WjGlN XBeLU Subject: [pkix] Question about the "Name Constraints" extension in OpenSSL X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "housseine@rejouan.com" List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 20:14:40 -0000 ------=_Part_250848_775883135.1336679780179 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi All, I am sorry to bother you but I am kind of stuck in how to setup the minimum and/or maximum for "Name Constraints" in OpenSSL mentioned in this document RFC 5280 , paragraph " 4.2.1.10. Name Constraints " I looked over the net but I couldn't find any thing about the syntax that I can use in openssl config file: I have the following setup but I need to set the minimum to 0 and I don't know the syntax. Everything I tried failed. nameConstraints = critical, excluded;URI:.mydomain.com;DNS:mydomain.com Can you please help or can you point me to some one who can help? Thank you very much Housseine ------=_Part_250848_775883135.1336679780179 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi All,

I am sorry to bother you but I am kind of stuck in how to setup the minimum and/or maximum for "Name Constraints" in OpenSSL mentioned in this document RFC 5280 , paragraph " 4.2.1.10. Name Constraints "

 

I looked over the net but I couldn't find any thing about the syntax that I can use in openssl config file:

I have the following setup but I need to set the minimum to 0 and I don't know the syntax. Everything I tried failed. 

 

nameConstraints = critical, excluded;URI:.mydomain.com;DNS:mydomain.com 

 

 

Can you please help or can you point me to some one who can help?

 

Thank you very much

Housseine

------=_Part_250848_775883135.1336679780179-- From eabalea@gmail.com Thu May 10 15:48:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4931621F8498 for ; Thu, 10 May 2012 15:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w3xPMDReqDT for ; Thu, 10 May 2012 15:48:02 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8521F8497 for ; Thu, 10 May 2012 15:48:02 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1623670ggm.31 for ; Thu, 10 May 2012 15:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bdH+lFs1uQWTI/rSfb4y0S4hT8IAQiGP5FSDvxLnsfY=; b=fdw/Vi+tu3KqkhySjb8fSIw3Px5cagZXij/t5xm90ZNc69bT40hJFmE99aFddd0JgK 7dZ26q1VLO/TOTSHERosvftgcftbqDEGToSrOFJl6VhGH+H+d+FRHb5GT6ivOyC3UIdr aYGJd3+9Ih7xRSZ5Ovmm/9ZXfdXbf/MY7E3Z4ebD4HPy+BAJ/KHZlmioW9mKRGw5erLv zmhQjUI3SqyeHWkqEZoZwoApB4ayzGKmyLDV2popm5xWa8P3/SWt+Zc0uCxoNSk15NCE pYl3L/8y00VtCQZq6R7nwLvJL/mVlU/Lo5jFq09FN/8KpbnHT86xrntVesK5spFcJnUq CmMA== MIME-Version: 1.0 Received: by 10.236.153.104 with SMTP id e68mr7630578yhk.36.1336690081713; Thu, 10 May 2012 15:48:01 -0700 (PDT) Received: by 10.236.103.4 with HTTP; Thu, 10 May 2012 15:48:01 -0700 (PDT) In-Reply-To: <958574276.250849.1336679780234.JavaMail.open-xchange@email.1and1.com> References: <958574276.250849.1336679780234.JavaMail.open-xchange@email.1and1.com> Date: Fri, 11 May 2012 00:48:01 +0200 Message-ID: From: Erwann Abalea To: "housseine@rejouan.com" Content-Type: multipart/alternative; boundary=20cf302efd5e7ecd5b04bfb669ea Cc: pkix@ietf.org Subject: Re: [pkix] Question about the "Name Constraints" extension in OpenSSL X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 22:48:07 -0000 --20cf302efd5e7ecd5b04bfb669ea Content-Type: text/plain; charset=UTF-8 2012/5/10 housseine@rejouan.com > ** > > Hi All, > > I am sorry to bother you but I am kind of stuck in how to setup the * > minimum* and/or *maximum* for "Name Constraints" in OpenSSL mentioned in > this document RFC 5280, paragraph " > * 4.2.1.10. Name Constraints * " > > > I looked over the net but I couldn't find any thing about the syntax that > I can use in openssl config file: > > I have the following setup but I need to set the minimum to 0 and I don't > know the syntax. Everything I tried failed. > > > *nameConstraints = critical, excluded;URI:.mydomain.com;DNS:mydomain.com > * > > > Can you please help or can you point me to some one who can help? > openssl-users at openssl.org But I think the minimum is already set to 0 by default, and the maximum omitted. If you don't see the "minimum" value when decoding the extension, then it means its value is 0 (which is the default, so it's not encoded in DER). -- Erwann. --20cf302efd5e7ecd5b04bfb669ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/5/10 housseine@rejouan.com <housseine@rejouan.com>=
=20 =20 =20

Hi All,

I am sorry to bother you but I am kind of stuck in how to setup the minimum and/or maximum for "Name Constraints" in OpenSSL mentioned in this document RFC 5280 , paragraph " 4.2.1.10. Name Constraints "


I looked over the net but I couldn't find any= thing about the syntax that I can use in openssl config file:

I have the following setup but I need to set the = minimum to 0 and I don't know the syntax. Everything I tried failed.=C2= =A0


nameConstraints =3D critical, excluded;URI:.mydomain.com;DNS:mydomain.com=C2=A0


Can you please help or can you point me to some o= ne who can help?


openssl-users a= t openssl.org

But I think t= he minimum is already set to 0 by default, and the maximum omitted.
If you don't see the "minimum" value when decoding the e= xtension, then it means its value is 0 (which is the default, so it's n= ot encoded in DER).

--
Erwann.
--20cf302efd5e7ecd5b04bfb669ea-- From housseine@rejouan.com Thu May 10 20:38:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D1C9E8005 for ; Thu, 10 May 2012 20:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsp15rBupCht for ; Thu, 10 May 2012 20:38:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 55BD59E8001 for ; Thu, 10 May 2012 20:38:40 -0700 (PDT) Received: from Housseine-Rejouans-MacBook-Pro-17.local (173-228-95-232.dsl.static.sonic.net [173.228.95.232]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M3RJA-1SB1HH45aK-00rHbI; Thu, 10 May 2012 23:38:38 -0400 Message-ID: <4FAC89BB.50604@rejouan.com> Date: Thu, 10 May 2012 20:38:35 -0700 From: Housseine Rejouan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Erwann Abalea References: <958574276.250849.1336679780234.JavaMail.open-xchange@email.1and1.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000204010708000909030209" X-Provags-ID: V02:K0:jNhNTKbM9O7NeFIL5Bjv0peMGI8teIEUQfxo9yM2h0q 7TwHPAfeiywKrEaOzcVva9Qxz9gT2QbKuITShxd3GpcuVmRXIv Sp8PaN2gnqpSa/UOX8hVwdXpwmkGFbzrl14bZLJwErPE4UHzjY jC+0/NYWJJN1YWd9akq9x20jC+HjFhpwfIy02tkCqNCq4CBKhW FzNheu/TWgxKpWdExwMB29mDdh0QHhV1XOWPYSPM4AT0ZSRad+ fubgL+31Uep4wEyxdLEfy3ix4yT4suMjw9QFAe9eYi9fsNb/Ap JCfm9GBf+BE/8+KFgerQFqj6slOirH8+Kg4yRnDujPph2LKpW2 5oBqr+hDeQq6dMN1UwhiNLv99oRyQSPEda2rdbWnBwxZ7J2WzA Be67UDF37FylQ== Cc: pkix@ietf.org Subject: Re: [pkix] Question about the "Name Constraints" extension in OpenSSL X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 03:38:45 -0000 This is a multi-part message in MIME format. --------------000204010708000909030209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Erwann, Thank you for your prompt response. Yes, you are right the default value is set to 0. I am looking also to be able to set this in future to any value we need to. It should be a way to set it up in the openssl configuration file. and that's what I am looking for. Thank you Housseine On 5/10/12 3:48 PM, Erwann Abalea wrote: > > 2012/5/10 housseine@rejouan.com > > > > Hi All, > > I am sorry to bother you but I am kind of stuck in how to setup > the *minimum* and/or *maximum* for "Name Constraints" in OpenSSL > mentioned in this document RFC 5280 > , > paragraph " *4.2.1.10. Name Constraints * " > > > I looked over the net but I couldn't find any thing about the > syntax that I can use in openssl config file: > > I have the following setup but I need to set the minimum to 0 and > I don't know the syntax. Everything I tried failed. > > > *nameConstraints = critical, excluded;URI:.mydomain.com > ;DNS:mydomain.com * > > > Can you please help or can you point me to some one who can help? > > > openssl-users at openssl.org > > But I think the minimum is already set to 0 by default, and the > maximum omitted. > If you don't see the "minimum" value when decoding the extension, then > it means its value is 0 (which is the default, so it's not encoded in > DER). > > -- > Erwann. --------------000204010708000909030209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Erwann,
Thank you for your prompt response. Yes, you are right the default value is set to 0.
I am looking also to be able to set this in future to any value we need to.
It should be a way to set it up in the openssl configuration file. and that's what I am looking for.
Thank you
Housseine


On 5/10/12 3:48 PM, Erwann Abalea wrote:

2012/5/10 housseine@rejouan.com <housseine@rejouan.com>

Hi All,

I am sorry to bother you but I am kind of stuck in how to setup the minimum and/or maximum for "Name Constraints" in OpenSSL mentioned in this document RFC 5280 , paragraph " 4.2.1.10. Name Constraints "


I looked over the net but I couldn't find any thing about the syntax that I can use in openssl config file:

I have the following setup but I need to set the minimum to 0 and I don't know the syntax. Everything I tried failed. 


nameConstraints = critical, excluded;URI:.mydomain.com;DNS:mydomain.com 


Can you please help or can you point me to some one who can help?


openssl-users at openssl.org

But I think the minimum is already set to 0 by default, and the maximum omitted.
If you don't see the "minimum" value when decoding the extension, then it means its value is 0 (which is the default, so it's not encoded in DER).

--
Erwann.
--------------000204010708000909030209-- From eabalea@gmail.com Fri May 11 01:07:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5787D21F845D for ; Fri, 11 May 2012 01:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcQqhJzQtbMD for ; Fri, 11 May 2012 01:07:23 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1AA21F845B for ; Fri, 11 May 2012 01:07:23 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1883771ggm.31 for ; Fri, 11 May 2012 01:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bGQcN6EituXrJb222W5BzC7TWYecl8Al6CfJlI5HC9s=; b=kckfWzfKUdrhREVFEUVF5yn8Ak1EJBrQOiFIqXPnheJAjVnmd5QJgukJgA7txIfeDW Q6FG7HnDOe7334ik4qFUB8qy6kWsL+tFh6bvqzOYxZ6kXcPeraVxqzjd6LqOxAgE5Gmw uq/2onwlS0fWchrhwab1IYe8qV78TD2PHkEBiCIcsJsofPktl9UhhLQJLcnVGR6r+Q0U vSl+Ji4SLVquM1BH70sQrhmZsHoehKcXFR6WULrKD3PHzlTYcCq8Q7YH18+DVmyB7zne d0Kblhmpms0WMv5wOGszzFax9Qo4BpNkQXKFYG7asIq3D95XsRwpHxoY2CB3oONPz6KT u5Dw== MIME-Version: 1.0 Received: by 10.236.153.104 with SMTP id e68mr9204949yhk.36.1336723642902; Fri, 11 May 2012 01:07:22 -0700 (PDT) Received: by 10.236.103.4 with HTTP; Fri, 11 May 2012 01:07:22 -0700 (PDT) In-Reply-To: <4FAC89BB.50604@rejouan.com> References: <958574276.250849.1336679780234.JavaMail.open-xchange@email.1and1.com> <4FAC89BB.50604@rejouan.com> Date: Fri, 11 May 2012 10:07:22 +0200 Message-ID: From: Erwann Abalea To: Housseine Rejouan Content-Type: multipart/alternative; boundary=20cf302efd5ee5e9f904bfbe394b Cc: pkix@ietf.org Subject: Re: [pkix] Question about the "Name Constraints" extension in OpenSSL X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:07:24 -0000 --20cf302efd5ee5e9f904bfbe394b Content-Type: text/plain; charset=UTF-8 Bonjour, 2012/5/11 Housseine Rejouan > Thank you for your prompt response. Yes, you are right the default value > is set to 0. > You really should ask this question to the right mailing list, as indicated in my answer: openssl-users at openssl.org. > I am looking also to be able to set this in future to any value we need to. > It should be a way to set it up in the openssl configuration file. and > that's what I am looking for. > Reading OpenSSL 1.0.0e source code tells me the minimum and maximum values can't be set by configuration file. OpenSSL, when asked to verify a certificate, will even stop with an error if minimum or maximum are set. Minimum and maximum values are useless for your examples (dnsName and emailAddress), as they only apply to "The Great Directory" proposed by X.500, and don't fit at all with IETF's view of the world. More, since PKIX states that minimum MUST be zero and maximum MUST be absent, asking in this mailing list how to set different values for a non-IETF product is awkward. -- Erwann. --20cf302efd5ee5e9f904bfbe394b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour,

2012/5/11 Housseine Rejouan <housseine@rejouan.com> =20 =20 =20
Thank you for your prompt response. Yes, you are right the default value is set to 0.

You really should ask= this question to the right mailing list, as indicated in my answer: openss= l-users at openssl.org.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I am looking also to be able to set this in future to any value we need to.
It should be a way to set it up in the openssl configuration file. and that's what I am looking for.

Reading OpenSSL 1.0.0e source code tells me the minimum and max= imum values can't be set by configuration file.
OpenSSL, when asked = to verify a certificate, will even stop with an error if minimum or maximum= are set.

Minimum and maximum values are useless for your examples (dnsName and e= mailAddress), as they only apply to "The Great Directory" propose= d by X.500, and don't fit at all with IETF's view of the world.
More, since PKIX states that minimum MUST be zero and maximum MUST be absen= t, asking in this mailing list how to set different values for a non-IETF p= roduct is awkward.

--
Erwann.
--20cf302efd5ee5e9f904bfbe394b-- From internet-drafts@ietf.org Tue May 15 12:18:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607E821F8889; Tue, 15 May 2012 12:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKu3JLHtQyDa; Tue, 15 May 2012 12:18:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2EA21F882D; Tue, 15 May 2012 12:18:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515191846.6697.28149.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 12:18:46 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-19.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:18:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : Internet X.509 Public Key Infrastructure -- HTTP Transpo= rt for CMP Author(s) : Tomi Kause Martin Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-19.txt Pages : 14 Date : 2012-05-15 This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols= -19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-= 19.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols/ From martin.peylo@nsn.com Tue May 15 12:21:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C31B21F88B9 for ; Tue, 15 May 2012 12:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNmBQdQjXfqd for ; Tue, 15 May 2012 12:21:49 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2272521F88AD for ; Tue, 15 May 2012 12:21:48 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4FJLjKX004064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 15 May 2012 21:21:48 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4FJLcJa024792 for ; Tue, 15 May 2012 21:21:45 +0200 Received: from FIESEXC006.nsn-intra.net ([10.159.0.14]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 May 2012 21:21:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 May 2012 22:21:24 +0300 Message-ID: <3BF363C82C184B46930A905352C2013F021E3A4D@FIESEXC006.nsn-intra.net> In-Reply-To: <20120515191846.6697.28149.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-19.txt Thread-Index: Ac0yz5P+uVSxM/8pTJipsnvOgoe8AAAAAibA References: <20120515191846.6697.28149.idtracker@ietfa.amsl.com> From: "Peylo, Martin (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 May 2012 19:21:30.0539 (UTC) FILETIME=[EE8C17B0:01CD32CF] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1661 X-purgate-ID: 151667::1337109708-00001F01-FF91F000/0-0/0-0 Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-19.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:21:50 -0000 This new draft version was produced due to the Gen-ART review by Christer Holmberg. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org Sent: Tuesday, May 15, 2012 10:19 PM To: i-d-announce@ietf.org Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-cmp-transport-protocols-19.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP Author(s) : Tomi Kause Martin Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-19.txt Pages : 14 Date : 2012-05-15 This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protoc ols-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protoco ls-19.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-cmp-transport-protocols / _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From internet-drafts@ietf.org Tue May 15 22:03:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5C721F870B; Tue, 15 May 2012 22:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lya4UfGM4GnO; Tue, 15 May 2012 22:03:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F8721F86F1; Tue, 15 May 2012 22:03:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120516050326.12393.25067.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 22:03:26 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 05:03:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : S/MIME Capabilities for Public Key Definitions Author(s) : Jim Schaad Filename : draft-ietf-pkix-pubkey-caps-07.txt Pages : 25 Date : 2012-05-15 This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is is detailed in Online Certificate Status Protocol Algorithm Agility (RFC 6277). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ From mrex@sap.com Wed May 16 04:26:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F23921F8767 for ; Wed, 16 May 2012 04:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.095 X-Spam-Level: X-Spam-Status: No, score=-10.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMCQqZPID9je for ; Wed, 16 May 2012 04:26:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 850DF21F8661 for ; Wed, 16 May 2012 04:26:29 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q4GBQRIl024570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 May 2012 13:26:28 +0200 (MEST) From: Martin Rex Message-Id: <201205161126.q4GBQPdR023464@fs4113.wdf.sap.corp> To: pkix@ietf.org Date: Wed, 16 May 2012 13:26:25 +0200 (MEST) In-Reply-To: <20120516050326.12393.25067.idtracker@ietfa.amsl.com> from "internet-drafts@ietf.org" at May 15, 12 10:03:26 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Subject: Re: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 11:26:30 -0000 internet-drafts@ietf.org wrote: > > Title : S/MIME Capabilities for Public Key Definitions > Author(s) : Jim Schaad > Filename : draft-ietf-pkix-pubkey-caps-07.txt I'm slighty confused: http://tools.ietf.org/html/draft-ietf-pkix-pubkey-caps-07#section-3.1 DSAKeyCapabilities ::= CHOICE { keySizes [0] SEQUENCE { minKeySize DSAKeySize, maxKeySize DSAKeySize OPTIONAL, maxSizeP [1] INTEGER OPTIONAL, maxSizeQ [2] INTEGER OPTIONAL, maxSizeG [3] INTEGER OPTIONAL }, keyParams [1] pk-dsa.&Params } keyParams contains the exact set of DSA for the key used to sign the message. This field is provided for completeness and to match the fields for Elliptical Curve, however it is expected that usage of this field is extremely rare. keyParams is not marked OPTIONAL, so what does "however it is expected that usage of this field is extremely rare" mean? Is the OPTIONAL tag missing, or is an explicit NULL supposed to indicate that the field is unused? -Martin From James.H.Manger@team.telstra.com Wed May 16 05:16:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22A221F8540 for ; Wed, 16 May 2012 05:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMXjKiZoL1te for ; Wed, 16 May 2012 05:16:27 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8995821F8539 for ; Wed, 16 May 2012 05:16:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,603,1330866000"; d="scan'208";a="74040189" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 16 May 2012 22:16:18 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6712"; a="62794234" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 16 May 2012 22:16:17 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 16 May 2012 22:16:17 +1000 From: "Manger, James H" To: "mrex@sap.com" , "pkix@ietf.org" Date: Wed, 16 May 2012 22:16:15 +1000 Thread-Topic: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-07.txt Thread-Index: Ac0zVsO0O3wCE9wuQE2Em1FSeiuldgABmw1g Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2E1B5BF@WSMSG3153V.srv.dir.telstra.com> References: <20120516050326.12393.25067.idtracker@ietfa.amsl.com> from "internet-drafts@ietf.org" at May 15, 12 10:03:26 pm <201205161126.q4GBQPdR023464@fs4113.wdf.sap.corp> In-Reply-To: <201205161126.q4GBQPdR023464@fs4113.wdf.sap.corp> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 12:16:27 -0000 It is in a CHOICE. Presumably it is expected that keySizes is almost always= chosen.=20 -- James Manger -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Wednesday, 16 May 2012 9:26 PM To: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-07.txt internet-drafts@ietf.org wrote: > > Title : S/MIME Capabilities for Public Key Definitions > Author(s) : Jim Schaad > Filename : draft-ietf-pkix-pubkey-caps-07.txt I'm slighty confused: http://tools.ietf.org/html/draft-ietf-pkix-pubkey-caps-07#section-3.1 DSAKeyCapabilities ::=3D CHOICE { keySizes [0] SEQUENCE { minKeySize DSAKeySize, maxKeySize DSAKeySize OPTIONAL, maxSizeP [1] INTEGER OPTIONAL, maxSizeQ [2] INTEGER OPTIONAL, maxSizeG [3] INTEGER OPTIONAL }, keyParams [1] pk-dsa.&Params } keyParams contains the exact set of DSA for the key used to sign the message. This field is provided for completeness and to match the fields for Elliptical Curve, however it is expected that usage of this field is extremely rare. keyParams is not marked OPTIONAL, so what does "however it is expected that usage of this field is extremely rare" mean? Is the OPTIONAL tag missing, or is an explicit NULL supposed to indicate that the field is unused? -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Wed May 16 06:09:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862CD21F86A8 for ; Wed, 16 May 2012 06:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.096 X-Spam-Level: X-Spam-Status: No, score=-10.096 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwcle0F1S0fE for ; Wed, 16 May 2012 06:09:23 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CB3C021F86A7 for ; Wed, 16 May 2012 06:09:22 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4GD9Kqg022907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2012 15:09:21 +0200 (MEST) From: Martin Rex Message-Id: <201205161309.q4GD9JRb029199@fs4113.wdf.sap.corp> To: James.H.Manger@team.telstra.com (Manger James H) Date: Wed, 16 May 2012 15:09:19 +0200 (MEST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2E1B5BF@WSMSG3153V.srv.dir.telstra.com> from "Manger, James H" at May 16, 12 10:16:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:09:23 -0000 Manger, James H wrote: > > It is in a CHOICE. Presumably it is expected that keySizes > is almost always chosen. Thanks for the pointer -- since the structure definition was not in sight after reading the description of "keyParams", I missed the CHOICE at the beginning. > > keyParams is not marked OPTIONAL, so what does "however it is expected that > usage of this field is extremely rare" mean? s/this field/this CHOICE/ might have provided enough redundancy to prevent my confusion. -Martin From ietf@augustcellars.com Wed May 16 10:26:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F52B21F86F7 for ; Wed, 16 May 2012 10:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aEdaLAxhQ92 for ; Wed, 16 May 2012 10:26:48 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5072021F86A2 for ; Wed, 16 May 2012 10:26:48 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E451D2CA23 for ; Wed, 16 May 2012 10:26:47 -0700 (PDT) From: "Jim Schaad" To: References: <20120516050326.12393.25067.idtracker@ietfa.amsl.com> In-Reply-To: <20120516050326.12393.25067.idtracker@ietfa.amsl.com> Date: Wed, 16 May 2012 10:25:42 -0700 Message-ID: <011a01cd3388$ebfd5770$c3f80650$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQNI3eNwxVU+8WLF795gCJLiWjkYsZPVVfcQ Content-Language: en-us Subject: [pkix] FW: I-D Action: draft-ietf-pkix-pubkey-caps-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:26:49 -0000 This update has been made to address some final IESG comments. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, May 15, 2012 10:03 PM > To: i-d-announce@ietf.org > Cc: pkix@ietf.org > Subject: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public-Key Infrastructure (X.509) Working > Group of the IETF. > > Title : S/MIME Capabilities for Public Key Definitions > Author(s) : Jim Schaad > Filename : draft-ietf-pkix-pubkey-caps-07.txt > Pages : 25 > Date : 2012-05-15 > > This document defines a set of Secure/Multipurpose Internet Mail > Extensions (S/MIME) Capability types for ASN.1 encoding for the > current set of public keys defined by the PKIX working group. This > facilitates the ability for a requester to specify information on the > public keys and signature algorithms to be used in responses. An > example of where this is used is is detailed in Online Certificate > Status Protocol Algorithm Agility (RFC 6277). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-07.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From hallam@gmail.com Wed May 16 23:38:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5216721F85CD; Wed, 16 May 2012 23:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Heuw1u2wPDu; Wed, 16 May 2012 23:38:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B814C21F85BE; Wed, 16 May 2012 23:38:32 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2524219obb.31 for ; Wed, 16 May 2012 23:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u8/sCIPi5QuW+yTnfU2NSAXtM9YjFLDh+jiQV2igsmc=; b=syhdvgUVRL0Fv41+jDfyzsesi530upPhs3KG8fkCy6EdYoe4cIDFfFvVZbDLWZ+ut1 WICfvd4HvalTXHN9i4RnAetXY6ZnM/QdWMeO+LJ7Nuh4wqLTu5vfexZ2S+qh7s4Tz9SD noYApyUuBqy1+l95izsVkZsaqXqXspP7Iw5luSmhlH0vuEdhdbyengLDLzqwrIL2Iofh vR3/BrwhcTo9+Y7YljngBV9R4BTdH8u+NIN/T1mZFPIxU5cOHE85p8weEHwCCpxeHlbU 5fnCG1YUJYT2JsS+1pkk1oWOIx+OCFDBzziqCnS1P3A+sRsrDDa12jhA8CNkCVxcU2ZD ZFAA== MIME-Version: 1.0 Received: by 10.182.245.17 with SMTP id xk17mr5310676obc.66.1337236712316; Wed, 16 May 2012 23:38:32 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Wed, 16 May 2012 23:38:32 -0700 (PDT) In-Reply-To: References: <4F72C59A.90900@KingsMountain.com> Date: Thu, 17 May 2012 16:38:32 +1000 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF PKIX WG , IETF Security Area Advisory Group Subject: Re: [pkix] [saag] fyi: CA/Browser Forum (CABF) reform deliberations + Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 06:38:34 -0000 SK is a TTP system as the notaries are still trusted to provide availability even if the other aspects of operation are cryptographically constrained against default. A group of notaries could collude to establish a cartel and extract functional pricing for their services if there was a sufficiently large number of relying parties. Alternatively they can simply publish a key for party X and then ransom it to the legitimate owner of the domain. SK is a silly, silly scheme that should be laughed off the stage. It punts on all the hard problems of PKI by asserting an administrative model that is ludicrous. 'google.com' must be worth a couple of billion dollars at least. I cannot see anyone with a valuable domain name risking it to a scheme that has revocation mechanism in case of administrative error. 'Don't make mistakes' is not a viable administrative approach. On Wed, Mar 28, 2012 at 6:10 PM, Ben Laurie wrote: > > > On Wed, Mar 28, 2012 at 8:02 AM, =JeffH > wrote: >> >> The CA/Browser Forum (CABF) was mentioned a few times during this very >> interesting presentation in the PKIX session at IETF-83 Paris yesterday... >> >> Trust-Related Activities: >> Internet Certification Authorities >> Revocation and SSL Replacements/Enhancements >> https://www.ietf.org/proceedings/83/slides/slides-83-pkix-10.pdf > > > Hmmm... > > a) Doesn't mention Certificate Transparency. > > b) Thinks Sovereign Keys (and presumably, had they mentioned it, CT) is a > TTP, which is incorrect. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ From iesg-secretary@ietf.org Thu May 17 09:15:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2837321F8686; Thu, 17 May 2012 09:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bKSmMdGF3tG; Thu, 17 May 2012 09:15:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B03121F86A4; Thu, 17 May 2012 09:15:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120517161548.26743.57520.idtracker@ietfa.amsl.com> Date: Thu, 17 May 2012 09:15:48 -0700 Cc: pkix mailing list , pkix chair , RFC Editor Subject: [pkix] Document Action: 'S/MIME Capabilities for Public Key Definitions' to Informational RFC (draft-ietf-pkix-pubkey-caps-07.txt) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 16:15:49 -0000 The IESG has approved the following document: - 'S/MIME Capabilities for Public Key Definitions' (draft-ietf-pkix-pubkey-caps-07.txt) as Informational RFC This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ Technical Summary This document defines a set of S/MIME Capability types for ASN.1 encoding for the current set of public key algorithms identified in the PKIX working group. This enables a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is the OCSP Agility draft. Working Group Summary There were no significant issues about the document that were raised during the WG process, as such the changes represent the consensus of the active participants on the document Document Quality No known implementations of the work currently exist. The author does not know if there has been any active work in getting the algorithm agility work for OCSP rolled out. Personnel Document Shepherd: Stephen Kent. Responsible Area Director: Sean Turner. From anders.rundgren@telia.com Sun May 20 12:05:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F24D21F8604 for ; Sun, 20 May 2012 12:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNkUXh4uPQHe for ; Sun, 20 May 2012 12:05:25 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id DC29E21F85CF for ; Sun, 20 May 2012 12:05:24 -0700 (PDT) Received: from [192.168.0.203] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4FAE329400284779; Sun, 20 May 2012 21:05:21 +0200 Message-ID: <4FB94067.4010106@telia.com> Date: Sun, 20 May 2012 21:05:11 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexander Truskovsky References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> In-Reply-To: <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 19:05:26 -0000 IMO, Apple has a better solution to certificate enrollment than PKIX: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/Introduction/Introduction.html It works both for BYOD and consumers. Unlike traditional certificate enrollment schemes, the Apple profile bootstrap can also provide VPN settings in the the same step as certificates are enrolled! In my own adoption of Apple's system, a server-based enrollment object is created before the actual profile and SCEP-request kicks in. The SCEP DN and challenge are only used for binding the SCEP request to the enrollment object. Anders On 2012-04-27 15:46, Alexander Truskovsky wrote: > Max, > > You are correct, the same problem exists if CMS is used. I think an exception to the RFC 5280 key usage restrictions is reasonable in the case of certificate renewal only. When verifying certificates you have never seen before, I believe it is important to ensure the key usage is appropriate and EST should perform full certificate verification when authenticating the initial CSRs using certificates issued by another PKI. In the case of certificate renewal the EST server will be verifying certificates that it issued, and I think ignoring the key usage here does not really degrade security. > > We are interested in deploying a solution that will work for Client Authentication and Email Protection certificates (enrollment and renewal). I don't think that mobile devices have the need to support enrollment for certificates with any other extended key usage. > > I don't have any other suggestions right now. Perhaps the TLS client authentication can still be used if it is more convenient to some clients and CMS can be used as a secondary option. It is certainly easier to override the key usage warning in the EST server implementation when using CMS. > > Regards, > Alex > > > -----Original Message----- > From: Max Pritikin [mailto:pritikin@cisco.com] > Sent: Wednesday, April 25, 2012 7:20 PM > To: Alexander Truskovsky > Cc: pkix@ietf.org; Matthew Campagna; Chris Bender > Subject: Re: Some comments on draft-ietf-pkix-est-01 > > > Thank you for the feedback on EST (and SCEP). > > In regards for your request for EST functionality: > > I agree that dealing with clients that can't use their certificates for digitalSignature is a problem -- but doesn't the same problem exist if the client's key usage is such that they shouldn't be signing PKCS7/CMS either? > > "CMC provides a method to prove the client's identity based on a client/server shared-secret" [RFC5272] ... but I don't believe it provides an exception to the problem you're discussing. > > Is there general interest in finding another approach? I've hesitated to suggest an exception to the RFC5280 key usage restrictions but haven't been able to think of a different approach. > > Do you have any suggestions? It is very possible I'm missing something, > > - max > > On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: > >> Max, >> >> I have been implementing the current SCEP draft, and have come across several issues that we are glad to see addressed in EST, specifically: >> >> 1) The use of a certificate issued by another PKI to authenticate the initial request is optional in SCEP. This is now a MUST requirement in EST (A3). >> 2) The GetCACaps response is not signed in SCEP. This is not a problem in EST because of the TLS use. >> 3) The SCEP draft mentions that RSA is the only algorithm supported by the current implementations. Although there is no technical limitation that prevents the usage of ECC in SCEP and some implementations do support ECC, we are glad to see that algorithm agility is a MUST requirement in EST (K1). >> >> EST is a specification we would also consider deploying. There is an additional use case we would like to see supported by EST. When renewing an email protection certificate, it cannot be used to authenticate the request using the TLS client authentication. Although this can be achieved by using a full CMC operation, it would be better if it were handled by plain EST. Wrapping the PKCS10 in PKCS7 and signing it with the email protection key would work without having to use a full CMC operation. >> >> We think the use of TLS client authentication, although elegant, makes it inconvenient to use in some cases because a full CMC operation needs to be used. We propose to continue using PKCS7 to wrap the PKCS10 to support this and similar use cases. >> >> Thanks for your consideration, >> Alex >> >> >> Alexander Truskovsky >> BlackBerry OS Security | Research In Motion >> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From kent@bbn.com Tue May 22 07:40:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D6021F84E4 for ; Tue, 22 May 2012 07:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeC7ozdOtG+m for ; Tue, 22 May 2012 07:40:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 93E1821F84D6 for ; Tue, 22 May 2012 07:40:14 -0700 (PDT) Received: from dhcp89-089-239.bbn.com ([128.89.89.239]:49233) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWqFU-000KO7-0E for pkix@ietf.org; Tue, 22 May 2012 10:39:44 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 22 May 2012 10:40:08 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] I'm back, sorta ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:40:15 -0000 Folks, I have been on vacation for about a month, not reading any work e-mail. I have about 3K messages to process. I'll be getting up to speed on PKIX traffic over the next week or so. Steve From rob.stradling@comodo.com Fri May 25 02:05:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D43421F8623 for ; Fri, 25 May 2012 02:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9acY+vTO3hB for ; Fri, 25 May 2012 02:05:26 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 64C3121F8622 for ; Fri, 25 May 2012 02:05:25 -0700 (PDT) Received: (qmail 4879 invoked from network); 25 May 2012 09:05:23 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 25 May 2012 09:05:23 -0000 Received: (qmail 24683 invoked by uid 1000); 25 May 2012 09:05:23 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 25 May 2012 10:05:23 +0100 Message-ID: <4FBF4B37.1090208@comodo.com> Date: Fri, 25 May 2012 10:04:55 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 09:05:27 -0000 Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses? RFC2560 and the expired 2560bis-04 don't mention the Key Usage extension at all. RFC5280 says... " id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } -- Signing OCSP responses -- Key usage bits that may be consistent: digitalSignature -- and/or nonRepudiation" ...but id-kp-OCSPSigning is only applicable to Designated Responders. The (relatively recently published) CABForum Baseline Requirements document says: "Bit positions for keyCertSign and cRLSign MUST be set. If the Root/Subordinate CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set." Is this "digitalSignature bit MUST be set" requirement sensible? Or unnecessary? Or problematic? Does any other standard explicitly state the same requirement? IMHO, it'd kinda make sense for the cRLSign bit to govern whether or not the CA Certificate can directly sign OCSP Responses, but sadly I can find no text to support this idea. RFC5280 says... "The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), such as those used in an entity authentication service, a data origin authentication service, and/or an integrity service." Spot the "such as". X.509 (2008/05) says... "digitalSignature: for verifying digital signatures that are used with an entity authentication service, a data origin authentication service and/or an integrity service;" Spot the absence of "such as". Is OCSP an "entity authentication service, a data origin authentication service and/or an integrity service"? If not, then surely it'd be wrong (according to the X.509 text) for digitalSignature to govern whether or not the CA Certificate can directly sign OCSP Responses? We (Comodo) directly sign OCSP Responses using CA Certificates that do not have the digitalSignature bit set. We've not encountered any interop problems so far. My concern is that future relying party software might choose to enforce the "digitalSignature bit MUST be set" requirement from the Baseline Requirements and therefore reject our OCSP Responses. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From housley@vigilsec.com Fri May 25 08:50:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AF421F86C2 for ; Fri, 25 May 2012 08:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.672 X-Spam-Level: X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAwjweZkhGCm for ; Fri, 25 May 2012 08:50:43 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7821F86B7 for ; Fri, 25 May 2012 08:50:43 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1AC519A4725; Fri, 25 May 2012 11:50:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 5t2bXAH8osRJ; Fri, 25 May 2012 11:50:29 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7ABD59A471B; Fri, 25 May 2012 11:50:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <4FBF4B37.1090208@comodo.com> Date: Fri, 25 May 2012 11:50:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 15:50:43 -0000 Rob: > Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses? Do you mean that the same private key is used by the CA to sign = certificates, CRLs, and OCSP Responses? If so, I would expect the CA = certificate that contains the corresponding public key to include the = key usage and the extended key usage extensions. The key usage = extension should have at least the keyCertSign and the cRLSign bits set. = The extended key usage extension should include at least the = id-kp-OCSPSigning object identifier. Russ From david.cooper@nist.gov Fri May 25 09:08:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8599E21F874A for ; Fri, 25 May 2012 09:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKeTQL2amNJC for ; Fri, 25 May 2012 09:08:50 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id DC2F821F873E for ; Fri, 25 May 2012 09:08:49 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 May 2012 12:08:40 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Fri, 25 May 2012 12:07:33 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q4PG8ld3032510; Fri, 25 May 2012 12:08:48 -0400 Message-ID: <4FBFAE8F.4070303@nist.gov> Date: Fri, 25 May 2012 12:08:47 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120426 Thunderbird/12.0 MIME-Version: 1.0 To: Russ Housley References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> In-Reply-To: <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:08:50 -0000 Russ, RFC 2560 is clear that the id-kp-OCSPSigning OID is only required if the certificate issuer does not sign the OCSP responses itself. In addition, RFC 5280 says: If the [extended key usage] extension is present, then the certificate MUST only be used for one of the purposes indicated. If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose. So, including an extended key usage extension in a CA certificate would be problematic, since the IETF does not specify any key purpose OIDs that indicate a usage of certificate or CRL signing. One could get around this by including the anyExtendedKeyUsage OID, but it is better to simply not include an extended key usage extension in a CA certificate. Dave On 05/25/2012 11:50 AM, Russ Housley wrote: > Rob: >> Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses? > Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses? If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions. The key usage extension should have at least the keyCertSign and the cRLSign bits set. The extended key usage extension should include at least the id-kp-OCSPSigning object identifier. > > Russ From denis.pinkas@bull.net Fri May 25 09:31:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B495821F8748; Fri, 25 May 2012 09:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nwnsIAhtG6A; Fri, 25 May 2012 09:31:37 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 973C421F873A; Fri, 25 May 2012 09:31:36 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 72B9B1800F; Fri, 25 May 2012 18:31:35 +0200 (CEST) In-Reply-To: <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> To: Russ Housley MIME-Version: 1.0 X-KeepSent: 225B9899:F6519150-C1257A09:00571E94; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 25 May 2012 18:31:34 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 25/05/2012 18:31:35, Serialize complete at 25/05/2012 18:31:35 Content-Type: multipart/alternative; boundary="=_alternative 005AC5A0C1257A09_=" Cc: pkix@ietf.org, pkix-bounces@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:31:37 -0000 Message en plusieurs parties au format MIME --=_alternative 005AC5A0C1257A09_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Russ, I raised the question in my presentation on OCSP during the last PKIX=20 session in Paris,=20 since there is currently no answer in the PKIX documents. I don't believe that your response is correct. The id-kp-OCSPSigning object identifier is only for a designated OCSP=20 responder.=20 This is not the case we are considering in this discussion. RFC 2560 states: "OCSP signing delegation SHALL be designated by the=20 inclusion of id-kp-OCSPSigning=20 in an extendedKeyUsage certificate extension included in the OCSP response = signer's certificate". Ideally, we should have added an OCSP signing bit in the key usage bits,=20 but unfortunately=20 nobody raised the point when we built RFC 2560. Rob mentioned the (relatively recently published) CABForum Baseline=20 Requirements=20 document which says: "Bit positions for keyCertSign and cRLSign MUST be=20 set.=20 If the Root/Subordinate CA Private Key is used for signing OCSP responses, = then=20 the digitalSignature bit MUST be set." I don't believe that this response is correct either, since in the general = case an upper CA=20 does not sign OCSP responses for a lower CA.=20 Let me propose a strawman: The keyCertSign bit and the digitalSignature bit MUST be set. The cRLSign bit MAY be set. A few explanations are needed.=20 Since the CA issues certificates, the keyCertSign bit MUST be set. Since the CA signs OCSP responses, the digitalSignature bit MUST be set.=20 If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST=20 be set,=20 otherwise it MUST NOT be set. Let us now suppose that a CA starts to issue CRLs and that, later on, the=20 CA wants to issue OCSP responses.=20 With this strawman proposal, the CA must obtain a new certificate from its = upper CA. This makes sense since=20 the Certification Policy has changed and the upper CA has the right to=20 verify the practices of its child CA. Note: Any proposal will break some eggs and make an omelet, since, without = guidance, implementers did "something". What is strange is that OCSP currently works !=20 I would guess most implementations only test the keyCertSign bit.=20 Denis De : Russ Housley A : Rob Stradling Cc : pkix@ietf.org Date : 25/05/2012 17:50 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits Envoy=E9 par : pkix-bounces@ietf.org Rob: > Which Key Usage bits (if any) are required to be present in a CA=20 Certificate that directly signs OCSP Responses? Do you mean that the same private key is used by the CA to sign=20 certificates, CRLs, and OCSP Responses? If so, I would expect the CA=20 certificate that contains the corresponding public key to include the key=20 usage and the extended key usage extensions. The key usage extension=20 should have at least the keyCertSign and the cRLSign bits set. The=20 extended key usage extension should include at least the id-kp-OCSPSigning = object identifier. Russ =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 005AC5A0C1257A09_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Russ,

I raised the question in my presentation on OCSP during the last PKIX session in Paris,
since there is currently no answer in the PKIX documents.


I don't believe that your response is cor= rect.

The id-kp-OCSPSigning object identifier is only for a designated OCSP responder.
This is not the case we are considering in this discussion.


RFC 2560 states: "OCSP signing deleg= ation SHALL be designated by the inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate".


Ideally, we should have added an OCSP sig= ning bit in the key usage bits, but unfortunately
nobody raised the point when we built RFC 2560.


Rob mentioned the (relatively recently pu= blished) CABForum Baseline Requirements
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate CA Private Key is used for signing OCSP responses, then
the digitalSignature bit MUST be set."


I don't believe that this response is cor= rect either, since in the general case an upper CA
does not sign OCSP responses for a lower CA.


Let me propose a strawman:

The keyCertSign bit and the digitalSignat= ure bit MUST be set.
The cRLSign bit MAY be set.

A few explanations are needed.
Since the CA issues certificates, the key= CertSign bit MUST be set.
Since the CA signs OCSP responses, the di= gitalSignature bit MUST be set.
If the CA issues both CRLs and OCSP Respo= nses, then the cRLSign bit MUST be set,
otherwise it MUST NOT be set.


Let us now suppose that a CA starts to is= sue CRLs and that, later on, the CA wants to issue OCSP responses.
With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since
the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.


Note: Any proposal will break some eggs a= nd make an omelet, since, without guidance, implementers did "something&q= uot;.
        What is stran= ge is that OCSP currently works !
        I would guess most implementations only test the keyCertSign bit.

Denis



De :     &= nbsp;  Russ Housley <housley@vi= gilsec.com>
A :     &n= bsp;  Rob Stradling <rob.strad= ling@comodo.com>
Cc :   &nb= sp;    pkix@ietf.org
Date :    =    25/05/2012 17:50
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g




Rob:

> Which Key Usage bits (if any) are required to be present in a CA Certi= ficate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign certificate= s, CRLs, and OCSP Responses?  If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--=_alternative 005AC5A0C1257A09_=-- From ryan.hurst@globalsign.com Fri May 25 09:34:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD22721F874C for ; Fri, 25 May 2012 09:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEi7C+s27McX for ; Fri, 25 May 2012 09:34:14 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABAFA21F8742 for ; Fri, 25 May 2012 09:34:14 -0700 (PDT) Received: by dacx6 with SMTP id x6so1493130dac.31 for ; Fri, 25 May 2012 09:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id:x-mailer :thread-index:content-language:mime-version:content-type; bh=bDM7cFuFTpblH5GLtAe87YFkaAARVKgva/hsx2wUxWo=; b=HSA4Vly7Xu+KH1tYQJzuGgxpFEglOWaf5qdeGUaG+Pz9vnpsBFxjBQMZhqR2wjkmgk ti9AdHI/H/5/B/pi90D/vKY95E+V7l5/cwbiE2vydOC5gz/B7qau01dQdijrkLYYjOXo WdzKr1s4zJj90g3qmuXHajITSU+iUyk1y7mVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id:x-mailer :thread-index:content-language:mime-version:content-type :x-gm-message-state; bh=bDM7cFuFTpblH5GLtAe87YFkaAARVKgva/hsx2wUxWo=; b=gcTZcmsNxZmQpYXlE7DpzfRxllv0VLyYPRDHsvtirl47eRY+/cHJt42krjP+ZEgqi5 URW2O/XQRgCkVZcW3y9p1O7/J8WwcGN6t84W79SL0JPlX4n+vCc3XdJCkJBo4+DJzvks /95PjfYExL6x/+26aOzO/QXE5hl+ycl0VnXwFSupcQ7WDBEWgIANv18uiv8Dw5xNffVO kNx0CNlCPptv20olU5y1saHne9AoNpyHkO+ndY2NkvC1N3Lvr3KRRKk+GMvgedwBRtTS kcVJat7vV8XtueBrUJdrmYlMW95P1P3c1TIjyPcn116hgFp0J6Uoju+InlEdapmbYNQs fSCA== Received: by 10.68.228.170 with SMTP id sj10mr33565423pbc.106.1337963654394; Fri, 25 May 2012 09:34:14 -0700 (PDT) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id of1sm9543337pbb.15.2012.05.25.09.34.12 (version=SSLv3 cipher=OTHER); Fri, 25 May 2012 09:34:13 -0700 (PDT) From: "Ryan Hurst" To: , "'Russ Housley'" References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> In-Reply-To: Date: Fri, 25 May 2012 09:34:10 -0700 Message-ID: <10b901cd3a94$36a2eb70$a3e8c250$@globalsign.com> X-Mailer: Microsoft Outlook 14.0 thread-index: AQFUv5L8Hono6dQLELE4R9uV0I6ojwJeK/rFArM5DQeXox39AA== Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_10B2_01CD3A59.899A8D00" X-Gm-Message-State: ALoCoQmUs10tENn2vLXvK6h7lB3B9gp+e3Jed+DJE2qrs17h2/yOJIQ0Xks/KZLtu2HOXQtXW9Zg Cc: pkix@ietf.org, pkix-bounces@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:34:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_10B2_01CD3A59.899A8D00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_10B3_01CD3A59.899A8D00" ------=_NextPart_001_10B3_01CD3A59.899A8D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have always assumed the logic Denis mentions, I have no clue what = clients expect though :/ =20 Ryan =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net Sent: Friday, May 25, 2012 9:32 AM To: Russ Housley Cc: pkix@ietf.org; pkix-bounces@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits =20 Russ,=20 I raised the question in my presentation on OCSP during the last PKIX session in Paris,=20 since there is currently no answer in the PKIX documents.=20 I don't believe that your response is correct.=20 The id-kp-OCSPSigning object identifier is only for a designated OCSP responder.=20 This is not the case we are considering in this discussion.=20 RFC 2560 states: "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning=20 in an extendedKeyUsage certificate extension included in the OCSP = response signer's certificate".=20 Ideally, we should have added an OCSP signing bit in the key usage bits, = but unfortunately=20 nobody raised the point when we built RFC 2560.=20 Rob mentioned the (relatively recently published) CABForum Baseline Requirements=20 document which says: "Bit positions for keyCertSign and cRLSign MUST be = set. If the Root/Subordinate CA Private Key is used for signing OCSP = responses, then=20 the digitalSignature bit MUST be set." I don't believe that this response is correct either, since in the = general case an upper CA=20 does not sign OCSP responses for a lower CA.=20 Let me propose a strawman:=20 The keyCertSign bit and the digitalSignature bit MUST be set.=20 The cRLSign bit MAY be set.=20 A few explanations are needed.=20 Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA signs OCSP responses, the digitalSignature bit MUST be set. = If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST = be set,=20 otherwise it MUST NOT be set.=20 Let us now suppose that a CA starts to issue CRLs and that, later on, = the CA wants to issue OCSP responses.=20 With this strawman proposal, the CA must obtain a new certificate from = its upper CA. This makes sense since=20 the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.=20 Note: Any proposal will break some eggs and make an omelet, since, = without guidance, implementers did "something".=20 What is strange is that OCSP currently works !=20 I would guess most implementations only test the keyCertSign = bit.=20 Denis=20 De : Russ Housley =20 A : Rob Stradling =20 Cc : pkix@ietf.org=20 Date : 25/05/2012 17:50=20 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20 Envoy=E9 par : pkix-bounces@ietf.org=20 _____ =20 Rob: > Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses? Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses? If so, I would expect the CA certificate that contains the corresponding public key to include the = key usage and the extended key usage extensions. The key usage extension = should have at least the keyCertSign and the cRLSign bits set. The extended = key usage extension should include at least the id-kp-OCSPSigning object identifier. Russ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_001_10B3_01CD3A59.899A8D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have always assumed the logic Denis mentions, I have no clue what = clients expect though :/

 

Ryan

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = denis.pinkas@bull.net
Sent: Friday, May 25, 2012 9:32 = AM
To: Russ Housley
Cc: pkix@ietf.org; = pkix-bounces@ietf.org
Subject: Re: [pkix] Integrated OCSP = Responders / Key Usage bits

 

Russ, =

I raised the = question in my presentation on OCSP during the last PKIX session in = Paris,
since there is currently no answer in the PKIX = documents.


I don't = believe that your response is correct.

The = id-kp-OCSPSigning object identifier is only for a designated OCSP = responder.
This is not the case we are considering in this = discussion.


RFC 2560 = states: "OCSP signing delegation SHALL be designated by the = inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate = extension included in the OCSP response signer's = certificate".


Ideally, we = should have added an OCSP signing bit in the key usage bits, but = unfortunately
nobody raised the point when we built RFC 2560.
=

Rob = mentioned the (relatively recently published) CABForum Baseline = Requirements
document which says: "Bit positions for = keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate = CA Private Key is used for signing OCSP responses, then
the = digitalSignature bit MUST be set."


I don't = believe that this response is correct either, since in the general case = an upper CA
does not sign OCSP responses for a lower CA. =


Let me = propose a strawman:

The = keyCertSign bit and the digitalSignature bit MUST be set. =
The cRLSign = bit MAY be set.

A few = explanations are needed.
Since the CA = issues certificates, the keyCertSign bit MUST be set.
Since the CA = signs OCSP responses, the digitalSignature bit MUST be set. =
If the CA = issues both CRLs and OCSP Responses, then the cRLSign bit MUST be set, =
otherwise it MUST NOT be set.


Let us now = suppose that a CA starts to issue CRLs and that, later on, the CA wants = to issue OCSP responses.
With this strawman proposal, the CA must = obtain a new certificate from its upper CA. This makes sense since =
the Certification Policy has changed and the upper CA has the right = to verify the practices of its child CA.


Note: Any = proposal will break some eggs and make an omelet, since, without = guidance, implementers did "something".
  =       What is strange is that OCSP currently works ! =
  =       I would guess most implementations only test the = keyCertSign bit.

Denis =



= De :        Russ Housley = <housley@vigilsec.com> =
= A :        Rob Stradling = <rob.stradling@comodo.com>=
= Cc :        pkix@ietf.org
= Date :        25/05/2012 = 17:50
= Objet :        Re: [pkix] = Integrated OCSP Responders / Key Usage bits
= Envoy=E9 par :        pkix-bounces@ietf.org =





Rob:

> = Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses?

Do you = mean that the same private key is used by the CA to sign certificates, = CRLs, and OCSP Responses?  If so, I would expect the CA certificate = that contains the corresponding public key to include the key usage and = the extended key usage extensions.  The key usage extension should = have at least the keyCertSign and the cRLSign bits set.  The = extended key usage extension should include at least the = id-kp-OCSPSigning object = identifier.

Russ



________________= _______________________________
pkix mailing = list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

------=_NextPart_001_10B3_01CD3A59.899A8D00-- ------=_NextPart_000_10B2_01CD3A59.899A8D00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM3jCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggRXMIIDP6ADAgECAgsEAAAAAAEvTuExRjAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h 0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l 1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA AaOCASUwggEhMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQ/ FdJtfC/nMZ5DCgaolGwsO8XuZTBHBgNVHSAEQDA+MDwGBFUdIAAwNDAyBggrBgEFBQcCARYmaHR0 cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wMwYDVR0fBCwwKjAooCagJIYiaHR0 cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMTAfBgNVHSMEGDAWgBRge2YaRQ2X yolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAyFjhfKEB6SONcDttXFL4xPNfY7rhmtOR ecivxEqlvvbYfb34RvdnmgUi1YkyCVe4HwhW7ddVnsXyv+ODXoiTH4ucF+rCu157fECCuZR+2V9V oP8ytXF464EWmFDl/zAPj5rkZuIFldMxcGDitrr+DhYGjJla/vHp+ytWkGNnnCPWIRGg1jnEho+k jfA78z3ROBuLQZOP2iLFIHnfbBg6kWMHipWty0zY1z6bNWPs7FW4By7Y3TiAdGGdYa5QEHGNi/2/ lfmMqIuwjHTrZptUZuiYeSC28EE45VApILuclXX7PSwynDNEj3gpXZI32hlUnfp1ETDlMt4X8bDF bsffhTCCBQYwggPuoAMCAQICEhEhb640/F3CUxHuqwZT6bSC5TANBgkqhkiG9w0BAQUFADBUMQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2ln biBQZXJzb25hbFNpZ24gMiBDQSAtIEcyMB4XDTEyMDEyMzE2MzY1OVoXDTE1MDEyMzE2MzY1OVow gZQxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1OZXcgSGFtc3BoaXJlMRMwEQYDVQQHEwpQb3J0c21v dXRoMRkwFwYDVQQKExBHbG9iYWxTaWduLCBJbmMuMRMwEQYDVQQDEwpSeWFuIEh1cnN0MSgwJgYJ KoZIhvcNAQkBFhlyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAuAEkk72r5rBUAKG+tLpEksDgC/Z0/7PfZbTVAgH+Xzx+YzXHjCsWkLHtpojp kUSF2spHKtaf02yO9GbXHt/K9pmzsKgxxz1YtdxsSRMlF1oGkQbXgzLuThsljRtZHIVbBlqW7LU9 GeL9JneZtQWBZ8QdtHmycjkdpVw8bBStvJ5ylfuXjI++lPAaT0OEgh+8kzBustF17Ad3AqwSq9qN 0zmIBCr/qDZ22qDLd1MTLfZ0n/Y8iLIY6n50+QHsNwlDTGrTueYORV13SLpAMHoNWEm9ZbNOalt7 FtNE93e3ULPf+zbsQoPwNnpZlSUqMvPjC0fCUhRH/2jIIzv08i4P4wIDAQABo4IBjzCCAYswDgYD VR0PAQH/BAQDAgWgME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRw czovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAkBgNVHREEHTAbgRlyeWFuLmh1cnN0 QGdsb2JhbHNpZ24uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3NwZXJzb25h bHNpZ24yZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDovL3NlY3VyZS5n bG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0GA1UdDgQWBBRVohAn tPy+9nlWKnFmJy1ekko84TAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTANBgkqhkiG 9w0BAQUFAAOCAQEAIUIuoSz3rnZn9yAReCA8wr0SNBWmHQSn6a0pPx9Dw3muL6bC21qQNLdEmoo4 iWLcSo5TOGz3ftnIW+3o2rQ3cq2SM5g1cquHN9P8TJ4pxiqJKWANdf1Xvotnb47pbuuamrK7UERs mwLrmeu5a6fytzjBYI1eTQtwB2C87zVOA8HOEENQWjDoOis2EqymwAUWWo366Qvbonj7L+5gyFy8 f7aAT8VjZWubyZuQ62XZ+7h3bwQhOpDMpGzizeaZhCtFCJcCoekIuVw9Kc5VZBGZYhZATCYLm3f3 he8XoO0yj1guccjhafUnTKJSTOy0wt8J0jt36wQHr/qv5xrPV8cr7DGCA5gwggOUAgEBMGowVDEL MAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNp Z24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMAkGBSsOAwIaBQCg ggIDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyNTE2MzQw OVowIwYJKoZIhvcNAQkEMRYEFP9BMOWoZ/1BEmJk71YPhN9BkzI7MHkGCSsGAQQBgjcQBDFsMGow VDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2Jh bFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMHsGCyqGSIb3 DQEJEAILMWygajBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgG A1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIEcyAhIRIW+uNPxdwlMR7qsGU+m0 guUwgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3 DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgB ZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAkwNA0XJb1nZXT8Q7GJMFbF0jqdrM7VxsncCqwBEyaclT DqS01BWPlZlo8PE5beIf0hIVLW5FVDCx+oMT98GE2DP30D0L8tUY4s7UTLdnBNKeRKNPoL74k2n2 issZDmqU6CYmwYEDCCyhqWKi+4xvpGaixuYvEIJIwhW8u7I5riZ8jXp8P9tStCAzgLoQZ5FwqBCM Ow5J5WTDX5YR8Upx1mh68Yn+APDKFSPssVnyR0eROi5a8EqwZpm4Taj25AQbZ+rPgw8DSuJFEKfg dc7habIVZei4VFLTg181RT0JLV1bvSKnYoz8pf5qm0YUGS7a0DmKVVQ87h1T7kmdVUtGbQAAAAAA AA== ------=_NextPart_000_10B2_01CD3A59.899A8D00-- From housley@vigilsec.com Fri May 25 09:46:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A2F21F8723 for ; Fri, 25 May 2012 09:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foWe4fIv8obC for ; Fri, 25 May 2012 09:46:37 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 51F9421F873E for ; Fri, 25 May 2012 09:46:37 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 505E2F24035; Fri, 25 May 2012 12:46:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 0cRO4ncqwnWb; Fri, 25 May 2012 12:46:11 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 45324F24025; Fri, 25 May 2012 12:46:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <4FBFAE8F.4070303@nist.gov> Date: Fri, 25 May 2012 12:46:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <334096E8-11A0-4DCB-88ED-CD5144C786F2@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <4FBFAE8F.4070303@nist.gov> To: "David A. Cooper" X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:46:38 -0000 David: Thanks for pointing out my mistake. I agree that RFC 2560 does not require the id-kp-OCSPSigning OID if the = CA certificate will be used to validate the OCSP response; however, RFC = 2560 does not say that the CA certificate cannot also make use of the = id-kp-OCSPSigning OID. For the same private key is used by the CA to sign certificates, CRLs, = and OCSP Responses, the digitalSignature bit would also need to be set = to ensure consistence between the extend key usage and the extended key = usage extensions. I do not think that the use of the anyExtendedKeyUsage OID in a CA = certificate is desirable. Russ On May 25, 2012, at 12:08 PM, David A. Cooper wrote: > Russ, >=20 > RFC 2560 is clear that the id-kp-OCSPSigning OID is only required if = the certificate issuer does not sign the OCSP responses itself. >=20 > In addition, RFC 5280 says: >=20 > If the [extended key usage] extension is present, then the = certificate MUST > only be used for one of the purposes indicated. >=20 > If a certificate contains both a key usage extension and an extended > key usage extension, then both extensions MUST be processed > independently and the certificate MUST only be used for a purpose > consistent with both extensions. If there is no purpose consistent > with both extensions, then the certificate MUST NOT be used for any > purpose. >=20 > So, including an extended key usage extension in a CA certificate = would be problematic, since the IETF does not specify any key purpose = OIDs that indicate a usage of certificate or CRL signing. One could get = around this by including the anyExtendedKeyUsage OID, but it is better = to simply not include an extended key usage extension in a CA = certificate. >=20 > Dave >=20 > On 05/25/2012 11:50 AM, Russ Housley wrote: >> Rob: >>> Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses? >> Do you mean that the same private key is used by the CA to sign = certificates, CRLs, and OCSP Responses? If so, I would expect the CA = certificate that contains the corresponding public key to include the = key usage and the extended key usage extensions. The key usage = extension should have at least the keyCertSign and the cRLSign bits set. = The extended key usage extension should include at least the = id-kp-OCSPSigning object identifier. >>=20 >> Russ From hallam@gmail.com Fri May 25 09:47:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8076921F8768 for ; Fri, 25 May 2012 09:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3hemZ9bEll5 for ; Fri, 25 May 2012 09:47:50 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8072721F873E for ; Fri, 25 May 2012 09:47:50 -0700 (PDT) Received: by yhq56 with SMTP id 56so870034yhq.31 for ; Fri, 25 May 2012 09:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yl2fKAGEYWDU0yLDQWblAh/2b/5S2ck1Y3YjTnY9dvM=; b=X2PSN0mpaJPYczar6QToEZW9IhTpWR1ebMlTSHEBxzzJ8/tE8hOz104DiWZHKJJPBA Cbf+0ED90QpEFKwgh2ZX6OUa+/2LhXUQTEcthrfD+t+8LgimcYInSCLlH01kP3ARmKr0 0TgDetiRj8+NfTs0p0T28yP/zmA1XYerVOOnNnIt84omTnrJOwArO/ctZP7t1bIRy/CF JZmLYMw1B4doO0dTm9HEPI04i/LWrfun8C1eSFIXcx71crogaCPrhe92uWVEzbceeQRM erH8mFk4Qkbd4o1t3faJzBgaBjw1oCBntU+PSWdqpW4+Ir4sXe3MM5VCXxNKeeSWXPOe SH1A== MIME-Version: 1.0 Received: by 10.60.2.35 with SMTP id 3mr3705049oer.63.1337964469945; Fri, 25 May 2012 09:47:49 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Fri, 25 May 2012 09:47:49 -0700 (PDT) Date: Fri, 25 May 2012 12:47:49 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: multipart/alternative; boundary=e89a8f234829f405ed04c0df20ff Subject: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:47:51 -0000 --e89a8f234829f405ed04c0df20ff Content-Type: text/plain; charset=ISO-8859-1 The issue was discussed here earlier without a conclusion. I just wanted to point out that the issue is currently the subject of a ballot in CABForum: http://cabforum.org/pipermail/public/2012-May/000027.html Delete the following text from the "Subordinate CA Certificate" section of both the Baseline Requirements Appendix B and EV Guidelines Appendix B: "All other fields and extensions MUST be set in accordance to RFC 5280." AND replace it with the following: "F. nameConstraints (optional) . If present, this extension SHOULD be marked critical*. All other fields and extensions MUST be set in accordance to RFC 5280. * Non-critical Name Constraints are an exception to RFC 5280 that MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide." Anyone who wants to follow the ballot discussion can do so at: http://cabforum.org/mailman/listinfo/public The reason this change is being considered is as follows: 1) Deployment of name constraints without a criticality flag provides an immediate an advantageous reduction in risk without impact on any deployed systems. 2) Deployment of name constraints with a criticality flag would entail an unacceptable incompatibility with widely deployed systems. 3) None of the following reasons advanced for requiring name constraints to be marked critical has been found to be persuasive: 3a) 'Critical means important' - no it does not, clients are required to process extensions that they understand regardless of whether they are marked critical or not. 3b) 'This is not a requirement for the DoD' - this is not about the DoD PKI. 3c) 'People should deploy RFC 5280 compliant systems rather than change the spec' - This is not a normative argument. People should live in brotherly peace and harmony too but the fact that they don't is the reason we need PKI in the first place. This change has been considered by a group of experts whose credentials and experience in the PKI space is at least equal to that of this WG. So please, no appeals to authority. Should this ballot pass, I will submit an ID to propose making the same change to RFC5280 as an erratum. In my personal view, it is clearly desirable for the IETF specifications to track the deployed specification. -- Website: http://hallambaker.com/ --e89a8f234829f405ed04c0df20ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The issue was discussed here earlier without a conclusion. I just want= ed to point out that the issue is currently the subject of a ballot in CABF= orum:

http://cabforum.org/pipermail/public/2012-May/000027.h= tml=A0

Delete the following text from the "Subordinate CA= Certificate" section of=20 both the Baseline Requirements Appendix B and EV Guidelines Appendix B:
"All other fields and extensions MUST be set in accordance to RFC= =20 5280."
AND replace it with the following:
"F. nameConstraints (optional)
. If present, this extension SHOULD be marked critical*.
All other fields and extensions MUST be set in accordance to RFC=20 5280.
* Non-critical Name Constraints are an exception to RFC 5280 that MAY = be=20 used until the Name Constraints extension is supported by Application Softw= are=20 Suppliers whose software is used by a substantial portion of Relying Partie= s=20 worldwide."


Anyone who wants t= o follow the ballot discussion can do so at:

The reason this change is being considered is as = follows:

1) Deployment of name constraints without= a criticality flag provides an immediate an advantageous reduction in risk= without impact on any deployed systems.

2) Deployment of=A0name constraints with a criticality = flag would entail an unacceptable incompatibility with widely deployed syst= ems.

3) None of the following reasons advanced for= requiring name constraints to be marked critical has been found to be pers= uasive:=A0

3a) 'Critical means important' - no it does not= , clients are required to process extensions that they understand regardles= s of whether they are marked critical or not.

3b) 'This is not a requirement for the DoD' - this is not about the= DoD PKI.

3c) 'People should deploy RFC 5280 c= ompliant systems rather than change the spec' - This is not a normative= argument. People should live in brotherly peace and harmony too but the fa= ct that they don't is the reason we need PKI in the first place.

This change has been considered by a group of experts w= hose credentials and experience in the PKI space is at least equal to that = of this WG. So please, no appeals to authority.


Should this ballot pass, I will submit an ID to propose maki= ng the same change to RFC5280 as an erratum. In my personal view, it is cle= arly desirable for the IETF specifications to track the deployed specificat= ion.

--
Website: http://h= allambaker.com/

--e89a8f234829f405ed04c0df20ff-- From housley@vigilsec.com Fri May 25 09:54:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C071521F8770 for ; Fri, 25 May 2012 09:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.668 X-Spam-Level: X-Spam-Status: No, score=-102.668 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na9BrzDTzq5P for ; Fri, 25 May 2012 09:54:26 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7972C21F8750 for ; Fri, 25 May 2012 09:54:26 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 2E4609A4725; Fri, 25 May 2012 12:54:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id k0xjKGRtai86; Fri, 25 May 2012 12:53:58 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D60BF9A471B; Fri, 25 May 2012 12:54:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-63-1027895123 From: Russ Housley In-Reply-To: Date: Fri, 25 May 2012 12:54:24 -0400 Message-Id: <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> To: denis.pinkas@bull.net X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:54:27 -0000 --Apple-Mail-63-1027895123 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Denis: I think my reply to David is consistent with your analysis. My first = reply was incorrect; the digitalSignature key usage bit needs to be set. My summary: Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA issues CRLs, the cRLSign bit MUST be set. Since the CA signs OCSP responses, the digitalSignature bit MUST be set, = and the id-kp-OCSOSigning OID MAY be present.=20 I think including the id-kp-OCSOSigning OID is desirable. It indicates = the intention to sign OCSP responses even though it is not require by = RFC 2560. Russ On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote: > Russ,=20 >=20 > I raised the question in my presentation on OCSP during the last PKIX = session in Paris,=20 > since there is currently no answer in the PKIX documents.=20 >=20 > I don't believe that your response is correct.=20 >=20 > The id-kp-OCSPSigning object identifier is only for a designated OCSP = responder.=20 > This is not the case we are considering in this discussion.=20 >=20 > RFC 2560 states: "OCSP signing delegation SHALL be designated by the = inclusion of id-kp-OCSPSigning=20 > in an extendedKeyUsage certificate extension included in the OCSP = response signer's certificate".=20 >=20 > Ideally, we should have added an OCSP signing bit in the key usage = bits, but unfortunately=20 > nobody raised the point when we built RFC 2560.=20 >=20 > Rob mentioned the (relatively recently published) CABForum Baseline = Requirements=20 > document which says: "Bit positions for keyCertSign and cRLSign MUST = be set. =20 > If the Root/Subordinate CA Private Key is used for signing OCSP = responses, then=20 > the digitalSignature bit MUST be set." >=20 > I don't believe that this response is correct either, since in the = general case an upper CA=20 > does not sign OCSP responses for a lower CA.=20 >=20 > Let me propose a strawman:=20 >=20 > The keyCertSign bit and the digitalSignature bit MUST be set.=20 > The cRLSign bit MAY be set.=20 >=20 > A few explanations are needed.=20 > Since the CA issues certificates, the keyCertSign bit MUST be set.=20 > Since the CA signs OCSP responses, the digitalSignature bit MUST be = set.=20 > If the CA issues both CRLs and OCSP Responses, then the cRLSign bit = MUST be set,=20 > otherwise it MUST NOT be set.=20 >=20 > Let us now suppose that a CA starts to issue CRLs and that, later on, = the CA wants to issue OCSP responses.=20 > With this strawman proposal, the CA must obtain a new certificate from = its upper CA. This makes sense since=20 > the Certification Policy has changed and the upper CA has the right to = verify the practices of its child CA.=20 >=20 > Note: Any proposal will break some eggs and make an omelet, since, = without guidance, implementers did "something".=20 > What is strange is that OCSP currently works !=20 > I would guess most implementations only test the keyCertSign = bit.=20 >=20 > Denis=20 >=20 >=20 >=20 > De : Russ Housley =20 > A : Rob Stradling =20 > Cc : pkix@ietf.org=20 > Date : 25/05/2012 17:50=20 > Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20= > Envoy=E9 par : pkix-bounces@ietf.org=20 >=20 >=20 >=20 > Rob: >=20 > > Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses? >=20 > Do you mean that the same private key is used by the CA to sign = certificates, CRLs, and OCSP Responses? If so, I would expect the CA = certificate that contains the corresponding public key to include the = key usage and the extended key usage extensions. The key usage = extension should have at least the keyCertSign and the cRLSign bits set. = The extended key usage extension should include at least the = id-kp-OCSPSigning object identifier. >=20 > Russ >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 --Apple-Mail-63-1027895123 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 denis.pinkas@bull.net = wrote:

Russ,

I raised the question in my = presentation on OCSP during the last PKIX session in Paris,
since there is currently no answer in the PKIX documents.


I don't believe that your response = is correct.

The id-kp-OCSPSigning object = identifier is only for a designated OCSP responder.
This is not the case we are considering in this discussion.


RFC 2560 states: "OCSP signing = delegation SHALL be designated by the inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate extension included in the OCSP = response signer's certificate".


Ideally, we should have added an = OCSP signing bit in the key usage bits, but unfortunately
nobody raised the point when we built RFC 2560.


Rob mentioned the (relatively = recently published) CABForum Baseline Requirements
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate CA Private Key is used for signing OCSP = responses, then
the digitalSignature bit MUST be set."


I don't believe that this response = is correct either, since in the general case an upper CA
does not sign OCSP responses for a lower CA.


Let me propose a strawman:

The keyCertSign bit and the = digitalSignature bit MUST be set.
The cRLSign bit MAY be set.

A few explanations are needed. =
Since the CA issues certificates, = the keyCertSign bit MUST be set.
Since the CA signs OCSP responses, = the digitalSignature bit MUST be set.
If the CA issues both CRLs and OCSP = Responses, then the cRLSign bit MUST be set,
otherwise it MUST NOT be set.


Let us now suppose that a CA starts = to issue CRLs and that, later on, the CA wants to issue OCSP responses.
With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since
the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.


Note: Any proposal will break some = eggs and make an omelet, since, without guidance, implementers did = "something".
        What is = strange is that OCSP currently works !
        I would = guess most implementations only test the keyCertSign bit.

Denis



De :   =      Russ Housley <housley@vigilsec.com>
A :   =      Rob Stradling <rob.stradling@comodo.com><= /font>
Cc : =        pkix@ietf.org
Date :   =      25/05/2012 = 17:50
Objet : =        Re: [pkix] = Integrated OCSP Responders / Key Usage bits
Envoy=E9 par = :        pkix-bounces@ietf.org




Rob:

> Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign = certificates, CRLs, and OCSP Responses?  If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The = extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix<= font size=3D"2">


= --Apple-Mail-63-1027895123-- From david.cooper@nist.gov Fri May 25 10:11:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A73121F8764 for ; Fri, 25 May 2012 10:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZXXyU6pYkYv for ; Fri, 25 May 2012 10:11:19 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEFD21F876C for ; Fri, 25 May 2012 10:11:07 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 May 2012 13:10:58 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Fri, 25 May 2012 13:09:51 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q4PHB3El005573; Fri, 25 May 2012 13:11:04 -0400 Message-ID: <4FBFBD26.3080005@nist.gov> Date: Fri, 25 May 2012 13:11:02 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120426 Thunderbird/12.0 MIME-Version: 1.0 To: Russ Housley References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> In-Reply-To: <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:11:26 -0000 Russ, You seem to providing contradictory suggestions. If you include an extended key usage extension in a CA certificate that asserts id-kp-OCSPSigning, but not anyExtendedKeyUsage, then the subject public key cannot be used to verify signatures on certificates or CRLs, even if the keyCertSign and cRLSign bits are set in key usage. In theory, you could get around this by defining a key purpose OID (or OIDs) consistent with certificate and CRL signing, but why bother. Dave On 05/25/2012 12:54 PM, Russ Housley wrote: > Denis: > > I think my reply to David is consistent with your analysis. My first > reply was incorrect; the digitalSignature key usage bit needs to be set. > > My summary: > Since the CA issues certificates, the keyCertSign bit MUST be set. > Since the CA issues CRLs, the cRLSign bit MUST be set. > Since the CA signs OCSP responses, the digitalSignature bit MUST be > set, and > the id-kp-OCSOSigning OID MAY be present. > > I think including the id-kp-OCSOSigning OID is desirable. It > indicates the intention to sign OCSP responses even though it is not > require by RFC 2560. > > Russ > On 05/25/2012 12:46 PM, Russ Housley wrote: > I do not think that the use of the anyExtendedKeyUsage OID in a CA certificate is desirable. > > Russ > > On May 25, 2012, at 12:08 PM, David A. Cooper wrote: >> In addition, RFC 5280 says: >> >> If the [extended key usage] extension is present, then the certificate MUST >> only be used for one of the purposes indicated. >> >> If a certificate contains both a key usage extension and an extended >> key usage extension, then both extensions MUST be processed >> independently and the certificate MUST only be used for a purpose >> consistent with both extensions. If there is no purpose consistent >> with both extensions, then the certificate MUST NOT be used for any >> purpose. From mrex@sap.com Fri May 25 10:50:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFA021F8712; Fri, 25 May 2012 10:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipm9lv+vzDLB; Fri, 25 May 2012 10:50:12 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 78F6D21F86EA; Fri, 25 May 2012 10:50:11 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4PHo80B004947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 May 2012 19:50:08 +0200 (MEST) From: Martin Rex Message-Id: <201205251750.q4PHo7ga008485@fs4113.wdf.sap.corp> To: ryan.hurst@globalsign.com (Ryan Hurst) Date: Fri, 25 May 2012 19:50:07 +0200 (MEST) In-Reply-To: <10b901cd3a94$36a2eb70$a3e8c250$@globalsign.com> from "Ryan Hurst" at May 25, 12 09:34:10 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, pkix-bounces@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 17:50:12 -0000 Ryan Hurst wrote: > > I have always assumed the logic Denis mentions, > I have no clue what clients expect though :/ +1 Denis Pinkas wrote: > > A few explanations are needed. > Since the CA issues certificates, the keyCertSign bit MUST be set. > Since the CA signs OCSP responses, the digitalSignature bit MUST be set. > If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST be > set, otherwise it MUST NOT be set. This sounds right to me (about KeyUsage). > > What is strange is that OCSP currently works ! > I would guess most implementations only test the keyCertSign bit. I believe that implementation MUST check for digitalSignature when verifying the signature on the OCSP response with a cert that contains a KeyUsage extension. The situation with the presence of an ExtendedKeyUsage in a CA cert is less clear than desirable. http://tools.ietf.org/html/rfc5280#section-4.2.1.12 This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates. This extension is defined as follows: [...] If the extension is present, then the certificate MUST only be used for one of the purposes indicated. The unclear "in addition to or in place of" could result in RPs rejecting CA certs with ExtendedKeyUsage in them, by being _very_ strict about the MUST above. The spec should have clarified, to which KeyUsage types the "in addition to" applies, and to which "in place of" applies. Currently, much of the installed base might be entirely ignoring ExtendedKeyUsage except for very specific usage scenarios that explicitly call for it (so that the check is implemented entirely at the "application caller" level, and that ExtendedKeyUsage is entirely ignored during certificate path validation. -Martin From denis.pinkas@bull.net Fri May 25 11:41:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F73821F8773 for ; Fri, 25 May 2012 11:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmor0ZvTvoCP for ; Fri, 25 May 2012 11:41:02 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3867321F8770 for ; Fri, 25 May 2012 11:41:02 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 5138C18032; Fri, 25 May 2012 20:41:01 +0200 (CEST) In-Reply-To: <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> To: Russ Housley MIME-Version: 1.0 X-KeepSent: 62E99FCF:107092C9-C1257A09:00653C0C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 25 May 2012 20:41:00 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 25/05/2012 20:41:01, Serialize complete at 25/05/2012 20:41:01 Content-Type: multipart/alternative; boundary="=_alternative 00668B76C1257A09_=" Cc: IETF PKIX Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 18:41:03 -0000 Message en plusieurs parties au format MIME --=_alternative 00668B76C1257A09_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Russ, We only agree on two points: - Since the CA issues certificates, the keyCertSign bit MUST be set.=20 - Since the CA signs OCSP responses, the digitalSignature bit MUST be set However, when the CA does not issue CRLs, the cRLSign bit MUST NOT be set. Changing the content of RFC 2560 about the meaning of id-kp-OCSPSigning=20 OID is impossible.=20 As you know, id-kp-OCSPSigning is defined through an OID which has a=20 precise meaning.=20 If you change the meaning, then you need to define a new OID. So your proposal to include the id-kp-OCSPSigning OID in the extended key=20 usage extension=20 cannot be accepted. It is also unnecessary, even with a new OID. Denis De : Russ Housley A : denis.pinkas@bull.net Cc : IETF PKIX , Rob Stradling=20 Date : 25/05/2012 19:18 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits Denis: I think my reply to David is consistent with your analysis. My first=20 reply was incorrect; the digitalSignature key usage bit needs to be set. My summary: Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA issues CRLs, the cRLSign bit MUST be set. Since the CA signs OCSP responses, the digitalSignature bit MUST be set,=20 and the id-kp-OCSOSigning OID MAY be present.=20 I think including the id-kp-OCSOSigning OID is desirable. It indicates=20 the intention to sign OCSP responses even though it is not require by RFC=20 2560. Russ On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote: Russ,=20 I raised the question in my presentation on OCSP during the last PKIX=20 session in Paris,=20 since there is currently no answer in the PKIX documents.=20 I don't believe that your response is correct.=20 The id-kp-OCSPSigning object identifier is only for a designated OCSP=20 responder.=20 This is not the case we are considering in this discussion.=20 RFC 2560 states: "OCSP signing delegation SHALL be designated by the=20 inclusion of id-kp-OCSPSigning=20 in an extendedKeyUsage certificate extension included in the OCSP response = signer's certificate".=20 Ideally, we should have added an OCSP signing bit in the key usage bits,=20 but unfortunately=20 nobody raised the point when we built RFC 2560.=20 Rob mentioned the (relatively recently published) CABForum Baseline=20 Requirements=20 document which says: "Bit positions for keyCertSign and cRLSign MUST be=20 set.=20 If the Root/Subordinate CA Private Key is used for signing OCSP responses, = then=20 the digitalSignature bit MUST be set." I don't believe that this response is correct either, since in the general = case an upper CA=20 does not sign OCSP responses for a lower CA.=20 Let me propose a strawman:=20 The keyCertSign bit and the digitalSignature bit MUST be set.=20 The cRLSign bit MAY be set.=20 A few explanations are needed.=20 Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA signs OCSP responses, the digitalSignature bit MUST be set.=20 If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST=20 be set,=20 otherwise it MUST NOT be set.=20 Let us now suppose that a CA starts to issue CRLs and that, later on, the=20 CA wants to issue OCSP responses.=20 With this strawman proposal, the CA must obtain a new certificate from its = upper CA. This makes sense since=20 the Certification Policy has changed and the upper CA has the right to=20 verify the practices of its child CA.=20 Note: Any proposal will break some eggs and make an omelet, since, without = guidance, implementers did "something".=20 What is strange is that OCSP currently works !=20 I would guess most implementations only test the keyCertSign bit.=20 Denis=20 De : Russ Housley =20 A : Rob Stradling =20 Cc : pkix@ietf.org=20 Date : 25/05/2012 17:50=20 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20 Envoy=E9 par : pkix-bounces@ietf.org=20 Rob: > Which Key Usage bits (if any) are required to be present in a CA=20 Certificate that directly signs OCSP Responses? Do you mean that the same private key is used by the CA to sign=20 certificates, CRLs, and OCSP Responses? If so, I would expect the CA=20 certificate that contains the corresponding public key to include the key=20 usage and the extended key usage extensions. The key usage extension=20 should have at least the keyCertSign and the cRLSign bits set. The=20 extended key usage extension should include at least the id-kp-OCSPSigning = object identifier. Russ =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00668B76C1257A09_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Russ,

We only agree on two points:

 - Since the CA issues certificates, the keyCertSign bit MUST be set.
 - Since the CA signs OCSP responses, the digitalSignature bit MUST be set

However, when the CA does not issue CRLs, the cRLSign bit MUST NOT be set.

Changing the content of RFC 2560 about the meaning of id-kp-OCSPSigning OID is impossible.
As you know, id-kp-OCSPSigning is defined through an OID which has a precise meaning.
If you change the meaning, then you need to define a new OID.


So your proposal to include the id-kp-OCS= PSigning OID in the extended key usage extension
cannot be accepted.


It is also unnecessary, even with a new O= ID.

Denis



De :     &= nbsp;  Russ Housley <housley@vi= gilsec.com>
A :     &n= bsp;  denis.pinkas@bull.net
Cc :   &nb= sp;    IETF PKIX <pkix@i= etf.org>, Rob Stradling <rob.stradling@comodo.com>
Date :    =    25/05/2012 19:18
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits




Denis:

I think my reply to David is consistent with your analys= is.  My first reply was incorrect; the digitalSignature key usage bit needs to be set.

My summary:
Since the CA issues certificates, the keyCertSign bit MUST be set.
Since the CA issues CRLs, the cRLSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set, and
    the id-kp-OCSOSigning OID MAY be present.

I think including the id-kp-OCSOSigning OID is desirable.  It indicates the intention to sign OCSP responses even though it is not require by RFC 2560.

Russ


On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote:

Russ,

I raised the question in my presentation on OCSP during the last PKIX sessi= on in Paris,
since there is currently no answer in the PKIX documents.


I don't believe that your response is correct.


The id-kp-OCSPSigning object identifier is only for a designated OCSP respo= nder.
This is not the case we are considering in this discussion.


RFC 2560 states: "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate".


Ideally, we should have added an OCSP signing bit in the key usage bits, but unfortunately
nobody raised the point when we built RFC 2560.


Rob mentioned the (relatively recently published) CABForum Baseline Require= ments
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate CA Private Key is used for signing OCSP responses, then
the digitalSignature bit MUST be set."


I don't believe that this response is correct either, since in the general case an upper CA
does not sign OCSP responses for a lower CA.


Let me propose a strawman:


The keyCertSign bit and the digitalSignature bit MUST be set.

The cRLSign bit MAY be set.


A few explanations are needed.
Since the CA issues certificates, the keyCertSign bit MUST be set.

Since the CA signs OCSP responses, the digitalSignature bit MUST be set.
If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST be set,
otherwise it MUST NOT be set.


Let us now suppose that a CA starts to issue CRLs and that, later on, the CA wants to issue OCSP responses.
With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since
the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.


Note: Any proposal will break some eggs and make an omelet, since, without guidance, implementers did "something".

       What is strange is that OCSP currently works !
       I would guess most implementations only test the keyCertSign bit.


Denis




De :        
R= uss Housley <housley@vigilsec.com>
A :        
Rob Stradling <rob.stradling@comodo.com>
Cc :        
pkix@ietf.org
<= font size=3D3>

Date :        
25/05/2012 17:50
Objet :        
Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoy=E9 par :        
pkix-boun= ces@ietf.org




Rob:

> Which Key Usage bits (if any) are required to be present in a CA Certi= ficate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign certificate= s, CRLs, and OCSP Responses?  If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list

pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix


--=_alternative 00668B76C1257A09_=-- From housley@vigilsec.com Fri May 25 12:29:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E7C21F87A3 for ; Fri, 25 May 2012 12:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf2D+XWz4IK9 for ; Fri, 25 May 2012 12:29:10 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id BE9E421F87A2 for ; Fri, 25 May 2012 12:29:09 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 11D9BF24037; Fri, 25 May 2012 15:29:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 3RlKYcd9bG5G; Fri, 25 May 2012 15:29:01 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D3282F24025; Fri, 25 May 2012 15:29:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-69-1037177393 From: Russ Housley In-Reply-To: Date: Fri, 25 May 2012 15:29:06 -0400 Message-Id: <20F003EC-0620-45B5-BA3E-7984CCC6C671@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> To: Denis Pinkas , David Cooper X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:29:11 -0000 --Apple-Mail-69-1037177393 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Denis and David: In my original message, I said: "Do you mean that the same private key = is used by the CA to sign certificates, CRLs, and OCSP Responses?" My = response was in that context. RFC 2560 certainly requires the id-kp-Sigining OID in certificates that = are directly subordinate to the CA certificate that will be used to = validate OCSP responses. Re-reading it just now, I still do not see = anything that says the id-kp-Sigining OID cannot be in the CA = certificate.=20 The point that David Cooper raises needs further discussion. I'm = uncomfortable with his conclusion, but there is nothing in RFC 5280 that = I can point to as justification. However, the most recent version of = X.509 does offer some support. It says: "This field indicates one or = more purposes for which the certified public key may be used, in = addition to or in place of the basic purposes indicated in the key usage = extension field." Russ On May 25, 2012, at 2:41 PM, denis.pinkas@bull.net wrote: > Russ,=20 >=20 > We only agree on two points:=20 >=20 > - Since the CA issues certificates, the keyCertSign bit MUST be set.=20= > - Since the CA signs OCSP responses, the digitalSignature bit MUST be = set=20 >=20 > However, when the CA does not issue CRLs, the cRLSign bit MUST NOT be = set.=20 >=20 > Changing the content of RFC 2560 about the meaning of = id-kp-OCSPSigning OID is impossible.=20 > As you know, id-kp-OCSPSigning is defined through an OID which has a = precise meaning.=20 > If you change the meaning, then you need to define a new OID.=20 >=20 > So your proposal to include the id-kp-OCSPSigning OID in the extended = key usage extension=20 > cannot be accepted.=20 >=20 > It is also unnecessary, even with a new OID.=20 >=20 > Denis=20 >=20 >=20 >=20 > De : Russ Housley =20 > A : denis.pinkas@bull.net=20 > Cc : IETF PKIX , Rob Stradling = =20 > Date : 25/05/2012 19:18=20 > Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20= >=20 >=20 >=20 > Denis:=20 >=20 > I think my reply to David is consistent with your analysis. My first = reply was incorrect; the digitalSignature key usage bit needs to be set.=20= >=20 > My summary:=20 > Since the CA issues certificates, the keyCertSign bit MUST be set.=20 > Since the CA issues CRLs, the cRLSign bit MUST be set.=20 > Since the CA signs OCSP responses, the digitalSignature bit MUST be = set, and=20 > the id-kp-OCSOSigning OID MAY be present.=20 >=20 > I think including the id-kp-OCSOSigning OID is desirable. It = indicates the intention to sign OCSP responses even though it is not = require by RFC 2560.=20 >=20 > Russ=20 >=20 >=20 > On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote:=20 >=20 > Russ,=20 >=20 > I raised the question in my presentation on OCSP during the last PKIX = session in Paris,=20 > since there is currently no answer in the PKIX documents.=20 >=20 > I don't believe that your response is correct.=20 >=20 > The id-kp-OCSPSigning object identifier is only for a designated OCSP = responder.=20 > This is not the case we are considering in this discussion.=20 >=20 > RFC 2560 states: "OCSP signing delegation SHALL be designated by the = inclusion of id-kp-OCSPSigning=20 > in an extendedKeyUsage certificate extension included in the OCSP = response signer's certificate".=20 >=20 > Ideally, we should have added an OCSP signing bit in the key usage = bits, but unfortunately=20 > nobody raised the point when we built RFC 2560.=20 >=20 > Rob mentioned the (relatively recently published) CABForum Baseline = Requirements=20 > document which says: "Bit positions for keyCertSign and cRLSign MUST = be set. =20 > If the Root/Subordinate CA Private Key is used for signing OCSP = responses, then=20 > the digitalSignature bit MUST be set." >=20 > I don't believe that this response is correct either, since in the = general case an upper CA=20 > does not sign OCSP responses for a lower CA.=20 >=20 > Let me propose a strawman:=20 >=20 > The keyCertSign bit and the digitalSignature bit MUST be set.=20 > The cRLSign bit MAY be set.=20 >=20 > A few explanations are needed.=20 > Since the CA issues certificates, the keyCertSign bit MUST be set.=20 > Since the CA signs OCSP responses, the digitalSignature bit MUST be = set.=20 > If the CA issues both CRLs and OCSP Responses, then the cRLSign bit = MUST be set,=20 > otherwise it MUST NOT be set.=20 >=20 > Let us now suppose that a CA starts to issue CRLs and that, later on, = the CA wants to issue OCSP responses.=20 > With this strawman proposal, the CA must obtain a new certificate from = its upper CA. This makes sense since=20 > the Certification Policy has changed and the upper CA has the right to = verify the practices of its child CA.=20 >=20 > Note: Any proposal will break some eggs and make an omelet, since, = without guidance, implementers did "something".=20 > What is strange is that OCSP currently works !=20 > I would guess most implementations only test the keyCertSign = bit.=20 >=20 > Denis=20 >=20 >=20 >=20 > De : Russ Housley =20 > A : Rob Stradling =20 > Cc : pkix@ietf.org=20 > Date : 25/05/2012 17:50=20 > Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20= > Envoy=E9 par : pkix-bounces@ietf.org=20 >=20 >=20 >=20 > Rob: >=20 > > Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses? >=20 > Do you mean that the same private key is used by the CA to sign = certificates, CRLs, and OCSP Responses? If so, I would expect the CA = certificate that contains the corresponding public key to include the = key usage and the extended key usage extensions. The key usage = extension should have at least the keyCertSign and the cRLSign bits set. = The extended key usage extension should include at least the = id-kp-OCSPSigning object identifier. >=20 > Russ >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 --Apple-Mail-69-1037177393 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Denis = and David:

In my original message, I said: "Do you = mean that the same private key is used by the CA to sign certificates, = CRLs, and OCSP Responses?"  My response was in that = context.

RFC 2560 certainly requires the = id-kp-Sigining OID in certificates that are directly subordinate to = the CA certificate that will be used to validate OCSP responses. =  Re-reading it just now, I still do not see anything that says = the id-kp-Sigining OID cannot be in the CA = certificate. 

The point that David Cooper = raises needs further discussion.  I'm uncomfortable with his = conclusion, but there is nothing in RFC 5280 that I can point to as = justification.  However, the most recent version of X.509 does = offer some support.  It says: "This field indicates one or more = purposes for which the certified public key may be used, in addition to = or in place of the basic purposes indicated in the key usage extension = field."

Russ


On May 25, 2012, at 2:41 PM, denis.pinkas@bull.net = wrote:

Russ,

We only agree on two points:

 - Since the CA issues = certificates, the keyCertSign bit MUST be set.
 - Since the CA signs OCSP = responses, the digitalSignature bit MUST be set

However, when the CA does not issue = CRLs, the cRLSign bit MUST NOT be set.

Changing the content of RFC 2560 = about the meaning of id-kp-OCSPSigning OID is impossible.
As you know, id-kp-OCSPSigning is defined through an OID which has a = precise meaning.
If you change the meaning, then you need to define a new OID.


So your proposal to include the = id-kp-OCSPSigning OID in the extended key usage extension
cannot be accepted.


It is also unnecessary, even with a = new OID.

Denis



De :   =      Russ Housley <housley@vigilsec.com>
A :   =      denis.pinkas@bull.net
Cc : =        IETF PKIX = <pkix@ietf.org>, Rob Stradling <rob.stradling@comodo.com><= /font>
Date :   =      25/05/2012 = 19:18
Objet : =        Re: [pkix] = Integrated OCSP Responders / Key Usage bits




Denis:

I think my reply to David is consistent with your = analysis.  My first reply was incorrect; the digitalSignature key usage bit needs to be set.

My summary:
Since the CA issues certificates, the keyCertSign = bit MUST be set.
Since the CA issues CRLs, the cRLSign bit MUST be = set.
Since the CA signs OCSP responses, the = digitalSignature bit MUST be set, and
    the id-kp-OCSOSigning OID MAY be = present.

I think including the id-kp-OCSOSigning OID is = desirable.  It indicates the intention to sign OCSP responses even though it is not require by RFC 2560.

Russ


On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote:

Russ,

I raised the question in my presentation on OCSP during the last PKIX = session in Paris,
since there is currently no answer in the PKIX documents.


I don't believe that your response is correct.
=

The id-kp-OCSPSigning object identifier is only for a designated OCSP = responder.
This is not the case we are considering in this discussion.


RFC 2560 states: "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate extension included in the OCSP = response signer's certificate".


Ideally, we should have added an OCSP signing bit in the key usage bits, but unfortunately
nobody raised the point when we built RFC 2560.
=

Rob mentioned the (relatively recently published) CABForum Baseline = Requirements
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate CA Private Key is used for signing OCSP = responses, then
the digitalSignature bit MUST be set."


I don't believe that this response is correct either, since in the = general case an upper CA
does not sign OCSP responses for a lower CA.


Let me propose a strawman:


The keyCertSign bit and the digitalSignature bit MUST be = set.

The cRLSign bit MAY be set.


A few explanations are needed.
Since the CA issues certificates, the keyCertSign bit MUST be = set.

Since the CA signs OCSP responses, the digitalSignature bit MUST be set.
If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST be set,
otherwise it MUST NOT be set.


Let us now suppose that a CA starts to issue CRLs and that, later on, = the CA wants to issue OCSP responses.
With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since
the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.


Note: Any proposal will break some eggs and make an omelet, since, = without guidance, implementers did "something".
=
       What is strange is that OCSP currently works !
       I would guess most implementations only test the keyCertSign bit.


Denis




De :        
Russ Housley <housley@vigilsec.com>
A :        
Rob Stradling <rob.stradling@comodo.com>
Cc :        
pkix@ietf.org
Date :        
25/05/2012 17:50
Objet :        
Re: [pkix] Integrated OCSP Responders / Key Usage bits=
Envoy=E9 par :        
pkix-bounces@ietf.org




Rob:

> Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign = certificates, CRLs, and OCSP Responses?  If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The = extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ



_______________________________________________
pkix mailing list

pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix



= --Apple-Mail-69-1037177393-- From mstjohns@comcast.net Fri May 25 12:58:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64BF21F87B9 for ; Fri, 25 May 2012 12:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFz-0OKphjNb for ; Fri, 25 May 2012 12:58:11 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9519A21F87C1 for ; Fri, 25 May 2012 12:58:11 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id EGwb1j00D1smiN4A1KyBiu; Fri, 25 May 2012 19:58:11 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta20.emeryville.ca.mail.comcast.net with comcast id EKxx1j01W57vnMg8gKxyZa; Fri, 25 May 2012 19:58:11 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 May 2012 15:57:49 -0400 To: Phillip Hallam-Baker ,pkix@ietf.org From: Michael StJohns In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_941309486==.ALT" Message-Id: <20120525195811.9519A21F87C1@ietfa.amsl.com> Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:58:12 -0000 --=====================_941309486==.ALT Content-Type: text/plain; charset="us-ascii" I hesitate to respond to this, but my review of the bidding is not that there wasn't a conclusion, but that there was no consensus for change. I think I support the status quo. Assuming a "Root CA -> CA with Name Constraint -> End Entity certificate chain" there are three degrees of freedom: 1) Whether the NC is marked critical, 2) whether the EE certificate has a name compliant with the NC, and 3) whether the RP understands the NC extension. The combinations are thus: Critical/Compliant/Understands - > Accepts the cert Critical/Compliant/Does not understand -> Rejects the cert **** Critical/Non-Compliant/Understands -> Rejects the cert Critical/Non-Compliant/Does not understand -> Rejects the cert Non-Critical/Compliant/Understands -> Accepts the cert Non-Critical/Compliant/Does not understand -> Accepts the cert Non-Critical/Non-Compliant/Understands -> Rejects the cert Non-Critical/Non-Compliant/Does not understand -> Accepts the cert. **** (There is one other combination - no NC present -> Accepts the cert) The two items marked with **** are combinations where possibly the "wrong" thing happened. The first one is just due to the implementation at the RP not being complete enough, but complies with the policy imposed on the NC CA by the root. The second is due to a violation of policy - the NC CA was able to issue a certificate with a name that violated the name constraints imposed upon it by the root CA and have it accepted by an RP that didn't understand the NC extension. You also end up with a situation where a "GOOD" RP (one that understands the NC), ends up rejecting the certificate - which is probably not what you wanted. Phil - you're proposing a change which is the equivalent of posting a guard at the door to a building and requiring the guard to reject bad badges if they are offered, but allowing anyone who doesn't present a badge to enter the building. If the Root CA doesn't care about enforceable name constraints, it probably shouldn't include them in the NC CA certificate. If it wants them to be enforced, then the NC extension needs to be marked critical. And on a last topic. I'm finding the arm twisting a bit distasteful. If the CAB forum wants to pick its marbles and leave, just do it and stop trying to coerce the process. Mike At 12:47 PM 5/25/2012, Phillip Hallam-Baker wrote: >The issue was discussed here earlier without a conclusion. I just wanted to point out that the issue is currently the subject of a ballot in CABForum: > >http://cabforum.org/pipermail/public/2012-May/000027.html > >Delete the following text from the "Subordinate CA Certificate" section of both the Baseline Requirements Appendix B and EV Guidelines Appendix B: >"All other fields and extensions MUST be set in accordance to RFC 5280." >AND replace it with the following: >"F. nameConstraints (optional) >. If present, this extension SHOULD be marked critical*. >All other fields and extensions MUST be set in accordance to RFC 5280. >* Non-critical Name Constraints are an exception to RFC 5280 that MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide." > > >Anyone who wants to follow the ballot discussion can do so at: >http://cabforum.org/mailman/listinfo/public > >The reason this change is being considered is as follows: > >1) Deployment of name constraints without a criticality flag provides an immediate an advantageous reduction in risk without impact on any deployed systems. > >2) Deployment of name constraints with a criticality flag would entail an unacceptable incompatibility with widely deployed systems. > >3) None of the following reasons advanced for requiring name constraints to be marked critical has been found to be persuasive: > >3a) 'Critical means important' - no it does not, clients are required to process extensions that they understand regardless of whether they are marked critical or not. > >3b) 'This is not a requirement for the DoD' - this is not about the DoD PKI. > >3c) 'People should deploy RFC 5280 compliant systems rather than change the spec' - This is not a normative argument. People should live in brotherly peace and harmony too but the fact that they don't is the reason we need PKI in the first place. > >This change has been considered by a group of experts whose credentials and experience in the PKI space is at least equal to that of this WG. So please, no appeals to authority. > > >Should this ballot pass, I will submit an ID to propose making the same change to RFC5280 as an erratum. In my personal view, it is clearly desirable for the IETF specifications to track the deployed specification. > >-- >Website: http://hallambaker.com/ > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix --=====================_941309486==.ALT Content-Type: text/html; charset="us-ascii" I hesitate to respond to this, but my review of the bidding is not that there wasn't a conclusion, but that there was no consensus for change.

I think I support the status quo.


Assuming a "Root CA -> CA with Name Constraint -> End Entity certificate chain" there are three degrees of freedom:  1) Whether the NC is marked critical, 2) whether the EE certificate has a name compliant with the NC, and 3) whether the RP understands the NC extension.

The combinations are thus:

Critical/Compliant/Understands - >  Accepts the cert
Critical/Compliant/Does not understand -> Rejects the cert  ****
Critical/Non-Compliant/Understands -> Rejects the cert
Critical/Non-Compliant/Does not understand -> Rejects the cert
Non-Critical/Compliant/Understands -> Accepts the cert
Non-Critical/Compliant/Does not understand -> Accepts the cert
Non-Critical/Non-Compliant/Understands -> Rejects the cert
Non-Critical/Non-Compliant/Does not understand -> Accepts the cert.  ****

(There is one other combination - no NC present -> Accepts the cert)

The two items marked with **** are combinations where possibly the "wrong" thing happened.  The first one is just due to the implementation at the RP not being complete enough, but complies with the policy imposed on the NC CA by the root.  The second is due to a violation of policy - the NC CA was able to issue a certificate with a name that violated the name constraints imposed upon it by the root CA and have it accepted by an RP that didn't understand the NC extension.

You also end up with a situation where a "GOOD" RP (one that understands the NC), ends up rejecting the certificate - which is probably not what you wanted.

Phil - you're proposing a change which is the equivalent of posting a guard at the door to a building and requiring the guard to reject bad badges if they are offered, but allowing anyone who doesn't present a badge to enter the building.

If the Root CA doesn't care about enforceable name constraints, it probably shouldn't include them in the NC CA certificate.  If it wants them to be enforced, then the NC extension needs to be marked critical.

And on a last topic.  I'm finding the arm twisting a bit distasteful.  If the CAB forum wants to pick its marbles and leave, just do it and stop trying to coerce the process.

Mike




At 12:47 PM 5/25/2012, Phillip Hallam-Baker wrote:
The issue was discussed here earlier without a conclusion. I just wanted to point out that the issue is currently the subject of a ballot in CABForum:

http://cabforum.org/pipermail/public/2012-May/000027.html

Delete the following text from the "Subordinate CA Certificate" section of both the Baseline Requirements Appendix B and EV Guidelines Appendix B:
"All other fields and extensions MUST be set in accordance to RFC 5280."
AND replace it with the following:
"F. nameConstraints (optional)
. If present, this extension SHOULD be marked critical*.
All other fields and extensions MUST be set in accordance to RFC 5280.
* Non-critical Name Constraints are an exception to RFC 5280 that MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide."


Anyone who wants to follow the ballot discussion can do so at:
http://cabforum.org/mailman/listinfo/public

The reason this change is being considered is as follows:

1) Deployment of name constraints without a criticality flag provides an immediate an advantageous reduction in risk without impact on any deployed systems.

2) Deployment of name constraints with a criticality flag would entail an unacceptable incompatibility with widely deployed systems.

3) None of the following reasons advanced for requiring name constraints to be marked critical has been found to be persuasive:

3a) 'Critical means important' - no it does not, clients are required to process extensions that they understand regardless of whether they are marked critical or not.

3b) 'This is not a requirement for the DoD' - this is not about the DoD PKI.

3c) 'People should deploy RFC 5280 compliant systems rather than change the spec' - This is not a normative argument. People should live in brotherly peace and harmony too but the fact that they don't is the reason we need PKI in the first place.

This change has been considered by a group of experts whose credentials and experience in the PKI space is at least equal to that of this WG. So please, no appeals to authority.


Should this ballot pass, I will submit an ID to propose making the same change to RFC5280 as an erratum. In my personal view, it is clearly desirable for the IETF specifications to track the deployed specification.

--
Website: http://hallambaker.com/

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--=====================_941309486==.ALT-- From wtc@google.com Fri May 25 13:52:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E434421F87EA for ; Fri, 25 May 2012 13:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUuDAI9RKcz3 for ; Fri, 25 May 2012 13:52:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96B21F87E7 for ; Fri, 25 May 2012 13:52:40 -0700 (PDT) Received: by yenq13 with SMTP id q13so814539yen.31 for ; Fri, 25 May 2012 13:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=bQwH/FT630HTybVi5ZbGbqVjE995NYhnA/pL3z/yItw=; b=F/Sw+PzPDS/kgdBiLNpxx1i+RmqPeG23ZoeDeK1YAH+w376PXyxy90aB/eDr7h1/gE WZaK4Pk91LUWNuPYwTt7qqYbyQwz9o1cR/Cx1EPJrZnu3tJ2XgjdXUkZtnHyaCPkUIE/ Fmacd45f9f/t3rUo9C9wyXFb4Rvs4HQk2k9gYX6ngHkEt9+xebYhaTE9ihZT/yK2sptE 49w+pJy/jd5Q2HQgDigy0EcOY3LpsEPewAytbc/vqVwq9kAzaY9hfxOggEsvjOCmW3Tp P7nWk/dFyNG4fZRmPJrG3RWfYou1YP4ktJCGs8tRL6d1g+qz8sJpB1lIMi8UgQ+rqoai 6jDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=bQwH/FT630HTybVi5ZbGbqVjE995NYhnA/pL3z/yItw=; b=guZzukV8aE9rYPjFJcPv/YVnmICzwBxAqkobyLnD0x6TO+46w72o7xqG4BZJ44YPWO dNDzn/Lkbjv1kiW/Tjp6EMVVwSSei38ACdPzEIW0UCmof5+flbPVJs+mFpE7kVGgFfFc JNwXJqUTgTgIamyJzjnvNz/ZATtXJC7PHQgcDciIyNSd/Cj5uu22oViRiq2d1IO9g+wg 1ic7mNSh/eJzYTQi2bDVz5zGNIxpLZostvdfrtj6OSbu5QuXcdxiUTBBCF3s+am9gZrs QuoCajJqTJrrlulg8DBhCeOUZEKUXU87d9uhyRzi1QMGWCkewbGMf4qAGXjXrNM7yB+Q rFbg== Received: by 10.50.76.163 with SMTP id l3mr243495igw.55.1337979159502; Fri, 25 May 2012 13:52:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.76.163 with SMTP id l3mr243486igw.55.1337979159404; Fri, 25 May 2012 13:52:39 -0700 (PDT) Received: by 10.231.245.74 with HTTP; Fri, 25 May 2012 13:52:39 -0700 (PDT) In-Reply-To: <20120525195811.9519A21F87C1@ietfa.amsl.com> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> Date: Fri, 25 May 2012 13:52:39 -0700 Message-ID: From: Wan-Teh Chang To: Michael StJohns Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkg9qz2r3Z6nWh3cjliDAILyguexA49H2kiTd27Kki88Uq6/Hqysn5uHPBP+sS6MGC+2VK0WwDevbHQ5SWgZkV1sVUeBmrIRMDJbHFI+fFuDcHX3MxcQ9sXxBewd/hoejD4+Qyk Cc: pkix@ietf.org Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:52:41 -0000 On Fri, May 25, 2012 at 12:57 PM, Michael StJohns wrote: > > Phil - you're proposing a change which is the equivalent of posting a guard > at the door to a building and requiring the guard to reject bad badges if > they are offered, but allowing anyone who doesn't present a badge to enter > the building. No. A better analogy is as follows: Current status: no buildings have a guard posted. A person who doesn't present a badge can enter all buildings. Proposed change: some buildings will have guards posted. A person who doesn't present a badge can still enter the buildings that have no guards, but won't be able to enter the buildings that have guards posted. Wan-Teh From mrex@sap.com Fri May 25 13:59:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9321F8802 for ; Fri, 25 May 2012 13:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2Q5Mc0+-z-0 for ; Fri, 25 May 2012 13:59:27 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC2621F87F1 for ; Fri, 25 May 2012 13:59:27 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4PKxDno001503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 May 2012 22:59:18 +0200 (MEST) From: Martin Rex Message-Id: <201205252059.q4PKxCYB018804@fs4113.wdf.sap.corp> To: mstjohns@comcast.net (Michael StJohns) Date: Fri, 25 May 2012 22:59:12 +0200 (MEST) In-Reply-To: <20120525195811.9519A21F87C1@ietfa.amsl.com> from "Michael StJohns" at May 25, 12 03:57:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:59:28 -0000 Michael StJohns wrote: > > Phil - you're proposing a change which is the equivalent of posting > a guard at the door to a building and requiring the guard to reject > bad badges if they are offered, but allowing anyone who doesn't > present a badge to enter the building. This is an incorrect analogy. The certificate holder himself can not selectively make the name constraint invisible to RPs. ONLY the issuing CA can perform an educated individual risk management decision whether a name constraint imposed on a certificate it issues must be unconditionally enforced, or whether it is sufficient when only the RPs that care reject it. Since it is up to the CA that issues the cert, it remains in full control of the feature. There will be exactly ZERO unforseeable consequences, and it is the behaviour recommended by X.509! (and where the PKIX profile differs from X.509 without providing a justification--and no matter how much you and others in the PKIX WG have been writing, I have not seen a single rationale that could justify to _not_ let the CA decide about criticality of name constraints. > > If the Root CA doesn't care about enforceable name constraints, > it probably shouldn't include them in the NC CA certificate. > If it wants them to be enforced, then the NC extension needs > to be marked critical. I'm sorry, but that explanation does not account for the fact that support for name constraints has always been, and still is optional for RPs and has resulted in a huge installed base that does, in fact, not support name constraints (that includes all version of OpenSSL < 1.0) > > And on a last topic. I'm finding the arm twisting a bit distasteful. > If the CAB forum wants to pick its marbles and leave, just do it and > stop trying to coerce the process. The idea behind X.509 certificate profiles is that consumers can select the certificate profile that fits best their usage requirements. As it has become obvious, the certificate profile that calls itself the "Internet Certificate and CRL profile" has been neglecting itself and the installed base on what it says about name constraints. There are two possible resolutions: the Internet Certificate and CRL profile (PKIX) is changed to match the installed base, or the applications will have to use a different or modified profile that matches their requirements better. Listen to your customers, or your customers will eventually go elsewhere! -Martin From david.cooper@nist.gov Fri May 25 14:09:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6521F8818 for ; Fri, 25 May 2012 14:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFlTKY8FU1uI for ; Fri, 25 May 2012 14:09:39 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 1753A21F8814 for ; Fri, 25 May 2012 14:09:39 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 25 May 2012 17:09:29 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Fri, 25 May 2012 17:08:22 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q4PL9bB9020945; Fri, 25 May 2012 17:09:37 -0400 Message-ID: <4FBFF511.4020107@nist.gov> Date: Fri, 25 May 2012 17:09:37 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120426 Thunderbird/12.0 MIME-Version: 1.0 To: Russ Housley References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> <20F003EC-0620-45B5-BA3E-7984CCC6C671@vigilsec.com> In-Reply-To: <20F003EC-0620-45B5-BA3E-7984CCC6C671@vigilsec.com> Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:09:40 -0000 Russ,

The most recent version of X.509 that I have (11/2008) also says:
If a certificate contains both a critical key usage field and a critical extended key usage field, then both fields shall be processed independently and the certificate shall only be used for a purpose consistent with both fields. If there is no purpose consistent with both fields, then the certificate shall not be used for any purpose.

I don't know why it says "critical" since the text says that even it the extension is non-critical applications that can process the extension shall only use the certificate for the purposes indicated in the extension.

Dave

On 05/25/2012 03:29 PM, Russ Housley wrote:
Denis and David:

In my original message, I said: "Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses?"  My response was in that context.

RFC 2560 certainly requires the id-kp-Sigining OID in certificates that are directly subordinate to the CA certificate that will be used to validate OCSP responses.  Re-reading it just now, I still do not see anything that says the id-kp-Sigining OID cannot be in the CA certificate. 

The point that David Cooper raises needs further discussion.  I'm uncomfortable with his conclusion, but there is nothing in RFC 5280 that I can point to as justification.  However, the most recent version of X.509 does offer some support.  It says: "This field indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension field."

Russ


On May 25, 2012, at 2:41 PM, denis.pinkas@bull.net wrote:

Russ,

We only agree on two points:

 - Since the CA issues certificates, the keyCertSign bit MUST be set.
 - Since the CA signs OCSP responses, the digitalSignature bit MUST be set

However, when the CA does not issue CRLs, the cRLSign bit MUST NOT be set.

Changing the content of RFC 2560 about the meaning of id-kp-OCSPSigning OID is impossible.
As you know, id-kp-OCSPSigning is defined through an OID which has a precise meaning.
If you change the meaning, then you need to define a new OID.


So your proposal to include the id-kp-OCSPSigning OID in the extended key usage extension
cannot be accepted.


It is also unnecessary, even with a new OID.

Denis



De :        Russ Housley <housley@vigilsec.com>
A :        denis.pinkas@bull.net
Cc :        IETF PKIX <pkix@ietf.org>, Rob Stradling <rob.stradling@comodo.com>
Date :        25/05/2012 19:18
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits




Denis:

I think my reply to David is consistent with your analysis.  My first reply was incorrect; the digitalSignature key usage bit needs to be set.

My summary:
Since the CA issues certificates, the keyCertSign bit MUST be set.
Since the CA issues CRLs, the cRLSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set, and
    the id-kp-OCSOSigning OID MAY be present.

I think including the id-kp-OCSOSigning OID is desirable.  It indicates the intention to sign OCSP responses even though it is not require by RFC 2560.

Russ


On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote:

Russ,

I raised the question in my presentation on OCSP during the last PKIX session in Paris,
since there is currently no answer in the PKIX documents.


I don't believe that your response is correct.


The id-kp-OCSPSigning object identifier is only for a designated OCSP responder.
This is not the case we are considering in this discussion.


RFC 2560 states: "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate".


Ideally, we should have added an OCSP signing bit in the key usage bits, but unfortunately
nobody raised the point when we built RFC 2560.


Rob mentioned the (relatively recently published) CABForum Baseline Requirements
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate CA Private Key is used for signing OCSP responses, then
the digitalSignature bit MUST be set."


I don't believe that this response is correct either, since in the general case an upper CA
does not sign OCSP responses for a lower CA.


Let me propose a strawman:


The keyCertSign bit and the digitalSignature bit MUST be set.

The cRLSign bit MAY be set.


A few explanations are needed.
Since the CA issues certificates, the keyCertSign bit MUST be set.

Since the CA signs OCSP responses, the digitalSignature bit MUST be set.
If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST be set,
otherwise it MUST NOT be set.


Let us now suppose that a CA starts to issue CRLs and that, later on, the CA wants to issue OCSP responses.
With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since
the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.


Note: Any proposal will break some eggs and make an omelet, since, without guidance, implementers did "something".

       What is strange is that OCSP currently works !
       I would guess most implementations only test the keyCertSign bit.


Denis




De :        
Russ Housley <housley@vigilsec.com>
A :        
Rob Stradling <rob.stradling@comodo.com>
Cc :        
pkix@ietf.org
Date :        
25/05/2012 17:50
Objet :        
Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoyé par :        
pkix-bounces@ietf.org




Rob:

> Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses?  If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ



_______________________________________________
pkix mailing list

pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix




From hallam@gmail.com Fri May 25 14:29:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2AC21F880F for ; Fri, 25 May 2012 14:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PxC2nDrwJXj for ; Fri, 25 May 2012 14:29:07 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4949A21F880C for ; Fri, 25 May 2012 14:29:07 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2101437obb.31 for ; Fri, 25 May 2012 14:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZAfaP4FolTiCwYwzonaxlxs363qiyeBr7CLF8oushOU=; b=kRcOgxPo/LqXYh/8n8K21EB1VA7ZJCEAIHLd8aVP4xK1Xg5RjXDQGGDSQHXIDMMU7P W5mDME9uzd4a82YpFwebE4WmJMD/tfTbMAqEAk2B1tzH5vXx6vPxzWsRRl9CPGe3Vlbr Q+QUI2HUjLIGRZ/IbJkeyVeFkvONJep0W7CeH5Qpz6PpzB/WOWR6MC7Pd8f7v6l5Z9x6 J0xEIp5xDXVJJG7yfj3C3SggYULQVsaJ636tU0jiqXj7mUHQZxvkhXucCEZiOqWk1jpC CP8gimvu3rDUmp+oV7WX18QqCQm65RXR1hQ0YMVPlqiEcs0U1Pvgp+LdD7bHa9kAz63o 7hIQ== MIME-Version: 1.0 Received: by 10.182.8.99 with SMTP id q3mr320684oba.63.1337981346547; Fri, 25 May 2012 14:29:06 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Fri, 25 May 2012 14:29:06 -0700 (PDT) In-Reply-To: <4fbfe453.2882440a.42e9.1e29SMTPIN_ADDED@mx.google.com> References: <4fbfe453.2882440a.42e9.1e29SMTPIN_ADDED@mx.google.com> Date: Fri, 25 May 2012 17:29:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d0444ed59e087d204c0e30e81 Cc: pkix@ietf.org Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:29:08 -0000 --f46d0444ed59e087d204c0e30e81 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 25, 2012 at 3:57 PM, Michael StJohns wrote: > I hesitate to respond to this, but my review of the bidding is not that > there wasn't a conclusion, but that there was no consensus for change. > > I think I support the status quo. > > > Assuming a "Root CA -> CA with Name Constraint -> End Entity certificate > chain" there are three degrees of freedom: 1) Whether the NC is marked > critical, 2) whether the EE certificate has a name compliant with the NC, > and 3) whether the RP understands the NC extension. > > The combinations are thus: > > Critical/Compliant/Understands - > Accepts the cert > Critical/Compliant/Does not understand -> Rejects the cert **** > Critical/Non-Compliant/Understands -> Rejects the cert > Critical/Non-Compliant/Does not understand -> Rejects the cert > Non-Critical/Compliant/Understands -> Accepts the cert > Non-Critical/Compliant/Does not understand -> Accepts the cert > Non-Critical/Non-Compliant/Understands -> Rejects the cert > Non-Critical/Non-Compliant/Does not understand -> Accepts the cert. **** > > (There is one other combination - no NC present -> Accepts the cert) > > The two items marked with **** are combinations where possibly the "wrong" > thing happened. The first one is just due to the implementation at the RP > not being complete enough, but complies with the policy imposed on the NC > CA by the root. The second is due to a violation of policy - the NC CA was > able to issue a certificate with a name that violated the name constraints > imposed upon it by the root CA and have it accepted by an RP that didn't > understand the NC extension. > I don't understand your analysis here. Nothing that is being proposed will actually affect the required behavior of the clients. The only thing that will change is that CAs will now be permitted to issue certificates with a non critical NC constraint and so the last four cases are more likely to occur. We don't actually have the following conditions occurring in the wild: Non-Critical/Compliant/Understands -> REJECT for violating RFC5280 Non-Critical/Compliant/Does not understand -> REJECT for violating RFC5280 Non-Critical/Non-Compliant/Understands -> REJECT for violating RFC5280 Non-Critical/Non-Compliant/Does not understand -> REJECT for violating RFC5280 So we are not talking about a change in code here, merely a change in what CAs will be issuing. You also end up with a situation where a "GOOD" RP (one that understands > the NC), ends up rejecting the certificate - which is probably not what you > wanted. > That is not an observed behavior in existing systems. The criticality flag does not affect the semantics of an extension. The only change in behavior is directed at systems that don't support the extension. In this case the desired behavior is that systems that do not enforce NCs ignore them and accept the certificate. > Phil - you're proposing a change which is the equivalent of posting a > guard at the door to a building and requiring the guard to reject bad > badges if they are offered, but allowing anyone who doesn't present a badge > to enter the building. > Absolutely not the case. What I am proposing is exactly what Visa and MasterCard have done with chip and pin. If you have a C&P card then you must use the C&P authentication system but a C&P enabled POS terminal MAY accept legacy mag stripe cards because the US banks are too thick to realize that there is a demand. Now in practice there are many merchants that do in fact adopt your approach which is why using US issued CCs is now almost impossible in non-tourist parts of Europe. Whatever the interchange agreement might say, many merchants do not accept magstripe cards and the European banks have zero intention of forcing them to. If the Root CA doesn't care about enforceable name constraints, it probably > shouldn't include them in the NC CA certificate. If it wants them to be > enforced, then the NC extension needs to be marked critical. > That is your opinion. The CAs and the browser providers appear to have come to a different conclusion. > And on a last topic. I'm finding the arm twisting a bit distasteful. If > the CAB forum wants to pick its marbles and leave, just do it and stop > trying to coerce the process. > You mean, like was done to the ITU X.509 working group almost twenty years ago now. The fact is that I am rather tired of the current situation where only the US Govt. and its contractors get to have any input into this working group. Or more specifically the US DoD and its contractors. We have a real world constraint here that we have to meet in our deployment. Progress in the WG was held up by a handful of people who have no stake in the matter. So the decision has moved elsewhere. If you don't like that outcome then maybe this WG needs to rethink the way that it works as have many other IETF WGs. I really don't see a reason why US DoD and its contractors should get to veto standards for commercial PKI. At present the assumption seems to be that PKIX is perfect and any proposal for change should begin from the presumption that change is bad. Other WGs have decided that change is a good thing and that opponents should be able to point to some harm. You can try to pretend that the only reason for the current breakdown in the relationship between the PKI industry and the PKIX working group is that the commercial CAs and browser providers don't understand the security risks. I think it is rather ridiculous that the WG would want to take the disagreement to the point of forcing an actual divorce. To take it to the point of a breach over a single bit is a bit like having a As far as I am concerned the mandate of this WG is not to teach the industry how to suck eggs. We really do have quite a bit of security expertise. The scope of PKIX should be strictly limited to defining standards and specifications. It should explain the security consequences of a configuration but it should not presume to decide what the appropriate risk mitigation strategy is for the industry. The only reason we have a schism here is because the PKIX WG has overstepped the scope of authority that the industry is willing to grant it. You can get upset about that if you like. But remember how this started. The industry came to IETF because it was unhappy with ITU process. The only reason that PKIX matters is because there is an industry that mad it matter. You might want the PKIX WG to have authority over the industry, but that was never the deal. -- Website: http://hallambaker.com/ --f46d0444ed59e087d204c0e30e81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 25, 2012 at 3:57 PM, Michael= StJohns <mstjohns@comcast.net> wrote:
I hesitate to respond to this, but my review of the bidding is not that there wasn't a conclusion, but that there was no consensus for change.

I think I support the status quo.


Assuming a "Root CA -> CA with Name Constraint -> End Entity certificate chain" there are three degrees of freedom:=A0 1) Whether the NC is marked critical, 2) whether the EE certificate has a name compliant with the NC, and 3) whether the RP understands the NC extension.

The combinations are thus:

Critical/Compliant/Understands - >=A0 Accepts the cert
Critical/Compliant/Does not understand -> Rejects the cert=A0 ****
Critical/Non-Compliant/Understands -> Rejects the cert
Critical/Non-Compliant/Does not understand -> Rejects the cert
Non-Critical/Compliant/Understands -> Accepts the cert
Non-Critical/Compliant/Does not understand -> Accepts the cert
Non-Critical/Non-Compliant/Understands -> Rejects the cert
Non-Critical/Non-Compliant/Does not understand -> Accepts the cert.=A0 ****

(There is one other combination - no NC present -> Accepts the cert)

The two items marked with **** are combinations where possibly the "wrong" thing happened.=A0 The first one is just due to the implementation at the RP not being complete enough, but complies with the policy imposed on the NC CA by the root.=A0 The second is due to a violation of policy - the NC CA was able to issue a certificate with a name that violated the name constraints imposed upon it by the root CA and have it accepted by an RP that didn't understand the NC extension.

I don't understand your anal= ysis here.

Nothing that is being proposed will act= ually affect the required behavior of the clients. The only thing that will= change is that CAs will now be permitted to issue certificates with a non = critical NC constraint and so the last four cases are more likely to occur.=

We don't actually have the following conditions occ= urring in the wild:

Non-Critical/Compliant/<= /span>Understands -> REJECT for violating RFC5280=A0
Non-Critical/Compliant/Does not understand ->=A0 REJECT for violating RFC5280=A0=A0
Non-Critical/Non-C= ompliant/Understands ->=A0 REJECT for violating RFC5280=A0=A0
Non-Critical/Non-C= ompliant/Does not understand ->=A0REJECT for v= iolating RFC5280=A0

So we are not talking about a change in code here, merely a change in what = CAs will be issuing.


You also end up with a situation where a "GOOD" RP (one that understands the NC), ends up rejecting the certificate - which is probably not what you wanted.

Tha= t is not an observed behavior in existing systems. The criticality flag doe= s not affect the semantics of an extension. The only change in behavior is = directed at systems that don't support the extension.

In this case the desired behavior is that systems that = do not enforce NCs ignore them and accept the certificate.

=A0
Phil - you're proposing a change which is the equivalent of posting a guard at the door to a building and requiring the guard to reject bad badges if they are offered, but allowing anyone who doesn't present a badge to enter the building.

Abso= lutely not the case. What I am proposing is exactly what Visa and MasterCar= d have done with chip and pin. If you have a C&P card then you must use= the C&P authentication system but a C&P enabled POS terminal MAY a= ccept legacy mag stripe cards because the US banks are too thick to realize= that there is a demand.

Now in practice there are many merchants that do in fac= t adopt your approach which is why using US issued CCs is now almost imposs= ible in non-tourist parts of Europe. Whatever the interchange agreement mig= ht say, many merchants do not accept magstripe cards and the European banks= have zero intention of forcing them to.


If the Root CA doesn't care about enforceable name constraints, it probably shouldn't include them in the NC CA certificate.=A0 If it wants them to be enforced, then the NC extension needs to be marked critical.

That is your opinion. T= he CAs and the browser providers appear to have come to a different conclus= ion.

=A0
And on a last topic.=A0 I'm finding the arm twisting a bit distasteful.=A0 If the CAB forum wants to pick its marbles and leave, just do it and stop trying to coerce the process.

You mean, like was done to the ITU X.509 working group alm= ost twenty years ago now.

The fact is that I am ra= ther tired of the current situation where only the US Govt. and its contrac= tors get to have any input into this working group. Or more specifically th= e US DoD and its contractors.

We have a real world constraint here that we have to me= et in our deployment. Progress in the WG was held up by a handful of people= who have no stake in the matter. So the decision has moved elsewhere. If y= ou don't like that outcome then maybe this WG needs to rethink the way = that it works as have many other IETF WGs.

I really don't see a reason why US DoD and its cont= ractors should get to veto standards for commercial PKI.

At present the assumption seems to be that PKIX is perfect and any p= roposal for change should begin from the presumption that change is bad. Ot= her WGs have decided that change is a good thing and that opponents should = be able to point to some harm.


You can try to pretend that the only rea= son for the current breakdown in the relationship between the PKI industry = and the PKIX working group is that the commercial CAs and browser providers= don't understand the security risks. I think it is rather ridiculous t= hat the WG would want to take the disagreement to the point of forcing an a= ctual divorce. To take it to the point of a breach over a single bit is a b= it like having a=A0

As far as I am concerned the mandate of this WG is not = to teach the industry how to suck eggs. We really do have quite a bit of se= curity expertise.

The scope of PKIX should be stri= ctly limited to defining standards and specifications. It should explain th= e security consequences of a configuration but it should not presume to dec= ide what the appropriate risk mitigation strategy is for the industry.


The only reason we have a schism here is= because the PKIX WG has overstepped the scope of authority that the indust= ry is willing to grant it. You can get upset about that if you like. But re= member how this started. The industry came to IETF because it was unhappy w= ith ITU process. The only reason that PKIX matters is because there is an i= ndustry that mad it matter.

You might want the PKIX WG to have authority over the i= ndustry, but that was never the deal.

=A0
--
Website: ht= tp://hallambaker.com/

--f46d0444ed59e087d204c0e30e81-- From hallam@gmail.com Fri May 25 20:14:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4324411E8089 for ; Fri, 25 May 2012 20:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDzUegocLArW for ; Fri, 25 May 2012 20:14:01 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20D8711E8080 for ; Fri, 25 May 2012 20:14:01 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2496930obb.31 for ; Fri, 25 May 2012 20:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SasxR0pGYFDntuxCLQUCf83rLoJsQ3QZJ89cZVkKjic=; b=RXfI1+JRAUke2KVbNSEaMQHsbWXiulzi0brhgmQkSRlt8YCBng5rS6WbW/7bfL4hwg Pd8Va3Jm2Zx82wYOo/kw17x6dqp/1n5Vamj5VNV/MRgmj1TNSv/SzwbDyRdEFJz6ZgiU 4GD4OOH9h4x5xlPbER086pcWXEHFLBrh0jaybkv9Wg7OprSY3VxYVIIIMHbMMcCCBYCU UR5uQqyhYys4bjz92HvO9qCVsOmJ41GAiAaIhPMjFO3m2SSa4cKvpHTRXgOn1Q/A0Lki +XMYjMfsFUr2MNCViN5hsaFC9Dxyd/n8szGqHFPR8p6xjZWXa/P6TLa41Zv63wu+zaey 2vbQ== MIME-Version: 1.0 Received: by 10.60.29.137 with SMTP id k9mr1075011oeh.23.1338002039953; Fri, 25 May 2012 20:13:59 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Fri, 25 May 2012 20:13:59 -0700 (PDT) In-Reply-To: <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> Date: Fri, 25 May 2012 23:13:59 -0400 Message-ID: From: Phillip Hallam-Baker To: ryan-ietftls@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 03:14:02 -0000 That is precisely right, the desired behavior is: Compliant/Understands -> Accepts the cert Compliant/Does not understand -> Accepts the cert Non-Compliant/Understands -> Rejects the cert Non-Compliant/Does not understand -> Accepts the cert. We expressly DO NOT WANT browsers to reject a certificate unless they understand the NC constraint. That is the behavior we desire. That is precisely the behavior that not setting the criticality bit provide= s. On Fri, May 25, 2012 at 10:03 PM, Ryan Sleevi wro= te: >> =A0I hesitate to respond to this, but my review of the bidding is not th= at >> =A0there wasn't a conclusion, but that there was no consensus for change= . >> >> =A0I think I support the status quo. >> >> >> =A0Assuming a "Root CA -> CA with Name Constraint -> End Entity certific= ate >> =A0chain" there are three degrees of freedom: =A01) Whether the NC is ma= rked >> =A0critical, 2) whether the EE certificate has a name compliant with the= NC, >> =A0and 3) whether the RP understands the NC extension. >> >> =A0The combinations are thus: >> >> =A0Critical/Compliant/Understands - > =A0Accepts the cert >> =A0Critical/Compliant/Does not understand -> Rejects the cert =A0**** >> =A0Critical/Non-Compliant/Understands -> Rejects the cert >> =A0Critical/Non-Compliant/Does not understand -> Rejects the cert >> =A0Non-Critical/Compliant/Understands -> Accepts the cert >> =A0Non-Critical/Compliant/Does not understand -> Accepts the cert >> =A0Non-Critical/Non-Compliant/Understands -> Rejects the cert >> =A0Non-Critical/Non-Compliant/Does not understand -> Accepts the cert. = =A0**** > > This last behaviour, which you identify as the "wrong" thing happening, i= s > realistically a policy decision, and one that should be dealt with by the > respective CA and their policies. > > So rather than the "wrong thing", it's the exact same thing as the "No NC > Present" case. Same result - so for CAs, this is the RIGHT thing, because > it has no discernable behaviour change for clients in the > "Non-Critical/Non-Compliant/Does not understand" case from the effective > "No NC Present", while it IMPROVES the situation for the > "Non-Critical/Non-Compliant/Understands" case. > > The current state of the industry is that no public CA issuing public > certificates for use on the Internet wants to use name constraints, > because they present a compatibility issue. CAs therefore choose to issue > unconstrained CAs, which are accepted by clients, and rather than > technical measures, attempt to use procedural/contractual/legal measures > to constrain the CA. > > As Phil has pointed out, this is undesirable for browser vendors and othe= r > RPs, because there is no programatic awareness of whatever the procedural > or contractual constraints may be between the two CAs, therefore it's not > possible to detect violations of policy. > > For a CA that wishes to programatically enforce NC as policy: > =A0- Mark the extension as critical, and it will be processed as such. > For a CA that wishes to programatically /advertise/ NC: > =A0- Mark the extension as non-critical. Compliant implementations will > process or reject. Non-compliant implementations will treat it as if > there was no NC present. > > >> >> =A0(There is one other combination - no NC present -> Accepts the cert) >> >> =A0The two items marked with **** are combinations where possibly the "w= rong" >> =A0thing happened. =A0The first one is just due to the implementation at= the RP >> =A0not being complete enough, but complies with the policy imposed on th= e NC >> =A0CA by the root. =A0The second is due to a violation of policy - the N= C CA >> =A0was able to issue a certificate with a name that violated the name >> =A0constraints imposed upon it by the root CA and have it accepted by an= RP >> =A0that didn't understand the NC extension. >> >> =A0You also end up with a situation where a "GOOD" RP (one that understa= nds >> =A0the NC), ends up rejecting the certificate - which is probably not wh= at >> =A0you wanted. >> >> =A0Phil - you're proposing a change which is the equivalent of posting a >> =A0guard at the door to a building and requiring the guard to reject bad >> =A0badges if they are offered, but allowing anyone who doesn't present a >> =A0badge to enter the building. >> >> =A0If the Root CA doesn't care about enforceable name constraints, it >> =A0probably shouldn't include them in the NC CA certificate. =A0If it wa= nts >> =A0them to be enforced, then the NC extension needs to be marked critica= l. >> >> =A0And on a last topic. =A0I'm finding the arm twisting a bit distastefu= l. =A0If >> =A0the CAB forum wants to pick its marbles and leave, just do it and sto= p >> =A0trying to coerce the process. >> >> =A0Mike >> >> >> >> >> =A0At 12:47 PM 5/25/2012, Phillip Hallam-Baker wrote: >> >The issue was discussed here earlier without a conclusion. I just wante= d >> > to point out that the issue is currently the subject of a ballot in >> > CABForum: >> > >> >http://cabfo= rum.org/pipermail/public/2012-May/000027.html >> > >> >Delete the following text from the "Subordinate CA Certificate" section >> > of both the Baseline Requirements Appendix B and EV Guidelines Appendi= x >> > B: >> >"All other fields and extensions MUST be set in accordance to RFC 5280.= " >> >AND replace it with the following: >> >"F. nameConstraints (optional) >> >. If present, this extension SHOULD be marked critical*. >> >All other fields and extensions MUST be set in accordance to RFC 5280. >> >* Non-critical Name Constraints are an exception to RFC 5280 that MAY b= e >> > used until the Name Constraints extension is supported by Application >> > Software Suppliers whose software is used by a substantial portion of >> > Relying Parties worldwide." >> > >> > >> >Anyone who wants to follow the ballot discussion can do so at: >> >http://cabforum.org/mailma= n/listinfo/public >> > >> >The reason this change is being considered is as follows: >> > >> >1) Deployment of name constraints without a criticality flag provides a= n >> > immediate an advantageous reduction in risk without impact on any >> > deployed systems. >> > >> >2) Deployment of name constraints with a criticality flag would entail = an >> > unacceptable incompatibility with widely deployed systems. >> > >> >3) None of the following reasons advanced for requiring name constraint= s >> > to be marked critical has been found to be persuasive: >> > >> >3a) 'Critical means important' - no it does not, clients are required t= o >> > process extensions that they understand regardless of whether they are >> > marked critical or not. >> > >> >3b) 'This is not a requirement for the DoD' - this is not about the DoD >> > PKI. >> > >> >3c) 'People should deploy RFC 5280 compliant systems rather than change >> > the spec' - This is not a normative argument. People should live in >> > brotherly peace and harmony too but the fact that they don't is the >> > reason we need PKI in the first place. >> > >> >This change has been considered by a group of experts whose credentials >> > and experience in the PKI space is at least equal to that of this WG. = So >> > please, no appeals to authority. >> > >> > >> >Should this ballot pass, I will submit an ID to propose making the same >> > change to RFC5280 as an erratum. In my personal view, it is clearly >> > desirable for the IETF specifications to track the deployed >> > specification. >> > >> >-- >> >Website: http://hallambaker.com/ >> > >> >_______________________________________________ >> >pkix mailing list >> >pkix@ietf.org >> >https://www.ietf.org/mailman/listinfo/pkix >> >> =A0_______________________________________________ >> =A0pkix mailing list >> =A0pkix@ietf.org >> =A0https://www.ietf.org/mailman/listinfo/pkix >> > --=20 Website: http://hallambaker.com/ From wcwang@cht.com.tw Fri May 25 23:57:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EFD21F8634 for ; Fri, 25 May 2012 23:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.937 X-Spam-Level: * X-Spam-Status: No, score=1.937 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmhL1BZrdE-p for ; Fri, 25 May 2012 23:57:20 -0700 (PDT) Received: from scan4.cht.com.tw (scan4.cht.com.tw [202.39.168.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8123E21F857D for ; Fri, 25 May 2012 23:57:19 -0700 (PDT) X-AuditID: 0aa00272-9b4c1ba000000c3b-a5-4fc07eccd2bf From: =?iso-2022-jp?B?GyRCMiZKOEA1GyhC?= To: Phillip Hallam-Baker , "ryan-ietftls@sleevi.com" Content-Class: urn:content-classes:message Date: Sat, 26 May 2012 14:57:19 +0800 Thread-Topic: [pkix] NameConstraints criticality flag Thread-Index: Ac067b8R5mUEfi/ZSh+3k1JtX2dcQwAG12ysAADreLA= Message-ID: References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com>, In-Reply-To: Accept-Language: en-US, zh-TW Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, zh-TW x-mimectl: Produced By Microsoft Exchange V8.2.176.0 Content-Type: multipart/alternative; boundary="_000_A5E8B37A25C44E55BC1CC291028BD6F7mimectl_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "pkix@ietf.org" Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 06:57:22 -0000 --_000_A5E8B37A25C44E55BC1CC291028BD6F7mimectl_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Phillip, If the "we" in your last post means the CAB Forum, I would like to remind y= ou that the ballot is still in progress and its close date is June 1. Therefore, what you posted here does not necessary reprsent the consensus o= f the CAB Forum. There might be members, like me, who will choose to vote against the motion= . Who knows. I think it will be more appopriate if we wait untill the ballot closed and = then speak here for the CAB Forum. Wen-Cheng Wang ________________________________ From: pkix-bounces@ietf.org [pkix-bounces@ietf.org] On Behalf Of Phillip Ha= llam-Baker [hallam@gmail.com] Sent: Saturday, May 26, 2012 11:13 AM To: ryan-ietftls@sleevi.com Cc: pkix@ietf.org Subject: Re: [pkix] NameConstraints criticality flag That is precisely right, the desired behavior is: Compliant/Understands -> Accepts the cert Compliant/Does not understand -> Accepts the cert Non-Compliant/Understands -> Rejects the cert Non-Compliant/Does not understand -> Accepts the cert. We expressly DO NOT WANT browsers to reject a certificate unless they understand the NC constraint. That is the behavior we desire. That is precisely the behavior that not setting the criticality bit provide= s. On Fri, May 25, 2012 at 10:03 PM, Ryan Sleevi wro= te: >> I hesitate to respond to this, but my review of the bidding is not that >> there wasn't a conclusion, but that there was no consensus for change. >> >> I think I support the status quo. >> >> >> Assuming a "Root CA -> CA with Name Constraint -> End Entity certificat= e >> chain" there are three degrees of freedom: 1) Whether the NC is marked >> critical, 2) whether the EE certificate has a name compliant with the N= C, >> and 3) whether the RP understands the NC extension. >> >> The combinations are thus: >> >> Critical/Compliant/Understands - > Accepts the cert >> Critical/Compliant/Does not understand -> Rejects the cert **** >> Critical/Non-Compliant/Understands -> Rejects the cert >> Critical/Non-Compliant/Does not understand -> Rejects the cert >> Non-Critical/Compliant/Understands -> Accepts the cert >> Non-Critical/Compliant/Does not understand -> Accepts the cert >> Non-Critical/Non-Compliant/Understands -> Rejects the cert >> Non-Critical/Non-Compliant/Does not understand -> Accepts the cert. **= ** > > This last behaviour, which you identify as the "wrong" thing happening, i= s > realistically a policy decision, and one that should be dealt with by the > respective CA and their policies. > > So rather than the "wrong thing", it's the exact same thing as the "No NC > Present" case. Same result - so for CAs, this is the RIGHT thing, because > it has no discernable behaviour change for clients in the > "Non-Critical/Non-Compliant/Does not understand" case from the effective > "No NC Present", while it IMPROVES the situation for the > "Non-Critical/Non-Compliant/Understands" case. > > The current state of the industry is that no public CA issuing public > certificates for use on the Internet wants to use name constraints, > because they present a compatibility issue. CAs therefore choose to issue > unconstrained CAs, which are accepted by clients, and rather than > technical measures, attempt to use procedural/contractual/legal measures > to constrain the CA. > > As Phil has pointed out, this is undesirable for browser vendors and othe= r > RPs, because there is no programatic awareness of whatever the procedural > or contractual constraints may be between the two CAs, therefore it's not > possible to detect violations of policy. > > For a CA that wishes to programatically enforce NC as policy: > - Mark the extension as critical, and it will be processed as such. > For a CA that wishes to programatically /advertise/ NC: > - Mark the extension as non-critical. Compliant implementations will > process or reject. Non-compliant implementations will treat it as if > there was no NC present. > > >> >> (There is one other combination - no NC present -> Accepts the cert) >> >> The two items marked with **** are combinations where possibly the "wro= ng" >> thing happened. The first one is just due to the implementation at the= RP >> not being complete enough, but complies with the policy imposed on the = NC >> CA by the root. The second is due to a violation of policy - the NC CA >> was able to issue a certificate with a name that violated the name >> constraints imposed upon it by the root CA and have it accepted by an R= P >> that didn't understand the NC extension. >> >> You also end up with a situation where a "GOOD" RP (one that understand= s >> the NC), ends up rejecting the certificate - which is probably not what >> you wanted. >> >> Phil - you're proposing a change which is the equivalent of posting a >> guard at the door to a building and requiring the guard to reject bad >> badges if they are offered, but allowing anyone who doesn't present a >> badge to enter the building. >> >> If the Root CA doesn't care about enforceable name constraints, it >> probably shouldn't include them in the NC CA certificate. If it wants >> them to be enforced, then the NC extension needs to be marked critical. >> >> And on a last topic. I'm finding the arm twisting a bit distasteful. = If >> the CAB forum wants to pick its marbles and leave, just do it and stop >> trying to coerce the process. >> >> Mike >> >> >> >> >> At 12:47 PM 5/25/2012, Phillip Hallam-Baker wrote: >> >The issue was discussed here earlier without a conclusion. I just wante= d >> > to point out that the issue is currently the subject of a ballot in >> > CABForum: >> > >> >http://cabfo= rum.org/pipermail/public/2012-May/000027.html >> > >> >Delete the following text from the "Subordinate CA Certificate" section >> > of both the Baseline Requirements Appendix B and EV Guidelines Appendi= x >> > B: >> >"All other fields and extensions MUST be set in accordance to RFC 5280.= " >> >AND replace it with the following: >> >"F. nameConstraints (optional) >> >. If present, this extension SHOULD be marked critical*. >> >All other fields and extensions MUST be set in accordance to RFC 5280. >> >* Non-critical Name Constraints are an exception to RFC 5280 that MAY b= e >> > used until the Name Constraints extension is supported by Application >> > Software Suppliers whose software is used by a substantial portion of >> > Relying Parties worldwide." >> > >> > >> >Anyone who wants to follow the ballot discussion can do so at: >> >http://cabforum.org/mailma= n/listinfo/public >> > >> >The reason this change is being considered is as follows: >> > >> >1) Deployment of name constraints without a criticality flag provides a= n >> > immediate an advantageous reduction in risk without impact on any >> > deployed systems. >> > >> >2) Deployment of name constraints with a criticality flag would entail = an >> > unacceptable incompatibility with widely deployed systems. >> > >> >3) None of the following reasons advanced for requiring name constraint= s >> > to be marked critical has been found to be persuasive: >> > >> >3a) 'Critical means important' - no it does not, clients are required t= o >> > process extensions that they understand regardless of whether they are >> > marked critical or not. >> > >> >3b) 'This is not a requirement for the DoD' - this is not about the DoD >> > PKI. >> > >> >3c) 'People should deploy RFC 5280 compliant systems rather than change >> > the spec' - This is not a normative argument. People should live in >> > brotherly peace and harmony too but the fact that they don't is the >> > reason we need PKI in the first place. >> > >> >This change has been considered by a group of experts whose credentials >> > and experience in the PKI space is at least equal to that of this WG. = So >> > please, no appeals to authority. >> > >> > >> >Should this ballot pass, I will submit an ID to propose making the same >> > change to RFC5280 as an erratum. In my personal view, it is clearly >> > desirable for the IETF specifications to track the deployed >> > specification. >> > >> >-- >> >Website: http://hallambaker.com/ >> > >> >_______________________________________________ >> >pkix mailing list >> >pkix@ietf.org >> >https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > -- Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --_000_A5E8B37A25C44E55BC1CC291028BD6F7mimectl_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Phil= lip,
 
If the "we" in your last post=  means the CAB Forum, I would like to remind you that the ballot = is still in progress and its close date is June 1.
Therefore, what you posted he= re does not necessary reprsent the consensus of the CAB Forum.
There might be members, = like me, who will choose to vote against the motion. Who knows.=
I think it will be more = appopriate if we wait untill the ballot closed and then speak here for the = CAB Forum.
 
Wen-Cheng Wang
 

From: pkix-bounces@ietf.org [pki= x-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker [hallam@gmail.com]Sent: Saturday, May 26, 2012 11:13 AM
To: ryan-ietftls@sl= eevi.com
Cc: pkix@ietf.org
Subject: Re: [pkix] NameCons= traints criticality flag

That is precisely right, the desired behavior is:
Compliant/Understands -> Accepts the cert
Compliant/Does not und= erstand -> Accepts the cert
Non-Compliant/Understands -> Rejects t= he cert
Non-Compliant/Does not understand -> Accepts the cert.

We expressly DO NOT WANT browsers to reject a certificate unless they<= BR>understand the NC constraint. That is the behavior we desire.

Tha= t is precisely the behavior that not setting the criticality bit provides.<= BR>




On Fri, May 25, 2012 at 10:03 PM, Ryan Sleevi <ry= an-ietftls@sleevi.com> wrote:
>>  I hesitate to respond to= this, but my review of the bidding is not that
>>  there was= n't a conclusion, but that there was no consensus for change.
>>>>  I think I support the status quo.
>>
>><= BR>>>  Assuming a "Root CA -> CA with Name Constraint -> E= nd Entity certificate
>>  chain" there are three degrees of f= reedom:  1) Whether the NC is marked
>>  critical, 2) wh= ether the EE certificate has a name compliant with the NC,
>> &nbs= p;and 3) whether the RP understands the NC extension.
>>
>&g= t;  The combinations are thus:
>>
>>  Critical/= Compliant/Understands - >  Accepts the cert
>>  Criti= cal/Compliant/Does not understand -> Rejects the cert  ****
>= >  Critical/Non-Compliant/Understands -> Rejects the cert
>= ;>  Critical/Non-Compliant/Does not understand -> Rejects the ce= rt
>>  Non-Critical/Compliant/Understands -> Accepts the c= ert
>>  Non-Critical/Compliant/Does not understand -> Acce= pts the cert
>>  Non-Critical/Non-Compliant/Understands ->= Rejects the cert
>>  Non-Critical/Non-Compliant/Does not und= erstand -> Accepts the cert.  ****
>
> This last behavi= our, which you identify as the "wrong" thing happening, is
> realisti= cally a policy decision, and one that should be dealt with by the
> r= espective CA and their policies.
>
> So rather than the "wrong = thing", it's the exact same thing as the "No NC
> Present" case. Same= result - so for CAs, this is the RIGHT thing, because
> it has no di= scernable behaviour change for clients in the
> "Non-Critical/Non-Com= pliant/Does not understand" case from the effective
> "No NC Present"= , while it IMPROVES the situation for the
> "Non-Critical/Non-Complia= nt/Understands" case.
>
> The current state of the industry is = that no public CA issuing public
> certificates for use on the Intern= et wants to use name constraints,
> because they present a compatibil= ity issue. CAs therefore choose to issue
> unconstrained CAs, which a= re accepted by clients, and rather than
> technical measures, attempt= to use procedural/contractual/legal measures
> to constrain the CA.<= BR>>
> As Phil has pointed out, this is undesirable for browser ve= ndors and other
> RPs, because there is no programatic awareness of w= hatever the procedural
> or contractual constraints may be between th= e two CAs, therefore it's not
> possible to detect violations of poli= cy.
>
> For a CA that wishes to programatically enforce NC as p= olicy:
>  - Mark the extension as critical, and it will be proce= ssed as such.
> For a CA that wishes to programatically /advertise/ N= C:
>  - Mark the extension as non-critical. Compliant implementa= tions will
> process or reject. Non-compliant implementations will tr= eat it as if
> there was no NC present.
>
>
>>>>  (There is one other combination - no NC present -> Acce= pts the cert)
>>
>>  The two items marked with **** = are combinations where possibly the "wrong"
>>  thing happene= d.  The first one is just due to the implementation at the RP
>&= gt;  not being complete enough, but complies with the policy imposed o= n the NC
>>  CA by the root.  The second is due to a vio= lation of policy - the NC CA
>>  was able to issue a certific= ate with a name that violated the name
>>  constraints impose= d upon it by the root CA and have it accepted by an RP
>>  th= at didn't understand the NC extension.
>>
>>  You al= so end up with a situation where a "GOOD" RP (one that understands
>&= gt;  the NC), ends up rejecting the certificate - which is probably no= t what
>>  you wanted.
>>
>>  Phil - y= ou're proposing a change which is the equivalent of posting a
>> &= nbsp;guard at the door to a building and requiring the guard to reject bad<= BR>>>  badges if they are offered, but allowing anyone who doesn= 't present a
>>  badge to enter the building.
>>
= >>  If the Root CA doesn't care about enforceable name constrain= ts, it
>>  probably shouldn't include them in the NC CA certi= ficate.  If it wants
>>  them to be enforced, then the N= C extension needs to be marked critical.
>>
>>  And = on a last topic.  I'm finding the arm twisting a bit distasteful. &nbs= p;If
>>  the CAB forum wants to pick its marbles and leave, j= ust do it and stop
>>  trying to coerce the process.
>&= gt;
>>  Mike
>>
>>
>>
>><= BR>>>  At 12:47 PM 5/25/2012, Phillip Hallam-Baker wrote:
>= ;> >The issue was discussed here earlier without a conclusion. I just= wanted
>> > to point out that the issue is currently the subje= ct of a ballot in
>> > CABForum:
>> >
>> &= gt;<http://cabforum.org/pipermail/public/2012-May/000027.html>http://= cabforum.org/pipermail/public/2012-May/000027.html
>> >
>= > >Delete the following text from the "Subordinate CA Certificate" se= ction
>> > of both the Baseline Requirements Appendix B and EV = Guidelines Appendix
>> > B:
>> >"All other fields a= nd extensions MUST be set in accordance to RFC 5280."
>> >AND r= eplace it with the following:
>> >"F. nameConstraints (optional= )
>> >. If present, this extension SHOULD be marked critical*.<= BR>>> >All other fields and extensions MUST be set in accordance t= o RFC 5280.
>> >* Non-critical Name Constraints are an exceptio= n to RFC 5280 that MAY be
>> > used until the Name Constraints = extension is supported by Application
>> > Software Suppliers w= hose software is used by a substantial portion of
>> > Relying = Parties worldwide."
>> >
>> >
>> >Anyon= e who wants to follow the ballot discussion can do so at:
>> >&= lt;http://cabforum.org/mailman/listinfo/public>http://cabforum.org/mailm= an/listinfo/public
>> >
>> >The reason this change = is being considered is as follows:
>> >
>> >1) Depl= oyment of name constraints without a criticality flag provides an
>&g= t; > immediate an advantageous reduction in risk without impact on any>> > deployed systems.
>> >
>> >2) Deplo= yment of name constraints with a criticality flag would entail an
>&g= t; > unacceptable incompatibility with widely deployed systems.
>&= gt; >
>> >3) None of the following reasons advanced for requ= iring name constraints
>> > to be marked critical has been foun= d to be persuasive:
>> >
>> >3a) 'Critical means im= portant' - no it does not, clients are required to
>> > process= extensions that they understand regardless of whether they are
>>= > marked critical or not.
>> >
>> >3b) 'This is= not a requirement for the DoD' - this is not about the DoD
>> >= ; PKI.
>> >
>> >3c) 'People should deploy RFC 5280 = compliant systems rather than change
>> > the spec' - This is n= ot a normative argument. People should live in
>> > brotherly p= eace and harmony too but the fact that they don't is the
>> > r= eason we need PKI in the first place.
>> >
>> >This= change has been considered by a group of experts whose credentials
>= > > and experience in the PKI space is at least equal to that of this= WG. So
>> > please, no appeals to authority.
>> ><= BR>>> >
>> >Should this ballot pass, I will submit an = ID to propose making the same
>> > change to RFC5280 as an erra= tum. In my personal view, it is clearly
>> > desirable for the = IETF specifications to track the deployed
>> > specification.>> >
>> >--
>> >Website: <http://h= allambaker.com/>http://hallambaker.com/
>> >
>>= >_______________________________________________
>> >pkix m= ailing list
>> >pkix@ietf.org
>> >https://www.ietf.= org/mailman/listinfo/pkix
>>
>>  ___________________= ____________________________
>>  pkix mailing list
>>= ;  pkix@ietf.org
>>  https://www.ietf.org/mailman/listinfo/p= kix
>>
>



--
Website: http://hallambaker.com/
________= _______________________________________
pkix mailing list
pkix@ietf.o= rg
https://www.ietf.org/mailman/listinfo/pkix
--_000_A5E8B37A25C44E55BC1CC291028BD6F7mimectl_-- From era@x500.eu Sat May 26 00:51:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0FE21F8616 for ; Sat, 26 May 2012 00:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1c4Ce6NqRKz for ; Sat, 26 May 2012 00:51:56 -0700 (PDT) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8E75821F8604 for ; Sat, 26 May 2012 00:51:54 -0700 (PDT) Received: from Morten ([212.27.17.234]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id KMZ21552; Sat, 26 May 2012 09:51:52 +0200 From: "Erik Andersen" To: References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> In-Reply-To: Date: Sat, 26 May 2012 09:51:44 +0200 Message-ID: <004901cd3b14$6b0951d0$411bf570$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01CD3B25.2E9221D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac06k+T8HqjX3qY8RPiABF+smmtEdwAf/oHw Content-Language: da Cc: pkix@ietf.org, pkix-bounces@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 07:51:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004A_01CD3B25.2E9221D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Denis, =20 As X.509 is the master specification the keyUsage extension, any = addition to that extension should be done in X.509. Others could then copy it. =20 Erik =20 Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af denis.pinkas@bull.net Sendt: 25. maj 2012 18:32 Til: Russ Housley Cc: pkix@ietf.org; pkix-bounces@ietf.org Emne: Re: [pkix] Integrated OCSP Responders / Key Usage bits =20 Russ,=20 I raised the question in my presentation on OCSP during the last PKIX session in Paris,=20 since there is currently no answer in the PKIX documents.=20 I don't believe that your response is correct.=20 The id-kp-OCSPSigning object identifier is only for a designated OCSP responder.=20 This is not the case we are considering in this discussion.=20 RFC 2560 states: "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning=20 in an extendedKeyUsage certificate extension included in the OCSP = response signer's certificate".=20 Ideally, we should have added an OCSP signing bit in the key usage bits, = but unfortunately=20 nobody raised the point when we built RFC 2560.=20 Rob mentioned the (relatively recently published) CABForum Baseline Requirements=20 document which says: "Bit positions for keyCertSign and cRLSign MUST be = set. If the Root/Subordinate CA Private Key is used for signing OCSP = responses, then=20 the digitalSignature bit MUST be set." I don't believe that this response is correct either, since in the = general case an upper CA=20 does not sign OCSP responses for a lower CA.=20 Let me propose a strawman:=20 The keyCertSign bit and the digitalSignature bit MUST be set.=20 The cRLSign bit MAY be set.=20 A few explanations are needed.=20 Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA signs OCSP responses, the digitalSignature bit MUST be set. = If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST = be set,=20 otherwise it MUST NOT be set.=20 Let us now suppose that a CA starts to issue CRLs and that, later on, = the CA wants to issue OCSP responses.=20 With this strawman proposal, the CA must obtain a new certificate from = its upper CA. This makes sense since=20 the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.=20 Note: Any proposal will break some eggs and make an omelet, since, = without guidance, implementers did "something".=20 What is strange is that OCSP currently works !=20 I would guess most implementations only test the keyCertSign = bit.=20 Denis=20 De : Russ Housley =20 A : Rob Stradling =20 Cc : pkix@ietf.org=20 Date : 25/05/2012 17:50=20 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20 Envoy=E9 par : pkix-bounces@ietf.org=20 _____ =20 Rob: > Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses? Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses? If so, I would expect the CA certificate that contains the corresponding public key to include the = key usage and the extended key usage extensions. The key usage extension = should have at least the keyCertSign and the cRLSign bits set. The extended = key usage extension should include at least the id-kp-OCSPSigning object identifier. Russ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_004A_01CD3B25.2E9221D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Denis,

 

As X.509 is the master specification the keyUsage extension, any = addition to that extension should be done in X.509. Others could then = copy it.

 

Erik

 

Fra:<= /b> = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = denis.pinkas@bull.net
Sendt: 25. maj 2012 = 18:32
Til: Russ Housley
Cc: pkix@ietf.org; = pkix-bounces@ietf.org
Emne: Re: [pkix] Integrated OCSP = Responders / Key Usage bits

 

Russ, =

I raised the = question in my presentation on OCSP during the last PKIX session in = Paris,
since there is currently no answer in the PKIX = documents.


I don't = believe that your response is correct.

The = id-kp-OCSPSigning object identifier is only for a designated OCSP = responder.
This is not the case we are considering in this = discussion.


RFC 2560 = states: "OCSP signing delegation SHALL be designated by the = inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate = extension included in the OCSP response signer's = certificate".


Ideally, we = should have added an OCSP signing bit in the key usage bits, but = unfortunately
nobody raised the point when we built RFC 2560.
=

Rob = mentioned the (relatively recently published) CABForum Baseline = Requirements
document which says: "Bit positions for = keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate = CA Private Key is used for signing OCSP responses, then
the = digitalSignature bit MUST be set."


I don't = believe that this response is correct either, since in the general case = an upper CA
does not sign OCSP responses for a lower CA. =


Let me = propose a strawman:

The = keyCertSign bit and the digitalSignature bit MUST be set. =
The cRLSign = bit MAY be set.

A few = explanations are needed.
Since the CA = issues certificates, the keyCertSign bit MUST be set.
Since the CA = signs OCSP responses, the digitalSignature bit MUST be set. =
If the CA = issues both CRLs and OCSP Responses, then the cRLSign bit MUST be set, =
otherwise it MUST NOT be set.


Let us now = suppose that a CA starts to issue CRLs and that, later on, the CA wants = to issue OCSP responses.
With this strawman proposal, the CA must = obtain a new certificate from its upper CA. This makes sense since =
the Certification Policy has changed and the upper CA has the right = to verify the practices of its child CA.


Note: Any = proposal will break some eggs and make an omelet, since, without = guidance, implementers did "something".
  =       What is strange is that OCSP currently works ! =
  =       I would guess most implementations only test the = keyCertSign bit.

Denis =



= De :        Russ Housley = <housley@vigilsec.com> =
= A :        Rob Stradling = <rob.stradling@comodo.com>=
= Cc :        pkix@ietf.org
= Date :        25/05/2012 = 17:50
= Objet :        Re: [pkix] = Integrated OCSP Responders / Key Usage bits
= Envoy=E9 par :        pkix-bounces@ietf.org =





Rob:

> = Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses?

Do you = mean that the same private key is used by the CA to sign certificates, = CRLs, and OCSP Responses?  If so, I would expect the CA certificate = that contains the corresponding public key to include the key usage and = the extended key usage extensions.  The key usage extension should = have at least the keyCertSign and the cRLSign bits set.  The = extended key usage extension should include at least the = id-kp-OCSPSigning object = identifier.

Russ



________________= _______________________________
pkix mailing = list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

------=_NextPart_000_004A_01CD3B25.2E9221D0-- From mrex@sap.com Sat May 26 05:10:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F74221F852C for ; Sat, 26 May 2012 05:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqWAsdbcF9bi for ; Sat, 26 May 2012 05:10:40 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1620E21F852B for ; Sat, 26 May 2012 05:10:39 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4QCAbV9008939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 26 May 2012 14:10:37 +0200 (MEST) From: Martin Rex Message-Id: <201205261210.q4QCAanx009823@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Sat, 26 May 2012 14:10:36 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at May 25, 12 11:13:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, ryan-ietftls@sleevi.com Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 12:10:45 -0000 Speaking about support of NameConstraints (I briefly looked at the code in OpenSSL 1.0), the existing PKIX document looks somewhat unclear to me. rfc5280 Section 6.1 Basic Path Validation says The primary goal of path validation is to verify the binding between a subject distinguished name or a subject alternative name and subject public key, as represented in the target certificate, based on the public key of the trust anchor. In most cases, the target certificate will be an end entity certificate, but the target certificate may be a CA certificate as long as the subject public key is to be used for a purpose other than verifying the signature on a public key certificate. Verifying the binding between the name and subject public key requires obtaining a sequence of certificates that *> support that binding. The procedure performed to obtain this *> sequence of certificates is outside the scope of this specification. and declares the "procedure to obtain this sequence of certficates outside of the scope of this specification". But looking at ITU-T X.509 (11/2008), Processing of name constraints Appendix G.3.3 G.3.3 Examples where multiple Cross Certificates with Name Constraint Extension are needed In some cases, it may be required that more than one certificate be issued from a CA to another CA in order to achieve the desired results. This might be the case if some of the name constraints requirements conflict, or if the disjunctive evaluation of different name forms is required. There seems to be a contradiction in that processing of name constraints has a prerequisite of building several alternative certification paths, and this very issue being out of scope for PKIX. Looking at the details of name constraints processing, the included subtree looks like white-listing, whereas the excluded subtree looks like black-listing (the latter being an unconditionally bad idea when it comes to security). While i believe that strict processing of the included tree (memcmp on the head of the ASN.1 blob) is a good idea, I'm wondering what kind of comparison is expected for the excluded subtree? Should there be a memcmp on the head of the ASN.1 blob as well, or is a component-wise comparison of the RDName attribute values expected that normalizes the attribute values to the same encoding for comparison and performs case-insensitive comparison of the attribute values where the directory attributes call for it. And what about the weird side effect of ASN.1 DER encoding of multiple Attribute value pairs within an RDName set? If it is supposed to be a security feature, the specification should have clearly predictable behaviour. To me, it doesn't look that there is predictable behaviour specified for processing of name constraints for distinguished names. -Martin From housley@vigilsec.com Sat May 26 06:59:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED6521F859A for ; Sat, 26 May 2012 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0i+plBbEqDV for ; Sat, 26 May 2012 06:59:25 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1B321F8598 for ; Sat, 26 May 2012 06:59:25 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 04AD9F2402F; Sat, 26 May 2012 09:59:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id G9Sm0kYJoyr5; Sat, 26 May 2012 09:59:21 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B1DBDF24025; Sat, 26 May 2012 09:59:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-87--1043690192 From: Russ Housley In-Reply-To: <004901cd3b14$6b0951d0$411bf570$@eu> Date: Sat, 26 May 2012 09:59:22 -0400 Message-Id: <352AF057-71DE-4895-8630-C81188EE2228@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <004901cd3b14$6b0951d0$411bf570$@eu> To: "Erik Andersen" X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 13:59:26 -0000 --Apple-Mail-87--1043690192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Erik: I think Denis meant that we should have asked for such a bit back in = 1998 and 1999 when OCSP was first being defined. Russ On May 26, 2012, at 3:51 AM, Erik Andersen wrote: > Hi Denis, > =20 > As X.509 is the master specification the keyUsage extension, any = addition to that extension should be done in X.509. Others could then = copy it. > =20 > Erik > =20 > Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne = af denis.pinkas@bull.net > Sendt: 25. maj 2012 18:32 > Til: Russ Housley > Cc: pkix@ietf.org; pkix-bounces@ietf.org > Emne: Re: [pkix] Integrated OCSP Responders / Key Usage bits > =20 > Russ,=20 >=20 > I raised the question in my presentation on OCSP during the last PKIX = session in Paris,=20 > since there is currently no answer in the PKIX documents.=20 >=20 > I don't believe that your response is correct.=20 >=20 > The id-kp-OCSPSigning object identifier is only for a designated OCSP = responder.=20 > This is not the case we are considering in this discussion.=20 >=20 > RFC 2560 states: "OCSP signing delegation SHALL be designated by the = inclusion of id-kp-OCSPSigning=20 > in an extendedKeyUsage certificate extension included in the OCSP = response signer's certificate".=20 >=20 > Ideally, we should have added an OCSP signing bit in the key usage = bits, but unfortunately=20 > nobody raised the point when we built RFC 2560.=20 >=20 > Rob mentioned the (relatively recently published) CABForum Baseline = Requirements=20 > document which says: "Bit positions for keyCertSign and cRLSign MUST = be set. =20 > If the Root/Subordinate CA Private Key is used for signing OCSP = responses, then=20 > the digitalSignature bit MUST be set." >=20 > I don't believe that this response is correct either, since in the = general case an upper CA=20 > does not sign OCSP responses for a lower CA.=20 >=20 > Let me propose a strawman:=20 >=20 > The keyCertSign bit and the digitalSignature bit MUST be set.=20 > The cRLSign bit MAY be set.=20 >=20 > A few explanations are needed.=20 > Since the CA issues certificates, the keyCertSign bit MUST be set.=20 > Since the CA signs OCSP responses, the digitalSignature bit MUST be = set.=20 > If the CA issues both CRLs and OCSP Responses, then the cRLSign bit = MUST be set,=20 > otherwise it MUST NOT be set.=20 >=20 > Let us now suppose that a CA starts to issue CRLs and that, later on, = the CA wants to issue OCSP responses.=20 > With this strawman proposal, the CA must obtain a new certificate from = its upper CA. This makes sense since=20 > the Certification Policy has changed and the upper CA has the right to = verify the practices of its child CA.=20 >=20 > Note: Any proposal will break some eggs and make an omelet, since, = without guidance, implementers did "something".=20 > What is strange is that OCSP currently works !=20 > I would guess most implementations only test the keyCertSign = bit.=20 >=20 > Denis=20 >=20 >=20 >=20 > De : Russ Housley =20 > A : Rob Stradling =20 > Cc : pkix@ietf.org=20 > Date : 25/05/2012 17:50=20 > Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20= > Envoy=E9 par : pkix-bounces@ietf.org >=20 >=20 >=20 > Rob: >=20 > > Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses? >=20 > Do you mean that the same private key is used by the CA to sign = certificates, CRLs, and OCSP Responses? If so, I would expect the CA = certificate that contains the corresponding public key to include the = key usage and the extended key usage extensions. The key usage = extension should have at least the keyCertSign and the cRLSign bits set. = The extended key usage extension should include at least the = id-kp-OCSPSigning object identifier. >=20 > Russ >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-87--1043690192 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 --e89a8ff1c79640c8ea04c0f354d9-- From housley@vigilsec.com Sat May 26 11:34:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18BB21F859A for ; Sat, 26 May 2012 11:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.679 X-Spam-Level: X-Spam-Status: No, score=-102.679 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHReJpXpAleX for ; Sat, 26 May 2012 11:34:16 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFF721F8598 for ; Sat, 26 May 2012 11:34:16 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 07DA99A471B for ; Sat, 26 May 2012 14:34:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id XQM+MIjaSWUB for ; Sat, 26 May 2012 14:34:12 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 489FD9A470F for ; Sat, 26 May 2012 14:34:20 -0400 (EDT) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-99--1027198419 Date: Sat, 26 May 2012 14:34:14 -0400 In-Reply-To: <177611008030645534@unknownmsgid> To: IETF PKIX References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> Message-Id: <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 18:34:16 -0000 --Apple-Mail-99--1027198419 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Phillip: > I see no reason to defer to people who are not interested in my = requirements and give me no vote Indeed. Why should the open IETF community defer to a closed community? Russ --Apple-Mail-99--1027198419 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I see no = reason to defer to people who are not interested in my requirements and = give me no vote

Hi = Denis,
As = X.509 is the master specification the keyUsage extension, any addition = to that extension should be done in X.509. Others could then copy = it.
Russ, 

I raised the = question in my presentation on OCSP during the last PKIX session in = Paris, 
since there = is currently no answer in the PKIX documents.
 

I don't = believe that your response is correct. 

The = id-kp-OCSPSigning object identifier is only for a designated OCSP = responder. 
This is = not the case we are considering in this discussion.
 

RFC 2560 = states: "OCSP signing delegation SHALL be designated by the inclusion of = id-kp-OCSPSigning 
in= an extendedKeyUsage certificate extension included in the OCSP response = signer's certificate".
 

Ideally, we = should have added an OCSP signing bit in the key usage bits, but = unfortunately 
nobody= raised the point when we built RFC 2560.
 

Rob = mentioned the (relatively recently published) CABForum Baseline = Requirements 
document which says: = "Bit positions for keyCertSign and cRLSign MUST be set.  
If the = Root/Subordinate CA Private Key is used for signing OCSP responses, = then 
the = digitalSignature bit MUST be set."


I don't believe that this = response is correct either, since in the general case an upper CA 
does not sign OCSP = responses for a lower CA. 


Let me = propose a strawman: 

The = keyCertSign bit and the digitalSignature bit MUST be set. 
The cRLSign bit MAY be = set. 

A few = explanations are needed. 
Since the CA = issues certificates, the keyCertSign bit MUST be set. 
Since the CA signs OCSP = responses, the digitalSignature bit MUST be set. 
If the CA = issues both CRLs and OCSP Responses, then the cRLSign bit MUST be = set, 
otherwise it = MUST NOT be set.
 

Let us now = suppose that a CA starts to issue CRLs and that, later on, the CA wants = to issue OCSP responses. 
With this strawman = proposal, the CA must obtain a new certificate from its upper CA. This = makes sense since 
the Certification = Policy has changed and the upper CA has the right to verify the = practices of its child CA.
 

Note: Any = proposal will break some eggs and make an omelet, since, without = guidance, implementers did "something". 
        = What is strange is that OCSP currently works ! 
  =       I would guess most implementations only test the = keyCertSign bit. 

 



De :        Russ = Housley <
 
A : =        Rob Stradling <
 
 
Date : =        25/05/2012 17:50 
Objet = :        Re: [pkix] Integrated OCSP Responders = / Key Usage bits 
Envoy=E9= par :        

Rob:

> Which Key Usage bits (if any) are required to be = present in a CA Certificate that directly signs OCSP = Responses?

Do you = mean that the same private key is used by the CA to sign certificates, = CRLs, and OCSP Responses?  If so, I would expect the CA certificate = that contains the corresponding public key to include the key usage and = the extended key usage extensions.  The key usage extension should = have at least the keyCertSign and the cRLSign bits set.  The = extended key usage extension should include at least the = id-kp-OCSPSigning object identifier.

Russ



pkix mailing list
pkix@ietf.org
, "ryan-ietftls@sleevi.com" Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 16:53:52 -0000 --e89a8ff1c79640c8ea04c0f354d9 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable Absolutely correct. Which I tried to make clear in the first post informing people that the ballot is in progress The industry has not yet decided this issue. But it has decided to decide. The issue is not going to be blocked by a handful of people in this working group The IETF may not have votes but that does not stop others holding one I see no reason to defer to people who are not interested in my requirements and give me no vote Sent from my iPhone On May 26, 2012, at 2:57 AM, "=A4=FD=A4=E5=A5=BF" wrote= : Phillip, If the "we" in your last post means the CAB Forum, I would like to remind you that the ballot is still in progress and its close date is June 1. Therefore, what you posted here does not necessary reprsent the consensus of the CAB Forum. There might be members, like me, who will choose to vote against the motion. Who knows. I think it will be more appopriate if we wait untill the ballot closed and then speak here for the CAB Forum. Wen-Cheng Wang ------------------------------ *From:* pkix-bounces@ietf.org [pkix-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker [hallam@gmail.com] *Sent:* Saturday, May 26, 2012 11:13 AM *To:* ryan-ietftls@sleevi.com *Cc:* pkix@ietf.org *Subject:* Re: [pkix] NameConstraints criticality flag That is precisely right, the desired behavior is: Compliant/Understands -> Accepts the cert Compliant/Does not understand -> Accepts the cert Non-Compliant/Understands -> Rejects the cert Non-Compliant/Does not understand -> Accepts the cert. We expressly DO NOT WANT browsers to reject a certificate unless they understand the NC constraint. That is the behavior we desire. That is precisely the behavior that not setting the criticality bit provides. On Fri, May 25, 2012 at 10:03 PM, Ryan Sleevi wrote: >> I hesitate to respond to this, but my review of the bidding is not that >> there wasn't a conclusion, but that there was no consensus for change. >> >> I think I support the status quo. >> >> >> Assuming a "Root CA -> CA with Name Constraint -> End Entity certificat= e >> chain" there are three degrees of freedom: 1) Whether the NC is marked >> critical, 2) whether the EE certificate has a name compliant with the NC, >> and 3) whether the RP understands the NC extension. >> >> The combinations are thus: >> >> Critical/Compliant/Understands - > Accepts the cert >> Critical/Compliant/Does not understand -> Rejects the cert **** >> Critical/Non-Compliant/Understands -> Rejects the cert >> Critical/Non-Compliant/Does not understand -> Rejects the cert >> Non-Critical/Compliant/Understands -> Accepts the cert >> Non-Critical/Compliant/Does not understand -> Accepts the cert >> Non-Critical/Non-Compliant/Understands -> Rejects the cert >> Non-Critical/Non-Compliant/Does not understand -> Accepts the cert. **** > > This last behaviour, which you identify as the "wrong" thing happening, i= s > realistically a policy decision, and one that should be dealt with by the > respective CA and their policies. > > So rather than the "wrong thing", it's the exact same thing as the "No NC > Present" case. Same result - so for CAs, this is the RIGHT thing, because > it has no discernable behaviour change for clients in the > "Non-Critical/Non-Compliant/Does not understand" case from the effective > "No NC Present", while it IMPROVES the situation for the > "Non-Critical/Non-Compliant/Understands" case. > > The current state of the industry is that no public CA issuing public > certificates for use on the Internet wants to use name constraints, > because they present a compatibility issue. CAs therefore choose to issue > unconstrained CAs, which are accepted by clients, and rather than > technical measures, attempt to use procedural/contractual/legal measures > to constrain the CA. > > As Phil has pointed out, this is undesirable for browser vendors and othe= r > RPs, because there is no programatic awareness of whatever the procedural > or contractual constraints may be between the two CAs, therefore it's not > possible to detect violations of policy. > > For a CA that wishes to programatically enforce NC as policy: > - Mark the extension as critical, and it will be processed as such. > For a CA that wishes to programatically /advertise/ NC: > - Mark the extension as non-critical. Compliant implementations will > process or reject. Non-compliant implementations will treat it as if > there was no NC present. > > >> >> (There is one other combination - no NC present -> Accepts the cert) >> >> The two items marked with **** are combinations where possibly the "wrong" >> thing happened. The first one is just due to the implementation at the RP >> not being complete enough, but complies with the policy imposed on the NC >> CA by the root. The second is due to a violation of policy - the NC CA >> was able to issue a certificate with a name that violated the name >> constraints imposed upon it by the root CA and have it accepted by an R= P >> that didn't understand the NC extension. >> >> You also end up with a situation where a "GOOD" RP (one that understand= s >> the NC), ends up rejecting the certificate - which is probably not what >> you wanted. >> >> Phil - you're proposing a change which is the equivalent of posting a >> guard at the door to a building and requiring the guard to reject bad >> badges if they are offered, but allowing anyone who doesn't present a >> badge to enter the building. >> >> If the Root CA doesn't care about enforceable name constraints, it >> probably shouldn't include them in the NC CA certificate. If it wants >> them to be enforced, then the NC extension needs to be marked critical. >> >> And on a last topic. I'm finding the arm twisting a bit distasteful. If >> the CAB forum wants to pick its marbles and leave, just do it and stop >> trying to coerce the process. >> >> Mike >> >> >> >> >> At 12:47 PM 5/25/2012, Phillip Hallam-Baker wrote: >> >The issue was discussed here earlier without a conclusion. I just wante= d >> > to point out that the issue is currently the subject of a ballot in >> > CABForum: >> > >> > http://cabforum.org/pipermail/public/2012-May/000027.html >> > >> >Delete the following text from the "Subordinate CA Certificate" section >> > of both the Baseline Requirements Appendix B and EV Guidelines Appendi= x >> > B: >> >"All other fields and extensions MUST be set in accordance to RFC 5280.= " >> >AND replace it with the following: >> >"F. nameConstraints (optional) >> >. If present, this extension SHOULD be marked critical*. >> >All other fields and extensions MUST be set in accordance to RFC 5280. >> >* Non-critical Name Constraints are an exception to RFC 5280 that MAY b= e >> > used until the Name Constraints extension is supported by Application >> > Software Suppliers whose software is used by a substantial portion of >> > Relying Parties worldwide." >> > >> > >> >Anyone who wants to follow the ballot discussion can do so at: >> > http://cabforum.org/mailman/listinfo/public >> > >> >The reason this change is being considered is as follows: >> > >> >1) Deployment of name constraints without a criticality flag provides a= n >> > immediate an advantageous reduction in risk without impact on any >> > deployed systems. >> > >> >2) Deployment of name constraints with a criticality flag would entail an >> > unacceptable incompatibility with widely deployed systems. >> > >> >3) None of the following reasons advanced for requiring name constraint= s >> > to be marked critical has been found to be persuasive: >> > >> >3a) 'Critical means important' - no it does not, clients are required t= o >> > process extensions that they understand regardless of whether they are >> > marked critical or not. >> > >> >3b) 'This is not a requirement for the DoD' - this is not about the DoD >> > PKI. >> > >> >3c) 'People should deploy RFC 5280 compliant systems rather than change >> > the spec' - This is not a normative argument. People should live in >> > brotherly peace and harmony too but the fact that they don't is the >> > reason we need PKI in the first place. >> > >> >This change has been considered by a group of experts whose credentials >> > and experience in the PKI space is at least equal to that of this WG. So >> > please, no appeals to authority. >> > >> > >> >Should this ballot pass, I will submit an ID to propose making the same >> > change to RFC5280 as an erratum. In my personal view, it is clearly >> > desirable for the IETF specifications to track the deployed >> > specification. >> > >> >-- >> >Website: http://hallambaker.com/ >> > >> >_______________________________________________ >> >pkix mailing list >> >pkix@ietf.org >> >https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > --=20 Website: http://hallambaker.com/ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --e89a8ff1c79640c8ea04c0f354d9 Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: quoted-printable



The IETF may not have votes but that does not stop othe= rs holding one

I see no reason to defer to people = who are not interested in my requirements and give me no vote



Sent from my iPhone
 
If the "we" in yo= ur last post means the CAB Forum, I would like to remind you that = ;the ballot is still in progress and its close date is June 1.
Therefore, what you posted = here does not necessary reprsent the consensus of the CAB Forum.
There might be members,&nbs= p;like me, who will choose to vote against the motion. Who knows.
I think it will be mor= e appopriate if we wait untill the ballot closed and then speak here for th= e CAB Forum.
 
Wen-Cheng Wang
 

From: pkix-bounces@ietf.org [pkix-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker [hallam@gmail.com]
Sent: Saturday, May 26, 2012 11:13 AM
To: ryan-ietftls@sleevi.com
Cc: pkix@ietf.org
Subject: Re: [pkix] = NameConstraints criticality flag

That is precisely right, the desired behavior is:<= br>
Compliant/Understands -> Accepts the cert
Compliant/Does not u= nderstand -> Accepts the cert
Non-Compliant/Understands -> Rejects= the cert
Non-Compliant/Does not understand -> Accepts the cert.


We exp= ressly DO NOT WANT browsers to reject a certificate unless they
understa= nd the NC constraint. That is the behavior we desire.

That is precis= ely the behavior that not setting the criticality bit provides.





On Fri, May 25, 2012 at 10:03 PM, Ryan Sleevi <ryan-ietftls@sleevi.com> wrote= :
>>  I hesitate to respond to this, but my review of the bid= ding is not that
>>  there wasn't a conclusion, but that there was no consens= us for change.
>>
>>  I think I support the status q= uo.
>>
>>
>>  Assuming a "Root CA ->= ; CA with Name Constraint -> End Entity certificate
>>  chain" there are three degrees of freedom:  1) Whe= ther the NC is marked
>>  critical, 2) whether the EE certifi= cate has a name compliant with the NC,
>>  and 3) whether the= RP understands the NC extension.
>>
>>  The combinations are thus:
>>
>&g= t;  Critical/Compliant/Understands - >  Accepts the cert
&g= t;>  Critical/Compliant/Does not understand -> Rejects the cert =  ****
>>  Critical/Non-Compliant/Understands -> Rejec= ts the cert
>>  Critical/Non-Compliant/Does not understand -> Rejects the= cert
>>  Non-Critical/Compliant/Understands -> Accepts th= e cert
>>  Non-Critical/Compliant/Does not understand -> A= ccepts the cert
>>  Non-Critical/Non-Compliant/Understands -> Rejects the cer= t
>>  Non-Critical/Non-Compliant/Does not understand -> Ac= cepts the cert.  ****
>
> This last behaviour, which you i= dentify as the "wrong" thing happening, is
> realistically a policy decision, and one that should be dealt with by = the
> respective CA and their policies.
>
> So rather tha= n the "wrong thing", it's the exact same thing as the "N= o NC
> Present" case. Same result - so for CAs, this is the RIGHT thing,= because
> it has no discernable behaviour change for clients in the<= br>> "Non-Critical/Non-Compliant/Does not understand" case fro= m the effective
> "No NC Present", while it IMPROVES the situation for the
= > "Non-Critical/Non-Compliant/Understands" case.
>
&g= t; The current state of the industry is that no public CA issuing public > certificates for use on the Internet wants to use name constraints,> because they present a compatibility issue. CAs therefore choose to i= ssue
> unconstrained CAs, which are accepted by clients, and rather t= han
> technical measures, attempt to use procedural/contractual/legal measur= es
> to constrain the CA.
>
> As Phil has pointed out, th= is is undesirable for browser vendors and other
> RPs, because there = is no programatic awareness of whatever the procedural
> or contractual constraints may be between the two CAs, therefore it= 9;s not
> possible to detect violations of policy.
>
> Fo= r a CA that wishes to programatically enforce NC as policy:
>  -= Mark the extension as critical, and it will be processed as such.
> For a CA that wishes to programatically /advertise/ NC:
>  = - Mark the extension as non-critical. Compliant implementations will
>= ; process or reject. Non-compliant implementations will treat it as if
&= gt; there was no NC present.
>
>
>>
>>  (There is one other combination = - no NC present -> Accepts the cert)
>>
>>  The t= wo items marked with **** are combinations where possibly the "wrong&q= uot;
>>  thing happened.  The first one is just due to the imple= mentation at the RP
>>  not being complete enough, but compli= es with the policy imposed on the NC
>>  CA by the root. &nbs= p;The second is due to a violation of policy - the NC CA
>>  was able to issue a certificate with a name that violated th= e name
>>  constraints imposed upon it by the root CA and hav= e it accepted by an RP
>>  that didn't understand the NC = extension.
>>
>>  You also end up with a situation where a "G= OOD" RP (one that understands
>>  the NC), ends up rejec= ting the certificate - which is probably not what
>>  you wan= ted.
>>
>>  Phil - you're proposing a change which is the equivalent= of posting a
>>  guard at the door to a building and requiri= ng the guard to reject bad
>>  badges if they are offered, bu= t allowing anyone who doesn't present a
>>  badge to enter the building.
>>
>>  I= f the Root CA doesn't care about enforceable name constraints, it
&g= t;>  probably shouldn't include them in the NC CA certificate. =  If it wants
>>  them to be enforced, then the NC extension needs to be marke= d critical.
>>
>>  And on a last topic.  I'= m finding the arm twisting a bit distasteful.  If
>>  th= e CAB forum wants to pick its marbles and leave, just do it and stop
>>  trying to coerce the process.
>>
>>  = Mike
>>
>>
>>
>>
>>  At 1= 2:47 PM 5/25/2012, Phillip Hallam-Baker wrote:
>> >The issue wa= s discussed here earlier without a conclusion. I just wanted
>> > to point out that the issue is currently the subject of a bal= lot in
>> > CABForum:
>> >
>> ><http://ca= bforum.org/pipermail/public/2012-May/000027.html>http://cabforum.org/pipe= rmail/public/2012-May/000027.html
>> >
>> >Delete the following text from the "Subo= rdinate CA Certificate" section
>> > of both the Baseline = Requirements Appendix B and EV Guidelines Appendix
>> > B:
>> >"All other fields and extensions MUST be set in accordanc= e to RFC 5280."
>> >AND replace it with the following:
= >> >"F. nameConstraints (optional)
>> >. If prese= nt, this extension SHOULD be marked critical*.
>> >All other fields and extensions MUST be set in accordance to R= FC 5280.
>> >* Non-critical Name Constraints are an exception t= o RFC 5280 that MAY be
>> > used until the Name Constraints ext= ension is supported by Application
>> > Software Suppliers whose software is used by a substantial po= rtion of
>> > Relying Parties worldwide."
>> >=
>> >
>> >Anyone who wants to follow the ballot dis= cussion can do so at:
>> ><ht= tp://cabforum.org/mailman/listinfo/public>http://cabforum.org/mailman/listinfo/public
>> >
>> >The reason this change is being considered is= as follows:
>> >
>> >1) Deployment of name constra= ints without a criticality flag provides an
>> > immediate an a= dvantageous reduction in risk without impact on any
>> > deployed systems.
>> >
>> >2) Deploym= ent of name constraints with a criticality flag would entail an
>>= > unacceptable incompatibility with widely deployed systems.
>>= ; >
>> >3) None of the following reasons advanced for requiring name c= onstraints
>> > to be marked critical has been found to be pers= uasive:
>> >
>> >3a) 'Critical means important&= #39; - no it does not, clients are required to
>> > process extensions that they understand regardless of whether= they are
>> > marked critical or not.
>> >
>= > >3b) 'This is not a requirement for the DoD' - this is not = about the DoD
>> > PKI.
>> >
>> >3c) 'People should = deploy RFC 5280 compliant systems rather than change
>> > the s= pec' - This is not a normative argument. People should live in
>&= gt; > brotherly peace and harmony too but the fact that they don't i= s the
>> > reason we need PKI in the first place.
>> >
&g= t;> >This change has been considered by a group of experts whose cred= entials
>> > and experience in the PKI space is at least equal = to that of this WG. So
>> > please, no appeals to authority.
>> >
>>= >
>> >Should this ballot pass, I will submit an ID to propo= se making the same
>> > change to RFC5280 as an erratum. In my = personal view, it is clearly
>> > desirable for the IETF specifications to track the deployed>> > specification.
>> >
>> >--
>&= gt; >Website: <
http://hallambaker.com/>http://hallambaker.com= /
>> >
>> >_____________________________________________= __
>> >pkix mailing list
>> >pkix@ietf.org
>> >https://www.ietf.org/mailman/listinfo/pkix
>>
>>  _______________________________________________<= br>>>  pkix mailing list
>>  pkix@ietf.org
>>  https://www.ietf.org/mailman/= listinfo/pkix
>>
>



--
Website: http://hallambaker.com/
_________________= ______________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix
Indeed. =  Why should the open IETF community defer to a closed = community?

Russ

= --Apple-Mail-99--1027198419-- From SChokhani@cygnacom.com Sat May 26 14:33:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A312621F850B for ; Sat, 26 May 2012 14:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCVpwPZHMTjf for ; Sat, 26 May 2012 14:33:05 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7371621F8507 for ; Sat, 26 May 2012 14:33:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,663,1330923600"; d="scan'208,217";a="1044172" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 26 May 2012 17:33:02 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 26 May 2012 17:33:02 -0400 From: Santosh Chokhani To: Russ Housley , IETF PKIX Date: Sat, 26 May 2012 17:33:01 -0400 Thread-Topic: [pkix] NameConstraints criticality flag Thread-Index: Ac07bjGFVYg5w63bSy+Zyixbjq7mEgAGJxJg Message-ID: References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> In-Reply-To: <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F662925scygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 21:33:06 -0000 --_000_B83745DA469B7847811819C5005244AF0F662925scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Why don't these folks go and work with Opera and Safari developers to get t= his right. There are open source toolkits if these folks need the code or = reference implementation to see a worked example. I see no need or benefit to dilute a security standard for the implementers= who do not get security or do not want to implement when explained. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Saturday, May 26, 2012 2:34 PM To: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag Phillip: I see no reason to defer to people who are not interested in my requirement= s and give me no vote Indeed. Why should the open IETF community defer to a closed community? Russ --_000_B83745DA469B7847811819C5005244AF0F662925scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable = --_000_B83745DA469B7847811819C5005244AF0F662925scygexch7cygnac_-- From ryan-pkix@sleevi.com Sat May 26 14:57:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64BE21F84DE for ; Sat, 26 May 2012 14:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdwOfU7ebTej for ; Sat, 26 May 2012 14:57:36 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 39DB521F8469 for ; Sat, 26 May 2012 14:57:36 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 4808C7E405D; Sat, 26 May 2012 14:57:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= sleevi.com; b=UF2Pi4RmNQctpmxEKkWQtub/61HwveGCv+gPgXIEDmXACRu/mB iej48ivXGdGByBGEuL4Jy4pvGDedEtJRwRSZqKtVMoNUgkC1iQ4HcQ0kTpG7Km/v onNi+VZxCDADu+zKCwLFyAveEXKTlvw4GKxhvstbiLac1EEbTPBBKWnlM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=uO/dzYpKA5IQ8K5tFO4hdPuQCFA=; b=r5cHJkzxR47NEpucO Z8+82AT+PxPkK1Kt2j3sZAteBqupeGjctiWjI4+6vBsVlToOOGVOS5T7tiMXhq42 +KkCmTSMnrp7zLojnYpRpHwJbEBnan5zwXnHXl4gFs9WKkMyE+fHiPjoCEcTtEUh vSg6zReSaeC7qgYGSveaqyhUIw= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPA id D6E297E4058; Sat, 26 May 2012 14:57:34 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Sat, 26 May 2012 14:57:35 -0700 Message-ID: In-Reply-To: References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> Date: Sat, 26 May 2012 14:57:35 -0700 From: "Ryan Sleevi" To: "Santosh Chokhani" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-pkix@sleevi.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 21:57:37 -0000 > +1 > > Why don't these folks go and work with Opera and Safari developers to = get > this right. There are open source toolkits if these folks need the co= de > or reference implementation to see a worked example. As mentioned several times already, because regardless of what tomorrows software does, there will still be millions of users who wish to use the Internet who will be running older software. Any CA who makes NC critical will necessarily prevent these users from accessing any servers whose certificates chain to them. Considering that so much of market position within the CA ecosystem is being able to interoperate with legacy systems, this is a unbearable market penalty for any CA. Considering the first mover penalties are so high, no CA wishing to stay in business would adopt NC. Further, unless and until every single CA simultaneously adopts critical NC, there will always be an incentive for CAs to offer technically-unconstrained (but still constrained by legal/procedural/contractual) sub-CAs, since that is the only RFC 5280 'compliant' means. This continued hardline opposition to non-critical nameConstraints does nothing doom them to being a non-implementable relic of the standards process, rather than being a viable path forward to a more secure Internet. Certainly, it would mean that the PKIX profile and the "PKI on the Internet" profile end up diverging, which does nothing to help adoption or understanding. > > I see no need or benefit to dilute a security standard for the > implementers who do not get security or do not want to implement when > explained. As has also been mentioned before, the expectation of 'fail closed' when encountering NC is a realistic decision of policy, not security, and has arguably no place in an IETF standard. While you can say that always having 'fail closed' is good for security, which I think no one will disagree with you on, the decision on when it's desirable to 'fail open' and 'fail closed' is one that should be left to relying parties, NOT mandated. It's not a matter of "implementers who do not get security" at this point - it's a matter of "standards making unnecessary policy requirements". As easy as it is to make ad hominem attacks, it's a lot harder to rewrite history and have all legacy implementations supporting nameConstraints. S= o rather than trying to do that, can we at least recognize the policy decision involved here? > > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f > Russ Housley > Sent: Saturday, May 26, 2012 2:34 PM > To: IETF PKIX > Subject: Re: [pkix] NameConstraints criticality flag > > Phillip: > > > I see no reason to defer to people who are not interested in my > requirements and give me no vote > > Indeed. Why should the open IETF community defer to a closed communit= y? > > Russ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From hallam@gmail.com Sat May 26 15:07:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CFB21F84FE for ; Sat, 26 May 2012 15:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z29WyAsR6YNA for ; Sat, 26 May 2012 15:07:52 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6AE21F84E6 for ; Sat, 26 May 2012 15:07:51 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1259488qcs.31 for ; Sat, 26 May 2012 15:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ITCSTqiBaQhH2nyRycFWseDRsDFWlHUJWGPmrjnnXP0=; b=Z20FbzYD1J+ULs8KmfbGQLenJCb4XD8uXqyU3l30eA0tp/XF60ZjVb5BNQxPPgnkEe N8w5Hn1+oGMUNIGyoYSPcbKpFyqTJ58QWGcVes9+7E6Dcc+mAx6r/aDK5z21558+jd5/ M/PPpu7WsCoCBgL9O/uEyB+Amd7GVFK0Sm/nZyQGOmL5DvCyyXS6ie38GxcZDBCFr3/E 9BXNZoBk7/Bdq6Td38vqhSm647QHIQ+LCVv8OADJuaJ8jdHZSZd50m1l5m/JXUB02mTj Mqq9m8SPUWb3GNoSdMAzFmmdNC3Ai55+zEXqyKIA1qVhG31dMmX+onFcInhyNSHHI2tv Yp6A== Received: by 10.229.137.144 with SMTP id w16mr962226qct.154.1338070070272; Sat, 26 May 2012 15:07:50 -0700 (PDT) Received: from [10.32.211.164] (mobile-198-228-205-033.mycingular.net. [198.228.205.33]) by mx.google.com with ESMTPS id dx8sm19515228qab.8.2012.05.26.15.07.47 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 May 2012 15:07:49 -0700 (PDT) References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> In-Reply-To: <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-6C775FC8-FFD2-4EC6-9E43-AE185BF0ECA6 Message-Id: <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com> X-Mailer: iPad Mail (9B176) From: Phillip Hallam-Baker Date: Sat, 26 May 2012 18:06:58 -0400 To: Russ Housley Cc: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 22:07:52 -0000 --Apple-Mail-6C775FC8-FFD2-4EC6-9E43-AE185BF0ECA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Anyone who agrees to the IPR policy can participate in CABForum CABforum is considerably more open in its governance than IETF. Here i have a= bsolutely no decision making power. Nor have i any vote. So if CaBForum is closed, then so is IETF.=20 I do not see a process in which an obstructionist minority can exercise veto= power to defend the status quo regardless of merit to be consensus based.=20= If you want decision making to return to the IETF in matters PKI then we are= going to have to consider a charter change for this WG as a minimum. Sent from my iPad On May 26, 2012, at 14:34, Russ Housley wrote: > Phillip: >=20 >> I see no reason to defer to people who are not interested in my requireme= nts and give me no vote >=20 > Indeed. Why should the open IETF community defer to a closed community? >=20 > Russ >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-6C775FC8-FFD2-4EC6-9E43-AE185BF0ECA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Anyone who agrees to the I= PR policy can participate in CABForum

CABforum is c= onsiderably more open in its governance than IETF. Here i have absolutel= y no decision making power. Nor have i any vote.

=
So if CaBForum is closed, then so is IETF. 


+1

 

Why don’t these folks go and work with Opera and Saf= ari developers to get this right.  There are open source toolkits if t= hese folks need the code or reference implementation to see a worked exampl= e.

 

I see no need or benefit to dilute a security st= andard for the implementers who do not get security or do not want to imple= ment when explained.

&n= bsp;

From: pkix-bounces@ie= tf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley
<= b>Sent:
Saturday, May 26, 2012 2:34 PM
To: IETF PKIX
Su= bject: Re: [pkix] NameConstraints criticality flag

 

Phillip:



I see no reason to defer to people who are = not interested in my requirements and give me no vote

=

 

Indeed.  Why should the open IETF community defer to a closed com= munity?

 

=

Russ

 

I do not see a process in which an obstructionist minority= can exercise veto power to defend the status quo regardless of merit to be c= onsensus based. 

If you want decision making t= o return to the IETF in matters PKI then we are going to have to consider a c= harter change for this WG as a minimum.



Sen= t from my iPad

On May 26, 2012, at 14:34, Russ Housley <housley@vigilsec.com> wrote:
<= br>
Phillip:
<= br class=3D"Apple-interchange-newline">
I se= e no reason to defer to people who are not interested in my requirements and= give me no vote

Indeed.  Why s= hould the open IETF community defer to a closed community?

Russ

_______________________________________________
pkix maili= ng list
pkix@ietf.org
https:= //www.ietf.org/mailman/listinfo/pkix
= --Apple-Mail-6C775FC8-FFD2-4EC6-9E43-AE185BF0ECA6-- From hallam@gmail.com Sat May 26 15:20:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5425621F8493 for ; Sat, 26 May 2012 15:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MP01xv3OOSZ for ; Sat, 26 May 2012 15:20:45 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 506BF21F848E for ; Sat, 26 May 2012 15:20:45 -0700 (PDT) Received: by qabj40 with SMTP id j40so332157qab.15 for ; Sat, 26 May 2012 15:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ieEH2F9hcIpbCXKuWxTVkzsCWBMp6KmD6i2F/MF4adY=; b=dMNePnFfXhTXR2OJXO6aAJCDVeelVknyvAQjiY03s/Hlm8x2m02nMaOOjKHhzonBki JpGa2NgckVmcm3eaiJlUDsprwy43Ckkrey1OeaenhT4jN3c/vnGpQ6wKG404BryPlwMQ jHV+HDQaT0mGgVyDeXaLMpwUgnN7sp4mNvKelQzHBsv5vgzU3s1aitXVrvLQkalpT1f0 ulU0Lzx2V/JOfOrBxlQxIRTEv2qJwsCfOLp1FOy/8O8IJ4zsFKOZl4FuW/OgwxWHfNOW l6X8eIIeXUu4EpxA/XILDAYP4J8JpH74NU+xYQmEim052ZbEfVM9avjTNBp2T6Qixo2s +Pgg== Received: by 10.224.33.8 with SMTP id f8mr3592558qad.11.1338070844736; Sat, 26 May 2012 15:20:44 -0700 (PDT) Received: from [10.32.211.164] (mobile-198-228-205-033.mycingular.net. [198.228.205.33]) by mx.google.com with ESMTPS id ej2sm19560471qab.7.2012.05.26.15.20.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 May 2012 15:20:44 -0700 (PDT) References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-C802C183-0B39-4671-B974-FC582EBCAAA9 Message-Id: <0EE27456-7995-435C-8F2E-6E1EFD84A73F@gmail.com> X-Mailer: iPad Mail (9B176) From: Phillip Hallam-Baker Date: Sat, 26 May 2012 18:20:40 -0400 To: Santosh Chokhani Cc: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 22:20:46 -0000 --Apple-Mail-C802C183-0B39-4671-B974-FC582EBCAAA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Of course it is in everyones interest for every browser to support NCs. But m= any deployed browsers cannot be updated and we see no reason to brick people= s mobile phones. As for people not getting security, you really do need to understand the dif= ference between not accepting your conslusion and not being competent. They s= imply do not consider your position to be valid and they are ignoring it. Ca= lling them stupid is not going to cause them to revise their opinion. Sent from my iPad On May 26, 2012, at 17:33, Santosh Chokhani wrote: > +1 > =20 > Why don=E2=80=99t these folks go and work with Opera and Safari developers= to get this right. There are open source toolkits if these folks need the c= ode or reference implementation to see a worked example. > =20 > I see no need or benefit to dilute a security standard for the implementer= s who do not get security or do not want to implement when explained. > =20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ru= ss Housley > Sent: Saturday, May 26, 2012 2:34 PM > To: IETF PKIX > Subject: Re: [pkix] NameConstraints criticality flag > =20 > Phillip: >=20 >=20 > I see no reason to defer to people who are not interested in my requiremen= ts and give me no vote > =20 > Indeed. Why should the open IETF community defer to a closed community? > =20 > Russ > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-C802C183-0B39-4671-B974-FC582EBCAAA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Of course it is in everyon= es interest for every browser to support NCs. But many deployed browsers can= not be updated and we see no reason to brick peoples mobile phones.

As for people not getting security, you really do need to u= nderstand the difference between not accepting your conslusion and not being= competent. They simply do not consider your position to be valid and they a= re ignoring it. Calling them stupid is not going to cause them to revise the= ir opinion.



Sent from my iPad
On May 26, 2012, at 17:33, Santosh Chokhani <SChokhani@cygnacom.com> wrote:

+1

 

Why don=E2=80=99t these folks go and work with Opera= and Safari developers to get this right.  There are open source toolki= ts if these folks need the code or reference implementation to see a worked e= xample.

<= o:p> 

I s= ee no need or benefit to dilute a security standard for the implementers who= do not get security or do not want to implement when explained.<= /span>

 

From: pkix-bounces@ietf.org= [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley
Sent:= Saturday, May 26, 2012 2:34 PM
To: IETF PKIX
Subject: Re: [pkix] NameConstraints criticality flag

 

Phillip:



=

I see no reason to defer to pe= ople who are not interested in my requirements and give me no vote

 

Indeed.  Why should the open IETF community defer to= a closed community?

&n= bsp;

Russ

 

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
<= /div>= --Apple-Mail-C802C183-0B39-4671-B974-FC582EBCAAA9-- From stephen.farrell@cs.tcd.ie Sat May 26 15:41:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9C021F84E6 for ; Sat, 26 May 2012 15:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPqy+lF4ANe1 for ; Sat, 26 May 2012 15:41:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id EC2B321F84E4 for ; Sat, 26 May 2012 15:41:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 65D121542E2; Sat, 26 May 2012 23:41:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338072113; bh=7XUyvg2FvNohZs JNtg9wkOKNMWwoKubYvnh9ex2FOZ4=; b=49U3z4wshDirlmFKWYC8HbapP7vzvI Jb5rgsFmc0+SdqfA45W3+ZkcUknYgIlHNjR3FIVH/0Dyb/gNvIa+ZCsJj97HL3MA twWmqXXQN3VQbWDshzpiU3qgAadLOJ8IXKpJEg9NDbX5nNK2XF8vZ5pQ0g4e0NW6 OV5CYR4pzYQscYIxHv/BOtHElWViHWnXRPEgAWvGVbrsXN2nghtp/0L89NmFIfJz 92hGKznK+RgN3nunZZaZ+7QigPxYkAlvJStv3uIB8+IpmiPgA8CKW/OAABOxG8PT 3jIi170YcZrLEzFdhvieIavUj8TnGvH9D9Lho9TO6wlMl/VMewW8NbYg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id NUp00lEj1CC1; Sat, 26 May 2012 23:41:53 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.70.236]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A83FB1542E1; Sat, 26 May 2012 23:41:52 +0100 (IST) Message-ID: <4FC15C30.10607@cs.tcd.ie> Date: Sat, 26 May 2012 23:41:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com> In-Reply-To: <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 22:41:56 -0000 Phill, On 05/26/2012 11:06 PM, Phillip Hallam-Baker wrote: > So if CaBForum is closed, then so is IETF. That is such utter nonsense. My guess is that you know its nonsense too but somehow think it helps your argument. From I would say pretty much any P-O-V, it just doesn't. (Unless maybe the P-O-V with one's foot in one's mouth perhaps;-) S. From paul.hoffman@vpnc.org Sat May 26 18:12:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08C21F84A1 for ; Sat, 26 May 2012 18:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43z7RpkmNeCH for ; Sat, 26 May 2012 18:12:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 968D521F8495 for ; Sat, 26 May 2012 18:12:01 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4R1BxVT042071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 26 May 2012 18:12:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com> Date: Sat, 26 May 2012 18:11:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17826B4A-9734-4186-9781-920F7E3D762F@vpnc.org> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com> To: IETF PKIX X-Mailer: Apple Mail (2.1278) Subject: [pkix] CABForum membership X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 01:12:02 -0000 The CABForum is a major user of the specs from this WG, so participation = there seems on-topic for this mailing list, at least for a bit. On May 26, 2012, at 3:06 PM, Phillip Hallam-Baker wrote: > Anyone who agrees to the IPR policy can participate in CABForum Is that true? I see no mention of that rule on the CABForum web page. = Further, I see no mention of the current members or its leadership. > CABforum is considerably more open in its governance than IETF. That's good to hear, but hard to verify. Where are the CABForum's = governance rules listed? Where is its leadership listed? (FWIW, these questions aren't aimed at Phill. Anyone from the CABForum = is welcome to educate those of us who can't find the information!) --Paul Hoffman From mstjohns@comcast.net Sat May 26 18:15:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C221F8473 for ; Sat, 26 May 2012 18:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9koSgU7ItS5 for ; Sat, 26 May 2012 18:15:00 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by ietfa.amsl.com (Postfix) with ESMTP id EE50621F8454 for ; Sat, 26 May 2012 18:14:59 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta12.emeryville.ca.mail.comcast.net with comcast id EpCb1j0010S2fkCACpEz3K; Sun, 27 May 2012 01:14:59 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta09.emeryville.ca.mail.comcast.net with comcast id EpEx1j00p57vnMg8VpEyjE; Sun, 27 May 2012 01:14:59 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 26 May 2012 21:14:52 -0400 To: ryan-pkix@sleevi.com,"Santosh Chokhani" From: Michael StJohns In-Reply-To: References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20120527011459.EE50621F8454@ietfa.amsl.com> Cc: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 01:15:00 -0000 At 05:57 PM 5/26/2012, Ryan Sleevi wrote: >Any CA who makes NC critical will necessarily prevent these users from >accessing any servers whose certificates chain to them. Considering that >so much of market position within the CA ecosystem is being able to >interoperate with legacy systems, this is a unbearable market penalty for >any CA. Considering the first mover penalties are so high, no CA wishing >to stay in business would adopt NC. I keep trying to understand this type of a statement, but it gives me a bad case of cognitive dissonance. I'm actually thinking that a critical NC and not being able to access those servers is a good thing and the whole idea of NC in the first place. Here's how I imagine an NC would be used. I'm a company that wants to issue certificates to my servers that chain back to a well known root. I *don't* want to have to do a server by server request to get certificates so I contract with the well known root (WKR) to get a CA certificate owned by my company signed. The WKR has two types of CA signing it will do - the first contains an NC that constrains me to issue certificates with names that are subordinate to "mikestjohnscompany.com" and costs X, the second that does not contain an NC and costs 10 X (mainly because the WKR doesn't want it competing with them for issuing TLS server certificates for random companies). If the WKR is only getting X, then the WKR is going to want to make sure that the certificates issued by the subordinate CA are enforceably within mikestjohnscompany.com which means setting the critical bit. If your (Ryan, Phil, etc) assumption is that very few RPs understand NC, then setting the bit to non-critical means that the NC is basically useless, and almost any name issued by that subordinate CA is going to be accepted by the vast majority of RPs including those not under mikestjohnscompany.com. Amusingly, if there are enough of non-critical NC/Non-Compliant name server certificates (because some subordinate CA was gaming the system, or was just stupid about how they set up their CA) deployed, deployments of browsers that implement NC support may never happen because those now NC supporting browsers will not be able to reach the servers with non-compliant certificates. Talk about anti-incentive. You're trying to deal with a legacy issue the wrong way (or so I believe). But, as someone else noted, it really is - in the final analysis - up to the issuing CA whether to set the critical bit or not. So as CA vendors you should feel free to set the bit as you please - it just won't be compliant with the 5280 profile if its set non-critical. Personally, I'd rather you just not include the NC in the certificate. Later, Mike From hallam@gmail.com Sat May 26 18:46:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739B121F848A for ; Sat, 26 May 2012 18:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf3o93GqoNpQ for ; Sat, 26 May 2012 18:46:07 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41DBB21F8484 for ; Sat, 26 May 2012 18:46:07 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4100789obb.31 for ; Sat, 26 May 2012 18:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MtLNXmNrTlaJ7GitQ+7DX0tntV9jGSgl9jO5yJND+Ew=; b=JUnWFJsFF0qotIcrtvjgPbn4MEgOD5xz2knDxOyaZmR5oDZZTkPUwIDE1ursdEs2vk ARHaN+IWAzsQkU+xmtpUPXmgENyceaxkfQe91E/GzZ5CMqC4KNXJNgoH9dUUkHXutgPx D4hNtRzKRWxACdW5pq4qVss5yg6WAjBxphuzNMMYbrLL/NeLnYSNcTI6ep/8qqZFjyib mDipl+MZEqgivHqQkvODl+bKKR4im9A/QkcQHGo93lOwt27qaa9lBQPYLAK6UZs1Xsh7 UL7/zIBFgCQqje6J4v0FDKQA9eGdmYmIQv6TKkBkxoU7DHucPeVWeu3mtcDuHOQTJriJ AZkQ== MIME-Version: 1.0 Received: by 10.182.164.69 with SMTP id yo5mr3752575obb.17.1338083165802; Sat, 26 May 2012 18:46:05 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Sat, 26 May 2012 18:46:05 -0700 (PDT) In-Reply-To: <20120527011459.EE50621F8454@ietfa.amsl.com> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <20120527011459.EE50621F8454@ietfa.amsl.com> Date: Sat, 26 May 2012 21:46:05 -0400 Message-ID: From: Phillip Hallam-Baker To: Michael StJohns Content-Type: multipart/alternative; boundary=e89a8f642d88c710ae04c0fac3eb Cc: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 01:46:08 -0000 --e89a8f642d88c710ae04c0fac3eb Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 26, 2012 at 9:14 PM, Michael StJohns wrote: > At 05:57 PM 5/26/2012, Ryan Sleevi wrote: > >Any CA who makes NC critical will necessarily prevent these users from > >accessing any servers whose certificates chain to them. Considering that > >so much of market position within the CA ecosystem is being able to > >interoperate with legacy systems, this is a unbearable market penalty for > >any CA. Considering the first mover penalties are so high, no CA wishing > >to stay in business would adopt NC. > > I keep trying to understand this type of a statement, but it gives me a > bad case of cognitive dissonance. I'm actually thinking that a critical NC > and not being able to access those servers is a good thing and the whole > idea of NC in the first place. > Think of it like a spam filter. It is much more important for a spam filter to ensure that all legitimate mail is delivered than to ensure that no spam gest through. Setting the criticality bit ensures that about 20% of users will get a false positive rejection of the cert. A false positive rate of even 1% is unacceptable. > Here's how I imagine an NC would be used. > > I'm a company that wants to issue certificates to my servers that chain > back to a well known root. I *don't* want to have to do a server by server > request to get certificates so I contract with the well known root (WKR) to > get a CA certificate owned by my company signed. > > The WKR has two types of CA signing it will do - the first contains an NC > that constrains me to issue certificates with names that are subordinate to > "mikestjohnscompany.com" and costs X, the second that does not contain an > NC and costs 10 X (mainly because the WKR doesn't want it competing with > them for issuing TLS server certificates for random companies). > > If the WKR is only getting X, then the WKR is going to want to make sure > that the certificates issued by the subordinate CA are enforceably within > mikestjohnscompany.com which means setting the critical bit. If your > (Ryan, Phil, etc) assumption is that very few RPs understand NC, then > setting the bit to non-critical means that the NC is basically useless, and > almost any name issued by that subordinate CA is going to be accepted by > the vast majority of RPs including those not under mikestjohnscompany.com. > You make a major mistake here in assuming that the value of name constraints is in client enforcement. Actually I think client enforcement of PKI path math is rather over-rated compared to the power of being able to detect AND REPORT anomalies. Since the majority of browsers do process Name Constraints, lets use this tool right now. > Amusingly, if there are enough of non-critical NC/Non-Compliant name > server certificates (because some subordinate CA was gaming the system, or > was just stupid about how they set up their CA) deployed, deployments of > browsers that implement NC support may never happen because those now NC > supporting browsers will not be able to reach the servers with > non-compliant certificates. Talk about anti-incentive. > You seem confused here. The critical flag has no effect on any browser unless it does not support the marked extension. A browser MAY reject a certificate for not being compliant with RFC 5280, but no browser is known to do so. A browser that processes Name Constraints is REQUIRED to do so EVEN IF THE CRITICALITY BIT IS NOT SET. > You're trying to deal with a legacy issue the wrong way (or so I believe). > But, as someone else noted, it really is - in the final analysis - up to > the issuing CA whether to set the critical bit or not. So as CA vendors > you should feel free to set the bit as you please - it just won't be > compliant with the 5280 profile if its set non-critical. Personally, I'd > rather you just not include the NC in the certificate. > It won't be compliant with the 5280 profile, correct. But how do we proceed if (as I expect) we have an essentially unanimous vote by the browser providers and the CAs to ignore 5280 on this point? Wouldn't that demonstrate a clear consensus in the industry in favor of the change? I think that the decision making in PKIX is broken and that there have to be changes or this group is going to be irrelevant. At the moment there is a presumption in favor of the status quo and any proposal that is brought here is shot down by a small group of people regardless of the merits. That isn't going to work any more. If what you really want is for all those annoying industry people to go take their ball home and play elsewhere then just let us know and we can do just that and leave you to do whatever it is you want to do in peace. If you want us to stay then you have to accept that we understand our own requirements and respect that our expertise in the field may equal or even exceed your own. Zero false positives is an absolute requirement for us. -- Website: http://hallambaker.com/ --e89a8f642d88c710ae04c0fac3eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, May 26, 2012 at 9:14 PM, Michael= StJohns <mstjohns@comcast.net> wrote:
At 05:57 PM 5/26/2012, Ryan Sleevi wrote:
>Any CA who makes NC critical will necessarily prevent these users from<= br> >accessing any servers whose certificates chain to them. Considering tha= t
>so much of market position within the CA ecosystem is being able to
>interoperate with legacy systems, this is a unbearable market penalty f= or
>any CA. Considering the first mover penalties are so high, no CA wishin= g
>to stay in business would adopt NC.

I keep trying to understand this type of a statement, but it gives me= a bad case of cognitive dissonance. =A0I'm actually thinking that a cr= itical NC and not being able to access those servers is a good thing and th= e whole idea of NC in the first place.

Think of it like a spam filter.
=
It is much more important for a spam filter to ensure that a= ll legitimate mail is delivered than to ensure that no spam gest through. S= etting the criticality bit ensures that about 20% of users will get a false= positive rejection of the cert.

A false positive rate of even 1% is unacceptable.
=


=A0
Here's how I imagine an NC would be used.

I'm a company that wants to issue certificates to my servers that chain= back to a well known root. =A0I *don't* want to have to do a server by= server request to get certificates so I contract with the well known root = (WKR) to get a CA certificate owned by my company signed.

The WKR has two types of CA signing it will do - the first contains an NC t= hat constrains me to issue certificates with names that are subordinate to = "mikestjoh= nscompany.com" and costs X, the second that does not contain an NC= and costs 10 X (mainly because the WKR doesn't want it competing with = them for issuing TLS server certificates for random companies).

If =A0the WKR is only getting X, then the WKR is going to want to make sure= that the certificates issued by the subordinate CA are enforceably within = mikestjohnscomp= any.com which means setting the critical bit. =A0 If your (Ryan, Phil, = etc) assumption is that very few RPs understand NC, then setting the bit to= non-critical means that the NC is basically useless, and almost any name i= ssued by that subordinate CA is going to be accepted by the vast majority o= f RPs including those not under mikestjohnscompany.com.

You make a major mistake here in assuming = that the value of name constraints is in client enforcement.

=
Actually I think client enforcement of PKI path math is rather o= ver-rated compared to the power of being able to detect AND REPORT anomalie= s.

Since the majority of browsers do process Name Constrai= nts, lets use this tool right now.

=A0
Amusingly, if there are enough of =A0non-critical NC/Non-Compliant name ser= ver certificates (because some subordinate CA was gaming the system, or was= just stupid about how they set up their CA) deployed, deployments of brows= ers that implement NC support may never happen because those now NC support= ing browsers will not be able to reach the servers with non-compliant certi= ficates. =A0Talk about anti-incentive.

You seem confused here. The critical flag = has no effect on any browser unless it does not support the marked extensio= n.=A0

A browser MAY reject a certificate for not b= eing compliant with RFC 5280, but no browser is known to do so.=A0

A browser that processes Name Constraints is REQUIRED t= o do so EVEN IF THE CRITICALITY BIT IS NOT SET.

= =A0
You're trying to deal with a legacy issue the wrong way (or so I believ= e). =A0 But, as someone else noted, it really is =A0- in the final analysis= - up to the issuing CA whether to set the critical bit or not. =A0So as CA= vendors you should feel free to set the bit as you please - it just won= 9;t be compliant with the 5280 profile if its set non-critical. =A0Personal= ly, I'd rather you just not include the NC in the certificate.

It won't be compliant with the 5280 pr= ofile, correct.

But how do we proceed if (as I exp= ect) we have an essentially unanimous vote by the browser providers and the= CAs to ignore 5280 on this point?

Wouldn't that demonstrate a clear consensus in the = industry in favor of the change?


I = think that the decision making in PKIX is broken and that there have to be = changes or this group is going to be irrelevant.=A0

At the moment there is a presumption in favor of the st= atus quo and any proposal that is brought here is shot down by a small grou= p of people regardless of the merits.

That isn'= ;t going to work any more.=A0


If what you really want is for all those= annoying industry people to go take their ball home and play elsewhere the= n just let us know and we can do just that and leave you to do whatever it = is you want to do in peace.

If you want us to stay then you have to accept that we = understand our own requirements and respect that our expertise in the field= may equal or even exceed your own.


Zero false positives is an absolute requirement for us.

--
Website: http://hall= ambaker.com/

--e89a8f642d88c710ae04c0fac3eb-- From ryan-pkix@sleevi.com Sat May 26 18:51:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398B021F84CF for ; Sat, 26 May 2012 18:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlmi03e9R2Ft for ; Sat, 26 May 2012 18:50:59 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2214321F84A2 for ; Sat, 26 May 2012 18:50:59 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id EE2571F0081; Sat, 26 May 2012 18:50:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= sleevi.com; b=soJQ2yjM2BzVvoPpUf/dgp/MiaiUi4lz/0IFycsmYDHQ/GQu+L 9AxyTr0VElp/sgXE1L/jnV+M5OfPTFd9/qVE93fbVUp8NXqFkH6hZDvc5nlYJJKS yFAsId8FyxQXZa0DQBNpD0Rg/9gj9wkc8rwjgjBiD1RF8iGGd5IT2XESM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=483ALZu3itZpizIp6ESbU9k51FY=; b=GWHJr++WXfknbolxm KLJbk6AzS6cWVyx1V7ndkguxN4o05cdnAacBdixsLSbIeq8fvirtPrGN3eOxMXb/ iQrPyYNN7vESEYTxGf+4p9/L+Q+2pqkBETZ9UTVd803tjZe09Mr/y5ko+BIPXq9E 4Xui/n7mbv6Yv0saQHOXeyI/Ls= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPA id 9BCB41F007C; Sat, 26 May 2012 18:50:55 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Sat, 26 May 2012 18:50:55 -0700 Message-ID: <711fa22908934fe7abe05ba28ef1d557.squirrel@webmail.dreamhost.com> In-Reply-To: <20120527011459.A244125DF79@homiemail-mx19.g.dreamhost.com> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <20120527011459.A244125DF79@homiemail-mx19.g.dreamhost.com> Date: Sat, 26 May 2012 18:50:55 -0700 From: "Ryan Sleevi" To: "Michael StJohns" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-pkix@sleevi.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 01:51:00 -0000 On Sat, May 26, 2012 6:14 pm, Michael StJohns wrote: > At 05:57 PM 5/26/2012, Ryan Sleevi wrote: > >Any CA who makes NC critical will necessarily prevent these users from > >accessing any servers whose certificates chain to them. Considering th= at > >so much of market position within the CA ecosystem is being able to > >interoperate with legacy systems, this is a unbearable market penalty = for > >any CA. Considering the first mover penalties are so high, no CA wishi= ng > >to stay in business would adopt NC. > > I keep trying to understand this type of a statement, but it gives me = a > bad case of cognitive dissonance. I'm actually thinking that a critic= al > NC and not being able to access those servers is a good thing and the > whole idea of NC in the first place. > > Here's how I imagine an NC would be used. > > I'm a company that wants to issue certificates to my servers that chai= n > back to a well known root. I *don't* want to have to do a server by > server request to get certificates so I contract with the well known r= oot > (WKR) to get a CA certificate owned by my company signed. > > The WKR has two types of CA signing it will do - the first contains an= NC > that constrains me to issue certificates with names that are subordina= te > to "mikestjohnscompany.com" and costs X, the second that does not cont= ain > an NC and costs 10 X (mainly because the WKR doesn't want it competing > with them for issuing TLS server certificates for random companies). > > If the WKR is only getting X, then the WKR is going to want to make s= ure > that the certificates issued by the subordinate CA are enforceably wit= hin > mikestjohnscompany.com which means setting the critical bit. If your > (Ryan, Phil, etc) assumption is that very few RPs understand NC, then > setting the bit to non-critical means that the NC is basically useless= , > and almost any name issued by that subordinate CA is going to be accep= ted > by the vast majority of RPs including those not under > mikestjohnscompany.com. Here's where it breaks down, and with all due respect to the CAs that participate here and in the CABForum: There is absolutely zero economic o= r practical incentive for the WKR to want to "make sure that the certificates issued by the subordinate CA are enforcably within mikestjohncompany.com" That's the reality of today and the past two decades. The WKR has absolutely zero obligation or incentive to protect clients/RP. They have every economic incentive to ensure you, Mike StJohns, don't start issuing certs off your root, which is why they constrain you with contractual and legal means, and every market incentive to ensure that if you, Mike StJohns, ask for a cert that can work with 98% of user-facing clients, it will. If they find you to be issuing certs outside of your contract, they'll revoke your cert - but that's not because of a desire to protect clients/RPs, that's out of a desire to protect their business interests (as you note when comparing X vs 10X's cost/benefits). Browser vendors and root store operators understandably don't like this - this leaves enforcement and detection solely in the hands of the WKRs, many of whom will not or cannot (due to contractual, legal, or economic reasons) disclose that they've issued an intermediate CA to Mike StJohns for use within mikestjohnscompany.com. This is bad. Now, if we continue further, one could argue that browsers/RPs should simply say the NC MUST be critical or the root will be removed. For publi= c CAs that are "Too Big Too Fail", this penalizes the browsers and users, i= n that removing such roots now means that users cannot validate 9/10 of the certificates on the Internet. For WKRs, such a requirement creates an economic penalty that is potentially life-threatening to their business - and must be protected by any means possible. Instead, a compromise has been reached - non-critical name constraints. Browsers can then programatically enforce what the WKRs are contractually enforcing, and WKRs can now programatically advertise the constraints they're enforcing contractually/legally. Further, as shown by proposed changes to items such as the Mozilla Root Certificate Policy, technical constraints can then be incorporated as /requirements/ for inclusions within the root store programs - ensuring that they get widely deployed b= y CAs. Further, if you want to buy one of those 10X certificates from a WKR= , root store requirements such as Mozilla's will require that you be /audited/ to the same degree as the WKR - something that cannot and is no= t distinguished by today. As more and more NC-certs are issued, clients/libraries that don't implement support for NC are now seen as security liabilities - and 'the market' can take care of educating customers/users, which encourages vendors to implement support for NC /as written/. People on the list can defend the purity of RFC 5280, its grand and noble intentions for security, but the reality is that many clients don't even ascribe to implement all of RFC 5280, 'just enough' to have some perceive= d modicum of security. If you were to look in any of the IETF Working Groups, you'd undoubtedly see a concern for and recognition of legacy interoperability - but here, it seems anathema to make any concessions that would aid such a goal. Again, I don't think anyone one disagrees that critical NC would be a great thing. But without a giant Internet flag day - which no one really wants and the economic incentives favour those who don't - their deployment is simply not going to happen. > > Amusingly, if there are enough of non-critical NC/Non-Compliant name > server certificates (because some subordinate CA was gaming the system= , or > was just stupid about how they set up their CA) deployed, deployments = of > browsers that implement NC support may never happen because those now = NC > supporting browsers will not be able to reach the servers with > non-compliant certificates. Talk about anti-incentive. > > You're trying to deal with a legacy issue the wrong way (or so I belie= ve). > But, as someone else noted, it really is - in the final analysis - = up > to the issuing CA whether to set the critical bit or not. So as CA > vendors you should feel free to set the bit as you please - it just wo= n't > be compliant with the 5280 profile if its set non-critical. Personall= y, > I'd rather you just not include the NC in the certificate. > > Later, Mike > > > > > > > From tom@ritter.vg Sat May 26 20:10:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97D221F8484 for ; Sat, 26 May 2012 20:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.976 X-Spam-Level: X-Spam-Status: No, score=-4.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRAs-X0L5gWN for ; Sat, 26 May 2012 20:10:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7C21F8478 for ; Sat, 26 May 2012 20:10:03 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4189660obb.31 for ; Sat, 26 May 2012 20:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YUtCgU/lE6dZMHRV1bPb1gDfnOqDQPrdRppCv3NaWA0=; b=iswmqWk3XoM7Wu6qwqTHuPXiNaqBQz4tMb53XZ2vx+RVN7P5EOMwAH3q9MxLBjiEng 8cMltK7vVbhepiRmTCVxOz39jAiQRAx/fCRLVRw7yXTOOuVqR8P8bI/Yfit89Sy5A0bp QuLUoq3LfEn7ozIjdyhW1vxrkKWFOFDcDUmiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YUtCgU/lE6dZMHRV1bPb1gDfnOqDQPrdRppCv3NaWA0=; b=dfsPlUKJN/Q7nt9QCdwXf3xe2pQ57P0mBiqKYHVeWtUvkiQdYqo8O2XCQCeJhahdw6 P3b7uX3NjerXT1yxySrcGUMOOOegi0rbCa4IoOOU9rKD50XgsTpgrrMiBjASjj39Rfui UYSmn867yoCeHktq7U9xv116G3ZsoubSfJS4yQobIrAkTqHuHVk03xSI3Nx/IoS5D1/S n6c3QdpwymErplc+/3vR6Hi+f5hwjZIv/Q9IftDIvnXiJjzUmgysaCEItyXh9x+ZnEkl 3eV3sbrvKOxMhkQwGkvAQ30AnYk3PSLD6BF1l9yvf3BAl0czP2xzP6Llqs+kpVeIQ63c JkbA== MIME-Version: 1.0 Received: by 10.182.119.33 with SMTP id kr1mr3840192obb.60.1338088196362; Sat, 26 May 2012 20:09:56 -0700 (PDT) Received: by 10.182.231.37 with HTTP; Sat, 26 May 2012 20:09:56 -0700 (PDT) Received: by 10.182.231.37 with HTTP; Sat, 26 May 2012 20:09:56 -0700 (PDT) In-Reply-To: <17826B4A-9734-4186-9781-920F7E3D762F@vpnc.org> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com> <17826B4A-9734-4186-9781-920F7E3D762F@vpnc.org> Date: Sat, 26 May 2012 23:09:56 -0400 Message-ID: From: Tom Ritter To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d044480d19f536b04c0fbefa2 X-Gm-Message-State: ALoCoQnnR0Ol3tEGmsQfQDYCDnQbJLQ6fhux4MjdRLjeKKzPMtnD8DejX1F2cnIix2JGqENa3omM Cc: IETF PKIX Subject: Re: [pkix] CABForum membership X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 03:10:04 -0000 --f46d044480d19f536b04c0fbefa2 Content-Type: text/plain; charset=ISO-8859-1 I was the only non-member at the first "Open" meeting of the CABForum, and subsequent meetings have been reverted back to private invitation. Also, my contribution to the "public list" (non antagonistic, merely pointing out a relevant link) was rejected because I'm not a member. The suggestion that it is more open, _right now_ is ridiculous. Once the new governance proposals (which are secret as of now) are decided on and take effect, maybe it will approach the level of openness the IETF enjoys, where at least anyone can voice opinions and propose changes. I don't aim to turn this list into a place to air grievances with the forum, but because you asked, and because I have tried to be involved, I'll offer my experiences. -tom --f46d044480d19f536b04c0fbefa2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I was the only non-member at the first "Open" meeting of the C= ABForum, and subsequent meetings have been reverted back to private invitat= ion. Also, my contribution to the "public list" (non antagonistic= , merely pointing out a relevant link) was rejected because I'm not a m= ember.

The suggestion that it is more open, _right now_ is ridiculous.=A0 Once = the new governance proposals (which are secret as of now) are decided on an= d take effect, maybe it will approach the level of openness the IETF enjoys= , where at least anyone can voice opinions and propose changes.

I don't aim to turn this list into a place to air grievances with th= e forum, but because you asked, and because I have tried to be involved, I&= #39;ll offer my experiences.

-tom

--f46d044480d19f536b04c0fbefa2-- From dev+ietf@seantek.com Sat May 26 22:49:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3699021F8497 for ; Sat, 26 May 2012 22:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI65vVMUeRWX for ; Sat, 26 May 2012 22:49:04 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7F12321F846C for ; Sat, 26 May 2012 22:49:04 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.173.239.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8F9C6509B4 for ; Sun, 27 May 2012 01:48:57 -0400 (EDT) Message-ID: <4FC1C046.9080900@seantek.com> Date: Sat, 26 May 2012 22:48:54 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <20120527011459.EE50621F8454@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 05:49:05 -0000 On 5/26/2012 6:46 PM, Phillip Hallam-Baker wrote: > It is much more important for a spam filter to ensure that all=20 > legitimate mail is delivered than to ensure that no spam gest through. = > Setting the criticality bit ensures that about 20% of users will get a = > false positive rejection of the cert. > > A false positive rate of even 1% is unacceptable. This is a misleading characterization. Enforcing the processing of a name constraint extension is more like a=20 false negative. The cert "should be valid", but the processing software=20 says "it's not valid", because the criticality bit is enforced when the=20 extension cannot be processed. That would be a false negative. False negatives are sad. A system with a high degree of false negatives=20 is not usable. Spam filters, of course, have a lot of false negatives. But false positives (accepting a certificate when it is widely=20 recognized to be invalid, such as the ComodoHacker and DigiNotar=20 incidents) are far worse. > Zero false positives is an absolute requirement for us. Zero false positives is a requirement for strong security in the=20 Internet community. Just don't confuse which is "false positive" and=20 which is "false negative". See DigiNotar. The browser industry voted on=20 that with its feet. Sean From hallam@gmail.com Sun May 27 04:56:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A9A21F8531 for ; Sun, 27 May 2012 04:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmjClZmxKNvy for ; Sun, 27 May 2012 04:56:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D155C21F852B for ; Sun, 27 May 2012 04:56:14 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4753221obb.31 for ; Sun, 27 May 2012 04:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mmVLQyrGd+CkKP9uSj7sZYKMEbSYMuLtFotvN1YzIWw=; b=iEO00QGTFbX/VRmG1xj40Om+Xdl1mo+FlVHHQyssaEm4iY6mfn2vAHkNmmFvR/LmpS cL+qmzR4wHpkrC+Xs3Ehwy3z5zHE+ninKaiawPR0wNSLME26bLHG1GBn969zqMVrCRWw k2596J6SiBVytOaw/zcYihhiIqrzYy5c9sk7AHkGfFQBGbFmgfw/amAal39DihZdP9SQ BVoR8r+cYWP91n5uKzl/wQiCevJwb8U7n4sW7TCnyVoeICX2hjgiqQLZDcydasXH9vNG QQ4rwpe0f2hxM+/aizq4tfu9ET7ef/vqMg+ldIqUIvp4k+GD2j7n+yI0w7xxpupV8hYI DU+A== MIME-Version: 1.0 Received: by 10.60.10.99 with SMTP id h3mr4817060oeb.72.1338119774435; Sun, 27 May 2012 04:56:14 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Sun, 27 May 2012 04:56:14 -0700 (PDT) In-Reply-To: <4FC1C046.9080900@seantek.com> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <20120527011459.EE50621F8454@ietfa.amsl.com> <4FC1C046.9080900@seantek.com> Date: Sun, 27 May 2012 07:56:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Sean Leonard Content-Type: multipart/alternative; boundary=e89a8fb1fbfad2791d04c1034901 Cc: pkix@ietf.org Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 11:56:16 -0000 --e89a8fb1fbfad2791d04c1034901 Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 27, 2012 at 1:48 AM, Sean Leonard wrote: > On 5/26/2012 6:46 PM, Phillip Hallam-Baker wrote: > >> It is much more important for a spam filter to ensure that all legitimate >> mail is delivered than to ensure that no spam gest through. Setting the >> criticality bit ensures that about 20% of users will get a false positive >> rejection of the cert. >> >> A false positive rate of even 1% is unacceptable. >> > > This is a misleading characterization. > > Enforcing the processing of a name constraint extension is more like a > false negative. The cert "should be valid", but the processing software > says "it's not valid", because the criticality bit is enforced when the > extension cannot be processed. That would be a false negative. > > False negatives are sad. A system with a high degree of false negatives is > not usable. Spam filters, of course, have a lot of false negatives. > > But false positives (accepting a certificate when it is widely recognized > to be invalid, such as the ComodoHacker and DigiNotar incidents) are far > worse. Since the Comodo certificates were revoked, an RP that implemented revocation checks properly should not have trusted the certs anyway. Name Constraints would not have had any effect in either case. Zero false positives is an absolute requirement for us. >> > > Zero false positives is a requirement for strong security in the Internet > community. Just don't confuse which is "false positive" and which is "false > negative". See DigiNotar. The browser industry voted on that with its feet. No, this proposal comes from Mozilla. The browser providers have almost unanimously decided not to support hard fail on revocation checks and have not revised that opinion in the light of the attacks. As a reality check here, application vulnerabilities are rather more consequential than CA compromises such as buffer overruns and happen with far greater frequency. -- Website: http://hallambaker.com/ --e89a8fb1fbfad2791d04c1034901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, May 27, 2012 at 1:48 AM, Sean Le= onard <dev+ietf@seantek.com> wrote:
On 5/26/2012 6:46 PM, Phillip Hallam-Baker wrote:
It is much more important for a spam filter to ensure that all legitimate m= ail is delivered than to ensure that no spam gest through. Setting the crit= icality bit ensures that about 20% of users will get a false positive rejec= tion of the cert.

A false positive rate of even 1% is unacceptable.

This is a misleading characterization.

Enforcing the processing of a name constraint extension is more like a fals= e negative. The cert "should be valid", but the processing softwa= re says "it's not valid", because the criticality bit is enfo= rced when the extension cannot be processed. That would be a false negative= .

False negatives are sad. A system with a high degree of false negatives is = not usable. Spam filters, of course, have a lot of false negatives.

But false positives (accepting a certificate when it is widely recognized t= o be invalid, such as the ComodoHacker and DigiNotar incidents) are far wor= se.

Since the Comodo certificates were revo= ked, an RP that implemented revocation checks properly should not have trus= ted the certs anyway.

Name Constraints would not have had any effect in eithe= r case.
=A0

Zero false positives is an absolute requirement for us.

Zero false positives is a requirement for strong security in the Internet c= ommunity. Just don't confuse which is "false positive" and wh= ich is "false negative". See DigiNotar. The browser industry vote= d on that with its feet.

No, this proposal comes from Mozilla.=A0

=
The browser providers have almost unanimously decided not to sup= port hard fail on revocation checks and have not revised that opinion in th= e light of the attacks.


As a reality check here, application vul= nerabilities are rather more consequential than CA compromises such as buff= er overruns and happen with far greater frequency.


--
Website: ht= tp://hallambaker.com/

--e89a8fb1fbfad2791d04c1034901-- From SChokhani@cygnacom.com Sun May 27 08:10:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5481C21F84FE for ; Sun, 27 May 2012 08:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVbBEOeBdD8L for ; Sun, 27 May 2012 08:10:05 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 75BC721F846C for ; Sun, 27 May 2012 08:10:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,665,1330923600"; d="scan'208";a="1046280" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 27 May 2012 11:09:52 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sun, 27 May 2012 11:09:52 -0400 From: Santosh Chokhani To: Michael StJohns , "ryan-pkix@sleevi.com" Date: Sun, 27 May 2012 11:09:50 -0400 Thread-Topic: Way Forward: Name Constraints Criticality Thread-Index: Ac08GsNsKS+J4IylThCqrltUJuYcsQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 15:10:06 -0000 I agree with Mike. In light of the fact we seem to have established positions which we do not = wish to change, I thought we should see if there are options we could agree= on. To that end and since the thread has several sub-threads, I have begun a ne= w thread. Here are the options that come to my mind. There may be others. Option 1: Do not change the standard Option 2: Do not change the standard but add language akin to the following= in an appropriate place in the standard " It is recognized that a CA may w= ish to make the name constraints extension non-critical in order to maximiz= e interoperability. Such CA shall either use other mechanisms that are not= specified in this standard or shall make such a decision based on trading = off increased interoperability and security exposure" Option 3: Change the standard to make the extension "recommended to be crit= ical for a period of time" This period of time should be short and should = be only made if Opera and Safari decision makers are willing to provide the= support for the extension ASAP in their browsers and maximize updates to t= he current version. We can add the applicable language and revision from O= ption 2. I would set this date to be expiry date of CA certificate since r= evocation checking in browsers is uneven. Option 4: Change the standard to make the extension "recommended to be crit= ical". I would be against it. May be we could use this or similar method to get a vote on the WG since in= my opinion no one is saying anything new. -----Original Message----- From: Michael StJohns [mailto:mstjohns@comcast.net]=20 Sent: Saturday, May 26, 2012 9:15 PM To: ryan-pkix@sleevi.com; Santosh Chokhani Cc: IETF PKIX Subject: Re: [pkix] NameConstraints criticality flag At 05:57 PM 5/26/2012, Ryan Sleevi wrote: >Any CA who makes NC critical will necessarily prevent these users from=20 >accessing any servers whose certificates chain to them. Considering=20 >that so much of market position within the CA ecosystem is being able=20 >to interoperate with legacy systems, this is a unbearable market=20 >penalty for any CA. Considering the first mover penalties are so high,=20 >no CA wishing to stay in business would adopt NC. I keep trying to understand this type of a statement, but it gives me a bad= case of cognitive dissonance. I'm actually thinking that a critical NC an= d not being able to access those servers is a good thing and the whole idea= of NC in the first place. Here's how I imagine an NC would be used. I'm a company that wants to issue certificates to my servers that chain bac= k to a well known root. I *don't* want to have to do a server by server re= quest to get certificates so I contract with the well known root (WKR) to g= et a CA certificate owned by my company signed. =20 The WKR has two types of CA signing it will do - the first contains an NC t= hat constrains me to issue certificates with names that are subordinate to = "mikestjohnscompany.com" and costs X, the second that does not contain an N= C and costs 10 X (mainly because the WKR doesn't want it competing with the= m for issuing TLS server certificates for random companies). If the WKR is only getting X, then the WKR is going to want to make sure t= hat the certificates issued by the subordinate CA are enforceably within mi= kestjohnscompany.com which means setting the critical bit. If your (Ryan,= Phil, etc) assumption is that very few RPs understand NC, then setting the= bit to non-critical means that the NC is basically useless, and almost any= name issued by that subordinate CA is going to be accepted by the vast maj= ority of RPs including those not under mikestjohnscompany.com. =20 Amusingly, if there are enough of non-critical NC/Non-Compliant name serve= r certificates (because some subordinate CA was gaming the system, or was j= ust stupid about how they set up their CA) deployed, deployments of browser= s that implement NC support may never happen because those now NC supportin= g browsers will not be able to reach the servers with non-compliant certifi= cates. Talk about anti-incentive. You're trying to deal with a legacy issue the wrong way (or so I believe). = But, as someone else noted, it really is - in the final analysis - up to= the issuing CA whether to set the critical bit or not. So as CA vendors y= ou should feel free to set the bit as you please - it just won't be complia= nt with the 5280 profile if its set non-critical. Personally, I'd rather y= ou just not include the NC in the certificate. Later, Mike From dev+ietf@seantek.com Sun May 27 08:27:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB4D21F84C8 for ; Sun, 27 May 2012 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8LPCQO+jVqC for ; Sun, 27 May 2012 08:27:44 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE5E21F8498 for ; Sun, 27 May 2012 08:27:44 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.173.239.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A010F50A64 for ; Sun, 27 May 2012 11:27:37 -0400 (EDT) Message-ID: <4FC247E8.80807@seantek.com> Date: Sun, 27 May 2012 08:27:36 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 15:27:44 -0000 Santosh provides a reasonable 4-option framework for a vote. On 5/27/2012 8:09 AM, Santosh Chokhani wrote: > Option 1: Do not change the standard > > Option 2: Do not change the standard but add language akin to the following in an appropriate place in the standard " It is recognized that a CA may wish to make the name constraints extension non-critical in order to maximize interoperability. Such CA shall either use other mechanisms that are not specified in this standard or shall make such a decision based on trading off increased interoperability and security exposure" > > Option 3: Change the standard to make the extension "recommended to be critical for a period of time" This period of time should be short and should be only made if Opera and Safari decision makers are willing to provide the support for the extension ASAP in their browsers and maximize updates to the current version. We can add the applicable language and revision from Option 2. I would set this date to be expiry date of CA certificate since revocation checking in browsers is uneven. > > Option 4: Change the standard to make the extension "recommended to be critical". I would be against it. > > May be we could use this or similar method to get a vote on the WG since in my opinion no one is saying anything new. From mstjohns@comcast.net Sun May 27 12:06:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4849E21F853B for ; Sun, 27 May 2012 12:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL2Pv45J2beT for ; Sun, 27 May 2012 12:06:19 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69C21F8531 for ; Sun, 27 May 2012 12:06:19 -0700 (PDT) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta11.emeryville.ca.mail.comcast.net with comcast id F75d1j0020FhH24AB76KV0; Sun, 27 May 2012 19:06:19 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta08.emeryville.ca.mail.comcast.net with comcast id F76H1j00i57vnMg8U76JP2; Sun, 27 May 2012 19:06:19 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 27 May 2012 15:06:16 -0400 To: Santosh Chokhani , "ryan-pkix@sleevi.com" From: Michael StJohns In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20120527190619.8B69C21F8531@ietfa.amsl.com> Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 19:06:20 -0000 Hi Santosh - I think you've got the correct 4 cases, but 5280 and its ilk are implementation standards/recommendations, and not so much operational guidance and your options 2 and 3 are really operational guidance twiddles. I'm actually thinking the right answer is for Phil et al to publish an Informational RFC that says they are doing X for Y reasons, note that this conflicts with 5280, note why they are doing it, note that other CAs may or may not want to do the same, and leave RFC5280 alone. That keeps 5280 in-line with the goals of best technical guidance* and still gives a place to record operational ... necessities? Mike Note: * As far as I can tell, the push by Phil et al for the change is not so much best technical guidance, but a semi-pragmatic and all capitalistic attempt to do something useful with NC without screwing up the CA business model - not wrong in and of itself, just not quite what is supposed to work in the IETF. The IETF has mostly been about trying to find the best technical approach which is why we've been so adamant over the years about people participating as individuals and not as representatives of their employers. At 11:09 AM 5/27/2012, Santosh Chokhani wrote: >I agree with Mike. > >In light of the fact we seem to have established positions which we do not wish to change, I thought we should see if there are options we could agree on. > >To that end and since the thread has several sub-threads, I have begun a new thread. > >Here are the options that come to my mind. There may be others. > >Option 1: Do not change the standard > >Option 2: Do not change the standard but add language akin to the following in an appropriate place in the standard " It is recognized that a CA may wish to make the name constraints extension non-critical in order to maximize interoperability. Such CA shall either use other mechanisms that are not specified in this standard or shall make such a decision based on trading off increased interoperability and security exposure" > >Option 3: Change the standard to make the extension "recommended to be critical for a period of time" This period of time should be short and should be only made if Opera and Safari decision makers are willing to provide the support for the extension ASAP in their browsers and maximize updates to the current version. We can add the applicable language and revision from Option 2. I would set this date to be expiry date of CA certificate since revocation checking in browsers is uneven. > >Option 4: Change the standard to make the extension "recommended to be critical". I would be against it. > >May be we could use this or similar method to get a vote on the WG since in my opinion no one is saying anything new. > >-----Original Message----- >From: Michael StJohns [mailto:mstjohns@comcast.net] >Sent: Saturday, May 26, 2012 9:15 PM >To: ryan-pkix@sleevi.com; Santosh Chokhani >Cc: IETF PKIX >Subject: Re: [pkix] NameConstraints criticality flag > >At 05:57 PM 5/26/2012, Ryan Sleevi wrote: >>Any CA who makes NC critical will necessarily prevent these users from >>accessing any servers whose certificates chain to them. Considering >>that so much of market position within the CA ecosystem is being able >>to interoperate with legacy systems, this is a unbearable market >>penalty for any CA. Considering the first mover penalties are so high, >>no CA wishing to stay in business would adopt NC. > >I keep trying to understand this type of a statement, but it gives me a bad case of cognitive dissonance. I'm actually thinking that a critical NC and not being able to access those servers is a good thing and the whole idea of NC in the first place. > >Here's how I imagine an NC would be used. > >I'm a company that wants to issue certificates to my servers that chain back to a well known root. I *don't* want to have to do a server by server request to get certificates so I contract with the well known root (WKR) to get a CA certificate owned by my company signed. > >The WKR has two types of CA signing it will do - the first contains an NC that constrains me to issue certificates with names that are subordinate to "mikestjohnscompany.com" and costs X, the second that does not contain an NC and costs 10 X (mainly because the WKR doesn't want it competing with them for issuing TLS server certificates for random companies). > >If the WKR is only getting X, then the WKR is going to want to make sure that the certificates issued by the subordinate CA are enforceably within mikestjohnscompany.com which means setting the critical bit. If your (Ryan, Phil, etc) assumption is that very few RPs understand NC, then setting the bit to non-critical means that the NC is basically useless, and almost any name issued by that subordinate CA is going to be accepted by the vast majority of RPs including those not under mikestjohnscompany.com. > >Amusingly, if there are enough of non-critical NC/Non-Compliant name server certificates (because some subordinate CA was gaming the system, or was just stupid about how they set up their CA) deployed, deployments of browsers that implement NC support may never happen because those now NC supporting browsers will not be able to reach the servers with non-compliant certificates. Talk about anti-incentive. > >You're trying to deal with a legacy issue the wrong way (or so I believe). But, as someone else noted, it really is - in the final analysis - up to the issuing CA whether to set the critical bit or not. So as CA vendors you should feel free to set the bit as you please - it just won't be compliant with the 5280 profile if its set non-critical. Personally, I'd rather you just not include the NC in the certificate. > >Later, Mike From rob.stradling@comodo.com Mon May 28 03:20:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95D521F845F for ; Mon, 28 May 2012 03:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrWznrYtkVJL for ; Mon, 28 May 2012 03:20:41 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id A7DD821F845D for ; Mon, 28 May 2012 03:20:40 -0700 (PDT) Received: (qmail 2094 invoked from network); 28 May 2012 10:20:38 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 28 May 2012 10:20:38 -0000 Received: (qmail 5611 invoked by uid 1000); 28 May 2012 10:20:38 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 28 May 2012 11:20:38 +0100 Message-ID: <4FC35175.80604@comodo.com> Date: Mon, 28 May 2012 11:20:37 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: IETF PKIX References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <004901cd3b14$6b0951d0$411bf570$@eu> <352AF057-71DE-4895-8630-C81188EE2228@vigilsec.com> In-Reply-To: <352AF057-71DE-4895-8630-C81188EE2228@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 10:20:42 -0000 The follow-ups in this thread so far all seem to say that the digitalSignature bit should be set in a CA certificate whose private key will sign OCSP Responses directly. The last question in my original post asked if this was actually consistent with X.509. Would anyone care to comment on this question? Here it is again... X.509 (2008/05) says... "digitalSignature: for verifying digital signatures that are used with an entity authentication service, a data origin authentication service and/or an integrity service;" Is OCSP... 1. "an entity authentication service"? 2. "a data origin authentication service"? 3. "an integrity service"? 4. More than 1 of the above? 5. None of the above? If "None of the above", then surely it'd be wrong for digitalSignature to govern whether or not the CA Certificate's private key can directly sign OCSP Responses? Thanks. On 26/05/12 14:59, Russ Housley wrote: > Erik: > > I think Denis meant that we should have asked for such a bit back in > 1998 and 1999 when OCSP was first being defined. > > Russ > > > On May 26, 2012, at 3:51 AM, Erik Andersen wrote: > >> Hi Denis, >> As X.509 is the master specification the keyUsage extension, any >> addition to that extension should be done in X.509. Others could then >> copy it. >> Erik >> *Fra:*pkix-bounces@ietf.org >> [mailto:pkix-bounces@ietf.org]*P vegne >> af*denis.pinkas@bull.net >> *Sendt:*25. maj 2012 18:32 >> *Til:*Russ Housley >> *Cc:*pkix@ietf.org ;pkix-bounces@ietf.org >> >> *Emne:*Re: [pkix] Integrated OCSP Responders / Key Usage bits >> Russ, >> >> I raised the question in my presentation on OCSP during the last PKIX >> session in Paris, >> since there is currently no answer in the PKIX documents. >> >> I don't believe that your response is correct. >> >> The id-kp-OCSPSigning object identifier is only for a designated OCSP >> responder. >> This is not the case we are considering in this discussion. >> >> RFC 2560 states: "OCSP signing delegation SHALL be designated by the >> inclusion of id-kp-OCSPSigning >> in an extendedKeyUsage certificate extension included in the OCSP >> response signer's certificate". >> >> Ideally, we should have added an OCSP signing bit in the key usage >> bits, but unfortunately >> nobody raised the point when we built RFC 2560. >> >> Rob mentioned the (relatively recently published) CABForum Baseline >> Requirements >> document which says: "Bit positions for keyCertSign and cRLSign MUST >> be set. >> If the Root/Subordinate CA Private Key is used for signing OCSP >> responses, then >> the digitalSignature bit MUST be set." >> >> I don't believe that this response is correct either, since in the >> general case an upper CA >> does not sign OCSP responses for a lower CA. >> >> Let me propose a strawman: >> >> The keyCertSign bit and the digitalSignature bit MUST be set. >> The cRLSign bit MAY be set. >> >> A few explanations are needed. >> Since the CA issues certificates, the keyCertSign bit MUST be set. >> Since the CA signs OCSP responses, the digitalSignature bit MUST be set. >> If the CA issues both CRLs and OCSP Responses, then the cRLSign bit >> MUST be set, >> otherwise it MUST NOT be set. >> >> Let us now suppose that a CA starts to issue CRLs and that, later on, >> the CA wants to issue OCSP responses. >> With this strawman proposal, the CA must obtain a new certificate from >> its upper CA. This makes sense since >> the Certification Policy has changed and the upper CA has the right to >> verify the practices of its child CA. >> >> Note: Any proposal will break some eggs and make an omelet, since, >> without guidance, implementers did "something". >> What is strange is that OCSP currently works ! >> I would guess most implementations only test the keyCertSign bit. >> >> Denis >> >> >> >> De : Russ Housley > >> A : Rob Stradling > > >> Cc : pkix@ietf.org >> Date : 25/05/2012 17:50 >> Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits >> Envoy par : pkix-bounces@ietf.org >> ------------------------------------------------------------------------ >> >> >> >> >> Rob: >> >> > Which Key Usage bits (if any) are required to be present in a CA >> Certificate that directly signs OCSP Responses? >> >> Do you mean that the same private key is used by the CA to sign >> certificates, CRLs, and OCSP Responses? If so, I would expect the CA >> certificate that contains the corresponding public key to include the >> key usage and the extended key usage extensions. The key usage >> extension should have at least the keyCertSign and the cRLSign bits >> set. The extended key usage extension should include at least the >> id-kp-OCSPSigning object identifier. >> >> Russ >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From rob.stradling@comodo.com Mon May 28 03:21:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9880621F84E1 for ; Mon, 28 May 2012 03:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoHexM9h9LG3 for ; Mon, 28 May 2012 03:21:24 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id B19DE21F845D for ; Mon, 28 May 2012 03:21:23 -0700 (PDT) Received: (qmail 2417 invoked from network); 28 May 2012 10:21:22 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 28 May 2012 10:21:22 -0000 Received: (qmail 5763 invoked by uid 1000); 28 May 2012 10:21:22 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 28 May 2012 11:21:22 +0100 Message-ID: <4FC351A2.7060807@comodo.com> Date: Mon, 28 May 2012 11:21:22 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Russ Housley References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> In-Reply-To: <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 10:21:24 -0000 On 25/05/12 16:50, Russ Housley wrote: > Rob: > >> Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses? > > Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses? Yes. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From ynir@checkpoint.com Mon May 28 05:39:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A9D21F847D for ; Mon, 28 May 2012 05:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WPsbnnrsSsD for ; Mon, 28 May 2012 05:39:27 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CCF6D21F8470 for ; Mon, 28 May 2012 05:39:25 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4SCcl6X000667; Mon, 28 May 2012 15:38:48 +0300 X-CheckPoint: {4FC37E46-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 28 May 2012 15:38:45 +0300 From: Yoav Nir To: Santosh Chokhani Date: Mon, 28 May 2012 15:38:40 +0300 Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac08ztI7vt/iVxqmRLm90kF0R23UzQ== Message-ID: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1199a60909cfe272e5e40b77087a3985f4cc67d18d Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 12:39:28 -0000 Hi Santosh I don't really see the difference between options 2 and 4. In option #2 we'= re keeping the MUST, but adding language that says that CAs can decide to m= ake it non-critical if certain conditions apply and/or they decide to trade= off interoperability for security. IMO this is the very definition of SHOU= LD Yoav On May 27, 2012, at 6:09 PM, Santosh Chokhani wrote: > I agree with Mike. >=20 > In light of the fact we seem to have established positions which we do no= t wish to change, I thought we should see if there are options we could agr= ee on. >=20 > To that end and since the thread has several sub-threads, I have begun a = new thread. >=20 > Here are the options that come to my mind. There may be others. >=20 > Option 1: Do not change the standard >=20 > Option 2: Do not change the standard but add language akin to the followi= ng in an appropriate place in the standard " It is recognized that a CA may= wish to make the name constraints extension non-critical in order to maxim= ize interoperability. Such CA shall either use other mechanisms that are n= ot specified in this standard or shall make such a decision based on tradin= g off increased interoperability and security exposure" >=20 > Option 3: Change the standard to make the extension "recommended to be cr= itical for a period of time" This period of time should be short and shoul= d be only made if Opera and Safari decision makers are willing to provide t= he support for the extension ASAP in their browsers and maximize updates to= the current version. We can add the applicable language and revision from= Option 2. I would set this date to be expiry date of CA certificate since= revocation checking in browsers is uneven. >=20 > Option 4: Change the standard to make the extension "recommended to be cr= itical". I would be against it. >=20 > May be we could use this or similar method to get a vote on the WG since = in my opinion no one is saying anything new. >=20 > -----Original Message----- > From: Michael StJohns [mailto:mstjohns@comcast.net]=20 > Sent: Saturday, May 26, 2012 9:15 PM > To: ryan-pkix@sleevi.com; Santosh Chokhani > Cc: IETF PKIX > Subject: Re: [pkix] NameConstraints criticality flag >=20 > At 05:57 PM 5/26/2012, Ryan Sleevi wrote: >> Any CA who makes NC critical will necessarily prevent these users from=20 >> accessing any servers whose certificates chain to them. Considering=20 >> that so much of market position within the CA ecosystem is being able=20 >> to interoperate with legacy systems, this is a unbearable market=20 >> penalty for any CA. Considering the first mover penalties are so high,=20 >> no CA wishing to stay in business would adopt NC. >=20 > I keep trying to understand this type of a statement, but it gives me a b= ad case of cognitive dissonance. I'm actually thinking that a critical NC = and not being able to access those servers is a good thing and the whole id= ea of NC in the first place. >=20 > Here's how I imagine an NC would be used. >=20 > I'm a company that wants to issue certificates to my servers that chain b= ack to a well known root. I *don't* want to have to do a server by server = request to get certificates so I contract with the well known root (WKR) to= get a CA certificate owned by my company signed. =20 >=20 > The WKR has two types of CA signing it will do - the first contains an NC= that constrains me to issue certificates with names that are subordinate t= o "mikestjohnscompany.com" and costs X, the second that does not contain an= NC and costs 10 X (mainly because the WKR doesn't want it competing with t= hem for issuing TLS server certificates for random companies). >=20 > If the WKR is only getting X, then the WKR is going to want to make sure= that the certificates issued by the subordinate CA are enforceably within = mikestjohnscompany.com which means setting the critical bit. If your (Rya= n, Phil, etc) assumption is that very few RPs understand NC, then setting t= he bit to non-critical means that the NC is basically useless, and almost a= ny name issued by that subordinate CA is going to be accepted by the vast m= ajority of RPs including those not under mikestjohnscompany.com. =20 >=20 > Amusingly, if there are enough of non-critical NC/Non-Compliant name ser= ver certificates (because some subordinate CA was gaming the system, or was= just stupid about how they set up their CA) deployed, deployments of brows= ers that implement NC support may never happen because those now NC support= ing browsers will not be able to reach the servers with non-compliant certi= ficates. Talk about anti-incentive. >=20 > You're trying to deal with a legacy issue the wrong way (or so I believe)= . But, as someone else noted, it really is - in the final analysis - up = to the issuing CA whether to set the critical bit or not. So as CA vendors= you should feel free to set the bit as you please - it just won't be compl= iant with the 5280 profile if its set non-critical. Personally, I'd rather= you just not include the NC in the certificate. >=20 > Later, Mike >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Mon May 28 05:44:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C0C21F84CD for ; Mon, 28 May 2012 05:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmlQPzyZk3-Z for ; Mon, 28 May 2012 05:44:58 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 369D521F8480 for ; Mon, 28 May 2012 05:44:57 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4SCitxW002407; Mon, 28 May 2012 15:44:56 +0300 X-CheckPoint: {4FC37FB6-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 28 May 2012 15:44:52 +0300 From: Yoav Nir To: Sean Leonard Date: Mon, 28 May 2012 15:44:46 +0300 Thread-Topic: [pkix] NameConstraints criticality flag Thread-Index: Ac08z60B+KzCeKqlQmO+596YorWXkA== Message-ID: References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <20120527011459.EE50621F8454@ietfa.amsl.com> <4FC1C046.9080900@seantek.com> In-Reply-To: <4FC1C046.9080900@seantek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11975edf121287da28760e31cba86867cb2c126f0f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 12:44:59 -0000 On May 27, 2012, at 8:48 AM, Sean Leonard wrote: > On 5/26/2012 6:46 PM, Phillip Hallam-Baker wrote: >> It is much more important for a spam filter to ensure that all=20 >> legitimate mail is delivered than to ensure that no spam gest through.=20 >> Setting the criticality bit ensures that about 20% of users will get a=20 >> false positive rejection of the cert. >>=20 >> A false positive rate of even 1% is unacceptable. >=20 > This is a misleading characterization. >=20 > Enforcing the processing of a name constraint extension is more like a=20 > false negative. The cert "should be valid", but the processing software=20 > says "it's not valid", because the criticality bit is enforced when the=20 > extension cannot be processed. That would be a false negative. >=20 > False negatives are sad. A system with a high degree of false negatives=20 > is not usable. Spam filters, of course, have a lot of false negatives. >=20 > But false positives (accepting a certificate when it is widely=20 > recognized to be invalid, such as the ComodoHacker and DigiNotar=20 > incidents) are far worse. I think you got your falses mixed. The terms are taken from medicine, where= a "positive" means "yes, you have cancer", or actually from statistics whe= re the null hypothesis is falsely rejected. In security, a false positive = would be rejecting a certificate that is valid, while a false negative is a= ccepting a certificate that is not valid.= From tim.moses@entrust.com Mon May 28 08:54:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FF321F852A for ; Mon, 28 May 2012 08:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwo+-VA5WCdF for ; Mon, 28 May 2012 08:54:58 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id A7AE621F842B for ; Mon, 28 May 2012 08:54:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,671,1330923600"; d="scan'208";a="5129262" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 28 May 2012 11:54:57 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0283.003; Mon, 28 May 2012 11:54:57 -0400 From: Tim Moses To: Paul Hoffman Thread-Topic: [pkix] CABForum membership Thread-Index: AQHNO6XCvAHidCN4q0WBaJ47Ixv4R5bfXSpI Date: Mon, 28 May 2012 15:54:56 +0000 Message-ID: <0E6721D6-DE17-44BD-8943-6A3543BCE810@entrust.com> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com>, <17826B4A-9734-4186-9781-920F7E3D762F@vpnc.org> In-Reply-To: <17826B4A-9734-4186-9781-920F7E3D762F@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] CABForum membership X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 15:54:59 -0000 Hi Paul. The CABForum is currently in the throes of deciding what role it w= ants to play going forward. I think there has been some misunderstanding of= its current role. The Forum exists to coordinate the views of SSL CAs and = present those views to the PMAs of the secure Web, i.e. the browser/OS supp= liers. The PMAs are free to accept or reject those views and look to other = sources of expertise as they see fit.=20 It has been suggested that the Forum take on a broader mandate, and/or act = as a conduit for other experts. These suggestions are currently under consi= deration. And, during this period of consideration, its positions and proce= dures may seem a bit uncoordinated. For that, I offer my apologies. We want= to get through this transition period as fast as possible, and make sure t= hat we can be effective in whatever new role we choose. =20 It is my hope and expectation that the future Forum will adopt a degree of = openness well suited to its new role.=20 All the best. Tim.=20 On May 26, 2012, at 9:12 PM, "Paul Hoffman" wrote: > The CABForum is a major user of the specs from this WG, so participation = there seems on-topic for this mailing list, at least for a bit. >=20 > On May 26, 2012, at 3:06 PM, Phillip Hallam-Baker wrote: >=20 >> Anyone who agrees to the IPR policy can participate in CABForum >=20 > Is that true? I see no mention of that rule on the CABForum web page. Fur= ther, I see no mention of the current members or its leadership. >=20 >> CABforum is considerably more open in its governance than IETF. >=20 > That's good to hear, but hard to verify. Where are the CABForum's governa= nce rules listed? Where is its leadership listed? >=20 > (FWIW, these questions aren't aimed at Phill. Anyone from the CABForum is= welcome to educate those of us who can't find the information!) >=20 > --Paul Hoffman >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Mon May 28 11:15:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AD921F8633 for ; Mon, 28 May 2012 11:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sazKoHfDe4vN for ; Mon, 28 May 2012 11:15:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B02121F8623 for ; Mon, 28 May 2012 11:15:45 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q4SIFSJf004303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 May 2012 11:15:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <0E6721D6-DE17-44BD-8943-6A3543BCE810@entrust.com> Date: Mon, 28 May 2012 11:15:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com>, <17826B4A-9734-4186-9781-920F7E3D762F@vpnc.org> <0E6721D6-DE17-44BD-8943-6A3543BCE810@entrust.com> To: Tim Moses X-Mailer: Apple Mail (2.1278) Cc: IETF PKIX Subject: Re: [pkix] CABForum membership X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 18:15:46 -0000 Thanks, Tim, that's good to hear. But that doesn't answer my questions = from below. Can "anyone who agrees to the IPR policy can participate in = CABForum"? Is the CABforum "considerably more open in its governance = than IETF"? --Paul Hoffman On May 28, 2012, at 8:54 AM, Tim Moses wrote: > Hi Paul. The CABForum is currently in the throes of deciding what role = it wants to play going forward. I think there has been some = misunderstanding of its current role. The Forum exists to coordinate the = views of SSL CAs and present those views to the PMAs of the secure Web, = i.e. the browser/OS suppliers. The PMAs are free to accept or reject = those views and look to other sources of expertise as they see fit.=20 >=20 > It has been suggested that the Forum take on a broader mandate, and/or = act as a conduit for other experts. These suggestions are currently = under consideration. And, during this period of consideration, its = positions and procedures may seem a bit uncoordinated. For that, I offer = my apologies. We want to get through this transition period as fast as = possible, and make sure that we can be effective in whatever new role we = choose. =20 >=20 > It is my hope and expectation that the future Forum will adopt a = degree of openness well suited to its new role.=20 >=20 > All the best. Tim.=20 >=20 > On May 26, 2012, at 9:12 PM, "Paul Hoffman" = wrote: >=20 >> The CABForum is a major user of the specs from this WG, so = participation there seems on-topic for this mailing list, at least for a = bit. >>=20 >> On May 26, 2012, at 3:06 PM, Phillip Hallam-Baker wrote: >>=20 >>> Anyone who agrees to the IPR policy can participate in CABForum >>=20 >> Is that true? I see no mention of that rule on the CABForum web page. = Further, I see no mention of the current members or its leadership. >>=20 >>> CABforum is considerably more open in its governance than IETF. >>=20 >> That's good to hear, but hard to verify. Where are the CABForum's = governance rules listed? Where is its leadership listed? >>=20 >> (FWIW, these questions aren't aimed at Phill. Anyone from the = CABForum is welcome to educate those of us who can't find the = information!) From tim.moses@entrust.com Mon May 28 11:42:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE68021F869A for ; Mon, 28 May 2012 11:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFHafvr+Hpxc for ; Mon, 28 May 2012 11:42:28 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2362C21F8697 for ; Mon, 28 May 2012 11:42:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,672,1330923600"; d="scan'208";a="1052852" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 28 May 2012 14:42:27 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0283.003; Mon, 28 May 2012 14:42:27 -0400 From: Tim Moses To: 'Paul Hoffman' Thread-Topic: [pkix] CABForum membership Thread-Index: AQHNO6XCvAHidCN4q0WBaJ47Ixv4R5bfXSpIgABqUAD//79xcA== Date: Mon, 28 May 2012 18:42:26 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C02E945@SOTTEXCH10.corp.ad.entrust.com> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> <177611008030645534@unknownmsgid> <0055F66D-0A32-4205-AF9C-3AC206A50E4D@vigilsec.com> <1A1CE5FE-2B93-49B6-B2E0-46165AC0E1A3@gmail.com>, <17826B4A-9734-4186-9781-920F7E3D762F@vpnc.org> <0E6721D6-DE17-44BD-8943-6A3543BCE810@entrust.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] CABForum membership X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 18:42:29 -0000 Paul - I don't want to get into a comparison. But, I can tell you that, as= befits its current mandate, voting membership is limited to representative= s of SSL CAs and root-program operators. Within those groups there are no = restrictions except an acceptance of the IPR policy. All technical issues = are decided by ballot amongst voting members. The Forum has also extended observer status to experts in the auditing comm= unity, and certificate subscriber community. We recently started distributing meeting agendas and minutes on a publicly-= readable mail list. The Forum does the bulk of its work in bi-weekly teleconferences and, as a = no-fee organization, and as a matter of economics, it is not at present pos= sible to accept more than 30 or so participants in that setting. Commonly,= participation levels are in the range 20-30. In case anyone were so motivated, both the PKIX and Mozilla dev-sec-pol lis= ts would be effective places to express opinions about the Forum and its wo= rk products. As mentioned previously, this is all in a state of flux. Ask me again at t= he end of the summer and I expect I will give a quite different answer. All the best. Tim. -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Monday, May 28, 2012 2:15 PM To: Tim Moses Cc: IETF PKIX Subject: Re: [pkix] CABForum membership Thanks, Tim, that's good to hear. But that doesn't answer my questions from= below. Can "anyone who agrees to the IPR policy can participate in CABForu= m"? Is the CABforum "considerably more open in its governance than IETF"? --Paul Hoffman On May 28, 2012, at 8:54 AM, Tim Moses wrote: > Hi Paul. The CABForum is currently in the throes of deciding what role it= wants to play going forward. I think there has been some misunderstanding = of its current role. The Forum exists to coordinate the views of SSL CAs an= d present those views to the PMAs of the secure Web, i.e. the browser/OS su= ppliers. The PMAs are free to accept or reject those views and look to othe= r sources of expertise as they see fit.=20 >=20 > It has been suggested that the Forum take on a broader mandate, and/or ac= t as a conduit for other experts. These suggestions are currently under con= sideration. And, during this period of consideration, its positions and pro= cedures may seem a bit uncoordinated. For that, I offer my apologies. We wa= nt to get through this transition period as fast as possible, and make sure= that we can be effective in whatever new role we choose. =20 >=20 > It is my hope and expectation that the future Forum will adopt a degree o= f openness well suited to its new role.=20 >=20 > All the best. Tim.=20 >=20 > On May 26, 2012, at 9:12 PM, "Paul Hoffman" wrote= : >=20 >> The CABForum is a major user of the specs from this WG, so participation= there seems on-topic for this mailing list, at least for a bit. >>=20 >> On May 26, 2012, at 3:06 PM, Phillip Hallam-Baker wrote: >>=20 >>> Anyone who agrees to the IPR policy can participate in CABForum >>=20 >> Is that true? I see no mention of that rule on the CABForum web page. Fu= rther, I see no mention of the current members or its leadership. >>=20 >>> CABforum is considerably more open in its governance than IETF. >>=20 >> That's good to hear, but hard to verify. Where are the CABForum's govern= ance rules listed? Where is its leadership listed? >>=20 >> (FWIW, these questions aren't aimed at Phill. Anyone from the CABForum i= s welcome to educate those of us who can't find the information!) From James.H.Manger@team.telstra.com Mon May 28 16:26:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1EE21F8717 for ; Mon, 28 May 2012 16:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOcV4SMKu0xz for ; Mon, 28 May 2012 16:26:01 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7688621F8715 for ; Mon, 28 May 2012 16:26:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,674,1330866000"; d="scan'208";a="75547728" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 29 May 2012 09:26:00 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6725"; a="65044120" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcdvi.tcif.telstra.com.au with ESMTP; 29 May 2012 09:25:57 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Tue, 29 May 2012 09:25:59 +1000 From: "Manger, James H" To: Rob Stradling , IETF PKIX Date: Tue, 29 May 2012 09:25:58 +1000 Thread-Topic: [pkix] Integrated OCSP Responders / Key Usage bits Thread-Index: Ac08u5F2RJ97RN90Tviyc/Sok5xwXAAbROiA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4D32BC7@WSMSG3153V.srv.dir.telstra.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <004901cd3b14$6b0951d0$411bf570$@eu> <352AF057-71DE-4895-8630-C81188EE2228@vigilsec.com> <4FC35175.80604@comodo.com> In-Reply-To: <4FC35175.80604@comodo.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 23:26:02 -0000 > X.509 (2008/05) says... > "digitalSignature: for verifying digital signatures that are used with=20 > an entity authentication service, a data origin authentication service=20 > and/or an integrity service;" > > Is OCSP... > 1. "an entity authentication service"? > 2. "a data origin authentication service"? > 3. "an integrity service"? > 4. More than 1 of the above? > 5. None of the above? #2. OCSP is a data origin authentication service. The signature on an OCSP response authenticates the origin of the status da= ta. -- James Manger From rob.stradling@comodo.com Tue May 29 01:24:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2A021F877E for ; Tue, 29 May 2012 01:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toijSB3EDwPs for ; Tue, 29 May 2012 01:24:14 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6E421F8754 for ; Tue, 29 May 2012 01:24:13 -0700 (PDT) Received: (qmail 26478 invoked from network); 29 May 2012 08:24:11 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 29 May 2012 08:24:11 -0000 Received: (qmail 32595 invoked by uid 1000); 29 May 2012 08:24:11 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 29 May 2012 09:24:11 +0100 Message-ID: <4FC487AB.6000603@comodo.com> Date: Tue, 29 May 2012 09:24:11 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: pkix@ietf.org References: <4FBF4B37.1090208@comodo.com> In-Reply-To: <4FBF4B37.1090208@comodo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 08:24:15 -0000 On 25/05/12 10:04, Rob Stradling wrote: > Which Key Usage bits (if any) are required to be present in a CA > Certificate that directly signs OCSP Responses? > IMHO, it'd kinda make sense for the cRLSign bit to govern whether or not > the CA Certificate can directly sign OCSP Responses, but sadly I can > find no text to support this idea. I've unearthed some text to support this idea, so at least I'm now sure I didn't completely make it up myself! RFC2459 said... "The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information (e.g., a CRL)." "The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than...revocation information signing (bit 6)." Obviously an OCSP Response's signature is "a signature on revocation information". Why did RFC3280 change the required bit for signing non-CRL revocation information from "cRLSign" to "digitalSignature"? Could we change it back, or at least allow either "cRLSign" or "digitalSignature" to be deemed acceptable for signing non-CRL revocation information? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From ryan-ietftls@sleevi.com Fri May 25 19:03:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18AA11E807F for ; Fri, 25 May 2012 19:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH+0GBdDp6Mh for ; Fri, 25 May 2012 19:03:08 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id DA05011E8087 for ; Fri, 25 May 2012 19:03:08 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 8B72B31805C; Fri, 25 May 2012 19:03:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= sleevi.com; b=cH0iICJ+f/y33bZf05nxaVKY2n5Zrx74K55Vhnyuw8SppsEuXM 6wK9IvcUU8/j54maL62tWez3anZ8x0QfxUkxw8XwjTEY6F2PA/P50vjj62YQZK/I nFf5rYz08NyMGR0sXW744CThwKGoU6teqNIZm/XU/1lCJPceLAPADcKLo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=VU5kcGND/MDZWpydvJVKYzlS8Wg=; b=nEe1EGxrJNSCQnwCD oFvfPzqMPUWKtFTLwQ1Wb+2jzklKJX93B8XWKbhXknMTycXD+4pQ1qgiYN/hxQDj UIhXYik0rMJfvpiTbsuM1qLZIq/vw8cT9oRHZn5BvUTFqTni78F4Hpi6qF59YvPl ki1UQq5++AKIEQAK4zZ125iq5k= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 3772E318058; Fri, 25 May 2012 19:03:08 -0700 (PDT) Received: from 216.239.45.4 (proxying for 216.239.45.4) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 25 May 2012 19:03:08 -0700 Message-ID: <658b865f798ab84d66d07ab160d701ec.squirrel@webmail.dreamhost.com> In-Reply-To: <20120525195811.9519A21F87C1@ietfa.amsl.com> References: <20120525195811.9519A21F87C1@ietfa.amsl.com> Date: Fri, 25 May 2012 19:03:08 -0700 From: "Ryan Sleevi" To: "Michael StJohns" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 29 May 2012 07:12:57 -0700 Cc: pkix@ietf.org Subject: Re: [pkix] NameConstraints criticality flag X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 02:03:09 -0000 > I hesitate to respond to this, but my review of the bidding is not tha= t > there wasn't a conclusion, but that there was no consensus for change. > > I think I support the status quo. > > > Assuming a "Root CA -> CA with Name Constraint -> End Entity certifica= te > chain" there are three degrees of freedom: 1) Whether the NC is marke= d > critical, 2) whether the EE certificate has a name compliant with the = NC, > and 3) whether the RP understands the NC extension. > > The combinations are thus: > > Critical/Compliant/Understands - > Accepts the cert > Critical/Compliant/Does not understand -> Rejects the cert **** > Critical/Non-Compliant/Understands -> Rejects the cert > Critical/Non-Compliant/Does not understand -> Rejects the cert > Non-Critical/Compliant/Understands -> Accepts the cert > Non-Critical/Compliant/Does not understand -> Accepts the cert > Non-Critical/Non-Compliant/Understands -> Rejects the cert > Non-Critical/Non-Compliant/Does not understand -> Accepts the cert. *= *** This last behaviour, which you identify as the "wrong" thing happening, i= s realistically a policy decision, and one that should be dealt with by the respective CA and their policies. So rather than the "wrong thing", it's the exact same thing as the "No NC Present" case. Same result - so for CAs, this is the RIGHT thing, because it has no discernable behaviour change for clients in the "Non-Critical/Non-Compliant/Does not understand" case from the effective "No NC Present", while it IMPROVES the situation for the "Non-Critical/Non-Compliant/Understands" case. The current state of the industry is that no public CA issuing public certificates for use on the Internet wants to use name constraints, because they present a compatibility issue. CAs therefore choose to issue unconstrained CAs, which are accepted by clients, and rather than technical measures, attempt to use procedural/contractual/legal measures to constrain the CA. As Phil has pointed out, this is undesirable for browser vendors and othe= r RPs, because there is no programatic awareness of whatever the procedural or contractual constraints may be between the two CAs, therefore it's not possible to detect violations of policy. For a CA that wishes to programatically enforce NC as policy: - Mark the extension as critical, and it will be processed as such. For a CA that wishes to programatically /advertise/ NC: - Mark the extension as non-critical. Compliant implementations will process or reject. Non-compliant implementations will treat it as if there was no NC present. > > (There is one other combination - no NC present -> Accepts the cert) > > The two items marked with **** are combinations where possibly the "wr= ong" > thing happened. The first one is just due to the implementation at th= e RP > not being complete enough, but complies with the policy imposed on the= NC > CA by the root. The second is due to a violation of policy - the NC C= A > was able to issue a certificate with a name that violated the name > constraints imposed upon it by the root CA and have it accepted by an = RP > that didn't understand the NC extension. > > You also end up with a situation where a "GOOD" RP (one that understan= ds > the NC), ends up rejecting the certificate - which is probably not wha= t > you wanted. > > Phil - you're proposing a change which is the equivalent of posting a > guard at the door to a building and requiring the guard to reject bad > badges if they are offered, but allowing anyone who doesn't present a > badge to enter the building. > > If the Root CA doesn't care about enforceable name constraints, it > probably shouldn't include them in the NC CA certificate. If it wants > them to be enforced, then the NC extension needs to be marked critical= . > > And on a last topic. I'm finding the arm twisting a bit distasteful. = If > the CAB forum wants to pick its marbles and leave, just do it and stop > trying to coerce the process. > > Mike > > > > > At 12:47 PM 5/25/2012, Phillip Hallam-Baker wrote: > >The issue was discussed here earlier without a conclusion. I just want= ed > > to point out that the issue is currently the subject of a ballot in > > CABForum: > > > >http://cabf= orum.org/pipermail/public/2012-May/000027.html > > > >Delete the following text from the "Subordinate CA Certificate" sectio= n > > of both the Baseline Requirements Appendix B and EV Guidelines Append= ix > > B: > >"All other fields and extensions MUST be set in accordance to RFC 5280= ." > >AND replace it with the following: > >"F. nameConstraints (optional) > >. If present, this extension SHOULD be marked critical*. > >All other fields and extensions MUST be set in accordance to RFC 5280. > >* Non-critical Name Constraints are an exception to RFC 5280 that MAY = be > > used until the Name Constraints extension is supported by Application > > Software Suppliers whose software is used by a substantial portion of > > Relying Parties worldwide." > > > > > >Anyone who wants to follow the ballot discussion can do so at: > >http://cabforum.org/mailm= an/listinfo/public > > > >The reason this change is being considered is as follows: > > > >1) Deployment of name constraints without a criticality flag provides = an > > immediate an advantageous reduction in risk without impact on any > > deployed systems. > > > >2) Deployment of name constraints with a criticality flag would entail= an > > unacceptable incompatibility with widely deployed systems. > > > >3) None of the following reasons advanced for requiring name constrain= ts > > to be marked critical has been found to be persuasive: > > > >3a) 'Critical means important' - no it does not, clients are required = to > > process extensions that they understand regardless of whether they ar= e > > marked critical or not. > > > >3b) 'This is not a requirement for the DoD' - this is not about the Do= D > > PKI. > > > >3c) 'People should deploy RFC 5280 compliant systems rather than chang= e > > the spec' - This is not a normative argument. People should live in > > brotherly peace and harmony too but the fact that they don't is the > > reason we need PKI in the first place. > > > >This change has been considered by a group of experts whose credential= s > > and experience in the PKI space is at least equal to that of this WG.= So > > please, no appeals to authority. > > > > > >Should this ballot pass, I will submit an ID to propose making the sam= e > > change to RFC5280 as an erratum. In my personal view, it is clearly > > desirable for the IETF specifications to track the deployed > > specification. > > > >-- > >Website: http://hallambaker.com/ > > > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From david.cooper@nist.gov Tue May 29 08:15:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9921F8541 for ; Tue, 29 May 2012 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJzZkA2S2NhA for ; Tue, 29 May 2012 08:15:02 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF3621F851C for ; Tue, 29 May 2012 08:15:01 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 29 May 2012 11:14:44 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Tue, 29 May 2012 11:13:29 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q4TFEvk0022876; Tue, 29 May 2012 11:14:58 -0400 Message-ID: <4FC4E7F1.3070908@nist.gov> Date: Tue, 29 May 2012 11:14:57 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120426 Thunderbird/12.0 MIME-Version: 1.0 To: Russ Housley References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> In-Reply-To: <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 15:15:03 -0000 Russ,

I occurred to me over the weekend that there is another reason not to include an extended key usage extension in the certificate in the case of an integrated OCSP responder.  Consider the following scenario of a subordinate CA that acts an an integrated OCSP responder with the certificate issued by the root CA to the subordinate CA containing keyUsage and extended key usage extensions as you suggest:

+----------------+
|    Root CA     |
+----------------+
      |
      |  keyUsage: keyCertSign, cRLSign, digitalSignature
      |  extKeyUsage: id-kp-OCSPSigning, ...
      |
     \/

+----------------+   
| subordinate CA |
+----------------+

As you noted, RFC 2560 does not require the extended key usage extension to be present in order for the subordinate CA to sign OCSP responses for its own certificates.  However, according to RFC 2560, by including the extended key usage extension with id-kp-OCSPSigning, the root CA is indicating to relying parties that the subordinate CA is authorized to act as a designated OCSP responder for the root CA.  So, this would make the subordinate CA authorized to provide status information for certificates issued by the root CA, even though the intention was only to indicate that it was authorized to provide status information for its own certificates.

Dave

On 05/25/2012 12:54 PM, Russ Housley wrote:
Denis:

I think my reply to David is consistent with your analysis.  My first reply was incorrect; the digitalSignature key usage bit needs to be set.

My summary:
Since the CA issues certificates, the keyCertSign bit MUST be set. 
Since the CA issues CRLs, the cRLSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set, and
    the id-kp-OCSOSigning OID MAY be present. 

I think including the id-kp-OCSOSigning OID is desirable.  It indicates the intention to sign OCSP responses even though it is not require by RFC 2560.

Russ


On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote:

Russ,

I raised the question in my presentation on OCSP during the last PKIX session in Paris,
since there is currently no answer in the PKIX documents.


I don't believe that your response is correct.

The id-kp-OCSPSigning object identifier is only for a designated OCSP responder.
This is not the case we are considering in this discussion.


RFC 2560 states: "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate".


Ideally, we should have added an OCSP signing bit in the key usage bits, but unfortunately
nobody raised the point when we built RFC 2560.


Rob mentioned the (relatively recently published) CABForum Baseline Requirements
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate CA Private Key is used for signing OCSP responses, then
the digitalSignature bit MUST be set."


I don't believe that this response is correct either, since in the general case an upper CA
does not sign OCSP responses for a lower CA.


Let me propose a strawman:

The keyCertSign bit and the digitalSignature bit MUST be set.
The cRLSign bit MAY be set.

A few explanations are needed.
Since the CA issues certificates, the keyCertSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set.
If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST be set,
otherwise it MUST NOT be set.


Let us now suppose that a CA starts to issue CRLs and that, later on, the CA wants to issue OCSP responses.
With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since
the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.


Note: Any proposal will break some eggs and make an omelet, since, without guidance, implementers did "something".
        What is strange is that OCSP currently works !
        I would guess most implementations only test the keyCertSign bit.

Denis



De :        Russ Housley <housley@vigilsec.com>
A :        Rob Stradling <rob.stradling@comodo.com>
Cc :        pkix@ietf.org
Date :        25/05/2012 17:50
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoyé par :        pkix-bounces@ietf.org




Rob:

> Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses?  If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix



From housley@vigilsec.com Tue May 29 09:25:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855AA11E8081 for ; Tue, 29 May 2012 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.668 X-Spam-Level: X-Spam-Status: No, score=-102.668 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzDxnASW8oee for ; Tue, 29 May 2012 09:25:22 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0390011E8073 for ; Tue, 29 May 2012 09:25:22 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id A88C7F24037; Tue, 29 May 2012 12:25:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id PqCgiwRtzqff; Tue, 29 May 2012 12:25:18 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-161.washdc.fios.verizon.net [96.255.37.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E75B8F24025; Tue, 29 May 2012 12:25:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-127--775733368 From: Russ Housley In-Reply-To: <4FC4E7F1.3070908@nist.gov> Date: Tue, 29 May 2012 12:25:19 -0400 Message-Id: <5228CC26-049B-4909-B1C5-8A9C4444111F@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> <4FC4E7F1.3070908@nist.gov> To: "David A. Cooper" X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 16:25:23 -0000 --Apple-Mail-127--775733368 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 David: This is a very good point. This would authorize every subordinate CA to = sign OCSP responses on behalf of the Root CA. This indeed a serious = side effect. Thanks for sharing. My revised summary: Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA issues CRLs, the cRLSign bit MUST be set. Since the CA signs OCSP responses, the digitalSignature bit MUST be set.=20= Russ On May 29, 2012, at 11:14 AM, David A. Cooper wrote: > Russ, >=20 > I occurred to me over the weekend that there is another reason not to = include an extended key usage extension in the certificate in the case = of an integrated OCSP responder. Consider the following scenario of a = subordinate CA that acts an an integrated OCSP responder with the = certificate issued by the root CA to the subordinate CA containing = keyUsage and extended key usage extensions as you suggest: >=20 > +----------------+ > | Root CA | > +----------------+ > | > | keyUsage: keyCertSign, cRLSign, digitalSignature > | extKeyUsage: id-kp-OCSPSigning, ... > | > \/ > +----------------+ =20 > | subordinate CA | > +----------------+ >=20 > As you noted, RFC 2560 does not require the extended key usage = extension to be present in order for the subordinate CA to sign OCSP = responses for its own certificates. However, according to RFC 2560, by = including the extended key usage extension with id-kp-OCSPSigning, the = root CA is indicating to relying parties that the subordinate CA is = authorized to act as a designated OCSP responder for the root CA. So, = this would make the subordinate CA authorized to provide status = information for certificates issued by the root CA, even though the = intention was only to indicate that it was authorized to provide status = information for its own certificates. >=20 > Dave >=20 > On 05/25/2012 12:54 PM, Russ Housley wrote: >>=20 >> Denis: >>=20 >> I think my reply to David is consistent with your analysis. My first = reply was incorrect; the digitalSignature key usage bit needs to be set. >>=20 >> My summary: >> Since the CA issues certificates, the keyCertSign bit MUST be set.=20 >> Since the CA issues CRLs, the cRLSign bit MUST be set. >> Since the CA signs OCSP responses, the digitalSignature bit MUST be = set, and >> the id-kp-OCSOSigning OID MAY be present.=20 >>=20 >> I think including the id-kp-OCSOSigning OID is desirable. It = indicates the intention to sign OCSP responses even though it is not = require by RFC 2560. >>=20 >> Russ >>=20 >>=20 >> On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote: >>=20 >>> Russ,=20 >>>=20 >>> I raised the question in my presentation on OCSP during the last = PKIX session in Paris,=20 >>> since there is currently no answer in the PKIX documents.=20 >>>=20 >>> I don't believe that your response is correct.=20 >>>=20 >>> The id-kp-OCSPSigning object identifier is only for a designated = OCSP responder.=20 >>> This is not the case we are considering in this discussion.=20 >>>=20 >>> RFC 2560 states: "OCSP signing delegation SHALL be designated by the = inclusion of id-kp-OCSPSigning=20 >>> in an extendedKeyUsage certificate extension included in the OCSP = response signer's certificate".=20 >>>=20 >>> Ideally, we should have added an OCSP signing bit in the key usage = bits, but unfortunately=20 >>> nobody raised the point when we built RFC 2560.=20 >>>=20 >>> Rob mentioned the (relatively recently published) CABForum Baseline = Requirements=20 >>> document which says: "Bit positions for keyCertSign and cRLSign MUST = be set. =20 >>> If the Root/Subordinate CA Private Key is used for signing OCSP = responses, then=20 >>> the digitalSignature bit MUST be set." >>>=20 >>> I don't believe that this response is correct either, since in the = general case an upper CA=20 >>> does not sign OCSP responses for a lower CA.=20 >>>=20 >>> Let me propose a strawman:=20 >>>=20 >>> The keyCertSign bit and the digitalSignature bit MUST be set.=20 >>> The cRLSign bit MAY be set.=20 >>>=20 >>> A few explanations are needed.=20 >>> Since the CA issues certificates, the keyCertSign bit MUST be set.=20= >>> Since the CA signs OCSP responses, the digitalSignature bit MUST be = set.=20 >>> If the CA issues both CRLs and OCSP Responses, then the cRLSign bit = MUST be set,=20 >>> otherwise it MUST NOT be set.=20 >>>=20 >>> Let us now suppose that a CA starts to issue CRLs and that, later = on, the CA wants to issue OCSP responses.=20 >>> With this strawman proposal, the CA must obtain a new certificate = from its upper CA. This makes sense since=20 >>> the Certification Policy has changed and the upper CA has the right = to verify the practices of its child CA.=20 >>>=20 >>> Note: Any proposal will break some eggs and make an omelet, since, = without guidance, implementers did "something".=20 >>> What is strange is that OCSP currently works !=20 >>> I would guess most implementations only test the keyCertSign = bit.=20 >>>=20 >>> Denis=20 >>>=20 >>>=20 >>>=20 >>> De : Russ Housley =20 >>> A : Rob Stradling =20 >>> Cc : pkix@ietf.org=20 >>> Date : 25/05/2012 17:50=20 >>> Objet : Re: [pkix] Integrated OCSP Responders / Key Usage = bits=20 >>> Envoy=E9 par : pkix-bounces@ietf.org=20 >>>=20 >>>=20 >>>=20 >>> Rob: >>>=20 >>> > Which Key Usage bits (if any) are required to be present in a CA = Certificate that directly signs OCSP Responses? >>>=20 >>> Do you mean that the same private key is used by the CA to sign = certificates, CRLs, and OCSP Responses? If so, I would expect the CA = certificate that contains the corresponding public key to include the = key usage and the extended key usage extensions. The key usage = extension should have at least the keyCertSign and the cRLSign bits set. = The extended key usage extension should include at least the = id-kp-OCSPSigning object identifier. >>>=20 >>> Russ >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>>=20 >>=20 >=20 --Apple-Mail-127--775733368 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
=20 =20
Russ,

I occurred to me over the weekend that there is another reason not to include an extended key usage extension in the certificate in the case of an integrated OCSP responder.  Consider the following scenario of a subordinate CA that acts an an integrated OCSP responder with the certificate issued by the root CA to the subordinate CA containing keyUsage and extended key usage extensions as you suggest:

+----------------+
|    Root CA     |
+----------------+
      |
      |  keyUsage: keyCertSign, cRLSign, = digitalSignature
      |  extKeyUsage: = id-kp-OCSPSigning, ...
      |
     \/

+----------------+   
| subordinate CA |
+----------------+

As you noted, RFC 2560 does not require the extended key usage extension to be present in order for the subordinate CA to sign OCSP responses for its own certificates.  However, according to RFC = 2560, by including the extended key usage extension with id-kp-OCSPSigning, the root CA is indicating to relying parties that the subordinate CA is authorized to act as a designated OCSP responder for the root CA.  So, this would make the subordinate = CA authorized to provide status information for certificates issued by the root CA, even though the intention was only to indicate that it was authorized to provide status information for its own certificates.

Dave

On 05/25/2012 12:54 PM, Russ Housley wrote:
Denis:

I think my reply to David is consistent with your analysis.  My first reply was incorrect; the digitalSignature key = usage bit needs to be set.

My summary:
Since the CA issues certificates, the keyCertSign bit MUST be set. 
Since the CA issues CRLs, the cRLSign bit MUST be = set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set, and
    the id-kp-OCSOSigning OID MAY be = present. 

I think including the id-kp-OCSOSigning OID is = desirable.  It indicates the intention to sign OCSP responses even though it is not require by RFC 2560.

Russ


On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote:

Russ,

I raised the question in my presentation on OCSP during the last PKIX session in Paris,
since there is currently no answer in the PKIX = documents.


I don't believe that your response is correct.

The id-kp-OCSPSigning object identifier is only for a designated OCSP responder.
This is not the case we are considering in this discussion.


RFC 2560 states: "OCSP = signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate".


Ideally, we should have = added an OCSP signing bit in the key usage bits, but unfortunately
nobody raised the point when we built RFC 2560.


Rob mentioned the = (relatively recently published) CABForum Baseline Requirements
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate CA Private Key is used for signing OCSP responses, then
the digitalSignature bit MUST be set."


I don't believe that this response is correct either, since in the general case an upper CA
does not sign OCSP responses for a lower CA.


Let me propose a = strawman:

The keyCertSign bit and the digitalSignature bit MUST be set.
The cRLSign bit MAY be = set.

A few explanations are = needed.
Since the CA issues certificates, the keyCertSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set.
If the CA issues both CRLs = and OCSP Responses, then the cRLSign bit MUST be set,
otherwise it MUST NOT be set.


Let us now suppose that a CA starts to issue CRLs and that, later on, the CA wants to issue OCSP responses.
With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since
the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.


Note: Any proposal will = break some eggs and make an omelet, since, without guidance, implementers did "something".
        = What is strange is that OCSP currently works !
        = I would guess most implementations only test the keyCertSign bit. =

Denis



De : =        Russ = Housley <housley@vigilsec.com>
A : =        Rob = Stradling <rob.stradling@comodo.com><= /font>
Cc :        pkix@ietf.org
Date = :        25/05/2012= 17:50
Objet = :        Re:= [pkix] Integrated OCSP Responders / Key Usage bits
Envoy=E9= par :        pkix-bounces@ietf.org




Rob:

> Which Key Usage bits (if any) are required to be present in a CA Certificate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign certificates, CRLs, and OCSP Responses?  If so, I would expect = the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ



_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix<= font size=3D"2">




= --Apple-Mail-127--775733368-- From denis.pinkas@bull.net Tue May 29 23:38:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199E121F866A for ; Tue, 29 May 2012 23:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj-o1Buyrv9s for ; Tue, 29 May 2012 23:38:27 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8D98621F8650 for ; Tue, 29 May 2012 23:38:26 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id B244918171; Wed, 30 May 2012 08:38:24 +0200 (CEST) In-Reply-To: <5228CC26-049B-4909-B1C5-8A9C4444111F@vigilsec.com> References: <4FBF4B37.1090208@comodo.com> <08E3848C-637D-4452-A8F4-6CF14FE26685@vigilsec.com> <85EA54F3-32F9-4EF1-BAC9-24738F6B5A81@vigilsec.com> <4FC4E7F1.3070908@nist.gov> <5228CC26-049B-4909-B1C5-8A9C4444111F@vigilsec.com> To: Russ Housley MIME-Version: 1.0 X-KeepSent: 724D9696:A5B3E24F-C1257A0E:00242541; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 30 May 2012 08:38:24 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 30/05/2012 08:38:24, Serialize complete at 30/05/2012 08:38:24 Content-Type: multipart/alternative; boundary="=_alternative 00245177C1257A0E_=" Cc: IETF PKIX Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 06:38:28 -0000 Message en plusieurs parties au format MIME --=_alternative 00245177C1257A0E_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Russ, We are now in strong agreement.=20 Denis De : Russ Housley A : "David A. Cooper" Cc : IETF PKIX Date : 29/05/2012 18:25 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits Envoy=E9 par : pkix-bounces@ietf.org David: This is a very good point. This would authorize every subordinate CA to=20 sign OCSP responses on behalf of the Root CA. This indeed a serious side=20 effect. Thanks for sharing. My revised summary: Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA issues CRLs, the cRLSign bit MUST be set. Since the CA signs OCSP responses, the digitalSignature bit MUST be set.=20 Russ On May 29, 2012, at 11:14 AM, David A. Cooper wrote: Russ, I occurred to me over the weekend that there is another reason not to=20 include an extended key usage extension in the certificate in the case of=20 an integrated OCSP responder. Consider the following scenario of a=20 subordinate CA that acts an an integrated OCSP responder with the=20 certificate issued by the root CA to the subordinate CA containing=20 keyUsage and extended key usage extensions as you suggest: +----------------+ | Root CA | +----------------+ | | keyUsage: keyCertSign, cRLSign, digitalSignature | extKeyUsage: id-kp-OCSPSigning, ... | \/ +----------------+=20 | subordinate CA | +----------------+ As you noted, RFC 2560 does not require the extended key usage extension=20 to be present in order for the subordinate CA to sign OCSP responses for=20 its own certificates. However, according to RFC 2560, by including the=20 extended key usage extension with id-kp-OCSPSigning, the root CA is=20 indicating to relying parties that the subordinate CA is authorized to act = as a designated OCSP responder for the root CA. So, this would make the=20 subordinate CA authorized to provide status information for certificates=20 issued by the root CA, even though the intention was only to indicate that = it was authorized to provide status information for its own certificates. Dave On 05/25/2012 12:54 PM, Russ Housley wrote:=20 Denis:=20 I think my reply to David is consistent with your analysis. My first=20 reply was incorrect; the digitalSignature key usage bit needs to be set. My summary: Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA issues CRLs, the cRLSign bit MUST be set. Since the CA signs OCSP responses, the digitalSignature bit MUST be set,=20 and the id-kp-OCSOSigning OID MAY be present.=20 I think including the id-kp-OCSOSigning OID is desirable. It indicates=20 the intention to sign OCSP responses even though it is not require by RFC=20 2560. Russ On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote: Russ,=20 I raised the question in my presentation on OCSP during the last PKIX=20 session in Paris,=20 since there is currently no answer in the PKIX documents.=20 I don't believe that your response is correct.=20 The id-kp-OCSPSigning object identifier is only for a designated OCSP=20 responder.=20 This is not the case we are considering in this discussion.=20 RFC 2560 states: "OCSP signing delegation SHALL be designated by the=20 inclusion of id-kp-OCSPSigning=20 in an extendedKeyUsage certificate extension included in the OCSP response = signer's certificate".=20 Ideally, we should have added an OCSP signing bit in the key usage bits,=20 but unfortunately=20 nobody raised the point when we built RFC 2560.=20 Rob mentioned the (relatively recently published) CABForum Baseline=20 Requirements=20 document which says: "Bit positions for keyCertSign and cRLSign MUST be=20 set.=20 If the Root/Subordinate CA Private Key is used for signing OCSP responses, = then=20 the digitalSignature bit MUST be set." I don't believe that this response is correct either, since in the general = case an upper CA=20 does not sign OCSP responses for a lower CA.=20 Let me propose a strawman:=20 The keyCertSign bit and the digitalSignature bit MUST be set.=20 The cRLSign bit MAY be set.=20 A few explanations are needed.=20 Since the CA issues certificates, the keyCertSign bit MUST be set.=20 Since the CA signs OCSP responses, the digitalSignature bit MUST be set.=20 If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST=20 be set,=20 otherwise it MUST NOT be set.=20 Let us now suppose that a CA starts to issue CRLs and that, later on, the=20 CA wants to issue OCSP responses.=20 With this strawman proposal, the CA must obtain a new certificate from its = upper CA. This makes sense since=20 the Certification Policy has changed and the upper CA has the right to=20 verify the practices of its child CA.=20 Note: Any proposal will break some eggs and make an omelet, since, without = guidance, implementers did "something".=20 What is strange is that OCSP currently works !=20 I would guess most implementations only test the keyCertSign bit.=20 Denis=20 De : Russ Housley =20 A : Rob Stradling =20 Cc : pkix@ietf.org=20 Date : 25/05/2012 17:50=20 Objet : Re: [pkix] Integrated OCSP Responders / Key Usage bits=20 Envoy=E9 par : pkix-bounces@ietf.org=20 Rob: > Which Key Usage bits (if any) are required to be present in a CA=20 Certificate that directly signs OCSP Responses? Do you mean that the same private key is used by the CA to sign=20 certificates, CRLs, and OCSP Responses? If so, I would expect the CA=20 certificate that contains the corresponding public key to include the key=20 usage and the extended key usage extensions. The key usage extension=20 should have at least the keyCertSign and the cRLSign bits set. The=20 extended key usage extension should include at least the id-kp-OCSPSigning = object identifier. Russ =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00245177C1257A0E_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Russ,

We are now in strong agreement.

Denis



De :     &= nbsp;  Russ Housley <housley@vi= gilsec.com>
A :     &n= bsp;  "David A. Cooper" <david.cooper@nist.gov>
Cc :   &nb= sp;    IETF PKIX <pkix@i= etf.org>
Date :    =    29/05/2012 18:25
Objet :        Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g




David:

This is a very good point.  This would authorize every subordinate CA to sign OCSP responses on behalf of the Root CA.  = ;This indeed a serious side effect.  Thanks for sharing.

My revised summary:
Since the CA issues certificates, the keyCertSign bit MUST be set.
Since the CA issues CRLs, the cRLSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set.

Russ


On May 29, 2012, at 11:14 AM, David A. Cooper wrote:

Russ,

I occurred to me over the weekend that there is another reason not to inclu= de an extended key usage extension in the certificate in the case of an integr= ated OCSP responder.  Consider the following scenario of a subordinate CA that acts an an integrated OCSP responder with the certificate issued by the root CA to the subordinate CA containing keyUsage and extended key usage extensions as you suggest:

+----------------+
|    Root CA     |
+----------------+
     |
     |  keyUsage: keyCertSign, cRLSign, digitalSignatu= re
     |  extKeyUsage: id-kp-OCSPSigning, ...
     |
    \/
+----------------+    
| subordinate CA |
+----------------+


As you noted, RFC 2560 does not require the extended key usage extension to be present in order for the subordinate CA to sign OCSP responses for its own certificates.  However, according to RFC 2560, by including the extended key usage extension with id-kp-OCSPSigning, the root CA is indicating to relying parties that the subordinate CA is authorized to act as a designated OCSP responder for the root CA.  So, this would make the subordinate CA authorized to provide status information for certif= icates issued by the root CA, even though the intention was only to indicate that it was authorized to provide status information for its own certificates.
Dave

On 05/25/2012 12:54 PM, Russ Housley wrote:

Denis:

I think my reply to David is consistent with your analys= is.  My first reply was incorrect; the digitalSignature key usage bit needs to be set.

My summary:
Since the CA issues certificates, the keyCertSign bit MUST be set.
Since the CA issues CRLs, the cRLSign bit MUST be set.
Since the CA signs OCSP responses, the digitalSignature bit MUST be set, and
    the id-kp-OCSOSigning OID MAY be present.

I think including the id-kp-OCSOSigning OID is desirable.  It indicates the intention to sign OCSP responses even though it is not require by RFC 2560.

Russ


On May 25, 2012, at 12:31 PM, denis.pinkas@bull.net wrote:

Russ,

I raised the question in my presentation on OCSP during the last PKIX sessi= on in Paris,
since there is currently no answer in the PKIX documents.


I don't believe that your response is correct.


The id-kp-OCSPSigning object identifier is only for a designated OCSP respo= nder.
This is not the case we are considering in this discussion.


RFC 2560 states: "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning
in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate".


Ideally, we should have added an OCSP signing bit in the key usage bits, but unfortunately
nobody raised the point when we built RFC 2560.


Rob mentioned the (relatively recently published) CABForum Baseline Require= ments
document which says: "Bit positions for keyCertSign and cRLSign MUST be set.  
If the Root/Subordinate CA Private Key is used for signing OCSP responses, then
the digitalSignature bit MUST be set."


I don't believe that this response is correct either, since in the general case an upper CA
does not sign OCSP responses for a lower CA.


Let me propose a strawman:


The keyCertSign bit and the digitalSignature bit MUST be set.

The cRLSign bit MAY be set.


A few explanations are needed.
Since the CA issues certificates, the keyCertSign bit MUST be set.

Since the CA signs OCSP responses, the digitalSignature bit MUST be set.
If the CA issues both CRLs and OCSP Responses, then the cRLSign bit MUST be set,
otherwise it MUST NOT be set.


Let us now suppose that a CA starts to issue CRLs and that, later on, the CA wants to issue OCSP responses.
With this strawman proposal, the CA must obtain a new certificate from its upper CA. This makes sense since
the Certification Policy has changed and the upper CA has the right to verify the practices of its child CA.


Note: Any proposal will break some eggs and make an omelet, since, without guidance, implementers did "something".

       What is strange is that OCSP currently works !
       I would guess most implementations only test the keyCertSign bit.


Denis




De :        
R= uss Housley <housley@vigilsec.com>
A :        
Rob Stradling <rob.stradling@comodo.com>
Cc :        
pkix@ietf.org
<= font size=3D3>

Date :        
25/05/2012 17:50
Objet :        
Re: [pkix] Integrated OCSP Responders / Key Usage bits
Envoy=E9 par :        
pkix-boun= ces@ietf.org




Rob:

> Which Key Usage bits (if any) are required to be present in a CA Certi= ficate that directly signs OCSP Responses?

Do you mean that the same private key is used by the CA to sign certificate= s, CRLs, and OCSP Responses?  If so, I would expect the CA certificate that contains the corresponding public key to include the key usage and the extended key usage extensions.  The key usage extension should have at least the keyCertSign and the cRLSign bits set.  The extended key usage extension should include at least the id-kp-OCSPSigning object identifier.

Russ



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list

pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--=_alternative 00245177C1257A0E_=-- From hallam@gmail.com Wed May 30 07:20:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807F011E8091 for ; Wed, 30 May 2012 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcyplmlBp1Qh for ; Wed, 30 May 2012 07:20:47 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1D21F8542 for ; Wed, 30 May 2012 07:20:47 -0700 (PDT) Received: by qabj40 with SMTP id j40so25976qab.15 for ; Wed, 30 May 2012 07:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=1zd5rwBfu+TvuXWT7jptswPHLtbDo8RTZb/Db2Pn0Js=; b=qq3ZtVY9mEv0U0txHlx5z0pQL2Z6RfdR4ufBS0ocyohwvemJsZZdZCt1Z4qfpldQB2 tS7OputqwiN0uPLr31wzKj5jOhSE+1XnL0HFIx1Rhft8GPD3/hWoAx2F4IilyX1gp20K al1UzhYDZGLU/P1v26oezckp3NgsHDKWuGr+yiyjM1Bu4Vctv0S/93p714jETwDEcJsl ADG27+gPBfaNmzskPkl6V3GhbsZ0CQ7PbFbtZigIODpcM50FTw0yEIqyttI6koDC8K2W N2dYGPxn60f/xs+4cwcd6t7DopiuSiDP15nhJQlEpezHtdGHsM2l1NCi8K8EMtZqaQ2j Yspg== Received: by 10.224.196.200 with SMTP id eh8mr16032125qab.88.1338387646763; Wed, 30 May 2012 07:20:46 -0700 (PDT) Received: from [10.64.71.49] (mobile-198-228-206-020.mycingular.net. [198.228.206.20]) by mx.google.com with ESMTPS id x10sm937491qan.1.2012.05.30.07.20.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 May 2012 07:20:45 -0700 (PDT) References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> In-Reply-To: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> X-Mailer: iPad Mail (9B176) From: Phillip Hallam-Baker Date: Wed, 30 May 2012 10:20:34 -0400 To: Yoav Nir Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 14:20:48 -0000 I dont see that either. Commercial CAs now face a mandate from Mozilla that requires them to use Nam= e Constraints. I have a draft of a draft that sets out the required client behavior when en= countering a certificate that is not 5280 compliant with respect to critical= ity setting and the consequences of not setting criticality. Sent from my iPad On May 28, 2012, at 8:38, Yoav Nir wrote: > Hi Santosh >=20 > I don't really see the difference between options 2 and 4. In option #2 we= 're keeping the MUST, but adding language that says that CAs can decide to m= ake it non-critical if certain conditions apply and/or they decide to trade o= ff interoperability for security. IMO this is the very definition of SHOULD >=20 > Yoav >=20 > On May 27, 2012, at 6:09 PM, Santosh Chokhani wrote: >=20 >> I agree with Mike. >>=20 >> In light of the fact we seem to have established positions which we do no= t wish to change, I thought we should see if there are options we could agre= e on. >>=20 >> To that end and since the thread has several sub-threads, I have begun a n= ew thread. >>=20 >> Here are the options that come to my mind. There may be others. >>=20 >> Option 1: Do not change the standard >>=20 >> Option 2: Do not change the standard but add language akin to the followi= ng in an appropriate place in the standard " It is recognized that a CA may w= ish to make the name constraints extension non-critical in order to maximize= interoperability. Such CA shall either use other mechanisms that are not s= pecified in this standard or shall make such a decision based on trading off= increased interoperability and security exposure" >>=20 >> Option 3: Change the standard to make the extension "recommended to be cr= itical for a period of time" This period of time should be short and should= be only made if Opera and Safari decision makers are willing to provide the= support for the extension ASAP in their browsers and maximize updates to th= e current version. We can add the applicable language and revision from Opt= ion 2. I would set this date to be expiry date of CA certificate since revo= cation checking in browsers is uneven. >>=20 >> Option 4: Change the standard to make the extension "recommended to be cr= itical". I would be against it. >>=20 >> May be we could use this or similar method to get a vote on the WG since i= n my opinion no one is saying anything new. >>=20 >> -----Original Message----- >> From: Michael StJohns [mailto:mstjohns@comcast.net]=20 >> Sent: Saturday, May 26, 2012 9:15 PM >> To: ryan-pkix@sleevi.com; Santosh Chokhani >> Cc: IETF PKIX >> Subject: Re: [pkix] NameConstraints criticality flag >>=20 >> At 05:57 PM 5/26/2012, Ryan Sleevi wrote: >>> Any CA who makes NC critical will necessarily prevent these users from=20= >>> accessing any servers whose certificates chain to them. Considering=20 >>> that so much of market position within the CA ecosystem is being able=20= >>> to interoperate with legacy systems, this is a unbearable market=20 >>> penalty for any CA. Considering the first mover penalties are so high,=20= >>> no CA wishing to stay in business would adopt NC. >>=20 >> I keep trying to understand this type of a statement, but it gives me a b= ad case of cognitive dissonance. I'm actually thinking that a critical NC a= nd not being able to access those servers is a good thing and the whole idea= of NC in the first place. >>=20 >> Here's how I imagine an NC would be used. >>=20 >> I'm a company that wants to issue certificates to my servers that chain b= ack to a well known root. I *don't* want to have to do a server by server r= equest to get certificates so I contract with the well known root (WKR) to g= et a CA certificate owned by my company signed. =20 >>=20 >> The WKR has two types of CA signing it will do - the first contains an NC= that constrains me to issue certificates with names that are subordinate to= "mikestjohnscompany.com" and costs X, the second that does not contain an N= C and costs 10 X (mainly because the WKR doesn't want it competing with them= for issuing TLS server certificates for random companies). >>=20 >> If the WKR is only getting X, then the WKR is going to want to make sure= that the certificates issued by the subordinate CA are enforceably within m= ikestjohnscompany.com which means setting the critical bit. If your (Ryan,= Phil, etc) assumption is that very few RPs understand NC, then setting the b= it to non-critical means that the NC is basically useless, and almost any na= me issued by that subordinate CA is going to be accepted by the vast majorit= y of RPs including those not under mikestjohnscompany.com. =20 >>=20 >> Amusingly, if there are enough of non-critical NC/Non-Compliant name ser= ver certificates (because some subordinate CA was gaming the system, or was j= ust stupid about how they set up their CA) deployed, deployments of browsers= that implement NC support may never happen because those now NC supporting b= rowsers will not be able to reach the servers with non-compliant certificate= s. Talk about anti-incentive. >>=20 >> You're trying to deal with a legacy issue the wrong way (or so I believe)= . But, as someone else noted, it really is - in the final analysis - up t= o the issuing CA whether to set the critical bit or not. So as CA vendors y= ou should feel free to set the bit as you please - it just won't be complian= t with the 5280 profile if its set non-critical. Personally, I'd rather you= just not include the NC in the certificate. >>=20 >> Later, Mike >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >> Scanned by Check Point Total Security Gateway. >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From dharkins@lounge.org Wed May 30 09:06:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321E511E80B6 for ; Wed, 30 May 2012 09:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.682 X-Spam-Level: X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4Lxdk9DsRFJ for ; Wed, 30 May 2012 09:06:26 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 31B6611E8083 for ; Wed, 30 May 2012 09:06:26 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E6FCB1022400A; Wed, 30 May 2012 09:06:25 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 30 May 2012 09:06:26 -0700 (PDT) Message-ID: <01d7bb19155d290f35de82ccb1477d7a.squirrel@www.trepanning.net> In-Reply-To: <260966ff0f0743ba0f04d902cca68116.squirrel@www.trepanning.net> References: <260966ff0f0743ba0f04d902cca68116.squirrel@www.trepanning.net> Date: Wed, 30 May 2012 09:06:26 -0700 (PDT) From: "Dan Harkins" To: "Max Pritikin" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: pkix@ietf.org Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 16:06:27 -0000 Hi Max, This comment seems to have been subsumed into a different discussion on the draft and I'd like to bring it back explicitly. What I'd like to see is that instead of the server responding with an RFC4945-style application/pkix-cert, I think it would be more useful to respond with an RFC5751-style application/pkcs7-mime of "certs-only". This is more in-line with "simple CMC" which is what EST is supposed to be supporting. I think it would be better for EST to reuse this model of PKCS#10 request and PKCS#7 response. regards, Dan. On Wed, March 28, 2012 2:04 am, Dan Harkins wrote: > > Hi, > > On Tue, 27 Mar 2012 at 11:25:05 Sean Turner said: >> Just a couple of comments the WG should consider: >> >>Technical: >> >> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s >> for >> the request and return the certificate(s) in a mime media type. In many >> instances, the "normal" query/response for a certificate is a PKCS#10 >> request followed by a PKCS#7 response, where the PKCS#7 is the >> degenerate >> certs-only message. Does anyone see any benefit in reusing the >> PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it would >> align nicely/exactly with the simple PKI request/response from CMC. > > Yes, I see value in reusing the PKCS#10/PKCS#7 model. EST is supposed > to implement "simple CMC" and that should use a PKCS#7 as the simple > response. > > regards, > > Dan. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From SChokhani@cygnacom.com Wed May 30 12:35:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3411E8135 for ; Wed, 30 May 2012 12:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp5hkqi2dSp6 for ; Wed, 30 May 2012 12:35:41 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id CAC0B11E813D for ; Wed, 30 May 2012 12:35:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,686,1330923600"; d="scan'208";a="5155170" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 30 May 2012 15:35:25 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 30 May 2012 15:35:25 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker , Yoav Nir Date: Wed, 30 May 2012 15:35:23 -0400 Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac0+b2ju9zWLOEMGRPuOd/UcJbQv8AAK7ssQ Message-ID: References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> In-Reply-To: <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 19:35:42 -0000 PHB, If you are going to recommend rules beyond 5280 (e.g., if something is mark= ed NC and 5280 says it should be critical), that is a non-starter. We do n= ot need to add such rules and they do not serve any useful purpose. -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Wednesday, May 30, 2012 10:21 AM To: Yoav Nir Cc: Santosh Chokhani; IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality I dont see that either. Commercial CAs now face a mandate from Mozilla that requires them to use Na= me Constraints. I have a draft of a draft that sets out the required client behavior when e= ncountering a certificate that is not 5280 compliant with respect to critic= ality setting and the consequences of not setting criticality. Sent from my iPad On May 28, 2012, at 8:38, Yoav Nir wrote: > Hi Santosh >=20 > I don't really see the difference between options 2 and 4. In option=20 > #2 we're keeping the MUST, but adding language that says that CAs can=20 > decide to make it non-critical if certain conditions apply and/or they=20 > decide to trade off interoperability for security. IMO this is the=20 > very definition of SHOULD >=20 > Yoav >=20 > On May 27, 2012, at 6:09 PM, Santosh Chokhani wrote: >=20 >> I agree with Mike. >>=20 >> In light of the fact we seem to have established positions which we do n= ot wish to change, I thought we should see if there are options we could ag= ree on. >>=20 >> To that end and since the thread has several sub-threads, I have begun a= new thread. >>=20 >> Here are the options that come to my mind. There may be others. >>=20 >> Option 1: Do not change the standard >>=20 >> Option 2: Do not change the standard but add language akin to the follow= ing in an appropriate place in the standard " It is recognized that a CA ma= y wish to make the name constraints extension non-critical in order to maxi= mize interoperability. Such CA shall either use other mechanisms that are = not specified in this standard or shall make such a decision based on tradi= ng off increased interoperability and security exposure" >>=20 >> Option 3: Change the standard to make the extension "recommended to be c= ritical for a period of time" This period of time should be short and shou= ld be only made if Opera and Safari decision makers are willing to provide = the support for the extension ASAP in their browsers and maximize updates t= o the current version. We can add the applicable language and revision fro= m Option 2. I would set this date to be expiry date of CA certificate sinc= e revocation checking in browsers is uneven. >>=20 >> Option 4: Change the standard to make the extension "recommended to be c= ritical". I would be against it. >>=20 >> May be we could use this or similar method to get a vote on the WG since= in my opinion no one is saying anything new. >>=20 >> -----Original Message----- >> From: Michael StJohns [mailto:mstjohns@comcast.net] >> Sent: Saturday, May 26, 2012 9:15 PM >> To: ryan-pkix@sleevi.com; Santosh Chokhani >> Cc: IETF PKIX >> Subject: Re: [pkix] NameConstraints criticality flag >>=20 >> At 05:57 PM 5/26/2012, Ryan Sleevi wrote: >>> Any CA who makes NC critical will necessarily prevent these users=20 >>> from accessing any servers whose certificates chain to them.=20 >>> Considering that so much of market position within the CA ecosystem=20 >>> is being able to interoperate with legacy systems, this is a=20 >>> unbearable market penalty for any CA. Considering the first mover=20 >>> penalties are so high, no CA wishing to stay in business would adopt NC= . >>=20 >> I keep trying to understand this type of a statement, but it gives me a = bad case of cognitive dissonance. I'm actually thinking that a critical NC= and not being able to access those servers is a good thing and the whole i= dea of NC in the first place. >>=20 >> Here's how I imagine an NC would be used. >>=20 >> I'm a company that wants to issue certificates to my servers that chain = back to a well known root. I *don't* want to have to do a server by server= request to get certificates so I contract with the well known root (WKR) t= o get a CA certificate owned by my company signed. =20 >>=20 >> The WKR has two types of CA signing it will do - the first contains an N= C that constrains me to issue certificates with names that are subordinate = to "mikestjohnscompany.com" and costs X, the second that does not contain a= n NC and costs 10 X (mainly because the WKR doesn't want it competing with = them for issuing TLS server certificates for random companies). >>=20 >> If the WKR is only getting X, then the WKR is going to want to make sur= e that the certificates issued by the subordinate CA are enforceably within= mikestjohnscompany.com which means setting the critical bit. If your (Ry= an, Phil, etc) assumption is that very few RPs understand NC, then setting = the bit to non-critical means that the NC is basically useless, and almost = any name issued by that subordinate CA is going to be accepted by the vast = majority of RPs including those not under mikestjohnscompany.com. =20 >>=20 >> Amusingly, if there are enough of non-critical NC/Non-Compliant name se= rver certificates (because some subordinate CA was gaming the system, or wa= s just stupid about how they set up their CA) deployed, deployments of brow= sers that implement NC support may never happen because those now NC suppor= ting browsers will not be able to reach the servers with non-compliant cert= ificates. Talk about anti-incentive. >>=20 >> You're trying to deal with a legacy issue the wrong way (or so I believe= ). But, as someone else noted, it really is - in the final analysis - up= to the issuing CA whether to set the critical bit or not. So as CA vendor= s you should feel free to set the bit as you please - it just won't be comp= liant with the 5280 profile if its set non-critical. Personally, I'd rathe= r you just not include the NC in the certificate. >>=20 >> Later, Mike >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >> Scanned by Check Point Total Security Gateway. >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From turners@ieca.com Wed May 30 12:39:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8EE11E814F for ; Wed, 30 May 2012 12:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.061 X-Spam-Level: X-Spam-Status: No, score=-102.061 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwOKW45RuKQR for ; Wed, 30 May 2012 12:39:13 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.137.85]) by ietfa.amsl.com (Postfix) with ESMTP id 81E6911E814C for ; Wed, 30 May 2012 12:39:13 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id F1E3B755AA664; Wed, 30 May 2012 14:39:12 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id E1C6C755AA644 for ; Wed, 30 May 2012 14:39:12 -0500 (CDT) Received: from [96.231.115.218] (port=39960 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZojg-0002ir-Ks for pkix@ietf.org; Wed, 30 May 2012 14:39:12 -0500 Message-ID: <4FC6775F.3070206@ieca.com> Date: Wed, 30 May 2012 15:39:11 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20120530193526.22578.94157.idtracker@ietfa.amsl.com> In-Reply-To: <20120530193526.22578.94157.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.115.218]:39960 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [pkix] I-D Action: draft-turner-additional-methods-4kis-05.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 19:39:14 -0000 I've updated this draft to remove the 224 and 384 options, added some rationale for the extension, removed the length field (we'll rely on the OID), and added a field to indicate the format of the output. spt On 5/30/12 3:35 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Additional Methods for Generating Key Identifiers and Key Identifier Semantic Extension > Author(s) : Sean Turner > Stephen Kent > Filename : draft-turner-additional-methods-4kis-05.txt > Pages : 8 > Date : 2012-05-30 > > This document specifies additional methods for generating key > identifiers from a public key. This document also specifies an > extension to identify the algorithms used to generate the key > identifiers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-05.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From jmdesp@free.fr Wed May 30 14:02:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD9311E8117 for ; Wed, 30 May 2012 14:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeqHgqrrr6T2 for ; Wed, 30 May 2012 14:02:02 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id 8640511E809C for ; Wed, 30 May 2012 14:02:00 -0700 (PDT) Received: from [172.30.24.38] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) (Authenticated sender: jmdesp) by smtp4-g21.free.fr (Postfix) with ESMTPA id 492194C8079 for ; Wed, 30 May 2012 23:01:55 +0200 (CEST) Message-ID: <4FC68AC2.7090007@free.fr> Date: Wed, 30 May 2012 23:01:54 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120522 Firefox/13.0 SeaMonkey/2.10 MIME-Version: 1.0 To: "pkix@ietf.org" References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> In-Reply-To: <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 21:02:03 -0000 Phillip Hallam-Baker a crit : > I have a draft of a draft that sets out the required client behavior > when encountering a certificate that is not 5280 compliant with > respect to criticality setting and the consequences of not setting > criticality. This shouldn't be needed. Maybe option 5 would be : - Modify RFC5280 to say that whilst compliant implementation MAY add additional restrictions to the Certification Path Validation algorithm, those restrictions SHOULD NOT cause to reject as invalid a certificate that contains a non critical extension that RFC5280 defines as critical. Actually I think it would be best to say also that implementation SHOULD display a warning about it in interactive settings. From david.cooper@nist.gov Wed May 30 14:17:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA7311E809C for ; Wed, 30 May 2012 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIs747AvY6JH for ; Wed, 30 May 2012 14:17:43 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9C11E8085 for ; Wed, 30 May 2012 14:17:43 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 30 May 2012 17:17:25 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Wed, 30 May 2012 17:16:07 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q4ULHedu007064; Wed, 30 May 2012 17:17:41 -0400 Message-ID: <4FC68E74.50709@nist.gov> Date: Wed, 30 May 2012 17:17:40 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120426 Thunderbird/12.0 MIME-Version: 1.0 To: Jean-Marc Desperrier References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <4FC68AC2.7090007@free.fr> In-Reply-To: <4FC68AC2.7090007@free.fr> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 21:17:44 -0000 On 05/30/2012 05:01 PM, Jean-Marc Desperrier wrote: > Phillip Hallam-Baker a crit : >> I have a draft of a draft that sets out the required client behavior >> when encountering a certificate that is not 5280 compliant with >> respect to criticality setting and the consequences of not setting >> criticality. > This shouldn't be needed. > > Maybe option 5 would be : > - Modify RFC5280 to say that whilst compliant implementation MAY add > additional restrictions to the Certification Path Validation algorithm, > those restrictions SHOULD NOT cause to reject as invalid a certificate > that contains a non critical extension that RFC5280 defines as critical. RFC 5280 already (effectively) says that: While the certificate and CRL profiles specified in Sections 4 and 5 of this document specify values for certificate and CRL fields and extensions that are considered to be appropriate for the Internet PKI, the algorithm presented in this section is not limited to accepting certificates and CRLs that conform to these profiles. Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. This applies to the criticality of the nameConstraints extension since RFC 5280 states that conforming CAs must mark the nameConstraints extension as critical, but does not "define" the extension as critical. The extension is defined in X.509, and X.509 says that the extension may be marked as either critical or non-critical. So, this is different from an extension such as the issuingDistributionPoint CRL extension, which X.509 says is always critical (i.e., is defined as critical). Even in this case, however, the path validation algorithm does not include a step to verify that the CRL issuer marked the extension as critical. Dave From hallam@gmail.com Wed May 30 14:41:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D937711E80C5 for ; Wed, 30 May 2012 14:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.295 X-Spam-Level: X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHydRVrPoZeo for ; Wed, 30 May 2012 14:41:07 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9946E11E80AB for ; Wed, 30 May 2012 14:41:07 -0700 (PDT) Received: by ggnc4 with SMTP id c4so325107ggn.31 for ; Wed, 30 May 2012 14:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G1LcwLTdPAWhdqaXGo0Y6nal6bhlzThLhZ6qOVlTwoI=; b=Q7igZvoxk3CY6ejLml3d0hPw//XvFKt7smjxmpfs+6VVd6DtuK04eDFqAqOHugaYeg /32c8WkGx9+EnEbmMm/m42FeSYDbaFYKFxCIEWhI+PdD/y3fPU2CIR65a/Gyzw4ubN56 QFyCiVQDuMyVAKk7O7vLn3OZNO0D/3uKlzkHAKi/8GyQM6jca2qGa761a2O6Mkc+L3kw Qb2eCNLJ6lWbjcNJXeBOdWoDjPikv/WKEDlOa2br4GbDdlVLQQt+8FktGu4KJS7UG9ov uvLp8imyC09hwwWmrptKJhPYJ54O6nqT71GR2M8jLnlHkeS3oh8wx449oRz/om5m0YF7 aAGg== MIME-Version: 1.0 Received: by 10.101.6.18 with SMTP id j18mr5296604ani.33.1338414066984; Wed, 30 May 2012 14:41:06 -0700 (PDT) Received: by 10.236.153.131 with HTTP; Wed, 30 May 2012 14:41:06 -0700 (PDT) In-Reply-To: References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> Date: Wed, 30 May 2012 17:41:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: multipart/alternative; boundary=001636c5bd1006678504c147cf32 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 21:41:10 -0000 --001636c5bd1006678504c147cf32 Content-Type: text/plain; charset=ISO-8859-1 What I propose to do is to write a document that explains the steps that are necessary to write software that works with and the security consequences of accepting the certificates that CAs will be required to distribute in the next few weeks baring the (unlikely) event that Mozilla changes its mind. I think that the practical utility of that document is rather obvious. On Wed, May 30, 2012 at 3:35 PM, Santosh Chokhani wrote: > PHB, > > If you are going to recommend rules beyond 5280 (e.g., if something is > marked NC and 5280 says it should be critical), that is a non-starter. We > do not need to add such rules and they do not serve any useful purpose. > > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Wednesday, May 30, 2012 10:21 AM > To: Yoav Nir > Cc: Santosh Chokhani; IETF PKIX > Subject: Re: [pkix] Way Forward: Name Constraints Criticality > > I dont see that either. > > Commercial CAs now face a mandate from Mozilla that requires them to use > Name Constraints. > > I have a draft of a draft that sets out the required client behavior when > encountering a certificate that is not 5280 compliant with respect to > criticality setting and the consequences of not setting criticality. > > > > > Sent from my iPad > > On May 28, 2012, at 8:38, Yoav Nir wrote: > > > Hi Santosh > > > > I don't really see the difference between options 2 and 4. In option > > #2 we're keeping the MUST, but adding language that says that CAs can > > decide to make it non-critical if certain conditions apply and/or they > > decide to trade off interoperability for security. IMO this is the > > very definition of SHOULD > > > > Yoav > > > > On May 27, 2012, at 6:09 PM, Santosh Chokhani wrote: > > > >> I agree with Mike. > >> > >> In light of the fact we seem to have established positions which we do > not wish to change, I thought we should see if there are options we could > agree on. > >> > >> To that end and since the thread has several sub-threads, I have begun > a new thread. > >> > >> Here are the options that come to my mind. There may be others. > >> > >> Option 1: Do not change the standard > >> > >> Option 2: Do not change the standard but add language akin to the > following in an appropriate place in the standard " It is recognized that a > CA may wish to make the name constraints extension non-critical in order to > maximize interoperability. Such CA shall either use other mechanisms that > are not specified in this standard or shall make such a decision based on > trading off increased interoperability and security exposure" > >> > >> Option 3: Change the standard to make the extension "recommended to be > critical for a period of time" This period of time should be short and > should be only made if Opera and Safari decision makers are willing to > provide the support for the extension ASAP in their browsers and maximize > updates to the current version. We can add the applicable language and > revision from Option 2. I would set this date to be expiry date of CA > certificate since revocation checking in browsers is uneven. > >> > >> Option 4: Change the standard to make the extension "recommended to be > critical". I would be against it. > >> > >> May be we could use this or similar method to get a vote on the WG > since in my opinion no one is saying anything new. > >> > >> -----Original Message----- > >> From: Michael StJohns [mailto:mstjohns@comcast.net] > >> Sent: Saturday, May 26, 2012 9:15 PM > >> To: ryan-pkix@sleevi.com; Santosh Chokhani > >> Cc: IETF PKIX > >> Subject: Re: [pkix] NameConstraints criticality flag > >> > >> At 05:57 PM 5/26/2012, Ryan Sleevi wrote: > >>> Any CA who makes NC critical will necessarily prevent these users > >>> from accessing any servers whose certificates chain to them. > >>> Considering that so much of market position within the CA ecosystem > >>> is being able to interoperate with legacy systems, this is a > >>> unbearable market penalty for any CA. Considering the first mover > >>> penalties are so high, no CA wishing to stay in business would adopt > NC. > >> > >> I keep trying to understand this type of a statement, but it gives me a > bad case of cognitive dissonance. I'm actually thinking that a critical NC > and not being able to access those servers is a good thing and the whole > idea of NC in the first place. > >> > >> Here's how I imagine an NC would be used. > >> > >> I'm a company that wants to issue certificates to my servers that chain > back to a well known root. I *don't* want to have to do a server by server > request to get certificates so I contract with the well known root (WKR) to > get a CA certificate owned by my company signed. > >> > >> The WKR has two types of CA signing it will do - the first contains an > NC that constrains me to issue certificates with names that are subordinate > to "mikestjohnscompany.com" and costs X, the second that does not contain > an NC and costs 10 X (mainly because the WKR doesn't want it competing with > them for issuing TLS server certificates for random companies). > >> > >> If the WKR is only getting X, then the WKR is going to want to make > sure that the certificates issued by the subordinate CA are enforceably > within mikestjohnscompany.com which means setting the critical bit. If > your (Ryan, Phil, etc) assumption is that very few RPs understand NC, then > setting the bit to non-critical means that the NC is basically useless, and > almost any name issued by that subordinate CA is going to be accepted by > the vast majority of RPs including those not under mikestjohnscompany.com. > >> > >> Amusingly, if there are enough of non-critical NC/Non-Compliant name > server certificates (because some subordinate CA was gaming the system, or > was just stupid about how they set up their CA) deployed, deployments of > browsers that implement NC support may never happen because those now NC > supporting browsers will not be able to reach the servers with > non-compliant certificates. Talk about anti-incentive. > >> > >> You're trying to deal with a legacy issue the wrong way (or so I > believe). But, as someone else noted, it really is - in the final > analysis - up to the issuing CA whether to set the critical bit or not. So > as CA vendors you should feel free to set the bit as you please - it just > won't be compliant with the 5280 profile if its set non-critical. > Personally, I'd rather you just not include the NC in the certificate. > >> > >> Later, Mike > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> pkix mailing list > >> pkix@ietf.org > >> https://www.ietf.org/mailman/listinfo/pkix > >> > >> Scanned by Check Point Total Security Gateway. > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --001636c5bd1006678504c147cf32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I propose to do is to write a document that explains the steps that ar= e necessary to write software that works with and the security consequences= of accepting the certificates that CAs will be required to distribute in t= he next few weeks baring the (unlikely) event that Mozilla changes its mind= .

I think that the practical utility of that document is rathe= r obvious.



On Wed, May 30, 2012 at 3:35 PM, Santosh Chokhani <SChokh= ani@cygnacom.com> wrote:
PHB,

If you are going to recommend rules beyond 5280 (e.g., if something is mark= ed NC and 5280 says it should be critical), that is a non-starter. =A0We do= not need to add such rules and they do not serve any useful purpose.

-----Original Message-----
From: Phillip Hallam-Baker [mailto:hall= am@gmail.com]
Sent: Wednesday, May 30, 2012 10:21 AM
To: Yoav Nir
Cc: Santosh Chokhani; IETF PKIX
Subject: Re: [pkix] Way Forward: Name Constraints Criticality

I dont see that either.

Commercial CAs now face a mandate from Mozilla that requires them to use Na= me Constraints.

I have a draft of a draft that sets out the required client behavior when e= ncountering a certificate that is not 5280 compliant with respect to critic= ality setting and the consequences of not setting criticality.




Sent from my iPad

On May 28, 2012, at 8:38, Yoav Nir <ynir@checkpoint.com> wrote:

> Hi Santosh
>
> I don't really see the difference between options 2 and 4. In opti= on
> #2 we're keeping the MUST, but adding language that says that CAs = can
> decide to make it non-critical if certain conditions apply and/or they=
> decide to trade off interoperability for security. IMO this is the
> very definition of SHOULD
>
> Yoav
>
> On May 27, 2012, at 6:09 PM, Santosh Chokhani wrote:
>
>> I agree with Mike.
>>
>> In light of the fact we seem to have established positions which w= e do not wish to change, I thought we should see if there are options we co= uld agree on.
>>
>> To that end and since the thread has several sub-threads, I have b= egun a new thread.
>>
>> Here are the options that come to my mind. =A0There may be others.=
>>
>> Option 1: Do not change the standard
>>
>> Option 2: Do not change the standard but add language akin to the = following in an appropriate place in the standard " It is recognized t= hat a CA may wish to make the name constraints extension non-critical in or= der to maximize interoperability. =A0Such CA shall either use other mechani= sms that are not specified in this standard or shall make such a decision b= ased on trading off increased interoperability and security exposure"<= br> >>
>> Option 3: Change the standard to make the extension "recommen= ded to be critical for a period of time" =A0This period of time should= be short and should be only made if Opera and Safari decision makers are w= illing to provide the support for the extension ASAP in their browsers and = maximize updates to the current version. =A0We can add the applicable langu= age and revision from Option 2. =A0I would set this date to be expiry date = of CA certificate since revocation checking in browsers is uneven.
>>
>> Option 4: Change the standard to make the extension "recommen= ded to be critical". =A0I would be against it.
>>
>> May be we could use this or similar method to get a vote on the WG= since in my opinion no one is saying anything new.
>>
>> -----Original Message-----
>> From: Michael StJohns [mailto:mstjohns@comcast.net]
>> Sent: Saturday, May 26, 2012 9:15 PM
>> To: ryan-pkix@sleevi.com; Santosh Chokhani
>> Cc: IETF PKIX
>> Subject: Re: [pkix] NameConstraints criticality flag
>>
>> At 05:57 PM 5/26/2012, Ryan Sleevi wrote:
>>> Any CA who makes NC critical will necessarily prevent these us= ers
>>> from accessing any servers whose certificates chain to them. >>> Considering that so much of market position within the CA ecos= ystem
>>> is being able to interoperate with legacy systems, this is a >>> unbearable market penalty for any CA. Considering the first mo= ver
>>> penalties are so high, no CA wishing to stay in business would= adopt NC.
>>
>> I keep trying to understand this type of a statement, but it gives= me a bad case of cognitive dissonance. =A0I'm actually thinking that a= critical NC and not being able to access those servers is a good thing and= the whole idea of NC in the first place.
>>
>> Here's how I imagine an NC would be used.
>>
>> I'm a company that wants to issue certificates to my servers t= hat chain back to a well known root. =A0I *don't* want to have to do a = server by server request to get certificates so I contract with the well kn= own root (WKR) to get a CA certificate owned by my company signed.
>>
>> The WKR has two types of CA signing it will do - the first contain= s an NC that constrains me to issue certificates with names that are subord= inate to "
= mikestjohnscompany.com" and costs X, the second that does not cont= ain an NC and costs 10 X (mainly because the WKR doesn't want it compet= ing with them for issuing TLS server certificates for random companies). >>
>> If =A0the WKR is only getting X, then the WKR is going to want to = make sure that the certificates issued by the subordinate CA are enforceabl= y within mikest= johnscompany.com which means setting the critical bit. =A0 If your (Rya= n, Phil, etc) assumption is that very few RPs understand NC, then setting t= he bit to non-critical means that the NC is basically useless, and almost a= ny name issued by that subordinate CA is going to be accepted by the vast m= ajority of RPs including those not under mikestjohnscompany.com.
>>
>> Amusingly, if there are enough of =A0non-critical NC/Non-Compliant= name server certificates (because some subordinate CA was gaming the syste= m, or was just stupid about how they set up their CA) deployed, deployments= of browsers that implement NC support may never happen because those now N= C supporting browsers will not be able to reach the servers with non-compli= ant certificates. =A0Talk about anti-incentive.
>>
>> You're trying to deal with a legacy issue the wrong way (or so= I believe). =A0 But, as someone else noted, it really is =A0- in the final= analysis - up to the issuing CA whether to set the critical bit or not. = =A0So as CA vendors you should feel free to set the bit as you please - it = just won't be compliant with the 5280 profile if its set non-critical. = =A0Personally, I'd rather you just not include the NC in the certificat= e.
>>
>> Later, Mike
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>> Scanned by Check Point Total Security Gateway.
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix



--
= Website: http://hallambaker.com/
--001636c5bd1006678504c147cf32-- From hallam@gmail.com Wed May 30 14:47:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980EB21F8744 for ; Wed, 30 May 2012 14:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0KDDSqdhUZ6 for ; Wed, 30 May 2012 14:47:49 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A814821F86FF for ; Wed, 30 May 2012 14:47:49 -0700 (PDT) Received: by ggnc4 with SMTP id c4so332257ggn.31 for ; Wed, 30 May 2012 14:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wQCZiT8eWkCl7/HEep8XZYQHRusVHw7sRWrgbuhStCg=; b=yC+uN8+wUm6cTfMG+witf5H/4nOq6Lko+9gNcnewdb0Fc14c435pWXpzghilsv0FWD Wc8JsxknR7WrAxyz57oLEYShwe6SKlFnt79C0uN8hfKPHXOLIfcmdhFXbhDPm+GitlF1 n31+LlJz6Nsq2RCw6fY4taI1JLTwjGyU1s8qTJHHk31zDZwDYvz6VxRjZdQ/5jMSxagj RoBIcvDqLiSl1THXomhdC5yRhK/KZ+PAoG0bMBYvtbSqb+TTptDY4tPw1fp5rBBztC+Q RMEA1AiZ5NkMh8nxX2o4OcfbvJWM34rvEHM+XNjEITE1MA2UjBIjmOh7fX1L+E+uWmtl COwg== MIME-Version: 1.0 Received: by 10.100.244.38 with SMTP id r38mr5266103anh.52.1338414469235; Wed, 30 May 2012 14:47:49 -0700 (PDT) Received: by 10.236.153.131 with HTTP; Wed, 30 May 2012 14:47:48 -0700 (PDT) In-Reply-To: <4FC68E74.50709@nist.gov> References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <4FC68AC2.7090007@free.fr> <4FC68E74.50709@nist.gov> Date: Wed, 30 May 2012 17:47:48 -0400 Message-ID: From: Phillip Hallam-Baker To: "David A. Cooper" Content-Type: multipart/alternative; boundary=001636c9257d00452904c147e790 Cc: "pkix@ietf.org" Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 21:47:50 -0000 --001636c9257d00452904c147e790 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 30, 2012 at 5:17 PM, David A. Cooper wro= te: > On 05/30/2012 05:01 PM, Jean-Marc Desperrier wrote: > >> Phillip Hallam-Baker a =E9crit : >> >>> I have a draft of a draft that sets out the required client behavior >>> when encountering a certificate that is not 5280 compliant with >>> respect to criticality setting and the consequences of not setting >>> criticality. >>> >> This shouldn't be needed. >> >> Maybe option 5 would be : >> - Modify RFC5280 to say that whilst compliant implementation MAY add >> additional restrictions to the Certification Path Validation algorithm, >> those restrictions SHOULD NOT cause to reject as invalid a certificate >> that contains a non critical extension that RFC5280 defines as critical. >> > > RFC 5280 already (effectively) says that: > > While the certificate and CRL profiles specified in Sections 4 and 5 > of this document specify values for certificate and CRL fields and > extensions that are considered to be appropriate for the Internet > PKI, the algorithm presented in this section is not limited to > accepting certificates and CRLs that conform to these profiles. > Therefore, the algorithm only includes checks to verify that the > certification path is valid according to X.509 and does not include > checks to verify that the certificates and CRLs conform to this > profile. While the algorithm could be extended to include checks for > conformance to the profiles in Sections 4 and 5, this profile > RECOMMENDS against including such checks. > > This applies to the criticality of the nameConstraints extension since RF= C > 5280 states that conforming CAs must mark the nameConstraints extension a= s > critical, but does not "define" the extension as critical. The extension > is defined in X.509, and X.509 says that the extension may be marked as > either critical or non-critical. So, this is different from an extension > such as the issuingDistributionPoint CRL extension, which X.509 says is > always critical (i.e., is defined as critical). Even in this case, > however, the path validation algorithm does not include a step to verify > that the CRL issuer marked the extension as critical. > Given that attempting to enforce this particular check will now cause damage, I think it is a good thing to have a document that notes that this is the case. Enforcing RFC 5280 compliance on certs would seem to be an idiotic thing to attempt in any case since there is no guarantee that RFC 5280 will be the perpetual internet standard in any case. In particular, I can't see how any revision to RFC 5280 is going to manage to get to DRAFT or FULL standard when the industry has taken a conscious decision to reject the WG advice on this point. --=20 Website: http://hallambaker.com/ --001636c9257d00452904c147e790 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, May 30, 2012 at 5:17 PM, David A. Cooper <david.cooper@nist.go= v> wrote:
On 05/30/2012 05:01 PM, Jean-Marc Desperrier wrote:
Phillip Hallam-Baker a =E9crit :
I have a draft of a draft that sets out the required client behavior
when encountering a certificate that is not 5280 compliant with
respect to criticality setting and the consequences of not setting
criticality.
This shouldn't be needed.

Maybe option 5 would be :
- Modify RFC5280 to say that whilst compliant implementation MAY add
additional restrictions to the Certification Path Validation algorithm,
those restrictions SHOULD NOT cause to reject as invalid a certificate
that contains a non critical extension that RFC5280 defines as critical.

RFC 5280 already (effectively) says that:

=A0 While the certificate and CRL profiles specified in Sections 4 and 5 =A0 of this document specify values for certificate and CRL fields and
=A0 extensions that are considered to be appropriate for the Internet
=A0 PKI, the algorithm presented in this section is not limited to
=A0 accepting certificates and CRLs that conform to these profiles.
=A0 Therefore, the algorithm only includes checks to verify that the
=A0 certification path is valid according to X.509 and does not include =A0 checks to verify that the certificates and CRLs conform to this
=A0 profile. =A0While the algorithm could be extended to include checks fo= r
=A0 conformance to the profiles in Sections 4 and 5, this profile
=A0 RECOMMENDS against including such checks.

This applies to the criticality of the nameConstraints extension since RFC = 5280 states that conforming CAs must mark the nameConstraints extension as = critical, but does not "define" the extension as critical. =A0The= extension is defined in X.509, and X.509 says that the extension may be ma= rked as either critical or non-critical. =A0So, this is different from an e= xtension such as the issuingDistributionPoint CRL extension, which X.509 sa= ys is always critical (i.e., is defined as critical). =A0Even in this case,= however, the path validation algorithm does not include a step to verify t= hat the CRL issuer marked the extension as critical.

Given that attempting to enforce this part= icular check will now cause damage, I think it is a good thing to have a do= cument that notes that this is the case.

Enforcing= RFC 5280 compliance on certs would seem to be an idiotic thing to attempt = in any case since there is no guarantee that RFC 5280 will be the perpetual= internet standard in any case.


In particular, I can't see how any r= evision to RFC 5280 is going to manage to get to DRAFT or FULL standard whe= n the industry has taken a conscious decision to reject the WG advice on th= is point.
=A0

--
Website: http://hallambaker.com/

--001636c9257d00452904c147e790-- From stephen.farrell@cs.tcd.ie Wed May 30 15:53:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357EE11E8138 for ; Wed, 30 May 2012 15:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdTR9qIf-MWW for ; Wed, 30 May 2012 15:53:15 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 648AA11E812D for ; Wed, 30 May 2012 15:53:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BF011153B27; Wed, 30 May 2012 23:53:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338418393; bh=rVGvqEWa5O629v txRjsVD0+TDaiI6QJjj6AjhOmDrmc=; b=Q99zqvTMobvbADHCBXSfZcjoQep6y4 dulFG5oR+B6lMZSg2pevGW3/tjavmH+Uh4lZsQJ2ZTDalnT2rU6mQ8IDDCS8HrWe ixB4zfQFtDXZqOzuo8vGr+RRI94QZuaxYze5ItQvmRkDAf7EO/dH1us2+a6APEo6 ex+NQ2ENP8SRk/anKaSuznxhnTPwNSCtgTICQs5jX615lCm31Sw2iNLUo9j1dBdW s8Pxbtyj02Tr7VHhFsZwJuieJW5SmCOUH5pRgBYL7t8VQKEZjsQHdB3y+04vOagQ F5fYPD1nzuVx6KXTi6F1h9c4UxZ620eQzs2vK2kbkb+Ww1Mz2rtmcyRw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id frKI9f9j4K3C; Wed, 30 May 2012 23:53:13 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.25.154]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AAFDF153B1E; Wed, 30 May 2012 23:53:11 +0100 (IST) Message-ID: <4FC6A4D7.7070505@cs.tcd.ie> Date: Wed, 30 May 2012 23:53:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <4FC68AC2.7090007@free.fr> <4FC68E74.50709@nist.gov> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 22:53:16 -0000 Phill, On 05/30/2012 10:47 PM, Phillip Hallam-Baker wrote: > Given that attempting to enforce this particular check will now cause > damage, I guess we disagree about that. > I think it is a good thing to have a document that notes that this > is the case. Sure. Sounds like a fine thing for the ISE. > Enforcing RFC 5280 compliance on certs would seem to be an idiotic thing to > attempt in any case since there is no guarantee that RFC 5280 will be the > perpetual internet standard in any case. I don't see how you can believe that, know about IETF processes, and see any utility in any standards. > In particular, I can't see how any revision to RFC 5280 is going to manage > to get to DRAFT or FULL standard when the industry has taken a conscious > decision to reject the WG advice on this point. There are no longer draft or full standards, just proposed and Internet standards. (two-levels). S > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From wtc@google.com Wed May 30 16:31:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43EF21F86B5 for ; Wed, 30 May 2012 16:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDy5w4c3HjGh for ; Wed, 30 May 2012 16:31:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3533421F866A for ; Wed, 30 May 2012 16:31:14 -0700 (PDT) Received: by yhq56 with SMTP id 56so268630yhq.31 for ; Wed, 30 May 2012 16:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=4V9d5YAvNoWAXZSRLpP6ny5SgO9jwLMLEot3kNuqDHA=; b=Ec+zeEkR41NMwqi44dMf0EV4u9nh8M9TZDyuKfbjOIlu4Bw0rrZ7NCGH+d4CNnEnJL XW0yq4GZVNWTdG1pR/jq4AbBchQxerLs7P1zH2iC5+ZaGCtT8llF0FWwjQG6eKdyBrPR 4Opc/mYfnIIpIVri7/2Ev/dOXk1KKQjZogFWwz0Nt2zSXqeJCxCFqO3KAepkTZ6GeVqW 782gpafQdmh2wHh6ckieX1Zj4vramV06XeOgzoIRnFLwb9t176fynyw8XYli5zly1zWM zfTj6MRZdNDHZ4SrbrOsSRzz/cnXuvyVahY94YHD7FKooi6Kh3arvD5S8B5wSjn+iFuB 0QdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=4V9d5YAvNoWAXZSRLpP6ny5SgO9jwLMLEot3kNuqDHA=; b=m1YZiXQm6Nbd0tzN4jEBDdgV2FIwgP42Ifk+/ptutYVcfb1ly0qy5vEiv/X454qKj5 RaVd1me0DY8VkDH/XZLqPVS+whujM8gPgcz9Umd/AUadk7hz7fAFjco3bmOgv2LbRvCt sBXGBtmWQaLh0Zhy4y0LADIaeFuHwFPq1tUSP2nlxNWSAhUPczTkeTHeZ5EwM8zk31jm ty74CMs9KQcEONo1mPY5/uWnpgnqCL9K+M6pwHC7nL5mBkn18QFtALo9v6yWBwWBUGDV xG66fARTkzrjmXqUaQ/gTAP809fv3V2Ze5BG/j8eEVuXfCau6cidYhAuza8sfp4nMGtt GTNQ== Received: by 10.50.41.226 with SMTP id i2mr12478181igl.4.1338420673578; Wed, 30 May 2012 16:31:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.41.226 with SMTP id i2mr12478175igl.4.1338420673363; Wed, 30 May 2012 16:31:13 -0700 (PDT) Received: by 10.231.245.74 with HTTP; Wed, 30 May 2012 16:31:13 -0700 (PDT) In-Reply-To: References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> Date: Wed, 30 May 2012 16:31:13 -0700 Message-ID: From: Wan-Teh Chang To: IETF PKIX Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkoY/3FRh+psMoeGnxxfwKeP0dBZAKNSCNhBPbSDNgM5NW6g9Asy3Lf5siG2FH80nn6pdiqZDgRPcWD37QbLYFBJHDU74n8ZQD5oA3+fqA9Hn8DWdLt9O7R04f3Qp7ZMT9S5QiD Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 23:31:28 -0000 RFC 2459 (a predecessor of RFC 5280) is 129 pages long. Isn't it possible that the reviewers of such a long document may have overlooked the full implications of "[The name constraints] extension MUST be critical"? Is the US DoD using the name constraints extension? Thanks, Wan-Teh From stephen.farrell@cs.tcd.ie Wed May 30 16:35:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B9C11E8117 for ; Wed, 30 May 2012 16:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYU5PH21wa1R for ; Wed, 30 May 2012 16:35:56 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCA911E80D5 for ; Wed, 30 May 2012 16:35:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C7C92153B1D; Thu, 31 May 2012 00:35:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1338420955; bh=4tfeD6fCPPA0ceg/9hdiLcKt fEI8jcZo83y2aBGUltQ=; b=undvZ5j59QxGAvBiqf777vFy0cSrSNyWApAGQHfo dSVOEAgsIOYDa6de23vvkuSqv4X+xWu03K6T2pZ01oAdSLCqkcJ0rvTmwSwroFuU RpDlJ1EKRQJuVe0vd/hORag8Zc3b0yH3jDeK4j3EgGgqVC2VLlTRBuaNnE32pukT Ii8dKLcLb8KwNcn8dIolDEA/va1JrQVBkmpyiXIGU4EdB4vNGYtsXdHcFOa9xghO L5mYY5QOQNRLerbHR7BZEeI/Xd9Y3URnclye15jbVmdyvllJPILU9wKV0BU01WR2 vvH80XMuW6Lm22vcdKYPCm7GwCHZu+BHPyDQNHGVqXcBEw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id R2OIpi+BeliQ; Thu, 31 May 2012 00:35:55 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.25.154]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CC14E153959; Thu, 31 May 2012 00:35:54 +0100 (IST) Message-ID: <4FC6AEDA.4010709@cs.tcd.ie> Date: Thu, 31 May 2012 00:35:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: pkix , "krb-wg mailing list (ietf-krb-wg@lists.anl.gov)" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] RFC 5742 review of draft-hotz-kx509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 23:35:58 -0000 Hi, The independent submissions editor (ISE) has asked the IESG to do an RFC 5742 review of this [1] document. That review is to check that the publication of this independent stream submission would not conflict with IETF work. In this case, the work is clearly related to the pkix and kerberos working groups, hence this mail. Note: this mail is not a request for a technical review of the content, but rather asking if publication would somehow be damaging to the work of these wgs. (If you do have technical comments, send them to the author or ISE). If you're not sure about any of that, then read RFC 5742. [2] I'll take silence as meaning that nobody thinks that there's a conflict. If someone thinks there is a conflict let me, the list, or the wg chairs know. In due course, I'll be doing my own evaluation as well of course, as will other IESG members. Thanks, Stephen. [1] http://tools.ietf.org/html/draft-hotz-kx509-04 [2] http://tools.ietf.org/html/rfc5742 From hallam@gmail.com Thu May 31 05:48:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A8421F869A for ; Thu, 31 May 2012 05:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lcKUUoyC2+l for ; Thu, 31 May 2012 05:48:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 799A321F8686 for ; Thu, 31 May 2012 05:48:09 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1506635obb.31 for ; Thu, 31 May 2012 05:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0i+RaJDPnex2Z21GGiDbx109s8wdSO4Ad92+TKw032o=; b=yhk71moO5U7gmmwr20Lw5x7VHRrRaj8L+Hrl//8h33LUXsZOB9c63VDnEtsgozN+7N xjsK4OLsSNou0kQlpEj8KvBI9dw6uqBUf6mpenpHasj/UQ8Y+aEZYI4epvWUqV/5f5Wy caylN/qRIwwZPrnbib6WaRXClRbzDwiMCEOB142yvxQ8Ek+XjpG6z8u4tzERkMPIlhYp GzWZkJBffWFjnUGpFoiE2O4i0Db1Kj6FEvfpqOTf2Mnd7JXfKrWvIhL3qzeVqD2WSh7x cR78sH/oh8UxN2U7C8H3TF5fT5K9OUluG4BOaCzSSKii7SLsEak69FNt6AZoXD6GrKBV Vaiw== MIME-Version: 1.0 Received: by 10.182.8.99 with SMTP id q3mr19005924oba.63.1338468489003; Thu, 31 May 2012 05:48:09 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Thu, 31 May 2012 05:48:08 -0700 (PDT) In-Reply-To: <4FC6A4D7.7070505@cs.tcd.ie> References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <4FC68AC2.7090007@free.fr> <4FC68E74.50709@nist.gov> <4FC6A4D7.7070505@cs.tcd.ie> Date: Thu, 31 May 2012 08:48:08 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d0444ed59d4838b04c1547a65 Cc: "pkix@ietf.org" Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 12:48:10 -0000 --f46d0444ed59d4838b04c1547a65 Content-Type: text/plain; charset=ISO-8859-1 The point of standards is to achieve interoperability. You are defending a standard that requires the industry to issue certificates that are going to break interoperability. On Wed, May 30, 2012 at 6:53 PM, Stephen Farrell wrote: > > Phill, > > On 05/30/2012 10:47 PM, Phillip Hallam-Baker wrote: > > > Given that attempting to enforce this particular check will now cause > > damage, > > I guess we disagree about that. > > > I think it is a good thing to have a document that notes that this > > is the case. > > Sure. Sounds like a fine thing for the ISE. > > > Enforcing RFC 5280 compliance on certs would seem to be an idiotic thing > to > > attempt in any case since there is no guarantee that RFC 5280 will be the > > perpetual internet standard in any case. > > I don't see how you can believe that, know about IETF processes, > and see any utility in any standards. > > > In particular, I can't see how any revision to RFC 5280 is going to > manage > > to get to DRAFT or FULL standard when the industry has taken a conscious > > decision to reject the WG advice on this point. > > There are no longer draft or full standards, just proposed and > Internet standards. (two-levels). > > S > > > > > > > > > > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --f46d0444ed59d4838b04c1547a65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The point of standards is to achieve interoperability.

Y= ou are defending a standard that requires the industry to issue certificate= s that are going to break interoperability.



On Wed, May 30, 2012 at 6:53 PM, Stephen Far= rell <stephen.farrell@cs.tcd.ie> wrote:

Phill,

On 05/30/2012 10:47 PM, Phillip Hallam-Baker wrote:

> Given that attempting to enforce this particular check will now cause<= br> > damage,

I guess we disagree about that.

> I think it is a good thing to have a document that notes that this
> is the case.

Sure. Sounds like a fine thing for the ISE.

> Enforcing RFC 5280 compliance on certs would seem to be an idiotic thi= ng to
> attempt in any case since there is no guarantee that RFC 5280 will be = the
> perpetual internet standard in any case.

I don't see how you can believe that, know about IETF processes,<= br> and see any utility in any standards.

> In particular, I can't see how any revision to RFC 5280 is going t= o manage
> to get to DRAFT or FULL standard when the industry has taken a conscio= us
> decision to reject the WG advice on this point.

There are no longer draft or full standards, just proposed and
Internet standards. (two-levels).

S

>
>
>
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix



--
= Website: http://hallambaker.com/
--f46d0444ed59d4838b04c1547a65-- From stephen.farrell@cs.tcd.ie Thu May 31 05:58:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFB321F8698 for ; Thu, 31 May 2012 05:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPlkfZGIE4T0 for ; Thu, 31 May 2012 05:58:44 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D10821F869E for ; Thu, 31 May 2012 05:58:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0BB201714DD; Thu, 31 May 2012 13:58:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338469122; bh=rf7EBs5lrSSWN9 qMAZn4soUNrfR3riwTM9XrydhnaNs=; b=yiYRdQTJj2QSG5252CouU0Dw5J1q5n VXTuYuNUUTEWmBbfm9Gv6grQxqghxWV/rRH0mw+hoPPBqnP5LJrOIatlig7HS7GT 1qwEdjoDaC7GMXqh8+E4t04MVcz2u+1qKYrxnYQJEUiSuIruel1Qb9/z6ilF6f0o 2TOYBeJqR58uUfJsggHxz1kWIYi2ISwpJLpK0HxpwppkYfmJQ+gwc9HYZd5vlkVM tTAOqvIC+CE5kGc06PqQOA+GSQYrSZ5oBiW0tSFwKktVcxf3/Bl4jlmodaQ3OCG+ VtQiPvvGnBo47Jw/FQFPecvx2BhQvdB7c9bwcmET8AVCu8BIMCupFMaA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id DN6kKsvoI5gM; Thu, 31 May 2012 13:58:42 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.75.48]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 68A61171477; Thu, 31 May 2012 13:58:42 +0100 (IST) Message-ID: <4FC76B02.5070604@cs.tcd.ie> Date: Thu, 31 May 2012 13:58:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <4FC68AC2.7090007@free.fr> <4FC68E74.50709@nist.gov> <4FC6A4D7.7070505@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 12:58:45 -0000 On 05/31/2012 01:48 PM, Phillip Hallam-Baker wrote: > The point of standards is to achieve interoperability. Sure. > You are defending a standard that requires the industry to issue > certificates that are going to break interoperability. Nope. I'm not "defending" anything, nor am I going on any offensive. I was correcting some wrong statements you made and suggesting a way forward. S > > > > On Wed, May 30, 2012 at 6:53 PM, Stephen Farrell > wrote: > >> >> Phill, >> >> On 05/30/2012 10:47 PM, Phillip Hallam-Baker wrote: >> >>> Given that attempting to enforce this particular check will now cause >>> damage, >> >> I guess we disagree about that. >> >>> I think it is a good thing to have a document that notes that this >>> is the case. >> >> Sure. Sounds like a fine thing for the ISE. >> >>> Enforcing RFC 5280 compliance on certs would seem to be an idiotic thing >> to >>> attempt in any case since there is no guarantee that RFC 5280 will be the >>> perpetual internet standard in any case. >> >> I don't see how you can believe that, know about IETF processes, >> and see any utility in any standards. >> >>> In particular, I can't see how any revision to RFC 5280 is going to >> manage >>> to get to DRAFT or FULL standard when the industry has taken a conscious >>> decision to reject the WG advice on this point. >> >> There are no longer draft or full standards, just proposed and >> Internet standards. (two-levels). >> >> S >> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> > > > From ynir@checkpoint.com Thu May 31 06:11:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C367421F8664 for ; Thu, 31 May 2012 06:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C68X0vhmDCqr for ; Thu, 31 May 2012 06:11:27 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6074921F8653 for ; Thu, 31 May 2012 06:11:25 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4VDAtnP009066; Thu, 31 May 2012 16:10:57 +0300 X-CheckPoint: {4FC77A24-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 31 May 2012 16:10:34 +0300 From: Yoav Nir To: Stephen Farrell Date: Thu, 31 May 2012 16:10:35 +0300 Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac0/LsNihnqdcJ7STN6jEO3YB5E3+Q== Message-ID: References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <4FC68AC2.7090007@free.fr> <4FC68E74.50709@nist.gov> <4FC6A4D7.7070505@cs.tcd.ie> <4FC76B02.5070604@cs.tcd.ie> In-Reply-To: <4FC76B02.5070604@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11690a80ffb9a3fcc928ac8f1b09950b7fd61525b1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 13:11:27 -0000 On May 31, 2012, at 3:58 PM, Stephen Farrell wrote: >=20 >=20 > On 05/31/2012 01:48 PM, Phillip Hallam-Baker wrote: >> The point of standards is to achieve interoperability. >=20 > Sure. >=20 >> You are defending a standard that requires the industry to issue >> certificates that are going to break interoperability. >=20 > Nope. I'm not "defending" anything, nor am I going on > any offensive. >=20 > I was correcting some wrong statements you made and > suggesting a way forward. I don't see how PHB is wrong here. It would be wrong for an RP to check tha= t a certificate complies with RFC 5280. Suppose the discussion of a few mon= ths ago ended differently, and the WG was convinced to remove the requireme= nt in RFC 5280 that name constraints MUST be critical. We would then issue = a new RFC (7280?) that said so. Soon there would be certificates around wit= h non-critical name constraints, perfectly compliant with the new standard,= but the old client would reject them. So PHB is right. The client should not make validation on the certificates = that they comply, unless the standard says that it should (or must or may). As David Cooper said, RFC 5280 already says that anyway. Yoav From rob.stradling@comodo.com Thu May 31 06:45:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D268821F864B for ; Thu, 31 May 2012 06:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY6dK5JF-SXe for ; Thu, 31 May 2012 06:45:36 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id A903221F8644 for ; Thu, 31 May 2012 06:45:35 -0700 (PDT) Received: (qmail 25287 invoked from network); 31 May 2012 13:45:34 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 31 May 2012 13:45:34 -0000 Received: (qmail 20149 invoked by uid 1000); 31 May 2012 13:45:34 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 31 May 2012 14:45:34 +0100 Message-ID: <4FC775FD.2020006@comodo.com> Date: Thu, 31 May 2012 14:45:33 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: pkix@ietf.org References: <4FBF4B37.1090208@comodo.com> <4FC487AB.6000603@comodo.com> In-Reply-To: <4FC487AB.6000603@comodo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 13:45:36 -0000 On 29/05/12 09:24, Rob Stradling wrote: > On 25/05/12 10:04, Rob Stradling wrote: >> Which Key Usage bits (if any) are required to be present in a CA >> Certificate that directly signs OCSP Responses? > >> IMHO, it'd kinda make sense for the cRLSign bit to govern whether or not >> the CA Certificate can directly sign OCSP Responses, but sadly I can >> find no text to support this idea. > > I've unearthed some text to support this idea, so at least I'm now sure > I didn't completely make it up myself! > > RFC2459 said... > "The cRLSign bit is asserted when the subject public key is used for > verifying a signature on revocation information (e.g., a CRL)." > "The digitalSignature bit is asserted when the subject public key is > used with a digital signature mechanism to support security services > other than...revocation information signing (bit 6)." > > Obviously an OCSP Response's signature is "a signature on revocation > information". > > Why did RFC3280 change the required bit for signing non-CRL revocation > information from "cRLSign" to "digitalSignature"? > > Could we change it back, or at least allow either "cRLSign" or > "digitalSignature" to be deemed acceptable for signing non-CRL > revocation information? PHB just noted in another thread that "The point of standards is to achieve interoperability". I'll restate my question with this thought in mind. We (Comodo) sign OCSP Responses directly from CA Certificates that have the keyCertSign and cRLSign bits set but the digitalSignature bit unset. This is/was fully compliant with RFC2459, but (I realized only this week) not compliant with 3280/5280. Thus far, I've not encountered any client software that rejects our OCSP Responses. But to "achieve interoperability", I wish to ensure that no future client software rejects our OCSP Responses on the basis that the digitalSignature bit is not set in the CA Certificates. So, can we please reinstate the 2459 text that "The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information" or at least say that cRLSign and/or digitalSignature is sufficient for this purpose? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rob.stradling@comodo.com Thu May 31 06:52:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FADB21F869A for ; Thu, 31 May 2012 06:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9szzzi+gqxS for ; Thu, 31 May 2012 06:52:12 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id E0DDD21F8658 for ; Thu, 31 May 2012 06:52:11 -0700 (PDT) Received: (qmail 27797 invoked from network); 31 May 2012 13:52:11 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 31 May 2012 13:52:11 -0000 Received: (qmail 32401 invoked by uid 1000); 31 May 2012 13:52:10 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 31 May 2012 14:52:10 +0100 Message-ID: <4FC7778A.2020209@comodo.com> Date: Thu, 31 May 2012 14:52:10 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Wan-Teh Chang References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 13:52:14 -0000 On 31/05/12 00:31, Wan-Teh Chang wrote: > RFC 2459 (a predecessor of RFC 5280) is 129 pages long. > > Isn't it possible that the reviewers of such a long document may have > overlooked the full implications of "[The name constraints] extension > MUST be critical"? I think it's worth noting that the X.509 spec and the current CABForum motion are in agreement. X.509 (08/2005) says: "8.4.2.2 Name constraints extension ... This extension may, at the option of the certificate issuer, be either critical or non-critical. It is recommended that it be flagged critical, otherwise a certificate user may not check that subsequent certificates in a certification path are located in the name space intended by the issuing CA." > Is the US DoD using the name constraints extension? > > Thanks, > Wan-Teh > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From stephen.farrell@cs.tcd.ie Thu May 31 07:06:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3929721F8618 for ; Thu, 31 May 2012 07:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQAOrptTpzyb for ; Thu, 31 May 2012 07:06:00 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id CC67321F858A for ; Thu, 31 May 2012 07:05:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B65281714DD; Thu, 31 May 2012 15:05:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338473153; bh=IojCh7Pcq1Y5yZ uP3+uHcf5DY2wIgo4ZoZwE46CbRnE=; b=qjGI7wkUWzb8Mpv4llGUJMV0+cPXkH EPPj7nfVQhJ+LuHW0lUG6nU4vTQ9tvCCEk9AshHnpWotU3FH1r/qD+83l7QjD3qt nPOgeu0a4c5w2Va7UAmxx0G2CQ7pPvLjR5RwdqlbBK/wacedTPdaFlju/ENRauSH ts5d8WEm/4aHoB1GBZ1rcL6TafyOooEPHCFhMGW4vxuOZ4xtmFzZcEC6Rj8Spj17 3/NdbGstmQBFM3qXigDLY22bIEoje0ICsETCCG69FFr8CjZapAPmBsyPu2FJYytC hIhnf4MJcrQUMqWILR8oVGp1RPiSO/eXH9Ra8Tg9J34pIxTjsnDTav8Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id hKhOVbjfDwaH; Thu, 31 May 2012 15:05:53 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.75.48]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D334C171479; Thu, 31 May 2012 15:05:52 +0100 (IST) Message-ID: <4FC77AC0.8070708@cs.tcd.ie> Date: Thu, 31 May 2012 15:05:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <4FC68AC2.7090007@free.fr> <4FC68E74.50709@nist.gov> <4FC6A4D7.7070505@cs.tcd.ie> <4FC76B02.5070604@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:06:01 -0000 On 05/31/2012 02:10 PM, Yoav Nir wrote: > > On May 31, 2012, at 3:58 PM, Stephen Farrell wrote: > >> >> >> On 05/31/2012 01:48 PM, Phillip Hallam-Baker wrote: >>> The point of standards is to achieve interoperability. >> >> Sure. >> >>> You are defending a standard that requires the industry to issue >>> certificates that are going to break interoperability. >> >> Nope. I'm not "defending" anything, nor am I going on >> any offensive. >> >> I was correcting some wrong statements you made and >> suggesting a way forward. > > I don't see how PHB is wrong here. I think if you read what I wrote you'd see that I was correcting wrong statements, e.g. cab forum are more open, that there is still a draft standard. I wasn't getting back into the meat of the extended discussion we had on this before. And I'm still not, other than to point out that there is the ISE route. S > It would be wrong for an RP to check that a certificate complies with RFC 5280. Suppose the discussion of a few months ago ended differently, and the WG was convinced to remove the requirement in RFC 5280 that name constraints MUST be critical. We would then issue a new RFC (7280?) that said so. Soon there would be certificates around with non-critical name constraints, perfectly compliant with the new standard, but the old client would reject them. > > So PHB is right. The client should not make validation on the certificates that they comply, unless the standard says that it should (or must or may). > > As David Cooper said, RFC 5280 already says that anyway. > > Yoav > > > From tmiller@mitre.org Thu May 31 07:08:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A95B21F8638 for ; Thu, 31 May 2012 07:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMQvuWZfePKG for ; Thu, 31 May 2012 07:08:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0407B21F8569 for ; Thu, 31 May 2012 07:08:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 44FAC21B1BCA; Thu, 31 May 2012 10:08:27 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2A07F21B1B9A; Thu, 31 May 2012 10:08:27 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Thu, 31 May 2012 10:08:27 -0400 From: "Miller, Timothy J." To: Wan-Teh Chang , IETF PKIX Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac08GsNsKS+J4IylThCqrltUJuYcsQA1ZLMAAGgkQwAACv6ugAAEY/8AAAPYhYAAFChsAA== Date: Thu, 31 May 2012 14:08:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.138.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:08:30 -0000 On 5/30/12 6:31 PM, "Wan-Teh Chang" wrote: >Is the US DoD using the name constraints extension? The Federal Bridge CA uses critical NC in cross-certs it issues. -- T From hallam@gmail.com Thu May 31 07:36:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281A821F8644 for ; Thu, 31 May 2012 07:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb8csuo1qCZb for ; Thu, 31 May 2012 07:36:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE8221F85AD for ; Thu, 31 May 2012 07:36:24 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1637805obb.31 for ; Thu, 31 May 2012 07:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LeTzlZXNnhAjOKDhO9cVAL7GYntdNRC5Yzr+wCKvz+E=; b=x1UKqh8O6r5dIdXMaiCga1buVgV8EHem7I4216dYIfq/Hvb868Dm9EbIoxixtzViVq vxdRnfjB8ZlK3qO9bZYw8YHICMLY2FzqHULOMz7izY6bR2FkqbyrRnO20db3smB7dlV9 43mBqa1cmmE7jVpNtwwFBdvgkQkHrZ/TcFPbgDnvUdHXXPZ4TW80HQhz2UNYkQwb8sXy 8wP5Lo0zyQtW58NaQebRw+hO0qlZVXcc7DXP0Nezqf6FxMqCl9XBHU1N9zTKChwbDHJs 44vVqsgYH1wB/mCqgImfa9kOM4SGEZj135wRe/zeipIQYw3gb1noEUxZZys2qEuXh2IR tHJg== MIME-Version: 1.0 Received: by 10.182.207.41 with SMTP id lt9mr2374669obc.41.1338474984054; Thu, 31 May 2012 07:36:24 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Thu, 31 May 2012 07:36:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 May 2012 10:36:23 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: multipart/alternative; boundary=e89a8f643588f71f2a04c155fdc8 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:36:25 -0000 --e89a8f643588f71f2a04c155fdc8 Content-Type: text/plain; charset=ISO-8859-1 In the context of bridge CA I agree that the NCs would have to be marked critical. Otherwise every agency could issue certs for every other agency. Commercial CA certification relationships are far more restrictive and in particular they are not bidirectional. We have a disagreement here between the US govt and their contractors and the commercial sector. Now that is fine but I don't see how one PKI user should get to dictate terms to the rest of us. It is permitted by the X.509v3 spec and this is a purely operational matter. PKIX should never have stuck their nose in and they should take it out. On Thu, May 31, 2012 at 10:08 AM, Miller, Timothy J. wrote: > On 5/30/12 6:31 PM, "Wan-Teh Chang" wrote: > > >Is the US DoD using the name constraints extension? > > The Federal Bridge CA uses critical NC in cross-certs it issues. > > -- T > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --e89a8f643588f71f2a04c155fdc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In the context of bridge CA I agree that the NCs would have to be marked cr= itical. Otherwise every agency could issue certs for every other agency.
Commercial CA certification relationships are far more res= trictive and in particular they are not bidirectional.


We have a disagreement here between the = US govt and their contractors and the commercial sector. Now that is fine b= ut I don't see how one PKI user should get to dictate terms to the rest= of us.

It is permitted by the X.509v3 spec and this is a purel= y operational matter. PKIX should never have stuck their nose in and they s= hould take it out.
--e89a8f643588f71f2a04c155fdc8-- From kent@bbn.com Thu May 31 07:44:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E61821F8700 for ; Thu, 31 May 2012 07:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkuQaYIu6YCI for ; Thu, 31 May 2012 07:44:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9D33421F86F7 for ; Thu, 31 May 2012 07:44:01 -0700 (PDT) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49222) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sa6b1-000Gzs-Bq; Thu, 31 May 2012 10:43:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> Date: Thu, 31 May 2012 10:35:04 -0400 To: Wan-Teh Chang From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:44:03 -0000 At 4:31 PM -0700 5/30/12, Wan-Teh Chang wrote: >RFC 2459 (a predecessor of RFC 5280) is 129 pages long. > >Isn't it possible that the reviewers of such a long document may have >overlooked the full implications of "[The name constraints] extension >MUST be critical"? > >Is the US DoD using the name constraints extension? > >Thanks, >Wan-Teh The U.S. federal PKI bridge (more broader than the DoD) relies on the name constraints extension in cross certs. Steve From SChokhani@cygnacom.com Thu May 31 07:51:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11A121F871C for ; Thu, 31 May 2012 07:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgNrtbm-ffE7 for ; Thu, 31 May 2012 07:51:16 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id C63E221F86DC for ; Thu, 31 May 2012 07:51:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,692,1330923600"; d="scan'208,217";a="1076985" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 31 May 2012 10:51:10 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 31 May 2012 10:51:10 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker , "Miller, Timothy J." Date: Thu, 31 May 2012 10:51:08 -0400 Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac0/Os4K0ktVSwshQ1awvkW4LT3eQgAATszg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F662A35scygexch7cygnac_" MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:51:18 -0000 --_000_B83745DA469B7847811819C5005244AF0F662A35scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The issue does not have anything to do with the type of PKI. As mentioned previously, X.509 does not call for any of the extensions in t= he certificate to be critical. 5280 profile choice is based on security since marking the constraints exte= nsions NC exposes relying parties that do not understand the semantics of t= he extensions. If you used X.509 as a model, basic constraints will not be marked critical= either. This crusade seems to be driven by outlier browsers' lack of support for th= e extension or by the desire to compromise security to enhance interoperabi= lity. I started this thread to build consensus on options. There are other threa= ds to voice opinions on. Let us keep this thread to discuss the options to build consensus since onc= e again no one is saying anything new. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Phi= llip Hallam-Baker Sent: Thursday, May 31, 2012 10:36 AM To: Miller, Timothy J. Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality In the context of bridge CA I agree that the NCs would have to be marked cr= itical. Otherwise every agency could issue certs for every other agency. Commercial CA certification relationships are far more restrictive and in p= articular they are not bidirectional. We have a disagreement here between the US govt and their contractors and t= he commercial sector. Now that is fine but I don't see how one PKI user sho= uld get to dictate terms to the rest of us. It is permitted by the X.509v3 spec and this is a purely operational matter= . PKIX should never have stuck their nose in and they should take it out. On Thu, May 31, 2012 at 10:08 AM, Miller, Timothy J. > wrote: On 5/30/12 6:31 PM, "Wan-Teh Chang" >= wrote: >Is the US DoD using the name constraints extension? The Federal Bridge CA uses critical NC in cross-certs it issues. -- T _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ --_000_B83745DA469B7847811819C5005244AF0F662A35scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The issue do= es not have anything to do with the type of PKI.

 

As= mentioned previously, X.509 does not call for any of the extensions in the= certificate to be critical.

=  

5280 profile choice is= based on security since marking the constraints extensions NC exposes rely= ing parties that do not understand the semantics of the extensions.

 

If you used X.509 as a model, basic constraints will not b= e marked critical either.

 

This crusade seems to be = driven by outlier browsers’ lack of support for the extension or by t= he desire to compromise security to enhance interoperability.

 

I started this thread to build consensus on options.  There= are other threads to voice opinions on.

 

Let us kee= p this thread to discuss the options to build consensus since once again no= one is saying anything new.

=  

From: pkix-bounces@ietf.org = [mailto:pkix-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
= Sent: Thursday, May 31, 2012 10:36 AM
To: Miller, Timothy = J.
Cc: IETF PKIX
Subject: Re: [pkix] Way Forward: Name = Constraints Criticality

&nbs= p;

In the context of bridge CA I agree that t= he NCs would have to be marked critical. Otherwise every agency could issue= certs for every other agency.

 

Commercial CA certificatio= n relationships are far more restrictive and in particular they are not bid= irectional.

 =

 

We have a disagreement here between the US govt and their con= tractors and the commercial sector. Now that is fine but I don't see how on= e PKI user should get to dictate terms to the rest of us.

 

It is permitted by the X.509v3 spec and this is a purely operational= matter. PKIX should never have stuck their nose in and they should take it= out.

 <= /p>

On Thu, May 31, 2012 at 10:08 AM, Miller, Timo= thy J. <tmiller@m= itre.org> wrote:

On 5/30/12 6:31 PM, "Wan-Teh Chang" <wtc@google.com> wrote:

>Is th= e US DoD using the name constraints extension?

The Federal Bridge CA uses critical NC in cross-certs it issue= s.

-- T


_____________________= __________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix<= o:p>



 

--
Website: http://hallambaker.com/

=
= --_000_B83745DA469B7847811819C5005244AF0F662A35scygexch7cygnac_-- From hallam@gmail.com Thu May 31 07:56:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101A721F86E1 for ; Thu, 31 May 2012 07:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.405 X-Spam-Level: X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn1UYIcoBDiY for ; Thu, 31 May 2012 07:56:50 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED49821F86D6 for ; Thu, 31 May 2012 07:56:49 -0700 (PDT) Received: by ggnc4 with SMTP id c4so979693ggn.31 for ; Thu, 31 May 2012 07:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vMlwccWRpR9064B0uUuyil7tYszv55o/Few193HZZzk=; b=gr5T32V475aCWcKkpcuB5PmnSBe2Kcx0ATd4AOVyp0OZRN0EtOjR9Zb6m7Tq1LF9sa ByNc7YHClchGD2LBBgRPUOyGngyhO4pGo1dueAD5/LGefYJFPfRwiYZ+Vw8wpREsoH7k sr6ZK4f/svgl7KcAGcfxoO1kt0p2aAtKABjBfnR2ncnFSA6I90NxsUhOPVLvJ/v0cD3j 8PVbs25GUYtmE4GxcNfF03Y1gKN0bI5fqloP1AIEy76E8B8qdYohioJmBq0LlMzucSxE dtexZw3wATeJdj2XhB64EBIx6ut8lyWlcA3D/jfAAwqltqLLyQxVoK0a7KKDHs0pOWd5 Pmbg== MIME-Version: 1.0 Received: by 10.60.10.99 with SMTP id h3mr2357930oeb.72.1338476209364; Thu, 31 May 2012 07:56:49 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Thu, 31 May 2012 07:56:49 -0700 (PDT) In-Reply-To: <4FC77AC0.8070708@cs.tcd.ie> References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <4FC68AC2.7090007@free.fr> <4FC68E74.50709@nist.gov> <4FC6A4D7.7070505@cs.tcd.ie> <4FC76B02.5070604@cs.tcd.ie> <4FC77AC0.8070708@cs.tcd.ie> Date: Thu, 31 May 2012 10:56:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=e89a8fb1fbfaffe08504c15646b2 Cc: "pkix@ietf.org" Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:56:51 -0000 --e89a8fb1fbfaffe08504c15646b2 Content-Type: text/plain; charset=ISO-8859-1 Open-ness depends on where you sit. I just don't find the PKIX DoD cabal to be in the least bit open or representative of my industry. On Thu, May 31, 2012 at 10:05 AM, Stephen Farrell wrote: > > > On 05/31/2012 02:10 PM, Yoav Nir wrote: > > > > On May 31, 2012, at 3:58 PM, Stephen Farrell wrote: > > > >> > >> > >> On 05/31/2012 01:48 PM, Phillip Hallam-Baker wrote: > >>> The point of standards is to achieve interoperability. > >> > >> Sure. > >> > >>> You are defending a standard that requires the industry to issue > >>> certificates that are going to break interoperability. > >> > >> Nope. I'm not "defending" anything, nor am I going on > >> any offensive. > >> > >> I was correcting some wrong statements you made and > >> suggesting a way forward. > > > > I don't see how PHB is wrong here. > > I think if you read what I wrote you'd see that I was correcting > wrong statements, e.g. cab forum are more open, that there is still > a draft standard. I wasn't getting back into the meat of the > extended discussion we had on this before. And I'm still not, > other than to point out that there is the ISE route. > > S > > > > It would be wrong for an RP to check that a certificate complies with > RFC 5280. Suppose the discussion of a few months ago ended differently, > and the WG was convinced to remove the requirement in RFC 5280 that name > constraints MUST be critical. We would then issue a new RFC (7280?) that > said so. Soon there would be certificates around with non-critical name > constraints, perfectly compliant with the new standard, but the old > client would reject them. > > > > So PHB is right. The client should not make validation on the > certificates that they comply, unless the standard says that it should (or > must or may). > > > > As David Cooper said, RFC 5280 already says that anyway. > > > > Yoav > > > > > > > -- Website: http://hallambaker.com/ --e89a8fb1fbfaffe08504c15646b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Open-ness depends on where you sit.

I just don't fin= d the PKIX DoD cabal to be in the least bit open or representative of my in= dustry.


On Thu, May= 31, 2012 at 10:05 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie<= /a>> wrote:


On 05/31/2012 02:10 PM, Yoav Nir wrote:
>
> On May 31, 2012, at 3:58 PM, Stephen Farrell wrote:
>
>>
>>
>> On 05/31/2012 01:48 PM, Phillip Hallam-Baker wrote:
>>> The point of standards is to achieve interoperability.
>>
>> Sure.
>>
>>> You are defending a standard that requires the industry to iss= ue
>>> certificates that are going to break interoperability.
>>
>> Nope. I'm not "defending" anything, nor am I going o= n
>> any offensive.
>>
>> I was correcting some wrong statements you made and
>> suggesting a way forward.
>
> I don't see how PHB is wrong here.

I think if you read what I wrote you'd see that I was correcting<= br> wrong statements, e.g. cab forum are more open, that there is still
a draft standard. I wasn't getting back into the meat of the
extended discussion we had on this before. And I'm still not,
other than to point out that there is the ISE route.

S


> It would be wrong for an RP to check that a certificate complies with<= br> RFC 5280. Suppose the discussion of a few months ago ended differently,
and the WG was convinced to remove the requirement in RFC 5280 that name constraints MUST be critical. We would then issue a new RFC (7280?) that said so. Soon there would be certificates around with non-critical name
constraints, perfectly compliant with the new standard, but the old
client would reject them.
>
> So PHB is right. The client should not make validation on the certific= ates that they comply, unless the standard says that it should (or must or = may).
>
> As David Cooper said, RFC 5280 already says that anyway.
>
> Yoav
>
>
>



--
= Website:
http://hallambaker.com/
--e89a8fb1fbfaffe08504c15646b2-- From tmiller@mitre.org Thu May 31 07:58:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E907421F86F3 for ; Thu, 31 May 2012 07:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYqboG73gikp for ; Thu, 31 May 2012 07:58:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D858621F86EE for ; Thu, 31 May 2012 07:58:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 76B1F21B1B95; Thu, 31 May 2012 10:58:05 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 69F2521B1B9E; Thu, 31 May 2012 10:58:05 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0283.003; Thu, 31 May 2012 10:58:05 -0400 From: "Miller, Timothy J." To: Santosh Chokhani , Phillip Hallam-Baker Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac08GsNsKS+J4IylThCqrltUJuYcsQA1ZLMAAGgkQwAACv6ugAAEY/8AAAPYhYAAFChsAAALdGaAAACD4AD//64bAA== Date: Thu, 31 May 2012 14:58:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [172.31.138.76] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:58:11 -0000 I guess I just don't see why you'd include NC in a cert but *not* mark it critical. Non-critical NC basically says "Beyond this point you should {only see/never see} the following names, but we don't actually care if you pay attention." -- T On 5/31/12 9:51 AM, "Santosh Chokhani" wrote: >The issue does not have anything to do with the type of PKI. >=20 >As mentioned previously, X.509 does not call for any of the extensions in >the certificate to be critical. >=20 >5280 profile choice is based on security since marking the constraints >extensions NC exposes relying parties that do not understand the >semantics of the extensions. >=20 >If you used X.509 as a model, basic constraints will not be marked >critical either. >=20 >This crusade seems to be driven by outlier browsers=B9 lack of support for >the extension or by the desire to compromise security to enhance >interoperability. >=20 >I started this thread to build consensus on options. There are other >threads to voice opinions on. >=20 >Let us keep this thread to discuss the options to build consensus since >once again no one is saying anything new. >=20 >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] >On Behalf Of Phillip Hallam-Baker >Sent: Thursday, May 31, 2012 10:36 AM >To: Miller, Timothy J. >Cc: IETF PKIX >Subject: Re: [pkix] Way Forward: Name Constraints Criticality >=20 >In the context of bridge CA I agree that the NCs would have to be marked >critical. Otherwise every agency could issue certs for every other agency. >=20 > >Commercial CA certification relationships are far more restrictive and in >particular they are not bidirectional. > >=20 > >=20 > >We have a disagreement here between the US govt and their contractors and >the commercial sector. Now that is fine but I don't see how one PKI user >should get to dictate terms to the rest of us. > >=20 > >It is permitted by the X.509v3 spec and this is a purely operational >matter. PKIX should never have stuck their nose in and they should take >it out. > >=20 >On Thu, May 31, 2012 at 10:08 AM, Miller, Timothy J. >wrote: >On 5/30/12 6:31 PM, "Wan-Teh Chang" wrote: > >>Is the US DoD using the name constraints extension? > >The Federal Bridge CA uses critical NC in cross-certs it issues. > >-- T > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > > > > > > >=20 > >--=20 >Website: http://hallambaker.com/ > > > From SChokhani@cygnacom.com Thu May 31 08:25:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A8011E8095 for ; Thu, 31 May 2012 08:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p07jjky63p09 for ; Thu, 31 May 2012 08:25:48 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFBD21F8776 for ; Thu, 31 May 2012 08:25:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,693,1330923600"; d="scan'208";a="5164336" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 31 May 2012 11:25:46 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 31 May 2012 11:25:46 -0400 From: Santosh Chokhani To: Rob Stradling , "pkix@ietf.org" Date: Thu, 31 May 2012 11:25:44 -0400 Thread-Topic: [pkix] Integrated OCSP Responders / Key Usage bits Thread-Index: Ac0/M691psHBgm+qQk6FaMi0biITKQADXCDA Message-ID: References: <4FBF4B37.1090208@comodo.com> <4FC487AB.6000603@comodo.com> <4FC775FD.2020006@comodo.com> In-Reply-To: <4FC775FD.2020006@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:25:51 -0000 Rob, You have three options for the ongoing operations: 1. Recut the CA certificate with DS bit set. 2. Issue yourself a responder certificate, i.e., certify the same key, sig= n it and put no check on it. Even the life of the certificate can extend t= o the CA certificate life 3. Do nothing and wait until some OCSP client barfs on it. For new installs, it seems the safe thing to do is set the DS bit on in the= CA certificate or use option 2 above.=20 -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rob= Stradling Sent: Thursday, May 31, 2012 9:46 AM To: pkix@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits On 29/05/12 09:24, Rob Stradling wrote: > On 25/05/12 10:04, Rob Stradling wrote: >> Which Key Usage bits (if any) are required to be present in a CA=20 >> Certificate that directly signs OCSP Responses? > >> IMHO, it'd kinda make sense for the cRLSign bit to govern whether or=20 >> not the CA Certificate can directly sign OCSP Responses, but sadly I=20 >> can find no text to support this idea. > > I've unearthed some text to support this idea, so at least I'm now=20 > sure I didn't completely make it up myself! > > RFC2459 said... > "The cRLSign bit is asserted when the subject public key is used for=20 > verifying a signature on revocation information (e.g., a CRL)." > "The digitalSignature bit is asserted when the subject public key is=20 > used with a digital signature mechanism to support security services=20 > other than...revocation information signing (bit 6)." > > Obviously an OCSP Response's signature is "a signature on revocation=20 > information". > > Why did RFC3280 change the required bit for signing non-CRL revocation=20 > information from "cRLSign" to "digitalSignature"? > > Could we change it back, or at least allow either "cRLSign" or=20 > "digitalSignature" to be deemed acceptable for signing non-CRL=20 > revocation information? PHB just noted in another thread that "The point of standards is to achieve= interoperability". I'll restate my question with this thought in mind. We (Comodo) sign OCSP Responses directly from CA Certificates that have the= keyCertSign and cRLSign bits set but the digitalSignature bit unset.=20 This is/was fully compliant with RFC2459, but (I realized only this week) not compliant with 3280/5280. Thus far, I've not encountered any client software that rejects our OCSP Re= sponses. But to "achieve interoperability", I wish to ensure that no future client s= oftware rejects our OCSP Responses on the basis that the digitalSignature b= it is not set in the CA Certificates. So, can we please reinstate the 2459 text that "The cRLSign bit is asserted= when the subject public key is used for verifying a signature on revocatio= n information" or at least say that cRLSign and/or digitalSignature is suff= icient for this purpose? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From rob.stradling@comodo.com Thu May 31 08:36:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2511E810C for ; Thu, 31 May 2012 08:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvSe+gavnwO0 for ; Thu, 31 May 2012 08:36:29 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id A072111E8100 for ; Thu, 31 May 2012 08:36:28 -0700 (PDT) Received: (qmail 22561 invoked from network); 31 May 2012 15:36:27 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 31 May 2012 15:36:27 -0000 Received: (qmail 28494 invoked by uid 1000); 31 May 2012 15:36:26 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 31 May 2012 16:36:26 +0100 Message-ID: <4FC78FFA.1070205@comodo.com> Date: Thu, 31 May 2012 16:36:26 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Santosh Chokhani References: <4FBF4B37.1090208@comodo.com> <4FC487AB.6000603@comodo.com> <4FC775FD.2020006@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:36:30 -0000 On 31/05/12 16:25, Santosh Chokhani wrote: > Rob, > > You have three options for the ongoing operations: > > 1. Recut the CA certificate with DS bit set. > 2. Issue yourself a responder certificate, i.e., certify the same key, sign it and put no check on it. Even the life of the certificate can extend to the CA certificate life > 3. Do nothing and wait until some OCSP client barfs on it. > > For new installs, it seems the safe thing to do is set the DS bit on in the CA certificate or use option 2 above. Hi Santosh. Yes, I'll make sure the digitalSignature bit is set in new CA Certificates we issue in the future. Recutting our existing CA certificates is not an option. There are rather a lot of them and they are widely deployed. I don't want to have to use dedicated responder certificates unless I really have to. Are you saying that trying to "fix" the standards is not really an option? What security hole would be introduced by once again allowing the "crlSign" bit to authorize the CA certificate as an Integrated Responder? > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rob Stradling > Sent: Thursday, May 31, 2012 9:46 AM > To: pkix@ietf.org > Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits > > On 29/05/12 09:24, Rob Stradling wrote: >> On 25/05/12 10:04, Rob Stradling wrote: >>> Which Key Usage bits (if any) are required to be present in a CA >>> Certificate that directly signs OCSP Responses? >> >>> IMHO, it'd kinda make sense for the cRLSign bit to govern whether or >>> not the CA Certificate can directly sign OCSP Responses, but sadly I >>> can find no text to support this idea. >> >> I've unearthed some text to support this idea, so at least I'm now >> sure I didn't completely make it up myself! >> >> RFC2459 said... >> "The cRLSign bit is asserted when the subject public key is used for >> verifying a signature on revocation information (e.g., a CRL)." >> "The digitalSignature bit is asserted when the subject public key is >> used with a digital signature mechanism to support security services >> other than...revocation information signing (bit 6)." >> >> Obviously an OCSP Response's signature is "a signature on revocation >> information". >> >> Why did RFC3280 change the required bit for signing non-CRL revocation >> information from "cRLSign" to "digitalSignature"? >> >> Could we change it back, or at least allow either "cRLSign" or >> "digitalSignature" to be deemed acceptable for signing non-CRL >> revocation information? > > PHB just noted in another thread that "The point of standards is to achieve interoperability". I'll restate my question with this thought in mind. > > We (Comodo) sign OCSP Responses directly from CA Certificates that have the keyCertSign and cRLSign bits set but the digitalSignature bit unset. > This is/was fully compliant with RFC2459, but (I realized only this > week) not compliant with 3280/5280. > > Thus far, I've not encountered any client software that rejects our OCSP Responses. > > But to "achieve interoperability", I wish to ensure that no future client software rejects our OCSP Responses on the basis that the digitalSignature bit is not set in the CA Certificates. > > So, can we please reinstate the 2459 text that "The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information" or at least say that cRLSign and/or digitalSignature is sufficient for this purpose? > > -- > Rob Stradling > Senior Research& Development Scientist > COMODO - Creating Trust Online > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From mrex@sap.com Thu May 31 09:00:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F073821F8526 for ; Thu, 31 May 2012 09:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGBTZfQNlNQq for ; Thu, 31 May 2012 09:00:07 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18521F8512 for ; Thu, 31 May 2012 09:00:06 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4VFxmaJ012383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 May 2012 17:59:48 +0200 (MEST) In-Reply-To: <4FC78FFA.1070205@comodo.com> To: Rob Stradling Date: Thu, 31 May 2012 17:59:48 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:00:08 -0000 Rob Stradling wrote: > > Are you saying that trying to "fix" the standards is not really an option? > > What security hole would be introduced by once again allowing the > "crlSign" bit to authorize the CA certificate as an Integrated Responder? This is _NOT_ a defect of rfc2560, it was a conscious design decision, and a careful implementor should have seen this. So "fixing" does not exist as an option only changing the behaviour in a successor OCSP spec. But should still account for implementations based on rfc2560 alone. What is more confusing to me is that you're PKI software did not error on your attempt to sign OCSP responses without the DigitalSignature bit in your CA cert. When sensibly implemented, a signature creation function should perform a number of plausibility checks on signature creation (including KeyUsage and Validity), because it does not make sense (other than in very limited debug situations) to create digital signatures that receipients will very probably fail verifying. -Martin From denis.pinkas@bull.net Thu May 31 09:22:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0025D21F86A5 for ; Thu, 31 May 2012 09:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiwZS6MsMv+K for ; Thu, 31 May 2012 09:22:55 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDE721F869C for ; Thu, 31 May 2012 09:22:55 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 5F25F12000E; Thu, 31 May 2012 18:22:54 +0200 (CEST) In-Reply-To: <4FC6AEDA.4010709@cs.tcd.ie> References: <4FC6AEDA.4010709@cs.tcd.ie> To: rra@stanford.edu, hotz@jpl.nasa.gov, Jim Schaad MIME-Version: 1.0 X-KeepSent: 2C174BF8:9661F84B-C1257A0F:0035B9F3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Thu, 31 May 2012 18:22:53 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 31/05/2012 18:22:54, Serialize complete at 31/05/2012 18:22:54 Content-Type: multipart/alternative; boundary="=_alternative 0059D8ADC1257A0F_=" Cc: pkix Subject: Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 16:22:57 -0000 Message en plusieurs parties au format MIME --=_alternative 0059D8ADC1257A0F_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVucnksIFJ1c3MgYW5kIEppbSwNCg0KSSBza2ltbWVkIHRocm91Z2ggdGhlIGRvY3VtZW50IGFu ZCByZWFkIHRoZSBmb2xsb3dpbmcgdHdvIHNlbnRlbmNlczoNCg0KICAgVGhlIHB1YmxpYyBrZXkg aW4gdGhlIHJlcXVlc3QgaXMgc2VudCBpbiB0aGUgY2xlYXIsIGFuZCB3aXRob3V0IGFueQ0KICAg Z3VhcmFudGVlcyB0aGF0IHRoZSByZXF1ZXN0b3IgYWN0dWFsbHkgcG9zc2Vzc2VzIHRoZSBjb3Jy ZXNwb25kaW5nDQogICBwcml2YXRlIGtleS4NCg0KICAgW1JGQzQyMTFdLCBBcHBlbmRpeCBDIGNv bnRhaW5zIGEgbW9yZSBkZXRhaWxlZCBkaXNjdXNzaW9uIG9mIHdoeSANCnByb29mLW9mLQ0KICAg cG9zc2Vzc2lvbiBpcyBpbXBvcnRhbnQuDQoNCkkgaGF2ZSBjb25jZXJucyB3aXRoIGJvdGggc2Vu dGVuY2VzLg0KDQpbUkZDNDIxMV0gaXMgaW5jb3JyZWN0IGFuZCB0aGlzIGhhcyBzZWN1cml0eSBp bXBsaWNhdGlvbnMgb24gdGhlIHByb3Bvc2VkIA0KcHJvdG9jb2wuDQoNCkEgcGFydCBvZiBBbm5l eCBDIGlzIGNvcGllZCBiZWxvdywgd2l0aCB0ZXh0IHdoaWNoIHNob3VsZCBiZSBhZGRlZCBpbiBi b2xkIA0KY2hhcmFjdGVycy4NCg0KICAgUE9QIGlzIGltcG9ydGFudCBiZWNhdXNlIGl0IHByb3Zp ZGVzIGFuIGFwcHJvcHJpYXRlIGxldmVsIG9mDQogICBhc3N1cmFuY2Ugb2YgdGhlIGNvcnJlY3Qg b3BlcmF0aW9uIG9mIHRoZSBQS0kgYXMgYSB3aG9sZS4gIEF0IGl0cw0KICAgbG93ZXN0IGxldmVs LCBQT1AgY291bnRlcnMgdGhlICJzZWxmLWluZmxpY3RlZCBkZW5pYWwgb2Ygc2VydmljZSI7DQog ICB0aGF0IGlzLCBhbiBlbnRpdHkgdm9sdW50YXJpbHkgZ2V0cyBhIGNlcnRpZmljYXRlIHRoYXQg Y2Fubm90IGJlIHVzZWQNCiAgIHRvIHNpZ24gb3IgZW5jcnlwdC9kZWNyeXB0IGluZm9ybWF0aW9u LiAgSG93ZXZlciwgYXMgdGhlIGZvbGxvd2luZw0KICAgdHdvIGV4YW1wbGVzIGRlbW9uc3RyYXRl LCBQT1AgYWxzbyBjb3VudGVycyBsZXNzIGRpcmVjdCwgYnV0IG1vcmUNCiAgIHNldmVyZSwgdGhy ZWF0czoNCg0KICAgICAgUE9QIGZvciBzaWduaW5nIGtleXM6IGl0IGlzIGltcG9ydGFudCB0byBw cm92aWRlIFBPUCBmb3Iga2V5cyB1c2VkDQogICAgICB0byBzaWduIG1hdGVyaWFsLCBpbiBvcmRl ciB0byBwcm92aWRlIG5vbi1yZXB1ZGlhdGlvbiBvZg0KICAgICAgdHJhbnNhY3Rpb25zLiAgRm9y IGV4YW1wbGUsIHN1cHBvc2UgQWxpY2UgbGVnaXRpbWF0ZWx5IGhhcyBwcml2YXRlDQogICAgICBr ZXkgWCBhbmQgaXRzIGNvcnJlc3BvbmRpbmcgcHVibGljIGtleSBZLiAgQWxpY2UgaGFzIGEgY2Vy dGlmaWNhdGUNCiAgICAgIGZyb20gQ2hhcmxpZSwgYSBDQSwgY29udGFpbmluZyBZLiAgQWxpY2Ug dXNlcyBYIHRvIHNpZ24gYQ0KICAgICAgdHJhbnNhY3Rpb24gVC4gIFdpdGhvdXQgUE9QLCBNYWwg Y291bGQgYWxzbyBnZXQgYSBjZXJ0aWZpY2F0ZSBmcm9tDQogICAgICBDaGFybGllIGNvbnRhaW5p bmcgdGhlIHNhbWUgcHVibGljIGtleSwgWS4gIE5vdywgdGhlcmUgYXJlIHR3bw0KICAgICAgcG9z c2libGUgdGhyZWF0czogTWFsIGNvdWxkIGNsYWltIHRvIGhhdmUgYmVlbiB0aGUgcmVhbCBzaWdu ZXIgb2YNCiAgICAgIFQ7IG9yIEFsaWNlIGNhbiBmYWxzZWx5IGRlbnkgc2lnbmluZyBULCBjbGFp bWluZyB0aGF0IGl0IHdhcw0KICAgICAgaW5zdGVhZCBNYWwuICBPbmUgY291bGQgc2F5LCBzaW5j ZSBubyBvbmUgY2FuIHJlbGlhYmx5IHByb3ZlIHRoYXQgDQpNYWwgZGlkIA0KICAgICAgb3IgZGlk IG5vdCBldmVyIHBvc3Nlc3MgWCwgbmVpdGhlciBvZiB0aGVzZSBjbGFpbXMgY2FuIGJlIHJlZnV0 ZWQsIA0KYW5kDQogICAgICB0aHVzIHRoZSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IGFuZCB0aGUgY29u ZmlkZW5jZSBpbiB0aGUgUEtJIGhhcw0KICAgICAgYmVlbiBkZWZlYXRlZC4gIEhvd2V2ZXIsIHNp bmNlIEFsaWNlIGxlZ2l0aW1hdGVseSBoYXMgcHJpdmF0ZQ0KICAgICAga2V5IFggYW5kIGl0cyBj b3JyZXNwb25kaW5nIHB1YmxpYyBrZXkgWSwgc2hlIHdpbGwgYXNrIGhlciANCmNlcnRpZmljYXRl IGZpcnN0LiANCiAgICAgIFdoZW4gdGhlIEFsaWNl4oCZcyBjZXJ0aWZpY2F0ZSB3aWxsIGJlIGRp c3RyaWJ1dGVkLCBNYWwgdGFrZXMgYSBjb3B5IA0Kb2YgDQogICAgICB0aGUgcHVibGljIGtleSBw cmVzZW50IGluIGhlciBjZXJ0aWZpY2F0ZSBhbmQgcmVxdWVzdHMgYSBjZXJ0aWZpY2F0ZSANCg0K ICAgICAgZm9yIGhpbXNlbGYuIEJ5IGNvbXBhcmluZyB0aGUgbG9ncyBpbiB0aGUgQ0EgZGF0YWJh c2VzLCBpdCBpcyANCnBvc3NpYmxlIA0KICAgICAgdG8ga25vdyB3aGljaCBvbmUgYXNrZWQgdGhl IGNlcnRpZmljYXRlIGZpcnN0IGFuZCB0aGVuIHRlbGwgdGhhdCANCkFsaWNlIA0KICAgICAgaXMg dGhlIGxlZ2l0aW1hdGUgaG9sZGVyLiBIb3dldmVyLCB0aGlzIG1lYW5zIHRoYXQgdGhlIHB1Ymxp YyBrZXkgDQogICAgICBtdXN0IGJlIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0ZWQgZHVyaW5nIGl0 cyB0cmFuc2l0IHRvIHRoZSBSQSwgaW4gDQpvcmRlciB0byANCiAgICAgIHByZXZlbnQgTWFsIHRv IGNvcHkgaXQuIChPZiBjb3Vyc2UsIGlmIE1hbCByZWFsbHkgZGlkIHBvc3Nlc3MgWCwgDQpBbGlj ZSdzDQogICAgICBwcml2YXRlIGtleSwgdGhlbiBubyBQT1AgbWVjaGFuaXNtIGluIHRoZSB3b3Js ZCB3aWxsIGhlbHAsIGJ1dA0KICAgICAgdGhhdCBpcyBhIGRpZmZlcmVudCBwcm9ibGVtLikNCg0K ICAgICAgTm90ZSB0aGF0IG9uZSBsZXZlbCBvZiBwcm90ZWN0aW9uIGNhbiBiZSBnYWluZWQgYnkg aGF2aW5nIEFsaWNlDQogICAgICAoYXMgdGhlIHRydWUgc2lnbmVyIG9mIHRoZSB0cmFuc2FjdGlv bikgaW5jbHVkZSBpbiB0aGUgc2lnbmVkDQogICAgICBpbmZvcm1hdGlvbiwgaGVyIGNlcnRpZmlj YXRlIG9yIGFuIGlkZW50aWZpZXIgb2YgaGVyIGNlcnRpZmljYXRlDQogICAgICAoZS5nLiwgYSBo YXNoIG9mIGhlciBjZXJ0aWZpY2F0ZSkuICBBbGljZSBjb3VsZCBtYWxpY2lvdXNseSBpbmNsdWRl IA0KICAgICAgTWFs4oCZcyBjZXJ0aWZpY2F0ZSByYXRoZXIgdGhhbiBoZXIgY2VydGlmaWNhdGUg aW4gdGhlIHRyYW5zYWN0aW9uLiBJbiANCmNhc2UgDQogICAgICBvZiBhIGRpc3B1dGUsIHRoZSBs b2dzIHByZXNlbnQgaW4gdGhlIENBIGRhdGFiYXNlcyB3aWxsIGJlIHVzZWQgYW5kIA0KICAgICAg dGhlIG9ubHkgbGVnaXRpbWF0ZSBjZXJ0aWZpY2F0ZSB3aWxsIGJlIHRoZSBvbmUgd2hpY2ggd2Fz IGlzc3VlZCANCmVhcmxpZXIuDQogICAgICBJdCBpcyB0aHVzIHBvc3NpYmxlIHRvIGRlbW9uc3Ry YXRlIHRoYXQgQWxpY2Ugd2FzIG1hbGljaW91cy4NCiANClRoZSBmb2xsb3dpbmcgdGV4dCBmcm9t IEFubmV4IEMgc2hvdWxkIGJlIGRlbGV0ZWQuDQoNCiAgICAgIFRoaXMgbWlnaHQgbWFrZSBpdCBt b3JlDQogICAgICBkaWZmaWN1bHQgZm9yIE1hbCB0byBjbGFpbSBhdXRob3JzaGlwOyBoZSB3b3Vs ZCBoYXZlIHRvIGFzc2VydA0KICAgICAgdGhhdCBoZSBpbmNvcnJlY3RseSBpbmNsdWRlZCBBbGlj ZSdzIGNlcnRpZmljYXRlLCByYXRoZXIgdGhhbiBoaXMNCiAgICAgIG93bi4gIEhvd2V2ZXIsIGl0 IHdvdWxkIG5vdCBzdG9wIEFsaWNlIGZyb20gZmFsc2VseSByZXB1ZGlhdGluZw0KICAgICAgaGVy IGFjdGlvbnMuICBTaW5jZSB0aGUgY2VydGlmaWNhdGUgaXRzZWxmIGlzIGEgcHVibGljIGl0ZW0s IE1hbA0KICAgICAgaW5kZWVkIGNvdWxkIGhhdmUgaW5zZXJ0ZWQgQWxpY2UncyBjZXJ0aWZpY2F0 ZSBvciBpZGVudGlmaWVyIGludG8NCiAgICAgIHRoZSBzaWduZWQgdHJhbnNhY3Rpb24sIGFuZCB0 aHVzIGl0cyBwcmVzZW5jZSBkb2VzIG5vdCBpbmRpY2F0ZQ0KICAgICAgdGhhdCBBbGljZSB3YXMg dGhlIG9uZSB3aG8gcGFydGljaXBhdGVkIGluIHRoZSBub3ctcmVwdWRpYXRlZA0KICAgICAgdHJh bnNhY3Rpb24uICBUaGUgb25seSByZWxpYWJsZSB3YXkgdG8gc3RvcCB0aGlzIGF0dGFjayBpcyB0 bw0KICAgICAgcmVxdWlyZSB0aGF0IE1hbCBwcm92ZSBoZSBwb3NzZXNzZXMgWCBiZWZvcmUgaGlz IGNlcnRpZmljYXRlIGlzDQogICAgICBpc3N1ZWQuDQoNClRoZSBpbXBsaWNhdGlvbiBpcyB0aGF0 IHRoZSBtZXNzYWdlIGRlZmluZWQgaW4gZHJhZnQtaG90ei1reDUwOSB3aGljaCANCmNhcnJpZXMg dGhlIHB1YmxpYyBrZXkgDQpNVVNUIEJFIHNvbWVob3cgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRl Z3JpdHkgcHJvdGVjdGVkLg0KDQpEZW5pcw0KDQpQUy4gSSBhbSBub3Qgb24gdGhlIEtlcmJlcm9z IGxpc3QsIHNvIHBsZWFzZSByZXNwb25kIGRpcmVjdGx5IG9yL2FuZCB0byANCnRoZSBwa2l4IGxp c3QuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGUgOiAgICBTdGVwaGVuIEZhcnJlbGwg PHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+DQpBIDogICAgIHBraXggPHBraXhAaWV0Zi5vcmc+ LCAia3JiLXdnIG1haWxpbmcgbGlzdCANCihpZXRmLWtyYi13Z0BsaXN0cy5hbmwuZ292KSIgPGll dGYta3JiLXdnQGxpc3RzLmFubC5nb3Y+DQpEYXRlIDogIDMxLzA1LzIwMTIgMDE6MzYNCk9iamV0 IDogW3BraXhdIFJGQyA1NzQyIHJldmlldyBvZiBkcmFmdC1ob3R6LWt4NTA5DQpFbnZvecOpIHBh ciA6ICAgIHBraXgtYm91bmNlc0BpZXRmLm9yZw0KDQoNCg0KDQpIaSwNCg0KVGhlIGluZGVwZW5k ZW50IHN1Ym1pc3Npb25zIGVkaXRvciAoSVNFKSBoYXMgYXNrZWQgdGhlDQpJRVNHIHRvIGRvIGFu IFJGQyA1NzQyIHJldmlldyBvZiB0aGlzIFsxXSBkb2N1bWVudC4NCg0KVGhhdCByZXZpZXcgaXMg dG8gY2hlY2sgdGhhdCB0aGUgcHVibGljYXRpb24gb2YgdGhpcw0KaW5kZXBlbmRlbnQgc3RyZWFt IHN1Ym1pc3Npb24gd291bGQgbm90IGNvbmZsaWN0IHdpdGgNCklFVEYgd29yay4NCg0KSW4gdGhp cyBjYXNlLCB0aGUgd29yayBpcyBjbGVhcmx5IHJlbGF0ZWQgdG8gdGhlIHBraXgNCmFuZCBrZXJi ZXJvcyB3b3JraW5nIGdyb3VwcywgaGVuY2UgdGhpcyBtYWlsLg0KDQpOb3RlOiB0aGlzIG1haWwg aXMgbm90IGEgcmVxdWVzdCBmb3IgYSB0ZWNobmljYWwgcmV2aWV3DQpvZiB0aGUgY29udGVudCwg YnV0IHJhdGhlciBhc2tpbmcgaWYgcHVibGljYXRpb24gd291bGQNCnNvbWVob3cgYmUgZGFtYWdp bmcgdG8gdGhlIHdvcmsgb2YgdGhlc2Ugd2dzLiAoSWYgeW91DQpkbyBoYXZlIHRlY2huaWNhbCBj b21tZW50cywgc2VuZCB0aGVtIHRvIHRoZSBhdXRob3INCm9yIElTRSkuIElmIHlvdSdyZSBub3Qg c3VyZSBhYm91dCBhbnkgb2YgdGhhdCwgdGhlbg0KcmVhZCBSRkMgNTc0Mi4gWzJdDQoNCkknbGwg dGFrZSBzaWxlbmNlIGFzIG1lYW5pbmcgdGhhdCBub2JvZHkgdGhpbmtzIHRoYXQNCnRoZXJlJ3Mg YSBjb25mbGljdC4gSWYgc29tZW9uZSB0aGlua3MgdGhlcmUgaXMgYQ0KY29uZmxpY3QgbGV0IG1l LCB0aGUgbGlzdCwgb3IgdGhlIHdnIGNoYWlycyBrbm93LiBJbg0KZHVlIGNvdXJzZSwgSSdsbCBi ZSBkb2luZyBteSBvd24gZXZhbHVhdGlvbiBhcyB3ZWxsDQpvZiBjb3Vyc2UsIGFzIHdpbGwgb3Ro ZXIgSUVTRyBtZW1iZXJzLg0KDQpUaGFua3MsDQpTdGVwaGVuLg0KDQpbMV0gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaG90ei1reDUwOS0wNA0KWzJdIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzU3NDINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnBraXggbWFpbGluZyBsaXN0DQpwa2l4QGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgNCg0KDQo= --=_alternative 0059D8ADC1257A0F_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5IZW5yeSwgUnVzcyBhbmQgSmltLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPkkgc2tpbW1lZCB0aHJvdWdoIHRoZSBk b2N1bWVudCBhbmQgcmVhZCB0aGUNCmZvbGxvd2luZyB0d28gc2VudGVuY2VzOjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDtUaGUgcHVibGlj IGtleSBpbiB0aGUgcmVxdWVzdA0KaXMgc2VudCBpbiB0aGUgY2xlYXIsIGFuZCB3aXRob3V0IGFu eTxicj4NCiAmbmJzcDsgZ3VhcmFudGVlcyB0aGF0IHRoZSByZXF1ZXN0b3IgYWN0dWFsbHkgcG9z c2Vzc2VzIHRoZSBjb3JyZXNwb25kaW5nPGJyPg0KICZuYnNwOyBwcml2YXRlIGtleS48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7W1JGQzQy MTFdLCBBcHBlbmRpeCBDIGNvbnRhaW5zDQphIG1vcmUgZGV0YWlsZWQgZGlzY3Vzc2lvbiBvZiB3 aHkgcHJvb2Ytb2YtPGJyPg0KICZuYnNwOyBwb3NzZXNzaW9uIGlzIGltcG9ydGFudC48YnI+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5JIGhhdmUgY29uY2VybnMgd2l0 aCBib3RoIHNlbnRlbmNlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj5bUkZDNDIxMV0gaXMgaW5jb3JyZWN0IGFuZCB0aGlzIGhhcyBzZWN1cml0eQ0KaW1wbGlj YXRpb25zIG9uIHRoZSBwcm9wb3NlZCBwcm90b2NvbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj5BIHBhcnQgb2YgQW5uZXggQyBpcyBjb3BpZWQgYmVsb3csIHdp dGggdGV4dA0Kd2hpY2ggc2hvdWxkIGJlIGFkZGVkIGluIGJvbGQgY2hhcmFjdGVycy48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7UE9QIGlz IGltcG9ydGFudCBiZWNhdXNlIGl0DQpwcm92aWRlcyBhbiBhcHByb3ByaWF0ZSBsZXZlbCBvZjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDthc3N1cmFu Y2Ugb2YgdGhlIGNvcnJlY3Qgb3BlcmF0aW9uDQpvZiB0aGUgUEtJIGFzIGEgd2hvbGUuICZuYnNw O0F0IGl0czwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJz cDtsb3dlc3QgbGV2ZWwsIFBPUCBjb3VudGVycyB0aGUNCiZxdW90O3NlbGYtaW5mbGljdGVkIGRl bmlhbCBvZiBzZXJ2aWNlJnF1b3Q7OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPiZuYnNwOyAmbmJzcDt0aGF0IGlzLCBhbiBlbnRpdHkgdm9sdW50YXJpbHkNCmdldHMgYSBj ZXJ0aWZpY2F0ZSB0aGF0IGNhbm5vdCBiZSB1c2VkPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwO3RvIHNpZ24gb3IgZW5jcnlwdC9kZWNyeXB0IGluZm9y bWF0aW9uLg0KJm5ic3A7SG93ZXZlciwgYXMgdGhlIGZvbGxvd2luZzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDt0d28gZXhhbXBsZXMgZGVtb25zdHJh dGUsIFBPUA0KYWxzbyBjb3VudGVycyBsZXNzIGRpcmVjdCwgYnV0IG1vcmU8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7c2V2ZXJlLCB0aHJlYXRzOjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7IFBPUCBmb3Igc2lnbmluZyBrZXlzOg0KaXQgaXMgaW1wb3J0YW50IHRvIHByb3ZpZGUg UE9QIGZvciBrZXlzIHVzZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyB0byBzaWduIG1hdGVyaWFsLCBpbg0Kb3JkZXIgdG8gcHJvdmlk ZSBub24tcmVwdWRpYXRpb24gb2Y8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0cmFuc2FjdGlvbnMuICZuYnNwO0Zvcg0KZXhhbXBsZSwg c3VwcG9zZSBBbGljZSBsZWdpdGltYXRlbHkgaGFzIHByaXZhdGU8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBrZXkgWCBhbmQgaXRzIGNv cnJlc3BvbmRpbmcNCnB1YmxpYyBrZXkgWS4gJm5ic3A7QWxpY2UgaGFzIGEgY2VydGlmaWNhdGU8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyBmcm9tIENoYXJsaWUsIGEgQ0EsDQpjb250YWluaW5nIFkuICZuYnNwO0FsaWNlIHVzZXMgWCB0 byBzaWduIGE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyB0cmFuc2FjdGlvbiBULiAmbmJzcDtXaXRob3V0DQpQT1AsIE1hbCBjb3VsZCBh bHNvIGdldCBhIGNlcnRpZmljYXRlIGZyb208L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBDaGFybGllIGNvbnRhaW5pbmcgdGhlDQpzYW1l IHB1YmxpYyBrZXksIFkuICZuYnNwO05vdywgdGhlcmUgYXJlIHR3bzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHBvc3NpYmxlIHRocmVh dHM6IE1hbA0KY291bGQgY2xhaW0gdG8gaGF2ZSBiZWVuIHRoZSByZWFsIHNpZ25lciBvZjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFQ7 IG9yIEFsaWNlIGNhbiBmYWxzZWx5DQpkZW55IHNpZ25pbmcgVCwgY2xhaW1pbmcgdGhhdCBpdCB3 YXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyBpbnN0ZWFkIE1hbC4gJm5ic3A7PGI+T25lDQpjb3VsZCBzYXksPC9iPiBzaW5jZSBubyBv bmUgY2FuIHJlbGlhYmx5IHByb3ZlIHRoYXQgTWFsIGRpZCA8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDtvciBkaWQgbm90IGV2ZXIgcG9zc2VzcyBYLCBuZWl0aGVyIG9mIHRoZXNlIGNsYWltcw0K Y2FuIGJlIHJlZnV0ZWQsIGFuZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRodXMgdGhlIHNlcnZpY2UgcHJvdmlkZWQNCmJ5IGFuZCB0 aGUgY29uZmlkZW5jZSBpbiB0aGUgUEtJIGhhczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlZW4gZGVmZWF0ZWQuICZuYnNwOzxiPkhv d2V2ZXIsDQpzaW5jZSBBbGljZSBsZWdpdGltYXRlbHkgaGFzIHByaXZhdGU8L2I+PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsga2V5 IFggYW5kIGl0cyBjb3JyZXNwb25kaW5nDQpwdWJsaWMga2V5IFksIHNoZSB3aWxsIGFzayBoZXIg Y2VydGlmaWNhdGUgZmlyc3QuIDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBXaGVuIHRoZSBBbGljZeKAmXMNCmNlcnRpZmlj YXRlIHdpbGwgYmUgZGlzdHJpYnV0ZWQsIE1hbCB0YWtlcyBhIGNvcHkgb2YgPC9iPjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRo ZSBwdWJsaWMga2V5IHByZXNlbnQNCmluIGhlciBjZXJ0aWZpY2F0ZSBhbmQgcmVxdWVzdHMgYSBj ZXJ0aWZpY2F0ZSA8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9yIGhpbXNlbGYuIEJ5IGNvbXBhcmluZw0KdGhlIGxvZ3Mg aW4gdGhlIENBIGRhdGFiYXNlcywgaXQgaXMgcG9zc2libGUgPC9iPjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIGtub3cgd2hp Y2ggb25lDQphc2tlZCB0aGUgY2VydGlmaWNhdGUgZmlyc3QgYW5kIHRoZW4gdGVsbCB0aGF0IEFs aWNlIDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48Yj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyBpcyB0aGUgbGVnaXRpbWF0ZQ0KaG9sZGVyLiBIb3dldmVyLCB0aGlzIG1l YW5zIHRoYXQgdGhlIHB1YmxpYyBrZXkgPC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPjxiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IG11c3QgYmUgY29uZmlkZW50aWFsaXR5 DQpwcm90ZWN0ZWQgZHVyaW5nIGl0cyB0cmFuc2l0IHRvIHRoZSBSQSwgaW4gb3JkZXIgdG8gPC9i PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7IHByZXZlbnQgTWFsIHRvIGNvcHkNCml0LjwvYj4gKE9mIGNvdXJzZSwgaWYgTWFsIHJl YWxseSBkaWQgcG9zc2VzcyBYLCBBbGljZSdzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJpdmF0ZSBrZXksIHRoZW4gbm8NClBPUCBt ZWNoYW5pc20gaW4gdGhlIHdvcmxkIHdpbGwgaGVscCwgYnV0PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhhdCBpcyBhIGRpZmZlcmVu dA0KcHJvYmxlbS4pPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgTm90ZSB0aGF0IG9uZSBsZXZlbA0Kb2YgcHJvdGVjdGlvbiBj YW4gYmUgZ2FpbmVkIGJ5IGhhdmluZyBBbGljZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IChhcyB0aGUgdHJ1ZSBzaWduZXINCm9mIHRo ZSB0cmFuc2FjdGlvbikgaW5jbHVkZSBpbiB0aGUgc2lnbmVkPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5mb3JtYXRpb24sIGhlciBj ZXJ0aWZpY2F0ZQ0Kb3IgYW4gaWRlbnRpZmllciBvZiBoZXIgY2VydGlmaWNhdGU8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAoZS5nLiwg YSBoYXNoIG9mIGhlcg0KY2VydGlmaWNhdGUpLiAmbmJzcDs8Yj5BbGljZSBjb3VsZCBtYWxpY2lv dXNseSBpbmNsdWRlIDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBNYWzigJlzIGNlcnRpZmljYXRlDQpyYXRoZXIgdGhhbiBo ZXIgY2VydGlmaWNhdGUgaW4gdGhlIHRyYW5zYWN0aW9uLiBJbiBjYXNlIDwvYj48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBvZiBh IGRpc3B1dGUsIHRoZQ0KbG9ncyBwcmVzZW50IGluIHRoZSBDQSBkYXRhYmFzZXMgd2lsbCBiZSB1 c2VkIGFuZCA8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgdGhlIG9ubHkgbGVnaXRpbWF0ZQ0KY2VydGlmaWNhdGUgd2lsbCBi ZSB0aGUgb25lIHdoaWNoIHdhcyBpc3N1ZWQgZWFybGllcjwvYj4uPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgPGI+SXQgaXMgdGh1cyBw b3NzaWJsZQ0KdG8gZGVtb25zdHJhdGUgdGhhdCBBbGljZSB3YXMgbWFsaWNpb3VzLjwvYj48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGUgZm9sbG93aW5nIHRleHQg ZnJvbSBBbm5leCBDIHNob3VsZCBiZQ0KZGVsZXRlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGlzIG1pZ2h0IG1ha2Ug aXQgbW9yZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7IGRpZmZpY3VsdCBmb3IgTWFsIHRvDQpjbGFpbSBhdXRob3JzaGlwOyBoZSB3b3Vs ZCBoYXZlIHRvIGFzc2VydDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZu YnNwOyAmbmJzcDsgJm5ic3A7IHRoYXQgaGUgaW5jb3JyZWN0bHkNCmluY2x1ZGVkIEFsaWNlJ3Mg Y2VydGlmaWNhdGUsIHJhdGhlciB0aGFuIGhpczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IG93bi4gJm5ic3A7SG93ZXZlciwNCml0IHdv dWxkIG5vdCBzdG9wIEFsaWNlIGZyb20gZmFsc2VseSByZXB1ZGlhdGluZzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGhlciBhY3Rpb25z LiAmbmJzcDtTaW5jZQ0KdGhlIGNlcnRpZmljYXRlIGl0c2VsZiBpcyBhIHB1YmxpYyBpdGVtLCBN YWw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyBpbmRlZWQgY291bGQgaGF2ZSBpbnNlcnRlZA0KQWxpY2UncyBjZXJ0aWZpY2F0ZSBvciBp ZGVudGlmaWVyIGludG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyB0aGUgc2lnbmVkIHRyYW5zYWN0aW9uLA0KYW5kIHRodXMgaXRzIHBy ZXNlbmNlIGRvZXMgbm90IGluZGljYXRlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJB cmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhhdCBBbGljZSB3YXMgdGhlIG9uZQ0Kd2hvIHBh cnRpY2lwYXRlZCBpbiB0aGUgbm93LXJlcHVkaWF0ZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0cmFuc2FjdGlvbi4gJm5ic3A7VGhl DQpvbmx5IHJlbGlhYmxlIHdheSB0byBzdG9wIHRoaXMgYXR0YWNrIGlzIHRvPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVxdWlyZSB0 aGF0IE1hbCBwcm92ZQ0KaGUgcG9zc2Vzc2VzIFggYmVmb3JlIGhpcyBjZXJ0aWZpY2F0ZSBpczwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGlzc3VlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGUg aW1wbGljYXRpb24gaXMgdGhhdCB0aGUgbWVzc2FnZSBkZWZpbmVkDQppbiBkcmFmdC1ob3R6LWt4 NTA5IHdoaWNoIGNhcnJpZXMgdGhlIHB1YmxpYyBrZXkgPGJyPg0KTVVTVCBCRSBzb21laG93IGNv bmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IHByb3RlY3RlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5EZW5pczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPlBTLiBJIGFtIG5vdCBvbiB0aGUgS2VyYmVyb3MgbGlzdCwgc28g cGxlYXNlDQpyZXNwb25kIGRpcmVjdGx5IG9yL2FuZCB0byB0aGUgcGtpeCBsaXN0LjwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1 ZiBmYWNlPSJzYW5zLXNlcmlmIj5EZSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN0ZXBoZW4gRmFycmVsbCAmbHQ7c3Rl cGhlbi5mYXJyZWxsQGNzLnRjZC5pZSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9y PSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+QSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBraXggJmx0O3BraXhAaWV0 Zi5vcmcmZ3Q7LA0KJnF1b3Q7a3JiLXdnIG1haWxpbmcgbGlzdCAoaWV0Zi1rcmItd2dAbGlzdHMu YW5sLmdvdikmcXVvdDsgJmx0O2lldGYta3JiLXdnQGxpc3RzLmFubC5nb3YmZ3Q7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRhdGUgOiAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4zMS8wNS8yMDEyIDAxOjM2PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0j NWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPk9iamV0IDogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W3BraXhdIFJGQyA1NzQy DQpyZXZpZXcgb2YgZHJhZnQtaG90ei1reDUwOTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29s b3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5FbnZvecOpIHBhciA6ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBraXgt Ym91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KSGksPGJyPg0KPGJyPg0KVGhlIGluZGVwZW5kZW50 IHN1Ym1pc3Npb25zIGVkaXRvciAoSVNFKSBoYXMgYXNrZWQgdGhlPGJyPg0KSUVTRyB0byBkbyBh biBSRkMgNTc0MiByZXZpZXcgb2YgdGhpcyBbMV0gZG9jdW1lbnQuPGJyPg0KPGJyPg0KVGhhdCBy ZXZpZXcgaXMgdG8gY2hlY2sgdGhhdCB0aGUgcHVibGljYXRpb24gb2YgdGhpczxicj4NCmluZGVw ZW5kZW50IHN0cmVhbSBzdWJtaXNzaW9uIHdvdWxkIG5vdCBjb25mbGljdCB3aXRoPGJyPg0KSUVU RiB3b3JrLjxicj4NCjxicj4NCkluIHRoaXMgY2FzZSwgdGhlIHdvcmsgaXMgY2xlYXJseSByZWxh dGVkIHRvIHRoZSBwa2l4PGJyPg0KYW5kIGtlcmJlcm9zIHdvcmtpbmcgZ3JvdXBzLCBoZW5jZSB0 aGlzIG1haWwuPGJyPg0KPGJyPg0KTm90ZTogdGhpcyBtYWlsIGlzIG5vdCBhIHJlcXVlc3QgZm9y IGEgdGVjaG5pY2FsIHJldmlldzxicj4NCm9mIHRoZSBjb250ZW50LCBidXQgcmF0aGVyIGFza2lu ZyBpZiBwdWJsaWNhdGlvbiB3b3VsZDxicj4NCnNvbWVob3cgYmUgZGFtYWdpbmcgdG8gdGhlIHdv cmsgb2YgdGhlc2Ugd2dzLiAoSWYgeW91PGJyPg0KZG8gaGF2ZSB0ZWNobmljYWwgY29tbWVudHMs IHNlbmQgdGhlbSB0byB0aGUgYXV0aG9yPGJyPg0Kb3IgSVNFKS4gSWYgeW91J3JlIG5vdCBzdXJl IGFib3V0IGFueSBvZiB0aGF0LCB0aGVuPGJyPg0KcmVhZCBSRkMgNTc0Mi4gWzJdPGJyPg0KPGJy Pg0KSSdsbCB0YWtlIHNpbGVuY2UgYXMgbWVhbmluZyB0aGF0IG5vYm9keSB0aGlua3MgdGhhdDxi cj4NCnRoZXJlJ3MgYSBjb25mbGljdC4gSWYgc29tZW9uZSB0aGlua3MgdGhlcmUgaXMgYTxicj4N CmNvbmZsaWN0IGxldCBtZSwgdGhlIGxpc3QsIG9yIHRoZSB3ZyBjaGFpcnMga25vdy4gSW48YnI+ DQpkdWUgY291cnNlLCBJJ2xsIGJlIGRvaW5nIG15IG93biBldmFsdWF0aW9uIGFzIHdlbGw8YnI+ DQpvZiBjb3Vyc2UsIGFzIHdpbGwgb3RoZXIgSUVTRyBtZW1iZXJzLjxicj4NCjxicj4NClRoYW5r cyw8YnI+DQpTdGVwaGVuLjxicj4NCjxicj4NClsxXSA8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ob3R6LWt4NTA5LTA0Ij48dHQ+PGZvbnQgc2l6 ZT0yPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhvdHota3g1MDktMDQ8L2ZvbnQ+ PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpbMl0gPC9mb250PjwvdHQ+PGEgaHJlZj1o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzQyPjx0dD48Zm9udCBzaXplPTI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc0MjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6 ZT0yPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KcGtpeCBtYWlsaW5nIGxpc3Q8YnI+DQpwa2l4QGlldGYub3JnPGJyPg0KPC9m b250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Br aXg+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3BraXg8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4N Cjxicj4NCg== --=_alternative 0059D8ADC1257A0F_=-- From mstjohns@comcast.net Thu May 31 10:27:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA1021F873D for ; Thu, 31 May 2012 10:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NN4LYNuNgK9 for ; Thu, 31 May 2012 10:27:01 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5807121F86FF for ; Thu, 31 May 2012 10:27:01 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id GgWs1j0071GhbT857hT0VL; Thu, 31 May 2012 17:27:00 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta07.westchester.pa.mail.comcast.net with comcast id GhSz1j00x57vnMg3ThT0sg; Thu, 31 May 2012 17:27:00 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 31 May 2012 13:26:57 -0400 To: Phillip Hallam-Baker , Santosh Chokhani From: Michael StJohns In-Reply-To: References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_157177028==.ALT" Message-Id: <20120531172701.5807121F86FF@ietfa.amsl.com> Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 17:27:03 -0000 --=====================_157177028==.ALT Content-Type: text/plain; charset="us-ascii" Phil - Reading the draft mozilla policy (http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html) you have two choices, either use technical controls or non-technical controls. For technical controls - you need to do NameConstraints, KeyUsage and ExtendedKeyUsage all in compliance with RFC5280. (but see the exception cited in the document I note below) For non-technical controls, you need to be able to say the subordinate CA is following the rules. So how hard is setting up an auditor or auditing process? >Each externally-operated subordinate CA must either be audited in accordance with Mozilla's CA Certificate Policy or be technically constrained. And making me wonder once and for all if this is a strawman you've set up to try and knock down, the draft policy says: >Name Constraints do not need to be marked as critical at this time. So exactly why are you trying to change RFC5280 when you've already been given a get out of jail free card? At 05:41 PM 5/30/2012, Phillip Hallam-Baker wrote: >What I propose to do is to write a document that explains the steps that are necessary to write software that works with and the security consequences of accepting the certificates that CAs will be required to distribute in the next few weeks baring the (unlikely) event that Mozilla changes its mind. > >I think that the practical utility of that document is rather obvious. > > > >On Wed, May 30, 2012 at 3:35 PM, Santosh Chokhani <SChokhani@cygnacom.com> wrote: >PHB, > >If you are going to recommend rules beyond 5280 (e.g., if something is marked NC and 5280 says it should be critical), that is a non-starter. We do not need to add such rules and they do not serve any useful purpose. > >-----Original Message----- >From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >Sent: Wednesday, May 30, 2012 10:21 AM >To: Yoav Nir >Cc: Santosh Chokhani; IETF PKIX >Subject: Re: [pkix] Way Forward: Name Constraints Criticality > >I dont see that either. > >Commercial CAs now face a mandate from Mozilla that requires them to use Name Constraints. > >I have a draft of a draft that sets out the required client behavior when encountering a certificate that is not 5280 compliant with respect to criticality setting and the consequences of not setting criticality. > > > > >Sent from my iPad > >On May 28, 2012, at 8:38, Yoav Nir <ynir@checkpoint.com> wrote: > >> Hi Santosh >> >> I don't really see the difference between options 2 and 4. In option >> #2 we're keeping the MUST, but adding language that says that CAs can >> decide to make it non-critical if certain conditions apply and/or they >> decide to trade off interoperability for security. IMO this is the >> very definition of SHOULD >> >> Yoav >> >> On May 27, 2012, at 6:09 PM, Santosh Chokhani wrote: >> >>> I agree with Mike. >>> >>> In light of the fact we seem to have established positions which we do not wish to change, I thought we should see if there are options we could agree on. >>> >>> To that end and since the thread has several sub-threads, I have begun a new thread. >>> >>> Here are the options that come to my mind. There may be others. >>> >>> Option 1: Do not change the standard >>> >>> Option 2: Do not change the standard but add language akin to the following in an appropriate place in the standard " It is recognized that a CA may wish to make the name constraints extension non-critical in order to maximize interoperability. Such CA shall either use other mechanisms that are not specified in this standard or shall make such a decision based on trading off increased interoperability and security exposure" >>> >>> Option 3: Change the standard to make the extension "recommended to be critical for a period of time" This period of time should be short and should be only made if Opera and Safari decision makers are willing to provide the support for the extension ASAP in their browsers and maximize updates to the current version. We can add the applicable language and revision from Option 2. I would set this date to be expiry date of CA certificate since revocation checking in browsers is uneven. >>> >>> Option 4: Change the standard to make the extension "recommended to be critical". I would be against it. >>> >>> May be we could use this or similar method to get a vote on the WG since in my opinion no one is saying anything new. >>> >>> -----Original Message----- >>> From: Michael StJohns [mailto:mstjohns@comcast.net] >>> Sent: Saturday, May 26, 2012 9:15 PM >>> To: ryan-pkix@sleevi.com; Santosh Chokhani >>> Cc: IETF PKIX >>> Subject: Re: [pkix] NameConstraints criticality flag >>> >>> At 05:57 PM 5/26/2012, Ryan Sleevi wrote: >>>> Any CA who makes NC critical will necessarily prevent these users >>>> from accessing any servers whose certificates chain to them. >>>> Considering that so much of market position within the CA ecosystem >>>> is being able to interoperate with legacy systems, this is a >>>> unbearable market penalty for any CA. Considering the first mover >>>> penalties are so high, no CA wishing to stay in business would adopt NC. >>> >>> I keep trying to understand this type of a statement, but it gives me a bad case of cognitive dissonance. I'm actually thinking that a critical NC and not being able to access those servers is a good thing and the whole idea of NC in the first place. >>> >>> Here's how I imagine an NC would be used. >>> >>> I'm a company that wants to issue certificates to my servers that chain back to a well known root. I *don't* want to have to do a server by server request to get certificates so I contract with the well known root (WKR) to get a CA certificate owned by my company signed. >>> >>> The WKR has two types of CA signing it will do - the first contains an NC that constrains me to issue certificates with names that are subordinate to "mikestjohnscompany.com" and costs X, the second that does not contain an NC and costs 10 X (mainly because the WKR doesn't want it competing with them for issuing TLS server certificates for random companies). >>> >>> If the WKR is only getting X, then the WKR is going to want to make sure that the certificates issued by the subordinate CA are enforceably within mikestjohnscompany.com which means setting the critical bit. If your (Ryan, Phil, etc) assumption is that very few RPs understand NC, then setting the bit to non-critical means that the NC is basically useless, and almost any name issued by that subordinate CA is going to be accepted by the vast majority of RPs including those not under mikestjohnscompany.com. >>> >>> Amusingly, if there are enough of non-critical NC/Non-Compliant name server certificates (because some subordinate CA was gaming the system, or was just stupid about how they set up their CA) deployed, deployments of browsers that implement NC support may never happen because those now NC supporting browsers will not be able to reach the servers with non-compliant certificates. Talk about anti-incentive. >>> >>> You're trying to deal with a legacy issue the wrong way (or so I believe). But, as someone else noted, it really is - in the final analysis - up to the issuing CA whether to set the critical bit or not. So as CA vendors you should feel free to set the bit as you please - it just won't be compliant with the 5280 profile if its set non-critical. Personally, I'd rather you just not include the NC in the certificate. >>> >>> Later, Mike >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> Scanned by Check Point Total Security Gateway. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > >-- >Website: http://hallambaker.com/ > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix --=====================_157177028==.ALT Content-Type: text/html; charset="us-ascii" Phil -

Reading the draft mozilla policy ( http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html ) you have two choices, either use technical controls or non-technical controls. 

For technical controls - you need to do NameConstraints, KeyUsage and ExtendedKeyUsage all in compliance with RFC5280.  (but see the exception cited in the document I note below)

For non-technical controls, you need to be able to say the subordinate CA is following the rules.    So how hard is setting up an auditor or auditing process?

Each externally-operated subordinate CA must either be audited in accordance with Mozilla's CA Certificate Policy or be technically constrained.


And making me wonder once and for all if this is a strawman you've set up to try and knock down, the draft policy says:

Name Constraints do not need to be marked as critical at this time.


So exactly why are you trying to change RFC5280 when you've already been given a get out of jail free card?





At 05:41 PM 5/30/2012, Phillip Hallam-Baker wrote:
What I propose to do is to write a document that explains the steps that are necessary to write software that works with and the security consequences of accepting the certificates that CAs will be required to distribute in the next few weeks baring the (unlikely) event that Mozilla changes its mind.

I think that the practical utility of that document is rather obvious.



On Wed, May 30, 2012 at 3:35 PM, Santosh Chokhani <SChokhani@cygnacom.com > wrote:
PHB,

If you are going to recommend rules beyond 5280 (e.g., if something is marked NC and 5280 says it should be critical), that is a non-starter.  We do not need to add such rules and they do not serve any useful purpose.

-----Original Message-----
From: Phillip Hallam-Baker [ mailto:hallam@gmail.com]
Sent: Wednesday, May 30, 2012 10:21 AM
To: Yoav Nir
Cc: Santosh Chokhani; IETF PKIX
Subject: Re: [pkix] Way Forward: Name Constraints Criticality

I dont see that either.

Commercial CAs now face a mandate from Mozilla that requires them to use Name Constraints.

I have a draft of a draft that sets out the required client behavior when encountering a certificate that is not 5280 compliant with respect to criticality setting and the consequences of not setting criticality.




Sent from my iPad

On May 28, 2012, at 8:38, Yoav Nir <ynir@checkpoint.com> wrote:

> Hi Santosh
>
> I don't really see the difference between options 2 and 4. In option
> #2 we're keeping the MUST, but adding language that says that CAs can
> decide to make it non-critical if certain conditions apply and/or they
> decide to trade off interoperability for security. IMO this is the
> very definition of SHOULD
>
> Yoav
>
> On May 27, 2012, at 6:09 PM, Santosh Chokhani wrote:
>
>> I agree with Mike.
>>
>> In light of the fact we seem to have established positions which we do not wish to change, I thought we should see if there are options we could agree on.
>>
>> To that end and since the thread has several sub-threads, I have begun a new thread.
>>
>> Here are the options that come to my mind.  There may be others.
>>
>> Option 1: Do not change the standard
>>
>> Option 2: Do not change the standard but add language akin to the following in an appropriate place in the standard " It is recognized that a CA may wish to make the name constraints extension non-critical in order to maximize interoperability.  Such CA shall either use other mechanisms that are not specified in this standard or shall make such a decision based on trading off increased interoperability and security exposure"
>>
>> Option 3: Change the standard to make the extension "recommended to be critical for a period of time"  This period of time should be short and should be only made if Opera and Safari decision makers are willing to provide the support for the extension ASAP in their browsers and maximize updates to the current version.  We can add the applicable language and revision from Option 2.  I would set this date to be expiry date of CA certificate since revocation checking in browsers is uneven.
>>
>> Option 4: Change the standard to make the extension "recommended to be critical".  I would be against it.
>>
>> May be we could use this or similar method to get a vote on the WG since in my opinion no one is saying anything new.
>>
>> -----Original Message-----
>> From: Michael StJohns [ mailto:mstjohns@comcast.net]
>> Sent: Saturday, May 26, 2012 9:15 PM
>> To: ryan-pkix@sleevi.com; Santosh Chokhani
>> Cc: IETF PKIX
>> Subject: Re: [pkix] NameConstraints criticality flag
>>
>> At 05:57 PM 5/26/2012, Ryan Sleevi wrote:
>>> Any CA who makes NC critical will necessarily prevent these users
>>> from accessing any servers whose certificates chain to them.
>>> Considering that so much of market position within the CA ecosystem
>>> is being able to interoperate with legacy systems, this is a
>>> unbearable market penalty for any CA. Considering the first mover
>>> penalties are so high, no CA wishing to stay in business would adopt NC.
>>
>> I keep trying to understand this type of a statement, but it gives me a bad case of cognitive dissonance.  I'm actually thinking that a critical NC and not being able to access those servers is a good thing and the whole idea of NC in the first place.
>>
>> Here's how I imagine an NC would be used.
>>
>> I'm a company that wants to issue certificates to my servers that chain back to a well known root.  I *don't* want to have to do a server by server request to get certificates so I contract with the well known root (WKR) to get a CA certificate owned by my company signed.
>>
>> The WKR has two types of CA signing it will do - the first contains an NC that constrains me to issue certificates with names that are subordinate to "mikestjohnscompany.com " and costs X, the second that does not contain an NC and costs 10 X (mainly because the WKR doesn't want it competing with them for issuing TLS server certificates for random companies).
>>
>> If  the WKR is only getting X, then the WKR is going to want to make sure that the certificates issued by the subordinate CA are enforceably within mikestjohnscompany.com which means setting the critical bit.   If your (Ryan, Phil, etc) assumption is that very few RPs understand NC, then setting the bit to non-critical means that the NC is basically useless, and almost any name issued by that subordinate CA is going to be accepted by the vast majority of RPs including those not under mikestjohnscompany.com.
>>
>> Amusingly, if there are enough of  non-critical NC/Non-Compliant name server certificates (because some subordinate CA was gaming the system, or was just stupid about how they set up their CA) deployed, deployments of browsers that implement NC support may never happen because those now NC supporting browsers will not be able to reach the servers with non-compliant certificates.  Talk about anti-incentive.
>>
>> You're trying to deal with a legacy issue the wrong way (or so I believe).   But, as someone else noted, it really is  - in the final analysis - up to the issuing CA whether to set the critical bit or not.  So as CA vendors you should feel free to set the bit as you please - it just won't be compliant with the 5280 profile if its set non-critical.  Personally, I'd rather you just not include the NC in the certificate.
>>
>> Later, Mike
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>> Scanned by Check Point Total Security Gateway.
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix




--
Website: http://hallambaker.com/

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--=====================_157177028==.ALT-- From agl@google.com Thu May 31 10:30:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290DD21F8772 for ; Thu, 31 May 2012 10:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WydPSKTzuIKt for ; Thu, 31 May 2012 10:30:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9289C21F8771 for ; Thu, 31 May 2012 10:30:51 -0700 (PDT) Received: by yhq56 with SMTP id 56so1038934yhq.31 for ; Thu, 31 May 2012 10:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=LJPT/aYJ63pEZwwNoC35FTr8FnUbAVNZcnyqF35i3QM=; b=Vds4eF3W2kvqeYU2LSCWv2VrXqxyKgKk747sDDi6hxlbKjTZM0/oZH4jmwLVhFRfSF qa7sXdofONI7gPTp1BgKkkgnWXVI9fpJcpy3nWH/YjnMaa7G2G+J3hbTZQuBKniXzkBt nMd0ZNounoEPf/E7uhEO3BQGEc2IAcMK2Af9aYBkfJhN7RfClljg1nyztN4wG3Q1rWUM xUzvDwlpQjZR/sSc2qpMsAFKntLahoasKFnT6h0tHf1ZtNIjRqrzi8lyegBuBALNAEdL jITKeNV2WadSKCHc10UryDVhmBJR62XZsX7GzZ7UQj/HgrGuknzwHL7bkKGXB/Qd8hNy kA7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=LJPT/aYJ63pEZwwNoC35FTr8FnUbAVNZcnyqF35i3QM=; b=Y11ZUaXypyyqZ2r16+GU8Yiv7pwAqmQh69xav5mtfwvRyBTgo2+tkjGLxa4ayJUIZN 3ssdzaU7EvRjybG6gUEa5jNgiHhrdqpkBZUFUqAsO66glxXZX2WXln117l3zbbISHvms wLQXmx6ysKm4pT6GysNVe7B9DK1+t2At5guq1CCgHJMjUOsv4Hlaw4G4bsJ5jBN2/flm aeJNLZscxL3rQHKzSnHtLyXT0tC6elZN0gwSVNB5WgH987o8SOT48CUTuZ08gn1VOM2b 1jxi82scgKrwxqhHZbwYzDOenB8LZmY9CaZ7E5pofSmdOefXMuVIY/fGS2y83PIL3m2k 3cRA== Received: by 10.42.244.202 with SMTP id lr10mr2186115icb.28.1338485450701; Thu, 31 May 2012 10:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.244.202 with SMTP id lr10mr2186100icb.28.1338485450606; Thu, 31 May 2012 10:30:50 -0700 (PDT) Received: by 10.231.5.201 with HTTP; Thu, 31 May 2012 10:30:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 May 2012 13:30:50 -0400 Message-ID: From: Adam Langley To: "Miller, Timothy J." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkg/7Hx84ftKpk2rsPYPxkXC0Cck4dCYFBJOHiWAwq14MeE9q1z+R9sEyp6+jN4aUsBgXPLj15guOdakZvHD8Q9usaWc2KirRZQB2DyJjsUhpTxvtVcIjJ0MmrH/F844QzEA1Kd Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 17:30:52 -0000 On Thu, May 31, 2012 at 10:58 AM, Miller, Timothy J. wr= ote: > I guess I just don't see why you'd include NC in a cert but *not* mark it > critical. =C2=A0Non-critical NC basically says "Beyond this point you sho= uld > {only see/never see} the following names, but we don't actually care if > you pay attention." The alternative is an intermediate CA certificate without any Name Constraints at all. By including non-critical Name Constraints the world benefits from fewer, all-powerful certificates as most clients will enforce them. However, given the size of the Internet these days, we can't reasonably deploy things that cause significant breakage. This is not ideal. Ideally we wouldn't start from where we are but, given that we have to, I believe that this is a positive step. Cheers AGL From DPKemp@missi.ncsc.mil Thu May 31 11:20:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF8421F86FA for ; Thu, 31 May 2012 11:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqJOBUX2bWfy for ; Thu, 31 May 2012 11:20:38 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF9421F86EC for ; Thu, 31 May 2012 11:20:38 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q4VIKbI6023292 for ; Thu, 31 May 2012 14:20:37 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 May 2012 14:20:36 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 31 May 2012 14:20:36 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac0/UyaOZlss8gyVRB+/jv/AnYjlbAAANQ2g References: From: "Kemp, David P." To: "IETF PKIX" X-OriginalArrivalTime: 31 May 2012 18:20:36.0926 (UTC) FILETIME=[136EFDE0:01CD3F5A] Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 18:20:39 -0000 Tm9ib2R5IGRpc3B1dGVzIHRoYXQgQ0FzIHNob3VsZCBhbmQgd2lsbCBkbyB0aGluZ3MgdGhhdCBh dm9pZCBzaWduaWZpY2FudCBicmVha2FnZS4NCg0KVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhl IHB1cnBvc2Ugb2YgUkZDIDUyODAgaXMgdG8gZGVmaW5lIGEgImNvcnJlY3QiIHByb2ZpbGUgKGRl ZmluaW5nIHdoYXQgd2UncmUgdHJ5aW5nIHRvIGFjaGlldmUpIG9yIGEgInByYWN0aWNhbCIgcHJv ZmlsZSAoZGVmaW5pbmcgdGhpbmdzIHRoYXQgYXJlIG5vdCBkZXNpcmVkLCBidXQgYXJlIG5lY2Vz c2FyeSB0byBhY2NvbW1vZGF0ZSBkZWZpY2llbmNpZXMgaW4gdGhlIGN1cnJlbnQgZW52aXJvbm1l bnQpLg0KDQpJZiB3ZSB3ZXJlIHdyaXRpbmcgYW4gZWxlY3RyaWMgcG93ZXIgcHJvZmlsZSwgdGhl IGNob2ljZSBpcyBiZXR3ZWVuIHNheWluZyBsaW5lIHZvbHRhZ2Ugb24gY3VzdG9tZXIgcHJlbWlz ZXM6DQogICogIE1VU1QgYmUgMTIwViArLy01ViAgKGtub3dpbmcgZnVsbCB3ZWxsIHRoYXQgdW5k ZXIgcGVhayBkZW1hbmQgdGhlIHV0aWxpdHkNCiAgICAgbWF5IG5lZWQgdG8gdmlvbGF0ZSB0aGUg c3RhbmRhcmQgYW5kIGNyYW5rIGl0IGRvd24gdG8gMTAwViB0byBhdm9pZCBsb3NpbmcNCiAgICAg cG93ZXIgYWx0b2dldGhlciksIG9yDQogICogIFNIT1VMRCBiZSAxMjBWICAoYWxsb3dpbmcgdGhl IHV0aWxpdHkgdGhlIGZyZWVkb20gdG8gZG8gd2hhdGV2ZXIgaXQgdGhpbmtzIG5lY2Vzc2FyeQ0K ICAgICB3aXRob3V0IGJlaW5nIGRlY2xhcmVkIG91dC1vZi1zcGVjKQ0KDQpNeSB2b3RlIGlzIHN0 aWxsIGZvciB0aGUgImNvcnJlY3QiIHByb2ZpbGUuICBBIENBIG1heSBpc3N1ZSBjZXJ0cyB0aGF0 IGRvbid0IGZvbGxvdyA1MjgwIHdoZW4gbmVjZXNzYXJ5IHRvIGFjY29tbW9kYXRlIG1hcmtldCBj b25kaXRpb25zLiAgQnV0IHRoZSBmYWN0IHRoYXQgdGhlcmUgYXJlIGV4Y2VwdGlvbnMgaXMgYSBz aWduYWwgdG8gdGhlIENBIHRvIHBlcmlvZGljYWxseSByZS1ldmFsdWF0ZSB0aGUgbWFya2V0IGFu ZCByZW1vdmUgdGhlIGV4Y2VwdGlvbiB3aGVuIGl0IGJlY29tZXMgcHJhY3RpY2FsIHRvIGRvIHNv Lg0KDQpEYXZlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGtpeC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQWRhbSBMYW5nbGV5DQpTZW50OiBUaHVyc2RheSwgTWF5IDMxLCAyMDEyIDE6MzEgUE0NClRv OiBNaWxsZXIsIFRpbW90aHkgSi4NCkNjOiBJRVRGIFBLSVgNClN1YmplY3Q6IFJlOiBbcGtpeF0g V2F5IEZvcndhcmQ6IE5hbWUgQ29uc3RyYWludHMgQ3JpdGljYWxpdHkNCg0KT24gVGh1LCBNYXkg MzEsIDIwMTIgYXQgMTA6NTggQU0sIE1pbGxlciwgVGltb3RoeSBKLiA8dG1pbGxlckBtaXRyZS5v cmc+IHdyb3RlOg0KPiBJIGd1ZXNzIEkganVzdCBkb24ndCBzZWUgd2h5IHlvdSdkIGluY2x1ZGUg TkMgaW4gYSBjZXJ0IGJ1dCAqbm90KiBtYXJrIA0KPiBpdCBjcml0aWNhbC4gwqBOb24tY3JpdGlj YWwgTkMgYmFzaWNhbGx5IHNheXMgIkJleW9uZCB0aGlzIHBvaW50IHlvdSANCj4gc2hvdWxkIHtv bmx5IHNlZS9uZXZlciBzZWV9IHRoZSBmb2xsb3dpbmcgbmFtZXMsIGJ1dCB3ZSBkb24ndCBhY3R1 YWxseSANCj4gY2FyZSBpZiB5b3UgcGF5IGF0dGVudGlvbi4iDQoNClRoZSBhbHRlcm5hdGl2ZSBp cyBhbiBpbnRlcm1lZGlhdGUgQ0EgY2VydGlmaWNhdGUgd2l0aG91dCBhbnkgTmFtZSBDb25zdHJh aW50cyBhdCBhbGwuIEJ5IGluY2x1ZGluZyBub24tY3JpdGljYWwgTmFtZSBDb25zdHJhaW50cyB0 aGUgd29ybGQgYmVuZWZpdHMgZnJvbSBmZXdlciwgYWxsLXBvd2VyZnVsIGNlcnRpZmljYXRlcyBh cyBtb3N0IGNsaWVudHMgd2lsbCBlbmZvcmNlIHRoZW0uIEhvd2V2ZXIsIGdpdmVuIHRoZSBzaXpl IG9mIHRoZSBJbnRlcm5ldCB0aGVzZSBkYXlzLCB3ZSBjYW4ndCByZWFzb25hYmx5IGRlcGxveSB0 aGluZ3MgdGhhdCBjYXVzZSBzaWduaWZpY2FudCBicmVha2FnZS4NCg0KVGhpcyBpcyBub3QgaWRl YWwuIElkZWFsbHkgd2Ugd291bGRuJ3Qgc3RhcnQgZnJvbSB3aGVyZSB3ZSBhcmUgYnV0LCBnaXZl biB0aGF0IHdlIGhhdmUgdG8sIEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgYSBwb3NpdGl2ZSBzdGVw Lg0KDQoNCkNoZWVycw0KDQpBR0wNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpwa2l4IG1haWxpbmcgbGlzdA0KcGtpeEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4DQo= From kent@bbn.com Thu May 31 11:55:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3D621F858F for ; Thu, 31 May 2012 11:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PKvJivT9AQ1 for ; Thu, 31 May 2012 11:55:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0921F858E for ; Thu, 31 May 2012 11:55:41 -0700 (PDT) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49239) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SaAWZ-000Pi0-2Z for pkix@ietf.org; Thu, 31 May 2012 14:55:07 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 31 May 2012 14:55:35 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] WGLC X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 18:55:41 -0000 Having read through the backlog of mail I see that PHB has requested WGLC for draft-ietf-pkix-caa-07. So, the WGLC begins tomorrow (6/1) and completes on 6/15. Steve From SChokhani@cygnacom.com Thu May 31 12:29:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B314011E80B4 for ; Thu, 31 May 2012 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LnZdtTpqid5 for ; Thu, 31 May 2012 12:29:14 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE4D11E80AC for ; Thu, 31 May 2012 12:29:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,693,1330923600"; d="scan'208";a="5167619" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 31 May 2012 15:29:10 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 31 May 2012 15:29:10 -0400 From: Santosh Chokhani To: Rob Stradling Date: Thu, 31 May 2012 15:25:04 -0400 Thread-Topic: [pkix] Integrated OCSP Responders / Key Usage bits Thread-Index: Ac0/QylTZXxsGBYdRemUI/qEBlKN9wAH7GzA Message-ID: References: <4FBF4B37.1090208@comodo.com> <4FC487AB.6000603@comodo.com> <4FC775FD.2020006@comodo.com> <4FC78FFA.1070205@comodo.com> In-Reply-To: <4FC78FFA.1070205@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 19:29:15 -0000 Rob, I support a fix to the standards. I do not see a need for DS bit for CA ce= rtificate. I also do not see a security issue with what you are doing. I proposed alternatives in case you want to comply with the current standar= ds. -----Original Message----- From: Rob Stradling [mailto:rob.stradling@comodo.com]=20 Sent: Thursday, May 31, 2012 11:36 AM To: Santosh Chokhani Cc: pkix@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits On 31/05/12 16:25, Santosh Chokhani wrote: > Rob, > > You have three options for the ongoing operations: > > 1. Recut the CA certificate with DS bit set. > 2. Issue yourself a responder certificate, i.e., certify the same=20 > key, sign it and put no check on it. Even the life of the certificate ca= n extend to the CA certificate life 3. Do nothing and wait until some OCSP= client barfs on it. > > For new installs, it seems the safe thing to do is set the DS bit on in t= he CA certificate or use option 2 above. Hi Santosh. Yes, I'll make sure the digitalSignature bit is set in new CA Certificates = we issue in the future. Recutting our existing CA certificates is not an option. There are rather = a lot of them and they are widely deployed. I don't want to have to use dedicated responder certificates unless I reall= y have to. Are you saying that trying to "fix" the standards is not really an option? What security hole would be introduced by once again allowing the "crlSign"= bit to authorize the CA certificate as an Integrated Responder? > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 > Of Rob Stradling > Sent: Thursday, May 31, 2012 9:46 AM > To: pkix@ietf.org > Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits > > On 29/05/12 09:24, Rob Stradling wrote: >> On 25/05/12 10:04, Rob Stradling wrote: >>> Which Key Usage bits (if any) are required to be present in a CA=20 >>> Certificate that directly signs OCSP Responses? >> >>> IMHO, it'd kinda make sense for the cRLSign bit to govern whether or=20 >>> not the CA Certificate can directly sign OCSP Responses, but sadly I=20 >>> can find no text to support this idea. >> >> I've unearthed some text to support this idea, so at least I'm now=20 >> sure I didn't completely make it up myself! >> >> RFC2459 said... >> "The cRLSign bit is asserted when the subject public key is used for=20 >> verifying a signature on revocation information (e.g., a CRL)." >> "The digitalSignature bit is asserted when the subject public key is=20 >> used with a digital signature mechanism to support security services=20 >> other than...revocation information signing (bit 6)." >> >> Obviously an OCSP Response's signature is "a signature on revocation=20 >> information". >> >> Why did RFC3280 change the required bit for signing non-CRL=20 >> revocation information from "cRLSign" to "digitalSignature"? >> >> Could we change it back, or at least allow either "cRLSign" or=20 >> "digitalSignature" to be deemed acceptable for signing non-CRL=20 >> revocation information? > > PHB just noted in another thread that "The point of standards is to achie= ve interoperability". I'll restate my question with this thought in mind. > > We (Comodo) sign OCSP Responses directly from CA Certificates that have t= he keyCertSign and cRLSign bits set but the digitalSignature bit unset. > This is/was fully compliant with RFC2459, but (I realized only this > week) not compliant with 3280/5280. > > Thus far, I've not encountered any client software that rejects our OCSP = Responses. > > But to "achieve interoperability", I wish to ensure that no future client= software rejects our OCSP Responses on the basis that the digitalSignature= bit is not set in the CA Certificates. > > So, can we please reinstate the 2459 text that "The cRLSign bit is assert= ed when the subject public key is used for verifying a signature on revocat= ion information" or at least say that cRLSign and/or digitalSignature is su= fficient for this purpose? > > -- > Rob Stradling > Senior Research& Development Scientist COMODO - Creating Trust Online=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=20 Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and=20 intended solely for the use of the individual or entity to whom they are=20 addressed. If you have received this email in error please notify the=20 sender by replying to the e-mail containing this attachment. Replies to=20 this email may be monitored by COMODO for operational or business=20 reasons. Whilst every endeavour is taken to ensure that e-mails are free=20 from viruses, no liability can be accepted and the recipient is=20 requested to use their own virus checking software. From SChokhani@cygnacom.com Thu May 31 12:29:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F1411E80AC for ; Thu, 31 May 2012 12:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCWV0jDElGXD for ; Thu, 31 May 2012 12:29:16 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id B7A3211E80B5 for ; Thu, 31 May 2012 12:29:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,693,1330923600"; d="scan'208";a="5167620" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 31 May 2012 15:29:15 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 31 May 2012 15:29:15 -0400 From: Santosh Chokhani To: "mrex@sap.com" , Rob Stradling Date: Thu, 31 May 2012 15:27:49 -0400 Thread-Topic: [pkix] Integrated OCSP Responders / Key Usage bits Thread-Index: Ac0/RnDnGGNklqvyRyuC8Thrbxie0wAHPCCw Message-ID: References: <4FC78FFA.1070205@comodo.com> <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> In-Reply-To: <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 19:29:16 -0000 I support what Rob is doing. I see no particular need for DS bit in CA cer= tificate. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, May 31, 2012 12:00 PM To: Rob Stradling Cc: Santosh Chokhani; pkix@ietf.org Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits Rob Stradling wrote: >=20 > Are you saying that trying to "fix" the standards is not really an option= ? >=20 > What security hole would be introduced by once again allowing the=20 > "crlSign" bit to authorize the CA certificate as an Integrated Responder? This is _NOT_ a defect of rfc2560, it was a conscious design decision, and = a careful implementor should have seen this. So "fixing" does not exist as an option only changing the behaviour in a su= ccessor OCSP spec. But should still account for implementations based on r= fc2560 alone. What is more confusing to me is that you're PKI software did not error on y= our attempt to sign OCSP responses without the DigitalSignature bit in your= CA cert. When sensibly implemented, a signature creation function should = perform a number of plausibility checks on signature creation (including Ke= yUsage and Validity), because it does not make sense (other than in very li= mited debug situations) to create digital signatures that receipients will very probabl= y fail verifying. -Martin From sph2sail@gmail.com Thu May 31 13:25:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED76121F8505 for ; Thu, 31 May 2012 13:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OOj2MgmFOlx for ; Thu, 31 May 2012 13:25:53 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3693921F8496 for ; Thu, 31 May 2012 13:25:49 -0700 (PDT) Received: by vcqp1 with SMTP id p1so973727vcq.31 for ; Thu, 31 May 2012 13:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=tijwj2ErnVsiqVABGvf4STcdtbzQR0BxFCOQ9eVum58=; b=T6AxK+jWCCcIRTFzOBzYvPPaHdkWI1u4YeYsAs8QSpPIBLyMLM1+fBx28r1C6VebYo opI94BqLfMiu9p1V16SUQ5sW9+mZcwLD1kZCtc2jQy2weDKnJ8QaAhLU6sFFqO0S5Xqi v1KxRsZh253tEOsjFV5cr9hldyH9Zm9EmcqL6/RnYsOWJoIpwDfxjlRlJOIzFZGRwCLi t4Xt2CZYrI7+n1aPzf50kVd8I1cMVzJfz3Yissf8uqZOFEzqThRSbTK61VBU+XACwbLc BkahsjUsJHUztfUpG8/XFwtZYVytkirR8gMfoYc4tWeDwwOt0b7UiWUfeO/qa/SHHRey UC2g== Received: by 10.52.180.230 with SMTP id dr6mr18992116vdc.130.1338495948690; Thu, 31 May 2012 13:25:48 -0700 (PDT) Received: from D7C54J1 (static-96-255-5-227.washdc.fios.verizon.net. [96.255.5.227]) by mx.google.com with ESMTPS id r15sm6566655vdj.8.2012.05.31.13.25.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 May 2012 13:25:47 -0700 (PDT) From: Steve Howard To: "'IETF PKIX'" References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> In-Reply-To: Date: Thu, 31 May 2012 16:27:07 -0400 Message-ID: <02ce01cd3f6b$c089a870$419cf950$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF39hmXCiqgLXUqiOgOhbSZMn8uSwJqiPohAaLdI4YCJb0VFAEcL2GyAnUukDOXQHgMIA== Content-Language: en-us Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 20:25:54 -0000 I have been watching this thread with interest. So far, the discussion does not contemplate bridged infrastructure. Rather, the predominance of the discussion is driven by the PKI up to a WKR. As a bridge, CertiPath does apply name constraints, and we mark them critical, for our enterprise customers. We find this both useful and not to be an interoperability issue for our customers. Respectfully, Steve Stephen P. Howard | Vice President, Credentials | CertiPath LLC 2300 Corporate Park Drive, Ste 150, Herndon, VA 20171 PH +1.703.793.7879 | Direct +1.703.319.3171 | FAX +1.703.773.6262 Email Steve.Howard@CertiPath.com CertiPath: Enabling Trusted Communication www.certipath.com -----Original Message----- From: Wan-Teh Chang [mailto:wtc@google.com] Sent: Wednesday, May 30, 2012 7:31 PM To: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality RFC 2459 (a predecessor of RFC 5280) is 129 pages long. Isn't it possible that the reviewers of such a long document may have overlooked the full implications of "[The name constraints] extension MUST be critical"? Is the US DoD using the name constraints extension? Thanks, Wan-Teh From rob.stradling@comodo.com Thu May 31 14:39:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDC721F8653 for ; Thu, 31 May 2012 14:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye0GCzHytZdh for ; Thu, 31 May 2012 14:39:35 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9584621F864C for ; Thu, 31 May 2012 14:39:32 -0700 (PDT) Received: (qmail 4864 invoked from network); 31 May 2012 21:39:30 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 31 May 2012 21:39:30 -0000 Received: (qmail 28814 invoked by uid 1000); 31 May 2012 21:39:30 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 31 May 2012 22:39:30 +0100 Message-ID: <4FC7E512.3000801@comodo.com> Date: Thu, 31 May 2012 22:39:30 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: mrex@sap.com References: <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> In-Reply-To: <20120531155948.88A2D1A094@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 21:39:37 -0000 On 31/05/12 16:59, Martin Rex wrote: > Rob Stradling wrote: >> >> Are you saying that trying to "fix" the standards is not really an option? >> >> What security hole would be introduced by once again allowing the >> "crlSign" bit to authorize the CA certificate as an Integrated Responder? > > This is _NOT_ a defect of rfc2560, it was a conscious design decision, > and a careful implementor should have seen this. RFC2560 cites RFC2459 as a reference, and RFC2459 says that "The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information (e.g., a CRL)." So if there was "a conscious design decision" by the RFC2560 authors regarding which Key Usage bits should be set in the Integrated Responder case, then surely that decision was in agreement with what I am asking for and in disagreement with the altered text in RFCs 3280 and 5280! > So "fixing" does not exist as an option only changing the behaviour > in a successor OCSP spec. But should still account for implementations > based on rfc2560 alone. And what about accounting for implementations based on RFC2459 alone? > What is more confusing to me is that you're PKI software did not > error on your attempt to sign OCSP responses without the > DigitalSignature bit in your CA cert. When sensibly implemented, Our PKI software was written by me, and until this week I hadn't noticed that RFC3280/5280 changed the rules on which Key Usage bit means what. Yes, I know RFC3280 was published 10 years ago. Sorry I didn't notice sooner. Call me a careless implementor if you like. >a signature creation function should perform a number of plausibility > checks on signature creation (including KeyUsage and Validity), > because it does not make sense (other than in very limited debug > situations) to create digital signatures that receipients will > very probably fail verifying. Let's look at this from another angle: What would happen today if a CA decides to implement an RFC5280-compliant PKI that uses Integrated-Responder-OCSP but not CRLs? If they follow RFC5280's guidance, they will set keyCertSign and digitalSignature (but NOT cRLSign) in the CA Certificate(s). Then, what would happen when an RFC2459-compliant client attempts to perform an OCSP check on an end-entity certificate from this PKI? If the client enforces the RFC2459 definitions of the Key Usage bits, it would reject the OCSP Response because the CA Certificate does not have the cRLSign bit set!! > -Martin > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From rob.stradling@comodo.com Thu May 31 14:41:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1602721F861F for ; Thu, 31 May 2012 14:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAV-OhvmELxT for ; Thu, 31 May 2012 14:41:04 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id A9ECB21F8526 for ; Thu, 31 May 2012 14:41:03 -0700 (PDT) Received: (qmail 5243 invoked from network); 31 May 2012 21:41:02 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 31 May 2012 21:41:02 -0000 Received: (qmail 29297 invoked by uid 1000); 31 May 2012 21:41:02 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 31 May 2012 22:41:02 +0100 Message-ID: <4FC7E56E.3000704@comodo.com> Date: Thu, 31 May 2012 22:41:02 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Santosh Chokhani References: <4FBF4B37.1090208@comodo.com> <4FC487AB.6000603@comodo.com> <4FC775FD.2020006@comodo.com> <4FC78FFA.1070205@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 21:41:05 -0000 On 31/05/12 20:25, Santosh Chokhani wrote: > Rob, > > I support a fix to the standards. I do not see a need for DS bit for CA certificate. > > I also do not see a security issue with what you are doing. Thanks Santosh. > I proposed alternatives in case you want to comply with the current standards. Understood. > -----Original Message----- > From: Rob Stradling [mailto:rob.stradling@comodo.com] > Sent: Thursday, May 31, 2012 11:36 AM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits > > On 31/05/12 16:25, Santosh Chokhani wrote: >> Rob, >> >> You have three options for the ongoing operations: >> >> 1. Recut the CA certificate with DS bit set. >> 2. Issue yourself a responder certificate, i.e., certify the same >> key, sign it and put no check on it. Even the life of the certificate can extend to the CA certificate life 3. Do nothing and wait until some OCSP client barfs on it. >> >> For new installs, it seems the safe thing to do is set the DS bit on in the CA certificate or use option 2 above. > > Hi Santosh. > > Yes, I'll make sure the digitalSignature bit is set in new CA Certificates we issue in the future. > > Recutting our existing CA certificates is not an option. There are rather a lot of them and they are widely deployed. > > I don't want to have to use dedicated responder certificates unless I really have to. > > Are you saying that trying to "fix" the standards is not really an option? > > What security hole would be introduced by once again allowing the "crlSign" bit to authorize the CA certificate as an Integrated Responder? > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >> Of Rob Stradling >> Sent: Thursday, May 31, 2012 9:46 AM >> To: pkix@ietf.org >> Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits >> >> On 29/05/12 09:24, Rob Stradling wrote: >>> On 25/05/12 10:04, Rob Stradling wrote: >>>> Which Key Usage bits (if any) are required to be present in a CA >>>> Certificate that directly signs OCSP Responses? >>> >>>> IMHO, it'd kinda make sense for the cRLSign bit to govern whether or >>>> not the CA Certificate can directly sign OCSP Responses, but sadly I >>>> can find no text to support this idea. >>> >>> I've unearthed some text to support this idea, so at least I'm now >>> sure I didn't completely make it up myself! >>> >>> RFC2459 said... >>> "The cRLSign bit is asserted when the subject public key is used for >>> verifying a signature on revocation information (e.g., a CRL)." >>> "The digitalSignature bit is asserted when the subject public key is >>> used with a digital signature mechanism to support security services >>> other than...revocation information signing (bit 6)." >>> >>> Obviously an OCSP Response's signature is "a signature on revocation >>> information". >>> >>> Why did RFC3280 change the required bit for signing non-CRL >>> revocation information from "cRLSign" to "digitalSignature"? >>> >>> Could we change it back, or at least allow either "cRLSign" or >>> "digitalSignature" to be deemed acceptable for signing non-CRL >>> revocation information? >> >> PHB just noted in another thread that "The point of standards is to achieve interoperability". I'll restate my question with this thought in mind. >> >> We (Comodo) sign OCSP Responses directly from CA Certificates that have the keyCertSign and cRLSign bits set but the digitalSignature bit unset. >> This is/was fully compliant with RFC2459, but (I realized only this >> week) not compliant with 3280/5280. >> >> Thus far, I've not encountered any client software that rejects our OCSP Responses. >> >> But to "achieve interoperability", I wish to ensure that no future client software rejects our OCSP Responses on the basis that the digitalSignature bit is not set in the CA Certificates. >> >> So, can we please reinstate the 2459 text that "The cRLSign bit is asserted when the subject public key is used for verifying a signature on revocation information" or at least say that cRLSign and/or digitalSignature is sufficient for this purpose? >> >> -- >> Rob Stradling >> Senior Research& Development Scientist COMODO - Creating Trust Online >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From James.H.Manger@team.telstra.com Thu May 31 16:50:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F7B11E80AB for ; Thu, 31 May 2012 16:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.724 X-Spam-Level: X-Spam-Status: No, score=-0.724 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvwndj7MOiOO for ; Thu, 31 May 2012 16:50:40 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8911311E80AA for ; Thu, 31 May 2012 16:50:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,695,1330866000"; d="scan'208";a="76249003" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 01 Jun 2012 09:50:37 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6728"; a="70123882" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 01 Jun 2012 09:50:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 1 Jun 2012 09:50:37 +1000 From: "Manger, James H" To: "Miller, Timothy J." , Santosh Chokhani , Phillip Hallam-Baker Date: Fri, 1 Jun 2012 09:50:36 +1000 Thread-Topic: [pkix] Way Forward: Name Constraints Criticality Thread-Index: Ac08GsNsKS+J4IylThCqrltUJuYcsQA1ZLMAAGgkQwAACv6ugAAEY/8AAAPYhYAAFChsAAALdGaAAACD4AD//64bAP//YkAw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4FC152E@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 23:50:40 -0000 PiBJIGd1ZXNzIEkganVzdCBkb24ndCBzZWUgd2h5IHlvdSdkIGluY2x1ZGUgTkMgaW4gYSBjZXJ0 IGJ1dCAqbm90KiBtYXJrIGl0DQo+IGNyaXRpY2FsLiAgTm9uLWNyaXRpY2FsIE5DIGJhc2ljYWxs eSBzYXlzICJCZXlvbmQgdGhpcyBwb2ludCB5b3Ugc2hvdWxkDQo+IHtvbmx5IHNlZS9uZXZlciBz ZWV9IHRoZSBmb2xsb3dpbmcgbmFtZXMsIGJ1dCB3ZSBkb24ndCBhY3R1YWxseSBjYXJlIGlmDQo+ IHlvdSBwYXkgYXR0ZW50aW9uLiINCg0KVGhlIGxhc3QgcGhyYXNlIGlzIGJldHRlciByZS1waHJh c2VkIGFzOg0KIi4uLiwgYnV0IHdlIFt0aGUgQ0FdIGRvbid0IGFjdHVhbGx5IGZvcmNlIHlvdSBb dGhlIHJlbHlpbmcgcGFydGllc10gdG8gcGF5IGF0dGVudGlvbiAtLSB0aGF0IGlzIHlvdXIgY2hv aWNlL3Jlc3BvbnNpYmlsaXR5LiINCg0KUkZDNTI4MCBhbG1vc3QgZ2l2ZXMgZWFjaCByZWx5aW5n IHBhcnR5IHRoZSBjaG9pY2UgYnkgc2F5aW5nIHRoZXkgU0hPVUxEIChub3QgTVVTVCkgaGFuZGxl IG5hbWUgY29uc3RyYWludHMgb24gZG9tYWluIG5hbWVzLCBidXQgdGhlbiBlZmZlY3RpdmVseSB0 YWtlcyBhd2F5IHRoYXQgY2hvaWNlIGJ5IGZvcmNpbmcgYSBDQSB0byBtYWtlIG9uZSBkZWNpc2lv biBmb3IgYWxsIHJlbHlpbmcgcGFydGllcyAoY3JpdGljYWwgY29uc3RyYWludCwgb3Igbm8gY29u c3RyYWludCkuIA0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg== From hallam@gmail.com Thu May 31 19:19:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3F011E8072 for ; Thu, 31 May 2012 19:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4vSM-KwPEVi for ; Thu, 31 May 2012 19:19:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A284321F84D6 for ; Thu, 31 May 2012 19:19:37 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2457016obb.31 for ; Thu, 31 May 2012 19:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=IL8rgbXXQtryk1fffKh09U5iMGcAhn5Xu4MP14HHvTc=; b=t/6SyYNWhT1iMhEWSQkK0hgL9tEJG/TaKkz/tJ3sDBgmHgqesiThKeZ78jV3i/v6hC NmLai41Re7B2z3rY5XAfOat7IrawbHiSv+nPZPZ//TwdNLsuOfQvmUJ7yUHQesw7Fzkt ZzOS8m/pBqCjlGw7NN8T9P9q046yefNGw4ue8gfnHXUD6tUVClv4MLEDj/gAke/iKYsv tbNPMvoPl+YfPDFlHA9f9TuClTxImu92zTHMtxhxTAGe9vdc5hz9XG90QNw/oAAQnyZ1 qWz9z04xrdVeHvfgo4PkdXGflokzNG/qhgClsZgazSjFPoWB7zOi4VvFFDbjK6I7AfqQ cxBw== MIME-Version: 1.0 Received: by 10.182.111.7 with SMTP id ie7mr871703obb.14.1338517177174; Thu, 31 May 2012 19:19:37 -0700 (PDT) Received: by 10.182.227.34 with HTTP; Thu, 31 May 2012 19:19:37 -0700 (PDT) In-Reply-To: <02ce01cd3f6b$c089a870$419cf950$@gmail.com> References: <02FF1B75-F277-4133-8FBC-3EDF91D01B7D@checkpoint.com> <3BECF49F-8B77-45AC-A5AA-E4154B573866@gmail.com> <02ce01cd3f6b$c089a870$419cf950$@gmail.com> Date: Thu, 31 May 2012 22:19:37 -0400 Message-ID: From: Phillip Hallam-Baker Cc: IETF PKIX Content-Type: multipart/alternative; boundary=14dae9399835df0a1304c15fd099 Subject: Re: [pkix] Way Forward: Name Constraints Criticality X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 02:19:38 -0000 --14dae9399835df0a1304c15fd099 Content-Type: text/plain; charset=ISO-8859-1 I am not going to reply to the points discussed at length already. I do however note that the security considerations for marking name constraints critical are markedly different for bridge CA configurations. In particular you are going to be a most unhappy bunny if you try to operate a bridge CA type infrastructure and do not mark your NCs as critical. In particular every CA in the bridge becomes a defacto root for every other member and the whole point of the bridge is utterly lost. Whether it is a must or a should, we probably don't want that particular point to get lost. --14dae9399835df0a1304c15fd099 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not going to reply to the points discussed at length already.

I do however note that the security considerations for = marking name constraints critical are markedly different for bridge CA conf= igurations.

In particular you are going to be a mo= st unhappy bunny if you try to operate a bridge CA type infrastructure and = do not mark your NCs as critical. In particular every CA in the bridge beco= mes a defacto root for every other member and the whole point of the bridge= is utterly lost.


Whether it is a must or a should, we pro= bably don't want that particular point to get lost.
--14dae9399835df0a1304c15fd099-- From rra@stanford.edu Thu May 31 22:14:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE521F85BD for ; Thu, 31 May 2012 22:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huFN7f+Ol5Qa for ; Thu, 31 May 2012 22:14:35 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id EFD6721F85BB for ; Thu, 31 May 2012 22:14:34 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 410BD45CC20; Thu, 31 May 2012 22:14:33 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 2541445E0C4; Thu, 31 May 2012 22:14:31 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id E36F92F435; Thu, 31 May 2012 22:14:30 -0700 (PDT) From: Russ Allbery To: denis.pinkas@bull.net In-Reply-To: (denis pinkas's message of "Thu, 31 May 2012 18:22:53 +0200") Organization: The Eyrie References: <4FC6AEDA.4010709@cs.tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Thu, 31 May 2012 22:14:30 -0700 Message-ID: <8762bbaa15.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pkix , Jim Schaad Subject: Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 05:14:36 -0000 denis.pinkas@bull.net writes: > I skimmed through the document and read the following two sentences: > The public key in the request is sent in the clear, and without any > guarantees that the requestor actually possesses the corresponding > private key. > [RFC4211], Appendix C contains a more detailed discussion of why > proof-of-possession is important. > I have concerns with both sentences. > [RFC4211] is incorrect and this has security implications on the > proposed protocol. Hi Denis, As Henry has mentioned, we have the limitation with this particular document that we're attempting to document an existing, deployed protocol sufficiently that interoperable implementations can be created. This protocol is deficient in multiple ways, and designing a better protocol is expected follow-on work. Changing something fundamental, such as requiring confidentiality in this protocol exchange, would defeat the point of the current work. Therefore, I think that any remedy here should be limited to clearly documenting the issue in the Security Considerations section rather than changing the protocol. If I'm understanding your message properly, you're saying that there is a partial defense against the lack of proof-of-possession by adding confidentiality protection to the exchange. I'm not sure in this context whether this really changes the security analysis of this protocol, given that no confidentiality is used. But if I'm missing something, could you suggest something that we could add to Security Considerations? -- Russ Allbery (rra@stanford.edu) From tomasg@primekey.se Thu May 31 23:08:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095E721F8599 for ; Thu, 31 May 2012 23:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vPsNfOWGS-H for ; Thu, 31 May 2012 23:08:24 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5A28A21F8507 for ; Thu, 31 May 2012 23:08:24 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id CCEA8E03E5 for ; Fri, 1 Jun 2012 08:08:22 +0200 (CEST) Received: from [192.168.0.3] (h195n13-aars-gr100.ias.bredband.telia.com [217.210.136.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id AF13EE01CB for ; Fri, 1 Jun 2012 08:08:22 +0200 (CEST) Message-ID: <4FC85C56.6000008@primekey.se> Date: Fri, 01 Jun 2012 08:08:22 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <4FBF4B37.1090208@comodo.com> <4FC487AB.6000603@comodo.com> <4FC775FD.2020006@comodo.com> In-Reply-To: <4FC775FD.2020006@comodo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] Integrated OCSP Responders / Key Usage bits X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 06:08:25 -0000 On 05/31/2012 03:45 PM, Rob Stradling wrote: > On 29/05/12 09:24, Rob Stradling wrote: >> On 25/05/12 10:04, Rob Stradling wrote: >>> Which Key Usage bits (if any) are required to be present in a CA >>> Certificate that directly signs OCSP Responses? >> >>> IMHO, it'd kinda make sense for the cRLSign bit to govern whether or not >>> the CA Certificate can directly sign OCSP Responses, but sadly I can >>> find no text to support this idea. >> >> I've unearthed some text to support this idea, so at least I'm now sure >> I didn't completely make it up myself! >> >> RFC2459 said... >> "The cRLSign bit is asserted when the subject public key is used for >> verifying a signature on revocation information (e.g., a CRL)." >> "The digitalSignature bit is asserted when the subject public key is >> used with a digital signature mechanism to support security services >> other than...revocation information signing (bit 6)." >> >> Obviously an OCSP Response's signature is "a signature on revocation >> information". >> >> Why did RFC3280 change the required bit for signing non-CRL revocation >> information from "cRLSign" to "digitalSignature"? That is interesting. Way back, a long time ago when we started development of integrated OCSP in EJBCA I had to assert digitalSignature in the CA certificate in order for things to work in, I think browsers. I had never considered that this behaviour might have changed, but it sounds as it has. >> >> Could we change it back, or at least allow either "cRLSign" or >> "digitalSignature" to be deemed acceptable for signing non-CRL >> revocation information? > > PHB just noted in another thread that "The point of standards is to > achieve interoperability". I'll restate my question with this thought in > mind. > > We (Comodo) sign OCSP Responses directly from CA Certificates that have > the keyCertSign and cRLSign bits set but the digitalSignature bit unset. > This is/was fully compliant with RFC2459, but (I realized only this > week) not compliant with 3280/5280. > > Thus far, I've not encountered any client software that rejects our OCSP > Responses. > > But to "achieve interoperability", I wish to ensure that no future > client software rejects our OCSP Responses on the basis that the > digitalSignature bit is not set in the CA Certificates. > > So, can we please reinstate the 2459 text that "The cRLSign bit is > asserted when the subject public key is used for verifying a signature > on revocation information" or at least say that cRLSign and/or > digitalSignature is sufficient for this purpose? >