From tero.suomela@insta.fi Fri Apr 1 01:18:54 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B7B3A6BFF for ; Fri, 1 Apr 2011 01:18:54 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pZQuPm2kGtn for ; Fri, 1 Apr 2011 01:18:53 -0700 (PDT) Received: from mail.insta.fi (mail.insta.fi [212.246.151.130]) by core3.amsl.com (Postfix) with ESMTP id E57783A6AF8 for ; Fri, 1 Apr 2011 01:18:51 -0700 (PDT) Received: from mail.insta.fi ([10.64.0.66]) by mail.insta.fi ([10.64.0.66]) with mapi; Fri, 1 Apr 2011 11:20:29 +0300 From: Suomela Tero To: "pkix@ietf.org" Date: Fri, 1 Apr 2011 11:20:28 +0300 Thread-Topic: [pkix] IETF 80: The future of PKIX certificate enrollment protocols Thread-Index: Acvv2JELuAGKdgftQ4eFjKbDce4wvwAa8gNA Message-ID: <503EB32C9885B2468531E6D637BE41121FB82E3FAE@mail.insta.fi> References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> In-Reply-To: <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.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] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:18:54 -0000 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of m= ax pritikin >> http://www.ietf.org/proceedings/80/slides/pkix-3.pdf > An important element of the EST proposal is to move the transport > security from the message layer (PKCS#7 or CMS) and instead to use TLS. > This is why we decided to call it Enrollment over Secure Transport. > TLS is well established as a transport layer security within the broader > community.=20 How does this really differ from CMP then? It has the same PKCS#10 and CRMF formats and can as well be used over TLS. I suppose the EST would be simple= r, but are there any real conceptual differences? Why choose this instead of C= MP? - Tero From kent@bbn.com Fri Apr 1 01:34:53 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8E13A6765 for ; Fri, 1 Apr 2011 01:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XREmboCDxVy2 for ; Fri, 1 Apr 2011 01:34:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 393803A63D2 for ; Fri, 1 Apr 2011 01:34:50 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:56830 helo=[130.129.20.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5ZqI-000Hz0-3o; Fri, 01 Apr 2011 04:36:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D95766D.7080303@telia.com> References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> Date: Fri, 1 Apr 2011 04:36:27 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:34:53 -0000 At 8:53 AM +0200 4/1/11, Anders Rundgren wrote: >Dear List, > >In a serious attempt keeping the discussion at a constructive >level, let me begin by scratching the surface of the enrollment >topic with a rather mundane requirement stated by banks: They >more or less always deploy a PIN to an issued credential. what does the phrase "deploy a PIN to an issued credential" mean. Do you mean a CA sends a PIN to a user, along with a cert issued to that user, in a sort of unilateral cert issuance model? or, do you mean requiring a user to send a PIN to a CA (a shared secret between the CA and the user) as part of a user requesting a cert? Steve From tomasg@primekey.se Fri Apr 1 02:33:26 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548F33A67A5 for ; Fri, 1 Apr 2011 02:33:26 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf5EyJDqkVOa for ; Fri, 1 Apr 2011 02:33:25 -0700 (PDT) Received: from mail.primekey.se (walter.primekey.se [213.179.18.6]) by core3.amsl.com (Postfix) with ESMTP id 476793A6781 for ; Fri, 1 Apr 2011 02:33:25 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 96EEDC3EAD for ; Fri, 1 Apr 2011 11:35:03 +0200 (CEST) Message-ID: <4D959C47.6020906@primekey.se> Date: Fri, 01 Apr 2011 11:35:03 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: pkix@ietf.org References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <503EB32C9885B2468531E6D637BE41121FB82E3FAE@mail.insta.fi> In-Reply-To: <503EB32C9885B2468531E6D637BE41121FB82E3FAE@mail.insta.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:33:26 -0000 On 04/01/2011 10:20 AM, Suomela Tero wrote: >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of max pritikin > >>> http://www.ietf.org/proceedings/80/slides/pkix-3.pdf > >> An important element of the EST proposal is to move the transport >> security from the message layer (PKCS#7 or CMS) and instead to use TLS. >> This is why we decided to call it Enrollment over Secure Transport. >> TLS is well established as a transport layer security within the broader >> community. > > How does this really differ from CMP then? It has the same PKCS#10 and CRMF > formats and can as well be used over TLS. I suppose the EST would be simpler, > but are there any real conceptual differences? Why choose this instead of CMP? Because the packaging around CMP is complex with lots and lots of options. Creating the PKCS#10 or CRMF are the easy parts, the tricky part with CMP comes after. Just passing them through TLS is trivial. Cheers, Tomas From denis.pinkas@bull.net Fri Apr 1 03:00:15 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC073A67D6; Fri, 1 Apr 2011 03:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.359 X-Spam-Level: ** X-Spam-Status: No, score=2.359 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0iFPLCjv++J; Fri, 1 Apr 2011 03:00:12 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id B85FC3A6783; Fri, 1 Apr 2011 03:00:11 -0700 (PDT) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 883EB198148; Fri, 1 Apr 2011 12:10:17 +0200 (CEST) Received: from B016404 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2011040112015096:2416 ; Fri, 1 Apr 2011 12:01:50 +0200 From: "Denis Pinkas" To: "pkix-bounces", "pkix" Date: Fri, 1 Apr 2011 12:01:50 +0200 Message-Id: References: <1B12070B-083A-48F3-9041-C37FEB67695F@carillon.ca> MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 01/04/2011 12:01:50, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 01/04/2011 12:01:51, Serialize complete at 01/04/2011 12:01:51 Content-Type: multipart/alternative; boundary="----=_NextPart_11040112015009771358507_002" Subject: Re: [pkix] New draft for consideration as a work item. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:00:15 -0000 ------=_NextPart_11040112015009771358507_002 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ISO-8859-1" SXQgaXMgYSBnb29kIGluaXRpYXRpdmUgYW5kIHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIGEgbmV3 IHdvcmsgaXRlbSBmb3IgdGhpcyBncm91cC4NCg0KSG93ZXZlciwgdGhpcyBkcmFmdCBpcyBub3Qg Z29pbmcgdG8gYmUgYWNjZXB0ZWQgd2l0aDogDQo0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN CiAgICAgTm9uZS4NClRoZSB2YXJpb3VzIFNIT1VMRCBmcm9tIHNlY3Rpb24gMyBzaG91bGQgYmUg ZXhwbGFpbmVkIGluIHNlY3Rpb24gNC4NCkRlbmlzDQotLS0tLSBNZXNzYWdlIHJl53UgLS0tLS0g DQpEZSA6IHBraXgtYm91bmNlcyANCsAgOiBwa2l4IA0KRGF0ZSA6IDIwMTEtMDMtMzEsIDE3OjA2 OjM1DQpTdWpldCA6IFtwa2l4XSBOZXcgZHJhZnQgZm9yIGNvbnNpZGVyYXRpb24gYXMgYSB3b3Jr IGl0ZW0uDQoNCg0KSGVsbG8gYWxsOg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcGF0 dGVyc29uLXBraXgtYXR0cmlidXRlLXNpZ25pbmctZWt1LTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgDQpzdWJtaXR0ZWQgYnkgUGF0cmljayBQYXR0ZXJzb24gYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogZHJhZnQtcGF0dGVyc29uLXBraXgtYXR0cmli dXRlLXNpZ25pbmctZWt1DQpSZXZpc2lvbjogMDANClRpdGxlOiBhdHRyaWJ1dGVTaWduaW5nIGV4 dGVuZGVkS2V5VXNhZ2UgdmFsdWUNCkNyZWF0aW9uX2RhdGU6IDIwMTEtMDMtMjgNCldHIElEOiBJ bmRlcGVuZGVudCBTdWJtaXNzaW9uDQpOdW1iZXJfb2ZfcGFnZXM6IDgNCg0KQWJzdHJhY3Q6DQpU aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHZhbHVlIGZvciB0aGUgZXh0ZW5kZWRLZXlVc2FnZSBY LjUwOQ0KZXh0ZW5zaW9uIHRoYXQgbWF5IGJlIHVzZWQgdG8gY3JlYXRlIGEgY2VydGlmaWNhdGUg dGhhdCB3b3VsZCBiZSB1c2VkDQp0byBzaWduIGF0dHJpYnV0ZSBhc3NlcnRpb25zLiBUaGlzIGFs bG93cyB0aGUgZGlmZmVyZW50aWF0aW9uIG9mDQpjZXJ0aWZpY2F0ZXMgdXNlZCB0byBpZGVudGlm eSBhIHBhcnRpY3VsYXIgc2VydmVyICh3aGljaCB3b3VsZCBoYXZlIGENCnNlcnZlckF1dGggRUtV KSwgZnJvbSB0aGUgY2VydGlmaWNhdGUgdXNlZCBieSB0aGF0IHNlcnZlciB0byBzaWduDQphdHRy aWJ1dGUgYXNzZXJ0aW9ucywgYW5kIHdvdWxkIGVhc2lseSBhbGxvdyBhIHBvbGljeSB0byBiZSBk ZXZlbG9wZWQNCmZvciBpc3N1YW5jZSBvZiBzdWNoIGEgY2VydGlmaWNhdGUgdG8gYW4gaWRlbnRp dHkgcHJvdmlkZXIuDQoNCkkgd291bGQgYXNrIHRoYXQgdGhlIGFib3ZlIGJlIGNvbnNpZGVyZWQg YXMgYSBuZXcgd29yayBpdGVtIGZvciB0aGlzIGdyb3VwLg0KDQpUaGFuayB5b3UuDQoNCi0tLQ0K UGF0cmljayBQYXR0ZXJzb24NCkNoaWVmIFBLSSBBcmNoaXRlY3QNCkNhcmlsbG9uIEluZm9ybWF0 aW9uIFNlY3VyaXR5IEluYy4NCmh0dHA6Ly93d3cuY2FyaWxsb24uY2ENCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBraXggbWFpbGluZyBsaXN0DQpw a2l4QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgN Cg== ------=_NextPart_11040112015009771358507_002 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ISO-8859-1" PEhUTUw+PEhFQUQ+PFRJVExFPjwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJLc0RIVE1MRURMaWIu b2N4LCBGcmVlV2FyZSBIVE1MIEVkaXRvciAxLjE2NC4yLCCpIEt1cnQgU2VuZmVyIiANCm5hbWU9 R0VORVJBVE9SPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiIGxlZnRNYXJnaW49NSB0b3BNYXJnaW49NSANCiNm ZmZmZmY+DQo8UD5JdCBpcyBhIGdvb2QgaW5pdGlhdGl2ZSBhbmQgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgYXMgYSBuZXcgd29yayBpdGVtIGZvciB0aGlzIA0KZ3JvdXAuPEJSPjxCUj5Ib3dldmVyLCB0 aGlzIGRyYWZ0IGlzIG5vdCBnb2luZyB0byBiZSBhY2NlcHRlZCB3aXRoOiA8L1A+DQo8UD48U1BB TiBsYW5nPUVOLUdCIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjQuPFNQQU4gDQpz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+U2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM8QlI+PC9TUEFOPjxTUEFOIA0KbGFuZz1FTi1HQiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3Vh Z2U6IEVOLUdCIj48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOzwvU1BBTj5Ob25lLjw/eG1sOm5hbWVzcGFjZSANCnByZWZpeCA9IG8gbnMg PSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiANCi8+PG86cD48L286 cD48L1NQQU4+PC9QPg0KPFA+VGhlIHZhcmlvdXMgU0hPVUxEIGZyb20gc2VjdGlvbiAzIHNob3Vs ZCBiZSBleHBsYWluZWQgaW4gc2VjdGlvbiA0LjwvUD4NCjxQPkRlbmlzPC9QPg0KPEJMT0NLUVVP VEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lO LUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6 IDBweCI+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6 IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklB TlQ6IG5vcm1hbCI+LS0tLS0gDQogIE1lc3NhZ2UgcmXndSAtLS0tLSA8L0RJVj4NCiAgPERJViAN CiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBCQUNLR1JPVU5E OiAjZTRlNGU0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQt VkFSSUFOVDogbm9ybWFsOyBmb250LWNvbG9yOiBibGFjayI+PEI+RGUgDQogIDo8L0I+IDxBIGhy ZWY9Im1haWx0byA6cGtpeC1ib3VuY2VzQGlldGYub3JnIj5wa2l4LWJvdW5jZXM8L0E+IDwvRElW Pg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7 IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBu b3JtYWwiPjxCPsAgDQogIDo8L0I+IDxBIGhyZWY9Im1haWx0byA6cGtpeEBpZXRmLm9yZyI+cGtp eDwvQT4gPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05U LVNJWkU6IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05U LVZBUklBTlQ6IG5vcm1hbCI+PEI+RGF0ZSANCiAgOjwvQj4gMjAxMS0wMy0zMSwgMTc6MDY6MzU8 L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTog OXB0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFO VDogbm9ybWFsIj48Qj5TdWpldCANCiAgOjwvQj4gW3BraXhdIE5ldyBkcmFmdCBmb3IgY29uc2lk ZXJhdGlvbiBhcyBhIHdvcmsgaXRlbS48L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+ PC9ESVY+DQogIDxESVY+PC9ESVY+DQogIDxESVY+DQogIDxESVY+SGVsbG8gYWxsOjxCUj48QlI+ QSBuZXcgdmVyc2lvbiBvZiBJLUQsIA0KICBkcmFmdC1wYXR0ZXJzb24tcGtpeC1hdHRyaWJ1dGUt c2lnbmluZy1la3UtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSANCiAgPEJSPnN1Ym1pdHRl ZCBieSBQYXRyaWNrIFBhdHRlcnNvbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIA0KICByZXBvc2l0 b3J5LjxCUj48QlI+RmlsZW5hbWU6IA0KICBkcmFmdC1wYXR0ZXJzb24tcGtpeC1hdHRyaWJ1dGUt c2lnbmluZy1la3U8QlI+UmV2aXNpb246IDAwPEJSPlRpdGxlOiANCiAgYXR0cmlidXRlU2lnbmlu ZyBleHRlbmRlZEtleVVzYWdlIHZhbHVlPEJSPkNyZWF0aW9uX2RhdGU6IDIwMTEtMDMtMjg8QlI+ V0cgSUQ6IA0KICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uPEJSPk51bWJlcl9vZl9wYWdlczogODxC Uj48QlI+QWJzdHJhY3Q6PEJSPlRoaXMgZG9jdW1lbnQgDQogIHNwZWNpZmllcyBhIHZhbHVlIGZv ciB0aGUgZXh0ZW5kZWRLZXlVc2FnZSBYLjUwOTxCUj5leHRlbnNpb24gdGhhdCBtYXkgYmUgdXNl ZCANCiAgdG8gY3JlYXRlIGEgY2VydGlmaWNhdGUgdGhhdCB3b3VsZCBiZSB1c2VkPEJSPnRvIHNp Z24gYXR0cmlidXRlIGFzc2VydGlvbnMuIA0KICBUaGlzIGFsbG93cyB0aGUgZGlmZmVyZW50aWF0 aW9uIG9mPEJSPmNlcnRpZmljYXRlcyB1c2VkIHRvIGlkZW50aWZ5IGEgDQogIHBhcnRpY3VsYXIg c2VydmVyICh3aGljaCB3b3VsZCBoYXZlIGE8QlI+c2VydmVyQXV0aCBFS1UpLCBmcm9tIHRoZSBj ZXJ0aWZpY2F0ZSANCiAgdXNlZCBieSB0aGF0IHNlcnZlciB0byBzaWduPEJSPmF0dHJpYnV0ZSBh c3NlcnRpb25zLCBhbmQgd291bGQgZWFzaWx5IGFsbG93IGEgDQogIHBvbGljeSB0byBiZSBkZXZl bG9wZWQ8QlI+Zm9yIGlzc3VhbmNlIG9mIHN1Y2ggYSBjZXJ0aWZpY2F0ZSB0byBhbiBpZGVudGl0 eSANCiAgcHJvdmlkZXIuPEJSPjxCUj5JIHdvdWxkIGFzayB0aGF0IHRoZSBhYm92ZSBiZSBjb25z aWRlcmVkIGFzIGEgbmV3IHdvcmsgaXRlbSANCiAgZm9yIHRoaXMgZ3JvdXAuPEJSPjxCUj5UaGFu ayB5b3UuPEJSPjxCUj4tLS08QlI+UGF0cmljayBQYXR0ZXJzb248QlI+Q2hpZWYgUEtJIA0KICBB cmNoaXRlY3Q8QlI+Q2FyaWxsb24gSW5mb3JtYXRpb24gU2VjdXJpdHkgSW5jLjxCUj48QSANCiAg aHJlZj0iaHR0cDovL3d3dy5jYXJpbGxvbi5jYSI+aHR0cDovL3d3dy5jYXJpbGxvbi5jYTwvQT48 QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJS PnBraXggDQogIG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJtYWlsdG86IHBraXhAaWV0Zi5vcmci PnBraXhAaWV0Zi5vcmc8L0E+PEJSPjxBIA0KICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3BraXgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGtpeDwvQT48QlI+PEJSPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1M Pg0K ------=_NextPart_11040112015009771358507_002-- From pgut001@login01.cs.auckland.ac.nz Fri Apr 1 03:07:51 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41FC3A67CC for ; Fri, 1 Apr 2011 03:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmATuMfIOzoI for ; Fri, 1 Apr 2011 03:07:50 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 6B41D3A67A6 for ; Fri, 1 Apr 2011 03:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1301652571; x=1333188571; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pkix@ietf.org,=20tomasg@primekey.se|Subject:=20Re: =20[pkix]=20IETF=2080:=20The=20future=20of=20PKIX=20certi ficate=09enrollment=09protocols|In-Reply-To:=20<4D959C47. 6020906@primekey.se>|Message-Id:=20|Date:=20Fri,=2001=20Apr=202011 =2023:09:22=20+1300; bh=IQchXmxKKjEyEQRWARFtuRo63bKhFPANnRM1xtWJlIY=; b=nmUjhPr76KZ0EA8XX7ygiFor9/cCve4nvAyxUoqlQSZmUMcVQo9R38AT 00Hcin19Z6ACfFz84ZWptb1TYTz88CdmlWN0KXNYoUTkEdufyx++4dUvR 0BxGryuW0oBEjYG/DmslghzA7sJvittDfcGzoKH+fQhAnxVK73KcuG6SM U=; X-IronPort-AV: E=Sophos;i="4.63,281,1299409200"; d="scan'208";a="54654662" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Apr 2011 23:09:22 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q5bIA-0007Jb-H4; Fri, 01 Apr 2011 23:09:22 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q5bIA-000297-7d; Fri, 01 Apr 2011 23:09:22 +1300 From: Peter Gutmann To: pkix@ietf.org, tomasg@primekey.se In-Reply-To: <4D959C47.6020906@primekey.se> Message-Id: Date: Fri, 01 Apr 2011 23:09:22 +1300 Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:07:51 -0000 Tomas Gustavsson writes: >Because the packaging around CMP is complex with lots and lots of options. >Creating the PKCS#10 or CRMF are the easy parts, the tricky part with CMP >comes after. Just passing them through TLS is trivial. You're being polite :-). A more succint way of putting it would be "Almost anything is less painful than trying to work with CMP". This is (presumably) one reason why SCEP, which is rather a kludge, remains so popular. Peter. From tomasg@primekey.se Fri Apr 1 08:03:39 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D6E3A686A for ; Fri, 1 Apr 2011 08:03:39 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvRI9M3IEfzj for ; Fri, 1 Apr 2011 08:03:39 -0700 (PDT) Received: from mail.primekey.se (walter.primekey.se [213.179.18.6]) by core3.amsl.com (Postfix) with ESMTP id 1A2E23A683E for ; Fri, 1 Apr 2011 08:03:37 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 4E4FDC473A; Fri, 1 Apr 2011 17:05:17 +0200 (CEST) Message-ID: <4D95E9AD.90108@primekey.se> Date: Fri, 01 Apr 2011 17:05:17 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 15:03:39 -0000 On 04/01/2011 12:09 PM, Peter Gutmann wrote: > Tomas Gustavsson writes: > >> Because the packaging around CMP is complex with lots and lots of options. >> Creating the PKCS#10 or CRMF are the easy parts, the tricky part with CMP >> comes after. Just passing them through TLS is trivial. > > You're being polite :-). A more succint way of putting it would be "Almost > anything is less painful than trying to work with CMP". This is (presumably) > one reason why SCEP, which is rather a kludge, remains so popular. Succinct is a new work in my dictionary, thanks :-) Agree on SCEP, I though it horrid when I first implemented it, but now it kind of does the job, easier to grasp than CMP. I'd say CMP almost works with the 1 or 2 options that are actually in the wild. Stripping the standard leaving only the few options actually used would make it almost usable. The ones I've seen are enrollment, revocation (and possibly keyrecovery) using PasswordBaseHMAC authentication and enrollment (includes renewal) using digital signature authentication. Always exciting when you encounter a new CMP client and have to make some small adjustments :-) Cheers, Tomas From pritikin@cisco.com Fri Apr 1 15:48:56 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53F728C10C for ; Fri, 1 Apr 2011 15:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIStjdQ6hacx for ; Fri, 1 Apr 2011 15:48:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8907F28C108 for ; Fri, 1 Apr 2011 15:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1721; q=dns/txt; s=iport; t=1301698214; x=1302907814; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=K59b296Bzp8A3BS3TAafpvydLHcxmiBY10dmtGV2xg4=; b=gHPDySu4xUuseZMc3YqSreZsOxWLjtim5AkOgRoGCjXk6HwrWsiTiRzC vywo0jiRNdoEpLRCDszw+lphLvg01SRDMlBmw02PtWWZRW5KOc+8UNEQ4 iT5h9cTZ0lKOoC31CU8teTrj6RYL0pk/FiQJzYyzssqdn5NrgfIB+mtAG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFVVlk2rRDoH/2dsb2JhbAClYneIeZwinBqFawSFRIdXg1k X-IronPort-AV: E=Sophos;i="4.63,285,1299456000"; d="scan'208";a="422649640" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2011 22:50:14 +0000 Received: from [10.101.1.82] (sjc-vpn7-1567.cisco.com [10.21.150.31]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p31MoDLB032287; Fri, 1 Apr 2011 22:50:14 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: <4D95E9AD.90108@primekey.se> Date: Fri, 1 Apr 2011 16:50:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D95E9AD.90108@primekey.se> To: Tomas Gustavsson X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 22:48:56 -0000 I agree with these comments.=20 A sufficiently restricted profile of CMP would be an improvement = regarding interoperability but would still be significantly more complex = than simply depending on TLS as a secure transport. - max On Apr 1, 2011, at 9:05 AM, Tomas Gustavsson wrote: > On 04/01/2011 12:09 PM, Peter Gutmann wrote: >> Tomas Gustavsson writes: >>=20 >>> Because the packaging around CMP is complex with lots and lots of = options. >>> Creating the PKCS#10 or CRMF are the easy parts, the tricky part = with CMP >>> comes after. Just passing them through TLS is trivial. >>=20 >> You're being polite :-). A more succint way of putting it would be = "Almost >> anything is less painful than trying to work with CMP". This is = (presumably) >> one reason why SCEP, which is rather a kludge, remains so popular. >=20 > Succinct is a new work in my dictionary, thanks :-) >=20 > Agree on SCEP, I though it horrid when I first implemented it, but now > it kind of does the job, easier to grasp than CMP. >=20 > I'd say CMP almost works with the 1 or 2 options that are actually in > the wild. Stripping the standard leaving only the few options actually > used would make it almost usable. The ones I've seen are enrollment, > revocation (and possibly keyrecovery) using PasswordBaseHMAC > authentication and enrollment (includes renewal) using digital = signature > authentication. > Always exciting when you encounter a new CMP client and have to make > some small adjustments :-) >=20 > Cheers, > Tomas > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pgut001@login01.cs.auckland.ac.nz Fri Apr 1 19:10:35 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6942E28C104 for ; Fri, 1 Apr 2011 19:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28udyn2WsSvY for ; Fri, 1 Apr 2011 19:10:34 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id C3E1828C0E3 for ; Fri, 1 Apr 2011 19:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1301710335; x=1333246335; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20tomasg@primekey.se |Subject:=20Re:=20[pkix]=20IETF=2080:=20The=20future=20of =20PKIX=20certificate=09enrollment=09protocols|Cc:=20pkix @ietf.org|In-Reply-To:=20<4D95E9AD.90108@primekey.se> |Message-Id:=20|Date:=20Sat,=2002=20Apr=202011=2015:12:06=20+1300; bh=FPSkO1UXCPcoLi+I/syq1F5YDC15Fg0BzQ77Z+fYkh4=; b=VEQn9YAtBpJCdm01yLwcA6xi24U05styvEJdFlGozOJYjNlT3zAPpnlQ i25I1vhF1lYTfGWWGSam7JkHIFIefHmpLXJXH9Vsns5UbHX0Xpr8krfw1 zmiUxvmvvrld7Xn5gTKsiiBZ7hTJnPCLmjogJWY3emmDdMBX1sMUb+dir 8=; X-IronPort-AV: E=Sophos;i="4.63,286,1299409200"; d="scan'208";a="54702780" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Apr 2011 15:12:06 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q5qJq-0001DS-HT; Sat, 02 Apr 2011 15:12:06 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q5qJq-000621-Bx; Sat, 02 Apr 2011 15:12:06 +1300 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, tomasg@primekey.se In-Reply-To: <4D95E9AD.90108@primekey.se> Message-Id: Date: Sat, 02 Apr 2011 15:12:06 +1300 Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 02:10:35 -0000 Tomas Gustavsson writes: >I'd say CMP almost works with the 1 or 2 options that are actually in the >wild. Stripping the standard leaving only the few options actually used would >make it almost usable. I've actually tried this in the past, during the 2000/2001 (non-)interop (I still have to notes somewhere, from late 2000). The problem is that once you remove the options that are unnecessary, the options that are incomprehensible (there were things in there that even the RFC authors couldn't explain when asked), and the options that no-one can agree on, what's left is something that isn't anything like CMP any more. For example many of the unnecessary/incomprehensible options are mandatory, so you have to invent non- values to put in there to fill them up, and conversely some of the optional options, if they're not present, will cause things to break... actually I've said all this before: http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix03.pdf So to "fix" CMP you end up re-doing it into something that isn't CMP any more. Every now and then I look at my code and think "yeah, I could probably get away with that", but then given that it's pretty much dead anyway (there are what, 3? 4? implementations left) I'm not sure that it's worth the effort. How much interest would there really be in creating (sigh, yet another) cert management protocol based on a rewrite of CMP that actually works? My "let's actually do it properly" itch would get scratched, but would anyone notice? Peter. From kent@bbn.com Sat Apr 2 02:08:22 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C421D3A6A67 for ; Sat, 2 Apr 2011 02:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6I8PXpuVvdGY for ; Sat, 2 Apr 2011 02:08:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 474353A6A5A for ; Sat, 2 Apr 2011 02:08:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45282 helo=[172.30.28.142]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5wqG-0006Zh-Qc; Sat, 02 Apr 2011 05:10:01 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D95E9AD.90108@primekey.se> Date: Sat, 2 Apr 2011 04:44:14 -0400 To: max pritikin From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:08:22 -0000 At 4:50 PM -0600 4/1/11, max pritikin wrote: >I agree with these comments. > >A sufficiently restricted profile of CMP would be an improvement >regarding interoperability but would still be significantly more >complex than simply depending on TLS as a secure transport. > >- max Max, As I noted during the PKIX meeting, one concern about relying on TLS is that most TLS implementations are pretty poor re PKI details. Thus using TLS as a building block for cert issuance will have to be very carefully vetted. Steve From anders.rundgren@telia.com Sat Apr 2 02:08:31 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393CB3A6A71 for ; Sat, 2 Apr 2011 02:08:31 -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.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SoeCU3XpVkG for ; Sat, 2 Apr 2011 02:08:30 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id B1CC83A6A6F for ; Sat, 2 Apr 2011 02:08:29 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA00EAD805; Sat, 2 Apr 2011 11:10:06 +0200 Message-ID: <4D96E7F5.7060904@telia.com> Date: Sat, 02 Apr 2011 11:10:13 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephen Kent References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:08:31 -0000 On 2011-04-01 10:36, Stephen Kent wrote: > At 8:53 AM +0200 4/1/11, Anders Rundgren wrote: >> Dear List, >> >> In a serious attempt keeping the discussion at a constructive >> level, let me begin by scratching the surface of the enrollment >> topic with a rather mundane requirement stated by banks: They >> more or less always deploy a PIN to an issued credential. > > what does the phrase "deploy a PIN to an issued credential" mean. > Do you mean a CA sends a PIN to a user, along with a cert issued to that user, > in a sort of unilateral cert issuance model? Yes, that's one way banks and governments deal with PIN-codes. The "unilateral issuance model" as you appropriately called it, also typically only cares about the public key in a CSR. > or, do you mean > requiring a user to send a PIN to a CA (a shared secret between the > CA and the user) as part of a user requesting a cert? No, I didn't mean anything related to the user authenticating to the CA. Authentication is BTW, not even a part of the proprietary enrollment protocols referred to since they are without exception browser-based using all-over-the-map web-methods and procedures for user authentication. In addition, there's a widely implemented variant of PIN deployment which is based on the user defining a PIN locally while still (also locally) enforcing that it adheres to the issuer's policy. Many PIN deployment schemes support a PIN covering multiple credentials. IMO, multi-step enrollment systems should use "Secure Messaging" where you establish a TLS-like channel between the cryptographic container and the issuer. This is where the industry is going AFAICT. A recent IETF standard that deals with PIN-codes during provisioning: http://datatracker.ietf.org/wg/keyprov Anders Rundgren Invited Expert member TrustedComputingGroup From pgut001@login01.cs.auckland.ac.nz Sat Apr 2 02:31:55 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9A83A6A53 for ; Sat, 2 Apr 2011 02:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ1p0oIZ5V4Q for ; Sat, 2 Apr 2011 02:31:54 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 641D03A69EE for ; Sat, 2 Apr 2011 02:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1301736816; x=1333272816; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20kent@bbn.com,=20pritikin@cisco.com|Subject:=20Re: =20[pkix]=20IETF=2080:=20The=20future=20of=20PKIX=20certi ficate=09enrollment=20protocols|Cc:=20pkix@ietf.org |In-Reply-To:=20 |Message-Id:=20|Date:=20Sat,=2002=20Apr=202011=2022:33:27=20+1300; bh=/kEVtbET668ChRurYp0fevoWrn3qGmiKS4UGIX6rFsA=; b=UJ6LzfzlpD5SEr7xybeiKaZCSL7y7pMCIwuWe6b4B8E68ctBYgVxrRcZ BihPaLjOd0ApBezBf+cTGRdi+VvfBdLoD/mPkaRy3RV3P6g/xQ8Erej2j hAahv8pPCgpKr7wlLIPwsELYr517Xbb5vmLOD63NlWqx9150szC7X8ybw A=; X-IronPort-AV: E=Sophos;i="4.63,287,1299409200"; d="scan'208";a="54723344" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Apr 2011 22:33:28 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q5xCx-00058g-Gg; Sat, 02 Apr 2011 22:33:27 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q5xCx-0002AV-3y; Sat, 02 Apr 2011 22:33:27 +1300 From: Peter Gutmann To: kent@bbn.com, pritikin@cisco.com In-Reply-To: Message-Id: Date: Sat, 02 Apr 2011 22:33:27 +1300 Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:31:55 -0000 Stephen Kent writes: >As I noted during the PKIX meeting, one concern about relying on TLS is that >most TLS implementations are pretty poor re PKI details. Thus using TLS as a >building block for cert issuance will have to be very carefully vetted. If you use TLS-PSK or -SRP, you're getting the same security as CMP. With both protocols you can then bootstrap further requests with the certs you've got (or continue with the PSK if you prefer). Peter. From kent@bbn.com Sat Apr 2 02:38:39 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518123A6A6C for ; Sat, 2 Apr 2011 02:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwP9yC8BfJMk for ; Sat, 2 Apr 2011 02:38:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 516963A69EE for ; Sat, 2 Apr 2011 02:38:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52445 helo=[172.30.28.142]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5xJa-0006fi-Uh; Sat, 02 Apr 2011 05:40:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D96E7F5.7060904@telia.com> References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> <4D96E7F5.7060904@telia.com> Date: Sat, 2 Apr 2011 05:39:56 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:38:39 -0000 At 11:10 AM +0200 4/2/11, Anders Rundgren wrote: >On 2011-04-01 10:36, Stephen Kent wrote: >> At 8:53 AM +0200 4/1/11, Anders Rundgren wrote: >>> Dear List, >>> >>> In a serious attempt keeping the discussion at a constructive >>> level, let me begin by scratching the surface of the enrollment >>> topic with a rather mundane requirement stated by banks: They >>> more or less always deploy a PIN to an issued credential. >> >> what does the phrase "deploy a PIN to an issued credential" mean. >> Do you mean a CA sends a PIN to a user, along with a cert issued >>to that user, >> in a sort of unilateral cert issuance model? > >Yes, that's one way banks and governments deal with PIN-codes. >The "unilateral issuance model" as you appropriately called it, >also typically only cares about the public key in a CSR. For this use case, CMP and CMC both have that capability. Also, in the U.S. DoD PKI, the public key is NOT the only the cert request value of interest. So, that's one example of a government-issued credential that runs counter to your assertion. > > or, do you mean >> requiring a user to send a PIN to a CA (a shared secret between the >> CA and the user) as part of a user requesting a cert? > >No, I didn't mean anything related to the user authenticating to the CA. I had personal experience am with CAs that used a PIN sent to a user as part of authenticating the user before allowing him to retrieve an issued cert. So, that model is not unknown, even if is not what you had in mind when you used the ambiguous phrase "deploy a PIN to an issued credential." >... > >IMO, multi-step enrollment systems should use "Secure Messaging" where >you establish a TLS-like channel between the cryptographic container >and the issuer. This is where the industry is going AFAICT. Are you suggesting using a "TLS-like" channel between a chip on a smart card and an HSM at an issuer? Again, it's not clear from the terms you are using. If so, then you should be talking to some ISO committee, because they deal with smart card standards. >A recent IETF standard that deals with PIN-codes during provisioning: >http://datatracker.ietf.org/wg/keyprov KEYPROV (now concluded) dealt with symmetric keys. Also, BTW, your URL does not point to any specific doc, but rather the full set of WG docs. Presumably the doc you had in mind is other than RFC 6031, since that one uses CMS :-). Steve From anders.rundgren@telia.com Sat Apr 2 02:42:20 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9E33A6A6A for ; Sat, 2 Apr 2011 02:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbaM-DYYbA59 for ; Sat, 2 Apr 2011 02:42:19 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by core3.amsl.com (Postfix) with ESMTP id 75DBD3A69EE for ; Sat, 2 Apr 2011 02:42:19 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A100EB3D55 for pkix@ietf.org; Sat, 2 Apr 2011 11:43:59 +0200 Message-ID: <4D96EFE6.3000602@telia.com> Date: Sat, 02 Apr 2011 11:44:06 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:42:20 -0000 On 2011-04-02 11:33, Peter Gutmann wrote: > Stephen Kent writes: > >> As I noted during the PKIX meeting, one concern about relying on TLS is that >> most TLS implementations are pretty poor re PKI details. Thus using TLS as a >> building block for cert issuance will have to be very carefully vetted. > > If you use TLS-PSK or -SRP, you're getting the same security as CMP. With > both protocols you can then bootstrap further requests with the certs you've > got (or continue with the PSK if you prefer). And by using embedded device certificates you get full end-to-end security without requiring a major server upgrade which TLS-PSK or TlS-SRP presumes. Anders From pgut001@login01.cs.auckland.ac.nz Sat Apr 2 03:58:00 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B7B3A6783 for ; Sat, 2 Apr 2011 03:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hohqpzPsJXo2 for ; Sat, 2 Apr 2011 03:57:59 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 06DAB3A6774 for ; Sat, 2 Apr 2011 03:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1301741979; x=1333277979; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20pkix@ietf.org |Subject:=20Re:=20[pkix]=20IETF=2080:=20The=20future=20of =20PKIX=20certificate=09enrollment=09protocols |In-Reply-To:=20<4D96EFE6.3000602@telia.com>|Message-Id: =20|Date: =20Sat,=2002=20Apr=202011=2023:59:35=20+1300; bh=xZscXyLeSRRQ7SZiT44WvKyQpq9Gz7+w7nbtS9aXe8A=; b=cVEm2HAlrUwJ7aiapwstqF5QxMu3P2/eOJZS5XQ2s21zjME+L3qjXASM eIel/epAld/jpRyt6Mr86eGE9vleI3MXOgnnpBerbNHVu/tXYnznOy0qM qcSsT6Nyp/IjXU0CcsDWY69GihFaruC+MG+6SExTaons290xA9seqmOUc o=; X-IronPort-AV: E=Sophos;i="4.63,287,1299409200"; d="scan'208";a="54726840" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Apr 2011 23:59:35 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q5yYJ-0007OF-H4; Sat, 02 Apr 2011 23:59:35 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q5yYJ-00067i-7q; Sat, 02 Apr 2011 23:59:35 +1300 From: Peter Gutmann To: anders.rundgren@telia.com, pkix@ietf.org In-Reply-To: <4D96EFE6.3000602@telia.com> Message-Id: Date: Sat, 02 Apr 2011 23:59:35 +1300 Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 10:58:00 -0000 Anders Rundgren writes: >And by using embedded device certificates you get full end-to-end security >without requiring a major server upgrade which TLS-PSK or TlS-SRP presumes. And you get your device certificates by ...... ? (More to the point, if you've already got device certs then you can just use them to move CMS blobs around, and don't need either CMP or TLS). Peter. From turners@ieca.com Sat Apr 2 04:43:08 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25BB53A67C1 for ; Sat, 2 Apr 2011 04:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Xm8HWWZFDK for ; Sat, 2 Apr 2011 04:43:07 -0700 (PDT) Received: from nm11.bullet.mail.bf1.yahoo.com (nm11.bullet.mail.bf1.yahoo.com [98.139.212.170]) by core3.amsl.com (Postfix) with SMTP id 1BBC13A67B7 for ; Sat, 2 Apr 2011 04:43:07 -0700 (PDT) Received: from [98.139.212.146] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 02 Apr 2011 11:44:45 -0000 Received: from [98.139.212.195] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 02 Apr 2011 11:44:45 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 02 Apr 2011 11:44:45 -0000 X-Yahoo-Newman-Id: 314303.80519.bm@omp1004.mail.bf1.yahoo.com Received: (qmail 18927 invoked from network); 2 Apr 2011 11:44:45 -0000 Received: from thunderfish.local (turners@198.180.150.234 with plain) by smtp103.biz.mail.bf1.yahoo.com with SMTP; 02 Apr 2011 04:44:44 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: HsEGecYVM1lIBEyFtRb_2KnT0Hgy8xiWjA0J6.sTqG2xpYI WKnin2DxIJREwDAj2CD9RDRzxzPnKSAetVRgfNwhRELiv_SQX7sqqwCWjdVi CNIO86qPW1QL1kD7uZLWrSvWId1dXJOYCTbx747xmtmUYoP0imIJ0U8iz.Ux z8pFL24YOCPx6Sa6xLc.CdXSin4TEYj21DyB1AWTyI77Mkyor_1B3CIGImPN _ZX6a_6firykiX0rvIqUw5y5dy.k5tT81KBMz8x1WiyjCqgQcrLCwWBo.gsO 82tGRrIpN4gJEmiUB X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D970C2D.2090007@ieca.com> Date: Sat, 02 Apr 2011 13:44:45 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: pkix@ietf.org References: <4D95E9AD.90108@primekey.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 11:43:08 -0000 On 4/2/11 12:50 AM, max pritikin wrote: > > I agree with these comments. > > A sufficiently restricted profile of CMP would be an improvement regarding interoperability but would still be significantly more complex than simply depending on TLS as a secure transport. The same could be said of CMC. spt > - max > > On Apr 1, 2011, at 9:05 AM, Tomas Gustavsson wrote: > >> On 04/01/2011 12:09 PM, Peter Gutmann wrote: >>> Tomas Gustavsson writes: >>> >>>> Because the packaging around CMP is complex with lots and lots of options. >>>> Creating the PKCS#10 or CRMF are the easy parts, the tricky part with CMP >>>> comes after. Just passing them through TLS is trivial. >>> >>> You're being polite :-). A more succint way of putting it would be "Almost >>> anything is less painful than trying to work with CMP". This is (presumably) >>> one reason why SCEP, which is rather a kludge, remains so popular. >> >> Succinct is a new work in my dictionary, thanks :-) >> >> Agree on SCEP, I though it horrid when I first implemented it, but now >> it kind of does the job, easier to grasp than CMP. >> >> I'd say CMP almost works with the 1 or 2 options that are actually in >> the wild. Stripping the standard leaving only the few options actually >> used would make it almost usable. The ones I've seen are enrollment, >> revocation (and possibly keyrecovery) using PasswordBaseHMAC >> authentication and enrollment (includes renewal) using digital signature >> authentication. >> Always exciting when you encounter a new CMP client and have to make >> some small adjustments :-) >> >> Cheers, >> Tomas >> _______________________________________________ >> 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 anders.rundgren@telia.com Sat Apr 2 04:45:19 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10E73A67BD for ; Sat, 2 Apr 2011 04:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQeexwNasVPV for ; Sat, 2 Apr 2011 04:45:19 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by core3.amsl.com (Postfix) with ESMTP id 0AF893A67B7 for ; Sat, 2 Apr 2011 04:45:19 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D65154400B3DA5B; Sat, 2 Apr 2011 13:46:54 +0200 Message-ID: <4D970CB4.6030607@telia.com> Date: Sat, 02 Apr 2011 13:47:00 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: [pkix] Device Certificates. Re: IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 11:45:20 -0000 On 2011-04-02 12:59, Peter Gutmann wrote: > Anders Rundgren writes: > >> And by using embedded device certificates you get full end-to-end security >> without requiring a major server upgrade which TLS-PSK or TlS-SRP presumes. > > And you get your device certificates by ...... ? If we assume that we are still talking about a potential new effort (?) it seems that companies like Cisco ought to be able deploying a device certificate during manufacturing. In fact, one of my day-job's customers have reportedly produced *hundreds of millions* of device certificates! For the IMO considerably less interesting use-case, creating a new enrollment system for dated operating systems and hardware, it should a zero problem creating a self-signed certificate during installation of the enrollment software. By doing that you can reduce the number of security options by at least a factor 2 which is a major boon for interoperability. > (More to the point, if you've already got device certs then you can just use > them to move CMS blobs around, and don't need either CMP or TLS). Or, even better, use them as a foundation for secure messaging which is way more powerful than CMS. Anders From pgut001@login01.cs.auckland.ac.nz Sat Apr 2 04:51:15 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD003A67BD for ; Sat, 2 Apr 2011 04:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fziNmRYFVPmU for ; Sat, 2 Apr 2011 04:51:14 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A0ACF3A67B7 for ; Sat, 2 Apr 2011 04:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1301745175; x=1333281175; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pkix@ietf.org|Subject:=20An=20interesting=20philos ophical=20question|Message-Id:=20|Date:=20Sun,=2003=20Apr=202011=200 0:52:52=20+1300; bh=82tmNN3qpyvS6jBx/RiS9muKnBW18Xaaqp4mSRBI8y0=; b=MxV4dFJ6pWlHE7sRRQEFf46akEZ9HE/95XBkKjIzfMRkiJXrWGo0CPMN ZJItXg9Jh/4deXXfCZxWVEsh5snGxYoC1oTmf02YVOFq3rKXLZ7ZpPONn EfSMr/JcfbIMzKhsDruHnmG/VRCL+fiZxRFes0QDnu7TcWRjdVBfPPZbm E=; X-IronPort-AV: E=Sophos;i="4.63,287,1299409200"; d="scan'208";a="54729512" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Apr 2011 00:52:52 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q5zNs-0000NF-Gj for pkix@ietf.org; Sun, 03 Apr 2011 00:52:52 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q5zNs-0000T8-4K for pkix@ietf.org; Sun, 03 Apr 2011 00:52:52 +1300 From: Peter Gutmann To: pkix@ietf.org Message-Id: Date: Sun, 03 Apr 2011 00:52:52 +1300 Subject: [pkix] An interesting philosophical question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 11:51:15 -0000 If you see an SSL server cert that contains an S/MIME Capabilities extension then, apart from the meta-statement made about the competence of whoever created it :-), what is one supposed to do with the cert? Peter. From pgut001@login01.cs.auckland.ac.nz Sat Apr 2 05:11:43 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FCE3A67DF for ; Sat, 2 Apr 2011 05:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7DVb5T9BWWu for ; Sat, 2 Apr 2011 05:11:42 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 128943A67D4 for ; Sat, 2 Apr 2011 05:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1301746404; x=1333282404; h=from:to:subject:cc:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pkix@ietf.org|Subject:=20Re:=20[pkix]=20fyi:=20Det ecting=20Certificate=20Authority=20compromises=20and=20we b=20browser=20collusion|Cc:=20mozilla-dev-security-policy @lists.mozilla.org|Message-Id:=20|Date:=20Sun,=2003=20Apr=202011=200 1:13:22=20+1300; bh=I/6CJILYyRltYb7lQTjt7VeU/zomHTwnJFf4QxlaEiU=; b=FsfY+nhaverupZfFqm5YL3Z//EjNoqBPFW50+06q1rpwbPCGLZiTJhAc 2RhJuNvmUv6NEcheSt6HNKfcTU2gQhTMMo3wjz0uQtNDa2EFItqX1/5Eo At/nLhvUhJe6Xcwk3hb8SAfwW47/qge7eau7O3I98OYZbLbLqwO781WX+ E=; X-IronPort-AV: E=Sophos;i="4.63,287,1299409200"; d="scan'208";a="54730373" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Apr 2011 01:13:22 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q5zhi-0000wb-HG; Sun, 03 Apr 2011 01:13:22 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q5zhi-0001Sn-9z; Sun, 03 Apr 2011 01:13:22 +1300 From: Peter Gutmann To: pkix@ietf.org Message-Id: Date: Sun, 03 Apr 2011 01:13:22 +1300 Cc: mozilla-dev-security-policy@lists.mozilla.org Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 12:11:43 -0000 [CC'd to the Mozilla security-policy list, maybe someone there can explain what's going on here]. "Ed Gerck, Ph.D." writes: >First, "Larry" does not know what's going on. This is the same Larry that >affirms "You are connected to xyz.com which is run by (unknown)" for a valid >cert for a known entity, which is clearly named in the O field and is >digitally signed in the cert. Try going to, for example, https://www.microsoft.com. "This site does not supply identity information / Your connection to this site is only partially encrypted". MSIE has no such problem (and yes, it does work for non-MS sites as well :-). I suspect Larry may have been hired away from the TSA's passenger-screening program... >I suspect that Larry is just a bouncer for non-EV certs. That could well be the case. He certainly seems to create the impression that EV cert = good, anything else = bad. Peter. From anders.rundgren@telia.com Sat Apr 2 05:35:18 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D083A67E6 for ; Sat, 2 Apr 2011 05:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L9TgtWaG5Ea for ; Sat, 2 Apr 2011 05:35:17 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id 2D1D53A67E5 for ; Sat, 2 Apr 2011 05:35:17 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA00EB81A6; Sat, 2 Apr 2011 14:36:48 +0200 Message-ID: <4D971867.3050901@telia.com> Date: Sat, 02 Apr 2011 14:36:55 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephen Kent References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> <4D96E7F5.7060904@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 12:35:19 -0000 On 2011-04-02 11:39, Stephen Kent wrote: > At 11:10 AM +0200 4/2/11, Anders Rundgren wrote: >> On 2011-04-01 10:36, Stephen Kent wrote: >>> At 8:53 AM +0200 4/1/11, Anders Rundgren wrote: >>>> Dear List, >>>> >>>> In a serious attempt keeping the discussion at a constructive >>>> level, let me begin by scratching the surface of the enrollment >>>> topic with a rather mundane requirement stated by banks: They >>>> more or less always deploy a PIN to an issued credential. >>> >>> what does the phrase "deploy a PIN to an issued credential" mean. >>> Do you mean a CA sends a PIN to a user, along with a cert issued >>> to that user, >>> in a sort of unilateral cert issuance model? >> >> Yes, that's one way banks and governments deal with PIN-codes. >> The "unilateral issuance model" as you appropriately called it, >> also typically only cares about the public key in a CSR. > > For this use case, CMP and CMC both have that capability. Would it be possible providing a reference? I can't find any PIN deployment support at least... Revocation passphrase is close but not the same. > Also, in the U.S. DoD PKI, the public key is NOT the only the cert request > value of interest. So, that's one example of a government-issued credential > that runs counter to your assertion. I have never claimed that my take on this topic is universal but for the web-based model, there is no point in providing anything certificate-related in a CSR beyond a public key. FWIW, my proposal (sorry no I-D, just an open specification and equally open working code), have zero support for DNs, key extensions, etc. >> > or, do you mean >>> requiring a user to send a PIN to a CA (a shared secret between the >>> CA and the user) as part of a user requesting a cert? >> >> No, I didn't mean anything related to the user authenticating to the CA. > > I had personal experience am with CAs that used a PIN sent to a user > as part of authenticating the user before allowing him to retrieve an > issued cert. So, that model is not unknown, even if is not what you > had in mind when you used the ambiguous phrase "deploy a PIN to an > issued credential." It is probably a fairly clear phrase for people who deal with enrollment issues on a daily basis. > >> ... >> >> IMO, multi-step enrollment systems should use "Secure Messaging" where >> you establish a TLS-like channel between the cryptographic container >> and the issuer. This is where the industry is going AFAICT. > > Are you suggesting using a "TLS-like" channel between a chip on a > smart card and an HSM at an issuer? Again, it's not clear from the > terms you are using. Secure messaging is the AFAIK established term in this context. The "quality" of the cryptographic containers may vary since this is a policy/cost issue. > If so, then you should be talking to some ISO > committee, because they deal with smart card standards. That's seems more to be a task for Max and PKIX in case smart cards is a part of "as many devices as possible". Is it? Personally, I don't want to build on technology and standards that were created in an entirely different time when hardware had 1/100 the power it has today, and on-line was equivalent to a 56kbit/s dial-up modem. >> A recent IETF standard that deals with PIN-codes during provisioning: >> http://datatracker.ietf.org/wg/keyprov > > KEYPROV (now concluded) dealt with symmetric keys. Also, BTW, your URL > does not point to any specific doc, but rather the full set of WG > docs. Presumably the doc you had in mind is other than RFC 6031, > since that one > uses CMS :-). I was thinking about the combination DSKPP/PSKC which has a specific XML-based mechanism for dealing with PIN-codes. Section 10.2 of http://www.rfc-editor.org/rfc/rfc6030.txt Anders From tgindin@us.ibm.com Sat Apr 2 07:33:29 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B67D3A682C for ; Sat, 2 Apr 2011 07:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3bRmIL61aAT for ; Sat, 2 Apr 2011 07:33:28 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 285B83A682A for ; Sat, 2 Apr 2011 07:33:27 -0700 (PDT) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p32EAlt3019719 for ; Sat, 2 Apr 2011 10:10:47 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 433D638C8038 for ; Sat, 2 Apr 2011 10:34:55 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p32EZ2Tq273648 for ; Sat, 2 Apr 2011 10:35:02 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p32EZ2QN013797 for ; Sat, 2 Apr 2011 11:35:02 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p32EZ1Tr013789; Sat, 2 Apr 2011 11:35:01 -0300 In-Reply-To: <4D95766D.7080303@telia.com> References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> To: Anders Rundgren MIME-Version: 1.0 X-KeepSent: 7EB78EA1:6DF415F8-85257865:005BEC8F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Sat, 2 Apr 2011 10:35:01 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 04/02/2011 10:35:01, Serialize complete at 04/02/2011 10:35:01 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 14:33:29 -0000 I don't think there's supposed to be PIN support in the protocol, as distinct from the data structures. In PKCS#10, for example, the equivalent of extensions go into the attributes. There is a "challenge password" in PKCS#9 (RFC 2985), but no "PIN" or anything like that. Are you proposing that an attribute called either "initial password" or "enrollment password" (depending on whether it's used with the server after enrollment) be added? If so, should that attribute be encrypted or should it be UTF-8? If it's UTF-8, I think that a warning to the following effect would be appropriate - "PKCS#10 structures containing challenge passwords or initial passwords should only be transmitted over encrypted links". I'm not sure why there's no warning like that now, at least in 2985's Security Considerations (right next to the one about not putting challenge password unencrypted into a directory). If it's encrypted, should it use EnvelopedData from CMS which CMP and CRMF use in some similar cases? Tom Gindin From: Anders Rundgren To: "pkix@ietf.org" Date: 04/01/2011 02:55 AM Subject: [pkix] PIN support in PKIX enrollment protocols Sent by: pkix-bounces@ietf.org Dear List, In a serious attempt keeping the discussion at a constructive level, let me begin by scratching the surface of the enrollment topic with a rather mundane requirement stated by banks: They more or less always deploy a PIN to an issued credential. Maybe the banks and I have difficulties reading RFCs, but none of us seems to have found any support for PINs in PKIX-related protocols. Due to this fact (right or wrong), banks in EU and Asia yearly spend hundreds of millions of dollars on maintaining entirely proprietary on-line credential enrollment systems. There's little point going further down in stack until we have cleared this hopefully fairly trivial issue. Anders _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Sat Apr 2 07:46:00 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D333A6828 for ; Sat, 2 Apr 2011 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kSSiYSgync3 for ; Sat, 2 Apr 2011 07:45:59 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by core3.amsl.com (Postfix) with ESMTP id 0E6B53A6830 for ; Sat, 2 Apr 2011 07:45:59 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A100EC3123; Sat, 2 Apr 2011 16:47:34 +0200 Message-ID: <4D97370B.3000403@telia.com> Date: Sat, 02 Apr 2011 16:47:39 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Tom Gindin References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 14:46:00 -0000 I didn't really ask for "solution" but whether the deployment of a a PIN to lets say a smart card-based credential is a part of any existing PKIX enrollment protocol. According to Steve it is already specified in CMC and CMP so I guess you and I are at a loss reading RFCs :-) Anders On 2011-04-02 16:35, Tom Gindin wrote: > I don't think there's supposed to be PIN support in the protocol, > as distinct from the data structures. In PKCS#10, for example, the > equivalent of extensions go into the attributes. There is a "challenge > password" in PKCS#9 (RFC 2985), but no "PIN" or anything like that. Are > you proposing that an attribute called either "initial password" or > "enrollment password" (depending on whether it's used with the server > after enrollment) be added? If so, should that attribute be encrypted or > should it be UTF-8? If it's UTF-8, I think that a warning to the > following effect would be appropriate - "PKCS#10 structures containing > challenge passwords or initial passwords should only be transmitted over > encrypted links". I'm not sure why there's no warning like that now, at > least in 2985's Security Considerations (right next to the one about not > putting challenge password unencrypted into a directory). If it's > encrypted, should it use EnvelopedData from CMS which CMP and CRMF use in > some similar cases? > > Tom Gindin > > > > > > From: > Anders Rundgren > To: > "pkix@ietf.org" > Date: > 04/01/2011 02:55 AM > Subject: > [pkix] PIN support in PKIX enrollment protocols > Sent by: > pkix-bounces@ietf.org > > > > Dear List, > > In a serious attempt keeping the discussion at a constructive > level, let me begin by scratching the surface of the enrollment > topic with a rather mundane requirement stated by banks: They > more or less always deploy a PIN to an issued credential. > > Maybe the banks and I have difficulties reading RFCs, but none > of us seems to have found any support for PINs in PKIX-related > protocols. Due to this fact (right or wrong), banks in EU and > Asia yearly spend hundreds of millions of dollars on maintaining > entirely proprietary on-line credential enrollment systems. > > There's little point going further down in stack until we have > cleared this hopefully fairly trivial issue. > > Anders > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > From tgindin@us.ibm.com Sat Apr 2 08:07:23 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF503A683F for ; Sat, 2 Apr 2011 08:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PHzxp4UIPqb for ; Sat, 2 Apr 2011 08:07:22 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 019DC3A6837 for ; Sat, 2 Apr 2011 08:07:21 -0700 (PDT) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p32EnwhT011102 for ; Sat, 2 Apr 2011 10:49:58 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id DCDEF6E8036 for ; Sat, 2 Apr 2011 11:08:54 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p32F8sXG354598 for ; Sat, 2 Apr 2011 11:08:54 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p32F8sAK000754 for ; Sat, 2 Apr 2011 11:08:54 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p32F8slT000751; Sat, 2 Apr 2011 11:08:54 -0400 In-Reply-To: <1B12070B-083A-48F3-9041-C37FEB67695F@carillon.ca> References: <1B12070B-083A-48F3-9041-C37FEB67695F@carillon.ca> To: Patrick Patterson MIME-Version: 1.0 X-KeepSent: D6AFBF48:F204870F-85257864:006E9AD4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Sat, 2 Apr 2011 11:08:54 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 04/02/2011 11:08:53, Serialize complete at 04/02/2011 11:08:53 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER Cc: pkix Subject: Re: [pkix] New draft for consideration as a work item. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 15:07:23 -0000 Patrick: Is it called "attributeSigning" or "assertionSigning"? The title says one, and section 3 says the other. BTW, it looks reasonable to me. Tom Gindin From: Patrick Patterson To: pkix Date: 03/31/2011 02:52 PM Subject: [pkix] New draft for consideration as a work item. Sent by: pkix-bounces@ietf.org Hello all: A new version of I-D, draft-patterson-pkix-attribute-signing-eku-00.txt has been successfully submitted by Patrick Patterson and posted to the IETF repository. Filename: draft-patterson-pkix-attribute-signing-eku Revision: 00 Title: attributeSigning extendedKeyUsage value Creation_date: 2011-03-28 WG ID: Independent Submission Number_of_pages: 8 Abstract: This document specifies a value for the extendedKeyUsage X.509 extension that may be used to create a certificate that would be used to sign attribute assertions. This allows the differentiation of certificates used to identify a particular server (which would have a serverAuth EKU), from the certificate used by that server to sign attribute assertions, and would easily allow a policy to be developed for issuance of such a certificate to an identity provider. I would ask that the above be considered as a new work item for this group. Thank you. --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Sat Apr 2 11:04:26 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C448028C13D for ; Sat, 2 Apr 2011 11:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu1ZdEEAFG8F for ; Sat, 2 Apr 2011 11:04:25 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id 7560128C103 for ; Sat, 2 Apr 2011 11:04:25 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA00EC7F22 for pkix@ietf.org; Sat, 2 Apr 2011 20:06:05 +0200 Message-ID: <4D976594.1000901@telia.com> Date: Sat, 02 Apr 2011 20:06:12 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 18:04:26 -0000 Since PIN deployment to issued credentials to my surprise apparently already is fully featured in existing PKIX protocols (although nobody has bothered with providing a reference), I continue with the next important feature: Secure Messaging. For those who are not yet up to speed on this topic, Secure Messaging was pioneered by ISO in 7816, and later enhanced by Global Platform. http://www.opensc-project.org/opensc/wiki/SecureMessaging The principle is quite simple: The issuer and the cryptographic container in some way establish a shared session secret which is used in an arbitrary number of subsequent steps to MAC and/or encrypt data in both directions. The power of this concept are plentiful: - You know that the generated keys actually reside in the crypto module - You can through use of a session perform a multi-step enrollment as a transaction. It either succeeds or leave the crypto module intact. - It becomes very simple to exchange secret data like PIN-codes or perform backup of private keys. So, is secure messaging also supported by CMP or CMC? Anders From mstjohns@comcast.net Sat Apr 2 19:20:05 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109143A68FF for ; Sat, 2 Apr 2011 19:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABdid6TNNP3W for ; Sat, 2 Apr 2011 19:20:03 -0700 (PDT) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id CFA003A68FE for ; Sat, 2 Apr 2011 19:20:02 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta11.emeryville.ca.mail.comcast.net with comcast id SqLw1g0051u4NiLABqMk61; Sun, 03 Apr 2011 02:21:44 +0000 Received: from Mike-PC3.comcast.net ([68.83.217.57]) by omta21.emeryville.ca.mail.comcast.net with comcast id SqMg1g00P1EtFYL8hqMhBq; Sun, 03 Apr 2011 02:21:44 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 Apr 2011 22:21:40 -0400 To: Peter Gutmann ,pkix@ietf.org From: Michael StJohns In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20110403022002.CFA003A68FE@core3.amsl.com> Subject: Re: [pkix] An interesting philosophical question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 02:20:05 -0000 If the server cert has all the correct elements for SSL in addition to the S/Mime extension, the obvious answer is the client should ignore the S/Mime extension. I can actually think of a reason to do this: - server is sending secure email notifications as a reaction to something a client is doing. It's somewhat easier to manage a single credential, but maybe not as secure. Later, Mike At 07:52 AM 4/2/2011, Peter Gutmann wrote: >If you see an SSL server cert that contains an S/MIME Capabilities extension >then, apart from the meta-statement made about the competence of whoever >created it :-), what is one supposed to do with the cert? > >Peter. > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From kyanha@kyanha.net Mon Apr 4 00:45:17 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D237F3A6970 for ; Mon, 4 Apr 2011 00:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-v0xJV92sKy for ; Mon, 4 Apr 2011 00:45:11 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D865A3A6920 for ; Mon, 4 Apr 2011 00:45:10 -0700 (PDT) Received: by gwb20 with SMTP id 20so2437358gwb.31 for ; Mon, 04 Apr 2011 00:46:52 -0700 (PDT) Received: by 10.150.214.17 with SMTP id m17mr6491418ybg.187.1301903212803; Mon, 04 Apr 2011 00:46:52 -0700 (PDT) Received: from [127.0.0.1] (c-71-202-74-146.hsd1.ca.comcast.net [71.202.74.146]) by mx.google.com with ESMTPS id q29sm2061790yba.17.2011.04.04.00.46.51 (version=SSLv3 cipher=OTHER); Mon, 04 Apr 2011 00:46:51 -0700 (PDT) From: "Kyle Hamilton" To: "Peter Gutmann" Date: Mon, 4 Apr 2011 00:46:51 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.6.2eqgm33k31ab7y45jjl342 Cc: pkix@ietf.org Subject: Re: [pkix] An interesting philosophical question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 07:45:17 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.6.2eqgm33k31ab7y45jjl342 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit I think that one handles it as an SSL server certificate which also happens to contain an expression of whatever S/MIME capabilities the owner of the server wishes to assert for the rfc822name listed as the contact. If certificates bind authoritative information, then all information within certificates must be authoritative and authoritatively bound to itself. StartCom issues such that SSL server certificates also include the SSL client EKU. You could as easily ask "If you see an SSL server cert which also contains an SSL client EKU extension [...]?". -Kyle H On Sat, Apr 2, 2011 at 4:52 AM, Peter Gutmann wrote: > If you see an SSL server cert that contains an S/MIME Capabilities extension > then, apart from the meta-statement made about the competence of whoever > created it :-), what is one supposed to do with the cert? > > Peter. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --gmsm1.6.2eqgm33k31ab7y45jjl342 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwNDA0MDc0NjUxWjAjBgkqhkiG9w0BCQQxFgQUfyxEEy9iZmCsoXGgqrvGnoms hIEwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAM/Z9qNFKtJm+j8QmXoWeGC6+JbR0DRpkhJlxEeVkAZVyLosRZvgIhgszuuF3eDC+METe5zJ fvmmiH764a09aXHkG7Hge0Ai1/29XSERMfWrVOayviLsIFRmFdYRV5+MsOCA7j+Ov7UBeud8C3EQ lWjdiS/9jqPF8uHm3R4USJoy4ylxO8fqQr5x+NolBOpg0FEKECStlJMhm0s8q1Qetkm7/G8frBqG 98TMCvyx/bem5ufpSBINfWJewTKcMT/NO3nyKGjBVINxv0Or3LjqsSSOWoQxz7C4kuoqbju//mxI x4yTnC68C/LR8HwBUzD+ecQMBdnanFUb/zX0jDnw3LMAAAAAAAA= --gmsm1.6.2eqgm33k31ab7y45jjl342-- From tmiller@mitre.org Mon Apr 4 05:24:06 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ACFA3A69EA for ; Mon, 4 Apr 2011 05:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[AWL=1.581, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsSoHCFeKWAc for ; Mon, 4 Apr 2011 05:24:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 6E5F83A69E6 for ; Mon, 4 Apr 2011 05:24:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9029321B1429; Mon, 4 Apr 2011 08:25:47 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 88FF821B1427; Mon, 4 Apr 2011 08:25:47 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 4 Apr 2011 08:25:47 -0400 From: "Miller, Timothy J." To: Anders Rundgren Date: Mon, 4 Apr 2011 08:25:44 -0400 Thread-Topic: [pkix] PIN support in PKIX enrollment protocols Thread-Index: Acvyw2z3ubqbIOpIQdy6xEFdVlm+IA== Message-ID: <9EA99870-A784-4AA5-9B40-F8325C2BB7F5@mitre.org> References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> <4D96E7F5.7060904@telia.com> <4D971867.3050901@telia.com> In-Reply-To: <4D971867.3050901@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1--657285719"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 12:24:06 -0000 --Apple-Mail-1--657285719 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 2, 2011, at 7:36 AM, Anders Rundgren wrote: >> If so, then you should be talking to some ISO=20 >> committee, because they deal with smart card standards. >=20 > That's seems more to be a task for Max and PKIX in case smart > cards is a part of "as many devices as possible". Is it? >=20 > Personally, I don't want to build on technology and standards > that were created in an entirely different time when hardware > had 1/100 the power it has today, and on-line was equivalent > to a 56kbit/s dial-up modem. I think Stephen's point was that secure channels between cryptomodules = is essentially a solved problem *under the condition* that at least one = module can be securely provisioned by or register a key with the other = (whether that key be symmetric or asymmetric). In the smartcard arena, = the token manager does this either at manufacture or at some other time = prior to issuance; once done, all subsequent interactions between = parties inherits the assurance of the union between the initial = provision/registry assurance and the inherent assurance of the = smartcard. You can layer as many levels of indirection around this as you want, but = I think this is a fundamental interaction that can't be escaped. I've looked at your work before, and correct me if I'm wrong, but I = don't think your approach does anything to lift this constraint. = Enabling third parties to manage this provisioning/registration = operation and attest it to others is fine and dandy as far as it goes, = but isn't the end-all, be-all of cryptomodule management. -- Tim --Apple-Mail-1--657285719 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MDQxMjI1NDVaMCMGCSqGSIb3DQEJBDEWBBTG7LkcPWGN6DHJFQoz 9foQfp9glzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgJkYnLXQ1FR8HaYOrC+BVxofIMqDYXS5ZTu2 k1FSr+qereOmZRL4ioSDOK6STtHmJAJ8ULLalubKmS6YChG/WNOaYBFuve792CkTMF40btqYfKHz +dNG6k7Uk4/tU0z3QjwXffGpebZJK1KdlEm61JjX1o/4HQXv22e7B2isP0j9AAAAAAAA --Apple-Mail-1--657285719-- From tmiller@mitre.org Mon Apr 4 05:28:12 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701ED28C11A for ; Mon, 4 Apr 2011 05:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=1.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGLPrxRWl92H for ; Mon, 4 Apr 2011 05:28:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 3B64328C11D for ; Mon, 4 Apr 2011 05:28:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 82A3B21B08F2; Mon, 4 Apr 2011 08:29:53 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7776921B13FF; Mon, 4 Apr 2011 08:29:53 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 4 Apr 2011 08:29:53 -0400 From: "Miller, Timothy J." To: Peter Gutmann Date: Mon, 4 Apr 2011 08:29:50 -0400 Thread-Topic: [pkix] An interesting philosophical question Thread-Index: Acvyw/9ENAVzmpHGS6CaCXPTlVhMQA== Message-ID: <3EE9F82F-0427-43A8-A9D5-26783D1FFA6E@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-4--657039829"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] An interesting philosophical question X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 12:28:12 -0000 --Apple-Mail-4--657039829 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 2, 2011, at 6:52 AM, Peter Gutmann wrote: > If you see an SSL server cert that contains an S/MIME Capabilities = extension > then, apart from the meta-statement made about the competence of = whoever > created it :-), what is one supposed to do with the cert? What about a web server that sends automated mailings (e.g., Sharepoint = alerts)? -- T --Apple-Mail-4--657039829 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MDQxMjI5NTFaMCMGCSqGSIb3DQEJBDEWBBTX/+vl1buZw0c0uyLx TrAqDkoJSTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgDrYHJeOisxjTvud6iOinmBPZ1HVXYWoUdHO pa4bI5tf4uiNu15zKQq4ecuJRROy7le0ykF5yrmEMGcHZEtPC1ka8fH8ENIzhZbuqGAJpa4YqIcN U/3eYh5nF8k3c/QpQDn/Hhk5tuiFhV21YC1QE7P0YyV0eb5Z20K1qLHdQM+rAAAAAAAA --Apple-Mail-4--657039829-- From pritikin@cisco.com Mon Apr 4 09:05:32 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EB763A683A for ; Mon, 4 Apr 2011 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.401 X-Spam-Level: X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ovrFJncsCz7 for ; Mon, 4 Apr 2011 09:05:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 256273A6830 for ; Mon, 4 Apr 2011 09:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2341; q=dns/txt; s=iport; t=1301933227; x=1303142827; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=+cpWpSFXPpUcWECgiKDPg5w6d6zwiso9eji4kII1xLs=; b=Fo5tgkzMsXno2hOAcDlgec3qz905/q8KXFNHsDx39DBVNXSXLvHn5lwj IJx/vfIEZQQGNn1YKRQIvtPKYRxcxnbGGBw02dTnxD3oB263KxFJ7BS+1 KeCoerp521DPqQd9FzWZm6USN/1ZaHaNYybntiwmFEvnLaT2eVpMZiPss Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJHrmU2rRDoJ/2dsb2JhbAClYXeIeZs0m2CFawSFR4dcg1s X-IronPort-AV: E=Sophos;i="4.63,298,1299456000"; d="scan'208";a="423501974" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2011 16:07:06 +0000 Received: from [192.168.0.106] ([10.21.118.88]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p34G76aT016130; Mon, 4 Apr 2011 16:07:06 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: <4D970C2D.2090007@ieca.com> Date: Mon, 4 Apr 2011 10:07:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D95E9AD.90108@primekey.se> <4D970C2D.2090007@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:05:32 -0000 On Apr 2, 2011, at 5:44 AM, Sean Turner wrote: > On 4/2/11 12:50 AM, max pritikin wrote: >>=20 >> I agree with these comments. >>=20 >> A sufficiently restricted profile of CMP would be an improvement = regarding interoperability but would still be significantly more complex = than simply depending on TLS as a secure transport. >=20 > The same could be said of CMC. Oddly I actually meant to type CMC. :) Yes, we are in agreement.=20 - max >=20 > spt >=20 >> - max >>=20 >> On Apr 1, 2011, at 9:05 AM, Tomas Gustavsson wrote: >>=20 >>> On 04/01/2011 12:09 PM, Peter Gutmann wrote: >>>> Tomas Gustavsson writes: >>>>=20 >>>>> Because the packaging around CMP is complex with lots and lots of = options. >>>>> Creating the PKCS#10 or CRMF are the easy parts, the tricky part = with CMP >>>>> comes after. Just passing them through TLS is trivial. >>>>=20 >>>> You're being polite :-). A more succint way of putting it would be = "Almost >>>> anything is less painful than trying to work with CMP". This is = (presumably) >>>> one reason why SCEP, which is rather a kludge, remains so popular. >>>=20 >>> Succinct is a new work in my dictionary, thanks :-) >>>=20 >>> Agree on SCEP, I though it horrid when I first implemented it, but = now >>> it kind of does the job, easier to grasp than CMP. >>>=20 >>> I'd say CMP almost works with the 1 or 2 options that are actually = in >>> the wild. Stripping the standard leaving only the few options = actually >>> used would make it almost usable. The ones I've seen are enrollment, >>> revocation (and possibly keyrecovery) using PasswordBaseHMAC >>> authentication and enrollment (includes renewal) using digital = signature >>> authentication. >>> Always exciting when you encounter a new CMP client and have to make >>> some small adjustments :-) >>>=20 >>> Cheers, >>> Tomas >>> _______________________________________________ >>> 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 >>=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Mon Apr 4 09:08:30 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F063C3A69DA for ; Mon, 4 Apr 2011 09:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyrxV75TfClH for ; Mon, 4 Apr 2011 09:08:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 797303A69CA for ; Mon, 4 Apr 2011 09:08:30 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49165) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6mM0-000LUd-RL; Mon, 04 Apr 2011 12:10:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 4 Apr 2011 10:45:26 -0400 To: Peter Gutmann From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:08:31 -0000 At 11:59 PM +1300 4/2/11, Peter Gutmann wrote: >Anders Rundgren writes: > >>And by using embedded device certificates you get full end-to-end security >>without requiring a major server upgrade which TLS-PSK or TlS-SRP presumes. > >And you get your device certificates by ...... ? in fairness to Anders, note that Cisco has shipped VoIP phones with embedded certs for several years, so they are capable of doing that for products. WiMax products ship with embedded device certs too. Steve From kent@bbn.com Mon Apr 4 09:08:32 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C843A69FE for ; Mon, 4 Apr 2011 09:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqaaa68ogju4 for ; Mon, 4 Apr 2011 09:08:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B66943A69FC for ; Mon, 4 Apr 2011 09:08:31 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49165) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6mM0-000LUd-6h; Mon, 04 Apr 2011 12:10:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 4 Apr 2011 10:43:54 -0400 To: Peter Gutmann From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:08:32 -0000 At 10:33 PM +1300 4/2/11, Peter Gutmann wrote: >Stephen Kent writes: > >>As I noted during the PKIX meeting, one concern about relying on TLS is that >>most TLS implementations are pretty poor re PKI details. Thus using TLS as a >>building block for cert issuance will have to be very carefully vetted. > >If you use TLS-PSK or -SRP, you're getting the same security as CMP. With >both protocols you can then bootstrap further requests with the certs you've >got (or continue with the PSK if you prefer). > >Peter. I don't what Max had in mind; max what did you envision? Did you anticipate using pre-shared keys or passwords? Also, -SRP is informational, which would not be an appropriate downref for a standards track cert management protocol. Finally, -SRP seems to focus on one-way (client to server) auth, but cert enrollment requires 2-way auth. Steve From kent@bbn.com Mon Apr 4 09:08:47 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFEC28C12D for ; Mon, 4 Apr 2011 09:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReV9pLyvC3X1 for ; Mon, 4 Apr 2011 09:08:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 717CC28C12B for ; Mon, 4 Apr 2011 09:08:40 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49165) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6mMA-000LUd-QJ; Mon, 04 Apr 2011 12:10:23 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 4 Apr 2011 11:23:16 -0400 To: Peter Gutmann From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, mozilla-dev-security-policy@lists.mozilla.org Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:08:47 -0000 At 1:13 AM +1300 4/3/11, Peter Gutmann wrote: >[CC'd to the Mozilla security-policy list, maybe someone there can explain > what's going on here]. > >"Ed Gerck, Ph.D." writes: > >>First, "Larry" does not know what's going on. This is the same Larry that >>affirms "You are connected to xyz.com which is run by (unknown)" for a valid >>cert for a known entity, which is clearly named in the O field and is >>digitally signed in the cert. > >Try going to, for example, https://www.microsoft.com. "This site does not >supply identity information / Your connection to this site is only partially >encrypted". MSIE has no such problem (and yes, it does work for non-MS sites >as well :-). I suspect Larry may have been hired away from the TSA's >passenger-screening program... I did not get a message of this sort when I connected, but then I did terminate the home page downloading when it ran on and on and ... Steve From pritikin@cisco.com Mon Apr 4 09:09:19 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4055D3A682E for ; Mon, 4 Apr 2011 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.426 X-Spam-Level: X-Spam-Status: No, score=-10.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIyP16dyAn7d for ; Mon, 4 Apr 2011 09:09:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 27D963A683A for ; Mon, 4 Apr 2011 09:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1664; q=dns/txt; s=iport; t=1301933455; x=1303143055; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7YW/RiFkaZyPdCsp5g70gO9+dfgoySeO+pCUUhBGJnU=; b=DXLaB1VPavzZhhBxdyCFfJXKaY4HourX+rHvd7MnBYses119s9C4X183 ilCfKGkuPhb1aBiMLDQtF4bGSrnsJt8p07oyCwAWzrbZClRzZ2wFRGVT0 GV+KaSDZrByztgqpXmxVdxLUGoDfsmNcv8Wyf6rTZSHWs3VxdG9/klPkM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALfsmU2rRDoI/2dsb2JhbAClYXeIeZslm2GCfoJtBIVHh1yDWw X-IronPort-AV: E=Sophos;i="4.63,298,1299456000"; d="scan'208";a="423505066" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2011 16:10:54 +0000 Received: from [192.168.0.106] ([10.21.118.88]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34GAr0h007919; Mon, 4 Apr 2011 16:10:54 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: <4D970CB4.6030607@telia.com> Date: Mon, 4 Apr 2011 10:10:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9C8E953C-B614-4135-ADC2-D4A10875FCC3@cisco.com> References: <4D970CB4.6030607@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org Subject: Re: [pkix] Device Certificates. Re: IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:09:19 -0000 On Apr 2, 2011, at 5:47 AM, Anders Rundgren wrote: > On 2011-04-02 12:59, Peter Gutmann wrote: >> Anders Rundgren writes: >>=20 >>> And by using embedded device certificates you get full end-to-end = security >>> without requiring a major server upgrade which TLS-PSK or TlS-SRP = presumes. >>=20 >> And you get your device certificates by ...... ? >=20 > If we assume that we are still talking about a potential new > effort (?) it seems that companies like Cisco ought to be able > deploying a device certificate during manufacturing. > In fact, one of my day-job's customers have reportedly produced > *hundreds of millions* of device certificates! I was the editor of IEEE 802.1AR Device Identity. I agree that = manufacturing installed certificates have an important role to play. - max > For the IMO considerably less interesting use-case, creating a > new enrollment system for dated operating systems and hardware, > it should a zero problem creating a self-signed certificate > during installation of the enrollment software. >=20 > By doing that you can reduce the number of security options by > at least a factor 2 which is a major boon for interoperability. >=20 >> (More to the point, if you've already got device certs then you can = just use >> them to move CMS blobs around, and don't need either CMP or TLS). >=20 > Or, even better, use them as a foundation for secure messaging > which is way more powerful than CMS. >=20 > Anders >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pritikin@cisco.com Mon Apr 4 09:19:57 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73D228C104 for ; Mon, 4 Apr 2011 09:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKHe11J7U9+5 for ; Mon, 4 Apr 2011 09:19:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8A4263A69C3 for ; Mon, 4 Apr 2011 09:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2061; q=dns/txt; s=iport; t=1301934091; x=1303143691; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PCVFJ4EOIUPeIH8gzNy1zTlbN4TM8CK43VjsGliK3Ks=; b=S44WRICZJktkwhfXAhOEWmHJxkgP2QcL9SA+j1wAxBenS4bPT/Mmx1Xo 45mgPOG6AWvRl//eO+9WARuu2zmyPtGoELGsHmU9MRjt62PmRNvs3Uu1/ rlvk3Lu+BSfZ1xpgMIAPC9XWlRajYuX9ONlcUKSar8ohZu5fNkVjVAoRE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFvvmU2rRDoI/2dsb2JhbAClYneIeZsbm2GDHYJOBIVHh1yDWw X-IronPort-AV: E=Sophos;i="4.63,298,1299456000"; d="scan'208";a="675408727" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2011 16:21:31 +0000 Received: from [192.168.0.106] (sjc-vpn5-1037.cisco.com [10.21.92.13]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34GLUbf020217; Mon, 4 Apr 2011 16:21:30 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: Date: Mon, 4 Apr 2011 10:21:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:19:57 -0000 On Apr 4, 2011, at 8:43 AM, Stephen Kent wrote: > At 10:33 PM +1300 4/2/11, Peter Gutmann wrote: >> Stephen Kent writes: >>=20 >>> As I noted during the PKIX meeting, one concern about relying on TLS = is that >>> most TLS implementations are pretty poor re PKI details. Thus using = TLS as a >>> building block for cert issuance will have to be very carefully = vetted. >>=20 >> If you use TLS-PSK or -SRP, you're getting the same security as CMP. = With >> both protocols you can then bootstrap further requests with the certs = you've >> got (or continue with the PSK if you prefer). >>=20 >> Peter. >=20 > I don't what Max had in mind; max what did you envision? Did you = anticipate using pre-shared keys or passwords? Also, -SRP is = informational, which would > not be an appropriate downref for a standards track cert management = protocol. >=20 > Finally, -SRP seems to focus on one-way (client to server) auth, but > cert enrollment requires 2-way auth. I brought up -SRP to help start that aspect of the conversation. I see = the following methods as being interesting: - a username/password used for client authentication (and subsequent = authorization) - an existing certificate (manufacturing installed or otherwise) used = for client authentication (and subsequent authorization) - a PIN w/o username use for ... - an existing certificate plus a username/password or PIN used for ... My hope & expectation is that these forms of client authentication are = not limited to PKIX certificate enrollment and that many of the = interesting protocol work can be, or has already been done, at the = TLS/HTTPS layers. Where it has not been done I'd propose we work with = the correct wg to get a general purpose ciphersuite/solution in place. Ideally it should not be necessary to include a PKIX specific element = for these issues. If they are realistic authentication method then I = imagine they are necessary for non-PKI centric solutions as well.=20 - max >=20 > Steve From pornin@bolet.org Mon Apr 4 09:31:08 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5961D28C141 for ; Mon, 4 Apr 2011 09:31:08 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA1-ND7vTEte for ; Mon, 4 Apr 2011 09:31:07 -0700 (PDT) Received: from arges.bolet.org (arges.bolet.org [88.191.65.205]) by core3.amsl.com (Postfix) with ESMTP id 5E4913A6843 for ; Mon, 4 Apr 2011 09:31:07 -0700 (PDT) Received: from [10.0.1.101] (modemcable051.204-200-24.mc.videotron.ca [24.200.204.51]) by arges.bolet.org (Postfix) with ESMTPSA id BBC0668C0AA; Mon, 4 Apr 2011 18:36:14 +0200 (CEST) From: Thomas Pornin To: Stephen Kent In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 04 Apr 2011 12:32:42 -0400 Message-ID: <1301934762.2382.8.camel@nostromo> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:31:08 -0000 On Mon, 2011-04-04 at 10:43 -0400, Stephen Kent wrote: > Finally, -SRP seems to focus on one-way (client to server) auth No, SRP is two-ways: the client and the server are mutually authenticated with regards to the shared secret (i.e. the password). SRP is a PAKE (Password Authenticated key Exchange) which adds protection against offline dictionary attacks: an attacker trying to guess the shared secret must interact with either the client or the server for each guess; he never learns enough to try potential passwords "at home". That's why the shared secret can be of relatively low entropy (e.g. something which fits in the brain of a human being, colloquially known as a "password"). Where SRP is asymmetric is in secret data storage: what the server stores is not the shared secret, but some data derived from the shared secret. This is additional security: an attacker who has read access to the complete server memory does not learn the shared secret (he does learn enough to be able to masquerade as the server, but not as the client; also, he learns enough to make an offline dictionary attack on the shared secret). --Thomas Pornin From kent@bbn.com Mon Apr 4 10:42:01 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95C623A698E for ; Mon, 4 Apr 2011 10:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2s5nWPWGxd3 for ; Mon, 4 Apr 2011 10:42:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5D50B3A6855 for ; Mon, 4 Apr 2011 10:42:00 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49155) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6noU-000MxD-AN; Mon, 04 Apr 2011 13:43:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D971867.3050901@telia.com> References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> <4D96E7F5.7060904@telia.com> <4D971867.3050901@telia.com> Date: Mon, 4 Apr 2011 13:31:52 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:42:01 -0000 At 2:36 PM +0200 4/2/11, Anders Rundgren wrote: >... > > >> For this use case, CMP and CMC both have that capability. > >Would it be possible providing a reference? I can't find any >PIN deployment support at least... Revocation passphrase is >close but not the same. Neither CMP nor CMC refer to PINs per say, as they are just examples of a shared secret between an issuer and a subject. But both protocols include provision for transport of such data. Just search for "passwords" in the docs. in CMC the relevant text is in Section 6.2 (6.2. Identification and Identity Proof Controls). In CMP, Section 5.1.3.1. (Shared Secret Information) is one area where this topic is discussed. Certainly you're not suggesting that the word "PIN" needs to be used here, right? >... >I have never claimed that my take on this topic is universal but >for the web-based model, there is no point in providing anything >certificate-related in a CSR beyond a public key. FWIW, my >proposal (sorry no I-D, just an open specification and equally >open working code), have zero support for DNs, key extensions, etc. thanks for the clarification of your position. as for the "no I-D just ..." that's fine, but not really relevant to PKIX. For any SDO, if one chooses to not submit a doc to that SDO, one ought not expect to have an impact on that SDO. >... So, that model is not unknown, even if is not what you > > had in mind when you used the ambiguous phrase "deploy a PIN to an >> issued credential." > >It is probably a fairly clear phrase for people who deal with >enrollment issues on a daily basis. PKIX members deal with general PKI issues, and that larger context, the phrase was vague. Again one needs to adopt the terminology of the context in which one wants to be heard, ... > >... > >Secure messaging is the AFAIK established term in this context. >The "quality" of the cryptographic containers may vary since >this is a policy/cost issue. "Secure messaging" is a broad term in the security community. In the IETF it nominally refers to S/MIME. If this is ISO (smart card) terminology, then you ought not expect it to be recognized in PKIX. > > If so, then you should be talking to some ISO >> committee, because they deal with smart card standards. > >That's seems more to be a task for Max and PKIX in case smart >cards is a part of "as many devices as possible". Is it? The phrase "as many devices as possible" is not mine :-). If operating on a smart card does not impose undue constraints on protocols, then I'm comfortable with including them. But, we have a broad constituency for PKI, and it would not be appropriate to skew solutions to one particular technology. >Personally, I don't want to build on technology and standards >that were created in an entirely different time when hardware >had 1/100 the power it has today, and on-line was equivalent >to a 56kbit/s dial-up modem. If this is an obtuse way of saying that you don't want to work in the PKIX/IETF context, please, just go away. > > A recent IETF standard that deals with PIN-codes during provisioning: > >> http://datatracker.ietf.org/wg/keyprov >> >> KEYPROV (now concluded) dealt with symmetric keys. Also, BTW, your URL >> does not point to any specific doc, but rather the full set of WG >> docs. Presumably the doc you had in mind is other than RFC 6031, >> since that one >> uses CMS :-). > >I was thinking about the combination DSKPP/PSKC which has a >specific XML-based mechanism for dealing with PIN-codes. >Section 10.2 of http://www.rfc-editor.org/rfc/rfc6030.txt thanks for identifying specific doc from that WG. I see the 6.5 pages of XML schema in this RFC, of which about 8-10 lines make reference to a PIN. So what? Certainly you're not suggesting that we adopt XML for this protocol just because there is a tiny amount of potentially relevant syntax this standard, right? Steve From kent@bbn.com Mon Apr 4 10:42:09 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD093A6A0E for ; Mon, 4 Apr 2011 10:42:09 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jo0vfdy+vVW for ; Mon, 4 Apr 2011 10:42:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 22B233A6A0D for ; Mon, 4 Apr 2011 10:42:08 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49155) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6noc-000MxD-Ha; Mon, 04 Apr 2011 13:43:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D976594.1000901@telia.com> References: <4D976594.1000901@telia.com> Date: Mon, 4 Apr 2011 13:39:24 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:42:09 -0000 At 8:06 PM +0200 4/2/11, Anders Rundgren wrote: >Since PIN deployment to issued credentials to my surprise apparently >already is fully featured in existing PKIX protocols (although nobody has >bothered with providing a reference), I continue with the next important >feature: Secure Messaging. > >For those who are not yet up to speed on this topic, Secure Messaging >was pioneered by ISO in 7816, and later enhanced by Global Platform. > >http://www.opensc-project.org/opensc/wiki/SecureMessaging According to the home page "OpenSC provides a set of libraries and utilities to work with smart cards." So, this terminology is smart card-specfic. >The principle is quite simple: The issuer and the cryptographic container >in some way establish a shared session secret which is used in an arbitrary >number of subsequent steps to MAC and/or encrypt data in both directions. > >The power of this concept are plentiful: >- You know that the generated keys actually reside in the crypto module > >- You can through use of a session perform a multi-step enrollment > as a transaction. It either succeeds or leave the crypto module intact. > >- It becomes very simple to exchange secret data like PIN-codes or > perform backup of private keys. > >So, is secure messaging also supported by CMP or CMC? CMC and CMP were not targeting smart cards. They did meet a requirement to support staged delivery communication with an issuer, as that was viewed as an important requirement. Thus it seems unlikely that they would offer a model that relies on realtime communications with an issuer. Steve From kent@bbn.com Mon Apr 4 10:42:10 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9D63A6A12 for ; Mon, 4 Apr 2011 10:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0I4sKStxnb8 for ; Mon, 4 Apr 2011 10:42:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id CB4373A6A0C for ; Mon, 4 Apr 2011 10:42:06 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49155) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6nob-000MxD-79; Mon, 04 Apr 2011 13:43:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1301934762.2382.8.camel@nostromo> References: <1301934762.2382.8.camel@nostromo> Date: Mon, 4 Apr 2011 13:15:00 -0400 To: Thomas Pornin From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:42:10 -0000 At 12:32 PM -0400 4/4/11, Thomas Pornin wrote: >On Mon, 2011-04-04 at 10:43 -0400, Stephen Kent wrote: >> Finally, -SRP seems to focus on one-way (client to server) auth > >No, SRP is two-ways: the client and the server are mutually >authenticated with regards to the shared secret (i.e. the password). SRP >is a PAKE (Password Authenticated key Exchange) which adds protection >against offline dictionary attacks: an attacker trying to guess the >shared secret must interact with either the client or the server for >each guess; he never learns enough to try potential passwords "at home". >That's why the shared secret can be of relatively low entropy (e.g. >something which fits in the brain of a human being, colloquially known >as a "password"). > >Where SRP is asymmetric is in secret data storage: what the server >stores is not the shared secret, but some data derived from the shared >secret. This is additional security: an attacker who has read access to >the complete server memory does not learn the shared secret (he does >learn enough to be able to masquerade as the server, but not as the >client; also, he learns enough to make an offline dictionary attack on >the shared secret). Thanks for the clarification. Steve From pritikin@cisco.com Mon Apr 4 11:57:06 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F913A6768 for ; Mon, 4 Apr 2011 11:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Awq89fYVmXNW for ; Mon, 4 Apr 2011 11:57:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C6E2F3A6767 for ; Mon, 4 Apr 2011 11:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2027; q=dns/txt; s=iport; t=1301943528; x=1303153128; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=GJPoMIgc+mHFuBspwKMlN8XbIXUsy3T9Rn6aAWwmZNc=; b=ABDz8W+D308lxKUb1GBSTzCMTpERm2Ry2E3hzUa4+rU85VY5b0v88cVv 6Tc4HqVGgJkcesAhhwbcSrWs3K3kKGrReWU2zBK4j9O8tz9p81ZnwisZq K/9fU2vpwxaGsigjiBdeKUZsLRYM2is1tp60wRxTjm6ZhgvdS/OFRDOKH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKcTmk2rRDoI/2dsb2JhbAClYXeIeZwknAuFawSFR4dcg1s X-IronPort-AV: E=Sophos;i="4.63,298,1299456000"; d="scan'208";a="675500373" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 04 Apr 2011 18:58:48 +0000 Received: from [192.168.20.2] ([10.21.74.207]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34Iwjv8005646; Mon, 4 Apr 2011 18:58:46 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: <4D976594.1000901@telia.com> Date: Mon, 4 Apr 2011 12:38:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <22DAA1A5-0B48-434B-8FF7-84C0A1028879@cisco.com> References: <4D976594.1000901@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1082) Cc: "pkix@ietf.org" Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:57:06 -0000 On Apr 2, 2011, at 12:06 PM, Anders Rundgren wrote: > Since PIN deployment to issued credentials to my surprise apparently > already is fully featured in existing PKIX protocols (although nobody = has > bothered with providing a reference), I continue with the next = important > feature: Secure Messaging. >=20 > For those who are not yet up to speed on this topic, Secure Messaging > was pioneered by ISO in 7816, and later enhanced by Global Platform. >=20 > http://www.opensc-project.org/opensc/wiki/SecureMessaging >=20 > The principle is quite simple: The issuer and the cryptographic = container > in some way establish a shared session secret which is used in an = arbitrary > number of subsequent steps to MAC and/or encrypt data in both = directions. >=20 > The power of this concept are plentiful: > - You know that the generated keys actually reside in the crypto = module >=20 > - You can through use of a session perform a multi-step enrollment > as a transaction. It either succeeds or leave the crypto module = intact. >=20 > - It becomes very simple to exchange secret data like PIN-codes or > perform backup of private keys. >=20 > So, is secure messaging also supported by CMP or CMC? CMC uses message layer security and does not directly support this = concept. The EST draft uses a TLS session to protect all traffic. This is = effectively what you describe -- if the cryptographic container has an appropriate = credential for=20 establishing the TLS connection "shared session secret" then any = subsequent=20 communication is protected by this secret. It sounds like you are = concerned that the cryptographic container be what establishes this connection -- in which = case TLS would be a reasonable protocol to be implemented by the cryptographic = container.=20 - max >=20 > Anders >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pritikin@cisco.com Mon Apr 4 11:57:08 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36EB3A679F for ; Mon, 4 Apr 2011 11:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8ko+07Fngtp for ; Mon, 4 Apr 2011 11:57:08 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 13F3B3A66B4 for ; Mon, 4 Apr 2011 11:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1886; q=dns/txt; s=iport; t=1301943530; x=1303153130; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=r1NTDB/pTcrRjDQUdbsYV6/Ht2VqtRJXF2Hr5hQ+8eU=; b=le9kjwaQZK8eY5UPbO4f1/LyvQ4Ew5f4e0O8im+Co4+FP2T90HUV+YF1 aTzaQSmMStcwpxSPfV0KjL4XOTbMGkKGWa/bsWASvP6NQuciwX4jwamaW ZDEpWI/FzNhkd7WqzFyyP92d51o5tyO5YAyUt17XeCt+/AEaLoJeKO7zz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB8Umk2rRDoI/2dsb2JhbAClY3eIeZwdnAuFawSFR4dcg1s X-IronPort-AV: E=Sophos;i="4.63,298,1299456000"; d="scan'208";a="289056415" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 04 Apr 2011 18:58:50 +0000 Received: from [192.168.20.2] ([10.21.74.207]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34Iwjv9005646; Mon, 4 Apr 2011 18:58:49 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: <503EB32C9885B2468531E6D637BE41121FB82E3FAE@mail.insta.fi> Date: Mon, 4 Apr 2011 12:56:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <503EB32C9885B2468531E6D637BE41121FB82E3FAE@mail.insta.fi> To: Suomela Tero X-Mailer: Apple Mail (2.1082) Cc: "pkix@ietf.org" Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:57:09 -0000 On Apr 1, 2011, at 2:20 AM, Suomela Tero wrote: >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of max pritikin >=20 >>> http://www.ietf.org/proceedings/80/slides/pkix-3.pdf >=20 >> An important element of the EST proposal is to move the transport >> security from the message layer (PKCS#7 or CMS) and instead to use = TLS. >> This is why we decided to call it Enrollment over Secure Transport. >> TLS is well established as a transport layer security within the = broader >> community.=20 >=20 > How does this really differ from CMP then? It has the same PKCS#10 and = CRMF > formats and can as well be used over TLS. I suppose the EST would be = simpler, > but are there any real conceptual differences? Why choose this instead = of CMP? Given the lack to interoperable PKI enrollment/deployment and use = mechanisms I feel that "simpler" is not to be understated.=20 CMP [RFC4210] describes transport as being handled by an external = "CMPTrans" document of which the current draft is = draft-ietf-pkix-cmp-transport-protocols-10 (expired 2 days ago but I = suspect an update will happen soon). As such CMP provides an optional = "PKI Message protection" methods where "In the future, if/when external = mechanisms are modified to accommodate boot-strapping scenarios, the use = of PKIProtection may become rare or non-existent". I believe the future is now. Sufficient external mechanisms are = currently available and we need to leverage them (in addition to = encouraging improvements in those areas as necessary). Doing so allows = us to simplify by removing many options and focusing only on the core = enrollment methods actually necessary.=20 - max >=20 > - Tero > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pritikin@cisco.com Mon Apr 4 11:57:12 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C608D3A67A8 for ; Mon, 4 Apr 2011 11:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nj9IjvhQ0sV for ; Mon, 4 Apr 2011 11:57:12 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 825C73A6407 for ; Mon, 4 Apr 2011 11:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2027; q=dns/txt; s=iport; t=1301943535; x=1303153135; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=GJPoMIgc+mHFuBspwKMlN8XbIXUsy3T9Rn6aAWwmZNc=; b=KImeCJcFRoGhPArkqH1l/Hqs1evrRAK1/KduERuiGqe9hld7+8kXHZ7/ S8wKQN6fdbnGEBqaAJL6gK9LTRobvjE+0YEnsQtvqQYuuoyHUG9hDZVFx vUElf+c/o1epZzzezW6LjMIijXHljq3Kir1coxK6D7x3hjuwZVAySSIAF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB8Umk2rRDoI/2dsb2JhbAClY3eIeZwdnAuFawSFR4dcg1s X-IronPort-AV: E=Sophos;i="4.63,298,1299456000"; d="scan'208";a="423618659" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2011 18:58:55 +0000 Received: from [192.168.20.2] ([10.21.74.207]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34IwjvB005646; Mon, 4 Apr 2011 18:58:53 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: <4D976594.1000901@telia.com> Date: Mon, 4 Apr 2011 12:58:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D976594.1000901@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1082) Cc: "pkix@ietf.org" Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:57:12 -0000 On Apr 2, 2011, at 12:06 PM, Anders Rundgren wrote: > Since PIN deployment to issued credentials to my surprise apparently > already is fully featured in existing PKIX protocols (although nobody = has > bothered with providing a reference), I continue with the next = important > feature: Secure Messaging. >=20 > For those who are not yet up to speed on this topic, Secure Messaging > was pioneered by ISO in 7816, and later enhanced by Global Platform. >=20 > http://www.opensc-project.org/opensc/wiki/SecureMessaging >=20 > The principle is quite simple: The issuer and the cryptographic = container > in some way establish a shared session secret which is used in an = arbitrary > number of subsequent steps to MAC and/or encrypt data in both = directions. >=20 > The power of this concept are plentiful: > - You know that the generated keys actually reside in the crypto = module >=20 > - You can through use of a session perform a multi-step enrollment > as a transaction. It either succeeds or leave the crypto module = intact. >=20 > - It becomes very simple to exchange secret data like PIN-codes or > perform backup of private keys. >=20 > So, is secure messaging also supported by CMP or CMC? CMC uses message layer security and does not directly support this = concept. The EST draft uses a TLS session to protect all traffic. This is = effectively what you describe -- if the cryptographic container has an appropriate = credential for=20 establishing the TLS connection "shared session secret" then any = subsequent=20 communication is protected by this secret. It sounds like you are = concerned that the cryptographic container be what establishes this connection -- in which = case TLS would be a reasonable protocol to be implemented by the cryptographic = container.=20 - max >=20 > Anders >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Mon Apr 4 12:51:47 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972EE3A67B1 for ; Mon, 4 Apr 2011 12:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj+Mu7gLgY1J for ; Mon, 4 Apr 2011 12:51:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id F1A063A6768 for ; Mon, 4 Apr 2011 12:51:46 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49173) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6pq4-000Otb-RG for pkix@ietf.org; Mon, 04 Apr 2011 15:53:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <016c01cbef98$f60521b0$e20f6510$@augustcellars.com> References: <016c01cbef98$f60521b0$e20f6510$@augustcellars.com> Date: Mon, 4 Apr 2011 15:48:23 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [pkix] Concluding OCSP Agility X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:51:47 -0000 Folks, Jim made a good argument why SMIMECapabilties might be preferable to AlgID in the context of advertising which algs are supported. At the PKIX meeting the ADs suggested that if we wanted to make this change to the OCSP agility doc (now in the RFC Editor's queue), that they would support this as a trivial change, not requiring a new IETF LC, etc. (This is justified because only one alg would be different in a bits-on-the-wire sense, and it is not clear that we care about it anyway.) So, I am now starting a 1-week LC on this issue. The LC will end Tuesday morning, 4/12. Steve >... >I realize that I am late on this. > >The definition that I use for these two types are: > >SMIMECapabilities is what party A uses to request that party B uses >one of a set of algorithms in talking to it. > >AlgorithmIdentifier is what party A uses to tell party B what >algorithm is actually being used. > >This separation makes it clear (at least to me) exactly when one >should use each of these items. > >Jim > From DPKemp@missi.ncsc.mil Mon Apr 4 13:04:28 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEA93A67CC for ; Mon, 4 Apr 2011 13:04:28 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMAmxCe3rHXV for ; Mon, 4 Apr 2011 13:04:27 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 3C9E83A67C3 for ; Mon, 4 Apr 2011 13:04:27 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p34K69Qq021344 for ; Mon, 4 Apr 2011 16:06:09 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Apr 2011 16:05:43 -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: Mon, 4 Apr 2011 16:06:08 -0400 Message-ID: In-Reply-To: <4D976594.1000901@telia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Secure Messaging in PKIX enrollment protocols Thread-Index: AcvxYKt5QxJzVGniT5KqVNGtcIEunwBlplWA References: <4D976594.1000901@telia.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 04 Apr 2011 20:05:43.0671 (UTC) FILETIME=[ADCFA870:01CBF303] Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:04:28 -0000 IlNlY3VyZSBNZXNzYWdpbmciIGlzIGFuIHVuZm9ydHVuYXRlIGNob2ljZSBvZiB0ZXJtcywgc2lu Y2UgdGhlIGNvbmNlcHQgZGVzY3JpYmVkIGluIHRoZSB3aWtpIC4uLg0KDQogICAg4oCiUHJvdmlk ZSBhIHBvc3NpYmlsaXR5IG9mIGRpZmZlcmVudCBTTSBzZXNzaW9uIGluaXRpYWxpemF0aW9uIG1v ZGVzIGFuZCBTTSBzZXNzaW9uIGxpZmV0aW1lcyANCiAgICAgICAg4pemaW5pdGlhbGl6ZWQgYXQg Y2FyZCBjb25uZWN0aW9uLCB2YWxpZCB1bnRpbCBjYXJkIGlzIGRpc2Nvbm5lY3RlZCANCiAgICAg ICAg4pemaW5pdGlhbGl6ZWQgd2hlbiBTTSBwcm90ZWN0ZWQgQUNMIGlzIGVuY291bnRlcmVkLCB2 YWxpZCBkdXJpbmcgdGhlIHNtYWxsIG51bWJlciBvZiB0cmFuc2FjdGlvbnMNCg0KLi4uIGlzICJz ZXNzaW9uIi4gIFRoZSBjb25jZXB0IG9mIHNlY3VyZSBzZXNzaW9ucyBkaWRuJ3Qgb3JpZ2luYXRl IHdpdGggR2xvYmFsIFBsYXRmb3JtOyB0aGUgd2hvbGUgaWRlYSBiZWhpbmQgU1NML1RMUyBhbmQg SVBTZWMgaXMgdG8gZXN0YWJsaXNoIHNlc3Npb24ga2V5cyB0aGF0IGFyZSB1c2VkIHRvIHByb3Rl Y3QgZGF0YSBleGNoYW5nZWQgd2l0aGluIHRoYXQgc2Vzc2lvbi4NCg0KTWVzc2FnaW5nIGludm9s dmVzIGRpc2NyZXRlIG1lc3NhZ2VzIChBUERVcykgdGhhdCBtYXkgYmUsIGJ1dCBhcmUgbm90IG5l Y2Vzc2FyaWx5LCBjYXJyaWVkIHdpdGhpbiBhIHNpbmdsZSBzZXNzaW9uLiAgVGhlIGFzc3VtcHRp b24gaXMgdGhhdCB0aGV5IGFyZSBub3QsIGFzIGluIFNNVFAsIFMvTUlNRSwgb3IgaHR0cDovL3d3 dy5kaXNhLm1pbC9uY2VzL20ybS5odG1sOiAiSXRzIGd1YXJhbnRlZWQgZGVsaXZlcnkgdG8gZGlz Y29ubmVjdGVkIGFwcGxpY2F0aW9ucyBlbnN1cmVzIHRoYXQgbWVzc2FnZXMgYXJlIGRlbGl2ZXJl ZC4iDQoNClNlY3VyZSBNZXNzYWdpbmcgc2hvdWxkIHByb3ZpZGUgc2VjdXJpdHkgZm9yIG1lc3Nh Z2VzLiAgU2luY2UgR2xvYmFsIFBsYXRmb3JtIFNNIGFkZHJlc3NlcyBvbmx5IHRoZSBzaW1wbGUg KGNvbm5lY3RlZCkgY2FzZSBhbmQgaWdub3JlcyB0aGUgbW9yZSBkaWZmaWN1bHQgKGNvbm5lY3Rp b25sZXNzKSBjYXNlLCB0aGF0IHRlY2hub2xvZ3kgc2hvdWxkIGJlIHF1YWxpZmllZCBhcyAiR1Ag U00iIG9yICJTZXNzaW9uLWJhc2VkIFNNIiB3aGVuIHRoZSBjb250ZXh0IGlzIG1lc3NhZ2luZyBp biBnZW5lcmFsLg0KDQpEYXZlDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHBraXgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFuZGVycyBSdW5kZ3Jlbg0KDQpGb3IgdGhvc2Ugd2hvIGFyZSBub3QgeWV0IHVw IHRvIHNwZWVkIG9uIHRoaXMgdG9waWMsIFNlY3VyZSBNZXNzYWdpbmcNCndhcyBwaW9uZWVyZWQg YnkgSVNPIGluIDc4MTYsIGFuZCBsYXRlciBlbmhhbmNlZCBieSBHbG9iYWwgUGxhdGZvcm0uDQoN Cmh0dHA6Ly93d3cub3BlbnNjLXByb2plY3Qub3JnL29wZW5zYy93aWtpL1NlY3VyZU1lc3NhZ2lu Zw0KDQpUaGUgcHJpbmNpcGxlIGlzIHF1aXRlIHNpbXBsZTogVGhlIGlzc3VlciBhbmQgdGhlIGNy eXB0b2dyYXBoaWMgY29udGFpbmVyDQppbiBzb21lIHdheSBlc3RhYmxpc2ggYSBzaGFyZWQgc2Vz c2lvbiBzZWNyZXQgd2hpY2ggaXMgdXNlZCBpbiBhbiBhcmJpdHJhcnkNCm51bWJlciBvZiBzdWJz ZXF1ZW50IHN0ZXBzIHRvIE1BQyBhbmQvb3IgZW5jcnlwdCBkYXRhIGluIGJvdGggZGlyZWN0aW9u cy4NCg0K From anders.rundgren@telia.com Mon Apr 4 13:38:01 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE4C43A67E1 for ; Mon, 4 Apr 2011 13:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNQQLP8kpalF for ; Mon, 4 Apr 2011 13:37:59 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by core3.amsl.com (Postfix) with ESMTP id 3AAD03A67DA for ; Mon, 4 Apr 2011 13:37:59 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D65154400BEAE17; Mon, 4 Apr 2011 22:39:38 +0200 Message-ID: <4D9A2C8B.6060402@telia.com> Date: Mon, 04 Apr 2011 22:39:39 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: max pritikin References: <4D976594.1000901@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:38:01 -0000 On 2011-04-04 20:58, max pritikin wrote: > >> So, is secure messaging also supported by CMP or CMC? > > CMC uses message layer security and does not directly support this concept. > > The EST draft uses a TLS session to protect all traffic. This is effectively what > you describe -- if the cryptographic container has an appropriate credential for > establishing the TLS connection "shared session secret" then any subsequent > communication is protected by this secret. It sounds like you are concerned that the > cryptographic container be what establishes this connection -- in which case TLS > would be a reasonable protocol to be implemented by the cryptographic container. At a 50000 ft level this sounds reasonable; at the ground level it looks quite different. In *my* take on secure messaging a "semi-trusted proxy" does all the "heavy lifting" as well as allowing user interaction. The latter would be impossible in a true TLS session and the former would be a poor use of "trusted silicon". By using a "TLS-inspired" scheme the net result became a simple but still quite capable crypto container: http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/sks/test/SKSReferenceImplementation.java supported by a rather nice high-level protocol: http://webpki.org/papers/keygen2/sks-api-arch.pdf#page=31 GlobalPlatform haven't released their enrollment specs yet, only the API (APDUs). Anders From stefan@aaa-sec.com Mon Apr 4 13:38:10 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72243A67E5 for ; Mon, 4 Apr 2011 13:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ULHp7+k7HnG for ; Mon, 4 Apr 2011 13:38:10 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by core3.amsl.com (Postfix) with ESMTP id CD4E63A67E3 for ; Mon, 4 Apr 2011 13:38:09 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id AD4B5310B4D for ; Mon, 4 Apr 2011 22:39:58 +0200 (CEST) Received: (qmail 54382 invoked from network); 4 Apr 2011 20:39:50 -0000 Received: from host-90-237-57-153.mobileonline.telia.com (HELO [172.20.10.3]) (stefan@fiddler.nu@[90.237.57.153]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Apr 2011 20:39:50 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Mon, 04 Apr 2011 22:39:42 +0200 From: Stefan Santesson To: Stephen Kent , Message-ID: Thread-Topic: [pkix] Concluding OCSP Agility In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Concluding OCSP Agility X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:38:10 -0000 I will start off by saying that I'm divided. I see the logic in Jim's arguments but liked the fact that the current algorithm identifier directly maps to the identifiers that are specified in other protocols which makes the mapping easier and possibly less error prone when implemented. I hope this LC will reveal some good arguments for either solution. /Stefan On 11-04-04 9:48 PM, "Stephen Kent" wrote: >Folks, > >Jim made a good argument why SMIMECapabilties might be preferable to AlgID >in the context of advertising which algs are supported. At the PKIX >meeting >the ADs suggested that if we wanted to make this change to the OCSP >agility doc (now in the RFC Editor's queue), that they would support >this as a trivial >change, not requiring a new IETF LC, etc. (This is justified because >only one alg would be different in a bits-on-the-wire sense, and it >is not clear that we care about it anyway.) > >So, I am now starting a 1-week LC on this issue. The LC will end >Tuesday morning, 4/12. > >Steve > >>... >>I realize that I am late on this. >> >>The definition that I use for these two types are: >> >>SMIMECapabilities is what party A uses to request that party B uses >>one of a set of algorithms in talking to it. >> >>AlgorithmIdentifier is what party A uses to tell party B what >>algorithm is actually being used. >> >>This separation makes it clear (at least to me) exactly when one >>should use each of these items. >> >>Jim >> >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Mon Apr 4 13:39:56 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7DA3A67E1 for ; Mon, 4 Apr 2011 13:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2fDRA0Ey8vi for ; Mon, 4 Apr 2011 13:39:53 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by core3.amsl.com (Postfix) with ESMTP id 2B0AB3A67B7 for ; Mon, 4 Apr 2011 13:39:53 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A100F9C4FE; Mon, 4 Apr 2011 22:41:32 +0200 Message-ID: <4D9A2CFE.2010104@telia.com> Date: Mon, 04 Apr 2011 22:41:34 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Miller, Timothy J." References: <4D941BD6.1050906@telia.com> <3B450330-DDA3-4CFD-ACEF-166EFE82DA66@cisco.com> <4D95766D.7080303@telia.com> <4D96E7F5.7060904@telia.com> <4D971867.3050901@telia.com> <9EA99870-A784-4AA5-9B40-F8325C2BB7F5@mitre.org> In-Reply-To: <9EA99870-A784-4AA5-9B40-F8325C2BB7F5@mitre.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] PIN support in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:39:56 -0000 On 2011-04-04 14:25, Miller, Timothy J. wrote: > On Apr 2, 2011, at 7:36 AM, Anders Rundgren wrote: > >>> If so, then you should be talking to some ISO >>> committee, because they deal with smart card standards. >> >> That's seems more to be a task for Max and PKIX in case smart >> cards is a part of "as many devices as possible". Is it? >> >> Personally, I don't want to build on technology and standards >> that were created in an entirely different time when hardware >> had 1/100 the power it has today, and on-line was equivalent >> to a 56kbit/s dial-up modem. > > I think Stephen's point was that secure channels between > cryptomodules is essentially a solved problem > *under the condition* that at least one module can be securely > provisioned by or register a key with the other (whether > that key be symmetric or asymmetric). Tim, Sure, but that doesn't make deployment of PINs automatically become a part of CMC, CMP, SCEP or EST. > In the smartcard arena, the token manager does this > either at manufacture or at some other time prior to > issuance; once done, all subsequent interactions between > parties inherits the assurance of the union between the > initial provision/registry assurance and the inherent > assurance of the smartcard. Absolutely. > You can layer as many levels of indirection around this as > you want, but I think this is a fundamental interaction that > can't be escaped. 100% agreed. > I've looked at your work before, and correct me if I'm wrong, > but I don't think your approach does anything to lift this > constraint. The intention is enabling working provisioning solutions for consumers who buy (or receive) a cryptomodule (be it embedded in a phone or a separate token), where issuers may discriminate cryptomodules vendors to their liking. A few related pointers worth following: http://www.globalplatform.org/medianewsletterarchives.asp?id=mednew201101 "GlobalPlatform Announces the Formation of a Consumer-centric Working Group" "the technical foundations are in place to address this 'white card' concept" http://www.digitaltrends.com/mobile/devices/google-teams-with-mastercard-and-citigroup-for-nfc-testing Regardless of if my take on this topic succeeds or not, I'm pretty convinced that the larger part of the consumer market will rely on on-line provisioning based on secure messaging and that IMHO, limits the scope of a new PKIX enrollment effort since all the tech *seems* to have been fixed before a more thorough use-case analysis has been carried out. I wouldn't underestimate the difficulties: http://www.craigburton.com/?p=3131 Although MSFT refers to all kinds of misfortunes ("the world wasn't ready"), the true culprit behind this epic failure is that MSFT does not have a consumer PKI enrollment solution that meets even the most basic requirements which has created a whole industry of IMO fairly redundant makers of "browser PKI clients". I always thought that the idea was that the browser did the PKI-ops itself!!! I think the following guys could have an instrumental role (if they want...) in the creation of consumer PKI technology: http://www.nist.gov/nstic --Anders From kent@bbn.com Mon Apr 4 13:54:44 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8102E3A67EE for ; Mon, 4 Apr 2011 13:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxgulCfIQ4VD for ; Mon, 4 Apr 2011 13:54:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CFCC03A67B7 for ; Mon, 4 Apr 2011 13:54:43 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49179) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q6qp0-000DvP-4i; Mon, 04 Apr 2011 16:56:26 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 4 Apr 2011 16:56:19 -0400 To: pritikin@cisco.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: [pkix] cert enrollment requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:54:44 -0000 Max, I think we (you?) should start to enumerate requirements for this protocol, based on a set of scenarios. I suggest that we begin with an outline that enumerates examples of what we MUST support, and then discusses characteristics that we want from the protocol, and going-in assumptions about ways to satisfy the requirements and meet the design goals. What kinds of subjects do we plan to support: people and devices? Do we require people have crypto tokens, or not? If we require a token, does the token need to have an embedded processor, like a smart card? What kinds of devices (end systems, network elements, embedded processors, ...) do we support? How do subjects authenticate to issuers, e.g., PIN/password, device cert, OTP token, ...? Will we support only those subjects that connect to an issuer in realtime or will we support staged delivery as well? What cert management functions will we support: cert request, renewal, rekey, revocation request, ...? WIll we support only RSA keys for the subject, or will sig-only alg keys or key-agreement only alg keys be ok too? (Hint: since algorithm agility is now mandated by the IESG, RSA-only is NOT a viable answer :-).) Will we support PoP for subject keys? (again, a trick question :-).) Do we assume that the issuer has an X.509 CA cert? This is just a start, but these are the types of questions that need to be answered if we are to make progress. Steve From anders.rundgren@telia.com Mon Apr 4 19:40:10 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABB73A684F for ; Mon, 4 Apr 2011 19:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.633 X-Spam-Level: X-Spam-Status: No, score=-3.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7gwSlQaNSre for ; Mon, 4 Apr 2011 19:40:09 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by core3.amsl.com (Postfix) with ESMTP id 260D03A6840 for ; Mon, 4 Apr 2011 19:40:08 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A100FA71E9; Tue, 5 Apr 2011 04:41:40 +0200 Message-ID: <4D9A8167.9080907@telia.com> Date: Tue, 05 Apr 2011 04:41:43 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephen Kent , "pkix@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] cert enrollment requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 02:40:10 -0000 Steve, Now you rock! Really good questions all the way. Anders On 2011-04-04 22:56, Stephen Kent wrote: > Max, > > I think we (you?) should start to enumerate requirements for this > protocol, based on a set of scenarios. I suggest that we begin with > an outline that enumerates examples of what we MUST support, and then > discusses characteristics that we want from the protocol, and > going-in assumptions about ways to satisfy the requirements and meet > the design goals. > > What kinds of subjects do we plan to support: people and devices? > > Do we require people have crypto tokens, or not? > If we require a token, does the token need to have an embedded > processor, like a smart card? > > What kinds of devices (end systems, network elements, embedded > processors, ...) do we support? > > How do subjects authenticate to issuers, e.g., PIN/password, device > cert, OTP token, ...? > > Will we support only those subjects that connect to an issuer in > realtime or will we support staged delivery as well? > > What cert management functions will we support: cert request, > renewal, rekey, revocation request, ...? > > WIll we support only RSA keys for the subject, or will sig-only alg > keys or key-agreement only alg keys be ok too? (Hint: since algorithm > agility is now mandated by the IESG, RSA-only is NOT a viable answer > :-).) > > Will we support PoP for subject keys? (again, a trick question :-).) > > Do we assume that the issuer has an X.509 CA cert? > > This is just a start, but these are the types of questions that need > to be answered if we are to make progress. > > Steve > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From Internet-Drafts@ietf.org Tue Apr 5 04:45:10 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7123A6938; Tue, 5 Apr 2011 04:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxqUQJjDsPel; Tue, 5 Apr 2011 04:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD403A67B3; Tue, 5 Apr 2011 04:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110405114502.9334.18078.idtracker@localhost> Date: Tue, 05 Apr 2011 04:45:02 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 11:45:10 -0000 --NextPart 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 : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Author(s) : D. Cooper, S. Santesson Filename : draft-ietf-pkix-rfc2560bis-03.txt Pages : 43 Date : 2011-04-05 This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2560bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-rfc2560bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-05043624.I-D@ietf.org> --NextPart-- From denis.pinkas@bull.net Tue Apr 5 04:53:50 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8DC3A67B3 for ; Tue, 5 Apr 2011 04:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.355 X-Spam-Level: ** X-Spam-Status: No, score=2.355 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwK99JsfgkKh for ; Tue, 5 Apr 2011 04:53:43 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id 471223A6403 for ; Tue, 5 Apr 2011 04:53:43 -0700 (PDT) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 0FDEC198138 for ; Tue, 5 Apr 2011 14:03:55 +0200 (CEST) Received: from B016404 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2011040513552572:3299 ; Tue, 5 Apr 2011 13:55:25 +0200 From: "Denis Pinkas" To: "pkix" Date: Tue, 5 Apr 2011 13:55:25 +0200 Message-Id: References: <20110405114502.9334.18078.idtracker@localhost> MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 05/04/2011 13:55:25, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 05/04/2011 13:55:25, Serialize complete at 05/04/2011 13:55:25 Content-Type: multipart/alternative; boundary="----=_NextPart_11040513552502837722772_002" Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 11:53:50 -0000 ------=_NextPart_11040513552502837722772_002 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ISO-8859-1" V291bGQgaXQgYmUgcG9zc2libGUgdGhhdCB0aGUgY28tZWRpdG9ycyBpbmRpY2F0ZSB3aGljaCBj aGFuZ2VzIGhhdmUgYmVlbiBkb25lID8NCg0KRGVuaXMNCi0tLS0tIE1lc3NhZ2UgcmXndSAtLS0t LSANCkRlIDogcGtpeC1ib3VuY2VzIA0KwCA6IGktZC1hbm5vdW5jZSANCkRhdGUgOiAyMDExLTA0 LTA1LCAxMzo0NTowMg0KU3VqZXQgOiBbcGtpeF0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLXBraXgt cmZjMjU2MGJpcy0wMy50eHQNCg0KDQpQaehjZShzKSBKb2ludGUocykgYXUgbWVzc2FnZSBvcmln aW5hbCA6DQogICgxKS4gZHJhZnQtaWV0Zi1wa2l4LXJmYzI1NjBiaXMtMDMudHh0DQoNCg0KICBU aXRsZSA6IFguNTA5IEludGVybmV0IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgT25saW5lIENl cnRpZmljYXRlIFN0YXR1cyBQcm90b2NvbCAtIE9DU1ANCiAgQXV0aG9yKHMpIDogRC4gQ29vcGVy LCBTLiBTYW50ZXNzb24NCiAgRmlsZW5hbWUgOiBkcmFmdC1pZXRmLXBraXgtcmZjMjU2MGJpcy0w My50eHQNCiAgUGFnZXMgOiA0Mw0KICBEYXRlIDogMjAxMS0wNC0wNQ0KDQpUaGlzIGRvY3VtZW50 IHNwZWNpZmllcyBhIHByb3RvY29sIHVzZWZ1bCBpbiBkZXRlcm1pbmluZyB0aGUgY3VycmVudA0K c3RhdHVzIG9mIGEgZGlnaXRhbCBjZXJ0aWZpY2F0ZSB3aXRob3V0IHJlcXVpcmluZyBDUkxzLg0K DQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGtpeC1yZmMyNTYwYmlzLTAzLnR4dA0KDQpJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3aGlj aCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQppbXBsZW1lbnRhdGlv biB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KSW50 ZXJuZXQtRHJhZnQuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fIG5leHQgcGFydCBfX19fX19f X19fX19fX19fX19fX19fDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpwa2l4IG1haWxpbmcgbGlzdA0KcGtpeEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4DQo= ------=_NextPart_11040513552502837722772_002 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ISO-8859-1" PEhUTUw+PEhFQUQ+PFRJVExFPjwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJLc0RIVE1MRURMaWIu b2N4LCBGcmVlV2FyZSBIVE1MIEVkaXRvciAxLjE2NC4yLCCpIEt1cnQgU2VuZmVyIiANCm5hbWU9 R0VORVJBVE9SPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiIGxlZnRNYXJnaW49NSB0b3BNYXJnaW49NSANCiNm ZmZmZmY+DQo8RElWPldvdWxkIGl0IGJlIHBvc3NpYmxlIHRoYXQgdGhlIGNvLWVkaXRvcnMgaW5k aWNhdGUgd2hpY2ggY2hhbmdlcyBoYXZlIGJlZW4gDQpkb25lID88L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPkRlbmlzPC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJ R0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVG VDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViANCiAgc3R5 bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBMSU5FLUhFSUdIVDogbm9y bWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFOVDogbm9ybWFsIj4tLS0tLSANCiAg TWVzc2FnZSByZed1IC0tLS0tIDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6 IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IEJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IExJTkUtSEVJR0hU OiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWw7IGZvbnQt Y29sb3I6IGJsYWNrIj48Qj5EZSANCiAgOjwvQj4gPEEgaHJlZj0ibWFpbHRvIDpwa2l4LWJvdW5j ZXNAaWV0Zi5vcmciPnBraXgtYm91bmNlczwvQT4gPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJG T05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsg Rk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklBTlQ6IG5vcm1hbCI+PEI+wCANCiAgOjwvQj4g PEEgaHJlZj0ibWFpbHRvIDppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZTwvQT4g PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6 IDlwdDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULVZBUklB TlQ6IG5vcm1hbCI+PEI+RGF0ZSANCiAgOjwvQj4gMjAxMS0wNC0wNSwgMTM6NDU6MDI8L0RJVj4N CiAgPERJViANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBM SU5FLUhFSUdIVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFOVDogbm9y bWFsIj48Qj5TdWpldCANCiAgOjwvQj4gW3BraXhdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1wa2l4 LXJmYzI1NjBiaXMtMDMudHh0PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPjwvRElW Pg0KICA8RElWPg0KICA8RElWPjxVPjxTVFJPTkc+UGnoY2UocykgSm9pbnRlKHMpIGF1IG1lc3Nh Z2Ugb3JpZ2luYWwgOjwvU1RST05HPjwvVT48L0RJVj4NCiAgPERJVj4mbmJzcDsmbmJzcDsoMSku Jm5ic3A7ZHJhZnQtaWV0Zi1wa2l4LXJmYzI1NjBiaXMtMDMudHh0PC9ESVY+PEJSPjwvRElWPg0K ICA8RElWPg0KICA8RElWPiZuYnNwOyZuYnNwO1RpdGxlIDogWC41MDkgSW50ZXJuZXQgUHVibGlj IEtleSBJbmZyYXN0cnVjdHVyZSBPbmxpbmUgDQogIENlcnRpZmljYXRlIFN0YXR1cyBQcm90b2Nv bCAtIE9DU1A8QlI+Jm5ic3A7Jm5ic3A7QXV0aG9yKHMpIDogRC4gQ29vcGVyLCBTLiANCiAgU2Fu dGVzc29uPEJSPiZuYnNwOyZuYnNwO0ZpbGVuYW1lIDogDQogIGRyYWZ0LWlldGYtcGtpeC1yZmMy NTYwYmlzLTAzLnR4dDxCUj4mbmJzcDsmbmJzcDtQYWdlcyA6IA0KICA0MzxCUj4mbmJzcDsmbmJz cDtEYXRlIDogMjAxMS0wNC0wNTxCUj48QlI+VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBwcm90 b2NvbCANCiAgdXNlZnVsIGluIGRldGVybWluaW5nIHRoZSBjdXJyZW50PEJSPnN0YXR1cyBvZiBh IGRpZ2l0YWwgY2VydGlmaWNhdGUgd2l0aG91dCANCiAgcmVxdWlyaW5nIENSTHMuPEJSPjxCUj5B IFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8QlI+PEEgDQogIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtcGtpeC1yZmMyNTYwYmlzLTAz LnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wa2l4 LXJmYzI1NjBiaXMtMDMudHh0PC9BPjxCUj48QlI+SW50ZXJuZXQtRHJhZnRzIA0KICBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCANCiAgYXQ6PEJSPmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvPEJSPjxCUj5CZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIA0K ICBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcjxCUj5pbXBsZW1lbnRhdGlvbiB0 byBhdXRvbWF0aWNhbGx5IA0KICByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiANCiAgdGhl PEJSPkludGVybmV0LURyYWZ0LjxCUj48QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fXyBuZXh0 IHBhcnQgDQogIF9fX19fX19fX19fX19fX19fX19fX188QlI+PEJSPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPnBraXggDQogIG1haWxpbmcgbGlzdDxC Uj48QSBocmVmPSJtYWlsdG86IHBraXhAaWV0Zi5vcmciPnBraXhAaWV0Zi5vcmc8L0E+PEJSPjxB IA0KICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeDwvQT48QlI+PEJSPjwvRElW PjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_11040513552502837722772_002-- From stefan@aaa-sec.com Tue Apr 5 05:01:17 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4303A6936 for ; Tue, 5 Apr 2011 05:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN5HuNxCulgW for ; Tue, 5 Apr 2011 05:01:10 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by core3.amsl.com (Postfix) with ESMTP id C65F83A6937 for ; Tue, 5 Apr 2011 05:01:08 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 9C8E62AC4B3 for ; Tue, 5 Apr 2011 14:02:54 +0200 (CEST) Received: (qmail 9521 invoked from network); 5 Apr 2011 12:02:48 -0000 Received: from unknown (HELO [192.168.1.8]) (stefan@fiddler.nu@[85.235.10.93]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Apr 2011 12:02:48 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 05 Apr 2011 14:02:43 +0200 From: Stefan Santesson To: , pkix Message-ID: Thread-Topic: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-03.txt In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384856968_6901625" Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 12:01:17 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384856968_6901625 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Denis, there are tools for that Browse http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-03 Click diff1 or diff2 on top of the page. FYI this is just an administrative update of 02 to prevent it from expiration. I did not include any changes of content. I will discuss with Dave and review comments on the list before updating content, but expect an update again quite soon. /Stefan From: Denis Pinkas Reply-To: Date: Tue, 5 Apr 2011 13:55:25 +0200 To: pkix Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-03.txt > Would it be possible that the co-editors indicate which changes have been= done > ? > =20 > Denis >> =20 >> ----- Message re=E7u ----- >> =20 >> De : pkix-bounces >> =20 >> =C0 : i-d-announce >> =20 >> Date : 2011-04-05, 13:45:02 >> =20 >> Sujet : [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-03.txt >> =20 >>=20 >> =20 >> =20 >> =20 >> Pi=E8ce(s) Jointe(s) au message original : >> =20 >> (1). draft-ietf-pkix-rfc2560bis-03.txt >>=20 >> =20 >> =20 >> Title : X.509 Internet Public Key Infrastructure Online Certificate S= tatus >> Protocol - OCSP >> Author(s) : D. Cooper, S. Santesson >> Filename : draft-ietf-pkix-rfc2560bis-03.txt >> Pages : 43 >> Date : 2011-04-05 >>=20 >> This document specifies a protocol useful in determining the current >> status of a digital certificate without requiring CRLs. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2560bis-03.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >>=20 >>=20 >> _____________________ next part ______________________ >>=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 --B_3384856968_6901625 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis, there are tools for t= hat

Click diff1 or diff2 on top of the page.

FYI this is just an administrative update of 02 to prevent = it from expiration.
I did not include any changes of content.

I will discuss with Dave and review comments on the lis= t before updating content, but expect an update again quite soon.
=
/Stefan


From: Denis Pinkas <denis.pinkas@bull.net>
Reply-To= : <denis.pinkas@bull.net>
Date: Tue, 5 Apr 2011 13:55= :25 +0200
To: pkix <pkix@ietf.org>
= Subject: Re: [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-03.txt
=

Would it be possible that the co-editors indicate which chan= ges have been done ?
 
Denis
----- Message re=E7u -----
Date : 2011-04-05, 13:45:02
Sujet : [pkix] I-D Action:draft-ietf-pkix-rfc2560bis-03.txt

Pi=E8ce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-rfc2560bis-03.txt

  Title : X.509 Internet Public Key Infrastructure Online = Certificate Status Protocol - OCSP
  Author(s) : D. Cooper, = S. Santesson
  Filename : draft-ietf-pkix-rfc2560bis-03.txt
  Pages : 43
  Date : 2011-04-05

This document specifies a prot= ocol useful in determining the current
status of a digital certificate with= out requiring CRLs.

A URL for this Internet-Draft is:
http://ww= w.ietf.org/internet-drafts/draft-ietf-pkix-rfc2560bis-03.txt

Inte= rnet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/i= nternet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_____________________ next part ______________________

___________________________________________= ____
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailma= n/listinfo/pkix

_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix --B_3384856968_6901625-- From thierry.moreau@connotech.com Tue Apr 5 07:13:59 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D603E28C11D for ; Tue, 5 Apr 2011 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwJgePEK+Cl5 for ; Tue, 5 Apr 2011 07:13:50 -0700 (PDT) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by core3.amsl.com (Postfix) with ESMTP id BC12F28C115 for ; Tue, 5 Apr 2011 07:13:49 -0700 (PDT) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 85E2B302F9; Tue, 5 Apr 2011 15:27:00 -0400 (EDT) Message-ID: <4D9B24E0.6090600@connotech.com> Date: Tue, 05 Apr 2011 10:19:12 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] cert enrollment requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:13:59 -0000 Stephen Kent wrote: > Max, > > I think we (you?) should start to enumerate requirements for this > protocol, based on a set of scenarios. I suggest that we begin with an > outline that enumerates examples of what we MUST support, and then > discusses characteristics that we want from the protocol, and going-in > assumptions about ways to satisfy the requirements and meet the design > goals. > Just to let you glimpse at what the world looks like when PKC capabilities are viewed outside of the PKI straight jacket, here are my quick responses. > What kinds of subjects do we plan to support: people and devices? > Two related things: people authenticated through a device (PKC capable), and devices installed with a human-operator-in-the-loop (provisioning without human witness is not in the present enrollment scope). > Do we require people have crypto tokens, or not? > If we require a token, does the token need to have an embedded > processor, like a smart card? > A local issue. See answer to next question. > What kinds of devices (end systems, network elements, embedded > processors, ...) do we support? > PKC capable in some sense. > How do subjects authenticate to issuers, e.g., PIN/password, device > cert, OTP token, ...? > Enrollment: Step 1: subject submits anonymous contextual information, namely a one-time pass query, protected by an enrollment clearinghouse TA Step 2: subject-related information sent in a secure session where the server authenticity is ascertained in part by the one-time pass query Production: By the subject PKC key pair established during enrollment (ah yes, enrollment did securely establish a secure authentication relationship in addition to just pretend you did) > Will we support only those subjects that connect to an issuer in > realtime or will we support staged delivery as well? > On-line capabilities are quite common these days, aren't they? So, no requirement to limit the number of round-trips in the protocol. Actually enrollment step 1 requires a small number of round-trips. > What cert management functions will we support: cert request, renewal, > rekey, revocation request, ...? > Impulsively, none of those, just enroll your credentials and use them with first party verifier. Actually, I list "PKC enrollment requirements" and not "PKI cert enrollment requirements", and I do list them just as an example of how things may be looked at by taking a broader perspective. > WIll we support only RSA keys for the subject, or will sig-only alg keys > or key-agreement only alg keys be ok too? (Hint: since algorithm agility > is now mandated by the IESG, RSA-only is NOT a viable answer :-).) > The answer is in the question. But it's a fun question anyway. May I suggest that the IESG algorithm agility mandate be fulfilled with agility among RSA and Rabin-Williams? Out of sheer laziness, I'm a bit too ignorant of discrete log / ECC cryptosystem family, and maybe I'm not the only designer with this attitude. > Will we support PoP for subject keys? (again, a trick question :-).) > PoP is achieved with the crypto/protocol potential of combined enrollment steps 1 and 2 above. > Do we assume that the issuer has an X.509 CA cert? > Yes, for issuer authentication during enrollment step 2. But its criticalness is limited to MITM attacks, not the easier phishng/pharming attacks. > This is just a start, but these are the types of questions that need to > be answered if we are to make progress. > Making progress with PKI enrollment without considering bare PKC capabilities first (and foremostly?) appears indeed somehow challenging. > Steve > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From kent@bbn.com Tue Apr 5 08:37:37 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762763A68E8 for ; Tue, 5 Apr 2011 08:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9TsP5DzzUUj for ; Tue, 5 Apr 2011 08:37:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C9B2128C119 for ; Tue, 5 Apr 2011 08:37:31 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49229) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q78La-0000K5-VX; Tue, 05 Apr 2011 11:39:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1B12070B-083A-48F3-9041-C37FEB67695F@carillon.ca> References: <1B12070B-083A-48F3-9041-C37FEB67695F@carillon.ca> Date: Tue, 5 Apr 2011 11:39:11 -0400 To: Patrick Patterson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-910104542==_ma============" Cc: pkix Subject: Re: [pkix] New draft for consideration as a work item. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 15:37:37 -0000 --============_-910104542==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:06 AM -0400 3/31/11, Patrick Patterson wrote: >Hello all: > >A new version of I-D, >draft-patterson-pkix-attribute-signing-eku-00.txt has been >successfully submitted by Patrick Patterson and posted to the IETF >repository. > >Filename: draft-patterson-pkix-attribute-signing-eku >Revision: 00 >Title: attributeSigning extendedKeyUsage value >Creation_date: 2011-03-28 >WG ID: Independent Submission >Number_of_pages: 8 > >Abstract: >This document specifies a value for the extendedKeyUsage X.509 >extension that may be used to create a certificate that would be used >to sign attribute assertions. This allows the differentiation of >certificates used to identify a particular server (which would have a >serverAuth EKU), from the certificate used by that server to sign >attribute assertions, and would easily allow a policy to be developed >for issuance of such a certificate to an identity provider. > > >I would ask that the above be considered as a new work item for this group. > >Thank you. I think you need to cite some examples of how this would be used and why it's important, to motivate this feature. Also, the doc contains the following text: " ... Federation Enabler Certification Authority for issuing certificates to Identity Providers or Attribute Providers in a WS-Fed or SAML federation." This set of terms is not defined anywhere in the doc, nor is there a reference to other docs that would explain them. So a lot more context is needed for me to understand what you're talking about. The Secruity Considerations section should be "TBD" at this stage, if you have nothing concrete to say. "None" is NOT acceptable for this doc :-). Steve --============_-910104542==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] New draft for consideration as a work item.
At 11:06 AM -0400 3/31/11, Patrick Patterson wrote:
Hello all:

A new version of I-D, draft-patterson-pkix-attribute-signing-eku-00.txt has been successfully submitted by Patrick Patterson and posted to the IETF repository.
Filename:       draft-patterson-pkix-attribute-signing-eku
Revision:    00
Title:               attributeSigning extendedKeyUsage value
Creation_date:  2011-03-28
WG ID:               Independent Submission
Number_of_pages: 8

Abstract:
This document specifies a value for the extendedKeyUsage X.509
extension that may be used to create a certificate that would be used
to sign attribute assertions.  This allows the differentiation of
certificates used to identify a particular server (which would have a
serverAuth EKU), from the certificate used by that server to sign
attribute assertions, and would easily allow a policy to be developed
for issuance of such a certificate to an identity provider.


I would ask that the above be considered as a new work item for this group.
Thank you.

I think you need to cite some examples of how this would be used and
why it's important, to motivate this feature.  Also, the doc contains the following text:

" ... Federation Enabler Certification Authority for issuing certificates to  Identity Providers or Attribute Providers in a WS-Fed or SAML federation."

This set of terms is not defined anywhere in the doc, nor is there a reference to other docs that would explain them. So a lot more context is needed for
me to understand what you're talking about.

The Secruity Considerations section should be "TBD" at this stage, if
you have nothing concrete to say.  "None" is NOT acceptable for this doc :-).

Steve
--============_-910104542==_ma============-- From pritikin@cisco.com Tue Apr 5 14:40:06 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFE7628C105 for ; Tue, 5 Apr 2011 14:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjtXkQimkTdD for ; Tue, 5 Apr 2011 14:40:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AAFA328C0EE for ; Tue, 5 Apr 2011 14:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=5207; q=dns/txt; s=iport; t=1302039709; x=1303249309; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tazZmDTlgAtHpna1x1M0AwDWbCnIgd6LAc28OtLiOZg=; b=izev9+lpIIVoXKnISb6h5cbDDR5EhntchF4TabHf3hMbZpmSwArD3NuG 9G7uDyZNHxH92cfh9T1PY5TsXCrvwRmUX2nZ/mxLC5y7KZTaWmjm9RFPY tA1+jb59pMZKvr36DRL1dLfwb1zxLcDzX7Lb2JP1aUcfTO9oeJdYQoVoh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFmMm02rRDoG/2dsb2JhbAClb3eIeZ4ZnB6DHYJPBIVHh16DWw X-IronPort-AV: E=Sophos;i="4.63,307,1299456000"; d="scan'208";a="289986440" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2011 21:41:49 +0000 Received: from [10.101.1.7] ([10.21.74.234]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p35Lfm3Z027104; Tue, 5 Apr 2011 21:41:48 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: Date: Tue, 5 Apr 2011 15:41:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6879CDC0-8B7B-498F-89D7-4615D6A2B79B@cisco.com> References: To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org Subject: Re: [pkix] cert enrollment requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:40:06 -0000 On Apr 4, 2011, at 2:56 PM, Stephen Kent wrote: > Max, >=20 > I think we (you?) should start to enumerate requirements for this = protocol, based on a set of scenarios. I suggest that we begin with an = outline that enumerates examples of what we MUST support, and then = discusses characteristics that we want from the protocol, and going-in = assumptions about ways to satisfy the requirements and meet the design = goals. I'll use these threads and my own ideas to put together a section on = requirements so that folks can provide concrete suggestions against a = formal document.=20 My initial thoughts are inline in response to your excellent questions, > What kinds of subjects do we plan to support: people and devices? Yes. As follows, S1. People - During enrollment authentication/authorization of only the = person is necessary.(Obviously a device is involved for storage and = protocol communication but in this case the user is the authenticated = entity during enrollment and the resulting certificate likely indicates = the user as the subject.=20 S2. Devices - During enrollment device is authenticated/authorized and = the resulting certificate likely indicates the device as the subject.=20 S3. People & Devices - During enrollment both the user and the device = are authenticated/authorized. The server has sufficient information to = indicate within the issued credential a combined subject although = specifications concerning the issued credentials are out of scope. > Do we require people have crypto tokens, or not? > If we require a token, does the token need to have an embedded = processor, like a smart card? We should not require this at all, it is the CA that enforces a policy = decision of this type. We should provide sufficient information to the = enrollment server to allow this form of policy check. For example see S3 = above.=20 > What kinds of devices (end systems, network elements, embedded = processors, ...) do we support? Thierry's response is my first thought: "PKC capable in some sense". A = better question might be to ask if there are any devices we want to = exclude (Answer: no). Thus the value of S1 because it is completely = independent of device authentication/authorization.=20 It is still the server policy responsibility to add additional = restrictions - but that policy is out of scope of the enrollment = protocol itself. > How do subjects authenticate to issuers, e.g., PIN/password, device = cert, OTP token, ...? This closely parallels the question on subjects. We'll need methods that = provide reasonable flexibility for the subjects targeted. As per my = discussions on thread I feel we can limit ourselves to a small set of = very common methods with extensibility for *future* options. I don't = feel we need to invent anything really new. A1. username/password A2. password/PIN (w/o an associated username) A3. existing certificate (device based or other) A4. A combination of A1+A3 or A2+A3. > Will we support only those subjects that connect to an issuer in = realtime or will we support staged delivery as well? Again, I agree with Thierry: Realtime connections are prevalent and we = should focus on them. Existing protocols include more than sufficient = complexities to support staged methods which has impacted their use for = simpler realtime solutions. > What cert management functions will we support: cert request, renewal, = rekey, revocation request, ...? Only the minimal subset necessary to join and maintain the key/certs = necessary for all the other management functions. This is not a trust = anchor management nor ongoing PKI management solution. This is minimum = necessary for=20 M1. Distribution of current CA credentials - necessary as a bootstrap = method and for CA rekey/renew operations (which client needs in order to = successfully renew/rekey itself).=20 M2. Enrollment=20 M3. Renewal/Rekey=20 > WIll we support only RSA keys for the subject, or will sig-only alg = keys or key-agreement only alg keys be ok too? (Hint: since algorithm = agility is now mandated by the IESG, RSA-only is NOT a viable answer = :-).) K1. Algorithm agility in all messages/methods. K2. suite-b compatibility=20 > Will we support PoP for subject keys? (again, a trick question :-).) R1. PoP of subject keys=20 > Do we assume that the issuer has an X.509 CA cert? Yes, but more specifically, I1. Server only has a certificate from a "private" (self-signed) = hierarchy. This is the common case of standing up a PKI by generating a = self-signed certificate.=20 I2. Server also has a certificate from a "common" (mutually trusted) = hierarchy. In addition to being a member and enrollment server for the = private hierarchy the server may also have a certificate issued by a = mutually trusted hierarchy. > This is just a start, but these are the types of questions that need = to be answered if we are to make progress. And as the list develops folks will be able to provide concrete textual = suggestions or comments, - max >=20 > Steve >=20 >=20 From kyanha@kyanha.net Tue Apr 5 19:25:08 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4933A683B for ; Tue, 5 Apr 2011 19:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DOOBLRupUub for ; Tue, 5 Apr 2011 19:25:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 19A303A6839 for ; Tue, 5 Apr 2011 19:25:03 -0700 (PDT) Received: by yxk30 with SMTP id 30so483064yxk.31 for ; Tue, 05 Apr 2011 19:26:47 -0700 (PDT) Received: by 10.91.76.4 with SMTP id d4mr1333023agl.42.1302056807028; Tue, 05 Apr 2011 19:26:47 -0700 (PDT) Received: from [127.0.0.1] (c-71-202-74-146.hsd1.ca.comcast.net [71.202.74.146]) by mx.google.com with ESMTPS id d36sm128054and.30.2011.04.05.19.26.45 (version=SSLv3 cipher=OTHER); Tue, 05 Apr 2011 19:26:46 -0700 (PDT) From: "Kyle Hamilton" To: "Stephen Kent" Date: Tue, 5 Apr 2011 19:26:46 -0700 (Pacific Daylight Time) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.6.2eqgm5n067ms9xeqgvix92 Cc: pkix@ietf.org Subject: Re: [pkix] cert enrollment requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 02:25:08 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.6.2eqgm5n067ms9xeqgvix92 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit My comments inline. On Mon, Apr 4, 2011 at 1:56 PM, Stephen Kent wrote: > > What kinds of subjects do we plan to support: people and devices? People and the property which Persons own. In other words, people and not merely personal-property devices as you're contemplating, but also devices built into real property. > Do we require people have crypto tokens, or not? We require Persons to have their own crypto implementations and containers, but they should not be forced into any particular form factor. These containers must understand the protocols we are creating. We allow for a signature by a token-specific certificate (embedded by its manufacturer) which can certify under what conditions a given key was generated. > If we require a token, does the token need to have an embedded processor, > like a smart card? The container must be able to have its own identity, separate from but subordinate to the Person who owns it. The container also has other attributes which can be attested to independent of its owner's identity. > What kinds of devices (end systems, network elements, embedded processors, > ...) do we support? Everything. We need a means to enroll a key in the PKI of the issuer (which essentially means "add a key record and point it to my master information, using whatever policy and procedure you must"), we need a means to assert under what conditions a key was created, and we need a means to assert what minimum conditions a given issuer requires. Those are the tasks for which we need data formats and semantics. (Since we don't have a workable solution right now, we don't have to worry about interoperability with the numerous proprietary schemes.) > How do subjects authenticate to issuers, e.g., PIN/password, device cert, > OTP token, ...? Device certificate is not used to authenticate a subject to an issuer, it's used to authenticate a device's assertion that it created a key in the manner required. Subjects authenticate to issuers the way subjects authenticate to issuers now. It's the workflow done under that authentication which needs to change. > Will we support only those subjects that connect to an issuer in realtime or > will we support staged delivery as well? Staged delivery would be useful. It would permit the issuer to be a completely separate empire from the customer-interaction team. There is no need for realtime connection, because we're dealing with atoms on the wire -- things which cannot be further broken down without destroying their essential characteristic of verifiability. Thus, we're dealing essentially with "blobs of information which need to move from one place to another". > What cert management functions will we support: cert request, renewal, > rekey, revocation request, ...? enroll, renew, rekey, disenroll We can also support additional cert management functions (like "ensure that the person's really serious about enrolling this key by requiring a signature by the person's enrollment key on top of the person's identity key") if we stop thinking in terms of bits and start thinking in terms of "what information does this entity need? Now, what form do we want to create to get that information to that entity?" > WIll we support only RSA keys for the subject, or will sig-only alg keys or > key-agreement only alg keys be ok too? (Hint: since algorithm agility is now > mandated by the IESG, RSA-only is NOT a viable answer :-).) There is no reason we have to even think about anything other than algorithm-agnosticism, or format-agnosticism. SubjectPublicKeyInfo is a well-defined system, as is Signature. Even if they weren't, OpenPGP has a need to provision keys too, and it is standard enough that it should be contemplated in what we're doing here. There is no reason to include details from one protocol in any other. > Will we support PoP for subject keys? (again, a trick question :-).) Even PKCS#10 supports and mandates Proof of Possession, which moves this out of the realm of 'trick question' and into the realm of 'belabored point'. > Do we assume that the issuer has an X.509 CA cert? There's no need. All we have to do is get the subject's assertions about his key and his authority to request the enrollment of the key to the issuer, and then get the issuer's authentication credentials to the subject, to back up the issuer's assertions about the subject. The real question is: Do we assume that the goal is to provide a PKIX-format-derived certificate to the subject? Or do we assume that the goal is to securely provision a device's enrollment into whatever form of PKI exists for the subject and relying party? Do we assume that the purpose of this kind of protocol is to convey identity information to enroll in a PKI? Or, do we assume that this protocol can be useful for things other than the state identity purpose conceived and standardized (currently in RFC5280) by this group? (This is something of a trick question -- bank account numbers are just as much 'identity' as our legal names are. They differ only because they refer to the records kept about a particular ongoing relationship by a private entity, as opposed to the records kept about a particular life-long relationship by a state entity.) > This is just a start, but these are the types of questions that need to be > answered if we are to make progress. I wholeheartedly agree. Thank you for starting the discussion. -Kyle H --gmsm1.6.2eqgm5n067ms9xeqgvix92 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwNDA2MDIyNjQ2WjAjBgkqhkiG9w0BCQQxFgQULKzXkI4InUAcuk7+oOepFEK5 X78wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAIJVjZP379AoqqvKqV/+41KV9NFRiWQQK7bfrLvNEOhO81WyOloyUFsMt2aS1+ZjultYHcYx l904FZ7qPz4QMcf4awlSocAENjNK63iVqNs6Dl+q6v/HVQ95rt7QGNkbucozBsJ0viY18va9MuK/ ngfdXoAZJAHVTgZK0CLSl/BWvOEIU376K28NLwPd0XuF5XVt6WyLID240HYV3wMhWDlxniTuuatV DTwZQo0L4+jci118ZcdllwbDiErXvnYBenl/Abo+qFTxJ7FFLphszu3q+X9/QIWZchXhMQwFxFGV 6z7Rv3V+hv7IuWstyzj9d86tKxuj9GyozcfZqMLHUWgAAAAAAAA= --gmsm1.6.2eqgm5n067ms9xeqgvix92-- From pgut001@login01.cs.auckland.ac.nz Tue Apr 5 22:32:25 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C4D3A6882 for ; Tue, 5 Apr 2011 22:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwxplpvNCdzp for ; Tue, 5 Apr 2011 22:32:21 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id E33A13A6879 for ; Tue, 5 Apr 2011 22:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302068045; x=1333604045; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20kent@bbn.com,=20pgut001@cs.auckland.ac.nz|Subject: =20Re:=20[pkix]=20IETF=2080:=20The=20future=20of=20PKIX =20certificate=09enrollment=20protocols|Cc:=20pkix@ietf.o rg,=20pritikin@cisco.com|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2006=20Apr=202011 =2017:34:02=20+1200; bh=oG55ZsUXv+aPySAz8A33ogi0fz1goPPNPECxIPAutjY=; b=sX9hlCtigyRIyMEy3gpoyhHWPE3NzJsR0/UoFTRYzLL+rKBqhICF94LN n8nlw2fuUX9h3CVSW9IfsdabFYASlwaFpGI5bR9Ne/4qymmazDh2Bemgg SAnSCfstX5sw5846YSd1tJnqPNzPyV9aiuP4S9Tfrx9n3y8CFE4w9cGBL 4=; X-IronPort-AV: E=Sophos;i="4.63,309,1299409200"; d="scan'208";a="55444059" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Apr 2011 17:34:03 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q7LNS-0002k2-J8; Wed, 06 Apr 2011 17:34:02 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q7LNS-0002oM-Si; Wed, 06 Apr 2011 17:34:02 +1200 From: Peter Gutmann To: kent@bbn.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Wed, 06 Apr 2011 17:34:02 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 05:32:25 -0000 Stephen Kent writes: >Also, -SRP is informational, which would not be an appropriate downref for a >standards track cert management protocol. -PSK is standards-track. >Finally, -SRP seems to focus on one-way (client to server) auth, but cert >enrollment requires 2-way auth. Both -SRP and -PSK provide true mutual auth. In fact they're the only mechanisms in TLS that do. Peter. From pgut001@login01.cs.auckland.ac.nz Tue Apr 5 23:43:12 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B76A28C0D8 for ; Tue, 5 Apr 2011 23:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1umOHE39xS0n for ; Tue, 5 Apr 2011 23:43:11 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 1605928B56A for ; Tue, 5 Apr 2011 23:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302072295; x=1333608295; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20kent@bbn.com|Subject: =20Re:=20[pkix]=20Secure=20Messaging=20in=20PKIX=20enroll ment=20protocols|Cc:=20pkix@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2006 =20Apr=202011=2018:44:51=20+1200; bh=3pLaS7fHVIlc0k/w8ZdfxzubW6tdppYZuMnGd1Xoo9A=; b=QMwxj77Bh0RDrLT6USZLd7Ze8QSsrvnm3pNL2Mtxa+TH4BjcJ+SJ0ENk m9hpLhTCVBwgv/D2svbFqW/AcZ3BZrV1DRMNz0bVrGpt0xY8uGYs6tTJf 1iOxNQ3im3QQGXtgePBpc6JL1FNcubro+LJdAHeU5ByxowJ5Bl6J3RTfi g=; X-IronPort-AV: E=Sophos;i="4.63,309,1299409200"; d="scan'208";a="55451333" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Apr 2011 18:44:52 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q7MTz-00056E-Id; Wed, 06 Apr 2011 18:44:51 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q7MTz-0006Q6-Nt; Wed, 06 Apr 2011 18:44:51 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, kent@bbn.com In-Reply-To: Message-Id: Date: Wed, 06 Apr 2011 18:44:51 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 06:43:12 -0000 Stephen Kent writes: >CMC and CMP were not targeting smart cards. They aren't? Two of my major (known) users of CMP are using it to provision crypto devices. Peter. From pgut001@login01.cs.auckland.ac.nz Tue Apr 5 23:47:21 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD6B3A688C for ; Tue, 5 Apr 2011 23:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeS2-tRAMOOM for ; Tue, 5 Apr 2011 23:47:20 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 86CCA3A68B6 for ; Tue, 5 Apr 2011 23:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302072545; x=1333608545; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pritikin@cisco.com,=20tero.suomela@insta.fi |Subject:=20Re:=20[pkix]=20IETF=2080:=20The=20future=20of =20PKIX=20certificate=20enrollment=09protocols|Cc:=20pkix @ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2006=20Apr=202011=2018: 49:03=20+1200; bh=NYIcPvoW9WkSNo8YRk5IRf7Hrf8NuFwOGQSQYu5kUds=; b=Dy/LZ7cEWIjL04QORN9f38OjYrGmJHlNekkJ0PdKnBdLaMbT0D920B9d 02Eq3qyQDSnJGm/I6UdHwiHQsBDWn96X1+cS4QV3RAeA3qrfySqVdPmuj awf0vZBoQxOMuFYFA3rRcCqUrS1U1igHcNbiitaPf+U1R05U72dtH2gVI E=; X-IronPort-AV: E=Sophos;i="4.63,309,1299409200"; d="scan'208";a="55453160" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Apr 2011 18:49:04 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q7MY3-0005Ib-If; Wed, 06 Apr 2011 18:49:03 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q7MY3-0006Y4-O3; Wed, 06 Apr 2011 18:49:03 +1200 From: Peter Gutmann To: pritikin@cisco.com, tero.suomela@insta.fi In-Reply-To: Message-Id: Date: Wed, 06 Apr 2011 18:49:03 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 06:47:21 -0000 max pritikin writes: >CMP [RFC4210] describes transport as being handled by an external "CMPTrans" Note that in effect "CMP transport" just means "use HTTP", it's about as simple as that. Peter. From pgut001@login01.cs.auckland.ac.nz Tue Apr 5 23:54:20 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651A53A68A7 for ; Tue, 5 Apr 2011 23:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTgr6BRUplFa for ; Tue, 5 Apr 2011 23:54:19 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 5AE913A688C for ; Tue, 5 Apr 2011 23:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302072963; x=1333608963; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20kent@bbn.com,=20pgut001@cs.auckland.ac.nz|Subject: =20Re:=20[pkix]=20fyi:=20Detecting=20Certificate=20Author ity=20compromises=20and=20web=20=09browser=20collusion |Cc:=20mozilla-dev-security-policy@lists.mozilla.org,=20p kix@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2006=20Apr=202011=2018:56:02 =20+1200; bh=hvbr112rvJUPEar+wytE0274h9hXnj7kHneWBgg7JDw=; b=sFE44QxJ8EKHjzsutWBkpIJZ+/eDxBVnb/6B2MUVRWXKOZ1Y8na/ZPet 77RNy2ZUw2qFePtBhUS9DrCgD5pA8jEN8fflX7lwtFRE7g61fChxgAtRn Kh0MjT6r8xjuBnTM0h2eV7arY8wXK9Do9MiednZCZnMcnD+raAcavIFSx o=; X-IronPort-AV: E=Sophos;i="4.63,309,1299409200"; d="scan'208";a="55454921" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Apr 2011 18:56:02 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q7Meo-0005YT-Hj; Wed, 06 Apr 2011 18:56:02 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q7Meo-0006nI-ER; Wed, 06 Apr 2011 18:56:02 +1200 From: Peter Gutmann To: kent@bbn.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Wed, 06 Apr 2011 18:56:02 +1200 Cc: pkix@ietf.org, mozilla-dev-security-policy@lists.mozilla.org Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 06:54:20 -0000 Stephen Kent writes: >I did not get a message of this sort when I connected, but then I did >terminate the home page downloading when it ran on and on and ... What happened when you clicked on Larry? It could have been because the page never finished loading, but all I get is 30K of HTML and 340 kB of images ("viewed page on Microsoft gigabit LAN, couldn't reproduce slow page load problem, resolved wontfix"). Peter. From anders.rundgren@telia.com Wed Apr 6 00:34:16 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A373A68CB for ; Wed, 6 Apr 2011 00:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgC9AxDPT7ke for ; Wed, 6 Apr 2011 00:34:16 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id A44CD3A68BF for ; Wed, 6 Apr 2011 00:34:15 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA01030DBF; Wed, 6 Apr 2011 09:35:51 +0200 Message-ID: <4D9C17DA.3030906@telia.com> Date: Wed, 06 Apr 2011 09:35:54 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 07:34:16 -0000 On 2011-04-06 08:44, Peter Gutmann wrote: > Stephen Kent writes: > >> CMC and CMP were not targeting smart cards. > > They aren't? Two of my major (known) users of CMP are using it to provision > crypto devices. This is where things get confusing since both statements are correct depending on what you actually mean by an "enrollment protocol". Existing PKIX enrollment protocols are indeed used for deploying credentials to smart cards. However, card management systems only use the enrollment protocols for the certificate part which is just one step in a card personalizing process. Things like PIN deployment (in another lingo: setting the user's PIN in the token) is usually dealt with through entirely proprietary methods and software. The (maybe fluffy term) "Secure Messaging" is a way to do *all* card/token operations though a protocol. Secure Message is great but requires very detailed knowledge of the container since *every low-level API method must have a direct counterpart in the protocol*. Due to this I as well as TrustedComputingGroup have found that the only reasonable way to succeed with Secure Messaging is defining a standard token and associated protocols down to the bit-level. IMO, this part is the one which will be the biggest hurdle since a protocol that supports both the the "old" (established) and the "new" (promising) way will make CMP look quite simple :-) Anyway, I haven't heard (it is in fact my line of work..) that card management systems actually *need* a new system while mobile devices and consumer tokens do. Secure Messaging is the way the smart card industry is going. Anders From kyanha@kyanha.net Wed Apr 6 01:04:02 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039AA3A68CC for ; Wed, 6 Apr 2011 01:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAwjTtsBpe-D for ; Wed, 6 Apr 2011 01:04:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 073713A69B0 for ; Wed, 6 Apr 2011 01:04:00 -0700 (PDT) Received: by gxk19 with SMTP id 19so579006gxk.31 for ; Wed, 06 Apr 2011 01:05:44 -0700 (PDT) Received: by 10.150.13.7 with SMTP id 7mr1542837ybm.201.1302077143621; Wed, 06 Apr 2011 01:05:43 -0700 (PDT) Received: from [127.0.0.1] (c-71-202-74-146.hsd1.ca.comcast.net [71.202.74.146]) by mx.google.com with ESMTPS id q29sm231869yba.17.2011.04.06.01.05.41 (version=SSLv3 cipher=OTHER); Wed, 06 Apr 2011 01:05:42 -0700 (PDT) From: "Kyle Hamilton" To: "Anders Rundgren" Date: Wed, 6 Apr 2011 01:05:43 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <4D976594.1000901@telia.com> References: <4D976594.1000901@telia.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.6.2eqgm5z41r1qe04xzfxfa2 Cc: pkix@ietf.org Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:04:02 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.6.2eqgm5z41r1qe04xzfxfa2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 VXNlIFBLSVgtc3RydWN0dXJlZCAodGhvdWdoIG5vdCBjdXJyZW50IFBLSVgtcG9saWN5KSBjZXJ0 aWZpY2F0ZXMgYXMgY29udGFpbmVycyBmb3IgYm90aCAoMSkgdGhlIGlzc3VlcidzIHJlcXVpcmVt ZW50cyBhbmQgZW50cm9weS1wcm92aXNpb24gZm9yIHRoZSBzdXBwbGljYW50J3Mga2V5IGdlbmVy YXRpb24gcHJvY2VzcywgYW5kICgyKSB0aGUgdG9rZW4ncyBhc3NlcnRpb24gb2YgdGhlIGdlbmVy YXRpb24gY2lyY3Vtc3RhbmNlcyBvZiB0aGUga2V5IGluIHRoZSBpbmNsdWRlZCBDU1IsIGluY2x1 ZGluZyBhIGhhc2ggb2YgdGhlIGVudHJvcHkgdGhhdCB0aGUgaXNzdWVyIHByb3ZpZGVkIGFuZCB0 aGUgcHJvdGVjdGlvbiBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHByaXZhdGUga2V5Lg0KDQotS3ls ZSBIDQoNCk9uIFdlZCwgQXByIDYsIDIwMTEgYXQgMTI6MzUgQU0sIEFuZGVycyBSdW5kZ3JlbiA8 YW5kZXJzLnJ1bmRncmVuQHRlbGlhLmNvbT4gd3JvdGU6DQo+IE9uIDIwMTEtMDQtMDYgMDg6NDQs IFBldGVyIEd1dG1hbm4gd3JvdGU6DQo+PiBTdGVwaGVuIEtlbnQgPGtlbnRAYmJuLmNvbT4gd3Jp dGVzOg0KPj4NCj4+PiBDTUMgYW5kIENNUCB3ZXJlIG5vdCB0YXJnZXRpbmcgc21hcnQgY2FyZHMu DQo+Pg0KPj4gVGhleSBhcmVuJ3Q/IKBUd28gb2YgbXkgbWFqb3IgKGtub3duKSB1c2VycyBvZiBD TVAgYXJlIHVzaW5nIGl0IHRvIHByb3Zpc2lvbg0KPj4gY3J5cHRvIGRldmljZXMuDQo+DQo+IFRo aXMgaXMgd2hlcmUgdGhpbmdzIGdldCBjb25mdXNpbmcgc2luY2UgYm90aCBzdGF0ZW1lbnRzIGFy ZSBjb3JyZWN0DQo+IGRlcGVuZGluZyBvbiB3aGF0IHlvdSBhY3R1YWxseSBtZWFuIGJ5IGFuICJl bnJvbGxtZW50IHByb3RvY29sIi4NCj4NCj4gRXhpc3RpbmcgUEtJWCBlbnJvbGxtZW50IHByb3Rv Y29scyBhcmUgaW5kZWVkIHVzZWQgZm9yIGRlcGxveWluZw0KPiBjcmVkZW50aWFscyB0byBzbWFy dCBjYXJkcy4goEhvd2V2ZXIsIGNhcmQgbWFuYWdlbWVudCBzeXN0ZW1zIG9ubHkNCj4gdXNlIHRo ZSBlbnJvbGxtZW50IHByb3RvY29scyBmb3IgdGhlIGNlcnRpZmljYXRlIHBhcnQgd2hpY2ggaXMg anVzdA0KPiBvbmUgc3RlcCBpbiBhIGNhcmQgcGVyc29uYWxpemluZyBwcm9jZXNzLiCgVGhpbmdz IGxpa2UgUElOIGRlcGxveW1lbnQNCj4gKGluIGFub3RoZXIgbGluZ286IHNldHRpbmcgdGhlIHVz ZXIncyBQSU4gaW4gdGhlIHRva2VuKSBpcyB1c3VhbGx5DQo+IGRlYWx0IHdpdGggdGhyb3VnaCBl bnRpcmVseSBwcm9wcmlldGFyeSBtZXRob2RzIGFuZCBzb2Z0d2FyZS4NCj4NCj4gVGhlIChtYXli ZSBmbHVmZnkgdGVybSkgIlNlY3VyZSBNZXNzYWdpbmciIGlzIGEgd2F5IHRvIGRvICphbGwqDQo+ IGNhcmQvdG9rZW4gb3BlcmF0aW9ucyB0aG91Z2ggYSBwcm90b2NvbC4NCj4NCj4gU2VjdXJlIE1l c3NhZ2UgaXMgZ3JlYXQgYnV0IHJlcXVpcmVzIHZlcnkgZGV0YWlsZWQga25vd2xlZGdlDQo+IG9m IHRoZSBjb250YWluZXIgc2luY2UgKmV2ZXJ5IGxvdy1sZXZlbCBBUEkgbWV0aG9kIG11c3QgaGF2 ZSBhDQo+IGRpcmVjdCBjb3VudGVycGFydCBpbiB0aGUgcHJvdG9jb2wqLiCgRHVlIHRvIHRoaXMg SSBhcyB3ZWxsIGFzDQo+IFRydXN0ZWRDb21wdXRpbmdHcm91cCBoYXZlIGZvdW5kIHRoYXQgdGhl IG9ubHkgcmVhc29uYWJsZSB3YXkNCj4gdG8gc3VjY2VlZCB3aXRoIFNlY3VyZSBNZXNzYWdpbmcg aXMgZGVmaW5pbmcgYSBzdGFuZGFyZCB0b2tlbg0KPiBhbmQgYXNzb2NpYXRlZCBwcm90b2NvbHMg ZG93biB0byB0aGUgYml0LWxldmVsLg0KPg0KPiBJTU8sIHRoaXMgcGFydCBpcyB0aGUgb25lIHdo aWNoIHdpbGwgYmUgdGhlIGJpZ2dlc3QgaHVyZGxlDQo+IHNpbmNlIGEgcHJvdG9jb2wgdGhhdCBz dXBwb3J0cyBib3RoIHRoZSB0aGUgIm9sZCIgKGVzdGFibGlzaGVkKQ0KPiBhbmQgdGhlICJuZXci IChwcm9taXNpbmcpIHdheSB3aWxsIG1ha2UgQ01QIGxvb2sgcXVpdGUgc2ltcGxlIDotKQ0KPg0K PiBBbnl3YXksIEkgaGF2ZW4ndCBoZWFyZCAoaXQgaXMgaW4gZmFjdCBteSBsaW5lIG9mIHdvcmsu LikgdGhhdA0KPiBjYXJkIG1hbmFnZW1lbnQgc3lzdGVtcyBhY3R1YWxseSAqbmVlZCogYSBuZXcg c3lzdGVtIHdoaWxlIG1vYmlsZQ0KPiBkZXZpY2VzIGFuZCBjb25zdW1lciB0b2tlbnMgZG8uIKBT ZWN1cmUgTWVzc2FnaW5nIGlzIHRoZSB3YXkgdGhlDQo+IHNtYXJ0IGNhcmQgaW5kdXN0cnkgaXMg Z29pbmcuDQo+DQo+IEFuZGVycw0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBwa2l4IG1haWxpbmcgbGlzdA0KPiBwa2l4QGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeA0KPg0KDQo= --gmsm1.6.2eqgm5z41r1qe04xzfxfa2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTEwNDA2MDgwNTQzWjAjBgkqhkiG9w0BCQQxFgQU5bKVxMxbkfavkImqvLdXjtEs fCAwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAKZiqHr/ym+H9Fz/FtUNP/iecqXn8w1Lo9dS1UoaJjfx234J1boTAIX/Pme6iW7EFWCn1GxF AuJXdsV4DkpXAH01fzJePfidRI2Z9lF61SlCTWc0hNCwk3My0BAGefG1JToIUU9KEgLW/Z8uys1f vzTAsFn1xLa5cBcqEb8U/XS2m8X7P4dn/gh6xCrnOrCPzzoV06Z2LPziouKhP20SXvG0ucoKOlwn MD6w+Z4y/dDz5cRCjwWQwCdazs602M45KKwxa9w/ov7vWpSxYc/KsPjXZuzdep1rYKhWKN1v04iA fTbHgyhkBODvlgku2CRezUlxr8JdoTn3ny/1vow2sCYAAAAAAAA= --gmsm1.6.2eqgm5z41r1qe04xzfxfa2-- From roberto@opazo.cl Wed Apr 6 06:45:51 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3C93A6938 for ; Wed, 6 Apr 2011 06:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5gPk2KuwH91 for ; Wed, 6 Apr 2011 06:45:51 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C81E93A67B2 for ; Wed, 6 Apr 2011 06:45:49 -0700 (PDT) Received: by wyb29 with SMTP id 29so1449880wyb.31 for ; Wed, 06 Apr 2011 06:47:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.241.66 with SMTP id f44mr1085076wer.37.1302097653187; Wed, 06 Apr 2011 06:47:33 -0700 (PDT) Received: by 10.216.47.82 with HTTP; Wed, 6 Apr 2011 06:47:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2011 10:47:33 -0300 Message-ID: From: Roberto Opazo To: IETF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Is there a SW standard to validate private key protection? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:45:51 -0000 Ok, but I didn=B4t say the system is untrusted. Let=92s say I trust in my PC OS. There are some users and programs that can use my PC, buy they don=92t have administrative permissions. So, are the following scenarios equivalents? 1.- I save my private key in plane in a public text file. 2.- I save my private key encrypted with a password (using AES) in a text f= ile. 3.- Same than 2, but the file can only be used for a system CryptoAPI that serves cryptographic requirements to applications. 4.- Same than 3, but there are no interfaces to export the private key. 5.- Same than 4, but there are no interfaces to import the private key, so the private key MUST be created by a Cryptographic Service Provider that connect the file with CryptoAPI. Maybe there are no standards to distinguish these scenarios, but, do you really think they are equivalent in terms of security? Best regards, Roberto Opazo 2011/3/10 Miller, Timothy J. : > On Mar 10, 2011, at 1:52 PM, Roberto Opazo wrote: > >> Is there a SW standard to validate private key protection? > > There's no *software-only* way to protect a private key on an *untrusted,= untrustable, general purpose computer*. =A0 Once the key's in memory it's = fair game to anything with the access rights. > > -- Tim > > > --=20 Saludos, Roberto Opazo From Internet-Drafts@ietf.org Wed Apr 6 07:15:02 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D90828C0EB; Wed, 6 Apr 2011 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE+Pb96niE9Y; Wed, 6 Apr 2011 07:15:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE22C28C0D7; Wed, 6 Apr 2011 07:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110406141501.7464.48443.idtracker@localhost> Date: Wed, 06 Apr 2011 07:15:01 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action:draft-ietf-pkix-rfc5272-bis-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:15:02 -0000 --NextPart 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 : Certificate Management over CMS (CMC) Updates Author(s) : J. Schaad Filename : draft-ietf-pkix-rfc5272-bis-03.txt Pages : 39 Date : 2011-04-06 This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273 and RFC 5274. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc5272-bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-rfc5272-bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-06070405.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Apr 6 07:15:02 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB1528C0E6; Wed, 6 Apr 2011 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4qg+6HpOp8V; Wed, 6 Apr 2011 07:15:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0ACA28C0E4; Wed, 6 Apr 2011 07:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110406141501.7464.11778.idtracker@localhost> Date: Wed, 06 Apr 2011 07:15:01 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action:draft-ietf-pkix-pubkey-caps-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:15:02 -0000 --NextPart 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) : J. Schaad Filename : draft-ietf-pkix-pubkey-caps-02.txt Pages : 21 Date : 2011-04-06 This document defines a set of S/MIME Capability types for ASN.1 encoding for the current set of public keys define in 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 with the OCSP Agility draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-pubkey-caps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-06070415.I-D@ietf.org> --NextPart-- From kent@bbn.com Wed Apr 6 08:29:35 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795933A67FB for ; Wed, 6 Apr 2011 08:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdlKc6SyOVF1 for ; Wed, 6 Apr 2011 08:29:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C66A53A67E7 for ; Wed, 6 Apr 2011 08:29:34 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49168) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7UhR-000IZ5-AQ; Wed, 06 Apr 2011 11:31:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 6 Apr 2011 11:10:51 -0400 To: Peter Gutmann From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:29:35 -0000 At 6:44 PM +1200 4/6/11, Peter Gutmann wrote: >Stephen Kent writes: > >>CMC and CMP were not targeting smart cards. > >They aren't? Two of my major (known) users of CMP are using it to provision >crypto devices. > >Peter. the fact that these protocols are useable with smart cards, today, does not contradict my comment. When these protocols were developed (2000) smart cards were pretty wimpy in terms of processor and memory capabilities. We did not try to create protocols, or profiles thereof, that were likely to be easy to implement in such constrained environments. Steve From kent@bbn.com Wed Apr 6 08:29:36 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A4B128C143 for ; Wed, 6 Apr 2011 08:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1yrD9bZcSKB for ; Wed, 6 Apr 2011 08:29:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 003B928C0F1 for ; Wed, 6 Apr 2011 08:29:35 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49168) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7UhT-000IZ5-N2; Wed, 06 Apr 2011 11:31:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6879CDC0-8B7B-498F-89D7-4615D6A2B79B@cisco.com> References: <6879CDC0-8B7B-498F-89D7-4615D6A2B79B@cisco.com> Date: Wed, 6 Apr 2011 11:16:43 -0400 To: max pritikin From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] cert enrollment requirements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:29:36 -0000 At 3:41 PM -0600 4/5/11, max pritikin wrote: >... >I'll use these threads and my own ideas to put together a section on >requirements so that folks can provide concrete suggestions against >a formal document. great, and I think your set of answers is a good start for a requirements doc discussion. Steve From anders.rundgren@telia.com Wed Apr 6 08:44:28 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9413028C11B for ; Wed, 6 Apr 2011 08:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdCqFAZwiMq2 for ; Wed, 6 Apr 2011 08:44:27 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id E6E6028C11A for ; Wed, 6 Apr 2011 08:44:26 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA01076BFD for pkix@ietf.org; Wed, 6 Apr 2011 17:46:09 +0200 Message-ID: <4D9C8AC5.7060405@telia.com> Date: Wed, 06 Apr 2011 17:46:13 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pkix@ietf.org References: <6879CDC0-8B7B-498F-89D7-4615D6A2B79B@cisco.com> In-Reply-To: <6879CDC0-8B7B-498F-89D7-4615D6A2B79B@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Cert Enroll Requirements: PoP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:44:28 -0000 If any meaningful exchange of ideas is to be performed on the list it may be useful separating [hopefully] independent issues. Here is such a topic. In TPMs (Trusted Platform Modules) as well as when using that fluffy term "Secure Messaging" (ISO GP SKS), self-signed requests are either not not used at all or play a less significant role, because it is rather the (trusted/trustworthy) *container* that vouches for the authenticity of container-generated public keys. The value of the traditional PoP in a scenario where the issuer has no control, knowledge, or interaction with the crypto container seems a bit exaggerated since anybody can create a key-pair. In the case the issuer has full control PoP appears slightly redundant. Even if you know (how?) that the client has a trustworthy container, PoP does not add much to verify that. The potential PKIX effort is of course free to support whatever "PoP" method you like, just beware of the fact that they are very different with Secure Messaging as the extreme... Anders From kent@bbn.com Wed Apr 6 08:55:30 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87E2D3A69C2 for ; Wed, 6 Apr 2011 08:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-ITeJTA8yHp for ; Wed, 6 Apr 2011 08:55:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A09E73A6874 for ; Wed, 6 Apr 2011 08:55:29 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49168) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7UhZ-000IZ5-H0; Wed, 06 Apr 2011 11:31:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 6 Apr 2011 11:22:51 -0400 To: Peter Gutmann From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:55:30 -0000 At 5:34 PM +1200 4/6/11, Peter Gutmann wrote: >Stephen Kent writes: > >>Also, -SRP is informational, which would not be an appropriate downref for a >>standards track cert management protocol. > >-PSK is standards-track. I didn't say otherwise. > >>Finally, -SRP seems to focus on one-way (client to server) auth, but cert >>enrollment requires 2-way auth. > >Both -SRP and -PSK provide true mutual auth. In fact they're the only >mechanisms in TLS that do. pre-shared keys/passwords do not scale well, and thus are a questionable basis for other than trivial deployment contexts. I don't consider either to be a viable basis for what Max is proposing, for that reason. Steve From paul.hoffman@vpnc.org Wed Apr 6 10:01:54 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37EE3A68CE for ; Wed, 6 Apr 2011 10:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.101 X-Spam-Level: X-Spam-Status: No, score=-102.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 094pRyLKG891 for ; Wed, 6 Apr 2011 10:01:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 771E33A68A9 for ; Wed, 6 Apr 2011 10:01:53 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p36H2Qd1019298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Apr 2011 10:02:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 6 Apr 2011 10:02:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:01:54 -0000 On Apr 6, 2011, at 8:22 AM, Stephen Kent wrote: > At 5:34 PM +1200 4/6/11, Peter Gutmann wrote: >> Stephen Kent writes: >>=20 >>> Also, -SRP is informational, which would not be an appropriate = downref for a >>> standards track cert management protocol. >>=20 >> -PSK is standards-track. >=20 > I didn't say otherwise. >=20 >>=20 >>> Finally, -SRP seems to focus on one-way (client to server) auth, but = cert >>> enrollment requires 2-way auth. >>=20 >> Both -SRP and -PSK provide true mutual auth. In fact they're the = only >> mechanisms in TLS that do. >=20 > pre-shared keys/passwords do not scale well, and thus are a = questionable basis for other than trivial deployment contexts. I don't = consider either to be a > viable basis for what Max is proposing, for that reason. While the "do not scale well" part is true for some scenarios, it is not = necessarily correct for enrollment of machine certs. That is, it is = perfectly reasonable to have a long preshared key printed on the label = on the bottom of the bottom of a hardware system and use that as the = preshared key. This scales just fine for certs that will be issued by = the hardware manufacturer. --Paul Hoffman From kent@bbn.com Wed Apr 6 10:50:37 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83E428C106 for ; Wed, 6 Apr 2011 10:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO-3VFNqnY+T for ; Wed, 6 Apr 2011 10:50:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0D8D728C0D6 for ; Wed, 6 Apr 2011 10:50:37 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49174) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7Wtw-000GCe-VT; Wed, 06 Apr 2011 13:52:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D9C8AC5.7060405@telia.com> References: <6879CDC0-8B7B-498F-89D7-4615D6A2B79B@cisco.com> <4D9C8AC5.7060405@telia.com> Date: Wed, 6 Apr 2011 13:30:27 -0400 To: Anders Rundgren From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Cert Enroll Requirements: PoP X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:50:37 -0000 At 5:46 PM +0200 4/6/11, Anders Rundgren wrote: >If any meaningful exchange of ideas is to be performed on the >list it may be useful separating [hopefully] independent issues. > >Here is such a topic. > >In TPMs (Trusted Platform Modules) as well as when using that >fluffy term "Secure Messaging" (ISO GP SKS), self-signed requests >are either not not used at all or play a less significant role, >because it is rather the (trusted/trustworthy) *container* that >vouches for the authenticity of container-generated public keys. OK, but that is at most one scenario of what is to be supported. >The value of the traditional PoP in a scenario where the issuer >has no control, knowledge, or interaction with the crypto container >seems a bit exaggerated since anybody can create a key-pair. the rationale for PoP is to establish that the requester of a cert holds the private key corresponding to the public key in the cert. > In the >case the issuer has full control Since the issuer is generally not the same entity as the creator of the "container," PoP still makes sense. In fact, because the container is not perfectly secure, if the interactions takes place as a distance, the issuer can't be sure that the request has not been fabricated by a tampered container, so PoP makes sense even in that case. > PoP appears slightly redundant. >Even if you know (how?) that the client has a trustworthy container, >PoP does not add much to verify that. PoP does what I mentioned earlier, i.e., it counters requests that attempt to associate someone else's public key with an identity not selected by the holder of the private key. Steve From kent@bbn.com Wed Apr 6 10:50:39 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54B028C110 for ; Wed, 6 Apr 2011 10:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWCYvSSugq4B for ; Wed, 6 Apr 2011 10:50:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1C11428C107 for ; Wed, 6 Apr 2011 10:50:39 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49174) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7Wty-000GCe-LW; Wed, 06 Apr 2011 13:52:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> Date: Wed, 6 Apr 2011 13:40:13 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:50:39 -0000 At 10:02 AM -0700 4/6/11, Paul Hoffman wrote: >... > > >> pre-shared keys/passwords do not scale well, and thus are a >>questionable basis for other than trivial deployment contexts. I >>don't consider either to be a >> viable basis for what Max is proposing, for that reason. > >While the "do not scale well" part is true for some scenarios, it is >not necessarily correct for enrollment of machine certs. That is, it >is perfectly reasonable to have a long preshared key printed on the >label on the bottom of the bottom of a hardware system and use that >as the preshared key. This scales just fine for certs that will be >issued by the hardware manufacturer. My perception is that certs that are provisioned by a manufacturer are generated and installed prior to shipping a product, not when the product is deployed at a customer's site. Are you discussing manufacture-time provisioning? Another issue is that if we say that we plan to support a broad range of scenarios, as Max did, then it is inappropriate to rely on pre-shared keys for TLS as a base for the protocol. Yes, they may be appropriate for some, limited contexts, but not overall. So, we might have to specify a range of context assumptions and matching TLS key management capabilities, and hope that folks can pair these appropriately. That is doable, but it may not be preferable, since we all know how well users follow such guidance :-). Steve From anders.rundgren@telia.com Wed Apr 6 10:55:00 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3D6E28C0D6 for ; Wed, 6 Apr 2011 10:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47gq0x-PTp5r for ; Wed, 6 Apr 2011 10:55:00 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by core3.amsl.com (Postfix) with ESMTP id 84F6728C106 for ; Wed, 6 Apr 2011 10:54:59 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D65154400CA2F70 for pkix@ietf.org; Wed, 6 Apr 2011 19:56:42 +0200 Message-ID: <4D9CA95E.6050207@telia.com> Date: Wed, 06 Apr 2011 19:56:46 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pkix@ietf.org References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> In-Reply-To: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Using SRP. Was: IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:55:00 -0000 On 2011-04-06 19:02, Paul Hoffman wrote: > On Apr 6, 2011, at 8:22 AM, Stephen Kent wrote: >> >> pre-shared keys/passwords do not scale well, and thus are >> a questionable basis for other than trivial deployment contexts. >> I don't consider either to be a viable basis for what >> Max is proposing, for that reason. > > > While the "do not scale well" part is true for some scenarios, > it is not necessarily correct for enrollment of machine certs. > That is, it is perfectly reasonable to have a long preshared > key printed on the label on the bottom of the bottom of a > hardware system and use that as the preshared key. This scales > just fine for certs that will be issued by the hardware manufacturer. For hardware systems there is no need for such measures. Certificates are deployed as an integral part of the [secure] production process. Anders From paul.hoffman@vpnc.org Wed Apr 6 11:36:50 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C976E28C0DE for ; Wed, 6 Apr 2011 11:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPcxH9G0kc6X for ; Wed, 6 Apr 2011 11:36:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id CBF5628C0D6 for ; Wed, 6 Apr 2011 11:36:49 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p36IbnnN023766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Apr 2011 11:37:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 6 Apr 2011 11:37:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 18:36:51 -0000 On Apr 6, 2011, at 10:40 AM, Stephen Kent wrote: > At 10:02 AM -0700 4/6/11, Paul Hoffman wrote: >> ... >> > >>> pre-shared keys/passwords do not scale well, and thus are a = questionable basis for other than trivial deployment contexts. I don't = consider either to be a >>> viable basis for what Max is proposing, for that reason. >>=20 >> While the "do not scale well" part is true for some scenarios, it is = not necessarily correct for enrollment of machine certs. That is, it is = perfectly reasonable to have a long preshared key printed on the label = on the bottom of the bottom of a hardware system and use that as the = preshared key. This scales just fine for certs that will be issued by = the hardware manufacturer. >=20 > My perception is that certs that are provisioned by a manufacturer are = generated > and installed prior to shipping a product, not when the product is = deployed > at a customer's site. Are you discussing manufacture-time = provisioning? I am discussing different deployment options for different = manufacturers, not a one-size-must-fit-all limitation. > Another issue is that if we say that we plan to support a broad range = of scenarios, as Max did, then it is inappropriate to rely on pre-shared = keys for TLS as a base for the protocol. Yes, they may be appropriate = for some, limited > contexts, but not overall. So, we might have to specify a range of = context assumptions and matching TLS key management capabilities, and = hope that folks > can pair these appropriately. That is doable, but it may not be = preferable, > since we all know how well users follow such guidance :-). If your concern is scalability, then it should be completely up to the = CA to measure that. If your concern is security of the enrollment = messages, then clearly listing the concerns and specifying how to make = preshared secrets strong enough is both easy and sufficient. --Paul Hoffman From anders.rundgren@telia.com Wed Apr 6 12:02:31 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3953A697A for ; Wed, 6 Apr 2011 12:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyTREc7O5NR9 for ; Wed, 6 Apr 2011 12:02:30 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by core3.amsl.com (Postfix) with ESMTP id B78DB3A67B6 for ; Wed, 6 Apr 2011 12:02:30 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A10109F572 for pkix@ietf.org; Wed, 6 Apr 2011 21:04:13 +0200 Message-ID: <4D9CB931.3070006@telia.com> Date: Wed, 06 Apr 2011 21:04:17 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Recent Microsoft enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 19:02:31 -0000 http://channel9.msdn.com/posts/Certificate-Enrollment-Concepts-and-Protocols-2010 Web Services (XML) encapsulating (among many things) PKIX structures. Anders From pritikin@cisco.com Wed Apr 6 14:02:31 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC63E28C0DE for ; Wed, 6 Apr 2011 14:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.136 X-Spam-Level: X-Spam-Status: No, score=-7.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqb53HEjOSUT for ; Wed, 6 Apr 2011 14:02:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id ECBA73A67C2 for ; Wed, 6 Apr 2011 14:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2906; q=dns/txt; s=iport; t=1302123855; x=1303333455; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=bRwyrJz30Pq/FndKaWoCcCOu7A015DD9zSlfFjKycOg=; b=H218dj8CUATPp7GKSLUvh5bDzEN/yNIZyI9rybeObdI9h4VE7Z+r8r7v +qiuYzCjVWEGQ9bjAASeFAPapU03U8xwAxm29ddrKqInJy6YSl2h0bWxF CITzUOGBxIrcz/yKnCv4iahSprk/YuKQBGQCBZbmRP9ZJlH6ug6OsDTLg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAJnUnE2rRDoI/2dsb2JhbAClFmcCd4h5niecTYJ+H4JPBIVOh26DaYVh X-IronPort-AV: E=Sophos;i="4.63,312,1299456000"; d="scan'208";a="290787772" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2011 21:04:15 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p36L4EXw006529; Wed, 6 Apr 2011 21:04:14 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 14:04:14 -0700 Received: from 128.107.191.32 ([128.107.191.32]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Apr 2011 21:04:13 +0000 References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> Content-Transfer-Encoding: quoted-printable Thread-Topic: [pkix] IETF 80: The future of PKIX certificate enrollmentprotocols Thread-Index: Acv0ni5x1i+iaSN2RQGDgDqeYlitag== From: "Max Pritikin (pritikin)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> Message-ID: Date: Wed, 6 Apr 2011 15:04:06 -0600 To: "Paul Hoffman" MIME-Version: 1.0 (iPhone Mail 8C148a) X-OriginalArrivalTime: 06 Apr 2011 21:04:14.0594 (UTC) FILETIME=[2F4F7E20:01CBF49E] Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollmentprotocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:02:32 -0000 A manufacturer with a sufficiently secure implementation of manufacturing in= stalled certificates is selling a product that can be easier and/or more sec= ure to deploy. The CA can verify device identity in addition to (2 factor) o= r even instead of user identity. The purchased HW provides value (if the CA w= ishes to leverage it).=20 As always the CA may require a preshared secret or other password based mech= anism to be used. The security concerns for the out-of-band distribution of t= hat key material are entirely handled by the customer.=20 These are captured in the Authorization 1-3 requirements I outlined in the o= ther thread.=20 - max On Apr 6, 2011, at 12:38 PM, "Paul Hoffman" wrote: > On Apr 6, 2011, at 10:40 AM, Stephen Kent wrote: >=20 >> At 10:02 AM -0700 4/6/11, Paul Hoffman wrote: >>> ... >>>>=20 >>>> pre-shared keys/passwords do not scale well, and thus are a questionabl= e basis for other than trivial deployment contexts. I don't consider either t= o be a >>>> viable basis for what Max is proposing, for that reason. >>>=20 >>> While the "do not scale well" part is true for some scenarios, it is not= necessarily correct for enrollment of machine certs. That is, it is perfect= ly reasonable to have a long preshared key printed on the label on the botto= m of the bottom of a hardware system and use that as the preshared key. This= scales just fine for certs that will be issued by the hardware manufacturer= . >>=20 >> My perception is that certs that are provisioned by a manufacturer are ge= nerated >> and installed prior to shipping a product, not when the product is deploy= ed >> at a customer's site. Are you discussing manufacture-time provisioning? >=20 > I am discussing different deployment options for different manufacturers, n= ot a one-size-must-fit-all limitation. >=20 >> Another issue is that if we say that we plan to support a broad range of s= cenarios, as Max did, then it is inappropriate to rely on pre-shared keys fo= r TLS as a base for the protocol. Yes, they may be appropriate for some, lim= ited >> contexts, but not overall. So, we might have to specify a range of contex= t assumptions and matching TLS key management capabilities, and hope that fo= lks >> can pair these appropriately. That is doable, but it may not be preferab= le, >> since we all know how well users follow such guidance :-). >=20 > If your concern is scalability, then it should be completely up to the CA t= o measure that. If your concern is security of the enrollment messages, then= clearly listing the concerns and specifying how to make preshared secrets s= trong enough is both easy and sufficient. >=20 > --Paul Hoffman >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From hotz@jpl.nasa.gov Wed Apr 6 14:03:19 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7257028C0DE; Wed, 6 Apr 2011 14:03:19 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qstllsd083b4; Wed, 6 Apr 2011 14:03:18 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id 750413A67C3; Wed, 6 Apr 2011 14:03:18 -0700 (PDT) Received: from dhcp-137-79-176-182.jpl.nasa.gov (dhcp-137-79-176-182.jpl.nasa.gov [137.79.176.182]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p36L50NG027499 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 6 Apr 2011 14:05:01 -0700 From: "Henry B. Hotz" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2011 14:05:00 -0700 References: <20110406204159.E04043A69B9@core3.amsl.com> To: saag@ietf.org, "ietf-krb-wg@anl.gov Group" , pkix PKIX Message-Id: <7D21A6AA-04C3-4A2B-9424-22F9FD2231D4@jpl.nasa.gov> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Source-IP: dhcp-137-79-176-182.jpl.nasa.gov [137.79.176.182] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Subject: [pkix] Fwd: New Version Notification for draft-hotz-kx509-02 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:03:20 -0000 This is an individual submission, but I'm treating this as a "last call" = for comments before I forward it up the chain. I think I've addressed = all the issues I can without making it incompatible with the deployed = base. The remaining issues are in Appendix C. (Yes, I intend to start = work on an incompatible upgrade once this draft has gotten published.) Changes from the Previous Draft: 1. The retry behavior was made slightly less specific. 2. The traditionally used SAN extensions were moved to a new appendix, = leaving only the id-pkinit-san as the RECOMMENDED SAN. 3. The absolute prohibition against digital signatures in the Security = Considerations section was relaxed since there are legitimate situations = where a signature based on the KX509 certificate is still useful. (E.g. integrity protection where the = actual signing identity is not important.) 4. Reference to TAGPMA in the abstract was replaced with a reference to = its parent, the International Grid Trust Federation, and more detailed = informative references were expanded in the Introduction. 5. Assorted other wording changes were made for clarity, but are not = believed to have changed the meaning. Begin forwarded message: > From: IETF I-D Submission Tool > Date: April 6, 2011 1:41:59 PM PDT > To: "Hotz, Henry B (173H)" > Subject: New Version Notification for draft-hotz-kx509-02=20 >=20 >=20 > A new version of I-D, draft-hotz-kx509-02.txt has been successfully = submitted by Henry Hotz and posted to the IETF repository. >=20 > Filename: draft-hotz-kx509 > Revision: 02 > Title: KX509 Kerberized Certificate Issuance Protocol > Creation_date: 2011-04-06 > WG ID: Independent Submission > Number_of_pages: 11 >=20 > Abstract: > This rfc describes a protocol, called kx509, for using Kerberos > tickets to acquire X.509 certificates. >=20 > While not (previously) standardized, this protocol is already in use > at several large organizations, and certificates issued with this > protocol are recognized by the International Grid Trust Federation. >=20 >=20 >=20 > The IETF Secretariat. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From anders.rundgren@telia.com Wed Apr 6 14:17:17 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E453A69B9 for ; Wed, 6 Apr 2011 14:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zmI57fPhksR for ; Wed, 6 Apr 2011 14:17:17 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by core3.amsl.com (Postfix) with ESMTP id 61A493A6956 for ; Wed, 6 Apr 2011 14:17:17 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A1010AC857 for pkix@ietf.org; Wed, 6 Apr 2011 23:19:00 +0200 Message-ID: <4D9CD8C8.9060908@telia.com> Date: Wed, 06 Apr 2011 23:19:04 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Cert Enroll Requirement: Browser integration X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:17:18 -0000 This is probably the biggest problem of all. Being a dare-devil (in this context NB...) I therefore put a "Yes, of course" in my take on this subject :-) From pritikin@cisco.com Wed Apr 6 14:41:49 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99083A67E3 for ; Wed, 6 Apr 2011 14:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.136 X-Spam-Level: X-Spam-Status: No, score=-7.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us0Plnwih-9r for ; Wed, 6 Apr 2011 14:41:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1DDCC3A67DB for ; Wed, 6 Apr 2011 14:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=888; q=dns/txt; s=iport; t=1302126213; x=1303335813; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=X0i2oFhnAgPtO9eknwVQ+OQOFd/mWEh5UOni/EJ0biU=; b=ie4h02T4Uaq0Wa0eFMB+6B75HrSKyNOZ0iMu0I8Qh+eBxWTU9JCt/C1D 5W6LwwPALo5RAMg2YGdtgwoVydElyquQF0B1WVOlQPxnVjqAtAsde8x7O pkUXQaQ5WkQ3ClXMQwLA+fKpivL/zdPntHOa6kQf7HCZVnQtUHpyfD47m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFADnenE2rRDoG/2dsb2JhbAClFmcCd4h5nhucX4VsBIVOh26DaYVh X-IronPort-AV: E=Sophos;i="4.63,312,1299456000"; d="scan'208";a="425170031" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 06 Apr 2011 21:43:33 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p36LhXue018367; Wed, 6 Apr 2011 21:43:33 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 14:43:33 -0700 Received: from 128.107.191.114 ([128.107.191.114]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Wed, 6 Apr 2011 21:43:32 +0000 References: <4D9CD8C8.9060908@telia.com> Content-Transfer-Encoding: quoted-printable Thread-Topic: [pkix] Cert Enroll Requirement: Browser integration Thread-Index: Acv0o6xb6PkQIMF9TTa1reT5GAeJMQ== From: "Max Pritikin (pritikin)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4D9CD8C8.9060908@telia.com> Message-ID: Date: Wed, 6 Apr 2011 15:43:27 -0600 To: "Anders Rundgren" MIME-Version: 1.0 (iPhone Mail 8C148a) X-OriginalArrivalTime: 06 Apr 2011 21:43:33.0113 (UTC) FILETIME=[AD18EE90:01CBF4A3] Cc: pkix@ietf.org Subject: Re: [pkix] Cert Enroll Requirement: Browser integration X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:41:50 -0000 We want the protocol to be reasonable to implement by a lot of clients - bro= wsers included.=20 As such building on the protocol stack specified in the EST draft is my reco= mmendation. A specific point is the text about server authentication with sp= ecifically calls put the browser/www authentication model (checking the subj= ectname as specified by a 3rd part certificate).=20 See requirement I2 in the other thread. (yes, these will be in the next draf= t).=20 - max On Apr 6, 2011, at 3:19 PM, "Anders Rundgren" wr= ote: > This is probably the biggest problem of all. >=20 > Being a dare-devil (in this context NB...) I therefore put a "Yes, of cour= se" in my take on this subject :-) >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Wed Apr 6 14:43:12 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2693A67DB for ; Wed, 6 Apr 2011 14:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN70dpylsKaM for ; Wed, 6 Apr 2011 14:43:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 24C353A6956 for ; Wed, 6 Apr 2011 14:43:12 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49181) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7aX1-000PWr-Qu; Wed, 06 Apr 2011 17:44:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> Date: Wed, 6 Apr 2011 17:28:02 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:43:12 -0000 At 11:37 AM -0700 4/6/11, Paul Hoffman wrote: >O... > >I am discussing different deployment options for different >manufacturers, not a one-size-must-fit-all limitation. I was worried that we might say that TLS cert processing concerns would be avoided by using SRP/PSK, and thus TLS is OK for all cases. if your comment was meant to convey the notion that SRP/PSK is OK for some environments, no problem. > > Another issue is that if we say that we plan to support a broad >range of scenarios, as Max did, then it is inappropriate to rely on >pre-shared keys for TLS as a base for the protocol. Yes, they may be >appropriate for some, limited >> contexts, but not overall. So, we might have to specify a range of >>context assumptions and matching TLS key management capabilities, >>and hope that folks >> can pair these appropriately. That is doable, but it may not be preferable, >> since we all know how well users follow such guidance :-). > >If your concern is scalability, then it should be completely up to >the CA to measure that. If your concern is security of the >enrollment messages, then clearly listing the concerns and >specifying how to make preshared secrets strong enough is both easy >and sufficient. I don't understand these last 2 comments. We're developing a standard. We need to specify the scope for which the standard is applicable. So far the suggestions of scope are not restricting this standard to only those contexts where SRP/PSK is viable, because scaling is not an issue. I don't think that it's reasonable to suggest that we can make pre-shared secrets "strong enough" for all of the contexts that have been proposed. Does that explanation help clarify my concerns? Steve From pgut001@login01.cs.auckland.ac.nz Wed Apr 6 20:56:41 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CD23A69A4 for ; Wed, 6 Apr 2011 20:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.57 X-Spam-Level: X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbooxFE6BgJK for ; Wed, 6 Apr 2011 20:56:38 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id BD94D3A6985 for ; Wed, 6 Apr 2011 20:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302148703; x=1333684703; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20kent@bbn.com,=20paul.hoffman@vpnc.org|Subject:=20R e:=20[pkix]=20IETF=2080:=20The=20future=20of=20PKIX=20cer tificate=09enrollment=20protocols|Cc:=20pkix@ietf.org |In-Reply-To:=20<6BF6B382-E775-4455-9141-2E6E0EF315B2@vpn c.org>|Message-Id:=20|Date:=20Thu,=2007=20Apr=202011=2015:58:21=20+1 200; bh=eFWPg6j7dKrlYaDk8VwSQggmLTYoEUDUDakYTWndpVo=; b=mN5OJHBfKuqjW0z7266iSAjYRByAMN2MTG+WWdZ+C9lTHdbGPMEQIsIM McKYYWpLsTsVzItSWtkgK00CkyufDeGdBJM4zTQxdSU1ouHt4YPCdmznp 8U6wHRW+U5IHTkZE3HS0Z+qji8163QliWnnDKcfO7pYZSaKPajZm3Xrsf I=; X-IronPort-AV: E=Sophos;i="4.63,314,1299409200"; d="scan'208";a="55645881" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Apr 2011 15:58:22 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q7gMP-00070y-IC; Thu, 07 Apr 2011 15:58:21 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q7gMP-0001fz-Hd; Thu, 07 Apr 2011 15:58:21 +1200 From: Peter Gutmann To: kent@bbn.com, paul.hoffman@vpnc.org In-Reply-To: <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> Message-Id: Date: Thu, 07 Apr 2011 15:58:21 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 03:56:42 -0000 Stephen Kent writes: > pre-shared keys/passwords do not scale well, "... and we'll keep asserting this until you cry Uncle, dammit!". PSKs/passwords are the basis of the most complex, scalable systems ever designed. Just one of these, Facebook, has half a billion users using non- scalable PSKs, and exactly zero using scalable PKI. Gmail, Yahoo, Youtube, Flickr, all of these operate on a planetary scale using non-scalable PSKs. So could I make the following modest suggestion, whenever someone wants to say "PSKs don't scale", could they either qualify it with "... beyond planetary scale" or alternatively "... and I'll keep asserting this while saying LALALALALAI'MNOTLISTENING until you go away". Thanks, Peter. From anders.rundgren@telia.com Wed Apr 6 21:10:03 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07AC228C0CF for ; Wed, 6 Apr 2011 21:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGuETuy9VN8f for ; Wed, 6 Apr 2011 21:10:02 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id BED1928C0D9 for ; Wed, 6 Apr 2011 21:10:01 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA0109F55C; Thu, 7 Apr 2011 06:11:43 +0200 Message-ID: <4D9D3983.2040400@telia.com> Date: Thu, 07 Apr 2011 06:11:47 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Max Pritikin (pritikin)" References: <4D9CD8C8.9060908@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Cert Enroll Requirement: Browser integration X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 04:10:03 -0000 On 2011-04-06 23:43, Max Pritikin (pritikin) wrote: > We want the protocol to be reasonable to implement by a lot of clients - browsers included. > > As such building on the protocol stack specified in the EST draft is my recommendation. No matter what stack we are talking about it will be a very hard sale. Personally, I don't think you get anywhere without donating code because the browser vendors are not following SDOs on this matter; they run their own enrollment agendas. These agendas are currently secret, not even their mere existence is acknowledged. How come? I think it is because the browser is gradually becoming the operating system which means that browsers will be used in 95% of all plausible use cases for enrollment of certificates to humans. Browsers also make protocols simpler since user authentication can be left out from the protocol (auth is done in the web layer). Anders A specific point is the text about server authentication with specifically calls put the browser/www authentication model (checking the subjectname as specified by a 3rd part certificate). > > See requirement I2 in the other thread. (yes, these will be in the next draft). > > - max > > On Apr 6, 2011, at 3:19 PM, "Anders Rundgren" wrote: > >> This is probably the biggest problem of all. >> >> Being a dare-devil (in this context NB...) I therefore put a "Yes, of course" in my take on this subject :-) >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > From pritikin@cisco.com Wed Apr 6 21:18:41 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920B83A69EE for ; Wed, 6 Apr 2011 21:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBf8ccPehFn6 for ; Wed, 6 Apr 2011 21:18:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AA8663A685D for ; Wed, 6 Apr 2011 21:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1349; q=dns/txt; s=iport; t=1302150025; x=1303359625; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=t2179uFHflYZwRNHEUYwXyuPk176TMxwDuWWAQufpwE=; b=ZMgdVJb2U5//4r5XS9KOkGQJtYWI92GqbDlrSNGHsV6L9Vci73o7+2Wm rKEu4bIMkMTfP/MjgL88jg3ABqaO1H9UgyAhu3wFJd1hONWivZsNk7kbX efP0arCinHp7aPiZfdjVFs7ekxh6E8HXjypUxVpDMhshxbhPHvQysntW0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGY6nU2rRDoH/2dsb2JhbACmAHeIeZ18nHODHYJPBIVOh2+DZokc X-IronPort-AV: E=Sophos;i="4.63,314,1299456000"; d="scan'208";a="290980104" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 04:20:25 +0000 Received: from [10.0.1.6] (stealth-10-32-244-66.cisco.com [10.32.244.66]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p374KORc002803; Thu, 7 Apr 2011 04:20:24 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: Date: Wed, 6 Apr 2011 22:20:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <62CAAD9D-E1A4-47EB-98F1-7E6E6336DDDB@cisco.com> References: To: Peter Gutmann X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 04:18:41 -0000 Peter, it is interesting to note that Facebook and other similar = examples are a hybrid model involving PSKs _and_ PKI, since all these = password exchanges occur over HTTPS. I think the most important lesson = from your example is that such hybrids are valuable and should not be = summarily dismissed. - max On Apr 6, 2011, at 9:58 PM, Peter Gutmann wrote: > Stephen Kent writes: >=20 >> pre-shared keys/passwords do not scale well, >=20 > "... and we'll keep asserting this until you cry Uncle, dammit!".=20 > PSKs/passwords are the basis of the most complex, scalable systems = ever=20 > designed. Just one of these, Facebook, has half a billion users using = non-=20 > scalable PSKs, and exactly zero using scalable PKI. Gmail, Yahoo, = Youtube,=20 > Flickr, all of these operate on a planetary scale using non-scalable = PSKs. So=20 > could I make the following modest suggestion, whenever someone wants = to say=20 > "PSKs don't scale", could they either qualify it with "... beyond = planetary=20 > scale" or alternatively "... and I'll keep asserting this while saying=20= > LALALALALAI'MNOTLISTENING until you go away". >=20 > Thanks, > Peter. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Wed Apr 6 21:23:28 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CFC28C0D9 for ; Wed, 6 Apr 2011 21:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.623 X-Spam-Level: X-Spam-Status: No, score=-3.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeyiVZGGDK-e for ; Wed, 6 Apr 2011 21:23:28 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by core3.amsl.com (Postfix) with ESMTP id 12A5128C0CF for ; Wed, 6 Apr 2011 21:23:28 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A1010B50A1; Thu, 7 Apr 2011 06:25:11 +0200 Message-ID: <4D9D3CAB.1090505@telia.com> Date: Thu, 07 Apr 2011 06:25:15 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pgut001@cs.aucKland.ac.nz Subject: [pkix] Passwords. Re: IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 04:23:29 -0000 On 2011-04-07 05:58, Peter Gutmann wrote: > Stephen Kent writes: > >> pre-shared keys/passwords do not scale well, > > "... and we'll keep asserting this until you cry Uncle, dammit!". > PSKs/passwords are the basis of the most complex, scalable systems ever > designed. Just one of these, Facebook, has half a billion users using non- > scalable PSKs, and exactly zero using scalable PKI. Gmail, Yahoo, Youtube, > Flickr, all of these operate on a planetary scale using non-scalable PSKs. So > could I make the following modest suggestion, whenever someone wants to say > "PSKs don't scale", could they either qualify it with "... beyond planetary > scale" or alternatively "... and I'll keep asserting this while saying > LALALALALAI'MNOTLISTENING until you go away". > It is possible that you guys are talking about different things. If containers should be capable of authenticating themselves it seems that PSKs would be a very stupid (non-scalable) solution. For users and operators that in some way invoke the enrollment process, a one-time/short-lived password is entirely appropriate. However, building on non-standard (generally implemented) TLS variants is not what I would do. Anders From tmiller@mitre.org Thu Apr 7 04:58:05 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C847F3A6918 for ; Thu, 7 Apr 2011 04:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.111 X-Spam-Level: X-Spam-Status: No, score=-5.111 tagged_above=-999 required=5 tests=[AWL=1.488, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMDlTsjZ2sqJ for ; Thu, 7 Apr 2011 04:58:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id DF7DB3A68F5 for ; Thu, 7 Apr 2011 04:58:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 27AAE21B0B14; Thu, 7 Apr 2011 07:59:49 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2085A2B78164; Thu, 7 Apr 2011 07:59:49 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 7 Apr 2011 07:59:48 -0400 From: "Miller, Timothy J." To: Paul Hoffman Date: Thu, 7 Apr 2011 07:59:50 -0400 Thread-Topic: [pkix] IETF 80: The future of PKIX certificate enrollment protocols Thread-Index: Acv1G0sqpPM33ZIZQsiewGGEX5IPPA== Message-ID: <29D93816-34E2-48E4-A01A-505CA1193F7B@mitre.org> References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> In-Reply-To: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1--399640412"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 11:58:05 -0000 --Apple-Mail-1--399640412 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 6, 2011, at 12:02 PM, Paul Hoffman wrote: > While the "do not scale well" part is true for some scenarios, it is = not necessarily correct for enrollment of machine certs. That is, it is = perfectly reasonable to have a long preshared key printed on the label = on the bottom of the bottom of a hardware system and use that as the = preshared key. Which anyone can read and claim, thus mooting the binding. -- T --Apple-Mail-1--399640412 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MDcxMTU5NTBaMCMGCSqGSIb3DQEJBDEWBBQqdP/a/PtXX/uYWmzM T8ibN2wEJzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgEfS+vUA9oqoOFlo311s7hJOr4K7ccMFNZJ3 Vd38pfE21OpgO0ZBvfRAkBrZu8unX5ttpMCZnLZmAtid6+FkLUcVrNu73e6OIT4KTjBq5vFSqFTo xG+M+nUtgWuGRSjSKYB3ZfnkCHiy8DoLWlU5iDHye7deSeYtqv9oLAUE1aTzAAAAAAAA --Apple-Mail-1--399640412-- From tmiller@mitre.org Thu Apr 7 05:02:15 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0883A68F5 for ; Thu, 7 Apr 2011 05:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.153 X-Spam-Level: X-Spam-Status: No, score=-5.153 tagged_above=-999 required=5 tests=[AWL=1.446, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySCtZFCCBYsc for ; Thu, 7 Apr 2011 05:02:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id BBE8C3A68C1 for ; Thu, 7 Apr 2011 05:02:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2CFAF21B0523; Thu, 7 Apr 2011 08:03:58 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 253E42B78275; Thu, 7 Apr 2011 08:03:58 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 7 Apr 2011 08:03:57 -0400 From: "Miller, Timothy J." To: "Max Pritikin (pritikin)" Date: Thu, 7 Apr 2011 08:03:58 -0400 Thread-Topic: [pkix] IETF 80: The future of PKIX certificate enrollmentprotocols Thread-Index: Acv1G996cFI5LiB9RiKKnLO2SEq/sg== Message-ID: <422ACC45-44FE-4323-9211-770D8C214427@mitre.org> References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2--399391683"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" , Paul Hoffman Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollmentprotocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:02:15 -0000 --Apple-Mail-2--399391683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The problem with manufacturer provisioning is in the consumer space the = potential for privacy violation is high. That's why TCG's Privacy CA = rigamarole looks the way it does; it prevents collusion between the = manufacturer and the identity consumers. Within an enterprise this = isn't a concern (or more accurately, it's a concern that can be signed = away in the employee contract). -- T On Apr 6, 2011, at 4:04 PM, Max Pritikin (pritikin) wrote: > A manufacturer with a sufficiently secure implementation of = manufacturing installed certificates is selling a product that can be = easier and/or more secure to deploy. The CA can verify device identity = in addition to (2 factor) or even instead of user identity. The = purchased HW provides value (if the CA wishes to leverage it).=20 >=20 > As always the CA may require a preshared secret or other password = based mechanism to be used. The security concerns for the out-of-band = distribution of that key material are entirely handled by the customer.=20= >=20 > These are captured in the Authorization 1-3 requirements I outlined in = the other thread.=20 >=20 > - max >=20 > On Apr 6, 2011, at 12:38 PM, "Paul Hoffman" = wrote: >=20 >> On Apr 6, 2011, at 10:40 AM, Stephen Kent wrote: >>=20 >>> At 10:02 AM -0700 4/6/11, Paul Hoffman wrote: >>>> ... >>>>>=20 >>>>> pre-shared keys/passwords do not scale well, and thus are a = questionable basis for other than trivial deployment contexts. I don't = consider either to be a >>>>> viable basis for what Max is proposing, for that reason. >>>>=20 >>>> While the "do not scale well" part is true for some scenarios, it = is not necessarily correct for enrollment of machine certs. That is, it = is perfectly reasonable to have a long preshared key printed on the = label on the bottom of the bottom of a hardware system and use that as = the preshared key. This scales just fine for certs that will be issued = by the hardware manufacturer. >>>=20 >>> My perception is that certs that are provisioned by a manufacturer = are generated >>> and installed prior to shipping a product, not when the product is = deployed >>> at a customer's site. Are you discussing manufacture-time = provisioning? >>=20 >> I am discussing different deployment options for different = manufacturers, not a one-size-must-fit-all limitation. >>=20 >>> Another issue is that if we say that we plan to support a broad = range of scenarios, as Max did, then it is inappropriate to rely on = pre-shared keys for TLS as a base for the protocol. Yes, they may be = appropriate for some, limited >>> contexts, but not overall. So, we might have to specify a range of = context assumptions and matching TLS key management capabilities, and = hope that folks >>> can pair these appropriately. That is doable, but it may not be = preferable, >>> since we all know how well users follow such guidance :-). >>=20 >> If your concern is scalability, then it should be completely up to = the CA to measure that. If your concern is security of the enrollment = messages, then clearly listing the concerns and specifying how to make = preshared secrets strong enough is both easy and sufficient. >>=20 >> --Paul Hoffman >>=20 >> _______________________________________________ >> 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 --Apple-Mail-2--399391683 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MDcxMjAzNTlaMCMGCSqGSIb3DQEJBDEWBBQJaDBkqAOcdJjxD2nj jKCFKaJL3jByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgBuVdmfO78WqOXPcoOcfv81yVJIWD++Oukeg XulrS6bqjV3NLOqntSb0Iy8aWl+LqAvDJycUIRUC43cBllAKq/IYErW0iYyKM/MnjP0+9cyCuvFk sFUA62UJVztRRGj8N8Qf5tCoSOu9yVN2fXd5QjGCTEcfbOlNu7FbbB0HiDL1AAAAAAAA --Apple-Mail-2--399391683-- From DPKemp@missi.ncsc.mil Thu Apr 7 05:37:40 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4335D3A690C for ; Thu, 7 Apr 2011 05:37:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xh6Z5W2NpUV for ; Thu, 7 Apr 2011 05:37:38 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 3E0313A68C8 for ; Thu, 7 Apr 2011 05:37: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 p37CdMOT072017 for ; Thu, 7 Apr 2011 08:39:22 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Apr 2011 08:38:57 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Thu, 7 Apr 2011 08:39:21 -0400 Message-ID: In-Reply-To: <422ACC45-44FE-4323-9211-770D8C214427@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] IETF 80: The future of PKIX certificate enrollment protocols Thread-Index: Acv1G996cFI5LiB9RiKKnLO2SEq/sgAA7TsQ References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org><6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> <422ACC45-44FE-4323-9211-770D8C214427@mitre.org> From: "Kemp, David P." To: X-OriginalArrivalTime: 07 Apr 2011 12:38:57.0906 (UTC) FILETIME=[C391C520:01CBF520] Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 12:37:40 -0000 Also note a comment on the last page of http://wwwcsif.cs.ucdavis.edu/~congdon/ecs235a-f07-poster.pdf: - TPM initialization process to support IDevID is cumbersome and expensive for manufacturers. - 802.1AR should consider loosening mandate to ship with IDevID and allow postmanufacturing provisioning. Apparently manufacturers of security-oriented devices don't want to be bothered with the inconvenience of actually having to generate a keypair! I don't know what to make of this - just another data point to consider. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Miller, Timothy J. Sent: Thursday, April 07, 2011 8:04 AM To: Max Pritikin (pritikin) Cc: pkix@ietf.org; Paul Hoffman Subject: Re: [pkix] IETF 80: The future ofPKIX certificate enrollmentprotocols The problem with manufacturer provisioning is in the consumer space the potential for privacy violation is high. That's why TCG's Privacy CA rigamarole looks the way it does; it prevents collusion between the manufacturer and the identity consumers. Within an enterprise this isn't a concern (or more accurately, it's a concern that can be signed away in the employee contract). -- T On Apr 6, 2011, at 4:04 PM, Max Pritikin (pritikin) wrote: > A manufacturer with a sufficiently secure implementation of manufacturing installed certificates is selling a product that can be easier and/or more secure to deploy. The CA can verify device identity in addition to (2 factor) or even instead of user identity. The purchased HW provides value (if the CA wishes to leverage it).=20 >=20 > As always the CA may require a preshared secret or other password based mechanism to be used. The security concerns for the out-of-band distribution of that key material are entirely handled by the customer.=20 >=20 > These are captured in the Authorization 1-3 requirements I outlined in the other thread.=20 >=20 > - max >=20 > On Apr 6, 2011, at 12:38 PM, "Paul Hoffman" wrote: >=20 >> On Apr 6, 2011, at 10:40 AM, Stephen Kent wrote: >>=20 >>> At 10:02 AM -0700 4/6/11, Paul Hoffman wrote: >>>> ... >>>>>=20 >>>>> pre-shared keys/passwords do not scale well, and thus are a=20 >>>>> questionable basis for other than trivial deployment contexts. I don't consider either to be a viable basis for what Max is proposing, for that reason. >>>>=20 >>>> While the "do not scale well" part is true for some scenarios, it is not necessarily correct for enrollment of machine certs. That is, it is perfectly reasonable to have a long preshared key printed on the label on the bottom of the bottom of a hardware system and use that as the preshared key. This scales just fine for certs that will be issued by the hardware manufacturer. >>>=20 >>> My perception is that certs that are provisioned by a manufacturer=20 >>> are generated and installed prior to shipping a product, not when=20 >>> the product is deployed at a customer's site. Are you discussing manufacture-time provisioning? >>=20 >> I am discussing different deployment options for different manufacturers, not a one-size-must-fit-all limitation. >>=20 >>> Another issue is that if we say that we plan to support a broad=20 >>> range of scenarios, as Max did, then it is inappropriate to rely on=20 >>> pre-shared keys for TLS as a base for the protocol. Yes, they may be >>> appropriate for some, limited contexts, but not overall. So, we might have to specify a range of context assumptions and matching TLS key management capabilities, and hope that folks can pair these appropriately. That is doable, but it may not be preferable, since we all know how well users follow such guidance :-). >>=20 >> If your concern is scalability, then it should be completely up to the CA to measure that. If your concern is security of the enrollment messages, then clearly listing the concerns and specifying how to make preshared secrets strong enough is both easy and sufficient. >>=20 >> --Paul Hoffman >>=20 >> _______________________________________________ >> 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 anders.rundgren@telia.com Thu Apr 7 07:52:38 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0613A69BA for ; Thu, 7 Apr 2011 07:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXwpZA-1wXep for ; Thu, 7 Apr 2011 07:52:36 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id 854DE3A69C5 for ; Thu, 7 Apr 2011 07:52:35 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA010EF53C; Thu, 7 Apr 2011 16:54:17 +0200 Message-ID: <4D9DD01D.9090000@telia.com> Date: Thu, 07 Apr 2011 16:54:21 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Miller, Timothy J." , "pkix@ietf.org" References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> <422ACC45-44FE-4323-9211-770D8C214427@mitre.org> In-Reply-To: <422ACC45-44FE-4323-9211-770D8C214427@mitre.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Privacy concerns: IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 14:52:38 -0000 On 2011-04-07 14:03, Miller, Timothy J. wrote: > The problem with manufacturer provisioning is in the consumer > space the potential for privacy violation is high. That's > why TCG's Privacy CA rigamarole looks the way it does; it > prevents collusion between the manufacturer and the > identity consumers. As a long-time member of TCG I'm aware of this but I actually disagree with this conclusion which I believe was based on the rather overblown idea that you need to attest the trustworthiness of your computer to essentially any site on the internet. For identity provisioning I claim that an e-mail address which is sort of the bare-bone minimum for identity vetting, is much more privacy-impeding than a fairy short-lived machine identity. That the machine identity is "certified" does not make a difference from a privacy point of view, it has only implications from a legal perspective in case of a criminal investigation and then your privacy is [more or less] gone anyway. Privacy should IMHO also be put it in a real-world context ranging from Cloud services, DNA, E-mail addresses, Mobile phone networks (they know WHO and WHEN you talk to and from WHERE!), Surveillance cameras, GPS-based Apps, to Social media like Facebook. TCG will have a hard time getting the Privacy CA going. The 200-400 million TPMs shipped have rather little to do and I think the root of the problem is that putting policy in silicon was a pretty bad idea. It was apparently a promise to BSI... As I understand, the mobile group have effectively nuked the privacy concept although they don't dare to say it in clear... In my take on this, the *user* makes the decision to enroll or not with information that his/her machine ID may be stored by the identity provider. This is similar to how other privacy threats are dealt with today so it feels alright :-) Anders Within an enterprise this isn't a > concern (or more accurately, it's a concern that can be > signed away in the employee contract). > > -- T > > > On Apr 6, 2011, at 4:04 PM, Max Pritikin (pritikin) wrote: > >> A manufacturer with a sufficiently secure implementation of manufacturing installed certificates is selling a product that can be easier and/or more secure to deploy. The CA can verify device identity in addition to (2 factor) or even instead of user identity. The purchased HW provides value (if the CA wishes to leverage it). >> >> As always the CA may require a preshared secret or other password based mechanism to be used. The security concerns for the out-of-band distribution of that key material are entirely handled by the customer. >> >> These are captured in the Authorization 1-3 requirements I outlined in the other thread. >> >> - max >> >> On Apr 6, 2011, at 12:38 PM, "Paul Hoffman" wrote: >> >>> On Apr 6, 2011, at 10:40 AM, Stephen Kent wrote: >>> >>>> At 10:02 AM -0700 4/6/11, Paul Hoffman wrote: >>>>> ... >>>>>> >>>>>> pre-shared keys/passwords do not scale well, and thus are a questionable basis for other than trivial deployment contexts. I don't consider either to be a >>>>>> viable basis for what Max is proposing, for that reason. >>>>> >>>>> While the "do not scale well" part is true for some scenarios, it is not necessarily correct for enrollment of machine certs. That is, it is perfectly reasonable to have a long preshared key printed on the label on the bottom of the bottom of a hardware system and use that as the preshared key. This scales just fine for certs that will be issued by the hardware manufacturer. >>>> >>>> My perception is that certs that are provisioned by a manufacturer are generated >>>> and installed prior to shipping a product, not when the product is deployed >>>> at a customer's site. Are you discussing manufacture-time provisioning? >>> >>> I am discussing different deployment options for different manufacturers, not a one-size-must-fit-all limitation. >>> >>>> Another issue is that if we say that we plan to support a broad range of scenarios, as Max did, then it is inappropriate to rely on pre-shared keys for TLS as a base for the protocol. Yes, they may be appropriate for some, limited >>>> contexts, but not overall. So, we might have to specify a range of context assumptions and matching TLS key management capabilities, and hope that folks >>>> can pair these appropriately. That is doable, but it may not be preferable, >>>> since we all know how well users follow such guidance :-). >>> >>> If your concern is scalability, then it should be completely up to the CA to measure that. If your concern is security of the enrollment messages, then clearly listing the concerns and specifying how to make preshared secrets strong enough is both easy and sufficient. >>> >>> --Paul Hoffman >>> >>> _______________________________________________ >>> 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 From hallam@gmail.com Thu Apr 7 12:00:30 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5178228C1A3 for ; Thu, 7 Apr 2011 12:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.006 X-Spam-Level: X-Spam-Status: No, score=-3.006 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ylxm1K8cP8AR for ; Thu, 7 Apr 2011 12:00:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 1D60528C18E for ; Thu, 7 Apr 2011 12:00:26 -0700 (PDT) Received: by vxg33 with SMTP id 33so2645474vxg.31 for ; Thu, 07 Apr 2011 12:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=pv9yub0jRZadfGlXhv1/NCpOwZYiynYQixiF64lfBxI=; b=fhRdzfOtOJulhiNZVwVtOA+mIAmjEW85zRCdZr/5PT3Yj7l9KgBUNwS/9PORCe8NWI 72Sm2GxfLD9HTh+2cVB6qkL4Jvd/LYmsrWsqO6eM3mtqbIhzyWTktSXMFRMzGH+iTTpU fD2BKRnPg1ZlTmdpCRsp+fLyWTnB797zt+E9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SEaJbV1GnWROoapfVBfFoD+l7ghBGHQfE0hJ9rxYx+9knd5wh9ROy53zwYS2KOyUZp hJKBph5F/6igvVA2TtLeDUN5pWny6Wx4PC1/3bsh6msBGdsVZl1nM6mKyJp5Q8icIb28 KBMUflH0cr7HM3pdWH3pD+1MduGN4qx1NZpu4= MIME-Version: 1.0 Received: by 10.52.18.11 with SMTP id s11mr1804239vdd.269.1302202930637; Thu, 07 Apr 2011 12:02:10 -0700 (PDT) Received: by 10.52.166.230 with HTTP; Thu, 7 Apr 2011 12:02:10 -0700 (PDT) Date: Thu, 7 Apr 2011 15:02:10 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: multipart/alternative; boundary=20cf3054a1131b2a0904a058bfe1 Subject: [pkix] Options for improving revocation X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 19:00:30 -0000 --20cf3054a1131b2a0904a058bfe1 Content-Type: text/plain; charset=ISO-8859-1 I have just submitted a new ID that attempts to draw together various proposals made to improve the effectiveness of revocation mechanisms including short lifetime certificates and use of OCSP stapling. Comments welcome. http://www.ietf.org/id/draft-hallambaker-revocation-options-00.txt I don't think the document is something that should become a PKIX item, but these requirements may well drive future changes to PKIX. -- Website: http://hallambaker.com/ --20cf3054a1131b2a0904a058bfe1 Content-Type: text/html; charset=ISO-8859-1 I have just submitted a new ID that attempts to draw together various proposals made to improve the effectiveness of revocation mechanisms including short lifetime certificates and use of OCSP stapling.

Comments welcome.



I don't think the document is something that should become a PKIX item, but these requirements may well drive future changes to PKIX.
--20cf3054a1131b2a0904a058bfe1-- From kent@bbn.com Thu Apr 7 14:59:35 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005CA28C16E for ; Thu, 7 Apr 2011 14:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trQxNa+YN0AG for ; Thu, 7 Apr 2011 14:59:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 448E728C0D8 for ; Thu, 7 Apr 2011 14:59:34 -0700 (PDT) Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49208) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q7xGQ-000I4o-Th; Thu, 07 Apr 2011 18:01:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 7 Apr 2011 17:59:24 -0400 To: Peter Gutmann From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 21:59:35 -0000 At 3:58 PM +1200 4/7/11, Peter Gutmann wrote: >Stephen Kent writes: > >> pre-shared keys/passwords do not scale well, > >"... and we'll keep asserting this until you cry Uncle, dammit!". >PSKs/passwords are the basis of the most complex, scalable systems ever >designed. Just one of these, Facebook, has half a billion users using non- >scalable PSKs, and exactly zero using scalable PKI. Gmail, Yahoo, Youtube, >Flickr, all of these operate on a planetary scale using non-scalable PSKs. So >could I make the following modest suggestion, whenever someone wants to say >"PSKs don't scale", could they either qualify it with "... beyond planetary >scale" or alternatively "... and I'll keep asserting this while saying >LALALALALAI'MNOTLISTENING until you go away". > >Thanks, >Peter. Peter, What on earth are you talking about? None of the cited systems use PSKs. They allow a user to select any PW and they associate that PW woth the asserted user ID, having not verified the user ID in any fashion at all. The user relies on the (seriously-flawed) browser PKI implementation (or on the DNS) to confirm that he/she is connected to the proper web site. None of these systems seem relevant to our discussion of cert enrollment, unless the goal is to allow cert enrollment to be as secure as widely-used systems that permit any user to select any name he/she desires. Steve From pritikin@cisco.com Thu Apr 7 15:22:53 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6954028C164 for ; Thu, 7 Apr 2011 15:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBBS2k8dxYp2 for ; Thu, 7 Apr 2011 15:22:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CCAA428C0D8 for ; Thu, 7 Apr 2011 15:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=5860; q=dns/txt; s=iport; t=1302215077; x=1303424677; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yoQ9wrr3p+ntCFuhJ4h7yQej67By+Er+CbtV1Dks3V0=; b=LcSuUIMFgvwDjSwu20YC0RSpzCkrTH1Vhxsv8F97sJ7k5efketUB4Syt Iv6ddAJvcb6BKcuK3RRi1JSh0DM/HZlKZPj4/eaTiSii0p+EidiBGIb50 Xgre1AIoepAGgdy9dSkyenmB+EVvQrKup5iMvrdsAtmhhvp2Fo/4TNjpZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0BAF85nk2rRDoG/2dsb2JhbAAwmA+NUneIeZtxnEyCfx+CTwSFUod4g2o X-IronPort-AV: E=Sophos;i="4.63,320,1299456000"; d="scan'208";a="332869924" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2011 22:24:36 +0000 Received: from [10.0.1.6] (stealth-10-32-244-66.cisco.com [10.32.244.66]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p37MOa0j002321; Thu, 7 Apr 2011 22:24:36 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: Date: Thu, 7 Apr 2011 15:24:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <712FAD19-F569-402A-BF97-74BFDE2C36BC@cisco.com> References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org><6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> <422ACC45-44FE-4323-9211-770D8C214427@mitre.org> To: "Kemp, David P." X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org Subject: [pkix] Manufacturing installed certificates Re: IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 22:22:53 -0000 (I consider this a little off topic, but interesting)=20 On Apr 7, 2011, at 5:39 AM, Kemp, David P. wrote: > Also note a comment on the last page of > http://wwwcsif.cs.ucdavis.edu/~congdon/ecs235a-f07-poster.pdf: >=20 > - TPM initialization process to support IDevID is > cumbersome and expensive for manufacturers. Yes, implementing the 802.1AR specification on existing TPM hardware is = cumbersome but possible. One could always design hardware that was = better at providing the IDevID functionalities but this particular = off-the-shelf solution was worth understanding. Paul Congdon (the author = of this paper) took time to understand that issue during 802.1AR = specification, which was much appreciated then and now.=20 > - 802.1AR should consider loosening mandate to ship > with IDevID and allow postmanufacturing provisioning. I think the definitions of "ship" and "postmanufacturing" are = sufficiently vague to make this a non-issue. Would it violate something = to 'ship' a device to an organization that performs a = 'postmanufacturing' insertion of an IDevID?=20 I suppose one could argue that 802.1AR should support an LDevID w/o an = IDevID. I think that would be too loose but could see the point. I'll = have to think about that approach.=20 None of this really effects how we use existing credentials during an = enrollment protocol.=20 > Apparently manufacturers of security-oriented devices don't want to be > bothered with the inconvenience of actually having to generate a > keypair! I don't know what to make of this - just another data point = to > consider. Yup. I think we can make this worth their time/effort. - max > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > Miller, Timothy J. > Sent: Thursday, April 07, 2011 8:04 AM > To: Max Pritikin (pritikin) > Cc: pkix@ietf.org; Paul Hoffman > Subject: Re: [pkix] IETF 80: The future ofPKIX certificate > enrollmentprotocols >=20 > The problem with manufacturer provisioning is in the consumer space = the > potential for privacy violation is high. That's why TCG's Privacy CA > rigamarole looks the way it does; it prevents collusion between the > manufacturer and the identity consumers. Within an enterprise this > isn't a concern (or more accurately, it's a concern that can be signed > away in the employee contract). >=20 > -- T >=20 >=20 > On Apr 6, 2011, at 4:04 PM, Max Pritikin (pritikin) wrote: >=20 >> A manufacturer with a sufficiently secure implementation of > manufacturing installed certificates is selling a product that can be > easier and/or more secure to deploy. The CA can verify device identity > in addition to (2 factor) or even instead of user identity. The > purchased HW provides value (if the CA wishes to leverage it).=20 >>=20 >> As always the CA may require a preshared secret or other password > based mechanism to be used. The security concerns for the out-of-band > distribution of that key material are entirely handled by the = customer.=20 >>=20 >> These are captured in the Authorization 1-3 requirements I outlined = in > the other thread.=20 >>=20 >> - max >>=20 >> On Apr 6, 2011, at 12:38 PM, "Paul Hoffman" > wrote: >>=20 >>> On Apr 6, 2011, at 10:40 AM, Stephen Kent wrote: >>>=20 >>>> At 10:02 AM -0700 4/6/11, Paul Hoffman wrote: >>>>> ... >>>>>>=20 >>>>>> pre-shared keys/passwords do not scale well, and thus are a=20 >>>>>> questionable basis for other than trivial deployment contexts. I > don't consider either to be a viable basis for what Max is proposing, > for that reason. >>>>>=20 >>>>> While the "do not scale well" part is true for some scenarios, it > is not necessarily correct for enrollment of machine certs. That is, = it > is perfectly reasonable to have a long preshared key printed on the > label on the bottom of the bottom of a hardware system and use that as > the preshared key. This scales just fine for certs that will be issued > by the hardware manufacturer. >>>>=20 >>>> My perception is that certs that are provisioned by a manufacturer=20= >>>> are generated and installed prior to shipping a product, not when=20= >>>> the product is deployed at a customer's site. Are you discussing > manufacture-time provisioning? >>>=20 >>> I am discussing different deployment options for different > manufacturers, not a one-size-must-fit-all limitation. >>>=20 >>>> Another issue is that if we say that we plan to support a broad=20 >>>> range of scenarios, as Max did, then it is inappropriate to rely on=20= >>>> pre-shared keys for TLS as a base for the protocol. Yes, they may = be >=20 >>>> appropriate for some, limited contexts, but not overall. So, we > might have to specify a range of context assumptions and matching TLS > key management capabilities, and hope that folks can pair these > appropriately. That is doable, but it may not be preferable, since we > all know how well users follow such guidance :-). >>>=20 >>> If your concern is scalability, then it should be completely up to > the CA to measure that. If your concern is security of the enrollment > messages, then clearly listing the concerns and specifying how to make > preshared secrets strong enough is both easy and sufficient. >>>=20 >>> --Paul Hoffman >>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pritikin@cisco.com Thu Apr 7 15:32:32 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D89A28C186 for ; Thu, 7 Apr 2011 15:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYTm3GFJHZ8k for ; Thu, 7 Apr 2011 15:32:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D2F2628C16E for ; Thu, 7 Apr 2011 15:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1310; q=dns/txt; s=iport; t=1302215657; x=1303425257; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=blZQQt3LykjcLcFhg95xHAr80BmjXzRbLrmIVRei9+c=; b=heBWLOHOtfwMa9wAAxSc4PkvTC1xNiskvZGQx6LxGrOo36ysnHtn7yHH MiNsGHxPBPfzJInRmGe6fOo2fWYTvaYrErCZfLxdExvZtH8vwcgBUp3P9 QJPpT7SpQ9ZSs+wUY8ApLBKNr1ygi2ebIpFhnJhHu2uYc5mDlZb2TMy9v k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHQ7nk2rRDoI/2dsb2JhbACmEXeIeZtmnFGFbQSFUod4g2qJHg X-IronPort-AV: E=Sophos;i="4.63,319,1299456000"; d="scan'208";a="425943168" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 07 Apr 2011 22:34:16 +0000 Received: from [10.0.1.6] (stealth-10-32-244-66.cisco.com [10.32.244.66]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p37MYGgB027947; Thu, 7 Apr 2011 22:34:16 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: Date: Thu, 7 Apr 2011 15:34:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Gutmann X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 22:32:32 -0000 On Apr 5, 2011, at 11:49 PM, Peter Gutmann wrote: > max pritikin writes: >=20 >> CMP [RFC4210] describes transport as being handled by an external = "CMPTrans" >=20 > Note that in effect "CMP transport" just means "use HTTP", it's about = as > simple as that. I continued: >> As such CMP provides an optional "PKI Message protection" methods = where "In the future, if/when external mechanisms are modified to = accommodate boot-strapping scenarios, the use of PKIProtection may = become rare or non-existent". Meaning that the different is that EST uses HTTPS (e.g. TLS) thus = allowing dramatic simplification of the messages. Is that a 'dramatic = profile of CMC' vs a new protocol? Shrug. Lets leave that semantic = discussion aside. The end result should be much simpler protocol resulting in greater = interoperability. There are other aspects borrowed from CMP (such as the = CA rekey discussion) and a more completely specified transport = discussion... so I find it easiest to think of this as a "unification of = good ideas" proposal. (I'd like to limit it to ideas that currently have traction plus some = extensibility agility, rather than throwing a million more options out = there and seeing what sticks).=20 - max >=20 > Peter. From pritikin@cisco.com Thu Apr 7 16:39:01 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00853A67EB for ; Thu, 7 Apr 2011 16:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdSucZi-SCr1 for ; Thu, 7 Apr 2011 16:39:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 85EBD3A67E1 for ; Thu, 7 Apr 2011 16:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=2688; q=dns/txt; s=iport; t=1302219645; x=1303429245; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=k87+/yytX9fXVQysLZu6k8j8mzGU9drf610ONdI7tBY=; b=hftbKyXF9LPd/tjkT5Hif/AmgGmN0E9eWcRz2ccmh3E9f77w0bvTipFA n+xNVMYmNwwqHv0dxrkHIviM742b2+a0pePYOMvUUJCMGVgRNEl5/lX1F qN/ydHLXWNcTsJWfyqYOE0MIypxwsxpiENHN2/iJ6brnpK+6alRycH0nN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE9Knk2rRDoH/2dsb2JhbACmEHeIeZt8nGmFbQSFUod4g2o X-IronPort-AV: E=Sophos;i="4.63,320,1299456000"; d="scan'208";a="291712260" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2011 23:40:45 +0000 Received: from [10.0.1.6] (stealth-10-32-244-66.cisco.com [10.32.244.66]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p37NejMf013956; Thu, 7 Apr 2011 23:40:45 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: <4D9C17DA.3030906@telia.com> Date: Thu, 7 Apr 2011 16:40:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BAA174D-8991-45A6-890C-013228841E12@cisco.com> References: <4D9C17DA.3030906@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1082) Cc: pkix@ietf.org Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 23:39:01 -0000 Anders, I'm not convinced, but then I'm not sure what you are asking yet. It is = possible to put this into the form of (P)roposed requirement: P1) Are you suggesting that the certificate enrollment protocol also = support a method for the secure distribution of arbitrary message/policy = objects? For example some form of "here is the generic policy blob that = goes with this credential"? If so are you suggesting that the encoding of this blob is in scope? Or = is it sufficient to simply offer a delivery channel? Does it matter if this blob is sent *before* the PKCS#10/CRMF is formed = or is it independent?=20 Or do you mean something else? Thanks, - max On Apr 6, 2011, at 12:35 AM, Anders Rundgren wrote: > On 2011-04-06 08:44, Peter Gutmann wrote: >> Stephen Kent writes: >>=20 >>> CMC and CMP were not targeting smart cards. >>=20 >> They aren't? Two of my major (known) users of CMP are using it to = provision >> crypto devices. >=20 > This is where things get confusing since both statements are correct > depending on what you actually mean by an "enrollment protocol". >=20 > Existing PKIX enrollment protocols are indeed used for deploying > credentials to smart cards. However, card management systems only > use the enrollment protocols for the certificate part which is just > one step in a card personalizing process. Things like PIN deployment > (in another lingo: setting the user's PIN in the token) is usually > dealt with through entirely proprietary methods and software. >=20 > The (maybe fluffy term) "Secure Messaging" is a way to do *all* > card/token operations though a protocol. >=20 > Secure Message is great but requires very detailed knowledge > of the container since *every low-level API method must have a > direct counterpart in the protocol*. Due to this I as well as > TrustedComputingGroup have found that the only reasonable way > to succeed with Secure Messaging is defining a standard token > and associated protocols down to the bit-level. >=20 > IMO, this part is the one which will be the biggest hurdle > since a protocol that supports both the the "old" (established) > and the "new" (promising) way will make CMP look quite simple :-) >=20 > Anyway, I haven't heard (it is in fact my line of work..) that > card management systems actually *need* a new system while mobile > devices and consumer tokens do. Secure Messaging is the way the > smart card industry is going. >=20 > Anders >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tgindin@us.ibm.com Thu Apr 7 18:16:46 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF5A3A6996 for ; Thu, 7 Apr 2011 18:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa1d6-qhxBnF for ; Thu, 7 Apr 2011 18:16:45 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 525B13A698F for ; Thu, 7 Apr 2011 18:16:45 -0700 (PDT) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p380udke004290 for ; Thu, 7 Apr 2011 20:56:39 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 1D65738C8039 for ; Thu, 7 Apr 2011 21:18:15 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p381INTU2596878 for ; Thu, 7 Apr 2011 21:18:23 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p381IM1b028907 for ; Thu, 7 Apr 2011 22:18:23 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p381IMPX028904; Thu, 7 Apr 2011 22:18:22 -0300 In-Reply-To: References: <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> To: Peter Gutmann MIME-Version: 1.0 X-KeepSent: CEDC9189:B67C9C9F-8525786B:0078F751; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Thu, 7 Apr 2011 21:18:22 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 04/07/2011 21:18:22, Serialize complete at 04/07/2011 21:18:22 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 01:16:46 -0000 Peter: After reading Anders' and Max's messages, I'm convinced that people are indeed talking past each other. A shared secret doesn't scale to large numbers of peers for a given entity. However, all the popular systems which use passwords have a star or wheel topology. The servers in the center do need authenticators recognized by large numbers of clients, so shared secrets would not work for them and they have certificates from public CA's. The clients on the boundary need to be authenticated against a central repository, so they have effectively only a single peer and thus passwords for them may pose a memorization or privacy problem but not a scaling one. I'd describe this difference between shared secrets and published certificates as one of "recognition scope". Having limited recognition scope, as self-signed certificates and bare public keys also do, doesn't really matter when a central authentication repository is used. Is there a term in use today to describe this property, or is this term useful? Tom Gindin From: Peter Gutmann To: kent@bbn.com, paul.hoffman@vpnc.org Cc: pkix@ietf.org Date: 04/06/2011 11:58 PM Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollment protocols Sent by: pkix-bounces@ietf.org Stephen Kent writes: > pre-shared keys/passwords do not scale well, "... and we'll keep asserting this until you cry Uncle, dammit!". PSKs/passwords are the basis of the most complex, scalable systems ever designed. Just one of these, Facebook, has half a billion users using non- scalable PSKs, and exactly zero using scalable PKI. Gmail, Yahoo, Youtube, Flickr, all of these operate on a planetary scale using non-scalable PSKs. So could I make the following modest suggestion, whenever someone wants to say "PSKs don't scale", could they either qualify it with "... beyond planetary scale" or alternatively "... and I'll keep asserting this while saying LALALALALAI'MNOTLISTENING until you go away". Thanks, Peter. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Thu Apr 7 22:34:42 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6034A3A6A44 for ; Thu, 7 Apr 2011 22:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.621 X-Spam-Level: X-Spam-Status: No, score=-3.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-8pPS4zxcpE for ; Thu, 7 Apr 2011 22:34:37 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by core3.amsl.com (Postfix) with ESMTP id AC16D3A6881 for ; Thu, 7 Apr 2011 22:34:36 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA0111DB2D; Fri, 8 Apr 2011 07:36:18 +0200 Message-ID: <4D9E9ED8.7030809@telia.com> Date: Fri, 08 Apr 2011 07:36:24 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: max pritikin References: <4D9C17DA.3030906@telia.com> <7BAA174D-8991-45A6-890C-013228841E12@cisco.com> In-Reply-To: <7BAA174D-8991-45A6-890C-013228841E12@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Secure Messaging in PKIX enrollment protocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 05:34:42 -0000 On 2011-04-08 01:40, max pritikin wrote: > > Anders, > > I'm not convinced, but then I'm not sure what you are asking yet. Max, I'm basically listing various enrollment protocol options. SM is a diametrically different take on the entire enrollment issue. SM has as most technical solutions pros and cons. Pro - Supports secure (and robust) *multiphase* processes Con - Requires 1-2-1 correspondence between protocol and API In *my* project which is targeting the billion+ users of mobile devices as well as "tokens", I recently slashed the original Y2007 design and replaced it with a scheme based on SM. The "Con" is IMO a "Pro" because it will make interoperability much easier and cheaper. It will also enable the "White label" token concept that IMO is a prerequisite for large-scale use of strong authentication like NSTIC. > It is possible to put this into the form of (P)roposed requirement: Here we get into some specifics and the only thing I can do is really describe what I have done and why. Other efforts must do their choices. > P1) Are you suggesting that the certificate enrollment > protocol also support a method for the secure distribution > of arbitrary message/policy objects? That is the cool thing with SM; you can transfer whatever you feel appropriate under a common security context requiring very little overhead. In a typical KeyGen2/SKS enrollment you typically perform seven(!) distinct signature/MAC operations. > For example some form of "here is the generic policy blob > that goes with this credential"? In SKS a there are PIN and PUK policy objects. To the key creation method there is a bunch of policy attributes like endorsed algorithms, export options etc. > If so are you suggesting that the encoding of this blob > is in scope? Or is it sufficient to simply offer a delivery channel? Since my proposal is not about creating a protocol, but about creating a complete token ecosystem, I have defined policy down to the bit-level. However, there is an option for "opaque" typed blobs that could be used for policy although my intention was really providing credential attribute data like VPN configuration, Information Card support, and through a variant of the attribute blob scheme, Logotypes. > Does it matter if this blob is sent *before* the PKCS#10/CRMF is > formed or is it independent? In my proposal all data "hangs" on the key and certificate so all but the PIN and PUK policy objects must be sent *after*. Note that SKS does not use CSRs, it creates container-attested keys on the issuer's request. Nothing prevents you from making a container-attested PKCS #10, I just didn't see the point. If I were to upgrade this scheme to for example making it a better fit to routers, I would insert (in the protocol) the router-originated data *before* the actual SM process was invoked. In an SM scheme, client-originated certification data shouldn't be created by the container; it only should only vouch for things is actually *knows* and do the crypto. > Or do you mean something else? I have already said too much :-) Anders > > Thanks, > > - max > > > On Apr 6, 2011, at 12:35 AM, Anders Rundgren wrote: > >> On 2011-04-06 08:44, Peter Gutmann wrote: >>> Stephen Kent writes: >>> >>>> CMC and CMP were not targeting smart cards. >>> >>> They aren't? Two of my major (known) users of CMP are using it to provision >>> crypto devices. >> >> This is where things get confusing since both statements are correct >> depending on what you actually mean by an "enrollment protocol". >> >> Existing PKIX enrollment protocols are indeed used for deploying >> credentials to smart cards. However, card management systems only >> use the enrollment protocols for the certificate part which is just >> one step in a card personalizing process. Things like PIN deployment >> (in another lingo: setting the user's PIN in the token) is usually >> dealt with through entirely proprietary methods and software. >> >> The (maybe fluffy term) "Secure Messaging" is a way to do *all* >> card/token operations though a protocol. >> >> Secure Message is great but requires very detailed knowledge >> of the container since *every low-level API method must have a >> direct counterpart in the protocol*. Due to this I as well as >> TrustedComputingGroup have found that the only reasonable way >> to succeed with Secure Messaging is defining a standard token >> and associated protocols down to the bit-level. >> >> IMO, this part is the one which will be the biggest hurdle >> since a protocol that supports both the the "old" (established) >> and the "new" (promising) way will make CMP look quite simple :-) >> >> Anyway, I haven't heard (it is in fact my line of work..) that >> card management systems actually *need* a new system while mobile >> devices and consumer tokens do. Secure Messaging is the way the >> smart card industry is going. >> >> Anders >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > From anders.rundgren@telia.com Fri Apr 8 00:07:14 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495AE3A6A4D for ; Fri, 8 Apr 2011 00:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.62 X-Spam-Level: X-Spam-Status: No, score=-3.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esq7nVvEEjd0 for ; Fri, 8 Apr 2011 00:07:13 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by core3.amsl.com (Postfix) with ESMTP id E0B6F3A6A4C for ; Fri, 8 Apr 2011 00:07:12 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D65154400D1F833; Fri, 8 Apr 2011 09:08:55 +0200 Message-ID: <4D9EB48D.4060304@telia.com> Date: Fri, 08 Apr 2011 09:09:01 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: max pritikin , "pkix@ietf.org" References: <4D9C17DA.3030906@telia.com> <7BAA174D-8991-45A6-890C-013228841E12@cisco.com> <4D9E9ED8.7030809@telia.com> In-Reply-To: <4D9E9ED8.7030809@telia.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [pkix] CSRs combined with Secure Messaging (SM) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 07:07:14 -0000 Max, I have given this topic a bit more thought and here is what I'm *considering*: Issuer request. Unmodified: Client (container) response. Original: ALhBpUjJK/mSjPAe/ … fXG8z1V3mVDZTBM7eZ AQAB Client (container) response with "PKCS #10-like" certification data option: ALhBpUjJK/mSjPAe/ … fXG8z1V3mVDZTBM7eZ AQAB A die-hard PKIXer would probably reject this arrangement but it works just fine while keeping all the goodies of the SM scheme. Note that Attestation still only covers the key, not CertificationData . Anyway, the whole KeyCreationResponse message could in this case be signed by an external SM-signature which is already a part of SKS. There is no need for using private keys for this purpose. As a "bonus" you get rid of awkward PIN requests during enrollment as well as the s.c. "misuse" of encryption keys. Anders From kent@bbn.com Mon Apr 11 10:45:53 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9F23A6A47 for ; Mon, 11 Apr 2011 10:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUgblBuWdtMs for ; Mon, 11 Apr 2011 10:45:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D0CB83A69A0 for ; Mon, 11 Apr 2011 10:45:52 -0700 (PDT) Received: from dhcp89-089-127.bbn.com ([128.89.89.127]:49166 helo=[128.89.89.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9LBR-000DVo-4a; Mon, 11 Apr 2011 13:45:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> Date: Mon, 11 Apr 2011 13:21:59 -0400 To: "Max Pritikin (pritikin)" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-909578544==_ma============" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollmentprotocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 17:45:53 -0000 --============_-909578544==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 3:04 PM -0600 4/6/11, Max Pritikin (pritikin) wrote: >A manufacturer with a sufficiently secure implementation of >manufacturing installed certificates is selling a product that can >be easier and/or more secure to deploy. The CA can verify device >identity in addition to (2 factor) or even instead of user identity. >The purchased HW provides value (if the CA wishes to leverage it). > >As always the CA may require a preshared secret or other password >based mechanism to be used. The security concerns for the >out-of-band distribution of that key material are entirely handled >by the customer. > >These are captured in the Authorization 1-3 requirements I outlined >in the other thread. > >- max max, I think we have gotten way off target here, and I apologize for any contribution to this distraction that I may have made. If a manufacturer installs a cert in a product, it probably can do so in an acceptably secure fashion, relative to its perception of what is secure enough. It could use pre-shared keys, or it could just declare that the cable between the device and a co-located A system is physically secured, and be done with it. The manufacturer need not use any standard in this provisioning process, if it takes place purely inside of the manufacturing context. There are benefits to using a standard here, e.g., the manufacturer might be able to use a CA system that adheres to the standard, instead of rolling its own. But, I don't see this as critical, and if this were the only (or even the primary) use case, I would suggest it is not worth developing the standard in PKIX. I think you have proposed a broader scope for this enrollment/management protocol. But, you also suggested that we use TLS to secure the connection between a cert requester and a CA. I asked whether we are comfortable with that assumption, because of concerns over how well TLS specifies use of certs. Citing examples where one need not use certs with TLS (e.g., using pre-shared keys) does not address the concern that I raised, unless we believe that such modes of TLS use cover ALL of the scope for this protocol. THus we need not spend any more time discussing whether factory initialization of a device can be made adequately secure via pre-shared keys. This is not a context in which scaling issues for pre-shared keys arise. If a device with a factory-installed cert is going to communicate with a CA that has no relationship to the vendor, then we are entering a different realm. We need to address how the device knows what CA it is talking to, to the satisfaction of the owner of the device. We also need to discuss how this CA knows that it is communicating with the device in question, since verification of the device cert requires interaction with the vendor (or the vendor's CA). Does this help? Steve --============_-909578544==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] IETF 80: The future of PKIX certificate enrollm
At 3:04 PM -0600 4/6/11, Max Pritikin (pritikin) wrote:
A manufacturer with a sufficiently secure implementation of manufacturing installed certificates is selling a product that can be easier and/or more secure to deploy. The CA can verify device identity in addition to (2 factor) or even instead of user identity. The purchased HW provides value (if the CA wishes to leverage it).

As always the CA may require a preshared secret or other password based mechanism to be used. The security concerns for the out-of-band distribution of that key material are entirely handled by the customer.

These are captured in the Authorization 1-3 requirements I outlined in the other thread.
- max

max,

I think we have gotten way off target here, and I apologize for any contribution to this distraction that I may have made.

If a manufacturer installs a cert in a product, it probably can do so in an acceptably secure fashion, relative to its perception of what is secure enough. It could use pre-shared keys, or it could just declare that the cable between the device and a co-located A system is physically secured, and be done with it.

The manufacturer need not use any standard in this provisioning process, if it takes place purely inside of the manufacturing context.  There are benefits to using a standard here, e.g., the manufacturer might be able to use a CA system that adheres to the standard, instead of rolling its own. But, I don't see this as critical, and if this were the only (or even the primary) use case, I would suggest it is not worth developing the standard in PKIX.

I think you have  proposed a broader scope for this enrollment/management protocol. But, you also suggested that we use TLS to secure the connection between a cert requester and a CA. I asked whether we are comfortable with
that assumption, because of concerns over how well TLS specifies use of certs.

Citing examples where one need not use certs with TLS (e.g., using pre-shared keys) does not address the concern that I raised, unless we believe that such modes of TLS use cover ALL of the scope for this protocol.  THus we need not spend any more time discussing whether factory initialization of a device can be made adequately secure via pre-shared keys.  This is not a context in which scaling issues for pre-shared keys arise.

If a device with a factory-installed cert is going to communicate with a CA that has no relationship to the vendor, then we are entering a different realm.  We need to address how the device knows what CA it is talking to, to the satisfaction of the owner of the device. We also need to discuss how this CA knows that it is communicating with the device in question, since verification of the device cert requires interaction with the vendor (or the vendor's CA).

Does this help?

Steve
--============_-909578544==_ma============-- From pritikin@cisco.com Mon Apr 11 11:33:13 2011 Return-Path: X-Original-To: pkix@core3.amsl.com Delivered-To: pkix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CDF23A69A0 for ; Mon, 11 Apr 2011 11:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw0Nm3BLK6I9 for ; Mon, 11 Apr 2011 11:33:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 22DC33A6999 for ; Mon, 11 Apr 2011 11:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=3839; q=dns/txt; s=iport; t=1302546792; x=1303756392; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lD9Eb9GJcNs1KULXlLDgy1FFSI4/ZYBJkcepX1YAgNM=; b=GwePSeET2x+3bYmjq+hUhaK5ufFa3YnLxr/X/8RArA/hQ36YTjhdb77B uovxk6zGHq336RdNtHq1KUDuKcPHix4+TBSwcudBtLj8Pnr5LWkysOxgu iXY2opvX5g9X5P0Kb9n+qrgu3/CoAlg0faDR29OfeYt6p9r3feSCKy7TI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI9Io02rRDoI/2dsb2JhbACmH3eIep4vnC6Cfx+CUASFW4d9g2o X-IronPort-AV: E=Sophos;i="4.64,192,1301875200"; d="scan'208";a="679168626" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2011 18:33:09 +0000 Received: from [10.0.1.6] (stealth-10-32-244-66.cisco.com [10.32.244.66]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BIX8IS011568; Mon, 11 Apr 2011 18:33:08 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: max pritikin In-Reply-To: Date: Mon, 11 Apr 2011 11:33:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <96ABD05D-2972-4871-8888-F93683DAF320@cisco.com> References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollmentprotocols X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:33:13 -0000 On Apr 11, 2011, at 10:21 AM, Stephen Kent wrote: > At 3:04 PM -0600 4/6/11, Max Pritikin (pritikin) wrote: >> A manufacturer with a sufficiently secure implementation of = manufacturing installed certificates is selling a product that can be = easier and/or more secure to deploy. The CA can verify device identity = in addition to (2 factor) or even instead of user identity. The = purchased HW provides value (if the CA wishes to leverage it). >>=20 >> As always the CA may require a preshared secret or other password = based mechanism to be used. The security concerns for the out-of-band = distribution of that key material are entirely handled by the customer. >>=20 >> These are captured in the Authorization 1-3 requirements I outlined = in the other thread. >> - max >=20 > max, >=20 > I think we have gotten way off target here, and I apologize for any = contribution to this distraction that I may have made. >=20 > If a manufacturer installs a cert in a product, it probably can do so = in an acceptably secure fashion, relative to its perception of what is = secure enough. It could use pre-shared keys, or it could just declare = that the cable between the device and a co-located A system is = physically secured, and be done with it. >=20 > The manufacturer need not use any standard in this provisioning = process, if it takes place purely inside of the manufacturing context. = There are benefits to using a standard here, e.g., the manufacturer = might be able to use a CA system that adheres to the standard, instead = of rolling its own. But, I don't see this as critical, and if this were = the only (or even the primary) use case, I would suggest it is not worth = developing the standard in PKIX. Agreed. Manufacturing installed certs are "off topic" and I think they = should be on a different thread. > I think you have proposed a broader scope for this = enrollment/management protocol. The scope of the enrollment protocol includes how the client is = authenticated. > But, you also suggested that we use TLS to secure the connection = between a cert requester and a CA. I asked whether we are comfortable = with > that assumption, because of concerns over how well TLS specifies use = of certs. TLS specifies some limitations on certificates involved but does not go = into detail concerning the authentication/authorization model (TLS 1.2 = D.2 pretty much just punts this). Using HTTPS provides us a bit of = guidance for server authentication, but the EST document is intended to = flesh this out fully for enrollment protocols. I don't see this as a = concern so much as a requirement: this needs to be specified.=20 > Citing examples where one need not use certs with TLS (e.g., using = pre-shared keys) does not address the concern that I raised, unless we = believe that such modes of TLS use cover ALL of the scope for this = protocol. THus we need not spend any more time discussing whether = factory initialization of a device can be made adequately secure via = pre-shared keys. This is not a context in which scaling issues for = pre-shared keys arise. Agreed. The text of EST is focuses on these issues not factory = installation issues. > If a device with a factory-installed cert is going to communicate with = a CA that has no relationship to the vendor, then we are entering a = different realm. We need to address how the device knows what CA it is = talking to, to the satisfaction of the owner of the device. We also need = to discuss how this CA knows that it is communicating with the device in = question, since verification of the device cert requires interaction = with the vendor (or the vendor's CA). Yup.=20 > Does this help? I think we're on the same page, - max > Steve From kent@bbn.com Mon Apr 11 15:30:44 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5AAECE06BD for ; Mon, 11 Apr 2011 15:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzAkWrp00VwJ for ; Mon, 11 Apr 2011 15:30:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id BA8CDE06BC for ; Mon, 11 Apr 2011 15:30:40 -0700 (PDT) Received: from dhcp89-089-127.bbn.com ([128.89.89.127]:49181 helo=[128.89.89.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q9Ngp-000GFX-Ck; Mon, 11 Apr 2011 16:26:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <96ABD05D-2972-4871-8888-F93683DAF320@cisco.com> References: <315DEF7B-3E73-4902-96DE-D2F0A236C7F1@vpnc.org> <6BF6B382-E775-4455-9141-2E6E0EF315B2@vpnc.org> <96ABD05D-2972-4871-8888-F93683DAF320@cisco.com> Date: Mon, 11 Apr 2011 15:55:55 -0400 To: max pritikin From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] IETF 80: The future of PKIX certificate enrollmentprotocols 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, 11 Apr 2011 22:30:44 -0000 Max, based on your reply, I think we're heading in the right direction. Thanks, Steve From anders.rundgren@telia.com Mon Apr 11 16:03:50 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5754AE06BF for ; Mon, 11 Apr 2011 16:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDnPHrNfN3Zf for ; Mon, 11 Apr 2011 16:03:49 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfc.amsl.com (Postfix) with ESMTP id DA749E0680 for ; Mon, 11 Apr 2011 16:03:47 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA0126332B for pkix@ietf.org; Mon, 11 Apr 2011 22:30:35 +0200 Message-ID: <4DA364F6.3020207@telia.com> Date: Mon, 11 Apr 2011 22:30:46 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Differences between "Router" and "Human" enrollments 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, 11 Apr 2011 23:03:50 -0000 I 'm not very much into routers so I obviously do not have the best background for creating an enrollment system for routers which is one reason why SKS/KeyGen2 isn't targeted at routers. However, since it is so costly bringing out a full-fledged enrollment scheme it may be an idea at least investigating what routers require that humans don't, right? After familiarizing myself a bit with SCEP I see one thing that you don't find in human-oriented enrollment and that's polling for the result. In the human variant of enrollment you rather get a notification by a messaging system that when you attend to it, brings you to the next phase. Another difference is protocol invocation, but here I see that a somewhat slimy web-proxy concept that I have already have running since 3 years back actually could work quite well. All you need is a web-browser. Due to the complexity of this, I believe you need to build proof-of-concept systems before claiming that you have a solution. I have done that for the human part. Anders From jun.hu@alcatel-lucent.com Tue Apr 12 11:42:21 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26395E082D for ; Tue, 12 Apr 2011 11:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3SvF3eQy+eZ for ; Tue, 12 Apr 2011 11:42:20 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfc.amsl.com (Postfix) with ESMTP id 13422E081C for ; Tue, 12 Apr 2011 11:42:19 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3CIgJcC009602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Apr 2011 13:42:19 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3CIgI9N018381 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 12 Apr 2011 13:42:19 -0500 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 12 Apr 2011 13:42:19 -0500 From: "Hu, Jun (Jun)" To: "pkix@ietf.org" Date: Tue, 12 Apr 2011 13:42:15 -0500 Thread-Topic: clarification of pathLenConstraint Thread-Index: Acv5QVgz5SM6paIjSHiDhEPWmLz9ig== Message-ID: <098C866D3766674B95CCF197E1C2489B0B9AD43FE9@USNAVSXCHMBSC1.ndc.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [pkix] clarification of pathLenConstraint 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, 12 Apr 2011 18:42:21 -0000 Hi, I have a certificate path like following: Root-CA(pathlen=3D0) --> CA1(pathlen=3D0) --> user_cert Root-CA is a self-issued CA, Root-CA signs CA1 and CA1 signs user_cert, bot= h Root-CA and CA1 has pathLenConstraint=3D0. So the question is:=20 Is the user_cert valid in this case? Following text in section 4.2.1.9 of RFC5280 seems to suggest user_cert in = this case is not valid "A pathLenConstraint of zero indicates that no non-self-issued intermediate= CA certificates may follow in a valid certification path." But then following text in section 6.1 seems to suggest the opposite:=20 "These self-issued certificates are not counted when evaluating path length= or name constraints." Because if Root-CA is not counted, the CA1(pathlen=3D0)-->user_cert is a va= lid cert path.=20 So I am bit confused here ... --------------- Hu Jun From pornin@bolet.org Tue Apr 12 11:54:58 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D35C5E0898 for ; Tue, 12 Apr 2011 11:54:58 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xuig0+FpovUf for ; Tue, 12 Apr 2011 11:54:58 -0700 (PDT) Received: from arges.bolet.org (arges.bolet.org [88.191.65.205]) by ietfc.amsl.com (Postfix) with ESMTP id 390CCE0716 for ; Tue, 12 Apr 2011 11:54:58 -0700 (PDT) Received: from [10.0.1.101] (modemcable030.142-202-24.mc.videotron.ca [24.202.142.30]) by arges.bolet.org (Postfix) with ESMTPSA id 3C43B68C0BC; Tue, 12 Apr 2011 20:54:55 +0200 (CEST) From: Thomas Pornin To: "Hu, Jun (Jun)" In-Reply-To: <098C866D3766674B95CCF197E1C2489B0B9AD43FE9@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> References: <098C866D3766674B95CCF197E1C2489B0B9AD43FE9@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 12 Apr 2011 14:54:50 -0400 Message-ID: <1302634490.2362.9.camel@nostromo> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] clarification of pathLenConstraint 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, 12 Apr 2011 18:54:59 -0000 On Tue, 2011-04-12 at 13:42 -0500, Hu, Jun (Jun) wrote: > Root-CA is a self-issued CA RFC 5280 does not really recognize the concept of "self-signed root CA". Certificate validation begins with a "trust anchor", which consists in a public key and a name, and also some parameters detailed in section 6.1.1. None of these parameters is a limit on subsequent path length. The "max_path_length" variable is initialized to the total path length (in section 6.1.2, clause (k)). It is _traditional_ to encode trust anchors (and some other validation inputs) as self-signed certificates. However, this is out of scope of RFC 5280. The storage format for a trust anchor has no influence on the validation process. In particular, the Basic Constraints Extension which may be present in the self-signed root certificate will be completely ignored. As per RFC 5280 rules, your path shall be considered as valid. --Thomas Pornin From david.cooper@nist.gov Tue Apr 12 12:08:22 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 21A85E0892 for ; Tue, 12 Apr 2011 12:08:22 -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, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26MD2ps8SvwX for ; Tue, 12 Apr 2011 12:08:21 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfc.amsl.com (Postfix) with ESMTP id 58DBAE0891 for ; Tue, 12 Apr 2011 12:08:21 -0700 (PDT) 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 p3CJ86CG015245; Tue, 12 Apr 2011 15:08:07 -0400 Message-ID: <4DA4A316.3030004@nist.gov> Date: Tue, 12 Apr 2011 15:08:06 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110407 Mandriva/3.1.9-0.2mdv2010.2 (2010.2) Thunderbird/3.1.9 MIME-Version: 1.0 To: "Hu, Jun (Jun)" References: <098C866D3766674B95CCF197E1C2489B0B9AD43FE9@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> In-Reply-To: <098C866D3766674B95CCF197E1C2489B0B9AD43FE9@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] clarification of pathLenConstraint 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, 12 Apr 2011 19:08:22 -0000 It is unclear in the scenario that you describe below whether the self-issued certificate that was issued by Root-CA is self-signed, so the answer is that it depends. If Root-CA is not a self-signed certificate, then this path is not valid since the first certificate in the path includes a constraint of pathLenConstraint=0 and that certificate is followed in the path by a non-self-issued intermediate certificate. [The path would be valid if the second certificate in the path, CA1, were self-issued.] If Root-CA is a self-signed certificate, then this certification path really only consists of two certificates: CA1 and user_cert. In this case, Root-CA is just the source of trust anchor information (Section 6.1.1 (d)) and (as is stated in Section 6.1) is not part of the prospective certification path. In this case, a path validation algorithm would be to permitted to ignore the constraints information in the self-signed certificate, which would lead to its considering the path to be valid. One would have to wonder, though, why a CA would place a constraint of pathLenConstraint=0 in its self-signed certificate and then proceed to issue a CA certificate. Did it change its mind about issuing CA certificates after generating and distributing the self-signed certificate? Are the CA certificates only intended to be accepted by relying parties that use Root-CA as an intermediate CA and not as a trust anchor? On 04/12/2011 02:42 PM, Hu, Jun (Jun) wrote: > Hi, > I have a certificate path like following: > > Root-CA(pathlen=0) --> CA1(pathlen=0) --> user_cert > > Root-CA is a self-issued CA, Root-CA signs CA1 and CA1 signs user_cert, both Root-CA and CA1 has pathLenConstraint=0. > > So the question is: > Is the user_cert valid in this case? > > Following text in section 4.2.1.9 of RFC5280 seems to suggest user_cert in this case is not valid > "A pathLenConstraint of zero indicates that no non-self-issued intermediate CA certificates may follow in a valid certification path." > > But then following text in section 6.1 seems to suggest the opposite: > "These self-issued certificates are not counted when evaluating path length or name constraints." > Because if Root-CA is not counted, the CA1(pathlen=0)-->user_cert is a valid cert path. > > So I am bit confused here ... > > --------------- > Hu Jun From jun.hu@alcatel-lucent.com Tue Apr 12 15:29:40 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5F564E07BE for ; Tue, 12 Apr 2011 15:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS9Hu279NqFj for ; Tue, 12 Apr 2011 15:29:39 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfc.amsl.com (Postfix) with ESMTP id 7672EE0883 for ; Tue, 12 Apr 2011 15:29:39 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p3CMTcRR019357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 17:29:38 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3CMTcab002754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Apr 2011 17:29:38 -0500 Received: from USNAVSXCHMBSC1.ndc.alcatel-lucent.com ([135.3.39.145]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 12 Apr 2011 17:29:38 -0500 From: "Hu, Jun (Jun)" To: "David A. Cooper" Date: Tue, 12 Apr 2011 17:29:34 -0500 Thread-Topic: [pkix] clarification of pathLenConstraint Thread-Index: Acv5RP0sR7cP1Ot7RJeXd9EdSa7pmwAF2nNQ Message-ID: <098C866D3766674B95CCF197E1C2489B0B9AD440F5@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> References: <098C866D3766674B95CCF197E1C2489B0B9AD43FE9@USNAVSXCHMBSC1.ndc.alcatel-lucent.com> <4DA4A316.3030004@nist.gov> In-Reply-To: <4DA4A316.3030004@nist.gov> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "pkix@ietf.org" Subject: Re: [pkix] clarification of pathLenConstraint 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, 12 Apr 2011 22:29:40 -0000 Thanks for the clarification. The Root-CA I was using is a self-signed cert= ificate.=20 One thing maybe worth to mention: I imported these certificates into windows xp like following: Self signed Root-CA into Trusted Root Certification Authorities CA1 into Intermediate Certificate Authorities=20 user_cert into Other People=20 Then it seems windows consider user_cert is invalid, here is the screen sho= ot: http://tinypic.com/r/16izc44/7 -----Original Message----- From: David A. Cooper [mailto:david.cooper@nist.gov]=20 Sent: Tuesday, April 12, 2011 12:08 PM To: Hu, Jun (Jun) Cc: pkix@ietf.org Subject: Re: [pkix] clarification of pathLenConstraint It is unclear in the scenario that you describe below whether the=20 self-issued certificate that was issued by Root-CA is self-signed, so=20 the answer is that it depends. If Root-CA is not a self-signed certificate, then this path is not valid=20 since the first certificate in the path includes a constraint of=20 pathLenConstraint=3D0 and that certificate is followed in the path by a=20 non-self-issued intermediate certificate. [The path would be valid if=20 the second certificate in the path, CA1, were self-issued.] If Root-CA is a self-signed certificate, then this certification path=20 really only consists of two certificates: CA1 and user_cert. In this=20 case, Root-CA is just the source of trust anchor information (Section=20 6.1.1 (d)) and (as is stated in Section 6.1) is not part of the=20 prospective certification path. In this case, a path validation=20 algorithm would be to permitted to ignore the constraints information in=20 the self-signed certificate, which would lead to its considering the=20 path to be valid. One would have to wonder, though, why a CA would place a constraint of=20 pathLenConstraint=3D0 in its self-signed certificate and then proceed to=20 issue a CA certificate. Did it change its mind about issuing CA=20 certificates after generating and distributing the self-signed=20 certificate? Are the CA certificates only intended to be accepted by=20 relying parties that use Root-CA as an intermediate CA and not as a=20 trust anchor? On 04/12/2011 02:42 PM, Hu, Jun (Jun) wrote: > Hi, > I have a certificate path like following: > > Root-CA(pathlen=3D0) --> CA1(pathlen=3D0) --> user_cert > > Root-CA is a self-issued CA, Root-CA signs CA1 and CA1 signs user_cert, b= oth Root-CA and CA1 has pathLenConstraint=3D0. > > So the question is: > Is the user_cert valid in this case? > > Following text in section 4.2.1.9 of RFC5280 seems to suggest user_cert i= n this case is not valid > "A pathLenConstraint of zero indicates that no non-self-issued intermedia= te CA certificates may follow in a valid certification path." > > But then following text in section 6.1 seems to suggest the opposite: > "These self-issued certificates are not counted when evaluating path leng= th or name constraints." > Because if Root-CA is not counted, the CA1(pathlen=3D0)-->user_cert is a = valid cert path. > > So I am bit confused here ... > > --------------- > Hu Jun From pgut001@login01.cs.auckland.ac.nz Tue Apr 12 23:57:36 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B5564E06D1 for ; Tue, 12 Apr 2011 23:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3qLfi4gazev for ; Tue, 12 Apr 2011 23:57:35 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 2E272E0674 for ; Tue, 12 Apr 2011 23:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1302677855; x=1334213855; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20jun.hu@alcatel-lucent.com,=20pornin@bolet.org |Subject:=20Re:=20[pkix]=20clarification=20of=20pathLenCo nstraint|Cc:=20pkix@ietf.org|In-Reply-To:=20<1302634490.2 362.9.camel@nostromo>|Message-Id:=20|Date:=20Wed,=2013=20Apr=202011 =2018:57:25=20+1200; bh=YCtKb41U5QkmBH+4JuqfNxQdZEdPcFtwL4D4f0/Vdvo=; b=VDWUiPP19fbBebib4Bgs+LG6cQJR/UdJ5VNzi1dQ/BGySMfBk+WlDqRb c16REoqw3J4ZGNsYp+cvqb5AL8dWECbvV3IeGO6mwD6cBoegqgDVP388p FshGIam5LcJFPiuOZ7EWnBJ6TC8YMcmR8eVJueTYtDCO6lcWBo+ARKYlK 0=; X-IronPort-AV: E=Sophos;i="4.64,203,1301832000"; d="scan'208";a="56606767" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Apr 2011 18:57:26 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q9u0z-0007tY-Io; Wed, 13 Apr 2011 18:57:25 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Q9u0z-0007o9-Pa; Wed, 13 Apr 2011 18:57:25 +1200 From: Peter Gutmann To: jun.hu@alcatel-lucent.com, pornin@bolet.org In-Reply-To: <1302634490.2362.9.camel@nostromo> Message-Id: Date: Wed, 13 Apr 2011 18:57:25 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] clarification of pathLenConstraint 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, 13 Apr 2011 06:57:36 -0000 Thomas Pornin writes: >As per RFC 5280 rules, your path shall be considered as valid. You really need to qualify this a bit more, although I guess the "as per RFC 5280 rules" is one qualification :-). The real-life version though is: If the implementation ignores path-length constraints, it's valid. If the implementation doesn't ignore path-length constraints and pays attention to extensions in root certs, it's not valid. If the implementation doesn't ignore path-length constraints but ignores extensions in TAs, it's back to not valid again. A more succint summary would be: It's a coin-toss. I guess it all comes down to whether the original poster was interested in what's valid in theory vs. what will actually happen in practice. Peter. From anders.rundgren@telia.com Wed Apr 13 12:23:06 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DD23EE073C for ; Wed, 13 Apr 2011 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-AZhVOYyTWf for ; Wed, 13 Apr 2011 12:23:06 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfc.amsl.com (Postfix) with ESMTP id 26C77E065C for ; Wed, 13 Apr 2011 12:23:05 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A10137BA84 for pkix@ietf.org; Wed, 13 Apr 2011 21:14:13 +0200 Message-ID: <4DA5F615.6000305@telia.com> Date: Wed, 13 Apr 2011 21:14:29 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Browser enrollments and ASN.1 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, 13 Apr 2011 19:23:07 -0000 As far as I know there are four different browser enrollment schemes: - Netscape's - Microsoft's "CertEnroll" - Mozilla's generateCRMFrequest () - Apple's SCEP A common denominator is that the request is based on an ASN.1 construct of some kind. Another common denominator is that protocol invocation is based on all-over-the-map methods where none is using ASN.1. Exactly where that leaves a PKIX enrollment effort is unclear to me at least. Anders From tgindin@us.ibm.com Thu Apr 14 04:50:06 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B24DE06C1 for ; Thu, 14 Apr 2011 04:50:06 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NUf1MXUk7MA for ; Thu, 14 Apr 2011 04:50:05 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfc.amsl.com (Postfix) with ESMTP id 4F544E0692 for ; Thu, 14 Apr 2011 04:50:05 -0700 (PDT) Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3EBNnIB017942 for ; Thu, 14 Apr 2011 07:23:49 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 187E138C803D for ; Thu, 14 Apr 2011 07:49:37 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3EBnlub319546 for ; Thu, 14 Apr 2011 07:49:47 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3EBnkgu001592 for ; Thu, 14 Apr 2011 08:49:46 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3EBnk5c001589; Thu, 14 Apr 2011 08:49:46 -0300 In-Reply-To: References: <1302634490.2362.9.camel@nostromo> To: Peter Gutmann MIME-Version: 1.0 X-KeepSent: D118BF12:7F96F9AA-85257871:006AA769; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Thu, 14 Apr 2011 07:49:45 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 04/14/2011 07:49:45, Serialize complete at 04/14/2011 07:49:45 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER Cc: pkix@ietf.org Subject: Re: [pkix] clarification of pathLenConstraint 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, 14 Apr 2011 11:50:06 -0000 Here's mine - there's no point in putting path length constraints into self-signed certificates unless you expect them to be processed by an engine which implements an initial value for path length. RFC 5280 doesn't really favor such engines, although RFC 5914 does allow path length in the CertPathControls structure. That extension in a self-signed certificate is almost meaningless to a 5280 engine. Maybe we should put an extra variable for the length into RFC 5280 6.1.1 and change 6.1.2-k to use it. I would say that you could initialize max_path_length to 32K-1 (or "a positive integer greater than any path length supported by the validation engine") as easily as to N, since the only thing that matters about its value is it staying positive. Tom Gindin From: Peter Gutmann To: jun.hu@alcatel-lucent.com, pornin@bolet.org Cc: pkix@ietf.org Date: 04/13/2011 02:57 AM Subject: Re: [pkix] clarification of pathLenConstraint Sent by: pkix-bounces@ietf.org Thomas Pornin writes: >As per RFC 5280 rules, your path shall be considered as valid. You really need to qualify this a bit more, although I guess the "as per RFC 5280 rules" is one qualification :-). The real-life version though is: If the implementation ignores path-length constraints, it's valid. If the implementation doesn't ignore path-length constraints and pays attention to extensions in root certs, it's not valid. If the implementation doesn't ignore path-length constraints but ignores extensions in TAs, it's back to not valid again. A more succint summary would be: It's a coin-toss. I guess it all comes down to whether the original poster was interested in what's valid in theory vs. what will actually happen in practice. Peter. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From carl@redhoundsoftware.com Thu Apr 14 05:03:43 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2F8FFE073A for ; Thu, 14 Apr 2011 05:03:43 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVQ7CWJwlpH0 for ; Thu, 14 Apr 2011 05:03:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9C51AE076D for ; Thu, 14 Apr 2011 05:03:42 -0700 (PDT) Received: by qwc23 with SMTP id 23so1102878qwc.31 for ; Thu, 14 Apr 2011 05:03:42 -0700 (PDT) Received: by 10.224.125.134 with SMTP id y6mr451901qar.135.1302782622218; Thu, 14 Apr 2011 05:03:42 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-111-27.washdc.fios.verizon.net [173.79.111.27]) by mx.google.com with ESMTPS id m13sm1124211qcu.4.2011.04.14.05.03.40 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 05:03:41 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 14 Apr 2011 08:03:36 -0400 From: Carl Wallace To: Tom Gindin , Peter Gutmann Message-ID: Thread-Topic: [pkix] clarification of pathLenConstraint In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] clarification of pathLenConstraint 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, 14 Apr 2011 12:03:43 -0000 On 4/14/11 7:49 AM, "Tom Gindin" wrote: > Here's mine - there's no point in putting path length constraints >into self-signed certificates unless you expect them to be processed by >an >engine which implements an initial value for path length. RFC 5280 >doesn't really favor such engines, although RFC 5914 does allow path >length in the CertPathControls structure. That extension in a >self-signed >certificate is almost meaningless to a 5280 engine. > Maybe we should put an extra variable for the length into RFC >5280 >6.1.1 and change 6.1.2-k to use it. I would say that you could >initialize >max_path_length to 32K-1 (or "a positive integer greater than any path >length supported by the validation engine") as easily as to N, since the >only thing that matters about its value is it staying positive. RFC 5937 describes how to use the path length value from a TA during path processing. From anders.rundgren@telia.com Sat Apr 16 01:41:02 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4E9CEE0675 for ; Sat, 16 Apr 2011 01:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIxB1IXg1r3i for ; Sat, 16 Apr 2011 01:41:01 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfc.amsl.com (Postfix) with ESMTP id 879C0E06C9 for ; Sat, 16 Apr 2011 01:41:01 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D65154400F8F239 for pkix@ietf.org; Sat, 16 Apr 2011 10:41:00 +0200 Message-ID: <4DA9562C.9070701@telia.com> Date: Sat, 16 Apr 2011 10:41:16 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] NSTIC - On-line Enrollment 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, 16 Apr 2011 08:41:02 -0000 http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf I'm generally skeptical about government initiatives but since the industry have screwed-up big-time when it comes to interoperable and useful on-line enrollment schemes this may indeed be the catalyst needed. Unlike the EU-centric ETSI efforts which has limited industry traction, NSTIC will presumably be supported by the nowadays only three US vendors that effectively define some 98% of our personal computing platforms. There are currently more questions than answers but that's OK :-) --Anders From stephen.farrell@cs.tcd.ie Mon Apr 18 05:05:09 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F241E07C2; Mon, 18 Apr 2011 05:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.17 X-Spam-Level: X-Spam-Status: No, score=-105.17 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxFBLLujV1bz; Mon, 18 Apr 2011 05:05:05 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id E9340E067D; Mon, 18 Apr 2011 05:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E55A2171C6A; Mon, 18 Apr 2011 13:05:01 +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=1303128296; bh=TFwrScYiaorvxR kWL397NEjui24sdgUMVa+a+RFaeHM=; b=Wvqi6t47gDu2ER0R/KY9mqxXVA1sRb KXv6sFl5qM2k1PZ8gKI2fLdNjii84gdYaUtGtFDNMM7R4qJaAeLWBD/o/cAm7cMb +ucvxJZazn70Z4Djp+FQETma5Qdf2y+L40SXIRRVQFUZV9k40XW/SiyjnwIeCEsA UPusfz29YZoldmYVts0iBeKkn4v7I077owtdcIwHj8HqhtYs6gXXZFjErRL2nWWN a4W/fbi22SYrxPdXqZwus2kbiM27K8FNqGUecnTlIcNFp132vslmclrPVpUulOI0 /C8lpSUdj1JjhAWCN1Ay5BRFLqOuJ1N7aXsbi7aDrUCRMb0kg1jB8lkg== 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 FmGRAwv8SLM7; Mon, 18 Apr 2011 13:04:56 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B6F6D171C69; Mon, 18 Apr 2011 13:04:56 +0100 (IST) Message-ID: <4DAC28E7.2070602@cs.tcd.ie> Date: Mon, 18 Apr 2011 13:04:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Stephen Kent References: <201104122204.p3CM4cCu005416@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: pkix , dane@ietf.org Subject: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 18 Apr 2011 12:05:09 -0000 Sorry to drag this out but I think its worth being clear as to where the possible disagreement lies since that might influence how dane approaches handling TLS servers with these kind of self-signed data structures. On 15/04/11 18:00, Stephen Kent wrote: > 5280 is not silent on this topic. This is where one of the pkix chairs and one of the authors of 5280 (me:-) disagree. "This topic" is whether or not self-signed x.509 structures that are not for CAs are "covered" by 5280. I believe Steve is saying that 5280 says that such things are not allowed, whereas I believe that 5280 says nothing about them. I guess we both believe our interpretation is the right one:-) > It says that a certificate is either > and EE certificate of a CA certificate, and that CA certificates are of > 3 types, one of which is self-signed. This is pretty clearly a partition > of X.509 certificates in to EE and CA, and a further delineation of > types of CA certificates. there is no ambiguity here, nor did I > "misread" the RFC. Disagree. Quoting (end of p12): This specification covers two classes of certificates: CA certificates and end entity certificates. CA certificates may be further divided into three classes: cross-certificates, self-issued certificates, and self-signed certificates. That says that some CA certs are self-signed. It does not say that all self-signed certs are CA certs. It does not partition EE certs into any classes at all. A little further down it says that: Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations. Self- signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths. I recall this being added as a result of some confusion as to what a self-issued vs. self-signed cert might be. I do not recall it being added as anything normative (indeed there is no 2119 language there). In any case, in context, it clearly is only referring to CA certs since those are the only kind for which different (informative) classes are called out. And finally: End entity certificates are issued to subjects that are not authorized to issue certificates. So I think in 5280 terms its probably fair to say that the term "self-signed end entity cert" is a bit of a misnomer. However, that is at this stage a fairly well understood term so I'm not sure if we'll benefit from trying to get folks to use a different term. > I am aware of no text in 5280 or in X.509 that > suggests a self-signed certificate is anything other than a CA certificate. That's consistent with either interpretation. So I also took a look at the pkix list archives, and found only one relevant thread from 2004 that unfortunately doesn't really help. [1] [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html I also found some offlist mail from the design team that we had to develop 3280bis (which became 5280). It just says: "Harmonize language in path validation. Some places used the defined term “self-issued” certificate while some places states the requirement that subject and issuer names are identical. These definitions differ since the term “self-issued” also requires that names must be non-empty." (That was issue#65 in a spreadsheet Dave Cooper constructed collecting issues for 3280bis dated Jan 14 2005, not sure if there's a public archive for that 3280bis@nist.gov list or not.) So again that doesn't help us here. I didn't find any other mails with "self" in the subject line from my copy of the 3280bis design team mails. My conclusion is that neither 5280 nor the pkix archives justify any conclusion about self-signed end-entity certs. I guess if more consideration of this is needed, we should move the discussion to pkix alone, until there's a conclusion that dane can use. (So if following up on just the pkix aspect, removing dane from the cc list is probably the right thing to do.) To the extent it helps, the W3C web security context WG did also consider this topic, and included text in their recommendation about self-signed certs. [2] I think that clearly shows that that group did envisage the use of this kind of thing for some web servers. (I was involved in that group as an invited expert, but I don't recall this particular aspect being in any way controversial there. There was debate about what to do with such things, but not about the terminology that I recall.) [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts Stephen. PS: Note that Steve's on vacation so this might just sit for a few weeks until he's back to argue his side of the issue. From stefan@aaa-sec.com Mon Apr 18 14:26:41 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 95BE2E074D for ; Mon, 18 Apr 2011 14:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.992 X-Spam-Level: X-Spam-Status: No, score=-101.992 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSEXOv2fvo9G for ; Mon, 18 Apr 2011 14:26:40 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfc.amsl.com (Postfix) with ESMTP id 9E402E073D for ; Mon, 18 Apr 2011 14:26:39 -0700 (PDT) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B18543518A2 for ; Mon, 18 Apr 2011 23:08:17 +0200 (CEST) Received: (qmail 52174 invoked from network); 18 Apr 2011 21:08:09 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Apr 2011 21:08:09 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Mon, 18 Apr 2011 23:08:06 +0200 From: Stefan Santesson To: Stephen Kent , Patrick Patterson Message-ID: Thread-Topic: [pkix] New draft for consideration as a work item. In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386012889_466167" Cc: pkix Subject: Re: [pkix] New draft for consideration as a work item. 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, 18 Apr 2011 21:26:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3386012889_466167 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Patrick, As Stephen says, this document needs more motivation. EKU is a useful tool in PKIs where multiple types of certificates are used. I don't see that this is a typical case for a federation. It is common that the trust in IdP public keys are either by direct trust (OOB pre-configuration) or by means of signed metadata, signed by the federation operator. In neither case is an EKU necessary for the operation. It would therefore be useful to know more about the use case where you see this come into play. Further. It is common to define specific application specific EKUs in a WG dealing with the need of this application rather than doing it in PKIX. Is this possibly something more suitable for the abfab WG? ASN.1 OIDs are not assigned by IANA, so the IANA section is not correct. I guess Russ still maintains the PKIX arc. Definition of an EKU also requires an ASN.1 section with an ASN.1 module for import into compilers and other specs. /Stefan From: Stephen Kent Date: Tue, 5 Apr 2011 11:39:11 -0400 To: Patrick Patterson Cc: pkix Subject: Re: [pkix] New draft for consideration as a work item. > At 11:06 AM -0400 3/31/11, Patrick Patterson wrote: >> Hello all: >> >> A new version of I-D, draft-patterson-pkix-attribute-signing-eku-00.txt has >> been successfully submitted by Patrick Patterson and posted to the IETF >> repository. >> Filename: draft-patterson-pkix-attribute-signing-eku >> Revision: 00 >> Title: attributeSigning extendedKeyUsage value >> Creation_date: 2011-03-28 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> This document specifies a value for the extendedKeyUsage X.509 >> extension that may be used to create a certificate that would be used >> to sign attribute assertions. This allows the differentiation of >> certificates used to identify a particular server (which would have a >> serverAuth EKU), from the certificate used by that server to sign >> attribute assertions, and would easily allow a policy to be developed >> for issuance of such a certificate to an identity provider. >> >> >> I would ask that the above be considered as a new work item for this group. >> Thank you. > > I think you need to cite some examples of how this would be used and > why it's important, to motivate this feature. Also, the doc contains the > following text: > > " ... Federation Enabler Certification Authority for issuing certificates to > Identity Providers or Attribute Providers in a WS-Fed or SAML federation." > > This set of terms is not defined anywhere in the doc, nor is there a reference > to other docs that would explain them. So a lot more context is needed for > me to understand what you're talking about. > > The Secruity Considerations section should be "TBD" at this stage, if > you have nothing concrete to say. "None" is NOT acceptable for this doc :-). > > Steve > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3386012889_466167 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Patrick,

As Stephen says, this document needs more motivation.

EKU is a useful tool in PKIs where multiple types of certificates a= re used.

I don't see that this is a typical case fo= r a federation. It is common that the trust in IdP public keys are either by= direct trust (OOB pre-configuration) or by means of signed metadata, signed= by the federation operator. In neither case is an EKU necessary for the ope= ration.

It would therefore be useful to know more a= bout the use case where you see this come into play.

Further. It is common to define specific application specific EKUs in a WG= dealing with the need of this application rather than doing it in PKIX. Is = this possibly something more suitable for the abfab WG?

=
ASN.1 OIDs are not assigned by IANA, so the IANA section is not correct= . I guess Russ still maintains the PKIX arc.

Defini= tion of an EKU also requires an ASN.1 section with an ASN.1 module for impor= t into compilers and other specs.

/Stefan


From: Stephen = Kent <kent@bbn.com>
Date: Tue, 5 Apr 2011 11:39:11 -0400
To: Patrick Patterson <ppatterson@carillon.ca>
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] New draf= t for consideration as a work item.

At 11:06 AM -0400 3/31/11, Patrick Patterson wrote:
Hello all:

A new version of I-D, draft-patterson-pkix-attribute-signing-eku-00.txt has been successfully submitted by Patrick Patterson and posted to the IETF repository.
Filename:       draft-patterson-pkix-attribute-signing-eku
Revision:    00
Title:               attributeSigning extendedKeyUsage value
Creation_date:  2011-03-28
WG ID:               Independent Submission
Number_of_pages: 8

Abstract:
This document specifies a value for the extendedKeyUsage X.509
extension that may be used to create a certificate that would be used
to sign attribute assertions.  This allows the differentiation of
certificates used to identify a particular server (which would have a
serverAuth EKU), from the certificate used by that server to sign
attribute assertions, and would easily allow a policy to be developed
for issuance of such a certificate to an identity provider.


I would ask that the above be considered as a new work item for this group.
Thank you.

I think you need to cite some examples of how this wo= uld be used and
why it's important, to motivate this feature.  Also, the= doc contains the following text:

" ... Federation Enabler Certification Authority for issuing certificates to <= /font> Identity Providers or Attribute Providers in a WS-Fed or SAML federation."

<= font color=3D"#000000">This set of terms is not defined anywhere in the doc, nor is there a reference to other docs that would explain them. So a lot more context is needed for
me to understand what you're talking about.

The Secruity Considerations section should be "TBD" at this stage, if
you have = nothing concrete to say.  "None" is NOT acceptable for this doc :-).

Steve
<= /div>_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3386012889_466167-- From stefan@aaa-sec.com Mon Apr 18 14:26:41 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E91C1E0681 for ; Mon, 18 Apr 2011 14:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.667 X-Spam-Level: X-Spam-Status: No, score=-102.667 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tthzz5FzX7N2 for ; Mon, 18 Apr 2011 14:26:39 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfc.amsl.com (Postfix) with ESMTP id 9E59AE074B for ; Mon, 18 Apr 2011 14:26:39 -0700 (PDT) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B0F9F56942C for ; Mon, 18 Apr 2011 23:12:39 +0200 (CEST) Received: (qmail 2280 invoked from network); 18 Apr 2011 21:12:31 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Apr 2011 21:12:31 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Mon, 18 Apr 2011 23:12:26 +0200 From: Stefan Santesson To: Stefan Santesson , Stephen Kent , Message-ID: Thread-Topic: [pkix] Concluding OCSP Agility In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Concluding OCSP Agility 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, 18 Apr 2011 21:26:42 -0000 OK, So there are absolutely no opinions on this from PKIX members. I had hoped otherwise. I guess that is not enough strong voices for doing a change to the document. However. As long as the document has not passed Auth 48 the window for change is still open. Those feeling we need a change are encouraged to raise their voice. /Stefan On 11-04-04 10:39 PM, "Stefan Santesson" wrote: >I will start off by saying that I'm divided. > >I see the logic in Jim's arguments but liked the fact that the current >algorithm identifier directly maps to the identifiers that are specified >in other protocols which makes the mapping easier and possibly less error >prone when implemented. > >I hope this LC will reveal some good arguments for either solution. > >/Stefan > > >On 11-04-04 9:48 PM, "Stephen Kent" wrote: > >>Folks, >> >>Jim made a good argument why SMIMECapabilties might be preferable to >>AlgID >>in the context of advertising which algs are supported. At the PKIX >>meeting >>the ADs suggested that if we wanted to make this change to the OCSP >>agility doc (now in the RFC Editor's queue), that they would support >>this as a trivial >>change, not requiring a new IETF LC, etc. (This is justified because >>only one alg would be different in a bits-on-the-wire sense, and it >>is not clear that we care about it anyway.) >> >>So, I am now starting a 1-week LC on this issue. The LC will end >>Tuesday morning, 4/12. >> >>Steve >> >>>... >>>I realize that I am late on this. >>> >>>The definition that I use for these two types are: >>> >>>SMIMECapabilities is what party A uses to request that party B uses >>>one of a set of algorithms in talking to it. >>> >>>AlgorithmIdentifier is what party A uses to tell party B what >>>algorithm is actually being used. >>> >>>This separation makes it clear (at least to me) exactly when one >>>should use each of these items. >>> >>>Jim >>> >>_______________________________________________ >>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 stefan@aaa-sec.com Mon Apr 18 14:29:00 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8CC95E073D for ; Mon, 18 Apr 2011 14:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.75 X-Spam-Level: X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1hAUIxyjv63 for ; Mon, 18 Apr 2011 14:28:59 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfc.amsl.com (Postfix) with ESMTP id 0D10DE06E1 for ; Mon, 18 Apr 2011 14:28:59 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id EB0802BDBFE for ; Mon, 18 Apr 2011 23:29:06 +0200 (CEST) Received: (qmail 22694 invoked from network); 18 Apr 2011 21:28:58 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Apr 2011 21:28:58 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Mon, 18 Apr 2011 23:28:53 +0200 From: Stefan Santesson To: Stephen Farrell , Stephen Kent Message-ID: Thread-Topic: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) In-Reply-To: <4DAC28E7.2070602@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: pkix , dane@ietf.org Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 18 Apr 2011 21:29:00 -0000 Stephen, So let me land somewhere in-between. I understand what you mean by self-signed end-entity certs, but the term is misleading. A self signed cert is simply a convenient way to communicate a public key for an entity that has not been certified by a CA. I would say that it is a self signed cert. Period. Disregarding what type of entity it represents. The internet is full of them. Denying their valid existence does not help anyone. As far as RFC 5280 goes, it only deals with these certificates when used as trust anchors in path validation. When self-signed certificates are found in e.g. Signed metadata of an identity federation, that federation may have its own conventions regarding their use. They are not subject to 5280 path validation so all of that is out of scope. /Stefan On 11-04-18 2:04 PM, "Stephen Farrell" wrote: > >Sorry to drag this out but I think its worth being clear as to >where the possible disagreement lies since that might influence >how dane approaches handling TLS servers with these kind of >self-signed data structures. > >On 15/04/11 18:00, Stephen Kent wrote: >> 5280 is not silent on this topic. > >This is where one of the pkix chairs and one of the authors >of 5280 (me:-) disagree. "This topic" is whether or not >self-signed x.509 structures that are not for CAs are >"covered" by 5280. I believe Steve is saying that 5280 says >that such things are not allowed, whereas I believe that >5280 says nothing about them. I guess we both believe our >interpretation is the right one:-) > >> It says that a certificate is either >> and EE certificate of a CA certificate, and that CA certificates are of >> 3 types, one of which is self-signed. This is pretty clearly a partition >> of X.509 certificates in to EE and CA, and a further delineation of >> types of CA certificates. there is no ambiguity here, nor did I >> "misread" the RFC. > >Disagree. Quoting (end of p12): > > This specification covers two classes of certificates: CA > certificates and end entity certificates. CA certificates may be > further divided into three classes: cross-certificates, self-issued > certificates, and self-signed certificates. > >That says that some CA certs are self-signed. It does not say that >all self-signed certs are CA certs. It does not partition EE certs >into any classes at all. > >A little further down it says that: > > Self-issued certificates are CA certificates in which > the issuer and subject are the same entity. Self-issued certificates > are generated to support changes in policy or operations. Self- > signed certificates are self-issued certificates where the digital > signature may be verified by the public key bound into the > certificate. Self-signed certificates are used to convey a public > key for use to begin certification paths. > >I recall this being added as a result of some confusion as to what >a self-issued vs. self-signed cert might be. I do not recall it being >added as anything normative (indeed there is no 2119 language there). >In any case, in context, it clearly is only referring to CA certs >since those are the only kind for which different (informative) >classes are called out. > >And finally: > > End entity certificates > are issued to subjects that are not authorized to issue certificates. > >So I think in 5280 terms its probably fair to say that the term >"self-signed end entity cert" is a bit of a misnomer. However, that >is at this stage a fairly well understood term so I'm not sure if >we'll benefit from trying to get folks to use a different term. > >> I am aware of no text in 5280 or in X.509 that >> suggests a self-signed certificate is anything other than a CA >>certificate. > >That's consistent with either interpretation. > >So I also took a look at the pkix list archives, and found only one >relevant thread from 2004 that unfortunately doesn't really help. [1] > > [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html > >I also found some offlist mail from the design team that we had to >develop 3280bis (which became 5280). It just says: > > "Harmonize language in path validation. Some places used the defined > term =B3self-issued=B2 certificate while some places states the > requirement that subject and issuer names are identical. These > definitions differ since the term =B3self-issued=B2 also requires that > names must be non-empty." (That was issue#65 in a spreadsheet > Dave Cooper constructed collecting issues for 3280bis dated > Jan 14 2005, not sure if there's a public archive for that > 3280bis@nist.gov list or not.) > >So again that doesn't help us here. I didn't find any other mails >with "self" in the subject line from my copy of the 3280bis design >team mails. > >My conclusion is that neither 5280 nor the pkix archives justify >any conclusion about self-signed end-entity certs. > >I guess if more consideration of this is needed, we should move >the discussion to pkix alone, until there's a conclusion that dane >can use. (So if following up on just the pkix aspect, removing >dane from the cc list is probably the right thing to do.) > >To the extent it helps, the W3C web security context WG did also >consider this topic, and included text in their recommendation about >self-signed certs. [2] I think that clearly shows that that group >did envisage the use of this kind of thing for some web servers. >(I was involved in that group as an invited expert, but I don't >recall this particular aspect being in any way controversial there. >There was debate about what to do with such things, but not about >the terminology that I recall.) > > [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts > >Stephen. > >PS: Note that Steve's on vacation so this might just sit for a >few weeks until he's back to argue his side of the issue. > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From hallam@gmail.com Mon Apr 18 15:00:16 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2E59CE081E; Mon, 18 Apr 2011 15:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6dUpfBzt0Ai; Mon, 18 Apr 2011 15:00:14 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id E550EE06F7; Mon, 18 Apr 2011 15:00:13 -0700 (PDT) Received: by vxg33 with SMTP id 33so4830374vxg.31 for ; Mon, 18 Apr 2011 15:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uouoW07oAvmQho6cociz6Waf5fOZ5Gy28SoO2tujrPQ=; b=hZ5ycQM2+zahBI4rnMnv+UdGA26E1DBKJ962lLuV89AHMtFbsEZpH3xsqcVQDhUABs Quuwm1Dkupz2acfaS2N4Dsc5RAzFvX8kG5uFaiWqbJWjHtJJssYJqiRWIfnfSNwruFKc cIq7B3omww4i5ePqs+85nLs3jCG6BAVAq1bsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jg8M6+BpJ2vY983/LGkMk20wlhVjEgezzSvZFW/ARYHCkEKrgW/2RIIPia4OvFLulh DrqIT0R8VXpKtP7WgbC50gibMhjhcm1yV/0E+2yb8FeVGLvkjjSXiSCHANHKMG0l6eJ8 GJJT8mEUySiUfJGbBuv+EhKqaJxjpSF8XU9zE= MIME-Version: 1.0 Received: by 10.52.69.2 with SMTP id a2mr8368454vdu.5.1303164013537; Mon, 18 Apr 2011 15:00:13 -0700 (PDT) Received: by 10.52.161.3 with HTTP; Mon, 18 Apr 2011 15:00:13 -0700 (PDT) In-Reply-To: References: <4DAC28E7.2070602@cs.tcd.ie> Date: Mon, 18 Apr 2011 18:00:13 -0400 Message-ID: From: Phillip Hallam-Baker To: Stefan Santesson Content-Type: multipart/alternative; boundary=20cf30780e6e1c6a9004a1388481 Cc: pkix , dane@ietf.org Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: [keyassure] Use cases document.) 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, 18 Apr 2011 22:00:16 -0000 --20cf30780e6e1c6a9004a1388481 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that Kent is right on what the spec says. But the standard is set by the consensus and the running code which recognize self-signed certs.. I see the following courses of action as being open: D1) DANE says nothing at all about this issue in the DANE spec (I see no reason it need be mentioned at all). D2) DANE says that the EE cert can be a self signed EE cert in accordance with customary Internet usage P1) PKIX writes draft on how to specify self signed EE certs so that this i= s properly understood. I.E. relying applications MUST NOT rely on any claims other than the POP of the key and any restrictions on validity/usage. P2) PKIX ignores the issue. Note that D1/2 and P1/2 are orthogonal. These certs exist and I can't see there being a consensus likely to emerge to require a chain with a CA cert at the head. Nor can I see a requirement to introduce a downref to X.509v1 to try to circumvent this. On Mon, Apr 18, 2011 at 5:28 PM, Stefan Santesson wrote= : > Stephen, > > So let me land somewhere in-between. > > I understand what you mean by self-signed end-entity certs, but the term > is misleading. > > A self signed cert is simply a convenient way to communicate a public key > for an entity that has not been certified by a CA. > I would say that it is a self signed cert. Period. Disregarding what type > of entity it represents. > > The internet is full of them. Denying their valid existence does not help > anyone. > As far as RFC 5280 goes, it only deals with these certificates when used > as trust anchors in path validation. > > When self-signed certificates are found in e.g. Signed metadata of an > identity federation, that federation may have its own conventions > regarding their use. They are not subject to 5280 path validation so all > of that is out of scope. > > /Stefan > > > > On 11-04-18 2:04 PM, "Stephen Farrell" wrote: > > > > >Sorry to drag this out but I think its worth being clear as to > >where the possible disagreement lies since that might influence > >how dane approaches handling TLS servers with these kind of > >self-signed data structures. > > > >On 15/04/11 18:00, Stephen Kent wrote: > >> 5280 is not silent on this topic. > > > >This is where one of the pkix chairs and one of the authors > >of 5280 (me:-) disagree. "This topic" is whether or not > >self-signed x.509 structures that are not for CAs are > >"covered" by 5280. I believe Steve is saying that 5280 says > >that such things are not allowed, whereas I believe that > >5280 says nothing about them. I guess we both believe our > >interpretation is the right one:-) > > > >> It says that a certificate is either > >> and EE certificate of a CA certificate, and that CA certificates are o= f > >> 3 types, one of which is self-signed. This is pretty clearly a partiti= on > >> of X.509 certificates in to EE and CA, and a further delineation of > >> types of CA certificates. there is no ambiguity here, nor did I > >> "misread" the RFC. > > > >Disagree. Quoting (end of p12): > > > > This specification covers two classes of certificates: CA > > certificates and end entity certificates. CA certificates may be > > further divided into three classes: cross-certificates, self-issued > > certificates, and self-signed certificates. > > > >That says that some CA certs are self-signed. It does not say that > >all self-signed certs are CA certs. It does not partition EE certs > >into any classes at all. > > > >A little further down it says that: > > > > Self-issued certificates are CA certificates in which > > the issuer and subject are the same entity. Self-issued certificates > > are generated to support changes in policy or operations. Self- > > signed certificates are self-issued certificates where the digital > > signature may be verified by the public key bound into the > > certificate. Self-signed certificates are used to convey a public > > key for use to begin certification paths. > > > >I recall this being added as a result of some confusion as to what > >a self-issued vs. self-signed cert might be. I do not recall it being > >added as anything normative (indeed there is no 2119 language there). > >In any case, in context, it clearly is only referring to CA certs > >since those are the only kind for which different (informative) > >classes are called out. > > > >And finally: > > > > End entity certificates > > are issued to subjects that are not authorized to issue certificates. > > > >So I think in 5280 terms its probably fair to say that the term > >"self-signed end entity cert" is a bit of a misnomer. However, that > >is at this stage a fairly well understood term so I'm not sure if > >we'll benefit from trying to get folks to use a different term. > > > >> I am aware of no text in 5280 or in X.509 that > >> suggests a self-signed certificate is anything other than a CA > >>certificate. > > > >That's consistent with either interpretation. > > > >So I also took a look at the pkix list archives, and found only one > >relevant thread from 2004 that unfortunately doesn't really help. [1] > > > > [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html > > > >I also found some offlist mail from the design team that we had to > >develop 3280bis (which became 5280). It just says: > > > > "Harmonize language in path validation. Some places used the defined > > term =B3self-issued=B2 certificate while some places states the > > requirement that subject and issuer names are identical. These > > definitions differ since the term =B3self-issued=B2 also requires th= at > > names must be non-empty." (That was issue#65 in a spreadsheet > > Dave Cooper constructed collecting issues for 3280bis dated > > Jan 14 2005, not sure if there's a public archive for that > > 3280bis@nist.gov list or not.) > > > >So again that doesn't help us here. I didn't find any other mails > >with "self" in the subject line from my copy of the 3280bis design > >team mails. > > > >My conclusion is that neither 5280 nor the pkix archives justify > >any conclusion about self-signed end-entity certs. > > > >I guess if more consideration of this is needed, we should move > >the discussion to pkix alone, until there's a conclusion that dane > >can use. (So if following up on just the pkix aspect, removing > >dane from the cc list is probably the right thing to do.) > > > >To the extent it helps, the W3C web security context WG did also > >consider this topic, and included text in their recommendation about > >self-signed certs. [2] I think that clearly shows that that group > >did envisage the use of this kind of thing for some web servers. > >(I was involved in that group as an invited expert, but I don't > >recall this particular aspect being in any way controversial there. > >There was debate about what to do with such things, but not about > >the terminology that I recall.) > > > > [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts > > > >Stephen. > > > >PS: Note that Steve's on vacation so this might just sit for a > >few weeks until he's back to argue his side of the issue. > > > >_______________________________________________ > >pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --20cf30780e6e1c6a9004a1388481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that Kent is right on what the spec says.

But th= e standard is set by the consensus and the running code which recognize sel= f-signed certs..


I see the followin= g courses of action as being open:

D1) DANE says nothing at all about this issue in the DA= NE spec (I see no reason it need be mentioned at all).

=
D2) DANE says that the EE cert can be a self signed EE cert in accorda= nce with customary Internet usage

P1) PKIX writes draft on how to specify self signed EE = certs so that this is properly understood. I.E. relying applications MUST N= OT rely on any claims other than the POP of the key and any restrictions on= validity/usage.=A0

P2) PKIX ignores the issue.

No= te that D1/2 and P1/2 are orthogonal.


These certs exist and I can't see there being a consensus likely to = emerge to require a chain with a CA cert at the head. Nor can I see a requi= rement to introduce a downref to X.509v1 to try to circumvent this.



On Mon, A= pr 18, 2011 at 5:28 PM, Stefan Santesson <stefan@aaa-sec.com> wrote:
Stephen,

So let me land somewhere in-between.

I understand what you mean by self-signed end-entity certs, but the term is misleading.

A self signed cert is simply a convenient way to communicate a public key for an entity that has not been certified by a CA.
I would say that it is a self signed cert. Period. Disregarding what type of entity it represents.

The internet is full of them. Denying their valid existence does not help anyone.
As far as RFC 5280 goes, it only deals with these certificates when used as trust anchors in path validation.

When self-signed certificates are found in e.g. Signed metadata of an
identity federation, that federation may have its own conventions
regarding their use. They are not subject to 5280 path validation so all of that is out of scope.

/Stefan



On 11-04-18 2:04 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:

>
>Sorry to drag this out but I think its worth being clear as to
>where the possible disagreement lies since that might influence
>how dane approaches handling TLS servers with these kind of
>self-signed data structures.
>
>On 15/04/11 18:00, Stephen Kent wrote:
>> 5280 is not silent on this topic.
>
>This is where one of the pkix chairs and one of the authors
>of 5280 (me:-) disagree. "This topic" is whether or not
>self-signed x.509 structures that are not for CAs are
>"covered" by 5280. I believe Steve is saying that 5280 says >that such things are not allowed, whereas I believe that
>5280 says nothing about them. I guess we both believe our
>interpretation is the right one:-)
>
>> It says that a certificate is either
>> and EE certificate of a CA certificate, and that CA certificates a= re of
>> 3 types, one of which is self-signed. This is pretty clearly a par= tition
>> of X.509 certificates in to EE and CA, and a further delineation o= f
>> types of CA certificates. there is no ambiguity here, nor did I >> "misread" the RFC.
>
>Disagree. Quoting (end of p12):
>
> =A0 This specification covers two classes of certificates: CA
> =A0 certificates and end entity certificates. =A0CA certificates may b= e
> =A0 further divided into three classes: cross-certificates, self-issue= d
> =A0 certificates, and self-signed certificates.
>
>That says that some CA certs are self-signed. It does not say that
>all self-signed certs are CA certs. It does not partition EE certs
>into any classes at all.
>
>A little further down it says that:
>
> =A0 Self-issued certificates are CA certificates in which
> =A0 the issuer and subject are the same entity. =A0Self-issued certifi= cates
> =A0 are generated to support changes in policy or operations. =A0Self-=
> =A0 signed certificates are self-issued certificates where the digital=
> =A0 signature may be verified by the public key bound into the
> =A0 certificate. =A0Self-signed certificates are used to convey a publ= ic
> =A0 key for use to begin certification paths.
>
>I recall this being added as a result of some confusion as to what
>a self-issued vs. self-signed cert might be. I do not recall it being >added as anything normative (indeed there is no 2119 language there). >In any case, in context, it clearly is only referring to CA certs
>since those are the only kind for which different (informative)
>classes are called out.
>
>And finally:
>
> =A0 End entity certificates
> =A0 are issued to subjects that are not authorized to issue certificat= es.
>
>So I think in 5280 terms its probably fair to say that the term
>"self-signed end entity cert" is a bit of a misnomer. However= , that
>is at this stage a fairly well understood term so I'm not sure if >we'll benefit from trying to get folks to use a different term.
>
>> I am aware of no text in 5280 or in X.509 that
>> suggests a self-signed certificate is anything other than a CA
>>certificate.
>
>That's consistent with either interpretation.
>
>So I also took a look at the pkix list archives, and found only one
>relevant thread from 2004 that unfortunately doesn't really help. [= 1]
>
> =A0 [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01= 611.html
>
>I also found some offlist mail from the design team that we had to
>develop 3280bis (which became 5280). It just says:
>
> =A0 "Harmonize language in path validation. Some places used the = defined
> =A0 =A0term =B3self-issued=B2 certificate while some places states the=
> =A0 =A0requirement that subject and issuer names are identical. These<= br> > =A0 =A0definitions differ since the term =B3self-issued=B2 also requir= es that
> =A0 =A0names must be non-empty." (That was issue#65 in a spreadsh= eet
> =A0 =A0Dave Cooper constructed collecting issues for 3280bis dated
> =A0 =A0Jan 14 2005, not sure if there's a public archive for that<= br> > =A0 =A03280bis@nist.gov list o= r not.)
>
>So again that doesn't help us here. I didn't find any other mai= ls
>with "self" in the subject line from my copy of the 3280bis d= esign
>team mails.
>
>My conclusion is that neither 5280 nor the pkix archives justify
>any conclusion about self-signed end-entity certs.
>
>I guess if more consideration of this is needed, we should move
>the discussion to pkix alone, until there's a conclusion that dane<= br> >can use. (So if following up on just the pkix aspect, removing
>dane from the cc list is probably the right thing to do.)
>
>To the extent it helps, the W3C web security context WG did also
>consider this topic, and included text in their recommendation about >self-signed certs. [2] I think that clearly shows that that group
>did envisage the use of this kind of thing for some web servers.
>(I was involved in that group as an invited expert, but I don't
>recall this particular aspect being in any way controversial there.
>There was debate about what to do with such things, but not about
>the terminology that I recall.)
>
> =A0 [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts
>
>Stephen.
>
>PS: Note that Steve's on vacation so this might just sit for a
>few weeks until he's back to argue his side of the issue.
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix


_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--20cf30780e6e1c6a9004a1388481-- From mrex@sap.com Mon Apr 18 15:49:37 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CCB2E085A; Mon, 18 Apr 2011 15:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.701 X-Spam-Level: X-Spam-Status: No, score=-9.701 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f49-sxJ6PfxY; Mon, 18 Apr 2011 15:49:36 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 34016E084C; Mon, 18 Apr 2011 15:49:36 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3IMnSBI019261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 00:49:32 +0200 (MEST) From: Martin Rex Message-Id: <201104182249.p3IMnS6u029126@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Tue, 19 Apr 2011 00:49:28 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Apr 18, 11 06:00:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: stefan@aaa-sec.com, dane@ietf.org, pkix@ietf.org Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: 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: Mon, 18 Apr 2011 22:49:37 -0000 Phillip Hallam-Baker wrote: > > But the standard is set by the consensus and the running code which > recognize self-signed certs.. > > > I see the following courses of action as being open: > > D1) DANE says nothing at all about this issue in the DANE spec (I see no > reason it need be mentioned at all). > > D2) DANE says that the EE cert can be a self signed EE cert in accordance > with customary Internet usage > > P1) PKIX writes draft on how to specify self signed EE certs so that this is > properly understood. I.E. relying applications MUST NOT rely on any claims > other than the POP of the key and any restrictions on validity/usage. > > P2) PKIX ignores the issue. > > Note that D1/2 and P1/2 are orthogonal. > > > These certs exist and I can't see there being a consensus likely to emerge > to require a chain with a CA cert at the head. I have very little experience with / exposure to the discussions in the PKIX WG, so I don't know how much I like (P1). >From the data collected by EFF, there appear to be ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet with the BasicConstraint cA=TRUE ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet ~ 56000 self-signed X.509v3 Web Server certs installed on the internet without the BasicConstraint cA=TRUE There may be a much higher number of use case for self-signed certs on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're probably irrelevant for DANE because most are on private IP-Addresses and don't use officially registered DNS domains on their internal networks. > > Nor can I see a requirement > to introduce a downref to X.509v1 to try to circumvent this. I do not see the particular gripe that you have with X.509v1. X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard. The beauty of X.509v1 certs is that they're *MUCH* easier to create and hard to get wrong in an interop-impairing fashion. And, the biggest advantage: enforcing a rule "do not accept as signers of other certs" is trivial and fool-proof to implement, so that you don't create immediate and serious problems when you add such certs to the list of trusted keys for your PKI software along with Trust Anchors from commercial CAs. When you mix up self-signed CA certs from some web-servers into the list of trusted keys next to rootCAs from commercial CAs, then you may put yourself at risk today. But what are you real options today, with programmatic clients? Either disable the peer certificate check entirely, or add some peers self-signed certs to the same file as the self-signed certs of the commercial rootCAs. -Martin From stefan@aaa-sec.com Tue Apr 19 00:46:10 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 194CEE06C4 for ; Tue, 19 Apr 2011 00:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEFPMMh4BR63 for ; Tue, 19 Apr 2011 00:46:09 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfc.amsl.com (Postfix) with ESMTP id 1659BE0655 for ; Tue, 19 Apr 2011 00:46:09 -0700 (PDT) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4E083346DAE for ; Tue, 19 Apr 2011 09:45:42 +0200 (CEST) Received: (qmail 19999 invoked from network); 19 Apr 2011 07:45:39 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Apr 2011 07:45:39 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 19 Apr 2011 09:45:37 +0200 From: Stefan Santesson To: , Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] [dane] 5280 and self-signed ee certs (was: Re: In-Reply-To: <201104182249.p3IMnS6u029126@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org, dane@ietf.org Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: 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, 19 Apr 2011 07:46:10 -0000 Martin, For self signed certs in general I think X.509 v1 certs are just fine. /Stefan On 11-04-19 12:49 AM, "Martin Rex" wrote: >Phillip Hallam-Baker wrote: >> >> But the standard is set by the consensus and the running code which >> recognize self-signed certs.. >> >> >> I see the following courses of action as being open: >> >> D1) DANE says nothing at all about this issue in the DANE spec (I see no >> reason it need be mentioned at all). >> >> D2) DANE says that the EE cert can be a self signed EE cert in >>accordance >> with customary Internet usage >> >> P1) PKIX writes draft on how to specify self signed EE certs so that >>this is >> properly understood. I.E. relying applications MUST NOT rely on any >>claims >> other than the POP of the key and any restrictions on validity/usage. >> >> P2) PKIX ignores the issue. >> >> Note that D1/2 and P1/2 are orthogonal. >> >> >> These certs exist and I can't see there being a consensus likely to >>emerge >> to require a chain with a CA cert at the head. > > >I have very little experience with / exposure to the discussions >in the PKIX WG, so I don't know how much I like (P1). > >From the data collected by EFF, there appear to be > > ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet > with the BasicConstraint cA=TRUE > ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet > > ~ 56000 self-signed X.509v3 Web Server certs installed on the internet > without the BasicConstraint cA=TRUE > >There may be a much higher number of use case for self-signed certs >on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're >probably irrelevant for DANE because most are on private IP-Addresses and >don't use officially registered DNS domains on their internal networks. > > >> >> Nor can I see a requirement >> to introduce a downref to X.509v1 to try to circumvent this. > >I do not see the particular gripe that you have with X.509v1. > >X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard. > > >The beauty of X.509v1 certs is that they're *MUCH* easier to create >and hard to get wrong in an interop-impairing fashion. > >And, the biggest advantage: enforcing a rule "do not accept as signers >of other certs" is trivial and fool-proof to implement, so that you >don't create immediate and serious problems when you add such >certs to the list of trusted keys for your PKI software along >with Trust Anchors from commercial CAs. > >When you mix up self-signed CA certs from some web-servers into the >list of trusted keys next to rootCAs from commercial CAs, then >you may put yourself at risk today. > >But what are you real options today, with programmatic clients? >Either disable the peer certificate check entirely, or add some >peers self-signed certs to the same file as the self-signed certs >of the commercial rootCAs. > > >-Martin >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Tue Apr 19 06:19:14 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0CFB3E06B2; Tue, 19 Apr 2011 06:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cWDJRj4S+F0; Tue, 19 Apr 2011 06:19:13 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfc.amsl.com (Postfix) with ESMTP id 1F600E0663; Tue, 19 Apr 2011 06:19:13 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p3JDJ6h7064812; Tue, 19 Apr 2011 09:19:06 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 09:18:44 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Apr 2011 09:18:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] [dane] 5280 and self-signed ee certs (was: Re: Thread-Index: Acv+ZhMPYN6Whhr3TIW029gCnCBYOgAK8/jg References: <201104182249.p3IMnS6u029126@fs4113.wdf.sap.corp> From: "Kemp, David P." To: "Stefan Santesson" , , "Phillip Hallam-Baker" X-OriginalArrivalTime: 19 Apr 2011 13:18:44.0859 (UTC) FILETIME=[4F42E4B0:01CBFE94] Cc: pkix@ietf.org, dane@ietf.org Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: 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, 19 Apr 2011 13:19:14 -0000 There's nothing wrong with self-signed X.509 v1 certs except the "X.509" part and the "certificate" part. Self-signed keys have nice properties other than proof of possession - they allow an entity to "stake a claim" on a cryptographically-guaranteed-unused identity and support continuity-based (or reputation-based) trust in that identity, in addition to standard out-of-band mechanisms. If wishes were horses ... everyone would use a PKIX-standard signed key assertion that was NOT a syntactically-valid X.509 certificate. I don't see how using X.509v1 instead of x.509v3 for self-signed end-entity keys prevents applications from misusing them as CA certs. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Tuesday, April 19, 2011 3:46 AM To: mrex@sap.com; Phillip Hallam-Baker Cc: pkix@ietf.org; dane@ietf.org Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: Martin, For self signed certs in general I think X.509 v1 certs are just fine. /Stefan On 11-04-19 12:49 AM, "Martin Rex" wrote: >Phillip Hallam-Baker wrote: >>=20 >> But the standard is set by the consensus and the running code which >> recognize self-signed certs.. >>=20 >>=20 >> I see the following courses of action as being open: >>=20 >> D1) DANE says nothing at all about this issue in the DANE spec (I see no >> reason it need be mentioned at all). >>=20 >> D2) DANE says that the EE cert can be a self signed EE cert in >>accordance >> with customary Internet usage >>=20 >> P1) PKIX writes draft on how to specify self signed EE certs so that >>this is >> properly understood. I.E. relying applications MUST NOT rely on any >>claims >> other than the POP of the key and any restrictions on validity/usage. >>=20 >> P2) PKIX ignores the issue. >>=20 >> Note that D1/2 and P1/2 are orthogonal. >>=20 >>=20 >> These certs exist and I can't see there being a consensus likely to >>emerge >> to require a chain with a CA cert at the head. > > >I have very little experience with / exposure to the discussions >in the PKIX WG, so I don't know how much I like (P1). > >From the data collected by EFF, there appear to be > > ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet > with the BasicConstraint cA=3DTRUE > ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet > > ~ 56000 self-signed X.509v3 Web Server certs installed on the internet > without the BasicConstraint cA=3DTRUE > >There may be a much higher number of use case for self-signed certs >on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're >probably irrelevant for DANE because most are on private IP-Addresses and >don't use officially registered DNS domains on their internal networks. > > >> >> Nor can I see a requirement >> to introduce a downref to X.509v1 to try to circumvent this. > >I do not see the particular gripe that you have with X.509v1. > >X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard. > > >The beauty of X.509v1 certs is that they're *MUCH* easier to create >and hard to get wrong in an interop-impairing fashion. > >And, the biggest advantage: enforcing a rule "do not accept as signers >of other certs" is trivial and fool-proof to implement, so that you >don't create immediate and serious problems when you add such >certs to the list of trusted keys for your PKI software along >with Trust Anchors from commercial CAs. > >When you mix up self-signed CA certs from some web-servers into the >list of trusted keys next to rootCAs from commercial CAs, then >you may put yourself at risk today. > >But what are you real options today, with programmatic clients? >Either disable the peer certificate check entirely, or add some >peers self-signed certs to the same file as the self-signed certs >of the commercial rootCAs. > > >-Martin >_______________________________________________ >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 Internet-Drafts@ietf.org Tue Apr 19 07:15:02 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CFE7E0691; Tue, 19 Apr 2011 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.731 X-Spam-Level: X-Spam-Status: No, score=-102.731 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wkq8NaX-qnIo; Tue, 19 Apr 2011 07:15:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 91EEFE06C0; Tue, 19 Apr 2011 07:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110419141501.14711.85542.idtracker@ietfc.amsl.com> Date: Tue, 19 Apr 2011 07:15:01 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action:draft-ietf-pkix-cmp-transport-protocols-11.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, 19 Apr 2011 14:15:02 -0000 --NextPart 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 -- Transport Protocols for CMP Author(s) : T. Kause, M. Peylo Filename : draft-ietf-pkix-cmp-transport-protocols-11.txt Pages : 30 Date : 2011-04-19 This document describes how to layer the Certificate Management Protocol over various transport protocols. 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-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pkix-cmp-transport-protocols-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-19070123.I-D@ietf.org> --NextPart-- From hallam@gmail.com Tue Apr 19 07:40:11 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 17643E0700; Tue, 19 Apr 2011 07:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYNxxcPbYOXM; Tue, 19 Apr 2011 07:40:09 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 4C06CE06E9; Tue, 19 Apr 2011 07:40:09 -0700 (PDT) Received: by vws12 with SMTP id 12so5442049vws.31 for ; Tue, 19 Apr 2011 07:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VAMhcyBrVT6/O9fFaI9dnHu1204diTlRZgrnQM/pUoY=; b=hRJjE74JILI3Ta81a2Y1W6S6sS8GnqnQJl5eAbKIAYt3LV94pulLEqmBDD8WqN8Pdb X23XH2zuO45nH88fUCFQ59fp2a3YxE8KxrgYex6D+X/S/BdTrGjKufVQJNyI6lwvfJgp l/B/ECYRxJ+8IV4kfC12J4S9hNryw3QW6L/gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JQ7dSG7T47VjM7zoJuWXgc9IQDKEhUlzhSu+dXQ3UmMrlLswIPGfN3eYhiidm/9WAy I29Newi3Nx+EWgY1nHMpLml4a+4suVQZeKjRPqza2ScNMqkK6lE563WWGPCQHncwIFzR va9tGOaSyV4OmIwMn5PJjBkjDHpYccM9En1HQ= MIME-Version: 1.0 Received: by 10.52.173.240 with SMTP id bn16mr3900481vdc.245.1303224007977; Tue, 19 Apr 2011 07:40:07 -0700 (PDT) Received: by 10.52.161.3 with HTTP; Tue, 19 Apr 2011 07:40:07 -0700 (PDT) In-Reply-To: References: <201104182249.p3IMnS6u029126@fs4113.wdf.sap.corp> Date: Tue, 19 Apr 2011 10:40:07 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: multipart/alternative; boundary=bcaec51b199d0eec5204a1467c71 Cc: Stefan Santesson , mrex@sap.com, dane@ietf.org, pkix@ietf.org Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: 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, 19 Apr 2011 14:40:11 -0000 --bcaec51b199d0eec5204a1467c71 Content-Type: text/plain; charset=ISO-8859-1 There is no problem with using X.509v1 certs. But there is a very big problem with trying to make a normative reference in a new standards proposal to a standard that has been deprecated (ITU) or made HISTORIC (IETF). Given the vast number of v1 certs in circulation plus the very long lifetimes on many of them, I can't see a problem with requiring relying applications to process v1 certs. The use case here would be to support a device that shipped with a built in v1 device cert without having to rekey the device. But I can see a very big problem with attempting to get round the PKIX lawyering with a requirement that cannot be supported in a reasonable manner using the current standards. I really don't see this as a DANE issue. I see it as a requirement to clarify the PKIX spec as follows: * CA signing key usage MUST be set for keys used to sign certificates for any key OTHER THAN THEMSELVES. * EE certs may be CA signed or self-signed. * Security considerations for using self-signed certs (probably two pages worth at least). Specifically, no positive claims can be relied on other than POP for the key, all use restrictions and validity conditions MUST be observed. Since this is currently the largest class of server certificate deployed by number of certs it would be ostrich-like behavior to ignore them. I can't see programmers deciding that they want to have applications that generate self-signed certs create a chain of two certs for no other purpose than to comply with the spec. On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. wrote: > There's nothing wrong with self-signed X.509 v1 certs except the "X.509" > part and the "certificate" part. > > Self-signed keys have nice properties other than proof of possession - > they allow an entity to "stake a claim" on a > cryptographically-guaranteed-unused identity and support > continuity-based (or reputation-based) trust in that identity, in > addition to standard out-of-band mechanisms. If wishes were horses ... > everyone would use a PKIX-standard signed key assertion that was NOT a > syntactically-valid X.509 certificate. I don't see how using X.509v1 > instead of x.509v3 for self-signed end-entity keys prevents applications > from misusing them as CA certs. > > Dave > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Tuesday, April 19, 2011 3:46 AM > To: mrex@sap.com; Phillip Hallam-Baker > Cc: pkix@ietf.org; dane@ietf.org > Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: > > Martin, > > For self signed certs in general I think X.509 v1 certs are just fine. > > /Stefan > > On 11-04-19 12:49 AM, "Martin Rex" wrote: > > >Phillip Hallam-Baker wrote: > >> > >> But the standard is set by the consensus and the running code which > >> recognize self-signed certs.. > >> > >> > >> I see the following courses of action as being open: > >> > >> D1) DANE says nothing at all about this issue in the DANE spec (I see > no > >> reason it need be mentioned at all). > >> > >> D2) DANE says that the EE cert can be a self signed EE cert in > >>accordance > >> with customary Internet usage > >> > >> P1) PKIX writes draft on how to specify self signed EE certs so that > >>this is > >> properly understood. I.E. relying applications MUST NOT rely on any > >>claims > >> other than the POP of the key and any restrictions on validity/usage. > >> > >> P2) PKIX ignores the issue. > >> > >> Note that D1/2 and P1/2 are orthogonal. > >> > >> > >> These certs exist and I can't see there being a consensus likely to > >>emerge > >> to require a chain with a CA cert at the head. > > > > > >I have very little experience with / exposure to the discussions > >in the PKIX WG, so I don't know how much I like (P1). > > > >From the data collected by EFF, there appear to be > > > > ~ 830000 self-signed X.509v3 Web Server Certs installed on the > internet > > with the BasicConstraint cA=TRUE > > ~ 494000 self-signed X.509v1 Web Server Certs installed on the > internet > > > > ~ 56000 self-signed X.509v3 Web Server certs installed on the > internet > > without the BasicConstraint cA=TRUE > > > >There may be a much higher number of use case for self-signed certs > >on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're > >probably irrelevant for DANE because most are on private IP-Addresses > and > >don't use officially registered DNS domains on their internal networks. > > > > > >> > >> Nor can I see a requirement > >> to introduce a downref to X.509v1 to try to circumvent this. > > > >I do not see the particular gripe that you have with X.509v1. > > > >X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard. > > > > > >The beauty of X.509v1 certs is that they're *MUCH* easier to create > >and hard to get wrong in an interop-impairing fashion. > > > >And, the biggest advantage: enforcing a rule "do not accept as signers > >of other certs" is trivial and fool-proof to implement, so that you > >don't create immediate and serious problems when you add such > >certs to the list of trusted keys for your PKI software along > >with Trust Anchors from commercial CAs. > > > >When you mix up self-signed CA certs from some web-servers into the > >list of trusted keys next to rootCAs from commercial CAs, then > >you may put yourself at risk today. > > > >But what are you real options today, with programmatic clients? > >Either disable the peer certificate check entirely, or add some > >peers self-signed certs to the same file as the self-signed certs > >of the commercial rootCAs. > > > > > >-Martin > >_______________________________________________ > >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/ --bcaec51b199d0eec5204a1467c71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is no problem with using X.509v1 certs.

But there = is a very big problem with trying to make a normative reference in a new st= andards proposal to a standard that has been deprecated (ITU) or made HISTO= RIC (IETF).


Given the vast number of v1 certs in circulat= ion plus the very long lifetimes on many of them, I can't see a problem= with requiring relying applications to process v1 certs. The use case here= would be to support a device that shipped with a built in v1 device cert w= ithout having to rekey the device.=A0

But I can see a very big problem with attempting to get= round the PKIX lawyering with a requirement that cannot be supported in a = reasonable manner using the current standards.=A0


I really don't see this as a DANE issue. I see it as a r= equirement to clarify the PKIX spec as follows:

* = CA signing key usage MUST be set for keys used to sign certificates for any= key OTHER THAN THEMSELVES.

* EE certs may be CA signed or self-signed.
<= br>
* Security considerations for using self-signed certs (probab= ly two pages worth at least). Specifically, no positive claims can be relie= d on other than POP for the key, all use restrictions and validity conditio= ns MUST be observed.


Since this is currently the largest clas= s of server certificate deployed by number of certs it would be ostrich-lik= e behavior to ignore them. I can't see programmers deciding that they w= ant to have applications that generate self-signed certs create a chain of = two certs for no other purpose than to comply with the spec.





On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. <DPKemp@missi.ncsc.= mil> wrote:
There's nothing wrong with self-signed = X.509 v1 certs except the "X.509"
part and the "certificate" part.

Self-signed keys have nice properties other than proof of possession -
they allow an entity to "stake a claim" on a
cryptographically-guaranteed-unused identity and support
continuity-based (or reputation-based) trust in that identity, in
addition to standard out-of-band mechanisms. =A0If wishes were horses ... everyone would use a PKIX-standard signed key assertion that was NOT a
syntactically-valid X.509 certificate. =A0I don't see how using X.509v1=
instead of x.509v3 for self-signed end-entity keys prevents applications from misusing them as CA certs.

Dave


-----Original Message-----
From: pkix-bounces@ietf.org [m= ailto:pkix-bounces@ietf.org] O= n Behalf Of
Stefan Santesson
Sent: Tuesday, April 19, 2011 3:46 AM
To: mrex@sap.com; Phillip Hallam-Baker<= br> Cc: pkix@ietf.org; dane@ietf.org
Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:

Martin,

For self signed certs in general I think X.509 v1 certs are just fine.

/Stefan

On 11-04-19 12:49 AM, "Martin Rex" <mrex@sap.com> wrote:

>Phillip Hallam-Baker wrote:
>>
>> But the standard is set by the consensus and the running code whic= h
>> recognize self-signed certs..
>>
>>
>> I see the following courses of action as being open:
>>
>> D1) DANE says nothing at all about this issue in the DANE spec (I = see
no
>> reason it need be mentioned at all).
>>
>> D2) DANE says that the EE cert can be a self signed EE cert in
>>accordance
>> with customary Internet usage
>>
>> P1) PKIX writes draft on how to specify self signed EE certs so th= at
>>this is
>> properly understood. I.E. relying applications MUST NOT rely on an= y
>>claims
>> other than the POP of the key and any restrictions on validity/usa= ge.
>>
>> P2) PKIX ignores the issue.
>>
>> Note that D1/2 and P1/2 are orthogonal.
>>
>>
>> These certs exist and I can't see there being a consensus like= ly to
>>emerge
>> to require a chain with a CA cert at the head.
>
>
>I have very little experience with / exposure to the discussions
>in the PKIX WG, so I don't know how much I like (P1).
>
>From the data collected by EFF, there appear to be
>
> =A0~ 830000 self-signed X.509v3 Web Server Certs installed on the
internet
> =A0 =A0 =A0 =A0 =A0 with the BasicConstraint cA=3DTRUE
> =A0~ 494000 self-signed X.509v1 Web Server Certs installed on the
internet
>
> =A0~ =A056000 self-signed X.509v3 Web Server certs installed on the internet
> =A0 =A0 =A0 =A0 =A0 without the BasicConstraint cA=3DTRUE
>
>There may be a much higher number of use case for self-signed certs
>on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're<= br> >probably irrelevant for DANE because most are on private IP-Addresses and
>don't use officially registered DNS domains on their internal netwo= rks.
>
>
>>
>> Nor can I see a requirement
>> to introduce a downref to X.509v1 to try to circumvent this.
>
>I do not see the particular gripe that you have with X.509v1.
>
>X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
>
>
>The beauty of X.509v1 certs is that they're *MUCH* easier to create=
>and hard to get wrong in an interop-impairing fashion.
>
>And, the biggest advantage: enforcing a rule "do not accept as sig= ners
>of other certs" is trivial and fool-proof to implement, so that yo= u
>don't create immediate and serious problems when you add such
>certs to the list of trusted keys for your PKI software along
>with Trust Anchors from commercial CAs.
>
>When you mix up self-signed CA certs from some web-servers into the
>list of trusted keys next to rootCAs from commercial CAs, then
>you may put yourself at risk today.
>
>But what are you real options today, with programmatic clients?
>Either disable the peer certificate check entirely, or add some
>peers self-signed certs to the same file as the self-signed certs
>of the commercial rootCAs.
>
>
>-Martin
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix


_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix



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

--bcaec51b199d0eec5204a1467c71-- From stephen.farrell@cs.tcd.ie Tue Apr 19 07:51:38 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0225E06BE; Tue, 19 Apr 2011 07:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.188 X-Spam-Level: X-Spam-Status: No, score=-105.188 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB6KX5Oke8Sk; Tue, 19 Apr 2011 07:51:37 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id 6DE3EE06B2; Tue, 19 Apr 2011 07:51:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D8989171C1D; Tue, 19 Apr 2011 15:51:35 +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=1303224694; bh=BME90IWWN2HHe8 56T9VnArRvPOhzpaP7sBI83ZVloeU=; b=DLkQ0kuaG6FRRZHB5gG/FAZnY0nLoA ffkUS+ApL+OiXZKSMbiGck6Tr6mzL+xmN2ZD3RcImZlfeLRWRc5iNAFKfh8x9BkQ B2w5XNtXToZ0Hdn79YL/Ztp4qQh93Pq+SjnKR2WK+NngAV01VrMGUxG3l/HLAL0m h7wBmaf4OGSemGjqNu/fKPxk2nCk6AsYq0hsicX1BwPLWGFCfNPtKSYDG6a2Sx+b 76BdFKn6mGOdVKaRGW/Hfp5jufiBjtlPCvOgTyof2AxAAL9YhI8MqQwf+7OSsCqS AyIHqZNzQ+nNazA3K2rwRUougPJfEqYGwjAM/iwXw1ZK+hZY/qAx73iQ== 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 mUZ9V8Pz9-0G; Tue, 19 Apr 2011 15:51:34 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D4C5D171C19; Tue, 19 Apr 2011 15:51:30 +0100 (IST) Message-ID: <4DADA172.4090201@cs.tcd.ie> Date: Tue, 19 Apr 2011 15:51:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <201104182249.p3IMnS6u029126@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Santesson , mrex@sap.com, pkix@ietf.org, dane@ietf.org Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: 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, 19 Apr 2011 14:51:39 -0000 So can we take the discussion over to pkix then and have this be the last message on this topic to dane until pkix has come to some conclusion? So *please* remove dane from followups. S. On 19/04/11 15:40, Phillip Hallam-Baker wrote: > There is no problem with using X.509v1 certs. > > But there is a very big problem with trying to make a normative > reference in a new standards proposal to a standard that has been > deprecated (ITU) or made HISTORIC (IETF). > > > Given the vast number of v1 certs in circulation plus the very long > lifetimes on many of them, I can't see a problem with requiring relying > applications to process v1 certs. The use case here would be to support > a device that shipped with a built in v1 device cert without having to > rekey the device. > > But I can see a very big problem with attempting to get round the PKIX > lawyering with a requirement that cannot be supported in a reasonable > manner using the current standards. > > > I really don't see this as a DANE issue. I see it as a requirement to > clarify the PKIX spec as follows: > > * CA signing key usage MUST be set for keys used to sign certificates > for any key OTHER THAN THEMSELVES. > > * EE certs may be CA signed or self-signed. > > * Security considerations for using self-signed certs (probably two > pages worth at least). Specifically, no positive claims can be relied on > other than POP for the key, all use restrictions and validity conditions > MUST be observed. > > > Since this is currently the largest class of server certificate deployed > by number of certs it would be ostrich-like behavior to ignore them. I > can't see programmers deciding that they want to have applications that > generate self-signed certs create a chain of two certs for no other > purpose than to comply with the spec. > > > > > > On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. > wrote: > > There's nothing wrong with self-signed X.509 v1 certs except the "X.509" > part and the "certificate" part. > > Self-signed keys have nice properties other than proof of possession - > they allow an entity to "stake a claim" on a > cryptographically-guaranteed-unused identity and support > continuity-based (or reputation-based) trust in that identity, in > addition to standard out-of-band mechanisms. If wishes were horses ... > everyone would use a PKIX-standard signed key assertion that was NOT a > syntactically-valid X.509 certificate. I don't see how using X.509v1 > instead of x.509v3 for self-signed end-entity keys prevents applications > from misusing them as CA certs. > > Dave > > > -----Original Message----- > From: pkix-bounces@ietf.org > [mailto:pkix-bounces@ietf.org ] On > Behalf Of > Stefan Santesson > Sent: Tuesday, April 19, 2011 3:46 AM > To: mrex@sap.com ; Phillip Hallam-Baker > Cc: pkix@ietf.org ; dane@ietf.org > > Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: > > Martin, > > For self signed certs in general I think X.509 v1 certs are just fine. > > /Stefan > > On 11-04-19 12:49 AM, "Martin Rex" > wrote: > > >Phillip Hallam-Baker wrote: > >> > >> But the standard is set by the consensus and the running code which > >> recognize self-signed certs.. > >> > >> > >> I see the following courses of action as being open: > >> > >> D1) DANE says nothing at all about this issue in the DANE spec (I see > no > >> reason it need be mentioned at all). > >> > >> D2) DANE says that the EE cert can be a self signed EE cert in > >>accordance > >> with customary Internet usage > >> > >> P1) PKIX writes draft on how to specify self signed EE certs so that > >>this is > >> properly understood. I.E. relying applications MUST NOT rely on any > >>claims > >> other than the POP of the key and any restrictions on validity/usage. > >> > >> P2) PKIX ignores the issue. > >> > >> Note that D1/2 and P1/2 are orthogonal. > >> > >> > >> These certs exist and I can't see there being a consensus likely to > >>emerge > >> to require a chain with a CA cert at the head. > > > > > >I have very little experience with / exposure to the discussions > >in the PKIX WG, so I don't know how much I like (P1). > > > >From the data collected by EFF, there appear to be > > > > ~ 830000 self-signed X.509v3 Web Server Certs installed on the > internet > > with the BasicConstraint cA=TRUE > > ~ 494000 self-signed X.509v1 Web Server Certs installed on the > internet > > > > ~ 56000 self-signed X.509v3 Web Server certs installed on the > internet > > without the BasicConstraint cA=TRUE > > > >There may be a much higher number of use case for self-signed certs > >on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're > >probably irrelevant for DANE because most are on private IP-Addresses > and > >don't use officially registered DNS domains on their internal networks. > > > > > >> > >> Nor can I see a requirement > >> to introduce a downref to X.509v1 to try to circumvent this. > > > >I do not see the particular gripe that you have with X.509v1. > > > >X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard. > > > > > >The beauty of X.509v1 certs is that they're *MUCH* easier to create > >and hard to get wrong in an interop-impairing fashion. > > > >And, the biggest advantage: enforcing a rule "do not accept as signers > >of other certs" is trivial and fool-proof to implement, so that you > >don't create immediate and serious problems when you add such > >certs to the list of trusted keys for your PKI software along > >with Trust Anchors from commercial CAs. > > > >When you mix up self-signed CA certs from some web-servers into the > >list of trusted keys next to rootCAs from commercial CAs, then > >you may put yourself at risk today. > > > >But what are you real options today, with programmatic clients? > >Either disable the peer certificate check entirely, or add some > >peers self-signed certs to the same file as the self-signed certs > >of the commercial rootCAs. > > > > > >-Martin > >_______________________________________________ > >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 From pgut001@login01.cs.auckland.ac.nz Tue Apr 19 08:01:33 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7B22E0766; Tue, 19 Apr 2011 08:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifx5dorjdT7V; Tue, 19 Apr 2011 08:01:33 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id C237AE075A; Tue, 19 Apr 2011 08:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1303225289; x=1334761289; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20stephen.farrell@cs.tcd.ie |Subject:=20Re:=20[pkix]=20[dane]=205280=20and=20self-sig ned=20ee=20certs=20(was:=20Re:|Cc:=20dane@ietf.org,=20mre x@sap.com,=20pkix@ietf.org,=20stefan@aaa-sec.com |In-Reply-To:=20<4DADA172.4090201@cs.tcd.ie>|Message-Id: =20|Date: =20Wed,=2020=20Apr=202011=2003:01:19=20+1200; bh=amAiaOhfdrCXMt3NySgf3j7SBsf11H0FpFUdOpYVFcE=; b=uyS2URzGNkn68z0wBGHP45V27ktWJjz3zBD3cBOJLFUvW/42cMlCHJWX Q5XjonnsumhHHpdTeVdqCljcfbxUx4qjVTHnL6Byn9hm0nEx0oReo9VEU j/2Bz54WdOP01T2bdu1kxT9DHmPEZYe8WSyqnWL45aMDwELxcn0xMGcNT U=; X-IronPort-AV: E=Sophos;i="4.64,240,1301832000"; d="scan'208";a="57435833" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Apr 2011 03:01:19 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QCCQZ-0007HF-He; Wed, 20 Apr 2011 03:01:19 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QCCQZ-0007S8-DE; Wed, 20 Apr 2011 03:01:19 +1200 From: Peter Gutmann To: hallam@gmail.com, stephen.farrell@cs.tcd.ie In-Reply-To: <4DADA172.4090201@cs.tcd.ie> Message-Id: Date: Wed, 20 Apr 2011 03:01:19 +1200 Cc: pkix@ietf.org, mrex@sap.com, stefan@aaa-sec.com, dane@ietf.org Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: 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, 19 Apr 2011 15:01:33 -0000 Stephen Farrell writes: >So can we take the discussion over to pkix then and have this be the last >message on this topic to dane until pkix has come to some conclusion? What if they never come to a conclusion (which is not unusual whenever a tough topic comes up)? We should probably set a timer to expire after which (shudder) things start up here again. (Sorry, still sent to DANE since it's relevant here. "Kick it over to PKIX" presupposes that it'll converge on a solution at some point). Peter. From Massimiliano.Pala@Dartmouth.edu Tue Apr 19 09:38:56 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94D63E0691 for ; Tue, 19 Apr 2011 09:38:56 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-OczZhutTfR for ; Tue, 19 Apr 2011 09:38:56 -0700 (PDT) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by ietfc.amsl.com (Postfix) with ESMTP id 9C867E07CA for ; Tue, 19 Apr 2011 09:38:48 -0700 (PDT) Received: from newblitzen.Dartmouth.EDU (newblitzen.Dartmouth.EDU [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id p3JEKbKN006379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Apr 2011 12:38:37 -0400 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from c-68-45-60-165.hsd1.nj.comcast.net [68.45.60.165] by newblitzen.Dartmouth.EDU (Mac) via SMTP for pkix@ietf.org id <190166379>; 19 Apr 2011 12:38:26 -0400 Message-ID: <4DADBAB7.8020809@Dartmouth.edu> Date: Tue, 19 Apr 2011 12:39:19 -0400 From: Massimiliano Pala Organization: Dartmouth College / OpenCA Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000607080901000501060409" X-MailScanner: Found to be clean by mailhub2.dartmouth.edu X-MailScanner-SpamCheck: spam, SpamAssassin (not cached, score=8.783, required 1, autolearn=spam, AWL -1.82, BAYES_50 0.80, BLITZ_DISCLAIMER 0.05, DART_B_UPD 0.50, FH_HELO_EQ_D_D_D_D 3.18, HELO_DYNAMIC_IPADDR 1.95, RCVD_IN_PBL 3.33, RCVD_IN_SORBS_DUL 0.00, RDNS_NONE 0.79) X-MailScanner-SpamScore: ssssssss X-MailScanner-From: massimiliano.pala@dartmouth.edu Subject: [pkix] Email in Certs and Privacy Concerns 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, 19 Apr 2011 16:38:56 -0000 This is a cryptographically signed message in MIME format. --------------ms000607080901000501060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello all, I was thinking about a privacy problem we have in currently issued certs:= email addresses. Some CAs make the case that they do not wish to publish the list of certs= to avoid spammers to easily harvest all the email addresses in certs. A simple solution would be to allow for using an hash of the email addres= s instead of the email address itself in the subjectAltName. This would prevent attackers from using that information for spam/marketing purposes= , but still clients can easily verify the email address by simply hashing the From: email address and compare the hash instead of the bare address.= This approach could be used also to protect hostnames, although I don't see privacy issues there (maybe in some "special" environments?) Since this addresses an important issue, shall we try to have a small and= quick I-D that describes the addition ? Does this sound reasonable and easy to deploy ? --=20 Best Regards, Massimiliano Pala --o----------------------------------------------------------------------= -- Massimiliano Pala [OpenCA Project Manager] openca@acm.o= rg project.manager@openca.= org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-93= 32 PKI/Trust Laboratory Work Phone: +1 (603) 646-87= 34 --o----------------------------------------------------------------------= -- People who think they know everything are a great annoyance to those of u= s who do. -- Isaac Asimov --------------ms000607080901000501060409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6DCC BHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkW A2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTEw MDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNlZHUxGTAX BgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3Np bWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVYpWfvkEzS HWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN/4cqgCPY yjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHaOwk9SUc7 rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2cED6ioDn 2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn5h9WBlxK 7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1UdDwEB/wQE AwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C/DA3BgNV HR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNhLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2ltaWxpYW5v LlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYeTaN3EjAN BgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2KJs8xm93d yTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBcTDec5NWe 7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9Fa6HDxEM Xg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt/ZD6rJkE jYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQke9fCfwsx zghYIDCCBHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT 8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAY BgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgx MB4XDTEwMDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNl ZHUxGTAXBgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFE YXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMT EU1hc3NpbWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVY pWfvkEzSHWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN /4cqgCPYyjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHa Owk9SUc7rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2 cED6ioDn2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn 5h9WBlxK7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1Ud DwEB/wQEAwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C /DA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNh LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2lt aWxpYW5vLlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYe TaN3EjANBgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2K Js8xm93dyTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBc TDec5NWe7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9 Fa6HDxEMXg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt /ZD6rJkEjYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQk e9fCfwsxzghYIDGCA5owggOWAgEBMIGCMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJ kiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGgg Q29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQIHAIkS6kMSADAJBgUrDgMC GgUAoIIB7DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0 MTkxNjM5MTlaMCMGCSqGSIb3DQEJBDEWBBRwMoVtIrBcE0WbiLk2ZZt0FPEUPTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZMGCSsGAQQBgjcQBDGBhTCB gjB3MRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZImiZPyLGQBGRYJZGFydG1vdXRoMQsw CQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENvbGxlZ2UxHDAaBgNVBAMTE0RhcnRt b3V0aCBDZXJ0QXV0aDECBwCJEupDEgAwgZUGCyqGSIb3DQEJEAILMYGFoIGCMHcxEzARBgoJ kiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVT MRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRB dXRoMQIHAIkS6kMSADANBgkqhkiG9w0BAQEFAASCAQCRyvRKX6DvBHH6RGPz9GeEWBy46FyT zELPEjQiuobJ59i1OIrdLaDfpBfStwO+R5/z2yjB3ofqwnyVwxqEzURov51PAYC2Sf7RGf1Z C/K9jyMy3EK1ukwaiXtkAprYhTmSgK7jve5EVFHdDtjNExg+Ipx6R53aWKJmM+xpDeIOG+8K iXyIGCgeKTqGJt3pNZtCZAEDORT7zw13L3RzsQ99kcjUTn5vIoCJvGnn4M99+onWxPBYVs/V 1K8VLuFfhsH3V+1+CspYhBaHZWfu76UB1ZTiiFL1TXlYnq1r+2eppS357C+OJcu9f/oQRqQV 5wF5jlbKG98cB45DMDdM2RLwAAAAAAAA --------------ms000607080901000501060409-- From DPKemp@missi.ncsc.mil Tue Apr 19 11:31:02 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 330D0E0755 for ; Tue, 19 Apr 2011 11:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqOt2PpFW1Yv for ; Tue, 19 Apr 2011 11:31:01 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfc.amsl.com (Postfix) with ESMTP id 5199AE0700 for ; Tue, 19 Apr 2011 11:31:01 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p3JIV0IW073811 for ; Tue, 19 Apr 2011 14:31:00 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 14:30:38 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Apr 2011 14:22:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) Thread-Index: Acv+D6cmCsAH0bhBT86luWFCSu8xGgAnQGMA References: <4DAC28E7.2070602@cs.tcd.ie> From: "Kemp, David P." To: "pkix" X-OriginalArrivalTime: 19 Apr 2011 18:30:38.0765 (UTC) FILETIME=[E19E55D0:01CBFEBF] Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 19 Apr 2011 18:31:02 -0000 [dane omitted] From: Stefan Santesson > A self signed cert is simply a convenient way to communicate > a public key for an entity that has not been certified by a CA. > I would say that it is a self signed cert. Period. Disregarding > what type of entity it represents. +1. It is also syntactically a "certificate" but semantically not a certification, regardless of what type of entity it represents. From: Stephen Farrell > My conclusion is that neither 5280 nor the pkix archives > justify any conclusion about self-signed end-entity certs. +1. PKIX describes three types of CA certificates, one of which is an assertion by an entity about itself, not a certification by some other authority. Saying "some CA certificates are self-signed" is not a prohibition against "some non-CA certificates" also being self-signed, it is silence. From: Phillip Hallam-Baker > I really don't see this as a DANE issue. I see it as > a requirement to clarify the PKIX spec as follows: > > * CA signing key usage MUST be set for keys used to sign > certificates for any key OTHER THAN THEMSELVES. > > * EE certs may be CA signed or self-signed. RFC 5280 Section 4.2.1.3 Key Usage says: Conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. So the first bullet is unnecessary, PKIX is already perfectly clear. > And, the biggest advantage [of X.509v1]: enforcing a rule > "do not accept as signers > of other certs" is trivial and fool-proof to implement, so that you > don't create immediate and serious problems when you add such > certs to the list of trusted keys for your PKI software along > with Trust Anchors from commercial CAs. Section 6.1.4 of Basic Validation says: (k) If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE. (If certificate i is a version 1 or version 2 certificate, then the application MUST either verify that certificate i is a CA certificate through out-of-band means or reject the certificate. Conforming implementations may choose to reject all version 1 and version 2 intermediate certificates.) So that is not an advantage of v1 vs. v3. If a cert does not include a basic constraints extension, it is already "trivial and foolproof" to implement the rule that it is not a CA cert, yet apparently some application developers have managed to botch it. How likely is it that the version field would be a "more foolproof" indicator of non-CA-ness than basic constraints? >From the data collected by EFF, there appear to be > ~ 830000 self-signed X.509v3 Web Server Certs installed > on the internet with the BasicConstraint cA=3DTRUE > ~ 494000 self-signed X.509v1 Web Server Certs installed > on the internet > ~ 56000 self-signed X.509v3 Web Server certs installed > on the internet without the BasicConstraint cA=3DTRUE What impact can PKIX have, with or without additional guidance, on the issuers of these certs? 5280 may be complex, but the part about EE certs not being CA certs seems clear enough. Yet the number of CA certs issued by EEs to themselves dwarfs the number of v1 certs and EE certs combined. I prefer Stefan's clarification - self-signed certs have properties X, Y and Z regardless of type of entity named in the subject field. But I have no illusions about the likelihood of any such clarification being "foolproof". Dave From paul.hoffman@vpnc.org Tue Apr 19 11:42:48 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1B65FE0685 for ; Tue, 19 Apr 2011 11:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBFFzx4aiRxm for ; Tue, 19 Apr 2011 11:42:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id 7D382E0669 for ; Tue, 19 Apr 2011 11:42:47 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3JIgkpH088842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Apr 2011 11:42:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 19 Apr 2011 11:42:46 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4DAC28E7.2070602@cs.tcd.ie> To: "Kemp, David P." X-Mailer: Apple Mail (2.1084) Cc: pkix Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 19 Apr 2011 18:42:48 -0000 On Apr 19, 2011, at 11:22 AM, Kemp, David P. wrote: > +1. It is also syntactically a "certificate" but semantically not a > certification, regardless of what type of entity it represents. Excellent distinction! --Paul Hoffman From stephen.farrell@cs.tcd.ie Tue Apr 19 11:47:55 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4E3C0E06F2 for ; Tue, 19 Apr 2011 11:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNO7SWNXFMYA for ; Tue, 19 Apr 2011 11:47:54 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id 6BFDBE06BB for ; Tue, 19 Apr 2011 11:47:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id CAA85171C1B; Tue, 19 Apr 2011 19:47:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1303238871; bh=Wa/ap Ds2PbO+KYM5JfCbBTCH1NJhD7gD3PgstQ/UpXo=; b=IOAtitE+EgVtG5+5lFlmb qFWcRYKhglaaCx79pGKnNTPw6pIVDyAzpblD2yvkFrJH96f3MoqzA9PMTLhH2R5B jrLBIqSAxj/ZHHtWivUAO+wAHYxETEHKOY0Kj62J+Jcd9tFZXclePvBw5SEy3rmT 4Gq4lpUm4syt91IzVFe/on/SkukQerNvOKvX55B3wR+sGgaTVeWrI/A/uCLwvY9S +uqTMV4dp4fmv4dtdckOg3W5NP0EK9MynZiFspDihSiNmKSwcmGSibBQ2dgZQpC+ Q3X0iV9R1vNxEqTuse0/UA5LoAwI4DowXw6lKFzKUzzM7X9Js3lt3HQFKYo7RRqn g== 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 axFLaweGe9-y; Tue, 19 Apr 2011 19:47:51 +0100 (IST) Received: from [10.87.48.5] (unknown [86.42.177.204]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B21E8171C19; Tue, 19 Apr 2011 19:47:49 +0100 (IST) References: <4DAC28E7.2070602@cs.tcd.ie> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <48E0CAB6-6AA9-4114-875A-842BAF56C18C@cs.tcd.ie> X-Mailer: iPhone Mail (8G4) From: Stephen Farrell Date: Tue, 19 Apr 2011 19:47:44 +0100 To: Paul Hoffman Cc: pkix Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 19 Apr 2011 18:47:55 -0000 On 19 Apr 2011, at 19:42, Paul Hoffman wrote: > On Apr 19, 2011, at 11:22 AM, Kemp, David P. wrote: > >> +1. It is also syntactically a "certificate" but semantically not a >> certification, regardless of what type of entity it represents. > > Excellent distinction! Yeah that nails it nicely, S > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From DPKemp@missi.ncsc.mil Tue Apr 19 12:34:17 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94809E0856 for ; Tue, 19 Apr 2011 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL95Y5ct1Bb2 for ; Tue, 19 Apr 2011 12:34:17 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfc.amsl.com (Postfix) with ESMTP id 14973E0776 for ; Tue, 19 Apr 2011 12:34:12 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p3JJY9Gx075482 for ; Tue, 19 Apr 2011 15:34:11 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 15:33:48 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Apr 2011 15:33:33 -0400 Message-ID: In-Reply-To: <4DADBAB7.8020809@Dartmouth.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: Acv+sHRpe0/xslRRRKGKTL+CnWHvTgADxE/g References: <4DADBAB7.8020809@Dartmouth.edu> From: "Kemp, David P." To: X-OriginalArrivalTime: 19 Apr 2011 19:33:48.0187 (UTC) FILETIME=[B44A3EB0:01CBFEC8] Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 19 Apr 2011 19:34:17 -0000 I suspect that spammers, having gone to the trouble of harvesting certificates, would not balk at building rainbow tables for the hashes. There is not a whole lot of entropy in "localpart" @gmail.com, @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so salting doesn't help. It may be a bit more difficult to enumerate corporate, as opposed to public, email providers, but even so, this sounds like a small deterrent to a dedicated spammer. And if hashing gives a false sense of security, the harvesting step may be made easier. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Massimiliano Pala Sent: Tuesday, April 19, 2011 12:39 PM To: pkix@ietf.org Subject: [pkix] Email in Certs and Privacy Concerns Hello all, I was thinking about a privacy problem we have in currently issued certs: email addresses. Some CAs make the case that they do not wish to publish the list of certs to avoid spammers to easily harvest all the email addresses in certs. A simple solution would be to allow for using an hash of the email address instead of the email address itself in the subjectAltName. This would prevent attackers from using that information for spam/marketing purposes, but still clients can easily verify the email address by simply hashing the From: email address and compare the hash instead of the bare address. This approach could be used also to protect hostnames, although I don't see privacy issues there (maybe in some "special" environments?) Since this addresses an important issue, shall we try to have a small and quick I-D that describes the addition ? Does this sound reasonable and easy to deploy ? --=20 Best Regards, Massimiliano Pala --o--------------------------------------------------------------------- --- Massimiliano Pala [OpenCA Project Manager] openca@acm.org =20 project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o--------------------------------------------------------------------- --- People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov From SChokhani@cygnacom.com Tue Apr 19 12:50:06 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3281BE069C for ; Tue, 19 Apr 2011 12:50: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVkE3E7+4+lE for ; Tue, 19 Apr 2011 12:50:05 -0700 (PDT) Received: from sottexchE2.entrust.com (sottexche2.entrust.com [216.191.252.22]) by ietfc.amsl.com (Postfix) with ESMTP id 5F26EE0689 for ; Tue, 19 Apr 2011 12:50:05 -0700 (PDT) Received: from scygexch7.cygnacom.com (10.4.60.22) by sottexchE2.entrust.com (216.191.252.22) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Apr 2011 15:48:56 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 19 Apr 2011 15:50:03 -0400 From: Santosh Chokhani To: Massimiliano Pala , "pkix@ietf.org" Date: Tue, 19 Apr 2011 15:47:29 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: Acv+sGaKf5FgfAihSi+A781Ccri2qwAGiwLQ Message-ID: References: <4DADBAB7.8020809@Dartmouth.edu> In-Reply-To: <4DADBAB7.8020809@Dartmouth.edu> 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] Email in Certs and Privacy Concerns 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, 19 Apr 2011 19:50:06 -0000 May be add a salt to the hash for good measure. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mas= similiano Pala Sent: Tuesday, April 19, 2011 12:39 PM To: pkix@ietf.org Subject: [pkix] Email in Certs and Privacy Concerns Hello all, I was thinking about a privacy problem we have in currently issued certs: email addresses. Some CAs make the case that they do not wish to publish the list of certs t= o avoid spammers to easily harvest all the email addresses in certs. A simple solution would be to allow for using an hash of the email address = instead of the email address itself in the subjectAltName. This would preve= nt attackers from using that information for spam/marketing purposes, but s= till clients can easily verify the email address by simply hashing the From= : email address and compare the hash instead of the bare address. This approach could be used also to protect hostnames, although I don't see= privacy issues there (maybe in some "special" environments?) Since this addresses an important issue, shall we try to have a small and q= uick I-D that describes the addition ? Does this sound reasonable and easy to deploy ? --=20 Best Regards, Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] openca@acm.org project.manager@openca.or= g Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o------------------------------------------------------------------------ People who think they know everything are a great annoyance to those of us = who do. -- Isaac Asimov From mrex@sap.com Tue Apr 19 13:01:02 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DAFF9E079D for ; Tue, 19 Apr 2011 13:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.378 X-Spam-Level: X-Spam-Status: No, score=-9.378 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdSrRezMaxXF for ; Tue, 19 Apr 2011 13:01:01 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 984A7E0670 for ; Tue, 19 Apr 2011 13:01:01 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3JK0xXu006397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 22:01:00 +0200 (MEST) From: Martin Rex Message-Id: <201104192000.p3JK0wJp011169@fs4113.wdf.sap.corp> To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Tue, 19 Apr 2011 22:00:58 +0200 (MEST) In-Reply-To: from "Kemp, David P." at Apr 19, 11 02:22:53 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] 5280 and self-signed ee certs (was: Re: [dane] 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: Tue, 19 Apr 2011 20:01:03 -0000 Kemp, David P. wrote: > > From: Stefan Santesson > > > > A self signed cert is simply a convenient way to communicate > > a public key for an entity that has not been certified by a CA. > > I would say that it is a self signed cert. Period. Disregarding > > what type of entity it represents. > > +1. It is also syntactically a "certificate" but semantically not a > certification, regardless of what type of entity it represents. +1, nicely put. > > From: Stephen Farrell > > > My conclusion is that neither 5280 nor the pkix archives > > justify any conclusion about self-signed end-entity certs. > > +1. PKIX describes three types of CA certificates, one of which is an > assertion by an entity about itself, not a certification by some other > authority. Saying "some CA certificates are self-signed" is not a > prohibition against "some non-CA certificates" also being self-signed, > it is silence. +1 > > RFC 5280 Section 4.2.1.3 Key Usage says: > > Conforming CAs MUST include this extension > in certificates that contain public keys that are used > to validate digital signatures on other public key > certificates or CRLs. > > So the first bullet is unnecessary, PKIX is already perfectly clear. There is another "Conforming CAs MUST include" about the BasisConstraints extensions for CA certificates in rfc5280. But the section that you quoted from the certificate path validation: > > Section 6.1.4 of Basic Validation says: > > (k) If certificate i is a version 3 certificate, verify that the > basicConstraints extension is present and that cA is set to > TRUE. (If certificate i is a version 1 or version 2 > certificate, then the application MUST either verify that > certificate i is a CA certificate through out-of-band means > or reject the certificate. Conforming implementations may > choose to reject all version 1 and version 2 intermediate > certificates.) seems to distinguish the requirements for a "conforming CA" significantly from the requirements for a "conforming PKI implementation", in that it allows (but not require) PKI implementation to process X.509v1 intermediate CA certs. The rfc5280 requirements for "conforming PKI implementations" are overly soft "may reject version 1 and version 2 intermediate certificate". Personally, I would prefer a "MUST reject all version 1 intermediate certificates" (I can not comment on version 2). And on top of that, I would appreciate something like this: "Conforming implementations may choose to reject "TAs", that are distributed as self-signed version 1 certificates, as signers of other certificates." If you currently want to furnish a programmatic https client (like wget/curl linked to openssl) with a list of trusted keys for downloading data from TLS servers, you can not provide a list of self-signed server certs seperately from a list of commercial rootCA certs. Dealing with self-signed CA certs of some servers is significantly harder, because they're indistinguishable from organizational CAs -- and limiting what certs organizational CAs may issue is also often not possible with the existing TLS clients and existing convenience APIs provided by TLS toolkits. DANE might, at some point in the future, provide a useful limitation for the validity of self-signed X.509v3 CA certificates installed on many web servers out there. But it wouldn't hurt to provide additional options for existing software and for environments where DANE will not apply (many private&home networks) with a reduced risk by using X.509v1 certs and disabling X.509v1 cert usage in certificate path validations, i.e. as signers of other certs. > > So that is not an advantage of v1 vs. v3. If a cert does not include a > basic constraints extension, it is already "trivial and foolproof" to > implement the rule that it is not a CA cert, yet apparently some > application developers have managed to botch it. How likely is it that > the version field would be a "more foolproof" indicator of non-CA-ness > than basic constraints? What I meant: disabling X.509v1 certs as valid CA certs _entirely_ within the PKI software should be trivial and foolproof while not breaking any existing reasonable PKI. Dealing sensibly with the large number of self-signed X.509v3 CA certs installed on Web-Servers is much more difficult. DANE is one possible future solution, Browsers that allow pinning of server certs (while limiting that certs validity to a single hostname), may be an existing workable solution. But for a number of _existing_ programmatic TLS clients, a workable solution for X.509v1 self-signed server certs might be much easier than for X.509v3 self-signed server certs with BasicConstraints cA=TRUE. -Martin From mrex@sap.com Tue Apr 19 13:09:38 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 34DF9E0730 for ; Tue, 19 Apr 2011 13:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkDM9hRhUxZi for ; Tue, 19 Apr 2011 13:09:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 1F86EE072F for ; Tue, 19 Apr 2011 13:09:36 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3JK9VQ2007296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 22:09:31 +0200 (MEST) From: Martin Rex Message-Id: <201104192009.p3JK9UwO011445@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Tue, 19 Apr 2011 22:09:30 +0200 (MEST) In-Reply-To: from "Santosh Chokhani" at Apr 19, 11 03:47:29 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] Email in Certs and Privacy Concerns 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: Tue, 19 Apr 2011 20:09:38 -0000 Santosh Chokhani wrote: > > May be add a salt to the hash for good measure. Different to Passwords, most users want Email addresses to be easy to memorize for themselves _and_ all of their friends and contacts. And spammers will use any technique that gives them new addresses. They don't mind if the "quick approach" finds only 30-50% of those addresses that exist. They'll start with what they get. -Martin From Massimiliano.Pala@Dartmouth.edu Tue Apr 19 14:22:41 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E0E38E0895 for ; Tue, 19 Apr 2011 14:22:41 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6-AFRRc8E0K for ; Tue, 19 Apr 2011 14:22:41 -0700 (PDT) Received: from mailhub1.dartmouth.edu (mailhub1.Dartmouth.EDU [129.170.16.122]) by ietfc.amsl.com (Postfix) with ESMTP id 3AA4EE08A4 for ; Tue, 19 Apr 2011 14:22:39 -0700 (PDT) Received: from newblitzen.Dartmouth.EDU (newblitzen.Dartmouth.EDU [129.170.208.36]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id p3JKs74Q012971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Apr 2011 17:22:31 -0400 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from c-68-45-60-165.hsd1.nj.comcast.net [68.45.60.165] by newblitzen.Dartmouth.EDU (Mac) via SMTP for pkix@ietf.org id <190190409>; 19 Apr 2011 17:22:31 -0400 Message-ID: <4DADFD4C.6000100@Dartmouth.edu> Date: Tue, 19 Apr 2011 17:23:24 -0400 From: Massimiliano Pala Organization: Dartmouth College / OpenCA Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: pkix@ietf.org References: <4DADBAB7.8020809@Dartmouth.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050808050109070205050806" X-MailScanner: Found to be clean by mailhub1.dartmouth.edu X-MailScanner-SpamCheck: spam, SpamAssassin (not cached, score=8.889, required 1, autolearn=spam, AWL -1.72, BAYES_50 0.80, BLITZ_DISCLAIMER 0.05, DART_B_UPD 0.50, FH_HELO_EQ_D_D_D_D 3.18, HELO_DYNAMIC_IPADDR 1.95, RCVD_IN_PBL 3.33, RCVD_IN_SORBS_DUL 0.00, RDNS_NONE 0.79) X-MailScanner-SpamScore: ssssssss X-MailScanner-From: massimiliano.pala@dartmouth.edu Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 19 Apr 2011 21:22:42 -0000 This is a cryptographically signed message in MIME format. --------------ms050808050109070205050806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I understand the concern, but it seems to me we shall address this issue somehow. Any other idea that could provide a viable solution to this issue ? What about a little more "complex" hashing like the following: Hash(Hash(pKey) + Hash(email)) Cheers, Max On 04/19/2011 03:33 PM, Kemp, David P. wrote: > I suspect that spammers, having gone to the trouble of harvesting > certificates, would not balk at building rainbow tables for the hashes.= > There is not a whole lot of entropy in "localpart" @gmail.com, > @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so > salting doesn't help. It may be a bit more difficult to enumerate > corporate, as opposed to public, email providers, but even so, this > sounds like a small deterrent to a dedicated spammer. > > And if hashing gives a false sense of security, the harvesting step may= > be made easier. > > Dave > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of= > Massimiliano Pala > Sent: Tuesday, April 19, 2011 12:39 PM > To: pkix@ietf.org > Subject: [pkix] Email in Certs and Privacy Concerns > > Hello all, > > I was thinking about a privacy problem we have in currently issued > certs: > email addresses. > > Some CAs make the case that they do not wish to publish the list of > certs to avoid spammers to easily harvest all the email addresses in > certs. > > A simple solution would be to allow for using an hash of the email > address instead of the email address itself in the subjectAltName. This= > would prevent attackers from using that information for spam/marketing > purposes, but still clients can easily verify the email address by > simply hashing the From: email address and compare the hash instead of > the bare address. > > This approach could be used also to protect hostnames, although I don't= > see privacy issues there (maybe in some "special" environments?) > > Since this addresses an important issue, shall we try to have a small > and quick I-D that describes the addition ? > > Does this sound reasonable and easy to deploy ? > --=20 Best Regards, Massimiliano Pala --o----------------------------------------------------------------------= -- Massimiliano Pala [OpenCA Project Manager] openca@acm.o= rg project.manager@openca.= org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-93= 32 PKI/Trust Laboratory Work Phone: +1 (603) 646-87= 34 --o----------------------------------------------------------------------= -- People who think they know everything are a great annoyance to those of u= s who do. -- Isaac Asimov --------------ms050808050109070205050806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6DCC BHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkW A2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTEw MDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNlZHUxGTAX BgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3Np bWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVYpWfvkEzS HWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN/4cqgCPY yjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHaOwk9SUc7 rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2cED6ioDn 2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn5h9WBlxK 7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1UdDwEB/wQE AwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C/DA3BgNV HR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNhLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2ltaWxpYW5v LlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYeTaN3EjAN BgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2KJs8xm93d yTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBcTDec5NWe 7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9Fa6HDxEM Xg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt/ZD6rJkE jYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQke9fCfwsx zghYIDCCBHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT 8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAY BgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgx MB4XDTEwMDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNl ZHUxGTAXBgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFE YXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMT EU1hc3NpbWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVY pWfvkEzSHWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN /4cqgCPYyjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHa Owk9SUc7rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2 cED6ioDn2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn 5h9WBlxK7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1Ud DwEB/wQEAwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C /DA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNh LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2lt aWxpYW5vLlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYe TaN3EjANBgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2K Js8xm93dyTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBc TDec5NWe7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9 Fa6HDxEMXg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt /ZD6rJkEjYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQk e9fCfwsxzghYIDGCA5owggOWAgEBMIGCMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJ kiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGgg Q29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQIHAIkS6kMSADAJBgUrDgMC GgUAoIIB7DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0 MTkyMTIzMjRaMCMGCSqGSIb3DQEJBDEWBBSG5YPp1+9az7v8rAujnfYC3J1JsTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZMGCSsGAQQBgjcQBDGBhTCB gjB3MRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZImiZPyLGQBGRYJZGFydG1vdXRoMQsw CQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENvbGxlZ2UxHDAaBgNVBAMTE0RhcnRt b3V0aCBDZXJ0QXV0aDECBwCJEupDEgAwgZUGCyqGSIb3DQEJEAILMYGFoIGCMHcxEzARBgoJ kiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVT MRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRB dXRoMQIHAIkS6kMSADANBgkqhkiG9w0BAQEFAASCAQCIKytxDSG5RXcQWxWxeYO0Gp/zU+5L aUuaIwePPvFbb8MUI+MTTnuzi5UrtHO2uPS+XVaZF4RTuqb8dDGuHKNya7UYN09Qfu5NLamz bAZQucAsHzPiSKGHTMVOibqg2zsXzrETJXnsJwFgg9BgFETBC8U7fySBwCIEja/tXxPS3Yl6 RSICuoMosoYkUXDALpij7Dru7SOx9beludORlQihSj8SavDvcVwNJuFBCFwsaqv/rai14H50 2ttHKqfp4OReIg31dYkEHpv+g4gJ+QE/PedkBY7e2FrTQaLW4UMC2afTQ7kKW3JYRWNHpzRN SlU91EtihKCVPMJQD1GHuuVzAAAAAAAA --------------ms050808050109070205050806-- From hotz@jpl.nasa.gov Tue Apr 19 17:52:04 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2CF11E072F for ; Tue, 19 Apr 2011 17:52:04 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNHePw7la+z1 for ; Tue, 19 Apr 2011 17:52:03 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by ietfc.amsl.com (Postfix) with ESMTP id 27DDAE0670 for ; Tue, 19 Apr 2011 17:52:02 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3K0q04h009133 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Tue, 19 Apr 2011 17:52:01 -0700 From: "Henry B. Hotz" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Apr 2011 17:52:00 -0700 Message-Id: To: pkix PKIX Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Subject: [pkix] Recommended Language for a Security Issue 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, 20 Apr 2011 00:52:04 -0000 I still don't think I have this right. My latest iteration on the = warning label to go in the draft-hotz-kx509 (not yet submitted) is: The public key in the request is sent in the clear, and without any guarantees that the requestor actually possesses the corresponding private key. Therefore the only appropriate uses of the returned certificate are those where the subsequent use independently guarantees that the user possesses the private key. In particular the returned certificate MUST NOT be used for durable signatures of application data unless the application's use is appropriately structured, or the identity of the signer is not important. In less formal terms: the public key in the request could be sniffed by = someone and they could send their own request with the same public key. = Then there would exist two certs whose keys would match something signed = by the first requestor. That might support a form of plagiarism. Is the above language good enough? I'm specifically concerned that my = use of the term "durable" may not be standard enough for the weight it = carries. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hallam@gmail.com Tue Apr 19 18:26:09 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D248E073C for ; Tue, 19 Apr 2011 18:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGPBBWM0R95O for ; Tue, 19 Apr 2011 18:26:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 21AD5E0720 for ; Tue, 19 Apr 2011 18:26:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so239626vxg.31 for ; Tue, 19 Apr 2011 18:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HDSehKS5bJUDlsSWUmrs2hD4XFUqrwdkEIw3lFyjmBI=; b=ci63m+OimaIBx8yqEbyRFJjXouv79sEFZJvmtVmfjTyI9ejazaEp40bw5v0X5Py/do mLFotW/lbNcbOc8zOfsSPS44o5y63h4pVdWHcafgh2vMmUMLlSLBUrvlSkgF/mSsSesi 9/r4YrYDHB/c99dJrgWbim7RnLcT09uppICsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eDwcIVSc0P/Wm8tQ0pdE8xB9/Bx5wY8qe4zsSBsDluWy2bisC7jm3fm/uFo+56Zvk3 JYDDzZNKYcDSxLg4Ap9JMv8Gxfm01U9TZMho4PY15YE/aadr4YLqqFGnbZvghPF6wNxn GyPxGGr0T27JL6n9jhLkrWiaJbkhzt4LaMZpQ= MIME-Version: 1.0 Received: by 10.52.77.70 with SMTP id q6mr1689200vdw.165.1303262767485; Tue, 19 Apr 2011 18:26:07 -0700 (PDT) Received: by 10.52.161.3 with HTTP; Tue, 19 Apr 2011 18:26:06 -0700 (PDT) In-Reply-To: References: <4DADA172.4090201@cs.tcd.ie> Date: Tue, 19 Apr 2011 21:26:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=20cf3071cfae4e11f704a14f8228 Cc: pkix@ietf.org, stefan@aaa-sec.com Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re: 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, 20 Apr 2011 01:26:09 -0000 --20cf3071cfae4e11f704a14f8228 Content-Type: text/plain; charset=ISO-8859-1 It PKIX never comes to a conclusion that what DANE is doing is bad, then DANE need take no action. [DANE dropped from followups as per direction of AD] On Tue, Apr 19, 2011 at 11:01 AM, Peter Gutmann wrote: > Stephen Farrell writes: > > >So can we take the discussion over to pkix then and have this be the last > >message on this topic to dane until pkix has come to some conclusion? > > What if they never come to a conclusion (which is not unusual whenever a > tough > topic comes up)? We should probably set a timer to expire after which > (shudder) things start up here again. > > (Sorry, still sent to DANE since it's relevant here. "Kick it over to > PKIX" > presupposes that it'll converge on a solution at some point). > > Peter. > -- Website: http://hallambaker.com/ --20cf3071cfae4e11f704a14f8228 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It PKIX never comes to a conclusion that what DANE is doing is bad, then DA= NE need take no action.

[DANE dropped from followups as = per direction of AD]

On Tue, Apr 19, 2011= at 11:01 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Stephen Farrell <stephen.farrell@cs.tcd.ie> w= rites:

>So can we take the discussion over to pkix then and have this be the la= st
>message on this topic to dane until pkix has come to some conclusion?
What if they never come to a conclusion (which is not unusual wheneve= r a tough
topic comes up)? =A0We should probably set a timer to expire after which (shudder) things start up here again.

(Sorry, still sent to DANE since it's relevant here. =A0"Kick it o= ver to PKIX"
presupposes that it'll converge on a solution at some point).

Peter.



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

--20cf3071cfae4e11f704a14f8228-- From hallam@gmail.com Wed Apr 20 14:30:19 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E1C32E078F for ; Wed, 20 Apr 2011 14:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us-MngMi0+jS for ; Wed, 20 Apr 2011 14:30:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 6EB7AE066E for ; Wed, 20 Apr 2011 14:30:18 -0700 (PDT) Received: by vws12 with SMTP id 12so1113660vws.31 for ; Wed, 20 Apr 2011 14:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sRbDpEbkaNoNuQClHmeKbHVS1OhffTGZ58astYLRTTU=; b=uxvRkmDwx52XlRvgWb4HIKbVfC+PMSwsCgMBf4nmnDcQi3uaD8MhNTp1Tr9pJnd0NQ rnFR2+WiWq5prv6ggueQNVbwkUomN40DEixHG08wHgAjrkK35oXMeEpFny/EKRjDPxUs 1/DXgD7HHlHVHKjoRnS5ThFwCczVwXP+Vz/9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aA9OBsLyqUmR0KXYta+exJD2wpP6i8cX0O+rsKM0xyE1hLvoqDx8iqlPo1HRDo9YI+ vYCBEqwLZK4fgseyuw3uyg/uzPS5f4IXo4noKxjl4nwQvgKMKTTj6eytqYZrGc618OOp k8R0BEv0ReV004/6IoPnZMJ4NkCq12Cmy84A4= MIME-Version: 1.0 Received: by 10.52.186.69 with SMTP id fi5mr481603vdc.205.1303335017599; Wed, 20 Apr 2011 14:30:17 -0700 (PDT) Received: by 10.52.161.3 with HTTP; Wed, 20 Apr 2011 14:30:17 -0700 (PDT) In-Reply-To: References: <4DAC28E7.2070602@cs.tcd.ie> Date: Wed, 20 Apr 2011 17:30:17 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: multipart/alternative; boundary=bcaec548610abf540804a160549a Cc: pkix Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 20 Apr 2011 21:30:20 -0000 --bcaec548610abf540804a160549a Content-Type: text/plain; charset=ISO-8859-1 That works for me too. [But to be strictly precise, I never said that the existing spec was unclear, I merely stated that it was necessary to clarify it. I don't think we need elaborate on that distinction.] On Tue, Apr 19, 2011 at 2:22 PM, Kemp, David P. wrote: > [dane omitted] > > > From: Stefan Santesson > > > A self signed cert is simply a convenient way to communicate > > a public key for an entity that has not been certified by a CA. > > I would say that it is a self signed cert. Period. Disregarding > > what type of entity it represents. > > +1. It is also syntactically a "certificate" but semantically not a > certification, regardless of what type of entity it represents. > > > From: Stephen Farrell > > > My conclusion is that neither 5280 nor the pkix archives > > justify any conclusion about self-signed end-entity certs. > > +1. PKIX describes three types of CA certificates, one of which is an > assertion by an entity about itself, not a certification by some other > authority. Saying "some CA certificates are self-signed" is not a > prohibition against "some non-CA certificates" also being self-signed, > it is silence. > > > From: Phillip Hallam-Baker > > > I really don't see this as a DANE issue. I see it as > > a requirement to clarify the PKIX spec as follows: > > > > * CA signing key usage MUST be set for keys used to sign > > certificates for any key OTHER THAN THEMSELVES. > > > > * EE certs may be CA signed or self-signed. > > > RFC 5280 Section 4.2.1.3 Key Usage says: > > Conforming CAs MUST include this extension > in certificates that contain public keys that are used > to validate digital signatures on other public key > certificates or CRLs. > > So the first bullet is unnecessary, PKIX is already perfectly clear. > > > > And, the biggest advantage [of X.509v1]: enforcing a rule > > "do not accept as signers > > of other certs" is trivial and fool-proof to implement, so that you > > don't create immediate and serious problems when you add such > > certs to the list of trusted keys for your PKI software along > > with Trust Anchors from commercial CAs. > > Section 6.1.4 of Basic Validation says: > > (k) If certificate i is a version 3 certificate, verify that the > basicConstraints extension is present and that cA is set to > TRUE. (If certificate i is a version 1 or version 2 > certificate, then the application MUST either verify that > certificate i is a CA certificate through out-of-band means > or reject the certificate. Conforming implementations may > choose to reject all version 1 and version 2 intermediate > certificates.) > > So that is not an advantage of v1 vs. v3. If a cert does not include a > basic constraints extension, it is already "trivial and foolproof" to > implement the rule that it is not a CA cert, yet apparently some > application developers have managed to botch it. How likely is it that > the version field would be a "more foolproof" indicator of non-CA-ness > than basic constraints? > > >From the data collected by EFF, there appear to be > > ~ 830000 self-signed X.509v3 Web Server Certs installed > > on the internet with the BasicConstraint cA=TRUE > > ~ 494000 self-signed X.509v1 Web Server Certs installed > > on the internet > > ~ 56000 self-signed X.509v3 Web Server certs installed > > on the internet without the BasicConstraint cA=TRUE > > What impact can PKIX have, with or without additional guidance, on the > issuers of these certs? 5280 may be complex, but the part about EE > certs not being CA certs seems clear enough. Yet the number of CA certs > issued by EEs to themselves dwarfs the number of v1 certs and EE certs > combined. > > I prefer Stefan's clarification - self-signed certs have properties X, Y > and Z regardless of type of entity named in the subject field. But I > have no illusions about the likelihood of any such clarification being > "foolproof". > > Dave > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Website: http://hallambaker.com/ --bcaec548610abf540804a160549a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That works for me too.

[But to be strictly precise, I ne= ver said that the existing spec was unclear, I merely stated that it was ne= cessary to clarify it. I don't think we need elaborate on that distinct= ion.]

On Tue, Apr 19, 2011 at 2:22 PM, Kemp, David= P. <DPKemp@m= issi.ncsc.mil> wrote:
[dane omitted]


From: Stefan Santesson

> A self signed cert is simply a convenient way to communicate
> a public key for an entity that has not been certified by a CA.
> I would say that it is a self signed cert. Period. Disregarding
> what type of entity it represents.

+1. =A0It is also syntactically a "certificate" but semanti= cally not a
certification, regardless of what type of entity it represents.


From: Stephen Farrell

> My conclusion is that neither 5280 nor the pkix archives
> justify any conclusion about self-signed end-entity certs.

+1. =A0PKIX describes three types of CA certificates, one of which is= an
assertion by an entity about itself, not a certification by some other
authority. =A0Saying "some CA certificates are self-signed" is no= t a
prohibition against "some non-CA certificates" also being self-si= gned,
it is silence.


From: Phillip Hallam-Baker

> I really don't see this as a DANE issue. I see it as
> a requirement to clarify the PKIX spec as follows:
>
> * CA signing key usage MUST be set for keys used to sign
> certificates for any key OTHER THAN THEMSELVES.
>
> * EE certs may be CA signed or self-signed.


RFC 5280 Section 4.2.1.3 Key Usage says:

=A0 =A0 =A0 Conforming CAs MUST include this extension
=A0 =A0 =A0 in certificates that contain public keys that are used
=A0 =A0 =A0 to validate digital signatures on other public key
=A0 =A0 =A0 certificates or CRLs.

So the first bullet is unnecessary, PKIX is already perfectly clear.


> And, the biggest advantage [of X.509v1]: enforcing a rule
> "do not accept as signers
> of other certs" is trivial and fool-proof to implement, so that y= ou
> don't create immediate and serious problems when you add such
> certs to the list of trusted keys for your PKI software along
> with Trust Anchors from commercial CAs.

Section 6.1.4 of Basic Validation says:

=A0 =A0 =A0(k) =A0If certificate i is a version 3 certificate, verify that= the
=A0 =A0 =A0 =A0 =A0 basicConstraints extension is present and that cA is s= et to
=A0 =A0 =A0 =A0 =A0 TRUE. =A0(If certificate i is a version 1 or version 2=
=A0 =A0 =A0 =A0 =A0 certificate, then the application MUST either verify t= hat
=A0 =A0 =A0 =A0 =A0 certificate i is a CA certificate through out-of-band = means
=A0 =A0 =A0 =A0 =A0 or reject the certificate. =A0Conforming implementatio= ns may
=A0 =A0 =A0 =A0 =A0 choose to reject all version 1 and version 2 intermedi= ate
=A0 =A0 =A0 =A0 =A0 certificates.)

So that is not an advantage of v1 vs. v3. =A0If a cert does not include a basic constraints extension, it is already "trivial and foolproof"= ; to
implement the rule that it is not a CA cert, yet apparently some
application developers have managed to botch it. =A0How likely is it that the version field would be a "more foolproof" indicator of non-CA= -ness
than basic constraints?

>From the data collected by EFF, there appear to be
> =A0~ 830000 self-signed X.509v3 Web Server Certs installed
> =A0 =A0on the internet with the BasicConstraint cA=3DTRUE
> =A0~ 494000 self-signed X.509v1 Web Server Certs installed
> =A0 =A0on the internet
> =A0~ =A056000 self-signed X.509v3 Web Server certs installed
> =A0 =A0on the internet without the BasicConstraint cA=3DTRUE

What impact can PKIX have, with or without additional guidance, on the
issuers of these certs? =A05280 may be complex, but the part about EE
certs not being CA certs seems clear enough. =A0Yet the number of CA certs<= br> issued by EEs to themselves dwarfs the number of v1 certs and EE certs
combined.

I prefer Stefan's clarification - self-signed certs have properties X, = Y
and Z regardless of type of entity named in the subject field. =A0But I
have no illusions about the likelihood of any such clarification being
"foolproof".

Dave

_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix



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

--bcaec548610abf540804a160549a-- From tgindin@us.ibm.com Thu Apr 21 07:45:31 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F8D4E07A5 for ; Thu, 21 Apr 2011 07:45:31 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8zxlS62wVUZ for ; Thu, 21 Apr 2011 07:45:30 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfc.amsl.com (Postfix) with ESMTP id 52A34E07A3 for ; Thu, 21 Apr 2011 07:45:28 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3LEHBjN005770 for ; Thu, 21 Apr 2011 10:17:11 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3LEjMNX1654958 for ; Thu, 21 Apr 2011 10:45:23 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3LEjCvl008416 for ; Thu, 21 Apr 2011 11:45:12 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3LEjA8B008268; Thu, 21 Apr 2011 11:45:11 -0300 In-Reply-To: <4DADFD4C.6000100@Dartmouth.edu> References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> To: Massimiliano Pala MIME-Version: 1.0 X-KeepSent: 873686D3:C8314846-85257879:0048EEFC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Thu, 21 Apr 2011 10:45:12 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 04/21/2011 10:45:10, Serialize complete at 04/21/2011 10:45:10 Content-Type: text/plain; charset="US-ASCII" Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 21 Apr 2011 14:45:31 -0000 How about just hashing the concatenation of SubjectPublicKeyInfo and rfc822Address? At least it kills off reusable dictionary attacks, and the key's entropy is very high. The second hash step doesn't buy you much against attempts to calculate the "top 20K addresses" and compare. Remember, the spammer is an ordinary RP who happens to be malicious, and anything the ordinary RP can calculate it can also calculate. Tom Gindin From: Massimiliano Pala To: pkix@ietf.org Date: 04/19/2011 05:29 PM Subject: Re: [pkix] Email in Certs and Privacy Concerns Sent by: pkix-bounces@ietf.org Hi, I understand the concern, but it seems to me we shall address this issue somehow. Any other idea that could provide a viable solution to this issue ? What about a little more "complex" hashing like the following: Hash(Hash(pKey) + Hash(email)) Cheers, Max On 04/19/2011 03:33 PM, Kemp, David P. wrote: > I suspect that spammers, having gone to the trouble of harvesting > certificates, would not balk at building rainbow tables for the hashes. > There is not a whole lot of entropy in "localpart" @gmail.com, > @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so > salting doesn't help. It may be a bit more difficult to enumerate > corporate, as opposed to public, email providers, but even so, this > sounds like a small deterrent to a dedicated spammer. > > And if hashing gives a false sense of security, the harvesting step may > be made easier. > > Dave > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Massimiliano Pala > Sent: Tuesday, April 19, 2011 12:39 PM > To: pkix@ietf.org > Subject: [pkix] Email in Certs and Privacy Concerns > > Hello all, > > I was thinking about a privacy problem we have in currently issued > certs: > email addresses. > > Some CAs make the case that they do not wish to publish the list of > certs to avoid spammers to easily harvest all the email addresses in > certs. > > A simple solution would be to allow for using an hash of the email > address instead of the email address itself in the subjectAltName. This > would prevent attackers from using that information for spam/marketing > purposes, but still clients can easily verify the email address by > simply hashing the From: email address and compare the hash instead of > the bare address. > > This approach could be used also to protect hostnames, although I don't > see privacy issues there (maybe in some "special" environments?) > > Since this addresses an important issue, shall we try to have a small > and quick I-D that describes the addition ? > > Does this sound reasonable and easy to deploy ? > -- Best Regards, Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] openca@acm.org project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o------------------------------------------------------------------------ People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov [attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From ietf@augustcellars.com Thu Apr 21 17:21:56 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9E444E06DD for ; Thu, 21 Apr 2011 17:21:56 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1wQypSjY8lf for ; Thu, 21 Apr 2011 17:21:55 -0700 (PDT) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by ietfc.amsl.com (Postfix) with ESMTP id AB3F2E065C for ; Thu, 21 Apr 2011 17:21:55 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id 20E8E2CA4D; Thu, 21 Apr 2011 17:21:53 -0700 (PDT) From: "Jim Schaad" To: "'Tom Gindin'" , "'Massimiliano Pala'" References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> In-Reply-To: Date: Thu, 21 Apr 2011 17:47:49 -0700 Message-ID: <009701cc0086$e9e92490$bdbb6db0$@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: AQJEmCtalZMO7C7kG3zpxp6ioSbq8AF4QNzlAmWsC0MB77PyfZNJXLeQ Content-Language: en-us Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 22 Apr 2011 00:21:56 -0000 What is the point of the CA publishing certificates if I can't ask to find a certificate by the email address? The privacy question might be a different issue as once I give you a certificate then I cannot control who you release it to and having minor privacy at least makes you release two pieces of associated information rather than just one. Jim > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Tom Gindin > Sent: Thursday, April 21, 2011 7:45 AM > To: Massimiliano Pala > Cc: pkix@ietf.org > Subject: Re: [pkix] Email in Certs and Privacy Concerns > > How about just hashing the concatenation of SubjectPublicKeyInfo and > rfc822Address? At least it kills off reusable dictionary attacks, and the key's > entropy is very high. The second hash step doesn't buy you much against > attempts to calculate the "top 20K addresses" and compare. > Remember, the spammer is an ordinary RP who happens to be malicious, > and anything the ordinary RP can calculate it can also calculate. > > Tom Gindin > > > > > From: > Massimiliano Pala > To: > pkix@ietf.org > Date: > 04/19/2011 05:29 PM > Subject: > Re: [pkix] Email in Certs and Privacy Concerns Sent by: > pkix-bounces@ietf.org > > > > Hi, > > I understand the concern, but it seems to me we shall address this issue > somehow. Any other idea that could provide a viable solution to this issue ? > What about a little more "complex" hashing like the > following: > > Hash(Hash(pKey) + Hash(email)) > > > Cheers, > Max > > > On 04/19/2011 03:33 PM, Kemp, David P. wrote: > > I suspect that spammers, having gone to the trouble of harvesting > > certificates, would not balk at building rainbow tables for the hashes. > > There is not a whole lot of entropy in "localpart" @gmail.com, > > @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so > > salting doesn't help. It may be a bit more difficult to enumerate > > corporate, as opposed to public, email providers, but even so, this > > sounds like a small deterrent to a dedicated spammer. > > > > And if hashing gives a false sense of security, the harvesting step > > may be made easier. > > > > Dave > > > > > > -----Original Message----- > > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf > > Of Massimiliano Pala > > Sent: Tuesday, April 19, 2011 12:39 PM > > To: pkix@ietf.org > > Subject: [pkix] Email in Certs and Privacy Concerns > > > > Hello all, > > > > I was thinking about a privacy problem we have in currently issued > > certs: > > email addresses. > > > > Some CAs make the case that they do not wish to publish the list of > > certs to avoid spammers to easily harvest all the email addresses in > > certs. > > > > A simple solution would be to allow for using an hash of the email > > address instead of the email address itself in the subjectAltName. > > This would prevent attackers from using that information for > > spam/marketing purposes, but still clients can easily verify the email > > address by simply hashing the From: email address and compare the hash > > instead of the bare address. > > > > This approach could be used also to protect hostnames, although I > > don't see privacy issues there (maybe in some "special" environments?) > > > > Since this addresses an important issue, shall we try to have a small > > and quick I-D that describes the addition ? > > > > Does this sound reasonable and easy to deploy ? > > > > > -- > > Best Regards, > > Massimiliano Pala > > --o------------------------------------------------------------------------ > Massimiliano Pala [OpenCA Project Manager] openca@acm.org > project.manager@openca.org > > Dartmouth Computer Science Dept Home Phone: +1 (603) > 369-9332 > PKI/Trust Laboratory Work Phone: +1 (603) > 646-8734 > --o------------------------------------------------------------------------ > People who think they know everything are a great annoyance to those of us > who do. > -- Isaac Asimov > > [attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] > _______________________________________________ > 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 pgut001@login01.cs.auckland.ac.nz Fri Apr 22 04:11:53 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D55FEE0696 for ; Fri, 22 Apr 2011 04:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u-C-45PYPza for ; Fri, 22 Apr 2011 04:11:53 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id D67A4E0688 for ; Fri, 22 Apr 2011 04:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1303470713; x=1335006713; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20DPKemp@missi.ncsc.mil,=20pkix@ietf.org|Subject:=20 Re:=20[pkix]=205280=20and=20self-signed=20ee=20certs=20(w as:=20Re:=20[dane]=20[keyassure]=20Use=20cases=20document .)|In-Reply-To:=20|Message-Id:=20|Date:=20Fri,=2022=20Apr=202 011=2023:11:48=20+1200; bh=y8YrBJQ+Y+hJmEicBsiI+Xs2WgdTIFdqYqjDuL5ICSE=; b=mxuzZlXzpTZuQaEziEMGljjpTeGQNw8ZsQs5Z84FeDlGCKYBG8YqnF1F 4RSOe9PY41xx/r9Q8vjqTSQB8vBiSPpQ/slp3+aoLWySaxQ52W3PEfQRP zwYvuD9fADSt800/ZuN5QekFI3glCug0C25BkFdgTi6y1NafUMNkYsAXp I=; X-IronPort-AV: E=Sophos;i="4.64,253,1301832000"; d="scan'208";a="57846822" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Apr 2011 23:11:49 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QDEH6-0001P3-J0; Fri, 22 Apr 2011 23:11:48 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QDEH6-0002n4-Qq; Fri, 22 Apr 2011 23:11:48 +1200 From: Peter Gutmann To: DPKemp@missi.ncsc.mil, pkix@ietf.org In-Reply-To: Message-Id: Date: Fri, 22 Apr 2011 23:11:48 +1200 Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 22 Apr 2011 11:11:54 -0000 "Kemp, David P." writes: >It is also syntactically a "certificate" but semantically not a >certification, regardless of what type of entity it represents. We could really get into some semantic nitpicking here :-), but I'd say that a self-signed cert is an assertion if not necessarily a certification. Mind you what many commercial CAs do is just an assertion as well, so in neither case could you really call them certifications. Peter. From tmiller@mitre.org Fri Apr 22 04:46:41 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DD0CFE06C1 for ; Fri, 22 Apr 2011 04:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYFJ3hb9t3+l for ; Fri, 22 Apr 2011 04:46:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfc.amsl.com (Postfix) with ESMTP id EF76AE06B1 for ; Fri, 22 Apr 2011 04:46:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7EA621B1DA3; Fri, 22 Apr 2011 07:46:39 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D146021B05CC; Fri, 22 Apr 2011 07:46:39 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 22 Apr 2011 07:46:39 -0400 From: "Miller, Timothy J." To: Peter Gutmann Date: Fri, 22 Apr 2011 07:46:39 -0400 Thread-Topic: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) Thread-Index: AcwA4vD3pCUuOTyTSR6vqOjpSrwMaQ== Message-ID: <3C79B3DA-9CB2-49CB-AC15-97AD6C93BAB8@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1-895568603"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 22 Apr 2011 11:46:42 -0000 --Apple-Mail-1-895568603 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 22, 2011, at 6:11 AM, Peter Gutmann wrote: > "Kemp, David P." writes: >=20 >> It is also syntactically a "certificate" but semantically not a >> certification, regardless of what type of entity it represents. >=20 > We could really get into some semantic nitpicking here :-), but I'd = say that a=20 > self-signed cert is an assertion if not necessarily a certification. = Mind you=20 > what many commercial CAs do is just an assertion as well, so in = neither case=20 > could you really call them certifications. Yeah, but unlike a self-asserter commercial CAs can be held liable = (within unclear and probably variable limits). That's probably as good = as we're going to get, so I'm good with calling them certifications. :) -- T --Apple-Mail-1-895568603 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjIxMTQ2MzlaMCMGCSqGSIb3DQEJBDEWBBQE/6Vih6do0uw3cDIO LNkH1Jz5tzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgEXt3IGkDQxFBKb13dDF0KbpklCjz/XhC/26 K+bpx/Uv/U2UKZSKGeCOnW7usnbGOY7AWM3jrMAI+kCFWSsofHOHav62v2ikGKQH9CsrnkGSDD5b vHp0nnryeFCA2tFJzdRBbsyyyNTRf+kwQSSedWkBOlw0mvs92q1zFLPBPYG0AAAAAAAA --Apple-Mail-1-895568603-- From pgut001@login01.cs.auckland.ac.nz Fri Apr 22 05:21:34 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 28F8CE06B6 for ; Fri, 22 Apr 2011 05:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mocxqSbNdW4i for ; Fri, 22 Apr 2011 05:21:33 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id CBA81E0694 for ; Fri, 22 Apr 2011 05:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1303474893; x=1335010893; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20pgut001@cs.auckland.ac.nz,=20tmiller@mitre.org |Subject:=20Re:=20[pkix]=205280=20and=20self-signed=20ee =20certs=20(was:=20Re:=20[dane]=09[keyassure]=20Use=20cas es=20document.)|Cc:=20pkix@ietf.org|In-Reply-To:=20<3C79B 3DA-9CB2-49CB-AC15-97AD6C93BAB8@mitre.org>|Message-Id:=20 |Date:=20Sa t,=2023=20Apr=202011=2000:21:31=20+1200; bh=4iGCGswy1GRuYEMyYUc9v7GQTOFbvp1UsdoeDItp6qg=; b=hx0cAbWUExziVGxSQ9VuaMAEkP32+HGRw6T2Jy6ciBzibILTQEXFoAIX D8Ta9C0L0WeNRQSayn8YVYWiSrupvfsO2UvN3KaGSW5MN+6kCJRlH36id pOMUFNtocpoHpM9GhOWlWW6+JyNLeuWtyve3O32qafvbE/vYsJM2mm7wi g=; X-IronPort-AV: E=Sophos;i="4.64,253,1301832000"; d="scan'208";a="57849468" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Apr 2011 00:21:32 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QDFMZ-0003Lq-HE; Sat, 23 Apr 2011 00:21:31 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QDFMZ-0006VI-97; Sat, 23 Apr 2011 00:21:31 +1200 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, tmiller@mitre.org In-Reply-To: <3C79B3DA-9CB2-49CB-AC15-97AD6C93BAB8@mitre.org> Message-Id: Date: Sat, 23 Apr 2011 00:21:31 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.) 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, 22 Apr 2011 12:21:34 -0000 "Miller, Timothy J." writes: >Yeah, but unlike a self-asserter commercial CAs can be held liable (within >unclear and probably variable limits). Hmm, you haven't been following the discussion on the Mozilla policy list have you? Effectively once a commercial CA has issued enough certs to become Too Big To Fail, it's absolved of any liability (that's a very, very cut-down summary of an interminable discussion, see the thread "Response from Comodo" for the full thing). Peter. From Massimiliano.Pala@Dartmouth.edu Fri Apr 22 06:18:11 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0134BE067C for ; Fri, 22 Apr 2011 06:18:11 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi49RWnVN8vk for ; Fri, 22 Apr 2011 06:18:09 -0700 (PDT) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by ietfc.amsl.com (Postfix) with ESMTP id CC278E05F5 for ; Fri, 22 Apr 2011 06:18:09 -0700 (PDT) Received: from newblitzen.Dartmouth.EDU (newblitzen.Dartmouth.EDU [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id p3MDHeJn029776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Apr 2011 09:17:58 -0400 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from c-68-45-60-165.hsd1.nj.comcast.net [68.45.60.165] by newblitzen.Dartmouth.EDU (Mac) via SMTP for id <190391454>; 22 Apr 2011 09:17:58 -0400 Message-ID: <4DB1803C.4000903@Dartmouth.edu> Date: Fri, 22 Apr 2011 09:18:52 -0400 From: Massimiliano Pala Organization: Dartmouth College / OpenCA Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Jim Schaad References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> In-Reply-To: <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050300000608080806040503" X-MailScanner: Found to be clean by mailhub2.dartmouth.edu X-MailScanner-SpamCheck: spam, SpamAssassin (not cached, score=8.587, required 1, autolearn=spam, AWL -0.72, BAYES_40 -0.00, BLITZ_DISCLAIMER 0.05, FH_HELO_EQ_D_D_D_D 3.18, HELO_DYNAMIC_IPADDR 1.95, RCVD_IN_PBL 3.33, RCVD_IN_SORBS_DUL 0.00, RDNS_NONE 0.79) X-MailScanner-SpamScore: ssssssss X-MailScanner-From: massimiliano.pala@dartmouth.edu Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 22 Apr 2011 13:18:11 -0000 This is a cryptographically signed message in MIME format. --------------ms050300000608080806040503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Jim, Tom, all, [Tom: Hash] Maybe I am missing the point, but if we use a simple concatenation, the attacker could just use dictionary attack on the second part of the value= , right ? If you are proposing something like: hash(skid) + hash(addr), as an attacker I would just ignore the first XXX bytes (from hash(skid)). That is why I thought about re-hashing everything. Of course, there is one issue with not using the addr value directly: how to handle upper/low cases. In particular, although (if I remember correctly) only the domain part should be case-insensitive, in practice everybody treats all the parts of an email address as case-insensitive. Therefore, if we agree on any form of protection for the email addr in certificates, then the hash(addr) should probably be something like hash(lc(add)) or hash(uc(addr)). [Jim: searching] Actually, searching for the certificate and the contents of the certifica= te are, from a CA point of view, not correlated. Most of the CA software use= meta-data for certificate publication, not only the contents of the cert.= So, for example, you can have an LDAP server that has attributes like dn:= and multiple mail: . This allows a client to search with the mail: attrib= ute and retrieve the userCertificate;binary one. Then, by comparing the hash(= ) with the email addr used for sending the email, the client can pick the right certificate. So, we get the benefits for searching and when the certificate is used fo= r email purposes. But when used for other purposes (eg., SSL/TLS auth), the= email address is not automatically disclosed. Does this make sense ? Cheers, Max On 04/21/2011 08:47 PM, Jim Schaad wrote: > What is the point of the CA publishing certificates if I can't ask to f= ind a > certificate by the email address? > > The privacy question might be a different issue as once I give you a > certificate then I cannot control who you release it to and having mino= r > privacy at least makes you release two pieces of associated information= > rather than just one. > > Jim > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >> Tom Gindin >> Sent: Thursday, April 21, 2011 7:45 AM >> To: Massimiliano Pala >> Cc: pkix@ietf.org >> Subject: Re: [pkix] Email in Certs and Privacy Concerns >> >> How about just hashing the concatenation of SubjectPublicKeyI= nfo > and >> rfc822Address? At least it kills off reusable dictionary attacks, and= the > key's >> entropy is very high. The second hash step doesn't buy you much again= st >> attempts to calculate the "top 20K addresses" and compare. >> Remember, the spammer is an ordinary RP who happens to be malicious, >> and anything the ordinary RP can calculate it can also calculate. >> >> Tom Gindin >> >> >> >> >> From: >> Massimiliano Pala >> To: >> pkix@ietf.org >> Date: >> 04/19/2011 05:29 PM >> Subject: >> Re: [pkix] Email in Certs and Privacy Concerns Sent by: >> pkix-bounces@ietf.org >> >> >> >> Hi, >> >> I understand the concern, but it seems to me we shall address this iss= ue >> somehow. Any other idea that could provide a viable solution to this i= ssue > ? >> What about a little more "complex" hashing like the >> following: >> >> Hash(Hash(pKey) + Hash(email)) >> >> >> Cheers, >> Max >> >> >> On 04/19/2011 03:33 PM, Kemp, David P. wrote: >>> I suspect that spammers, having gone to the trouble of harvesting >>> certificates, would not balk at building rainbow tables for the hashe= s. >>> There is not a whole lot of entropy in "localpart" @gmail.com, >>> @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so >>> salting doesn't help. It may be a bit more difficult to enumerate >>> corporate, as opposed to public, email providers, but even so, this >>> sounds like a small deterrent to a dedicated spammer. >>> >>> And if hashing gives a false sense of security, the harvesting step >>> may be made easier. >>> >>> Dave >>> >>> >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >>> Of Massimiliano Pala >>> Sent: Tuesday, April 19, 2011 12:39 PM >>> To: pkix@ietf.org >>> Subject: [pkix] Email in Certs and Privacy Concerns >>> >>> Hello all, >>> >>> I was thinking about a privacy problem we have in currently issued >>> certs: >>> email addresses. >>> >>> Some CAs make the case that they do not wish to publish the list of >>> certs to avoid spammers to easily harvest all the email addresses in >>> certs. >>> >>> A simple solution would be to allow for using an hash of the email >>> address instead of the email address itself in the subjectAltName. >>> This would prevent attackers from using that information for >>> spam/marketing purposes, but still clients can easily verify the emai= l >>> address by simply hashing the From: email address and compare the has= h >>> instead of the bare address. >>> >>> This approach could be used also to protect hostnames, although I >>> don't see privacy issues there (maybe in some "special" environments?= ) >>> >>> Since this addresses an important issue, shall we try to have a small= >>> and quick I-D that describes the addition ? >>> >>> Does this sound reasonable and easy to deploy ? >>> >> >> >> -- >> >> Best Regards, >> >> Massimiliano Pala >> >> > --o--------------------------------------------------------------------= ---- >> Massimiliano Pala [OpenCA Project Manager] openca@acm.org >> project.manager@openca.org >> >> Dartmouth Computer Science Dept Home Phone: +1 (603) >> 369-9332 >> PKI/Trust Laboratory Work Phone: +1 (603) >> 646-8734 >> > --o--------------------------------------------------------------------= ---- >> People who think they know everything are a great annoyance to those o= f us >> who do. >> -- Isaac Asimov >> >> [attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] >> _______________________________________________ >> 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 Best Regards, Massimiliano Pala --o----------------------------------------------------------------------= -- Massimiliano Pala [OpenCA Project Manager] openca@acm.o= rg project.manager@openca.= org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-93= 32 PKI/Trust Laboratory Work Phone: +1 (603) 646-87= 34 --o----------------------------------------------------------------------= -- People who think they know everything are a great annoyance to those of u= s who do. -- Isaac Asimov --------------ms050300000608080806040503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6DCC BHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkW A2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTEw MDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNlZHUxGTAX BgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3Np bWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVYpWfvkEzS HWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN/4cqgCPY yjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHaOwk9SUc7 rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2cED6ioDn 2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn5h9WBlxK 7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1UdDwEB/wQE AwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C/DA3BgNV HR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNhLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2ltaWxpYW5v LlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYeTaN3EjAN BgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2KJs8xm93d yTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBcTDec5NWe 7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9Fa6HDxEM Xg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt/ZD6rJkE jYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQke9fCfwsx zghYIDCCBHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT 8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAY BgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgx MB4XDTEwMDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNl ZHUxGTAXBgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFE YXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMT EU1hc3NpbWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVY pWfvkEzSHWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN /4cqgCPYyjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHa Owk9SUc7rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2 cED6ioDn2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn 5h9WBlxK7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1Ud DwEB/wQEAwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C /DA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNh LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2lt aWxpYW5vLlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYe TaN3EjANBgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2K Js8xm93dyTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBc TDec5NWe7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9 Fa6HDxEMXg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt /ZD6rJkEjYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQk e9fCfwsxzghYIDGCA5owggOWAgEBMIGCMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJ kiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGgg Q29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQIHAIkS6kMSADAJBgUrDgMC GgUAoIIB7DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0 MjIxMzE4NTJaMCMGCSqGSIb3DQEJBDEWBBTiV6Gns0TbV4gabLTSZe5VbycQyTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZMGCSsGAQQBgjcQBDGBhTCB gjB3MRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZImiZPyLGQBGRYJZGFydG1vdXRoMQsw CQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENvbGxlZ2UxHDAaBgNVBAMTE0RhcnRt b3V0aCBDZXJ0QXV0aDECBwCJEupDEgAwgZUGCyqGSIb3DQEJEAILMYGFoIGCMHcxEzARBgoJ kiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVT MRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRB dXRoMQIHAIkS6kMSADANBgkqhkiG9w0BAQEFAASCAQA0yABC0h6VXIkn2wITiT6cFai7ZixU fiIIOOAAkyEv+FwZ2oILNAtwMm3jggOGHyCMHBRudisgrNC0FEWIUvmdhs9gfSx7eDEDHyqu pl3gNdhRtCXWwIMcJ10Kflh38N7fJ4H2ZztjZcm2OwH8Kz/PxP6hvkexvvD1SMCh3m7keJQu 4qFrtNVFdEyxNkulf9mfFEOjAPUlxpOYz27ygv0AyMHpyBKBVKePjA0XWJxqPWeiKkoseyfw VyIfacSdnbsLI1IpQzCm5+XsQVmTm9lTaSfi9cO/MNCIVlIY/1CITo0DnyXcXcV4W4rKiz75 zMlg7d6pqMnFy9rYkh9sx8SMAAAAAAAA --------------ms050300000608080806040503-- From DPKemp@missi.ncsc.mil Fri Apr 22 06:20:30 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F664E071A for ; Fri, 22 Apr 2011 06:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XZceVdbBDeM for ; Fri, 22 Apr 2011 06:20:30 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfc.amsl.com (Postfix) with ESMTP id 0612DE067C for ; Fri, 22 Apr 2011 06:20:29 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p3MDKTJJ052778 for ; Fri, 22 Apr 2011 09:20:29 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 09:20:08 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 22 Apr 2011 09:20:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) Thread-Index: AcwA5+GgNkVngT5cRPurpJLmBWV0rAABa83A References: <3C79B3DA-9CB2-49CB-AC15-97AD6C93BAB8@mitre.org> From: "Kemp, David P." To: X-OriginalArrivalTime: 22 Apr 2011 13:20:08.0390 (UTC) FILETIME=[0049F660:01CC00F0] Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 22 Apr 2011 13:20:30 -0000 So how is that different from my MSEE from Princeton University*? I'm sure they would refuse any and all liability, yet most people would consider that piece of sheepskin more authoritative than an MS degree I awarded to myself. Dave * I didn't go to Princeton, but I do have a MSEE from an institution of similar reputation. See me over a beer if you care which one. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Friday, April 22, 2011 8:22 AM To: pgut001@cs.auckland.ac.nz; tmiller@mitre.org Cc: pkix@ietf.org Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) "Miller, Timothy J." writes: >Yeah, but unlike a self-asserter commercial CAs can be held liable (within >unclear and probably variable limits). Hmm, you haven't been following the discussion on the Mozilla policy list have you? Effectively once a commercial CA has issued enough certs to become Too Big To Fail, it's absolved of any liability (that's a very, very cut-down summary of an interminable discussion, see the thread "Response from Comodo" for the full thing). Peter. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mattking1@gmail.com Fri Apr 22 10:51:26 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 16C74E0771 for ; Fri, 22 Apr 2011 10:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPNbsLikHS4e for ; Fri, 22 Apr 2011 10:51:25 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 57CAAE072A for ; Fri, 22 Apr 2011 10:51:25 -0700 (PDT) Received: by fxm15 with SMTP id 15so522706fxm.31 for ; Fri, 22 Apr 2011 10:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=fy8S+8SyqQvyN0B6Frpp9fHbyGiSb5IsUqBsaSwbsVc=; b=G5jqpQZrTzv9Xuem3wIxIuuuqkwUtZcgNckl2igNmSpgceu29XqNjhcm5SaOKhkFbf 0u9YlkBQetIv0QXdRL9MzeNW4m3tGyIwEORbNUBAbar7M07N/UjWwR4KmgCoWbq3xCia KBzFBk54rp93dK1+l8ty8AddhrEwKI7aOjsZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bUaQSyWeo9M+SGKziF43af/JvJrYP+n+LsqVSjN3OPdFMLneW0QDdn/jGQeAWrtJTR ocjyc0g6WXmU2PmM2BBpNu41wqYPYqQA8yfZkWWQffyMuqhM/BERL7XP/cjxtg8XuL+p 828CpbRbAKJxJWpOAIGP6Vlxh1V6aqjH7ilkY= MIME-Version: 1.0 Received: by 10.223.9.137 with SMTP id l9mr588009fal.25.1303494684583; Fri, 22 Apr 2011 10:51:24 -0700 (PDT) Received: by 10.223.28.12 with HTTP; Fri, 22 Apr 2011 10:51:24 -0700 (PDT) Date: Fri, 22 Apr 2011 13:51:24 -0400 Message-ID: From: Matt King To: pkix@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: matt.tebo@pgs.protiviti.com, pkix-chairs@tools.ietf.org Subject: [pkix] claimSigning EKU draft for PKIX WG Consideration 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, 22 Apr 2011 17:51:26 -0000 Dear PKIX Working Group I have posted an draft document describing a claimSigning EKU. It is titled =93draft-king-pkix-claimsigning-extn-00.txt=94 (abstract below) and it can be found at the following link for your review: http://datatracker.ietf.org/doc/draft-king-pkix-claimsigning-extn/?include_= text=3D1 I ask that the attached draft be considered as a new work item for this group. Thank you in advance for your time. Abstract This memo specifies an Extended Key Usage (EKU) X.509 certificate extension which indicates that the certificate holder is authorized to sign security tokens to assert claims, or attributes, about a principal. When an owner of a certificate that asserts the claimSigning EKU signs a claim, the owner is asserting that a statement about the principal is true. For example, a IdP secure token service (STS) would use an X.509 certificate containing the claimSigning EKU to sign SAML assertions containing an identifier and attributes about a user. --=20 Matt King Protiviti Government Services Matthew.King@pgs.protiviti.com mattking1@gmail.com 410-271-5624 (Mobile) From tgindin@us.ibm.com Fri Apr 22 15:11:51 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D9A24E06EF for ; Fri, 22 Apr 2011 15:11:51 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYMaxcgvs-rO for ; Fri, 22 Apr 2011 15:11:44 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfc.amsl.com (Postfix) with ESMTP id 800A1E0611 for ; Fri, 22 Apr 2011 15:11:44 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3MLhOvw018065 for ; Fri, 22 Apr 2011 17:43:24 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3MMBhkw082594 for ; Fri, 22 Apr 2011 18:11:43 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3MIBrd9032030 for ; Fri, 22 Apr 2011 15:11:53 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3MIBrGN032027; Fri, 22 Apr 2011 15:11:53 -0300 In-Reply-To: <4DB1803C.4000903@Dartmouth.edu> References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> <4DB1803C.4000903@Dartmouth.edu> To: Massimiliano Pala MIME-Version: 1.0 X-KeepSent: 04961FBD:D3C62BD0-8525787A:0059A6C7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Fri, 22 Apr 2011 18:11:40 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 04/22/2011 18:11:42, Serialize complete at 04/22/2011 18:11:42 Content-Type: text/plain; charset="US-ASCII" Cc: pkix@ietf.org, Jim Schaad Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 22 Apr 2011 22:11:52 -0000 Max: The value of the OTHER-NAME I'm proposing is derived by normalizing the e-mail address, concatenating it to the end of SubjectPublicKeyInfo, and hashing the structure which results from the concatenation. I would specify that the e-mail address be converted to lower-case and then encoded in DER as a UTF8String before concatenation. Concatenating the hashes doesn't work for the reason you gave, but I did not propose that and I do know better than to do so. Tom Gindin From: Massimiliano Pala To: Jim Schaad Cc: Tom Gindin/Watson/IBM@IBMUS, pkix@ietf.org Date: 04/22/2011 09:19 AM Subject: Re: [pkix] Email in Certs and Privacy Concerns Hi Jim, Tom, all, [Tom: Hash] Maybe I am missing the point, but if we use a simple concatenation, the attacker could just use dictionary attack on the second part of the value, right ? If you are proposing something like: hash(skid) + hash(addr), as an attacker I would just ignore the first XXX bytes (from hash(skid)). That is why I thought about re-hashing everything. Of course, there is one issue with not using the addr value directly: how to handle upper/low cases. In particular, although (if I remember correctly) only the domain part should be case-insensitive, in practice everybody treats all the parts of an email address as case-insensitive. Therefore, if we agree on any form of protection for the email addr in certificates, then the hash(addr) should probably be something like hash(lc(add)) or hash(uc(addr)). [Jim: searching] Actually, searching for the certificate and the contents of the certificate are, from a CA point of view, not correlated. Most of the CA software use meta-data for certificate publication, not only the contents of the cert. So, for example, you can have an LDAP server that has attributes like dn: and multiple mail: . This allows a client to search with the mail: attribute and retrieve the userCertificate;binary one. Then, by comparing the hash() with the email addr used for sending the email, the client can pick the right certificate. So, we get the benefits for searching and when the certificate is used for email purposes. But when used for other purposes (eg., SSL/TLS auth), the email address is not automatically disclosed. Does this make sense ? Cheers, Max On 04/21/2011 08:47 PM, Jim Schaad wrote: > What is the point of the CA publishing certificates if I can't ask to find a > certificate by the email address? > > The privacy question might be a different issue as once I give you a > certificate then I cannot control who you release it to and having minor > privacy at least makes you release two pieces of associated information > rather than just one. > > Jim > > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Tom Gindin >> Sent: Thursday, April 21, 2011 7:45 AM >> To: Massimiliano Pala >> Cc: pkix@ietf.org >> Subject: Re: [pkix] Email in Certs and Privacy Concerns >> >> How about just hashing the concatenation of SubjectPublicKeyInfo > and >> rfc822Address? At least it kills off reusable dictionary attacks, and the > key's >> entropy is very high. The second hash step doesn't buy you much against >> attempts to calculate the "top 20K addresses" and compare. >> Remember, the spammer is an ordinary RP who happens to be malicious, >> and anything the ordinary RP can calculate it can also calculate. >> >> Tom Gindin >> >> >> >> >> From: >> Massimiliano Pala >> To: >> pkix@ietf.org >> Date: >> 04/19/2011 05:29 PM >> Subject: >> Re: [pkix] Email in Certs and Privacy Concerns Sent by: >> pkix-bounces@ietf.org >> >> >> >> Hi, >> >> I understand the concern, but it seems to me we shall address this issue >> somehow. Any other idea that could provide a viable solution to this issue > ? >> What about a little more "complex" hashing like the >> following: >> >> Hash(Hash(pKey) + Hash(email)) >> >> >> Cheers, >> Max >> >> >> On 04/19/2011 03:33 PM, Kemp, David P. wrote: >>> I suspect that spammers, having gone to the trouble of harvesting >>> certificates, would not balk at building rainbow tables for the hashes. >>> There is not a whole lot of entropy in "localpart" @gmail.com, >>> @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so >>> salting doesn't help. It may be a bit more difficult to enumerate >>> corporate, as opposed to public, email providers, but even so, this >>> sounds like a small deterrent to a dedicated spammer. >>> >>> And if hashing gives a false sense of security, the harvesting step >>> may be made easier. >>> >>> Dave >>> >>> >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >>> Of Massimiliano Pala >>> Sent: Tuesday, April 19, 2011 12:39 PM >>> To: pkix@ietf.org >>> Subject: [pkix] Email in Certs and Privacy Concerns >>> >>> Hello all, >>> >>> I was thinking about a privacy problem we have in currently issued >>> certs: >>> email addresses. >>> >>> Some CAs make the case that they do not wish to publish the list of >>> certs to avoid spammers to easily harvest all the email addresses in >>> certs. >>> >>> A simple solution would be to allow for using an hash of the email >>> address instead of the email address itself in the subjectAltName. >>> This would prevent attackers from using that information for >>> spam/marketing purposes, but still clients can easily verify the email >>> address by simply hashing the From: email address and compare the hash >>> instead of the bare address. >>> >>> This approach could be used also to protect hostnames, although I >>> don't see privacy issues there (maybe in some "special" environments?) >>> >>> Since this addresses an important issue, shall we try to have a small >>> and quick I-D that describes the addition ? >>> >>> Does this sound reasonable and easy to deploy ? >>> >> >> >> -- >> >> Best Regards, >> >> Massimiliano Pala >> >> > --o------------------------------------------------------------------------ >> Massimiliano Pala [OpenCA Project Manager] openca@acm.org >> project.manager@openca.org >> >> Dartmouth Computer Science Dept Home Phone: +1 (603) >> 369-9332 >> PKI/Trust Laboratory Work Phone: +1 (603) >> 646-8734 >> > --o------------------------------------------------------------------------ >> People who think they know everything are a great annoyance to those of us >> who do. >> -- Isaac Asimov >> >> [attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] >> _______________________________________________ >> 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 > > -- Best Regards, Massimiliano Pala --o------------------------------------------------------------------------ Massimiliano Pala [OpenCA Project Manager] openca@acm.org project.manager@openca.org Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 --o------------------------------------------------------------------------ People who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov From ietf@augustcellars.com Fri Apr 22 15:32:43 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2C40FE07BF for ; Fri, 22 Apr 2011 15:32:43 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgKfpRJ0-Lgo for ; Fri, 22 Apr 2011 15:32:42 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfc.amsl.com (Postfix) with ESMTP id CD349E076C for ; Fri, 22 Apr 2011 15:32:41 -0700 (PDT) Received: from TITUS (unknown [50.46.72.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 8A90B6A49E; Fri, 22 Apr 2011 15:32:40 -0700 (PDT) From: "Jim Schaad" To: "'Massimiliano Pala'" References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> <4DB1803C.4000903@Dartmouth.edu> In-Reply-To: <4DB1803C.4000903@Dartmouth.edu> Date: Fri, 22 Apr 2011 15:58:46 -0700 Message-ID: <010d01cc0140$d63b0a70$82b11f50$@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: AQJEmCtalZMO7C7kG3zpxp6ioSbq8AF4QNzlAmWsC0MB77PyfQJtRh1oAiHZagqTJmr80A== Content-Language: en-us Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 22 Apr 2011 22:32:43 -0000 Max, I think that I have completely missed the argument. If as stated below: >>> Some CAs make the case that they do not wish to publish the list of >>> certs to avoid spammers to easily harvest all the email addresses in >>> certs. Why do they want to publish a list of certificates that is not usable for end-users? What is the purpose that they would publish such a list of certificates if the names were in some way shrouded? Jim > -----Original Message----- > From: Massimiliano Pala [mailto:Massimiliano.Pala@Dartmouth.edu] > Sent: Friday, April 22, 2011 6:19 AM > To: Jim Schaad > Cc: 'Tom Gindin'; pkix@ietf.org > Subject: Re: [pkix] Email in Certs and Privacy Concerns > > Hi Jim, Tom, all, > > [Tom: Hash] > > Maybe I am missing the point, but if we use a simple concatenation, the > attacker could just use dictionary attack on the second part of the value, > right ? If you are proposing something like: hash(skid) + hash(addr), as > an attacker I would just ignore the first XXX bytes (from hash(skid)). > That is why I thought about re-hashing everything. > > Of course, there is one issue with not using the addr value directly: > how to handle upper/low cases. In particular, although (if I remember > correctly) only the domain part should be case-insensitive, in practice > everybody treats all the parts of an email address as case-insensitive. > Therefore, if we agree on any form of protection for the email addr in > certificates, then the hash(addr) should probably be something like > hash(lc(add)) or hash(uc(addr)). > > > [Jim: searching] > > Actually, searching for the certificate and the contents of the certificate > are, from a CA point of view, not correlated. Most of the CA software use > meta-data for certificate publication, not only the contents of the cert. > So, for example, you can have an LDAP server that has attributes like dn: > and multiple mail: . This allows a client to search with the mail: attribute > and retrieve the userCertificate;binary one. Then, by comparing the hash() > with the email addr used for sending the email, the client can pick the > right certificate. > > So, we get the benefits for searching and when the certificate is used for > email purposes. But when used for other purposes (eg., SSL/TLS auth), the > email address is not automatically disclosed. > > Does this make sense ? > > Cheers, > Max > > > > On 04/21/2011 08:47 PM, Jim Schaad wrote: > > What is the point of the CA publishing certificates if I can't ask to find a > > certificate by the email address? > > > > The privacy question might be a different issue as once I give you a > > certificate then I cannot control who you release it to and having minor > > privacy at least makes you release two pieces of associated information > > rather than just one. > > > > Jim > > > > > >> -----Original Message----- > >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf > Of > >> Tom Gindin > >> Sent: Thursday, April 21, 2011 7:45 AM > >> To: Massimiliano Pala > >> Cc: pkix@ietf.org > >> Subject: Re: [pkix] Email in Certs and Privacy Concerns > >> > >> How about just hashing the concatenation of SubjectPublicKeyInfo > > and > >> rfc822Address? At least it kills off reusable dictionary attacks, and the > > key's > >> entropy is very high. The second hash step doesn't buy you much against > >> attempts to calculate the "top 20K addresses" and compare. > >> Remember, the spammer is an ordinary RP who happens to be malicious, > >> and anything the ordinary RP can calculate it can also calculate. > >> > >> Tom Gindin > >> > >> > >> > >> > >> From: > >> Massimiliano Pala > >> To: > >> pkix@ietf.org > >> Date: > >> 04/19/2011 05:29 PM > >> Subject: > >> Re: [pkix] Email in Certs and Privacy Concerns Sent by: > >> pkix-bounces@ietf.org > >> > >> > >> > >> Hi, > >> > >> I understand the concern, but it seems to me we shall address this issue > >> somehow. Any other idea that could provide a viable solution to this issue > > ? > >> What about a little more "complex" hashing like the > >> following: > >> > >> Hash(Hash(pKey) + Hash(email)) > >> > >> > >> Cheers, > >> Max > >> > >> > >> On 04/19/2011 03:33 PM, Kemp, David P. wrote: > >>> I suspect that spammers, having gone to the trouble of harvesting > >>> certificates, would not balk at building rainbow tables for the hashes. > >>> There is not a whole lot of entropy in "localpart" @gmail.com, > >>> @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so > >>> salting doesn't help. It may be a bit more difficult to enumerate > >>> corporate, as opposed to public, email providers, but even so, this > >>> sounds like a small deterrent to a dedicated spammer. > >>> > >>> And if hashing gives a false sense of security, the harvesting step > >>> may be made easier. > >>> > >>> Dave > >>> > >>> > >>> -----Original Message----- > >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf > >>> Of Massimiliano Pala > >>> Sent: Tuesday, April 19, 2011 12:39 PM > >>> To: pkix@ietf.org > >>> Subject: [pkix] Email in Certs and Privacy Concerns > >>> > >>> Hello all, > >>> > >>> I was thinking about a privacy problem we have in currently issued > >>> certs: > >>> email addresses. > >>> > >>> Some CAs make the case that they do not wish to publish the list of > >>> certs to avoid spammers to easily harvest all the email addresses in > >>> certs. > >>> > >>> A simple solution would be to allow for using an hash of the email > >>> address instead of the email address itself in the subjectAltName. > >>> This would prevent attackers from using that information for > >>> spam/marketing purposes, but still clients can easily verify the email > >>> address by simply hashing the From: email address and compare the > hash > >>> instead of the bare address. > >>> > >>> This approach could be used also to protect hostnames, although I > >>> don't see privacy issues there (maybe in some "special" environments?) > >>> > >>> Since this addresses an important issue, shall we try to have a small > >>> and quick I-D that describes the addition ? > >>> > >>> Does this sound reasonable and easy to deploy ? > >>> > >> > >> > >> -- > >> > >> Best Regards, > >> > >> Massimiliano Pala > >> > >> > > --o------------------------------------------------------------------------ > >> Massimiliano Pala [OpenCA Project Manager] openca@acm.org > >> project.manager@openca.org > >> > >> Dartmouth Computer Science Dept Home Phone: +1 (603) > >> 369-9332 > >> PKI/Trust Laboratory Work Phone: +1 (603) > >> 646-8734 > >> > > --o------------------------------------------------------------------------ > >> People who think they know everything are a great annoyance to those > of us > >> who do. > >> -- Isaac Asimov > >> > >> [attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] > >> _______________________________________________ > >> 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 > > > > > > > -- > > Best Regards, > > Massimiliano Pala > > --o------------------------------------------------------------------------ > Massimiliano Pala [OpenCA Project Manager] openca@acm.org > project.manager@openca.org > > Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332 > PKI/Trust Laboratory Work Phone: +1 (603) 646-8734 > --o------------------------------------------------------------------------ > People who think they know everything are a great annoyance to those of us > who do. > -- Isaac Asimov From stefan@aaa-sec.com Fri Apr 22 15:57:23 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2F77E067B for ; Fri, 22 Apr 2011 15:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.828 X-Spam-Level: X-Spam-Status: No, score=-102.828 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hw8hs2GuIDcA for ; Fri, 22 Apr 2011 15:57:23 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfc.amsl.com (Postfix) with ESMTP id C9EB8E065F for ; Fri, 22 Apr 2011 15:57:22 -0700 (PDT) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D87E73061DD for ; Sat, 23 Apr 2011 00:57:29 +0200 (CEST) Received: (qmail 17938 invoked from network); 22 Apr 2011 22:57:20 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.10]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Apr 2011 22:57:20 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sat, 23 Apr 2011 00:57:16 +0200 From: Stefan Santesson To: Tom Gindin , Massimiliano Pala Message-ID: Thread-Topic: [pkix] Email in Certs and Privacy Concerns In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 22 Apr 2011 22:57:24 -0000 >At least it kills off reusable dictionary attacks, and >the key's entropy is very high. No, it is 0 since it is known (even advertised in the cert. Only unknown aspects of data contribute to its entropy (Straight from information theory) And that is the key. No matter how much you mix and re-hash stuff, if the e-mail address is the only unknown data that goes into that calculation, it is very easy to repeat that process with a guess of the e-mail address to se if you are right. And guessing e-mail addresses is often very easy. Max proposal to mix upper and lower case characters randomly does make it harder, but also makes it harder to use the solution as the valid verifier need to know hoe to mix cases in the same way in order to validate it. Smelling like RFC 1925 truth 6. On Jim's comment on the other hand, I don't think hashing e-mail addresses makes them unusable if there is a straightforward way to generate the expected hash value of it and look up the cert indexed from a hash table, but if you can do that, then you are all target of dictionary attacks. It feels like if you want to do this usable, you need to do it so bad that it is not worth the effort. /Stefan On 11-04-21 4:45 PM, "Tom Gindin" wrote: > How about just hashing the concatenation of SubjectPublicKeyInfo >and rfc822Address? At least it kills off reusable dictionary attacks, >and >the key's entropy is very high. The second hash step doesn't buy you >much >against attempts to calculate the "top 20K addresses" and compare. >Remember, the spammer is an ordinary RP who happens to be malicious, and >anything the ordinary RP can calculate it can also calculate. > > Tom Gindin > > > > >From: >Massimiliano Pala >To: >pkix@ietf.org >Date: >04/19/2011 05:29 PM >Subject: >Re: [pkix] Email in Certs and Privacy Concerns >Sent by: >pkix-bounces@ietf.org > > > >Hi, > >I understand the concern, but it seems to me we shall address this >issue somehow. Any other idea that could provide a viable solution >to this issue ? What about a little more "complex" hashing like the >following: > > Hash(Hash(pKey) + Hash(email)) > > >Cheers, >Max > > >On 04/19/2011 03:33 PM, Kemp, David P. wrote: >> I suspect that spammers, having gone to the trouble of harvesting >> certificates, would not balk at building rainbow tables for the hashes. >> There is not a whole lot of entropy in "localpart" @gmail.com, >> @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so >> salting doesn't help. It may be a bit more difficult to enumerate >> corporate, as opposed to public, email providers, but even so, this >> sounds like a small deterrent to a dedicated spammer. >> >> And if hashing gives a false sense of security, the harvesting step may >> be made easier. >> >> Dave >> >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Massimiliano Pala >> Sent: Tuesday, April 19, 2011 12:39 PM >> To: pkix@ietf.org >> Subject: [pkix] Email in Certs and Privacy Concerns >> >> Hello all, >> >> I was thinking about a privacy problem we have in currently issued >> certs: >> email addresses. >> >> Some CAs make the case that they do not wish to publish the list of >> certs to avoid spammers to easily harvest all the email addresses in >> certs. >> >> A simple solution would be to allow for using an hash of the email >> address instead of the email address itself in the subjectAltName. This >> would prevent attackers from using that information for spam/marketing >> purposes, but still clients can easily verify the email address by >> simply hashing the From: email address and compare the hash instead of >> the bare address. >> >> This approach could be used also to protect hostnames, although I don't >> see privacy issues there (maybe in some "special" environments?) >> >> Since this addresses an important issue, shall we try to have a small >> and quick I-D that describes the addition ? >> >> Does this sound reasonable and easy to deploy ? >> > > >-- > >Best Regards, > > Massimiliano Pala > >--o----------------------------------------------------------------------- >- >Massimiliano Pala [OpenCA Project Manager] openca@acm.org > project.manager@openca.org > >Dartmouth Computer Science Dept Home Phone: +1 (603) >369-9332 >PKI/Trust Laboratory Work Phone: +1 (603) >646-8734 >--o----------------------------------------------------------------------- >- >People who think they know everything are a great annoyance to those of us >who do. > -- Isaac Asimov > >[attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] >_______________________________________________ >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 stefan@aaa-sec.com Fri Apr 22 16:31:36 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45840E0669 for ; Fri, 22 Apr 2011 16:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.869 X-Spam-Level: X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HELO_EQ_SE=0.35, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwUdvLL-lyJt for ; Fri, 22 Apr 2011 16:31:35 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfc.amsl.com (Postfix) with ESMTP id 3C6C0E065F for ; Fri, 22 Apr 2011 16:31:35 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 329FF28B922 for ; Sat, 23 Apr 2011 01:31:43 +0200 (CEST) Received: (qmail 62713 invoked from network); 22 Apr 2011 23:31:33 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.10]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Apr 2011 23:31:33 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sat, 23 Apr 2011 01:31:26 +0200 From: Stefan Santesson To: Matt King , Message-ID: Thread-Topic: [pkix] claimSigning EKU draft for PKIX WG Consideration In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: matt.tebo@pgs.protiviti.com, pkix-chairs@tools.ietf.org Subject: Re: [pkix] claimSigning EKU draft for PKIX WG Consideration 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, 22 Apr 2011 23:31:36 -0000 Matt, Thanks for binging this proposal to PKIX. First thing that strikes me is that we seem to have two competing proposals on the table. This one and draft-patterson-pkix-attribute-signing-eku. Is this a coincidence or are the authors aware of each other and has intentionally put forth different proposals? This draft seems to have more description of the use case and also involve the use for signing metadata records which is interesting. The OID declaration in section 3 seems to have corrupted line wrapping. Looks like you used NroffEdit and forgot to include the .nf directive :) Try replacing with the following: .in 8 .nf id-kp OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-claimSigning OBJECT IDENTIFIER ::=3D { id-kp TBD } .fi .in 3 The document is missing an ASN.1 section, but I guess you can add that later. Section 4 is problematic from a standardization scope perspective. A standard cannot mandate matters that is outside of it's scope (or jurisdiction). If this standard would define a claims signing protocol, then it would be within the scope of such standard to say what EKU values that such protocol mandates. However, this draft does not defines such a protocol. It only defines an EKU value. It is not reasonable for this standard to dictate behavior of implementations that does not implement this standard. Thus, you can't dictate that implementations MUT NOT accept a cert for any purpose if it does not contain the EKU you define. Likewise you can't force implementations to accept a cert if it DOES contain your EKU. All you can say is what statement this EKU provides. Unless you want to go further, you need to place such requirements in the protocol using the EKU. Finally, the use of this EKU for signing metadata provides an interesting use case as it could be done with a cert provided from a general purpose PKI. However isn't that a bit of a stretched semantics to denote that as claims signing? Given that there are no claims in the metadata. /Stefan On 11-04-22 7:51 PM, "Matt King" wrote: >Dear PKIX Working Group > >I have posted an draft document describing a claimSigning EKU. It is >titled =B3draft-king-pkix-claimsigning-extn-00.txt=B2 (abstract below) and >it can be found at the following link for your review: > >http://datatracker.ietf.org/doc/draft-king-pkix-claimsigning-extn/?include >_text=3D1 > >I ask that the attached draft be considered as a new work item for >this group. Thank you in advance for your time. > >Abstract > > This memo specifies an Extended Key Usage (EKU) X.509 certificate > extension which indicates that the certificate holder is authorized > to sign security tokens to assert claims, or attributes, about a > principal. > > When an owner of a certificate that asserts the claimSigning EKU > signs a claim, the owner is asserting that a statement about the > principal is true. For example, a IdP secure token service (STS) > would use an X.509 certificate containing the claimSigning EKU to > sign SAML assertions containing an identifier and attributes about a > user. > > >--=20 >Matt King >Protiviti >Government Services >Matthew.King@pgs.protiviti.com >mattking1@gmail.com >410-271-5624 (Mobile) >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From kyanha@kyanha.net Fri Apr 22 23:15:09 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 37BC1E06F8 for ; Fri, 22 Apr 2011 23:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro+dHwyO752B for ; Fri, 22 Apr 2011 23:15:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3AC66E062B for ; Fri, 22 Apr 2011 23:15:08 -0700 (PDT) Received: by vws12 with SMTP id 12so1009590vws.31 for ; Fri, 22 Apr 2011 23:15:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.18.44 with SMTP id t12mr457518vdd.55.1303539306309; Fri, 22 Apr 2011 23:15:06 -0700 (PDT) Received: by 10.52.161.196 with HTTP; Fri, 22 Apr 2011 23:15:06 -0700 (PDT) In-Reply-To: References: <3C79B3DA-9CB2-49CB-AC15-97AD6C93BAB8@mitre.org> Date: Fri, 22 Apr 2011 23:15:06 -0700 Message-ID: From: Kyle Hamilton To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 23 Apr 2011 06:15:09 -0000 A self-signed certificate structure has the semantic meaning of "I am that which can be identified with this public key, and the self-signature proves both that the private key to this public key exists and that its holder approved this statement." What everyone forgets is that X.509 is a means of carrying a chain of semantic authority through signatures provably chained from how that authority is identified (the authority's public key). Why must the signature structure in the outermost wrapper of the TBSCertificate be the only place where those signatures can be asserted? -Kyle H On Fri, Apr 22, 2011 at 6:20 AM, Kemp, David P. wro= te: > So how is that different from my MSEE from Princeton University*? =A0I'm > sure they would refuse any and all liability, yet most people would > consider that piece of sheepskin more authoritative than an MS degree I > awarded to myself. > > Dave > > * I didn't go to Princeton, but I do have a MSEE from an institution of > similar reputation. =A0See me over a beer if you care which one. > > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Peter Gutmann > Sent: Friday, April 22, 2011 8:22 AM > To: pgut001@cs.auckland.ac.nz; tmiller@mitre.org > Cc: pkix@ietf.org > Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] > [keyassure] Use cases document.) > > "Miller, Timothy J." writes: > >>Yeah, but unlike a self-asserter commercial CAs can be held liable > (within >>unclear and probably variable limits). > > Hmm, you haven't been following the discussion on the Mozilla policy > list have > you? =A0Effectively once a commercial CA has issued enough certs to becom= e > Too > Big To Fail, it's absolved of any liability (that's a very, very > cut-down > summary of an interminable discussion, see the thread "Response from > Comodo" > for the full thing). > > Peter. > > _______________________________________________ > 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 tgindin@us.ibm.com Sat Apr 23 15:13:21 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E1B56E06D9 for ; Sat, 23 Apr 2011 15:13:21 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDCdMRN2N38v for ; Sat, 23 Apr 2011 15:13:21 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfc.amsl.com (Postfix) with ESMTP id D7181E06C9 for ; Sat, 23 Apr 2011 15:13:20 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3NLn2Qp015752 for ; Sat, 23 Apr 2011 17:49:02 -0400 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3NMDENL1044644 for ; Sat, 23 Apr 2011 18:13:15 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3NMDDMV006761 for ; Sat, 23 Apr 2011 18:13:14 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3NMDDb9006758; Sat, 23 Apr 2011 18:13:13 -0400 In-Reply-To: References: To: Stefan Santesson MIME-Version: 1.0 X-KeepSent: AA1E42AD:96A7A885-8525787B:00799434; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Sat, 23 Apr 2011 18:13:11 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 04/23/2011 18:13:12, Serialize complete at 04/23/2011 18:13:12 Content-Type: text/plain; charset="US-ASCII" Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 23 Apr 2011 22:13:22 -0000 Stefan: For the purposes of building an attacker's reusable dictionary, the key's entropy is very high. For the purpose of building a one-time dictionary after receiving the certificate, it is indeed zero as you stated. Tom Gindin From: Stefan Santesson To: Tom Gindin/Watson/IBM@IBMUS, Massimiliano Pala Cc: Date: 04/22/2011 06:57 PM Subject: Re: [pkix] Email in Certs and Privacy Concerns >At least it kills off reusable dictionary attacks, and >the key's entropy is very high. No, it is 0 since it is known (even advertised in the cert. Only unknown aspects of data contribute to its entropy (Straight from information theory) And that is the key. No matter how much you mix and re-hash stuff, if the e-mail address is the only unknown data that goes into that calculation, it is very easy to repeat that process with a guess of the e-mail address to se if you are right. And guessing e-mail addresses is often very easy. Max proposal to mix upper and lower case characters randomly does make it harder, but also makes it harder to use the solution as the valid verifier need to know hoe to mix cases in the same way in order to validate it. Smelling like RFC 1925 truth 6. On Jim's comment on the other hand, I don't think hashing e-mail addresses makes them unusable if there is a straightforward way to generate the expected hash value of it and look up the cert indexed from a hash table, but if you can do that, then you are all target of dictionary attacks. It feels like if you want to do this usable, you need to do it so bad that it is not worth the effort. /Stefan On 11-04-21 4:45 PM, "Tom Gindin" wrote: > How about just hashing the concatenation of SubjectPublicKeyInfo >and rfc822Address? At least it kills off reusable dictionary attacks, >and >the key's entropy is very high. The second hash step doesn't buy you >much >against attempts to calculate the "top 20K addresses" and compare. >Remember, the spammer is an ordinary RP who happens to be malicious, and >anything the ordinary RP can calculate it can also calculate. > > Tom Gindin > > > > >From: >Massimiliano Pala >To: >pkix@ietf.org >Date: >04/19/2011 05:29 PM >Subject: >Re: [pkix] Email in Certs and Privacy Concerns >Sent by: >pkix-bounces@ietf.org > > > >Hi, > >I understand the concern, but it seems to me we shall address this >issue somehow. Any other idea that could provide a viable solution >to this issue ? What about a little more "complex" hashing like the >following: > > Hash(Hash(pKey) + Hash(email)) > > >Cheers, >Max > > >On 04/19/2011 03:33 PM, Kemp, David P. wrote: >> I suspect that spammers, having gone to the trouble of harvesting >> certificates, would not balk at building rainbow tables for the hashes. >> There is not a whole lot of entropy in "localpart" @gmail.com, >> @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so >> salting doesn't help. It may be a bit more difficult to enumerate >> corporate, as opposed to public, email providers, but even so, this >> sounds like a small deterrent to a dedicated spammer. >> >> And if hashing gives a false sense of security, the harvesting step may >> be made easier. >> >> Dave >> >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Massimiliano Pala >> Sent: Tuesday, April 19, 2011 12:39 PM >> To: pkix@ietf.org >> Subject: [pkix] Email in Certs and Privacy Concerns >> >> Hello all, >> >> I was thinking about a privacy problem we have in currently issued >> certs: >> email addresses. >> >> Some CAs make the case that they do not wish to publish the list of >> certs to avoid spammers to easily harvest all the email addresses in >> certs. >> >> A simple solution would be to allow for using an hash of the email >> address instead of the email address itself in the subjectAltName. This >> would prevent attackers from using that information for spam/marketing >> purposes, but still clients can easily verify the email address by >> simply hashing the From: email address and compare the hash instead of >> the bare address. >> >> This approach could be used also to protect hostnames, although I don't >> see privacy issues there (maybe in some "special" environments?) >> >> Since this addresses an important issue, shall we try to have a small >> and quick I-D that describes the addition ? >> >> Does this sound reasonable and easy to deploy ? >> > > >-- > >Best Regards, > > Massimiliano Pala > >--o----------------------------------------------------------------------- >- >Massimiliano Pala [OpenCA Project Manager] openca@acm.org > project.manager@openca.org > >Dartmouth Computer Science Dept Home Phone: +1 (603) >369-9332 >PKI/Trust Laboratory Work Phone: +1 (603) >646-8734 >--o----------------------------------------------------------------------- >- >People who think they know everything are a great annoyance to those of us >who do. > -- Isaac Asimov > >[attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] >_______________________________________________ >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 tmiller@mitre.org Sun Apr 24 11:23:58 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AB867E06BD for ; Sun, 24 Apr 2011 11:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnRzHw16RMGH for ; Sun, 24 Apr 2011 11:23:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfc.amsl.com (Postfix) with ESMTP id 60BF6E06AB for ; Sun, 24 Apr 2011 11:23:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7473721B1978; Sun, 24 Apr 2011 14:23:56 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6BBB421B0E33; Sun, 24 Apr 2011 14:23:56 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Sun, 24 Apr 2011 14:23:56 -0400 From: "Miller, Timothy J." To: Jim Schaad Date: Sun, 24 Apr 2011 14:24:09 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwCrMV5Lewh/sPJRdapCRtEBVEPAw== Message-ID: <2A645B64-1ED6-4A4E-A542-98D1531FA337@mitre.org> References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> <4DB1803C.4000903@Dartmouth.edu> <010d01cc0140$d63b0a70$82b11f50$@augustcellars.com> In-Reply-To: <010d01cc0140$d63b0a70$82b11f50$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2--1055265068"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 24 Apr 2011 18:23:58 -0000 --Apple-Mail-2--1055265068 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Given than the use of an RFC822 name is *optional* under S/MIME v3 and = later, why not just drop it from the cert and make the problem go away? -- T On Apr 22, 2011, at 5:58 PM, Jim Schaad wrote: > Max, >=20 > I think that I have completely missed the argument. If as stated = below: >=20 >>>> Some CAs make the case that they do not wish to publish the list of >>>> certs to avoid spammers to easily harvest all the email addresses = in >>>> certs. >=20 > Why do they want to publish a list of certificates that is not usable = for > end-users? What is the purpose that they would publish such a list of > certificates if the names were in some way shrouded? >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Massimiliano Pala [mailto:Massimiliano.Pala@Dartmouth.edu] >> Sent: Friday, April 22, 2011 6:19 AM >> To: Jim Schaad >> Cc: 'Tom Gindin'; pkix@ietf.org >> Subject: Re: [pkix] Email in Certs and Privacy Concerns >>=20 >> Hi Jim, Tom, all, >>=20 >> [Tom: Hash] >>=20 >> Maybe I am missing the point, but if we use a simple concatenation, = the >> attacker could just use dictionary attack on the second part of the = value, >> right ? If you are proposing something like: hash(skid) + hash(addr), = as >> an attacker I would just ignore the first XXX bytes (from = hash(skid)). >> That is why I thought about re-hashing everything. >>=20 >> Of course, there is one issue with not using the addr value directly: >> how to handle upper/low cases. In particular, although (if I remember >> correctly) only the domain part should be case-insensitive, in = practice >> everybody treats all the parts of an email address as = case-insensitive. >> Therefore, if we agree on any form of protection for the email addr = in >> certificates, then the hash(addr) should probably be something like >> hash(lc(add)) or hash(uc(addr)). >>=20 >>=20 >> [Jim: searching] >>=20 >> Actually, searching for the certificate and the contents of the > certificate >> are, from a CA point of view, not correlated. Most of the CA software = use >> meta-data for certificate publication, not only the contents of the = cert. >> So, for example, you can have an LDAP server that has attributes like = dn: >> and multiple mail: . This allows a client to search with the mail: > attribute >> and retrieve the userCertificate;binary one. Then, by comparing the = hash() >> with the email addr used for sending the email, the client can pick = the >> right certificate. >>=20 >> So, we get the benefits for searching and when the certificate is = used for >> email purposes. But when used for other purposes (eg., SSL/TLS auth), = the >> email address is not automatically disclosed. >>=20 >> Does this make sense ? >>=20 >> Cheers, >> Max >>=20 >>=20 >>=20 >> On 04/21/2011 08:47 PM, Jim Schaad wrote: >>> What is the point of the CA publishing certificates if I can't ask = to > find a >>> certificate by the email address? >>>=20 >>> The privacy question might be a different issue as once I give you a >>> certificate then I cannot control who you release it to and having = minor >>> privacy at least makes you release two pieces of associated = information >>> rather than just one. >>>=20 >>> Jim >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On = Behalf >> Of >>>> Tom Gindin >>>> Sent: Thursday, April 21, 2011 7:45 AM >>>> To: Massimiliano Pala >>>> Cc: pkix@ietf.org >>>> Subject: Re: [pkix] Email in Certs and Privacy Concerns >>>>=20 >>>> How about just hashing the concatenation of > SubjectPublicKeyInfo >>> and >>>> rfc822Address? At least it kills off reusable dictionary attacks, = and > the >>> key's >>>> entropy is very high. The second hash step doesn't buy you much > against >>>> attempts to calculate the "top 20K addresses" and compare. >>>> Remember, the spammer is an ordinary RP who happens to be = malicious, >>>> and anything the ordinary RP can calculate it can also calculate. >>>>=20 >>>> Tom Gindin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> From: >>>> Massimiliano Pala >>>> To: >>>> pkix@ietf.org >>>> Date: >>>> 04/19/2011 05:29 PM >>>> Subject: >>>> Re: [pkix] Email in Certs and Privacy Concerns Sent by: >>>> pkix-bounces@ietf.org >>>>=20 >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> I understand the concern, but it seems to me we shall address this > issue >>>> somehow. Any other idea that could provide a viable solution to = this > issue >>> ? >>>> What about a little more "complex" hashing like the >>>> following: >>>>=20 >>>> Hash(Hash(pKey) + Hash(email)) >>>>=20 >>>>=20 >>>> Cheers, >>>> Max >>>>=20 >>>>=20 >>>> On 04/19/2011 03:33 PM, Kemp, David P. wrote: >>>>> I suspect that spammers, having gone to the trouble of harvesting >>>>> certificates, would not balk at building rainbow tables for the > hashes. >>>>> There is not a whole lot of entropy in "localpart" @gmail.com, >>>>> @yahoo.com, @hotmail.com, etc. Email addresses are not reused, so >>>>> salting doesn't help. It may be a bit more difficult to enumerate >>>>> corporate, as opposed to public, email providers, but even so, = this >>>>> sounds like a small deterrent to a dedicated spammer. >>>>>=20 >>>>> And if hashing gives a false sense of security, the harvesting = step >>>>> may be made easier. >>>>>=20 >>>>> Dave >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On = Behalf >>>>> Of Massimiliano Pala >>>>> Sent: Tuesday, April 19, 2011 12:39 PM >>>>> To: pkix@ietf.org >>>>> Subject: [pkix] Email in Certs and Privacy Concerns >>>>>=20 >>>>> Hello all, >>>>>=20 >>>>> I was thinking about a privacy problem we have in currently issued >>>>> certs: >>>>> email addresses. >>>>>=20 >>>>> Some CAs make the case that they do not wish to publish the list = of >>>>> certs to avoid spammers to easily harvest all the email addresses = in >>>>> certs. >>>>>=20 >>>>> A simple solution would be to allow for using an hash of the email >>>>> address instead of the email address itself in the subjectAltName. >>>>> This would prevent attackers from using that information for >>>>> spam/marketing purposes, but still clients can easily verify the = email >>>>> address by simply hashing the From: email address and compare the >> hash >>>>> instead of the bare address. >>>>>=20 >>>>> This approach could be used also to protect hostnames, although I >>>>> don't see privacy issues there (maybe in some "special" = environments?) >>>>>=20 >>>>> Since this addresses an important issue, shall we try to have a = small >>>>> and quick I-D that describes the addition ? >>>>>=20 >>>>> Does this sound reasonable and easy to deploy ? >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best Regards, >>>>=20 >>>> Massimiliano Pala >>>>=20 >>>>=20 >>>=20 > = --o-----------------------------------------------------------------------= - >>>> Massimiliano Pala [OpenCA Project Manager] openca@acm.org >>>> project.manager@openca.org >>>>=20 >>>> Dartmouth Computer Science Dept Home Phone: +1 (603) >>>> 369-9332 >>>> PKI/Trust Laboratory Work Phone: +1 (603) >>>> 646-8734 >>>>=20 >>>=20 > = --o-----------------------------------------------------------------------= - >>>> People who think they know everything are a great annoyance to = those >> of us >>>> who do. >>>> -- Isaac Asimov >>>>=20 >>>> [attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>=20 >>>=20 >>=20 >>=20 >> -- >>=20 >> Best Regards, >>=20 >> Massimiliano Pala >>=20 >>=20 > = --o-----------------------------------------------------------------------= - >> Massimiliano Pala [OpenCA Project Manager] > openca@acm.org >>=20 > project.manager@openca.org >>=20 >> Dartmouth Computer Science Dept Home Phone: +1 (603) > 369-9332 >> PKI/Trust Laboratory Work Phone: +1 (603) > 646-8734 >>=20 > = --o-----------------------------------------------------------------------= - >> People who think they know everything are a great annoyance to those = of us >> who do. >> -- Isaac = Asimov >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-2--1055265068 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjQxODI0MDlaMCMGCSqGSIb3DQEJBDEWBBQSVsvyMoskh64JZorO KBymg75fNjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgMpwdneEQbhZS/PsMksPxoh2oODbCeuroWrV uA2jaPEhA33eok1JKp/ViHAMerybjDCy77YbjazHSnGvrYiKFgszJk0jpQjjFr0jTdJvG+hSDDLu dY1rVWQIWvqqpZOJ11mg12iTGzUwrXgyehdpJELsdVhfVOZvAYsBFOKnRd1GAAAAAAAA --Apple-Mail-2--1055265068-- From egerck@nma.com Sun Apr 24 12:23:08 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38D38E06A3 for ; Sun, 24 Apr 2011 12:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqEos32cA95A for ; Sun, 24 Apr 2011 12:23:07 -0700 (PDT) Received: from nm30-vm0.access.bullet.mail.mud.yahoo.com (nm30-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.86]) by ietfc.amsl.com (Postfix) with SMTP id 8BD06E0680 for ; Sun, 24 Apr 2011 12:23:07 -0700 (PDT) Received: from [66.94.237.126] by nm30.access.bullet.mail.mud.yahoo.com with NNFMP; 24 Apr 2011 19:23:07 -0000 Received: from [66.94.237.109] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 24 Apr 2011 19:23:07 -0000 Received: from [127.0.0.1] by omp1014.access.mail.mud.yahoo.com with NNFMP; 24 Apr 2011 19:23:07 -0000 X-Yahoo-Newman-Id: 134887.74117.bm@omp1014.access.mail.mud.yahoo.com Received: (qmail 44513 invoked from network); 24 Apr 2011 19:23:06 -0000 Received: from [172.16.1.88] (egerck@99.145.106.177 with plain) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 24 Apr 2011 12:23:06 -0700 PDT X-Yahoo-SMTP: MbPjQnGswBC7yA6NwEFbGJ4iXszffqyyVjqB X-YMail-OSG: lonW.54VM1k4BPBIftj6FiFxhc4UEpXRSRcnDgiCfzxp3iB Vem35vwDOZG0zwZA.7fdoGtRDv0mS7mYV_tl1sgo5XIYw0wBLyfLaOGzK6DI 2Kt_H4FkT8vkjCy8oKYK0McjTgLA.9y.3h6L6LcftQO5LoQP4gP82wly4Q4A HN.q1QRe0ihMyZ9IHOljodYPRXH0ykOKGN1dfSBsRfYq0iR5kme_mpoVa7ph ajxy2Qte_MxnyU3ZckFRJfGoDzBlo0tx8Hcc.Cmmb9_imlYG87znxi3LLajq Y1Kjy6koIaFWILpK5.mRl_IVJBFx7._XzIyEEd1_DgplpeTpy X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DB47899.3090701@nma.com> Date: Sun, 24 Apr 2011 12:23:05 -0700 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: pkix@ietf.org References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> <4DB1803C.4000903@Dartmouth.edu> <010d01cc0140$d63b0a70$82b11f50$@augustcellars.com> <2A645B64-1ED6-4A4E-A542-98D1531FA337@mitre.org> In-Reply-To: <2A645B64-1ED6-4A4E-A542-98D1531FA337@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 24 Apr 2011 19:23:08 -0000 List, this shows, once again (see archives), that the security model for protecting email with conventional PKC is backwards, technically and business wise. The sender, who is the party at risk, finds herself in the awkward position of having to rely on a lock provided by the recipient (his public-key) in order to protect her secrets (the message). Whereas the recipient risks losing privacy just by getting a key cert. If postal mail would provide message security a la PKC/PKI email, the sender would have to convince the recipient to pay and send in advance an envelope for the sender to use. The sender, however, would never know whether the envelope indeed prevented others from prying into its contents (translated to PKI: weak keys, escrowed keys, rogue CAs, etc.) Businesswise, the recipient is also not the business driver who needs to provide, pay for and protect the lock. The sender is the party who has the motivation to spend money to provide and protect the lock. Of course, PKC is a well-known and recognized standard (in various forms, including PKI and PGP) for encryption of email. However, their security and usability problems noted above just cannot be solved by improvements in usability, better pricing or user education regarding how it works. It simply does not work as it should work. That's also why conventional secure email has been difficult to use. It has the wrong logic for the problem. This is a basic limitation. Cheers, Ed Gerck From anders.rundgren@telia.com Sun Apr 24 23:44:37 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8132EE06A3 for ; Sun, 24 Apr 2011 23:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAucEhoVwLo1 for ; Sun, 24 Apr 2011 23:44:37 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfc.amsl.com (Postfix) with ESMTP id EDD3BE0694 for ; Sun, 24 Apr 2011 23:44:36 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA01723252 for pkix@ietf.org; Mon, 25 Apr 2011 08:44:35 +0200 Message-ID: <4DB5185E.6050505@telia.com> Date: Mon, 25 Apr 2011 08:44:46 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] OCSP stapling extension? 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, 25 Apr 2011 06:44:37 -0000 Dear List, This is not a suggestion but an open question. OCSP stapling is a nice idea but it is not universally applicable since PKIs run by banks typically do not allow arbitrary access to OCSP responders. This complicates the design of client SW. Would a certificate extension that in some way signals the "openness" of the OCSP responder be of any utility or is the "right" way to try to get a response and possibly fail? Unless the SW also "learns" the behavior of different PKIs, the latter IMO could lead to a somewhat erratic operation. I'm considering adding OCSP stapling to WebAUTH and WASP that are "companion" specifications to SKS/KeyGen2. Anders From tmiller@mitre.org Mon Apr 25 05:02:19 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F09CDE0705 for ; Mon, 25 Apr 2011 05:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 673zAm4BrqeC for ; Mon, 25 Apr 2011 05:02:19 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfc.amsl.com (Postfix) with ESMTP id 4DA04E06A4 for ; Mon, 25 Apr 2011 05:02:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3EBA921B1AA1; Mon, 25 Apr 2011 08:02:18 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3787A21B092D; Mon, 25 Apr 2011 08:02:18 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 25 Apr 2011 08:02:17 -0400 From: "Miller, Timothy J." To: "Ed Gerck, Ph.D." Date: Mon, 25 Apr 2011 08:02:19 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwDQJ7cWQCPByOZQjmAyiQG8oZlPA== Message-ID: <652553A4-E259-48BA-8B45-DDA087E5B21A@mitre.org> References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> <4DB1803C.4000903@Dartmouth.edu> <010d01cc0140$d63b0a70$82b11f50$@augustcellars.com> <2A645B64-1ED6-4A4E-A542-98D1531FA337@mitre.org> <4DB47899.3090701@nma.com> In-Reply-To: <4DB47899.3090701@nma.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1--991774724"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 25 Apr 2011 12:02:20 -0000 --Apple-Mail-1--991774724 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii OK, granted. So what's the alternative? (And don't say identity based = encryption or I promise I'll have you flogged :). -- T On Apr 24, 2011, at 2:23 PM, Ed Gerck, Ph.D. wrote: > List, >=20 > this shows, once again (see archives), that the security model for = protecting > email with conventional PKC is backwards, technically and business = wise. The > sender, who is the party at risk, finds herself in the awkward = position of having > to rely on a lock provided by the recipient (his public-key) in order = to protect > her secrets (the message). Whereas the recipient risks losing privacy = just by > getting a key cert. >=20 > If postal mail would provide message security a la PKC/PKI email, the = sender > would have to convince the recipient to pay and send in advance an > envelope for the sender to use. The sender, however, would never know > whether the envelope indeed prevented others from prying into its = contents > (translated to PKI: weak keys, escrowed keys, rogue CAs, etc.) >=20 > Businesswise, the recipient is also not the business driver who needs = to provide, > pay for and protect the lock. The sender is the party who has the = motivation to > spend money to provide and protect the lock. >=20 > Of course, PKC is a well-known and recognized standard (in various = forms, including > PKI and PGP) for encryption of email. However, their security and = usability=20 > problems > noted above just cannot be solved by improvements in usability, better = pricing=20 > or user > education regarding how it works. It simply does not work as it should = work.=20 > That's also > why conventional secure email has been difficult to use. It has the = wrong logic=20 > for the > problem. This is a basic limitation. >=20 > Cheers, > Ed Gerck >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-1--991774724 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjUxMjAyMjBaMCMGCSqGSIb3DQEJBDEWBBQ8c1L1/fwYSx1UWry0 dCxCrFy1ZTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgHqv6iPPFVW5wjt1m9lka8C1iHefPg+Q4v8E YLKCENtVE0ueeO60l/teaTsLyA3hfMY8U/zMazBSnSvhIYzkfQ5j+Q1RV6slC0ps7abKSwiI0oaW c+nw3u0glHYYtSq24W7eszJsH4+ZJBkm+yCE7WYAV3bT4vyQcc0aQCnpleA9AAAAAAAA --Apple-Mail-1--991774724-- From tmiller@mitre.org Mon Apr 25 05:08:43 2011 Return-Path: X-Original-To: pkix@ietfc.amsl.com Delivered-To: pkix@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F17DAE06A1 for ; Mon, 25 Apr 2011 05:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2ObmPt8VWLm for ; Mon, 25 Apr 2011 05:08:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfc.amsl.com (Postfix) with ESMTP id 6B9E0E064E for ; Mon, 25 Apr 2011 05:08:42 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 04CCF21B0FB9; Mon, 25 Apr 2011 08:08:42 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 63DED21B1C47; Mon, 25 Apr 2011 08:08:39 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 25 Apr 2011 08:08:39 -0400 From: "Miller, Timothy J." To: Anders Rundgren Date: Mon, 25 Apr 2011 08:08:39 -0400 Thread-Topic: [pkix] OCSP stapling extension? Thread-Index: AcwDQYLWS5d96zw2TZqKmN3bkuRYHA== Message-ID: References: <4DB5185E.6050505@telia.com> In-Reply-To: <4DB5185E.6050505@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2--991394501"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] OCSP stapling extension? 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, 25 Apr 2011 12:08:43 -0000 --Apple-Mail-2--991394501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 25, 2011, at 1:44 AM, Anders Rundgren wrote: >=20 > OCSP stapling is a nice idea but it is not universally applicable > since PKIs run by banks typically do not allow arbitrary access > to OCSP responders. This complicates the design of client SW. Functionally I think it's simpler (in a protocol with stapling defined) = to look for the stapled response first, before chasing id-ad-ocsp URIs. = Once I'm at the point of chasing AIA, either I can get a DNS response = for the host named or not. =20 While yes it's simpler to "always chase AIA" but really, is it that big = of a deal? > Would a certificate extension that in some way signals the "openness" So you'd take the complexity *out* of the specific client supporting = your protocol and put it in *every PKI library* instead? How does this = make anyone's life easier? -- T --Apple-Mail-2--991394501 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjUxMjA4NDBaMCMGCSqGSIb3DQEJBDEWBBQkmI4cWDL3JP8e9CC8 MnzjMvTfhzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgKJ8Pyj8VSvUEQCT+T3klMk6Np3pF2MYHXHX tl/CKdPxhuDFw+ZrariS+cPLpDl+kaTK90H3DuMGofSl5MJSCNexzS7U+eK0Ox1RW5e1Xh4kZI97 5sXA9SuuyXnZceDYB5DebdVxpA9wGAPiUwGy3oEjrLgPrtN43W4WeFMnAQWeAAAAAAAA --Apple-Mail-2--991394501-- From egerck@nma.com Mon Apr 25 15:26:55 2011 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 57DEFE0676 for ; Mon, 25 Apr 2011 15:26:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmaZSqFD334Q for ; Mon, 25 Apr 2011 15:26:54 -0700 (PDT) Received: from nm1-vm0.access.bullet.mail.mud.yahoo.com (nm1-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.27]) by ietfa.amsl.com (Postfix) with SMTP id 8F3BEE0663 for ; Mon, 25 Apr 2011 15:26:54 -0700 (PDT) Received: from [66.94.237.200] by nm1.access.bullet.mail.mud.yahoo.com with NNFMP; 25 Apr 2011 19:55:20 -0000 Received: from [66.94.237.124] by tm11.access.bullet.mail.mud.yahoo.com with NNFMP; 25 Apr 2011 19:55:20 -0000 Received: from [127.0.0.1] by omp1029.access.mail.mud.yahoo.com with NNFMP; 25 Apr 2011 19:55:20 -0000 X-Yahoo-Newman-Id: 949233.14094.bm@omp1029.access.mail.mud.yahoo.com Received: (qmail 41664 invoked from network); 25 Apr 2011 19:55:20 -0000 Received: from [172.16.1.88] (egerck@99.145.106.177 with plain) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 25 Apr 2011 12:55:20 -0700 PDT X-Yahoo-SMTP: MbPjQnGswBC7yA6NwEFbGJ4iXszffqyyVjqB X-YMail-OSG: 5fHwEn0VM1l7YRwyxwB_D.OwsROiZcbor0DgkcpS6OzSNlC Su1FQfhoHviUey9rAzwC6kBmKdgy60f17IC_DtCRiq6kI1zM1RhKNFpKobNt jAqvolC0Ez48U_QxU5JsJ7Yahd3tA.vK4vLMLD18Ph3.vG6_FeTRjMuRbSJI 9y16jwJ2_l9bYRb2gZXFtEWOIRGwTW5vKFjizycbe96vO1byOabVcQde4Xuw kw1bjRtl7s.gelWSF2jOmyWG8GSQihU2vlc9rmG2V_9t5SP2Ho_PZOmIZ106 cebULmokym94iw9BvHwUCK58fWOcxknoYd5n8ToGiLDWZP5KAnqcogfc.sfv V45JiWKX1BGSRhyHrJA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DB5D1A7.2030808@nma.com> Date: Mon, 25 Apr 2011 12:55:19 -0700 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> <4DB1803C.4000903@Dartmouth.edu> <010d01cc0140$d63b0a70$82b11f50$@augustcellars.com> <2A645B64-1ED6-4A4E-A542-98D1531FA337@mitre.org> <4DB47899.3090701@nma.com> <652553A4-E259-48BA-8B45-DDA087E5B21A@mitre.org> In-Reply-To: <652553A4-E259-48BA-8B45-DDA087E5B21A@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 25 Apr 2011 22:26:55 -0000 On 4/25/2011 5:02 AM, Miller, Timothy J. wrote: > OK, granted. So what's the alternative? (And don't say identity based encryption or I promise I'll have you flogged :). Well, using IBE encryption does not work because IBE requires sender key-escrow, and so the sender is always at risk that her messages can be read by someone else. In addition, key revocation has even less reliance than with PKI (yes, that is possible!). There are other problems as well. The alternative should provide a compatible solution to conventional PKI and PGP secure email, so that there is no need for format wars and the extensive PKIX (and Open PGP) work can be used where it fits. I also think that it should add first-contact and first-reply capabilities, as well as document lifecycle control functions, such as self-destruct (the certificate is short-lived and keys are destroyed). This hybrid PKI/PGP solution is ZSentry Universal, based on Zmail (ZSentry Mail) and reviewed with PKI, PGP and IBE in (reprint) http://email-security.net/papers/pki-pgp-ibe-zmail.pdf To comment, please send off-list as this is not a work item of PKIX (though an I-D may be submitted in the future). Cheers, Ed Gerck From stefan@aaa-sec.com Mon Apr 25 17:02:23 2011 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 DEC4DE0698 for ; Mon, 25 Apr 2011 17:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdT3xU9OUsFv for ; Mon, 25 Apr 2011 17:02:23 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 54224E0696 for ; Mon, 25 Apr 2011 17:02:21 -0700 (PDT) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id AEE732B417F for ; Tue, 26 Apr 2011 02:02:21 +0200 (CEST) Received: (qmail 88665 invoked from network); 26 Apr 2011 00:02:11 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.10]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Apr 2011 00:02:11 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 26 Apr 2011 02:02:05 +0200 From: Stefan Santesson To: "Miller, Timothy J." , "Ed Gerck, Ph.D." Message-ID: Thread-Topic: [pkix] Email in Certs and Privacy Concerns In-Reply-To: <652553A4-E259-48BA-8B45-DDA087E5B21A@mitre.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 00:02:24 -0000 I believe the closest we can come to an alternative is what was discussed in the plasma BOF. That is a model where you don't need the certificate of the recipient in order to send an encrypted mail. Instead you send an encrypted mail and deposit the key that the receiver can obtain from a key server upon authenticating itself to the key server according to a policy set by the sender. That effectively avoids the need for certificate repositories for secure e-mail. That is also the model used for secure e-mail since many years now using Microsoft Information Rights Management. The only problem with that is that it is not X.509 cert based but XRML license based. I think this is the kind of model secure e-mail needs in order to become feasible. /Stefan On 11-04-25 2:02 PM, "Miller, Timothy J." wrote: >OK, granted. So what's the alternative? (And don't say identity based >encryption or I promise I'll have you flogged :). > >-- T > > > >On Apr 24, 2011, at 2:23 PM, Ed Gerck, Ph.D. wrote: > >> List, >> >> this shows, once again (see archives), that the security model for >>protecting >> email with conventional PKC is backwards, technically and business >>wise. The >> sender, who is the party at risk, finds herself in the awkward position >>of having >> to rely on a lock provided by the recipient (his public-key) in order >>to protect >> her secrets (the message). Whereas the recipient risks losing privacy >>just by >> getting a key cert. >> >> If postal mail would provide message security a la PKC/PKI email, the >>sender >> would have to convince the recipient to pay and send in advance an >> envelope for the sender to use. The sender, however, would never know >> whether the envelope indeed prevented others from prying into its >>contents >> (translated to PKI: weak keys, escrowed keys, rogue CAs, etc.) >> >> Businesswise, the recipient is also not the business driver who needs >>to provide, >> pay for and protect the lock. The sender is the party who has the >>motivation to >> spend money to provide and protect the lock. >> >> Of course, PKC is a well-known and recognized standard (in various >>forms, including >> PKI and PGP) for encryption of email. However, their security and >>usability >> problems >> noted above just cannot be solved by improvements in usability, better >>pricing >> or user >> education regarding how it works. It simply does not work as it should >>work. >> That's also >> why conventional secure email has been difficult to use. It has the >>wrong logic >> for the >> problem. This is a basic limitation. >> >> Cheers, >> Ed Gerck >> >> >> _______________________________________________ >> 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 stefan@aaa-sec.com Mon Apr 25 17:09:54 2011 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 63AEAE0696 for ; Mon, 25 Apr 2011 17:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.783 X-Spam-Level: X-Spam-Status: No, score=-102.783 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG4FgP+-MbWt for ; Mon, 25 Apr 2011 17:09:49 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id D916FE068A for ; Mon, 25 Apr 2011 17:09:48 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 772323B14C6 for ; Tue, 26 Apr 2011 02:09:56 +0200 (CEST) Received: (qmail 67800 invoked from network); 26 Apr 2011 00:09:46 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.10]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Apr 2011 00:09:46 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 26 Apr 2011 02:09:43 +0200 From: Stefan Santesson To: Kyle Hamilton , "Kemp, David P." Message-ID: Thread-Topic: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 26 Apr 2011 00:09:54 -0000 This might be true, but unnecessarily complex and potentially confusing. I'd say that a self signed certificate is: "Information associated with a public key, asserted by the holder of the corresponding private key." And that is all it is. /Stefan On 11-04-23 8:15 AM, "Kyle Hamilton" wrote: >A self-signed certificate structure has the semantic meaning of "I am >that which can be identified with this public key, and the >self-signature proves both that the private key to this public key >exists and that its holder approved this statement." > >What everyone forgets is that X.509 is a means of carrying a chain of >semantic authority through signatures provably chained from how that >authority is identified (the authority's public key). > >Why must the signature structure in the outermost wrapper of the >TBSCertificate be the only place where those signatures can be >asserted? > >-Kyle H > >On Fri, Apr 22, 2011 at 6:20 AM, Kemp, David P. >wrote: >> So how is that different from my MSEE from Princeton University*? I'm >> sure they would refuse any and all liability, yet most people would >> consider that piece of sheepskin more authoritative than an MS degree I >> awarded to myself. >> >> Dave >> >> * I didn't go to Princeton, but I do have a MSEE from an institution of >> similar reputation. See me over a beer if you care which one. >> >> >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Peter Gutmann >> Sent: Friday, April 22, 2011 8:22 AM >> To: pgut001@cs.auckland.ac.nz; tmiller@mitre.org >> Cc: pkix@ietf.org >> Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] >> [keyassure] Use cases document.) >> >> "Miller, Timothy J." writes: >> >>>Yeah, but unlike a self-asserter commercial CAs can be held liable >> (within >>>unclear and probably variable limits). >> >> Hmm, you haven't been following the discussion on the Mozilla policy >> list have >> you? Effectively once a commercial CA has issued enough certs to become >> Too >> Big To Fail, it's absolved of any liability (that's a very, very >> cut-down >> summary of an interminable discussion, see the thread "Response from >> Comodo" >> for the full thing). >> >> Peter. >> >> _______________________________________________ >> 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 From thierry.moreau@connotech.com Mon Apr 25 17:46:43 2011 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 76115E0663 for ; Mon, 25 Apr 2011 17:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StGA4cvQPOaG for ; Mon, 25 Apr 2011 17:46:43 -0700 (PDT) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id E7EA8E062A for ; Mon, 25 Apr 2011 17:46:42 -0700 (PDT) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 40948302F1; Tue, 26 Apr 2011 01:56:34 -0400 (EDT) Message-ID: <4DB61727.7050901@connotech.com> Date: Mon, 25 Apr 2011 20:51:51 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 26 Apr 2011 00:46:43 -0000 Stefan Santesson wrote: > > I'd say that a self signed certificate is: > > "Information associated with a public key, asserted by the holder of the > corresponding private key." > > And that is all it is. > I would say a self-signed certificate is even less conclusive: s/the holder/a holder/ The belief that the corresponding private key is controlled by a single "holder" can not come from the self-signed certificate. Every single element of trust must be established by non-crypto means. Thereafter, crypto merely transposes trust from a context to the next. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 From mattking1@gmail.com Mon Apr 25 19:20:05 2011 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 DF6D7E06B3 for ; Mon, 25 Apr 2011 19:20:05 -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, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-UeABRRjHSZ for ; Mon, 25 Apr 2011 19:20:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59FFCE06AB for ; Mon, 25 Apr 2011 19:20:04 -0700 (PDT) Received: by fxm15 with SMTP id 15so150211fxm.31 for ; Mon, 25 Apr 2011 19:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G2GnL3TgXP4Wws6AefL3ue5PGWZ4JF6YSdtgHhPsFmI=; b=roZ8DM5jJZXGX/oRzuo9m9lQV3CRco6kecKI1/AW//jf9JUKwcc9wio46YX1WlmeIr jnGONEILC8GCZSySw9JZ+RsXmzXOdTDhLevzFywqAN5nAoPREjW8bR9/uNOklL7bpFmo 6wnHNmcGncNHesAnnCe86W4nvBKMGejyHXItQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gNnN+gMIa7Pg2VYOot9Ylgo5EM9BTaGfbFc/NWlyl4gDF+k0L6uQ3MGUcxVbVrpqWS OBYsUErRdkfuP43qEBeNGUlYpq5OjzlKC8tZDAC8wQf4oEs4PPZ6uIs2DAfRuXqw/gtz 8hz6ivLQCshyLUH0djDAvipGJiQMrKUAlTo2U= MIME-Version: 1.0 Received: by 10.223.148.203 with SMTP id q11mr186564fav.44.1303784403468; Mon, 25 Apr 2011 19:20:03 -0700 (PDT) Received: by 10.223.28.12 with HTTP; Mon, 25 Apr 2011 19:20:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Apr 2011 22:20:03 -0400 Message-ID: From: Matt King To: Stefan Santesson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: matt.tebo@pgs.protiviti.com, dave.silver@protiviti.com, pkix-chairs@tools.ietf.org, chris.louden@pgs.protiviti.com, pkix@ietf.org, tim.pinegar@pgs.protiviti.com Subject: Re: [pkix] claimSigning EKU draft for PKIX WG Consideration 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, 26 Apr 2011 02:20:06 -0000 Hi Stefan Thanks for your comments. To address some of your concerns: 1. We were not aware of the competing proposal and will analyze it to understand and proved more information about the differences 2. We will fix the wrapping issue and missing ASN.1 section 3. We will evaluate the feasibility and pracicality of defining a claimSigning protocol 4. I'll need to consult with my team about your metadata signing comment, but I do believe that someone who signs metadata is making a claim that the contents of the metadata are true. While you could execute this operation with a general purpose PKI, it would have more meaning if the metadata is signed with keys associated with a cert asserting a claimSigning EKU. I'll be out of town this week due to a death in my family, but I will look forward to continued discussion of our proposal and provide additional responses to your comments upon my return. Thank you again for considering our proposal. Matt --=20 Matt King Protiviti Inc. Government Services Matthew.King@pgs.protiviti.com 410-271-5624 (Mobile) On Fri, Apr 22, 2011 at 7:31 PM, Stefan Santesson wrot= e: > Matt, > > Thanks for binging this proposal to PKIX. > > First thing that strikes me is that we seem to have two competing > proposals on the table. This one and > draft-patterson-pkix-attribute-signing-eku. > Is this a coincidence or are the authors aware of each other and has > intentionally put forth different proposals? > > This draft seems to have more description of the use case and also involv= e > the use for signing metadata records which is interesting. > > The OID declaration in section 3 seems to have corrupted line wrapping. > Looks like you used NroffEdit and forgot to include the .nf directive :) > > Try replacing with the following: > .in 8 > .nf > id-kp =A0OBJECT IDENTIFIER =A0::=3D > =A0 { iso(1) identified-organization(3) dod(6) internet(1) > =A0 =A0 security(5) mechanisms(5) pkix(7) 3 } > > id-kp-claimSigning =A0OBJECT IDENTIFIER =A0::=3D =A0{ id-kp TBD } > .fi > .in 3 > > > The document is missing an ASN.1 section, but I guess you can add that > later. > > > Section 4 is problematic from a standardization scope perspective. A > standard cannot mandate matters that is outside of it's scope (or > jurisdiction). > If this standard would define a claims signing protocol, then it would be > within the scope of such standard to say what EKU values that such > protocol mandates. > > However, this draft does not defines such a protocol. It only defines an > EKU value. > It is not reasonable for this standard to dictate behavior of > implementations that does not implement this standard. > Thus, you can't dictate that implementations MUT NOT accept a cert for an= y > purpose if it does not contain the EKU you define. > Likewise you can't force implementations to accept a cert if it DOES > contain your EKU. > All you can say is what statement this EKU provides. Unless you want to g= o > further, you need to place such requirements in the protocol using the EK= U. > > > Finally, the use of this EKU for signing metadata provides an interesting > use case as it could be done with a cert provided from a general purpose > PKI. However isn't that a bit of a stretched semantics to denote that as > claims signing? > Given that there are no claims in the metadata. > > > /Stefan > > > > > On 11-04-22 7:51 PM, "Matt King" wrote: > >>Dear PKIX Working Group >> >>I have posted an draft document describing a claimSigning EKU. =A0It is >>titled =B3draft-king-pkix-claimsigning-extn-00.txt=B2 (abstract below) an= d >>it can be found at the following link for your review: >> >>http://datatracker.ietf.org/doc/draft-king-pkix-claimsigning-extn/?includ= e >>_text=3D1 >> >>I ask that the attached draft be considered as a new work item for >>this group. =A0Thank you in advance for your time. >> >>Abstract >> >> =A0 This memo specifies an Extended Key Usage (EKU) X.509 certificate >> =A0 extension which indicates that the certificate holder is authorized >> =A0 to sign security tokens to assert claims, or attributes, about a >> =A0 principal. >> >> =A0 When an owner of a certificate that asserts the claimSigning EKU >> =A0 signs a claim, the owner is asserting that a statement about the >> =A0 principal is true. For example, a IdP secure token service (STS) >> =A0 would use an X.509 certificate containing the claimSigning EKU to >> =A0 sign SAML assertions containing an identifier and attributes about a >> =A0 user. >> >> >>-- >>Matt King >>Protiviti >>Government Services >>Matthew.King@pgs.protiviti.com >>mattking1@gmail.com >>410-271-5624 (Mobile) >>_______________________________________________ >>pkix mailing list >>pkix@ietf.org >>https://www.ietf.org/mailman/listinfo/pkix > > > --=20 Matt King mattking1@gmail.com 410-271-5624 (Mobile) From stefan@aaa-sec.com Tue Apr 26 00:38:38 2011 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 03B0EE0701 for ; Tue, 26 Apr 2011 00:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrZxAi022ibx for ; Tue, 26 Apr 2011 00:38:37 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id E8010E067C for ; Tue, 26 Apr 2011 00:38:36 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B336F375880 for ; Tue, 26 Apr 2011 09:38:36 +0200 (CEST) Received: (qmail 8259 invoked from network); 26 Apr 2011 07:38:34 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.10]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Apr 2011 07:38:34 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 26 Apr 2011 09:38:26 +0200 From: Stefan Santesson To: Matt King Message-ID: Thread-Topic: [pkix] claimSigning EKU draft for PKIX WG Consideration In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: matt.tebo@pgs.protiviti.com, dave.silver@protiviti.com, pkix-chairs@tools.ietf.org, chris.louden@pgs.protiviti.com, pkix@ietf.org, tim.pinegar@pgs.protiviti.com Subject: Re: [pkix] claimSigning EKU draft for PKIX WG Consideration 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, 26 Apr 2011 07:38:38 -0000 Matt, In-line. On 11-04-26 4:20 AM, "Matt King" wrote: >Hi Stefan > >Thanks for your comments. To address some of your concerns: > >1. We were not aware of the competing proposal and will analyze it to >understand and proved more information about the differences >2. We will fix the wrapping issue and missing ASN.1 section >3. We will evaluate the feasibility and pracicality of defining a >claimSigning protocol That is not what I was suggesting. But if you feel that is desired then that should probably be a matter for another work group. My point is that different type of standards can put different requirements on EKU processing. A standard just defining EKU can for example not put requirements on clients not implementing the standard. So you need in any case clear up the requirements language of that section. >4. I'll need to consult with my team about your metadata signing >comment, but I do believe that someone who signs metadata is making a >claim that the contents of the metadata are true. While you could >execute this operation with a general purpose PKI, it would have more >meaning if the metadata is signed with keys associated with a cert >asserting a claimSigning EKU. Well, following your reasoning, all signing is claim signing. You can always say that you claim something in the act of signing. The term "Claims" however has been used lately in the industry in a much more defined manner. I'd say it has been used as a substitution for the term "Attribute" with a minor semantical twist that I never have understood, but in any case very close to attributes. SAML works with attributes and Information Cards with claims, even though they produce SAML assertions with attributes (identical to the claims) in the end. In the end of the day, the meta data catalog do not contain neither claims, nor attributes of subjects. It contain metadata about identity providers, service providers and attribute providers etc. I think you need to clarify your use of the term claims in your document to do what you suggest. /Stefan From tmiller@mitre.org Tue Apr 26 05:52:41 2011 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 56840E075D for ; Tue, 26 Apr 2011 05:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJFDn1mY7OsG for ; Tue, 26 Apr 2011 05:52:40 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 16884E075A for ; Tue, 26 Apr 2011 05:52:39 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 435EC21B1B9F; Tue, 26 Apr 2011 08:52:39 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3B1FB21B09A9; Tue, 26 Apr 2011 08:52:39 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 26 Apr 2011 08:52:38 -0400 From: "Miller, Timothy J." To: Stefan Santesson Date: Tue, 26 Apr 2011 08:52:37 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwEENKBt3ITo/OXQxin6Bd/yIRO8w== Message-ID: <701B1CE8-4A55-43E5-AB2B-F44B41D4BBC0@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-4--902356747"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 12:52:41 -0000 --Apple-Mail-4--902356747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That's nothing more than a walled garden email system; there are = hundreds of these out there (look around the HIPAA compliance space) and = really aren't any great shakes. The problems are, off the top of my head: - Prior arrangement between sender and recipient to select a TTP in = common; - Prior arrangement with the TTP to enroll keys and credentials;=20 - Trustability of the TTP; - Risks to the TTP key repository; - Recovery after breach of the TTP; - Secure authN to the TTP; - AuthZ at the TTP. I could go on if I tried harder. MS IRM is no different (and has a = couple additional problems, mostly stemming from implementation = details). My point is if you want to play in a walled garden with all the = necessary pre-arrangement this implies, the solution is trivial. But = S/MIME is solving a more general problem: i.e., secure communication = with a *minimum* of pre-arrangement (specifically, S/MIME requires a = single pre-arrangement message, communicating only the sender's = certificate). I have not seen any system *that attacks the same = problem* and does better. If people are concerned about privacy of the address, then stop using = email. I don't know what's expected here. Mail systems (including = snail mail) can't work by magic; the postman can't glean your intent = direct from your mind. *You have to write it on the damn envelope.* -- T On Apr 25, 2011, at 7:02 PM, Stefan Santesson wrote: > I believe the closest we can come to an alternative is what was = discussed > in the plasma BOF. >=20 > That is a model where you don't need the certificate of the recipient = in > order to send an encrypted mail. > Instead you send an encrypted mail and deposit the key that the = receiver > can obtain from a key server upon authenticating itself to the key = server > according to a policy set by the sender. > That effectively avoids the need for certificate repositories for = secure > e-mail. >=20 > That is also the model used for secure e-mail since many years now = using > Microsoft Information Rights Management. The only problem with that is > that it is not X.509 cert based but XRML license based. >=20 > I think this is the kind of model secure e-mail needs in order to = become > feasible. >=20 >=20 > /Stefan >=20 >=20 > On 11-04-25 2:02 PM, "Miller, Timothy J." wrote: >=20 >> OK, granted. So what's the alternative? (And don't say identity = based >> encryption or I promise I'll have you flogged :). >>=20 >> -- T >>=20 >>=20 >>=20 >> On Apr 24, 2011, at 2:23 PM, Ed Gerck, Ph.D. wrote: >>=20 >>> List, >>>=20 >>> this shows, once again (see archives), that the security model for >>> protecting >>> email with conventional PKC is backwards, technically and business >>> wise. The >>> sender, who is the party at risk, finds herself in the awkward = position >>> of having >>> to rely on a lock provided by the recipient (his public-key) in = order >>> to protect >>> her secrets (the message). Whereas the recipient risks losing = privacy >>> just by >>> getting a key cert. >>>=20 >>> If postal mail would provide message security a la PKC/PKI email, = the >>> sender >>> would have to convince the recipient to pay and send in advance an >>> envelope for the sender to use. The sender, however, would never = know >>> whether the envelope indeed prevented others from prying into its >>> contents >>> (translated to PKI: weak keys, escrowed keys, rogue CAs, etc.) >>>=20 >>> Businesswise, the recipient is also not the business driver who = needs >>> to provide, >>> pay for and protect the lock. The sender is the party who has the >>> motivation to >>> spend money to provide and protect the lock. >>>=20 >>> Of course, PKC is a well-known and recognized standard (in various >>> forms, including >>> PKI and PGP) for encryption of email. However, their security and >>> usability=20 >>> problems >>> noted above just cannot be solved by improvements in usability, = better >>> pricing=20 >>> or user >>> education regarding how it works. It simply does not work as it = should >>> work.=20 >>> That's also >>> why conventional secure email has been difficult to use. It has the >>> wrong logic=20 >>> for the >>> problem. This is a basic limitation. >>>=20 >>> Cheers, >>> Ed Gerck >>>=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 >=20 >=20 --Apple-Mail-4--902356747 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjYxMjUyMzhaMCMGCSqGSIb3DQEJBDEWBBTJ+t8UuRr4o20yFu/b g/bogAT6RjByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgK2W+0eODI5+YAgzGxv0G9TaLCnyqU6za/LF 9ItdqSF+StwCCwLvYVU7yI6gTBx7nbUURqR1c9l5X4BD/6W1G3sU3JcvZ4ZeKRdy90OgMQ0nVN2R 9F1jDgsGl0Xu9TtqbK4qWXRN3oVmqxP0EAsEwFANYlOl/c6dmZbzeLwDo7fgAAAAAAAA --Apple-Mail-4--902356747-- From tmiller@mitre.org Tue Apr 26 05:56:18 2011 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 15AD5E075E for ; Tue, 26 Apr 2011 05:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzLHzt-OeBYL for ; Tue, 26 Apr 2011 05:56:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBF7E075D for ; Tue, 26 Apr 2011 05:56:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 429AD21B2058; Tue, 26 Apr 2011 08:56:16 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3AADE21B2050; Tue, 26 Apr 2011 08:56:16 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 26 Apr 2011 08:56:15 -0400 From: "Miller, Timothy J." To: "Ed Gerck, Ph.D." Date: Tue, 26 Apr 2011 08:56:11 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwEEVNyjAVwsRC/SuW/KU8m84gL2A== Message-ID: <8FB55B47-6E8D-4083-A7DA-EE6981938941@mitre.org> References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> <4DB1803C.4000903@Dartmouth.edu> <010d01cc0140$d63b0a70$82b11f50$@augustcellars.com> <2A645B64-1ED6-4A4E-A542-98D1531FA337@mitre.org> <4DB47899.3090701@nma.com> <652553A4-E259-48BA-8B45-DDA087E5B21A@mitre.org> <4DB5D1A7.2030808@nma.com> In-Reply-To: <4DB5D1A7.2030808@nma.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-5--902142649"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 12:56:18 -0000 --Apple-Mail-5--902142649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No offense, Ed, but walled garden systems are a dime a dozen and = trivial. I don't consider these to be a solution to the base problem of = *two* communicating partners (walled garden systems have *three* = partners--sender, recipient, and keyserver). See my response to Stefan = for more. -- T On Apr 25, 2011, at 2:55 PM, Ed Gerck, Ph.D. wrote: > On 4/25/2011 5:02 AM, Miller, Timothy J. wrote: >> OK, granted. So what's the alternative? (And don't say identity = based encryption or I promise I'll have you flogged :). >=20 > Well, using IBE encryption does not work because IBE requires sender=20= > key-escrow, and so the sender is always at risk that her messages can = be read=20 > by someone else. In addition, key revocation has even less reliance = than with=20 > PKI (yes, that is possible!). There are other problems as well. >=20 > The alternative should provide a compatible solution to conventional = PKI and=20 > PGP secure email, so that there is no need for format wars and the = extensive=20 > PKIX (and Open PGP) work can be used where it fits. I also think that = it=20 > should add first-contact and first-reply capabilities, as well as = document=20 > lifecycle control functions, such as self-destruct (the certificate is=20= > short-lived and keys are destroyed). >=20 > This hybrid PKI/PGP solution is ZSentry Universal, based on Zmail = (ZSentry=20 > Mail) and reviewed with PKI, PGP and IBE in (reprint)=20 > http://email-security.net/papers/pki-pgp-ibe-zmail.pdf >=20 > To comment, please send off-list as this is not a work item of PKIX = (though an=20 > I-D may be submitted in the future). >=20 > Cheers, > Ed Gerck --Apple-Mail-5--902142649 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjYxMjU2MTJaMCMGCSqGSIb3DQEJBDEWBBQAsgZvyltTVQi49v7K TlX+/4S8WTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgBSj06HCOh8dz0zFj4tbD5AJM8oySNmdjyyl mnnqMpUsP712RtWOrOnY+HGveznbQNuVxsupUqqsAlZXXKNsEejI+tmW/667BHP8HRcYw+R2wdoQ tkw+ej79Fv9dwqZt4oN5qWNXjEI/b5RPMJaxAtTLMjKjy4mH3bTUcVJ9mPPVAAAAAAAA --Apple-Mail-5--902142649-- From ejnorman@doit.wisc.edu Tue Apr 26 06:09:46 2011 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 E7A4AE0780 for ; Tue, 26 Apr 2011 06:09:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0Hn+RGgjXxe for ; Tue, 26 Apr 2011 06:09:46 -0700 (PDT) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by ietfa.amsl.com (Postfix) with ESMTP id 4E121E0773 for ; Tue, 26 Apr 2011 06:09:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LK900000GK9ZA00@smtpauth3.wiscmail.wisc.edu> for pkix@ietf.org; Tue, 26 Apr 2011 08:09:45 -0500 (CDT) Received: from [192.168.0.12] (68-118-158-189.dhcp.mdsn.wi.charter.com [68.118.158.189]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LK900FKQGK8EB30@smtpauth3.wiscmail.wisc.edu> for pkix@ietf.org; Tue, 26 Apr 2011 08:09:44 -0500 (CDT) Date: Tue, 26 Apr 2011 08:09:32 -0500 From: Eric Norman In-reply-to: <4DB61727.7050901@connotech.com> To: pkix@ietf.org Message-id: <20F3DA1F-2264-4DE4-81C7-E91D49AF915C@doit.wisc.edu> X-Mailer: Apple Mail (2.1084) X-Spam-Score-Internal: ******* X-Spam-PmxInfo: Server=avs-10, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.26.130318, SenderIP=192.168.0.12 References: <4DB61727.7050901@connotech.com> Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 26 Apr 2011 13:09:47 -0000 On Apr 25, 2011, at 7:51 PM, Thierry Moreau wrote: > Stefan Santesson wrote: >> I'd say that a self signed certificate is: >> "Information associated with a public key, asserted by the holder of the >> corresponding private key." >> And that is all it is. > > I would say a self-signed certificate is even less conclusive: > s/the holder/a holder/ > > The belief that the corresponding private key is controlled by a single "holder" can not come from the self-signed certificate. But proof of possession will come from usage. I.e. the purported owner won't be able to sign or decrypt without the private key. EJN From stefan@aaa-sec.com Tue Apr 26 06:31:08 2011 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 07992E079E for ; Tue, 26 Apr 2011 06:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEl+6njaSLyp for ; Tue, 26 Apr 2011 06:31:07 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7343EE0781 for ; Tue, 26 Apr 2011 06:31:03 -0700 (PDT) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7C37D4AE8B8 for ; Tue, 26 Apr 2011 15:29:48 +0200 (CEST) Received: (qmail 29564 invoked from network); 26 Apr 2011 13:29:43 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Apr 2011 13:29:43 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 26 Apr 2011 15:29:40 +0200 From: Stefan Santesson To: "Miller, Timothy J." Message-ID: Thread-Topic: [pkix] Email in Certs and Privacy Concerns In-Reply-To: <701B1CE8-4A55-43E5-AB2B-F44B41D4BBC0@mitre.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 13:31:08 -0000 Timothy, You are absolutely right, However, in the world of identity federation, we often have almost all the pre arrangements already in place. If you already have a system in place for identification/authentication, all you need is to set up a key server as an SP and you are practically done. And that is what I think is key, to leverage existing infrastructures to make other problems easier to solve. Bare S/MIME has it's place, but I can't see it being overly successful in large communities that need e-mail encryption. /Stefan On 11-04-26 2:52 PM, "Miller, Timothy J." wrote: >That's nothing more than a walled garden email system; there are hundreds >of these out there (look around the HIPAA compliance space) and really >aren't any great shakes. > >The problems are, off the top of my head: > >- Prior arrangement between sender and recipient to select a TTP in >common; >- Prior arrangement with the TTP to enroll keys and credentials; >- Trustability of the TTP; >- Risks to the TTP key repository; >- Recovery after breach of the TTP; >- Secure authN to the TTP; >- AuthZ at the TTP. > >I could go on if I tried harder. MS IRM is no different (and has a >couple additional problems, mostly stemming from implementation details). > >My point is if you want to play in a walled garden with all the necessary >pre-arrangement this implies, the solution is trivial. But S/MIME is >solving a more general problem: i.e., secure communication with a >*minimum* of pre-arrangement (specifically, S/MIME requires a single >pre-arrangement message, communicating only the sender's certificate). I >have not seen any system *that attacks the same problem* and does better. > >If people are concerned about privacy of the address, then stop using >email. I don't know what's expected here. Mail systems (including snail >mail) can't work by magic; the postman can't glean your intent direct >from your mind. *You have to write it on the damn envelope.* > >-- T > > > >On Apr 25, 2011, at 7:02 PM, Stefan Santesson wrote: > >> I believe the closest we can come to an alternative is what was >>discussed >> in the plasma BOF. >> >> That is a model where you don't need the certificate of the recipient in >> order to send an encrypted mail. >> Instead you send an encrypted mail and deposit the key that the receiver >> can obtain from a key server upon authenticating itself to the key >>server >> according to a policy set by the sender. >> That effectively avoids the need for certificate repositories for secure >> e-mail. >> >> That is also the model used for secure e-mail since many years now using >> Microsoft Information Rights Management. The only problem with that is >> that it is not X.509 cert based but XRML license based. >> >> I think this is the kind of model secure e-mail needs in order to become >> feasible. >> >> >> /Stefan >> >> >> On 11-04-25 2:02 PM, "Miller, Timothy J." wrote: >> >>> OK, granted. So what's the alternative? (And don't say identity based >>> encryption or I promise I'll have you flogged :). >>> >>> -- T >>> >>> >>> >>> On Apr 24, 2011, at 2:23 PM, Ed Gerck, Ph.D. wrote: >>> >>>> List, >>>> >>>> this shows, once again (see archives), that the security model for >>>> protecting >>>> email with conventional PKC is backwards, technically and business >>>> wise. The >>>> sender, who is the party at risk, finds herself in the awkward >>>>position >>>> of having >>>> to rely on a lock provided by the recipient (his public-key) in order >>>> to protect >>>> her secrets (the message). Whereas the recipient risks losing privacy >>>> just by >>>> getting a key cert. >>>> >>>> If postal mail would provide message security a la PKC/PKI email, the >>>> sender >>>> would have to convince the recipient to pay and send in advance an >>>> envelope for the sender to use. The sender, however, would never know >>>> whether the envelope indeed prevented others from prying into its >>>> contents >>>> (translated to PKI: weak keys, escrowed keys, rogue CAs, etc.) >>>> >>>> Businesswise, the recipient is also not the business driver who needs >>>> to provide, >>>> pay for and protect the lock. The sender is the party who has the >>>> motivation to >>>> spend money to provide and protect the lock. >>>> >>>> Of course, PKC is a well-known and recognized standard (in various >>>> forms, including >>>> PKI and PGP) for encryption of email. However, their security and >>>> usability >>>> problems >>>> noted above just cannot be solved by improvements in usability, better >>>> pricing >>>> or user >>>> education regarding how it works. It simply does not work as it should >>>> work. >>>> That's also >>>> why conventional secure email has been difficult to use. It has the >>>> wrong logic >>>> for the >>>> problem. This is a basic limitation. >>>> >>>> Cheers, >>>> Ed Gerck >>>> >>>> >>>> _______________________________________________ >>>> 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 tmiller@mitre.org Tue Apr 26 06:34:35 2011 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 EF8B4E0773 for ; Tue, 26 Apr 2011 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwn+vzvrAjdN for ; Tue, 26 Apr 2011 06:34:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 30405E072A for ; Tue, 26 Apr 2011 06:34:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 97A0F21B1BBF; Tue, 26 Apr 2011 09:34:34 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9029B21B0237; Tue, 26 Apr 2011 09:34:34 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 26 Apr 2011 09:34:34 -0400 From: "Miller, Timothy J." To: Eric Norman Date: Tue, 26 Apr 2011 09:34:28 -0400 Thread-Topic: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) Thread-Index: AcwEFq0pOWY4ZkfIRxO8+fsWVfqE2Q== Message-ID: <89DCBB80-1694-458C-B695-A4CC4475F0B4@mitre.org> References: <4DB61727.7050901@connotech.com> <20F3DA1F-2264-4DE4-81C7-E91D49AF915C@doit.wisc.edu> In-Reply-To: <20F3DA1F-2264-4DE4-81C7-E91D49AF915C@doit.wisc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-8--899845818"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 26 Apr 2011 13:34:36 -0000 --Apple-Mail-8--899845818 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Actually, the belief that the corresponding private key is controlled by = a *single* holder doesn't come from any cert. It comes from the = issuance policy and the technology used to enforce it. All the cert = does is tell you which sections of which CP & CPS to go read. :) -- T On Apr 26, 2011, at 8:09 AM, Eric Norman wrote: >=20 > On Apr 25, 2011, at 7:51 PM, Thierry Moreau wrote: >=20 >> Stefan Santesson wrote: >>> I'd say that a self signed certificate is: >>> "Information associated with a public key, asserted by the holder of = the >>> corresponding private key." >>> And that is all it is. >>=20 >> I would say a self-signed certificate is even less conclusive: >> s/the holder/a holder/ >>=20 >> The belief that the corresponding private key is controlled by a = single "holder" can not come from the self-signed certificate. >=20 > But proof of possession will come from usage. I.e. the purported = owner won't be > able to sign or decrypt without the private key. >=20 > EJN > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-8--899845818 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjYxMzM0MjlaMCMGCSqGSIb3DQEJBDEWBBT2if96RZ0m8gpZeMCO kL3C8K1/6jByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgMOmtoXnt2uqtDSnOAlWoP7JnndRkMEfZiAO vN7IqM6gXyDfGItOqMvkEqlGbg6rEWNO0HGWGoDkgW9kMkgSJ7Xs7hrJ4fIQJsRy+riv1BzN8ZHU iCqmnf7w4dQse48HGCyySuABV8ESiWn+6ytGNc/vVKHl7Z0AvQLcxQD3G5SEAAAAAAAA --Apple-Mail-8--899845818-- From tmiller@mitre.org Tue Apr 26 06:42:14 2011 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 2D2FDE07A9 for ; Tue, 26 Apr 2011 06:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K9wYIzZblxT for ; Tue, 26 Apr 2011 06:42:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2D879E0738 for ; Tue, 26 Apr 2011 06:42:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A98DF21B2060; Tue, 26 Apr 2011 09:42:12 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A3B9721B1BC6; Tue, 26 Apr 2011 09:42:12 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 26 Apr 2011 09:42:12 -0400 From: "Miller, Timothy J." To: Stefan Santesson Date: Tue, 26 Apr 2011 09:42:10 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwEF77Eb5+QG5CFREqYjfcJ+6vMvw== Message-ID: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-9--899383656"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 13:42:14 -0000 --Apple-Mail-9--899383656 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 26, 2011, at 8:29 AM, Stefan Santesson wrote: > However, in the world of identity federation, we often have almost all = the > pre arrangements already in place. > If you already have a system in place for = identification/authentication, > all you need is to set up a key server as an SP and you are = practically > done. Email is more general still. MITRE and AAA-SEC have no prior = arrangements, yet I can send you secure email *if* I can associate a key = with you. *How* I associate a key with you is open for discussion. = This may use a prior arrangement (you send me a signed email) or I may = be able to discover it (via a directory, web reference, or email = archive) on my own. > And that is what I think is key, to leverage existing infrastructures = to > make other problems easier to solve. That's fine for intranet and E2E, but everyone else is left hanging. = While I'm sympathetic to intranet & E2E environments, it's not = particularly hard to build directories in either, and a simple directory = *does* solve the problem. As a result I tend to think inventing new = protocols to cover this special case is a waste of time. -- T --Apple-Mail-9--899383656 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjYxMzQyMTFaMCMGCSqGSIb3DQEJBDEWBBQB6Y1Vggpc0ftOuFas ojiAiHtPQzByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgHWGY9XqtFLWu1rm/JnOrViM9mVBPP3ddZE3 +gXi3toF/L+Zn0iHc39ylhveqBsVy1STAK5J1WQu5CNqIN6AiSLSmV+U5V4mWS9/1LxHcmwXQZt/ mzmRAyUm3DMW2Kel+S2ui+w7Jfn66f6dLVINaEw3Lq3umNQzLacDYbGEhAe4AAAAAAAA --Apple-Mail-9--899383656-- From stefan@aaa-sec.com Tue Apr 26 07:00:16 2011 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 01CEFE06A8 for ; Tue, 26 Apr 2011 07:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Zb1dQVT78IX for ; Tue, 26 Apr 2011 07:00:15 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF5E077A for ; Tue, 26 Apr 2011 07:00:14 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 69BC43AFC7A for ; Tue, 26 Apr 2011 16:00:19 +0200 (CEST) Received: (qmail 21470 invoked from network); 26 Apr 2011 14:00:13 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Apr 2011 14:00:13 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 26 Apr 2011 16:00:10 +0200 From: Stefan Santesson To: "Miller, Timothy J." Message-ID: Thread-Topic: [pkix] Email in Certs and Privacy Concerns In-Reply-To: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 14:00:16 -0000 On 11-04-26 3:42 PM, "Miller, Timothy J." wrote: >On Apr 26, 2011, at 8:29 AM, Stefan Santesson wrote: > >> However, in the world of identity federation, we often have almost all >>the >> pre arrangements already in place. > >> If you already have a system in place for identification/authentication, >> all you need is to set up a key server as an SP and you are practically >> done. > >Email is more general still. MITRE and AAA-SEC have no prior >arrangements, yet I can send you secure email *if* I can associate a key >with you. *How* I associate a key with you is open for discussion. This >may use a prior arrangement (you send me a signed email) or I may be able >to discover it (via a directory, web reference, or email archive) on my >own. It may actually not be that far away. The EU stork project has built an international model for identity federation across countries. If we both have means of identification inside our respective international infrastructure, that trust can be proxied cross borders. In the planned swedish identity federation it would be even easier. In the large international University community, this is all in place. The point is that infrastructures capable of doing identification are emerging. At some point there may be situations where you want to leverage that for other things, such as secure e-mail. Many other countries cross Europe has national identity federation solutions in various stages of maturity. > >> And that is what I think is key, to leverage existing infrastructures to >> make other problems easier to solve. > >That's fine for intranet and E2E, but everyone else is left hanging. >While I'm sympathetic to intranet & E2E environments, it's not >particularly hard to build directories in either, and a simple directory >*does* solve the problem. As a result I tend to think inventing new >protocols to cover this special case is a waste of time. On the very contrary, leveraging large scale identity federation communities is a solution for national and international relationships. This is where identity federation beats direct trust in user certificates by magnitudes. It's all out there happening right now. /Stefan From egerck@nma.com Tue Apr 26 07:53:52 2011 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 4B5D5E0769 for ; Tue, 26 Apr 2011 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs1WeQ0m56DY for ; Tue, 26 Apr 2011 07:53:51 -0700 (PDT) Received: from nm29-vm0.access.bullet.mail.mud.yahoo.com (nm29-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.255]) by ietfa.amsl.com (Postfix) with SMTP id 7F9EAE0681 for ; Tue, 26 Apr 2011 07:53:51 -0700 (PDT) Received: from [66.94.237.126] by nm29.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Apr 2011 14:53:51 -0000 Received: from [66.94.237.111] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 26 Apr 2011 14:53:51 -0000 Received: from [127.0.0.1] by omp1016.access.mail.mud.yahoo.com with NNFMP; 26 Apr 2011 14:53:51 -0000 X-Yahoo-Newman-Id: 248341.65522.bm@omp1016.access.mail.mud.yahoo.com Received: (qmail 33638 invoked from network); 26 Apr 2011 14:53:50 -0000 Received: from [172.16.1.88] (egerck@99.145.106.177 with plain) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 26 Apr 2011 07:53:50 -0700 PDT X-Yahoo-SMTP: MbPjQnGswBC7yA6NwEFbGJ4iXszffqyyVjqB X-YMail-OSG: nkiliy0VM1lAjLgF5_IQpDFftJry4RKBTtAIHo8_fV1d5W0 NLUFYn1hsMFSysLAzvvYNXOwk8xo1AQEhDBVQbJLnF8qn86Ihvex3qiL3DN1 vjz43QyTZzklzviJEa.W.sRHgT7.6rJsZL9gXg3dMRV9qGAQgof_FFgijyBP pKfpdUA2PJbsbNB6NGpu5dUbEhVx0c3f4I3F149M77G5c5vHOsG7u3R_bAwm vroWC5KUi8voHPSs7_oV41.Zcit1nMlOhlElNjpybWKk75yL94ubgf1kYYGu q0POoBQbLVqumOXEg.oK6ImBtTou3KOSdT7eRKbqcpJsUEicb_9An.74ZVOc J X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DB6DC7D.8070200@nma.com> Date: Tue, 26 Apr 2011 07:53:49 -0700 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Miller, Timothy J." References: <4DADBAB7.8020809@Dartmouth.edu> <4DADFD4C.6000100@Dartmouth.edu> <009701cc0086$e9e92490$bdbb6db0$@augustcellars.com> <4DB1803C.4000903@Dartmouth.edu> <010d01cc0140$d63b0a70$82b11f50$@augustcellars.com> <2A645B64-1ED6-4A4E-A542-98D1531FA337@mitre.org> <4DB47899.3090701@nma.com> <652553A4-E259-48BA-8B45-DDA087E5B21A@mitre.org> <4DB5D1A7.2030808@nma.com> <8FB55B47-6E8D-4083-A7DA-EE6981938941@mitre.org> In-Reply-To: <8FB55B47-6E8D-4083-A7DA-EE6981938941@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 14:53:52 -0000 On 4/26/2011 5:56 AM, Miller, Timothy J. wrote: > I don't consider these to be a solution to the base problem of *two* communicating partners (walled garden systems have *three* partners--sender, recipient, and keyserver). Actually, to induce trust (reliance on information) you need to have at least _four_ parties to start (*). What you call a "walled garden" is not enough to start. There is also no need for the third-party to be a key-server -- as the key can be computed by the parties in the dialogue (PKI, PGP, the zsentry system I mentioned). For example, in secure PKI implementations you find the four parties as the two parties in dialogue, the CA and a verifier. The CA is not a key-server. If you only have the same CA as both the trusted introducer and the trusted witness (verifier), or if they are not independent from each other and the parties in dialogue, then you will find certain failure modes that may not be detected by at least one of the parties (even if no collusion exists) versus a 4-party implementation. After you start, and trust has been verified to the the level desired by the two parties in dialogue, then the other two parties are no longer needed (the zsentry system). You can also operate PKI in this way, transitioning to a non-PKI system after you start (this also helps improve signal security). Cheers, Ed Gerck (*) You need to have /at least/ four parties to induce trust between two parties who have no pre-existing trust: the two parties in dialogue plus a trusted introducer and a trusted witness. The latter is absent in (standard) PGP but can be provided in PKI. The last two parties should be as independent as possible from each other and any other party. If you only have two parties to start, a secure solution depends on pre-existing trust. If you only have three parties to start, or if the last two parties are not independent, a secure solution also depends on pre-existing trust. For higher assurance, you can add more parties than four. Reference: the link I sent before. From DPKemp@missi.ncsc.mil Tue Apr 26 08:04:54 2011 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 2A57AE07A3 for ; Tue, 26 Apr 2011 08:04:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDrphJJF7Bvn for ; Tue, 26 Apr 2011 08:04:53 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE17E0681 for ; Tue, 26 Apr 2011 08:04:53 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p3QF4qbt040337 for ; Tue, 26 Apr 2011 11:04:52 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 11:04:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 26 Apr 2011 11:04:00 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwEGlb8uifVtxz4QsqA6cFGgyUONAAArIEg References: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> From: "Kemp, David P." To: X-OriginalArrivalTime: 26 Apr 2011 15:04:32.0968 (UTC) FILETIME=[3FEBB480:01CC0423] Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 15:04:54 -0000 Does large-scale identity federation solve any privacy concerns? In other words, given your name or other information about you, can I look up your email address? Given your email address, I can either: 1) look up your public key, or 2) look up your TTP's address, create a private key, and deposit it with the TTP for you to retrieve Whether or not the lookups use the LDAP protocol, the "identity federation" performs the function of a directory. And if the wall around the garden is large enough, it becomes "The Directory". So I've lost the bubble on the privacy concern - you may let only a defined community look up your email address and cert or TTP, or you may let everyone look them up. But as far as I know, there is no implementable policy that would let "everyone but spammers" look you up and send you encrypted email. Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson On the very contrary, leveraging large scale identity federation communities is a solution for national and international relationships. This is where identity federation beats direct trust in user certificates by magnitudes. It's all out there happening right now. /Stefan From thierry.moreau@connotech.com Tue Apr 26 08:31:32 2011 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 12ACAE07BF for ; Tue, 26 Apr 2011 08:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGk69bPoAVXk for ; Tue, 26 Apr 2011 08:31:31 -0700 (PDT) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id C0EC4E07F8 for ; Tue, 26 Apr 2011 08:31:27 -0700 (PDT) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 3758630290; Tue, 26 Apr 2011 16:41:16 -0400 (EDT) Message-ID: <4DB6E687.70904@connotech.com> Date: Tue, 26 Apr 2011 11:36:39 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: Eric Norman References: <4DB61727.7050901@connotech.com> <20F3DA1F-2264-4DE4-81C7-E91D49AF915C@doit.wisc.edu> In-Reply-To: <20F3DA1F-2264-4DE4-81C7-E91D49AF915C@doit.wisc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 26 Apr 2011 15:31:32 -0000 Eric Norman wrote: > On Apr 25, 2011, at 7:51 PM, Thierry Moreau wrote: > >> Stefan Santesson wrote: >>> I'd say that a self signed certificate is: >>> "Information associated with a public key, asserted by the holder of the >>> corresponding private key." >>> And that is all it is. >> I would say a self-signed certificate is even less conclusive: >> s/the holder/a holder/ >> >> The belief that the corresponding private key is controlled by a single "holder" can not come from the self-signed certificate. > > But proof of possession will come from usage. I.e. the purported owner won't be > able to sign or decrypt without the private key. > Granted, but that just partially counters the threat spectrum: 1) The bogus self-signed certificate may be stored alongside legitimate ones, 2) Bogus self-signed certificates may be used in a proxy (man-in-the-middle). 3) The bogus self-signed certificate may be required for a short period of time by the adversary. This is why self-signed certificates should not be used as an assertion by the purported owner without other basis for trust. - Thierry Moreau From thierry.moreau@connotech.com Tue Apr 26 08:31:50 2011 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 4D472E07FB for ; Tue, 26 Apr 2011 08:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+R5gQWwA6tj for ; Tue, 26 Apr 2011 08:31:49 -0700 (PDT) Received: from bretelle.intaglionic.org (unknown [76.10.176.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1B89CE07BF for ; Tue, 26 Apr 2011 08:31:49 -0700 (PDT) Received: from [192.168.1.200] (unknown [192.168.1.200]) by bretelle.intaglionic.org (Postfix) with ESMTPA id 2DBE630290; Tue, 26 Apr 2011 16:41:38 -0400 (EDT) Message-ID: <4DB6E69D.8060904@connotech.com> Date: Tue, 26 Apr 2011 11:37:01 -0400 From: Thierry Moreau User-Agent: Thunderbird 2.0.0.17 (X11/20090608) MIME-Version: 1.0 To: "Miller, Timothy J." References: <4DB61727.7050901@connotech.com> <20F3DA1F-2264-4DE4-81C7-E91D49AF915C@doit.wisc.edu> <89DCBB80-1694-458C-B695-A4CC4475F0B4@mitre.org> In-Reply-To: <89DCBB80-1694-458C-B695-A4CC4475F0B4@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 26 Apr 2011 15:31:50 -0000 Miller, Timothy J. wrote: > Actually, the belief that the corresponding private key is controlled by a *single* holder doesn't come from any cert. It comes from the issuance policy and the technology used to enforce it. All the cert does is tell you which sections of which CP & CPS to go read. :) > The "technology used to enforce [self-signed certificate]" is a bit of a misnomer (aren't we in a discussion about semantics?). I question the word "enforce". A relying party has a local policy to trust (or not) such and such certificates. In practice, this policy seems embedded in a software installation package. Relying parties are not subject to non-compliance enforcement. They just bear higher risk (if too accommodating) or operational hindrance (if too strict) in face of very difficult trust assessment. Furthermore, the "issuance policy" appears as an ineffective as the rest of the self-signed certificate for detecting a bogus one. - Thierry Moreau > -- T > > On Apr 26, 2011, at 8:09 AM, Eric Norman wrote: > >> On Apr 25, 2011, at 7:51 PM, Thierry Moreau wrote: >> >>> Stefan Santesson wrote: >>>> I'd say that a self signed certificate is: >>>> "Information associated with a public key, asserted by the holder of the >>>> corresponding private key." >>>> And that is all it is. >>> I would say a self-signed certificate is even less conclusive: >>> s/the holder/a holder/ >>> >>> The belief that the corresponding private key is controlled by a single "holder" can not come from the self-signed certificate. >> But proof of possession will come from usage. I.e. the purported owner won't be >> able to sign or decrypt without the private key. >> >> EJN >> _______________________________________________ >> 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 trevorf@exchange.microsoft.com Tue Apr 26 11:24:49 2011 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 81214E077C for ; Tue, 26 Apr 2011 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz7g6gnKzxmK for ; Tue, 26 Apr 2011 11:24:46 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id A5561E0758 for ; Tue, 26 Apr 2011 11:24:46 -0700 (PDT) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 26 Apr 2011 11:24:46 -0700 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 26 Apr 2011 11:24:46 -0700 Received: from DF-M14-10.exchange.corp.microsoft.com ([fe80::b9ce:8ce7:94eb:4757]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.01.0218.012; Tue, 26 Apr 2011 11:24:44 -0700 From: Trevor Freeman To: "Miller, Timothy J." , Stefan Santesson Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AQHL/rBlO+8oEikT3Em7pJgbRcLPq5RmCU6AgAAesQCAArVoAIAAqF+AgADR1wCAAKIGAIAC1++AgAAQd4CAARcvgIAAyRqAgADXSYCAAApaAIAAA34A///T28A= Date: Tue, 26 Apr 2011 18:24:43 +0000 Message-ID: References: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> In-Reply-To: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.101] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D392DB4EBDFM1410exchange_" MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 26 Apr 2011 18:24:49 -0000 --_000_E545B914D50B2A4B994F198378B1525D392DB4EBDFM1410exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By your definition - pki is a series of walled gardens. How many times do w= e see signed email we are unable to validate? So the walled garden argument= is just as applicable to S/MIME today. Technology alone is not going to solve the walled garden problem. It's goin= g to be a combination of technology and policy. We need a better defined se= t of rules for establishing subject identity and attributes so we can more = readily understand what is presented is acceptable. When I hire a car in E= urope, I don't need to present a European driver's license. I present a lic= ense which is deemed to have been issued under an agreed set of minimal sta= ndards. There is a form or trust framework in place. The objective of Plasma is to enable policy enforcement in addition to conf= identiality. In many situations knowing the recipients public key is not en= ough. You need to know more attributes about the recipient in order to dete= rmine if they can see the content of the message. The sender does not typic= ally have access to that wealth of information and it's unreasonable to exp= ect it. A recipient needs to provide consent to the release of that informa= tion. The TTP provides a mechanism for the recipient to present the necessa= ry attributes under their control. Plasma also looks to decouple the type of credential a recipient has from t= he protocol so we don't have to require the entire universe of recipients t= o have been enrolled in PKI at the time you send a message. Still waiting t= o that to happen:). We need a level of assurance of identity but there are = many forms of credentials which can be used and as long as it's good enough= , I don't care what is used. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mil= ler, Timothy J. Sent: Tuesday, April 26, 2011 6:42 AM To: Stefan Santesson Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns On Apr 26, 2011, at 8:29 AM, Stefan Santesson wrote: > However, in the world of identity federation, we often have almost all > the pre arrangements already in place. > If you already have a system in place for > identification/authentication, all you need is to set up a key server > as an SP and you are practically done. Email is more general still. MITRE and AAA-SEC have no prior arrangements,= yet I can send you secure email *if* I can associate a key with you. *How= * I associate a key with you is open for discussion. This may use a prior = arrangement (you send me a signed email) or I may be able to discover it (v= ia a directory, web reference, or email archive) on my own. > And that is what I think is key, to leverage existing infrastructures > to make other problems easier to solve. That's fine for intranet and E2E, but everyone else is left hanging. While= I'm sympathetic to intranet & E2E environments, it's not particularly hard= to build directories in either, and a simple directory *does* solve the pr= oblem. As a result I tend to think inventing new protocols to cover this s= pecial case is a waste of time. -- T --_000_E545B914D50B2A4B994F198378B1525D392DB4EBDFM1410exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

By your definition - pki is a series of walled ga= rdens. How many times do we see signed email we are unable to validate? So = the walled garden argument is just as applicable to S/MIME today.

 

Technology alone is not going to solve the walled= garden problem. It's going to be a combination of technology and policy. W= e need a better defined set of rules for establishing subject identity and = attributes so we can more readily understand what is presented is acceptable.  When I hire a car in Eur= ope, I don’t need to present a European driver's license. I present a= license which is deemed to have been issued under an agreed set of minimal= standards. There is a form or trust framework in place.

 

The objective of Plasma is to enable policy enfor= cement in addition to confidentiality. In many situations knowing the recip= ients public key is not enough. You need to know more attributes about the = recipient in order to determine if they can see the content of the message. The sender does not typically hav= e access to that wealth of information and it's unreasonable to expect it. = A recipient needs to provide consent to the release of that information. Th= e TTP provides a mechanism for the recipient to present the necessary attributes under their control.

 

Plasma also looks to decouple the type of credent= ial a recipient has from the protocol so we don’t have to require the= entire universe of recipients to have been enrolled in PKI at the time you= send a message. Still waiting to that to happenJ. We need a level of a= ssurance of identity but there are many forms of credentials which can be u= sed and as long as it's good enough, I don’t care what is used.

 

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mil= ler, Timothy J.
Sent: Tuesday, April 26, 2011 6:42 AM
To: Stefan Santesson
Cc: pkix@ietf.org
Subject: Re: [pkix] Email in Certs and Privacy Concerns

 

On Apr 26, 2011, at 8:29 AM, Stefan Santesson wro= te:

 

> However, in the world of identity federation= , we often have almost all

> the pre arrangements already in place.<= /o:p>

 

> If you already have a system in place for

> identification/authentication, all you need = is to set up a key server

> as an SP and you are practically done.<= /o:p>

 

Email is more general still.  MITRE and AAA-= SEC have no prior arrangements, yet I can send you secure email *if* I can = associate a key with you.  *How* I associate a key with you is open fo= r discussion.  This may use a prior arrangement (you send me a signed email) or I may be able to discover it (via a direct= ory, web reference, or email archive) on my own.

 

> And that is what I think is key, to leverage= existing infrastructures

> to make other problems easier to solve.=

 

That's fine for intranet and E2E, but everyone el= se is left hanging.  While I'm sympathetic to intranet & E2E envir= onments, it's not particularly hard to build directories in either, and a s= imple directory *does* solve the problem.  As a result I tend to think inventing new protocols to cover this special = case is a waste of time.

 

-- T

 

--_000_E545B914D50B2A4B994F198378B1525D392DB4EBDFM1410exchange_-- From ejnorman@doit.wisc.edu Tue Apr 26 18:21:21 2011 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 7464EE068E for ; Tue, 26 Apr 2011 18:21:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIwChI29RK4H for ; Tue, 26 Apr 2011 18:21:21 -0700 (PDT) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by ietfa.amsl.com (Postfix) with ESMTP id E61F4E0684 for ; Tue, 26 Apr 2011 18:21:20 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LKA00N00EFJ1X00@smtpauth3.wiscmail.wisc.edu> for pkix@ietf.org; Tue, 26 Apr 2011 20:21:19 -0500 (CDT) Received: from [192.168.0.12] (68-118-158-189.dhcp.mdsn.wi.charter.com [68.118.158.189]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LKA00IOREFITV10@smtpauth3.wiscmail.wisc.edu> for pkix@ietf.org; Tue, 26 Apr 2011 20:21:18 -0500 (CDT) Date: Tue, 26 Apr 2011 20:21:18 -0500 From: Eric Norman In-reply-to: <4DB6E69D.8060904@connotech.com> To: pkix@ietf.org Message-id: <93E7E0CB-6C8E-4B8E-8BD8-B2EF07DE73BA@doit.wisc.edu> X-Mailer: Apple Mail (2.1084) X-Spam-Score-Internal: ******* X-Spam-PmxInfo: Server=avs-9, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.27.10915, SenderIP=192.168.0.12 References: <4DB61727.7050901@connotech.com> <20F3DA1F-2264-4DE4-81C7-E91D49AF915C@doit.wisc.edu> <89DCBB80-1694-458C-B695-A4CC4475F0B4@mitre.org> <4DB6E69D.8060904@connotech.com> Subject: Re: [pkix] 5280 and self-signed ee certs (was: Re:[dane] [keyassure] Use cases document.) 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, 27 Apr 2011 01:21:21 -0000 To get back to what seems to be the original question, I think the text of the appropriate RFCs should make it clear that: A valid path can have a length as small as 1 if the public key from the end-entity certificate is used to establish a trust anchor in the relying party's software. Note that this requirement applies whether the end-entity certificate is self-signed or not. EJN From Massimiliano.Pala@Dartmouth.edu Tue Apr 26 22:39:13 2011 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 9C6DEE06AD for ; Tue, 26 Apr 2011 22:39:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j78zt94HjJi3 for ; Tue, 26 Apr 2011 22:39:13 -0700 (PDT) Received: from mailhub1.dartmouth.edu (mailhub1.dartmouth.edu [129.170.16.122]) by ietfa.amsl.com (Postfix) with ESMTP id DE8D6E06A2 for ; Tue, 26 Apr 2011 22:39:12 -0700 (PDT) Received: from newblitzen.Dartmouth.EDU (newblitzen.Dartmouth.EDU [129.170.208.36]) by mailhub1.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id p3R4lLfd024586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Apr 2011 01:39:05 -0400 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from c-66-31-140-39.hsd1.nh.comcast.net [66.31.140.39] by newblitzen.Dartmouth.EDU (Mac) via SMTP for pkix@ietf.org id <190727433>; 27 Apr 2011 01:39:05 -0400 Message-ID: <4DB7AC31.4050705@Dartmouth.edu> Date: Wed, 27 Apr 2011 01:40:01 -0400 From: Massimiliano Pala Organization: Dartmouth College / OpenCA Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: pkix@ietf.org References: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> In-Reply-To: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000702090400060908030201" X-MailScanner: Found to be clean by mailhub1.dartmouth.edu X-MailScanner-SpamCheck: spam, SpamAssassin (not cached, score=8.814, required 1, autolearn=spam, AWL -2.60, BAYES_50 0.80, BLITZ_DISCLAIMER 0.05, FH_HELO_EQ_D_D_D_D 3.18, HELO_DYNAMIC_IPADDR 1.95, RCVD_IN_PBL 3.33, RCVD_IN_RP_RNBL 1.31, RCVD_IN_SORBS_DUL 0.00, RDNS_NONE 0.79) X-MailScanner-SpamScore: ssssssss X-MailScanner-From: massimiliano.pala@dartmouth.edu Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 27 Apr 2011 05:39:13 -0000 This is a cryptographically signed message in MIME format. --------------ms000702090400060908030201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi List, when I posted the message I was trying to draw the attention to the fact that, even if in theory, email is not a concern for privacy, in practice CAs treat this field as if there were privacy issues. The current situation is that CAs don't publish certs in public directories. A simple solution would be to get rid of the email field. The problem is that many (if not all) email programs rely on that field in the certificate for certificate lookup (especially for sending encrypted emails). Also, by putting the email field in the cert, it allows CAs to "declare" which email addresses have been verified (for example, look at free email certs providers) by them (verifiable name space). The solution of having a somehow-hashed version of the email address in the certificate would solve this issue-non-issue and allow CAs to publish certs more easily without requiring to rely on any TTP and/or changing the whole S/MIME standards. Maybe we could agree on an extension in the certificate that implements the hashed version of the email and we could call it something like verifiedEmailAddresses. Just a thought: I am trying to propose a solution targeted to solve a specific issue we face today in the real world. I would like to hear the opinion of someone who works/manages internet- oriented CAs/PKIs (if there are on this list...) Cheers, Max --------------ms000702090400060908030201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6DCC BHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkW A2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTEw MDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNlZHUxGTAX BgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3Np bWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVYpWfvkEzS HWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN/4cqgCPY yjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHaOwk9SUc7 rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2cED6ioDn 2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn5h9WBlxK 7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1UdDwEB/wQE AwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C/DA3BgNV HR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNhLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2ltaWxpYW5v LlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYeTaN3EjAN BgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2KJs8xm93d yTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBcTDec5NWe 7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9Fa6HDxEM Xg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt/ZD6rJkE jYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQke9fCfwsx zghYIDCCBHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT 8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAY BgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgx MB4XDTEwMDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNl ZHUxGTAXBgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFE YXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMT EU1hc3NpbWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVY pWfvkEzSHWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN /4cqgCPYyjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHa Owk9SUc7rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2 cED6ioDn2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn 5h9WBlxK7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1Ud DwEB/wQEAwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C /DA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNh LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2lt aWxpYW5vLlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYe TaN3EjANBgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2K Js8xm93dyTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBc TDec5NWe7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9 Fa6HDxEMXg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt /ZD6rJkEjYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQk e9fCfwsxzghYIDGCA5owggOWAgEBMIGCMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJ kiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGgg Q29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQIHAIkS6kMSADAJBgUrDgMC GgUAoIIB7DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0 MjcwNTQwMDFaMCMGCSqGSIb3DQEJBDEWBBSYS1p4ZGCss1oOHyKFqP55/JiJtTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZMGCSsGAQQBgjcQBDGBhTCB gjB3MRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZImiZPyLGQBGRYJZGFydG1vdXRoMQsw CQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENvbGxlZ2UxHDAaBgNVBAMTE0RhcnRt b3V0aCBDZXJ0QXV0aDECBwCJEupDEgAwgZUGCyqGSIb3DQEJEAILMYGFoIGCMHcxEzARBgoJ kiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVT MRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRB dXRoMQIHAIkS6kMSADANBgkqhkiG9w0BAQEFAASCAQBubB+p9U4239b3Mdb4XKiRdOTjAxwi a2P2PCp1DKZlzbzDBTwK9aBEcIF+zKi/q+DAYzekSuYuZaD7qVcQSNNa80QsNGU989NhEC+r fKfpORqmUPUVeIE9U2PS0A3P/ijrNfuHvJTPiCrdEr9hX9RHSTOEmy5tQqSBualRzl7C2KnK 4ZCaJL84cMDBPOecr9VH9QGdZvLUqBfgyR1D53MIDgn24etv7pu4zBUOTcYpDRaozYb8HlO4 qs2SSK+3CfTCreL6oIJQpfzTIycFan9cklxTSiNifzZoGNW/s6ZuRuSEOXae1CWKXns1IQBB kUZgIiuhC5knEkPaRrXhnDoOAAAAAAAA --------------ms000702090400060908030201-- From stephen.farrell@cs.tcd.ie Wed Apr 27 01:24:20 2011 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 D237AE06A1 for ; Wed, 27 Apr 2011 01:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=1.651, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7GitGY3QGSC for ; Wed, 27 Apr 2011 01:24:10 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id D7674E06C3 for ; Wed, 27 Apr 2011 01:24:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 717BF171C1B; Wed, 27 Apr 2011 09:24:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1303892642; bh=iqAxx gQZ5uH24JWB0qTxShOR8fdSQhZHwKYJ05jhR4s=; b=2MSGxgbvosYiaBfn3LNPw 2SwOITqCZkWTtXBxBpeIZnbWhgoqnbDsoSJeg5+wp/Cirkh2RouA3y61gCCVv+TV wAkichujnjnGYVDv6JWE1HBo2Huf6GFxdJmHb2cIOv/lV6RR7yblzhJNQnKrrszi Dy+6lk3keIAHkizWde4+ZPrCRi33Qe6rDeFOpyta+9Xqxieu9qfRMq/OOpfhxHZF C5Q80TiC572mQJyGahPnbfGHktuVeP+xuM1r8SKGG8ljVALAK6nhkkMXRp46Ygzq 6+JL/eRhTgC4uLhqhimjHLHWq5qOzlVSmciAQsb/ItcLlkDuGw3fZKwz+myWgB2P A== 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 HHI-wBFiXpRo; Wed, 27 Apr 2011 09:24:02 +0100 (IST) Received: from [10.52.37.234] (mobileinternet4.o2.ie [62.40.32.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 40218171C17; Wed, 27 Apr 2011 09:24:00 +0100 (IST) References: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> <4DB7AC31.4050705@Dartmouth.edu> In-Reply-To: <4DB7AC31.4050705@Dartmouth.edu> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <071E33A9-30F7-4E43-AE46-89C4A7D22219@cs.tcd.ie> X-Mailer: iPhone Mail (8G4) From: Stephen Farrell Date: Wed, 27 Apr 2011 09:23:53 +0100 To: Massimiliano Pala Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 27 Apr 2011 08:24:20 -0000 On 27 Apr 2011, at 06:40, Massimiliano Pala wrote: > The current situation is that CAs don't publish certs in public > directories. >=20 > A simple solution would be to get rid of the email field. What evidence do you have a) that the first thing is a real problem and b) t= hat the second thing is even a solution at all? I think you're maybe making a bunch of unwarranted assumptions, when you go a= head and discuss mechanism here. S. > The problem > is that many (if not all) email programs rely on that field in the > certificate for certificate lookup (especially for sending encrypted > emails). Also, by putting the email field in the cert, it allows CAs > to "declare" which email addresses have been verified (for example, > look at free email certs providers) by them (verifiable name space). >=20 > The solution of having a somehow-hashed version of the email address > in the certificate would solve this issue-non-issue and allow CAs to > publish certs more easily without requiring to rely on any TTP and/or > changing the whole S/MIME standards. >=20 > Maybe we could agree on an extension in the certificate that implements > the hashed version of the email and we could call it something like > verifiedEmailAddresses. >=20 > Just a thought: I am trying to propose a solution targeted to solve a > specific issue we face today in the real world. >=20 > I would like to hear the opinion of someone who works/manages internet- > oriented CAs/PKIs (if there are on this list...) >=20 > Cheers, > Max >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pgut001@login01.cs.auckland.ac.nz Wed Apr 27 01:34:58 2011 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 88B40E06C1 for ; Wed, 27 Apr 2011 01:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsYJvi21awZU for ; Wed, 27 Apr 2011 01:34:54 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 662FEE06E7 for ; Wed, 27 Apr 2011 01:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1303893294; x=1335429294; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20Massimiliano.Pala@Dartmouth.edu,=20pkix@ietf.org |Subject:=20Re:=20[pkix]=20Email=20in=20Certs=20and=20Pri vacy=20Concerns|In-Reply-To:=20<4DB7AC31.4050705@Dartmout h.edu>|Message-Id:=20|Date:=20Wed,=2027=20Apr=202011=2020:34:49=20+1 200; bh=/czas2t4WY5evUK9BUyRVjHXcIP1I6w3WmmHZDeYQF4=; b=ZWTRiyCUKwLKoWKG1h2wmd0EUY39CV/u/pVmeU52doWSjykldImftmzl a9T38jkcpI3SmboXJ+hV+T/1s63uZX3obIkyyo6DIlU7ksqvkxN1dKRQw KL5+9OPDOUuGStC9PwTQor9pkSulM3/YpInhWbSgAAsE0ilxMuCY9BWj9 M=; X-IronPort-AV: E=Sophos;i="4.64,273,1301832000"; d="scan'208";a="58366412" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Apr 2011 20:34:49 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QF0Cv-0004Lg-Ii; Wed, 27 Apr 2011 20:34:49 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QF0Cv-0003Kc-OS; Wed, 27 Apr 2011 20:34:49 +1200 From: Peter Gutmann To: Massimiliano.Pala@Dartmouth.edu, pkix@ietf.org In-Reply-To: <4DB7AC31.4050705@Dartmouth.edu> Message-Id: Date: Wed, 27 Apr 2011 20:34:49 +1200 Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 27 Apr 2011 08:34:58 -0000 Massimiliano Pala writes: >The current situation is that CAs don't publish certs in public directories. This is because there aren't any public directories to publish them in, not because of any privacy concerns. >A simple solution would be to get rid of the email field. We should also add a pink elephant extension to certs, maybe that's another reason why CAs aren't publishing them in directories. >I am trying to propose a solution targeted to solve a specific issue we face >today in the real world. The issue we face is that there isn't anywhere to publish certs. No amount of email address hashing or pink elephants is going to fix that. Peter. From DPKemp@missi.ncsc.mil Wed Apr 27 05:31:00 2011 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 3B188E0739 for ; Wed, 27 Apr 2011 05:31:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZwxP1K4TlfD for ; Wed, 27 Apr 2011 05:30:59 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 933B3E0727 for ; Wed, 27 Apr 2011 05:30:59 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p3RCUw2U065495 for ; Wed, 27 Apr 2011 08:30:58 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 08:30:39 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 27 Apr 2011 08:22:26 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwEtgxHB+onycxgTkuWmOcGYgOpogAHS2Gw References: <4DB7AC31.4050705@Dartmouth.edu> From: "Kemp, David P." To: X-OriginalArrivalTime: 27 Apr 2011 12:30:39.0500 (UTC) FILETIME=[EAC20CC0:01CC04D6] Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 27 Apr 2011 12:31:00 -0000 For some reason Flickr hasn't found a way to monetize cert storage, Google /Bing have not found a way to monetize cert searches, and Facebook customers haven't asked for better login security. Unfortunately, despite the inconvenience resulting from the Playstation breach, users still aren't likely to demand it. But if Yahoo offered "generate cert" and "use existing cert" buttons beside the "pick a password" strength meter on the registration page, users might find PKI more convenient than the alternative. If Max wants certs published, he should be lobbying social media to make it easy, not PKIX to make it harder. Dave -----Original Message----- From: Peter Gutmann > > The issue we face is that there isn't anywhere to > publish certs. No amount of email address hashing or > pink elephants is going to fix that. > > Peter. From anders.rundgren@telia.com Wed Apr 27 06:29:24 2011 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 62B55E0768 for ; Wed, 27 Apr 2011 06:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m4ylcPVwMhW for ; Wed, 27 Apr 2011 06:29:20 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id B857EE0771 for ; Wed, 27 Apr 2011 06:29:17 -0700 (PDT) Received: from [192.168.3.130] (193.12.106.2) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA0184C0FB; Wed, 27 Apr 2011 15:29:14 +0200 Message-ID: <4DB81A37.1010001@telia.com> Date: Wed, 27 Apr 2011 15:29:27 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Kemp, David P." References: <4DB7AC31.4050705@Dartmouth.edu> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 27 Apr 2011 13:29:24 -0000 On 2011-04-27 14:22, Kemp, David P. wrote: > For some reason Flickr hasn't found a way to monetize cert storage, > Google /Bing have not found a way to monetize cert searches, and > Facebook customers haven't asked for better login security. > Unfortunately, despite the inconvenience resulting from the Playstation > breach, users still aren't likely to demand it. > > But if Yahoo offered "generate cert" and "use existing cert" buttons > beside the "pick a password" strength meter on the registration page, > users might find PKI more convenient than the alternative. > > If Max wants certs published, he should be lobbying social media to make > it easy, not PKIX to make it harder. Agreed. Why social media won't buy into this is because there is no working "generate cert" client solution worth mentioning. -- Anders > Dave > > > > -----Original Message----- > From: Peter Gutmann >> >> The issue we face is that there isn't anywhere to >> publish certs. No amount of email address hashing or >> pink elephants is going to fix that. >> >> Peter. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From Massimiliano.Pala@Dartmouth.edu Wed Apr 27 08:03:18 2011 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 78E5AE07F2 for ; Wed, 27 Apr 2011 08:03:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3PbFpOKKHDW for ; Wed, 27 Apr 2011 08:03:17 -0700 (PDT) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by ietfa.amsl.com (Postfix) with ESMTP id B1401E07DA for ; Wed, 27 Apr 2011 08:03:17 -0700 (PDT) Received: from newblitzen.Dartmouth.EDU (newblitzen.Dartmouth.EDU [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id p3RF2mJL009371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 11:03:05 -0400 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from dhcp-212-217.cs.dartmouth.edu [129.170.212.217] by newblitzen.Dartmouth.EDU (Mac) via SMTP for id <190753554>; 27 Apr 2011 11:03:05 -0400 Message-ID: <4DB83061.1010602@Dartmouth.edu> Date: Wed, 27 Apr 2011 11:04:01 -0400 From: Massimiliano Pala Organization: Dartmouth College / OpenCA Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Stephen Farrell References: <068C49DB-6680-4B9B-9223-9A33AC9CB78E@mitre.org> <4DB7AC31.4050705@Dartmouth.edu> <071E33A9-30F7-4E43-AE46-89C4A7D22219@cs.tcd.ie> In-Reply-To: <071E33A9-30F7-4E43-AE46-89C4A7D22219@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020504060806000707030003" X-MailScanner: Found to be clean by mailhub2.dartmouth.edu X-MailScanner-From: massimiliano.pala@dartmouth.edu Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 27 Apr 2011 15:03:18 -0000 This is a cryptographically signed message in MIME format. --------------ms020504060806000707030003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/27/2011 04:23 AM, Stephen Farrell wrote: [...] > What evidence do you have a) that the first thing is a real problem and= b) that the > second thing is even a solution at all? As a PKI practitioner and researcher, I face the certificate availability= problem all the time. This issue is quite a problem when it comes to the email environment where, as you know, email encryption is still hard to achieve. I was just trying to point out a problem that many PKI operators (e.g., universities or private companies) have told me about. Unfortunately I don't have statistics on that. I might just thought I would point out the issue in the list and see if there was anybody who was facing the same issues. It seems not, so I think there is no point in continuing the thread in this list. Just last thought, (a) also other people pointed out that the spam/email collecting is potentially an issue, and, just to be clear (b) I never sai= d that what I proposed *is the solution* but a 2-mins idea that could start= a discussion about the issue. Cheers, Max --------------ms020504060806000707030003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6DCC BHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkW A2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTEw MDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNlZHUxGTAX BgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3Np bWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVYpWfvkEzS HWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN/4cqgCPY yjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHaOwk9SUc7 rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2cED6ioDn 2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn5h9WBlxK 7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1UdDwEB/wQE AwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C/DA3BgNV HR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNhLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2ltaWxpYW5v LlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYeTaN3EjAN BgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2KJs8xm93d yTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBcTDec5NWe 7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9Fa6HDxEM Xg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt/ZD6rJkE jYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQke9fCfwsx zghYIDCCBHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT 8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAY BgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgx MB4XDTEwMDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNl ZHUxGTAXBgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFE YXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMT EU1hc3NpbWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVY pWfvkEzSHWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN /4cqgCPYyjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHa Owk9SUc7rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2 cED6ioDn2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn 5h9WBlxK7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1Ud DwEB/wQEAwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C /DA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNh LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2lt aWxpYW5vLlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYe TaN3EjANBgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2K Js8xm93dyTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBc TDec5NWe7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9 Fa6HDxEMXg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt /ZD6rJkEjYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQk e9fCfwsxzghYIDGCA5owggOWAgEBMIGCMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJ kiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGgg Q29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQIHAIkS6kMSADAJBgUrDgMC GgUAoIIB7DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0 MjcxNTA0MDFaMCMGCSqGSIb3DQEJBDEWBBS3f6C+5+WD3IoPcl9HCcJA4A9GLjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZMGCSsGAQQBgjcQBDGBhTCB gjB3MRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZImiZPyLGQBGRYJZGFydG1vdXRoMQsw CQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENvbGxlZ2UxHDAaBgNVBAMTE0RhcnRt b3V0aCBDZXJ0QXV0aDECBwCJEupDEgAwgZUGCyqGSIb3DQEJEAILMYGFoIGCMHcxEzARBgoJ kiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVT MRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRB dXRoMQIHAIkS6kMSADANBgkqhkiG9w0BAQEFAASCAQAoi3u9N4qtITmIhkjI3/D07Mh42VVf rc6GZhjFAX8Sfr5lISTOaxuXlOtzXp2B8vHvV1c+8kMiX6G3r+dHBzofDJeaMayIp7BSMsNN 5u6Xvt6TkRilybwbUi9pR3LX1ofgW7gcgglen5Op3TOpX2pkHKcJoNAecO1HWBVZMGFhiGNj BAxNWpjXu/t373RaxBmq4l5Nad1/I9i4zcvKIwVgE8Ut/CXfgPz+5xez4He0Z3Co8ptNPYeL wbFyvUbdtIeBrEjfV5tYkOQBBUbF600laGD7g0Z6GNS2diq5h0X0UsQRbfMACfZsNHBHJKfh 57lnBNPjCU14AYwd0Z0pIw2kAAAAAAAA --------------ms020504060806000707030003-- From Massimiliano.Pala@Dartmouth.edu Wed Apr 27 08:05:44 2011 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 074E0E073B for ; Wed, 27 Apr 2011 08:05:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G76nriKEGjWd for ; Wed, 27 Apr 2011 08:05:43 -0700 (PDT) Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5F766E06EC for ; Wed, 27 Apr 2011 08:05:43 -0700 (PDT) Received: from newblitzen.Dartmouth.EDU (newblitzen.Dartmouth.EDU [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id p3RF2mJr009371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 11:05:30 -0400 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from dhcp-212-217.cs.dartmouth.edu [129.170.212.217] by newblitzen.Dartmouth.EDU (Mac) via SMTP for id <190753833>; 27 Apr 2011 11:05:30 -0400 Message-ID: <4DB830F2.90206@Dartmouth.edu> Date: Wed, 27 Apr 2011 11:06:26 -0400 From: Massimiliano Pala Organization: Dartmouth College / OpenCA Labs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050102050407010007080506" X-MailScanner: Found to be clean by mailhub2.dartmouth.edu X-MailScanner-From: massimiliano.pala@dartmouth.edu Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 27 Apr 2011 15:05:44 -0000 This is a cryptographically signed message in MIME format. --------------ms050102050407010007080506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 04/27/2011 04:34 AM, Peter Gutmann wrote: > Massimiliano Pala writes: > >> The current situation is that CAs don't publish certs in public direct= ories. > > This is because there aren't any public directories to publish them in,= not because of > any privacy concerns. I might disagree with that. There are many organizations that have public= ly accessible directories. [...] > We should also add a pink elephant extension to certs, maybe that's ano= ther reason why > CAs aren't publishing them in directories. [...] > The issue we face is that there isn't anywhere to publish certs. No am= ount of email > address hashing or pink elephants is going to fix that. Although I do really like pink elephants... I agree that's not a solution= =2E Thanks for the feedback anyway. Cheers, Max --------------ms050102050407010007080506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6DCC BHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkW A2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTEw MDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNlZHUxGTAX BgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3Np bWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVYpWfvkEzS HWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN/4cqgCPY yjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHaOwk9SUc7 rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2cED6ioDn 2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn5h9WBlxK 7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1UdDwEB/wQE AwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C/DA3BgNV HR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNhLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2ltaWxpYW5v LlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYeTaN3EjAN BgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2KJs8xm93d yTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBcTDec5NWe 7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9Fa6HDxEM Xg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt/ZD6rJkE jYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQke9fCfwsx zghYIDCCBHAwggNYoAMCAQICBwCJEupDEgAwDQYJKoZIhvcNAQEFBQAwdzETMBEGCgmSJomT 8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAY BgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgx MB4XDTEwMDQwODE1MjIzOVoXDTEyMDQwODE1MjIzOVowgZExEzARBgoJkiaJk/IsZAEZEwNl ZHUxGTAXBgoJkiaJk/IsZAEZEwlkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFE YXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixkAQETCjEyMjU2MDI5NDcxGjAYBgNVBAMT EU1hc3NpbWlsaWFubyBQYWxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApCVY pWfvkEzSHWz8vHDqP4tVKvahbPwJgBsv9uJqNXdbbCFrBc3Ag/+iTNKJA/kjv+1qkoJjKErN /4cqgCPYyjBRkQLjXMUg7TLMJj2M5kI2y3uSJ4ORdOK1oJ50s2GZvMitHzqAbCpFroBH1sHa Owk9SUc7rzM9fdKaFWLC6rlEgtRsvsRqv0h9RGuU7RQNWeGuwYQ3YewdweWME6WgCZ3e9gL2 cED6ioDn2Kyt98h845r/7h7QqkM5C93wCi1rpWPXPbvMziHYQftB6+5pTuDXSqJuIYwpazNn 5h9WBlxK7KVnuUNE/ikXJkDQSj3KzweKf18BC/fHhf/m1OA09wIDAQABo4HlMIHiMA4GA1Ud DwEB/wQEAwIF4DAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR4Gz4zw2xhltHUEZG1YRiCjW9C /DA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvY29sbGVnZWNh LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwKgYDVR0RBCMwIYEfTWFzc2lt aWxpYW5vLlBhbGFAREFSVE1PVVRILkVEVTAfBgNVHSMEGDAWgBQ/wNbHp08Afu8GmWdsvJYe TaN3EjANBgkqhkiG9w0BAQUFAAOCAQEAXfSBGHQ5HS/tbeF6RsclgQfIlVhgy/QtJeQ1GU2K Js8xm93dyTDmUjxQGKGUwnuLpCNjIf/m1GZwXVsTAoKcFjviNx04Owi1AHjbwGMC7QVVTnBc TDec5NWe7UfDvPspbeAe0hG69zY4Wjua8MTcVoYVkA9dSLR+OnVgJGNNualMcXFG6kYqYnn9 Fa6HDxEMXg/e5+XsWX7kaSad6C6XNqDcDpER7yEUvccir+M0cllfn6HKKfLrlUOXqNPV4ztt /ZD6rJkEjYjitEP9yi6pd+ytcXs1X4+QcWw8hr39pLL01laKETcdDf4PP8LcnY2+PihraCQk e9fCfwsxzghYIDGCA5owggOWAgEBMIGCMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJ kiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGgg Q29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQIHAIkS6kMSADAJBgUrDgMC GgUAoIIB7DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0 MjcxNTA2MjZaMCMGCSqGSIb3DQEJBDEWBBRXDH7HTGv+06b7gr+P3RKMDBeiUTBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZMGCSsGAQQBgjcQBDGBhTCB gjB3MRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZImiZPyLGQBGRYJZGFydG1vdXRoMQsw CQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENvbGxlZ2UxHDAaBgNVBAMTE0RhcnRt b3V0aCBDZXJ0QXV0aDECBwCJEupDEgAwgZUGCyqGSIb3DQEJEAILMYGFoIGCMHcxEzARBgoJ kiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVT MRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRB dXRoMQIHAIkS6kMSADANBgkqhkiG9w0BAQEFAASCAQA7tnCM0CjK3XsZJajiuUa9bUivAyXH nWpgXKa3IVLQ0zJOfIbCzmVfuqRKzNI0sj23JnRXOmlexhHlCJWBq9CKm+NLWW6J1oCTx8ts 85F1/za+0cPufGgO9G3uMR8GEK4ekP3XPRKiSMGlo6Tgai7O/mVWYqR2B2oPIAUgKizStCop tX5IQepJMV65pAqDccwpRbO09YaWWmCLO18fGvD3Iod8MGa9C5QE0wMZj4iEfKgG1WE1l+8m sBc1xL9VEZEjC+rgUpLsm7uPMX0V/TYGxemf4FlZC9NtGmn9NUhDs98L+PW48yerv/IDdbV9 U9q2fsUeFmNU3/VXSjOocBcvAAAAAAAA --------------ms050102050407010007080506-- From swilson@lockstep.com.au Wed Apr 27 10:50:25 2011 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 E922AE0822 for ; Wed, 27 Apr 2011 10:50:25 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4Xo-oHdOQIF for ; Wed, 27 Apr 2011 10:50:24 -0700 (PDT) Received: from smtp162.iad.emailsrvr.com (smtp162.iad.emailsrvr.com [207.97.245.162]) by ietfa.amsl.com (Postfix) with ESMTP id 5E480E076E for ; Wed, 27 Apr 2011 10:50:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id D6E81A856E for ; Wed, 27 Apr 2011 13:50:23 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp26.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 8A58AA8634 for ; Wed, 27 Apr 2011 13:50:22 -0400 (EDT) Message-ID: <4DB85752.3030401@lockstep.com.au> Date: Thu, 28 Apr 2011 03:50:10 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080300040402060202050403" Subject: Re: [pkix] Email in Certs and Privacy Concerns X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 17:50:26 -0000 This is a multi-part message in MIME format. --------------080300040402060202050403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 27/04/2011 6:34 PM, Peter Gutmann wrote: > Massimiliano Pala writes: >> The current situation is that CAs don't publish certs in public directories. > This is because there aren't any public directories to publish them in, not > because of any privacy concerns. I disagree, and I am surprised that Max is not getting more traction on the list for this issue. I have plenty of clients in Australia building enterprise PKIs who are very reluctant to publish certificates and CRLs on any publicly accessible directory. They fear the certs will be trawled by spammers, and they recognise CRLs are private because they often contain personal information suggestive of employment matters like implied reasons for terminating employment. In closed communities where the certificates are typically consumed by special purpose applications, an access-controlled directory is usually preferable. This is the *general* case that standards bodies should consider. As I have tried to stress previously, the open public e-mail oriented PKI is a *special* case, and not especially interesting based on its miserable track record in the market. Cheers, Steve Wilson Lockstep http://lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy.Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. --------------080300040402060202050403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 27/04/2011 6:34 PM, Peter Gutmann wrote: 
Massimiliano Pala <Massimiliano.Pala@Dartmouth.edu> writes:

The current situation is that CAs don't publish certs in public directories.

This is because there aren't any public directories to publish them in, not
because of any privacy concerns.
I disagree, and I am surprised that Max is not getting more traction on the list for this issue.  I have plenty of clients in Australia building enterprise PKIs who are very reluctant to publish certificates and CRLs on any publicly accessible directory.  They fear the certs will be trawled by spammers, and they recognise CRLs are private because they often contain personal information suggestive of employment matters like implied reasons for terminating employment.

In closed communities where the certificates are typically consumed by special purpose applications, an access-controlled directory is usually preferable. 

This is the *general* case that standards bodies should consider. As I have tried to stress previously, the open public e-mail oriented PKI is a *special* case, and not especially interesting based on its miserable track record in the market.

Cheers,

Steve Wilson

Lockstep
http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.


--------------080300040402060202050403-- From tmiller@mitre.org Wed Apr 27 17:42:15 2011 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 76D71E08E9 for ; Wed, 27 Apr 2011 17:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMw7WZ0lM1jF for ; Wed, 27 Apr 2011 17:42:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CF1A6E08E8 for ; Wed, 27 Apr 2011 17:42:14 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E2FD21B1EFB; Wed, 27 Apr 2011 20:42:14 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0678121B0653; Wed, 27 Apr 2011 20:42:14 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 27 Apr 2011 20:42:13 -0400 From: "Miller, Timothy J." To: "swilson@lockstep.com.au" Date: Wed, 27 Apr 2011 20:42:12 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwFPR0pt1N37CQlRFycFLauvNbNXw== Message-ID: References: <4DB85752.3030401@lockstep.com.au> In-Reply-To: <4DB85752.3030401@lockstep.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1--773382002"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 28 Apr 2011 00:42:15 -0000 --Apple-Mail-1--773382002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 27, 2011, at 12:50 PM, Stephen Wilson wrote: > I disagree, and I am surprised that Max is not getting more traction = on the list for this issue. I have plenty of clients in Australia = building enterprise PKIs who are very reluctant to publish certificates = and CRLs on any publicly accessible directory. They fear the certs will = be trawled by spammers, and they recognise CRLs are private because they = often contain personal information suggestive of employment matters like = implied reasons for terminating employment. Yet they'll use those same email addresses to communicate with outside = partners--they'll email anyone at all, actually--and use mailing lists, = forums, or websites that require email registration. All of which can = be trawled by spammers (or even *sold* to spammers for profit). You'll = pardon me if I'm unsympathetic. And since reason codes are optional in CRLs, I fail to see a coherent = objection to publishing CRLs in an accessible location. -- T --Apple-Mail-1--773382002 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjgwMDQyMTJaMCMGCSqGSIb3DQEJBDEWBBQY0Qrl6bl5zL0x+477 3B8CAbxppDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgCuPYJFkAGbtaXsySSe1vylGWOC8pX4G1mxw K8rnq4bWKumzMxGAp5W5zuNf8RucTIQ9X5vkpNDfR93rmakgR59KYKKoIwcWwgCt1WDKXIBiJaKQ St7B+Ad4aOv14nuQl4RFfnBgLt/jO5zTulyJ3jTaGSExa1J+H7Ae7EWr6YqXAAAAAAAA --Apple-Mail-1--773382002-- From DPKemp@missi.ncsc.mil Thu Apr 28 07:31:24 2011 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 7E4D7E071E for ; Thu, 28 Apr 2011 07:31:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8le0wYWjJ2Fc for ; Thu, 28 Apr 2011 07:31:23 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id B0F12E0715 for ; Thu, 28 Apr 2011 07:31:23 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p3SEVLFS000878 for ; Thu, 28 Apr 2011 10:31:21 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 10:31:03 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 28 Apr 2011 10:30:53 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwFPR0pt1N37CQlRFycFLauvNbNXwAb7n0Q References: <4DB85752.3030401@lockstep.com.au> From: "Kemp, David P." To: X-OriginalArrivalTime: 28 Apr 2011 14:31:03.0125 (UTC) FILETIME=[E6C98050:01CC05B0] Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 28 Apr 2011 14:31:24 -0000 There is a qualitative difference between "give me the email addresses of all company employees" and "give me the email address of this employee". You can have a public web server with no access controls, but unless you already have links you can't get to the content without exhaustively searching the URL space. Max, in proposing that emails be hashed in certs, assumed that spammers already can trawl every cert published by the company. Why wouldn't it be better to publish all the certs, but only to someone who already knows what the cert contains. The index must be sparse - if the query is by Issuer / Serial Number you don't want to number the certs from 1 to N, the serial number should be unguessable like a 16 byte random value. Or, if you assume that email addresses are unguessable enough to make hashing useful, then just use email address as the search index without hashing. How could a spammer harvest all the certs without already knowing all the email addresses? In other words, what is the problem these Enterprise PKIs are trying to solve by not publishing certs or CRLs, and why can't it be solved instead by changing how they are published? Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Miller, Timothy J. Sent: Wednesday, April 27, 2011 8:42 PM To: swilson@lockstep.com.au Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns On Apr 27, 2011, at 12:50 PM, Stephen Wilson wrote: > I disagree, and I am surprised that Max is not getting more traction on the list for this issue. I have plenty of clients in Australia building enterprise PKIs who are very reluctant to publish certificates and CRLs on any publicly accessible directory. They fear the certs will be trawled by spammers, and they recognise CRLs are private because they often contain personal information suggestive of employment matters like implied reasons for terminating employment. Yet they'll use those same email addresses to communicate with outside partners--they'll email anyone at all, actually--and use mailing lists, forums, or websites that require email registration. All of which can be trawled by spammers (or even *sold* to spammers for profit). You'll pardon me if I'm unsympathetic. And since reason codes are optional in CRLs, I fail to see a coherent objection to publishing CRLs in an accessible location. -- T From stefan@aaa-sec.com Thu Apr 28 23:53:12 2011 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 6364FE06C9 for ; Thu, 28 Apr 2011 23:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.344 X-Spam-Level: X-Spam-Status: No, score=-101.344 tagged_above=-999 required=5 tests=[AWL=1.905, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms50aXzssHYF for ; Thu, 28 Apr 2011 23:53:11 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8C608E0695 for ; Thu, 28 Apr 2011 23:53:10 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 94AA731640E for ; Fri, 29 Apr 2011 08:53:10 +0200 (CEST) Received: (qmail 66588 invoked from network); 29 Apr 2011 06:53:08 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Apr 2011 06:53:08 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 29 Apr 2011 08:53:03 +0200 From: Stefan Santesson To: Peter Gutmann , , Message-ID: Thread-Topic: [pkix] Email in Certs and Privacy Concerns In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 06:53:12 -0000 On 11-04-27 10:34 AM, "Peter Gutmann" wrote: > >We should also add a pink elephant extension to certs, maybe that's >another >reason why CAs aren't publishing them in directories. This makes me excited... You may be onto something big here! > >>I am trying to propose a solution targeted to solve a specific issue we >>face >>today in the real world. > >The issue we face is that there isn't anywhere to publish certs. No >amount of >email address hashing or pink elephants is going to fix that. WHAT! Pink elephant extensions does not work either.... What a shame. Well, I can make a repository of certs, and I could make it public in minutes. I think that even if we could, we would not do it, because it is backwards and inefficient to let systems lookup end-user certs. It's only applicable to store and forward systems, and even there it is kind of backwards, especially when broadcasting information to a larger group. It obviously only works in tightly managed communities, and for that use-case I don't se a privacy issue. /Stefan From anders.rundgren@telia.com Fri Apr 29 00:36:04 2011 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 18258E0678 for ; Fri, 29 Apr 2011 00:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYtmgvAgr5Wb for ; Fri, 29 Apr 2011 00:36:03 -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 457E0E064B for ; Fri, 29 Apr 2011 00:36:03 -0700 (PDT) Received: from [192.168.0.203] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A101927A68; Fri, 29 Apr 2011 09:35:39 +0200 Message-ID: <4DBA6A5D.3030707@telia.com> Date: Fri, 29 Apr 2011 09:35:57 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 07:36:04 -0000 On 2011-04-29 08:53, Stefan Santesson wrote: > Well, I can make a repository of certs, and I could make it public in > minutes. > I think that even if we could, we would not do it, because it is backwards > and inefficient to let systems lookup end-user certs. It's only applicable > to store and forward systems, and even there it is kind of backwards, > especially when broadcasting information to a larger group. It obviously > only works in tightly managed communities, and for that use-case I don't > se a privacy issue. > IMO the real issue is: What is the alternative to S/MIME? I and some 500M other users depend on Skype which gives end-to-end security as default and have proved to work for non-techies as well. The reliance on a single provider is of course a snag but since the e-mail people screw up e-mail security by downplaying the domain/server-level alternative (which had worked for > 90% of all legitimate use-cases), this is essentially what we got. Anders From stefan@aaa-sec.com Fri Apr 29 01:31:20 2011 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 0C842E0764 for ; Fri, 29 Apr 2011 01:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JepY4PW-bF22 for ; Fri, 29 Apr 2011 01:31:19 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfa.amsl.com (Postfix) with ESMTP id 58B11E0750 for ; Fri, 29 Apr 2011 01:31:18 -0700 (PDT) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BB4E772F9 for ; Fri, 29 Apr 2011 10:31:18 +0200 (CEST) Received: (qmail 89906 invoked from network); 29 Apr 2011 08:31:15 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Apr 2011 08:31:15 -0000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 29 Apr 2011 10:31:08 +0200 From: Stefan Santesson To: Anders Rundgren Message-ID: Thread-Topic: [pkix] Email in Certs and Privacy Concerns In-Reply-To: <4DBA6A5D.3030707@telia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 08:31:20 -0000 On 11-04-29 9:35 AM, "Anders Rundgren" wrote: >IMO the real issue is: What is the alternative to S/MIME? I agree, I think the alternative to S/MIME is more like a complementary way to use S/MIME and that is not to encrypt the mail using the recipient's public key, but to encrypt it with a key that the user can retrieve by some kind of "I authenticate to receive the key" procedure. This would also be a golden opportunity to marry secure e-mail with identity federation techniques for authentication. And the latter has proven to be hugely successful simply because it allows users to live in a "walled garden", but still authenticate to services outside of it. Plasma could be a great step in that direction. /Stefan From pgut001@login01.cs.auckland.ac.nz Fri Apr 29 04:40:12 2011 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 6C1CBE06C0 for ; Fri, 29 Apr 2011 04:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IxQeWKHoLmk for ; Fri, 29 Apr 2011 04:40:08 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 498D7E0659 for ; Fri, 29 Apr 2011 04:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1304077208; x=1335613208; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20stefan@aaa-sec.com |Subject:=20Re:=20[pkix]=20Email=20in=20Certs=20and=20Pri vacy=20Concerns|Cc:=20Massimiliano.Pala@Dartmouth.edu,=20 pgut001@cs.auckland.ac.nz,=0D=0A=20=20=20=20pkix@ietf.org |In-Reply-To:=20<4DBA6A5D.3030707@telia.com>|Message-Id: =20|Date: =20Fri,=2029=20Apr=202011=2023:40:07=20+1200; bh=DH2DPQ70OSmMZqcZjMqZ0J3EFwbxjhWSjpO5sPR0PjE=; b=msbS2VQUKGRsX5dDmoLNB5oaMZH0eaCOwkAe9zaD5cMZGyaALwY81rAj fQ/4G2hf0HXwtopd8hTgFQes5hUjuF0UqPzyObLvZTkD6Xj1hIo7O1eoe BK0X/Omx9Oz3xpDpRoD3jB/MeRP+9wY25ISRaSizo9UO+LeB0kzAIheNi o=; X-IronPort-AV: E=Sophos;i="4.64,287,1301832000"; d="scan'208";a="59057216" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Apr 2011 23:40:07 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QFm3L-0006Au-Ho; Fri, 29 Apr 2011 23:40:07 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QFm3L-0007Wx-FO; Fri, 29 Apr 2011 23:40:07 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, stefan@aaa-sec.com In-Reply-To: <4DBA6A5D.3030707@telia.com> Message-Id: Date: Fri, 29 Apr 2011 23:40:07 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 11:40:12 -0000 Anders Rundgren writes: >IMO the real issue is: What is the alternative to S/MIME? STARTTLS. From a (very informal) survey I did about a year after it was deployed, it was protecting more email in its first year than every store-and- forward email encryption protocol combined after a decade of use. Peter. From pgut001@login01.cs.auckland.ac.nz Fri Apr 29 05:31:46 2011 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 2BBB3E0659 for ; Fri, 29 Apr 2011 05:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb71qiQMGESh for ; Fri, 29 Apr 2011 05:31:42 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id DCF26E064B for ; Fri, 29 Apr 2011 05:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1304080302; x=1335616302; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20swilson@lockstep.com.au|Subject:=20Re:=20[pkix]=20 Email=20in=20Certs=20and=20Privacy=20Concerns|Cc:=20pkix@ ietf.org|In-Reply-To:=20<4DB85752.3030401@lockstep.com.au >|Message-Id:=20|Date:=20Sat,=2030=20Apr=202011=2000:31:41=20+1200; bh=SgPkSSWqQEdgnkY/fpcdcOEBfsGKFyDvR1JyOqajq2w=; b=Ms/7qoZ7r4zAAs5/dOTR4D2CiQ0zsGeTpa0fYq0VusNIxpKoWLhLdzIW eqVXgQwmy/v7TORHYTCQ470i21/bRsx813R6g5P2vI8peQUesF/FjikE/ PQDU+wXpdE4lxH31J3Cq5aoXn9gMB75RG9pZOY/kop+giJqAH75TS2dpp 8=; X-IronPort-AV: E=Sophos;i="4.64,287,1301832000"; d="scan'208";a="59080999" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Apr 2011 00:31:41 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QFmrF-0007eC-GJ; Sat, 30 Apr 2011 00:31:41 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QFmrF-0001H7-0Q; Sat, 30 Apr 2011 00:31:41 +1200 From: Peter Gutmann To: swilson@lockstep.com.au In-Reply-To: <4DB85752.3030401@lockstep.com.au> Message-Id: Date: Sat, 30 Apr 2011 00:31:41 +1200 Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 12:31:46 -0000 Stephen Wilson writes: >I have plenty of clients in Australia building enterprise PKIs who are very >reluctant to publish certificates and CRLs on any publicly accessible >directory. They fear the certs will be trawled by spammers, and they >recognise CRLs are private because they often contain personal information >suggestive of employment matters like implied reasons for terminating >employment. So what you're facing here is a user perception problem rather than a real risk, from people who (I'm guessing) have very little to no of idea how the spam industry works. We know from anti-spam researchers that spam brokers don't even bother de-obfuscating the common 'name AT domain' address-hiding used in public web sites, blog posts, and so on, because they already have large databases of high-quality verified email account names and related metadata from vendor compromises (think events like Epsilon, or more generally do a search for "database compromised email address", which currently returns 10M hits). The chances of a spam broker looking around for undocumented certificate databases on the net, figuring out which DAP/LDAP voodoo they need to use to walk the database, extracting the certs, and pulling out the email addresses, is zero given that they don't even feel the need to convert 'AT' to '@' for a free address harvest. So what you have is purely a user perception problem, for which you can tell them that you have multiple levels of security in place to prevent harvesting (running LDAP is enough to scare anyone off, and putting things inside certs will stop the small percentage of truly insane people who do get that far, so that's multiple levels of security). Peter. From anders.rundgren@telia.com Fri Apr 29 05:46:31 2011 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 6BC6FE06CB for ; Fri, 29 Apr 2011 05:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLQvBNYBlYbT for ; Fri, 29 Apr 2011 05:46:31 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id AAF1CE0659 for ; Fri, 29 Apr 2011 05:46:30 -0700 (PDT) Received: from [192.168.0.203] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D65154401365244; Fri, 29 Apr 2011 14:46:21 +0200 Message-ID: <4DBAB32E.4060400@telia.com> Date: Fri, 29 Apr 2011 14:46:38 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 12:46:31 -0000 On 2011-04-29 13:40, Peter Gutmann wrote: >> IMO the real issue is: What is the alternative to S/MIME? > > STARTTLS. From a (very informal) survey I did about a year after it was > deployed, it was protecting more email in its first year than every store-and- > forward email encryption protocol combined after a decade of use. 100% Agreed. The problem as I see it is that STARTTLS and mail clients seem to live in separete worlds. If this had been properly architected you should get a warning "This message will be sent in clear, do you want to send it anyway?" if there was no STARTTLS support in the other end. In addition: - STARTTLS hides the identity of the receiver and sender. - STARTTLS enables efficient black-listing. - STARTTLS is compliant with message content scanning. IMNSHO, current e-mail (non) "security" is the result of major over-selling of S/MIME as the "solution". Anders From tmiller@mitre.org Fri Apr 29 07:43:54 2011 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 9A8B3E0761 for ; Fri, 29 Apr 2011 07:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfWeh3zmxcof for ; Fri, 29 Apr 2011 07:43:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9A030E06BF for ; Fri, 29 Apr 2011 07:43:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E25C621B18F5; Fri, 29 Apr 2011 10:43:49 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DA45321B18EE; Fri, 29 Apr 2011 10:43:49 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 29 Apr 2011 10:43:49 -0400 From: "Miller, Timothy J." To: Anders Rundgren Date: Fri, 29 Apr 2011 10:40:31 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwGe9lnVS2X533fRlm79WhTy9Dzwg== Message-ID: <3A0ACE57-23D6-418A-AFDB-7966F69E2CC1@mitre.org> References: <4DBA6A5D.3030707@telia.com> In-Reply-To: <4DBA6A5D.3030707@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1--636682506"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Stefan Santesson , "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 14:43:54 -0000 --Apple-Mail-1--636682506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Skype and S/MIME aren't comparable. Skype is a single system; S/MIME is = not--every mail system is independent of all others. Skype is also = synchronous (mostly), S/MIME is entirely asynchronous. These are completely different problem domains. -- Tim On Apr 29, 2011, at 2:35 AM, Anders Rundgren wrote: > On 2011-04-29 08:53, Stefan Santesson wrote: > >=20 >> Well, I can make a repository of certs, and I could make it public in >> minutes. >> I think that even if we could, we would not do it, because it is = backwards >> and inefficient to let systems lookup end-user certs. It's only = applicable >> to store and forward systems, and even there it is kind of backwards, >> especially when broadcasting information to a larger group. It = obviously >> only works in tightly managed communities, and for that use-case I = don't >> se a privacy issue. >>=20 >=20 > IMO the real issue is: What is the alternative to S/MIME? >=20 > I and some 500M other users depend on Skype which gives end-to-end > security as default and have proved to work for non-techies as well. >=20 > The reliance on a single provider is of course a snag but > since the e-mail people screw up e-mail security by downplaying > the domain/server-level alternative (which had worked for > 90% > of all legitimate use-cases), this is essentially what we got. >=20 > Anders > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-1--636682506 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjkxNDQwMzJaMCMGCSqGSIb3DQEJBDEWBBQNaql/2LlQKq4CVMbp Tr0BqGZxfTByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgLXZx2AE6o0QAdRmF6cEzksixIkN//cY6++L D1aGIjHF/e/X/rFSuRR9XYCDJ1qX3DQmyjHgI/JeDJJ55LP9sgUSWI6eu9OJ92d9R9MylpMCKhot dYGE/yix9wpUVDVWQ6wXBAWETgPJ/ZKvN4KoBSxFh+HhSSPaVCw/dNnvM3rEAAAAAAAA --Apple-Mail-1--636682506-- From tmiller@mitre.org Fri Apr 29 07:44:12 2011 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 0D1A4E0693 for ; Fri, 29 Apr 2011 07:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDeMvrVBcsGe for ; Fri, 29 Apr 2011 07:44:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 49602E0777 for ; Fri, 29 Apr 2011 07:44:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C7D2D21B18F5; Fri, 29 Apr 2011 10:44:05 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BFF1321B18F4; Fri, 29 Apr 2011 10:44:05 -0400 (EDT) Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 29 Apr 2011 10:44:05 -0400 From: "Miller, Timothy J." To: Peter Gutmann Date: Fri, 29 Apr 2011 10:42:58 -0400 Thread-Topic: [pkix] Email in Certs and Privacy Concerns Thread-Index: AcwGe+MLy4dmfeZ4RGayGWKG4OOTxA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2--636535559"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "stefan@aaa-sec.com" , "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 14:44:12 -0000 --Apple-Mail-2--636535559 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IMHO gateway-signed S/MIME makes more sense. An organization = attestation of "This message came from X" is nearly as good as the = individual's assertion. If you want federation-like capabilities, this is probably as close as = you get. -- T On Apr 29, 2011, at 6:40 AM, Peter Gutmann wrote: > Anders Rundgren writes: >=20 >> IMO the real issue is: What is the alternative to S/MIME? >=20 > STARTTLS. =46rom a (very informal) survey I did about a year after it = was > deployed, it was protecting more email in its first year than every = store-and- > forward email encryption protocol combined after a decade of use. >=20 > Peter. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-2--636535559 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDazCCA2cw ggJPoAMCAQICAkqJMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMTAxMDE5MTk0ODIzWhcNMTIwNDExMTk0ODIzWjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBlBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA0ZsLScP5aEy PlEM8Rhy/ovYqtCz3SjfNfWSXizlMtvi4bvO6mRZKdl3U2LrnB8uBYdWZQbP9saJau3TM9znzUg7 RdDA5NqUKi9RGDpb7qzU1Bl9gs5b6bQ1p3elUlQMfyaH+ExNm45MyTmaicA9XYApaYe3mtCGTJtZ t2b7WwIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUrW+ClcUuy07VoaV/C1t8 rKdzBH4wHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQCw9Jbevz2jhccp2w4I ssslPaZPuxqbb7fvl3znfMYGRRt/AP2e+k1Z1iFEdzMyhCi7aIQkdtrn5VoiZUH2RFu+X7wVntsd dQxzTT1oKg70XCKneH4q9COLRb1FQA0Njj0Tj1H762eB3POGh0xUBw+fvZRTTJNlhuJcmAi5odhw 0RtOpnNJjlYNXdQx7AEqbScyDF/Ra2nlN9TPe0/YqWfz8hFpC/5sdD0DzDU1y9Y1io2qlo3tsx2F UXGzFJ6Vl4VLzTNMEbFjEu53T2pLWAN6diZ3mNNanqph14gy3pEOLQ3Hm2XWVrjtsYcQkXrCch7v Q8RqNYUaPfHUw0/2OAvzMYICVDCCAlACAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTAJBgUrDgMCGgUAoIIBRzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMTA0MjkxNDQyNTlaMCMGCSqGSIb3DQEJBDEWBBQ9TezMDT0ulw8jKgan g2bdMCNy1jByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMV Q2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5 IENBLTECAkqJMHQGCyqGSIb3DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJp bWFyeSBDQS0xAgJKiTANBgkqhkiG9w0BAQEFAASBgFaolS/buWYkfde/NjOYmwRZshNGBp0S11XK IljnBDrrEkMT1u/3izay8Z5P/sMliSCRkR2JKZ+v3js9UfqLi+b8mB7hPxitnNbN1YOrz865n+E6 GSqkw7KHyIXNfFAJ1zHlRnvE9fA9cheRIt4DvG5RUDqcboiqsotR69w31OiXAAAAAAAA --Apple-Mail-2--636535559-- From martijn.list@gmail.com Fri Apr 29 07:45:33 2011 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 22B2BE06BF for ; Fri, 29 Apr 2011 07:45:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSEet1+fu0Uk for ; Fri, 29 Apr 2011 07:45:32 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4FAEE0693 for ; Fri, 29 Apr 2011 07:45:31 -0700 (PDT) Received: by ewy19 with SMTP id 19so1418334ewy.31 for ; Fri, 29 Apr 2011 07:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lBI50oV0AS//YrcGS+ywrAeABMoDsmFKjFBAqS0s74g=; b=QiBXp3Z9yCyu6YAz04rSAFforeRlY0fbrk1AOg+L5+IW6vBGOijOuV7d9U4c3WBS2w 3/8Zfbj/bgB0QOT5xkRwtQT8jojlKAL6sK0JdMc0z56O9YFNJsYgFB5EAAyiHuwVN5Y4 EU95FJQbzbE7Tef+3RiReuLN9RAIQQ2FBagkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Hlat+NJzJGlUjNliUI/yeRRAXxRdF4cBqySyMiMzJfp8rT4gJIQpiCXaDnvUDjOtIG LVc1rrClnQcHQktCP4MAbnFdjaVgJ1HXdotS9jUQo3pB/y1eaTNcySCmKTT5LOPVNlT3 XEK9nCn0D2DGDQJ5FOY2+hnWR0lrbfLzAB1Y0= Received: by 10.213.25.199 with SMTP id a7mr2241815ebc.30.1304088330983; Fri, 29 Apr 2011 07:45:30 -0700 (PDT) Received: from [192.168.178.20] (adsl-225-97.dsl.uva.nl [146.50.225.97]) by mx.google.com with ESMTPS id c14sm761546eeb.4.2011.04.29.07.45.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2011 07:45:30 -0700 (PDT) Message-ID: <4DBACF0D.5040901@gmail.com> Date: Fri, 29 Apr 2011 16:45:33 +0200 From: "martijn.list" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: pkix@ietf.org References: <4DBAB32E.4060400@telia.com> In-Reply-To: <4DBAB32E.4060400@telia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 14:45:33 -0000 On 04/29/2011 02:46 PM, Anders Rundgren wrote: > On 2011-04-29 13:40, Peter Gutmann wrote: > >>> IMO the real issue is: What is the alternative to S/MIME? >> >> STARTTLS. From a (very informal) survey I did about a year after it was >> deployed, it was protecting more email in its first year than every store-and- >> forward email encryption protocol combined after a decade of use. > > 100% Agreed. The problem as I see it is that STARTTLS and mail > clients seem to live in separete worlds. If this had been properly > architected you should get a warning > > "This message will be sent in clear, do you want to send it anyway?" > > if there was no STARTTLS support in the other end. > > In addition: > > - STARTTLS hides the identity of the receiver and sender. > > - STARTTLS enables efficient black-listing. > > - STARTTLS is compliant with message content scanning. Although STARTTLS has it's merits, it's not a real substitute for encrypting the message content with S/MIME or PGP. TLS only protects the channel not the message. You can enforce TLS only for the first SMTP hop, you can only hope that the next hops will use TLS as well but there is absolutely no guarantee. > IMNSHO, current e-mail (non) "security" is the result of major > over-selling of S/MIME as the "solution". Same thing can be said about TLS since it only gives you a false sense of (real) security. Kind regards, Martijn Brinkers -- Djigzo open source email encryption From anders.rundgren@telia.com Fri Apr 29 13:21:58 2011 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 9800FE07A9 for ; Fri, 29 Apr 2011 13:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9JEGpHv6L9b for ; Fri, 29 Apr 2011 13:21:56 -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 71A35E06E7 for ; Fri, 29 Apr 2011 13:21:56 -0700 (PDT) Received: from [192.168.0.203] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6517A101971445; Fri, 29 Apr 2011 22:21:49 +0200 Message-ID: <4DBB1DED.7070801@telia.com> Date: Fri, 29 Apr 2011 22:22:05 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Miller, Timothy J." References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stefan@aaa-sec.com" , "pkix@ietf.org" Subject: Re: [pkix] Email in Certs and Privacy Concerns 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, 29 Apr 2011 20:21:58 -0000 On 2011-04-29 16:42, Miller, Timothy J. wrote: > IMHO gateway-signed S/MIME makes more sense. An organization > attestation of "This message came from X" is nearly as good as > the individual's assertion. I personally advocated such solutions over a decade ago (!) in this very list and essentially everybody thought "server-based security" was an altogether bad idea. Now it is too late to [really] secure e-mail and the S/MIME group has closed. Skype won on "walk-over". Today PKCS #10 is claimed to be the "solution" for PKI provisioning in spite of the fact that: - PKCS #10 only addresses a tiny fraction of the actual process - XML (unlike ASN.1) is natively supported by Java and .NET - End-to-end security provisioning is piece if cake Just another obvious security train-wreck in the workings. Anders > > If you want federation-like capabilities, this is probably as close as you get. > > -- T > > On Apr 29, 2011, at 6:40 AM, Peter Gutmann wrote: > >> Anders Rundgren writes: >> >>> IMO the real issue is: What is the alternative to S/MIME? >> >> STARTTLS. From a (very informal) survey I did about a year after it was >> deployed, it was protecting more email in its first year than every store-and- >> forward email encryption protocol combined after a decade of use. >> >> Peter. >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >