From i-barreira@izenpe.net Mon Jun 3 14:55:21 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4DB21F92E7 for ; Mon, 3 Jun 2013 14:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HujxpRWK4HS for ; Mon, 3 Jun 2013 14:55:06 -0700 (PDT) Received: from correo.euskaltel.es (ektmail2mta2.euskaltel.es [212.55.8.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1572511E8115 for ; Mon, 3 Jun 2013 14:52:10 -0700 (PDT) Received: from ejlp024.ejgv ([194.30.48.247]) by ektmail2mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MNU00GJM7EWDJ20@ektmail2mta2.euskaltel.es> for wpkops@ietf.org; Mon, 03 Jun 2013 23:52:08 +0200 (MEST) Received: from AFE03.ejsarea.net (afe03 [10.200.192.20]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id r53Lq8YU003176; Mon, 03 Jun 2013 23:52:08 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by AFE03.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 03 Jun 2013 23:52:08 +0200 Date: Mon, 03 Jun 2013 23:51:12 +0200 From: i-barreira@izenpe.net In-reply-to: A <65DA4BEA501AFC409DF274CC71ED01A57C679C9F@SOTTEXCH10.corp.ad.entrust.com> To: sharon.boeyen@entrust.com, joelja@bogus.com, bruce.morton@entrust.com, paul.hoffman@vpnc.org, jeremy.rowley@digicert.com Message-id: <763539E260C37C46A0D6B340B5434C3B075366B8@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/mixed; boundary="Boundary_(ID_acUC1WdcePnj7ArvDgjp8A)" Content-class: urn:content-classes:message Thread-topic: [wpkops] Agenda Items for IETF 87 Thread-index: Ac5eFBP+zMDMaky/TkeQ46s/0NZtjAAKU36AAAfo5eD//8rDgIAAICvw//tcZJA= X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <073501ce5e17$0c8effc0$25acff40$@digicert.com> <452C99D20750E74083DBA441FF9323857BF92A9D@SOTTEXCH10.corp.ad.entrust.com> <51A8D80D.4030200@bogus.com> A <65DA4BEA501AFC409DF274CC71ED01A57C679C9F@SOTTEXCH10.corp.ad.entrust.com> X-OriginalArrivalTime: 03 Jun 2013 21:52:08.0073 (UTC) FILETIME=[97F65790:01CE60A4] Cc: wpkops@ietf.org Subject: Re: [wpkops] Agenda Items for IETF 87 X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 21:55:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_acUC1WdcePnj7ArvDgjp8A) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi, Meanwhile I=B4m preparing the document to upload it, here=B4s a word = version for you to check in the meantime. Sorry for doing so late. regards I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. -----Mensaje original----- De: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]=20 Enviado el: viernes, 31 de mayo de 2013 21:11 Para: joel jaeggli; Bruce Morton; Paul Hoffman; = jeremy.rowley@digicert.com CC: wpkops WG; Barreira Iglesias, I=F1igo Asunto: RE: [wpkops] Agenda Items for IETF 87 The WG milestone with respect to the Trust Models draft is that a draft = be adopted as the 1st WG draft in June 2013. In order to accomplish = that, a draft needs to be submitted early next week to give the WG = members time to review, discuss and potentially an updated draft = submitted for WG adoption before the end of June. If you and Inigo have = an updated draft it should be submitted asap. If there are outstanding = issues those could be identified on the mail list and input soliticited = from WG membership.=20 -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf = Of joel jaeggli Sent: Friday, May 31, 2013 1:04 PM To: Bruce Morton; Paul Hoffman; jeremy.rowley@digicert.com Cc: wpkops WG; "I=F1igo Barreira (i-barreira@izenpe.net)" Subject: Re: [wpkops] Agenda Items for IETF 87 On 5/31/13 9:59 AM, Bruce Morton wrote: > I=F1igo and I are working on a draft of the Trust Model document. I am = not sure that we will have time to get it prepared to a state that it = will be able to be published in the appropriate lead time before the = Berlin meeting. > > I will not be able to attend the Berlin meeting, but I=F1igo is seeing = if he can make it. > > I tend to agree with Paul that if the document has not been circulated = and there are no issues raised, then it will be difficult to have agenda = items for a meeting. It is the opinion of your AD that drafts that haven't been circulated = shouldn't be presented. which is why it's worth having this dicussion = now. thanks joel > > Bruce. > > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 > Behalf Of Paul Hoffman > Sent: Friday, May 31, 2013 12:28 PM > To: jeremy.rowley@digicert.com > Cc: wpkops WG > Subject: Re: [wpkops] Agenda Items for IETF 87 > > On May 31, 2013, at 8:53 AM, Jeremy Rowley = wrote: > >> Please email wpkops-chairs@tools.ietf.org with your agenda items for = IETF 87 in Berlin. Also, if you are a document editor, please let us = know whether you are attending the meeting and whether you plan to = present an update. If you are not attending, please provide a status = update on where you are on your project. > The documents were presented at the last IETF meeting in anticipation = of the documents being published. IETF face-to-face meetings are = normally used for discussing issues in the WG documents and presenting = new work, but the WG still has no documents published (and essentially = no discussion on the list). > > Is there really a reason to meet face-to-face at the next meeting? = Will any of the WG documents be published before then? > > And yes, I ask this as a co-editor on one of the planned documents. It = doesn't seem worth writing the documents if there is no real interest in = them. > > --Paul Hoffman > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops --Boundary_(ID_acUC1WdcePnj7ArvDgjp8A) Content-type: application/msword; name="Web PKI Trust Model.doc" Content-transfer-encoding: base64 Content-disposition: attachment; filename="Web PKI Trust Model.doc" Content-description: Web PKI Trust Model.doc 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAeAAAAAAAAAAA EAAAewAAAAEAAAD+////AAAAAHcAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAX8AJBAAA+BK/AAAAAAAAEAAAAAAACAAAnzgAAA4AYmpiagAVABUAAAAAAAAAAAAAAAAAAAAA AAAKDBYAQ1EAAGJ/AABifwAAjzAAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAOolAAAAAAAA6iUAAEgz AAAAAAAASDMAAAAAAABIMwAAAAAAAEgzAAAAAAAASDMAABQAAAAAAAAAAAAAAP////8AAAAAXDMA AAAAAABcMwAAAAAAAFwzAAA4AAAAlDMAADQAAADIMwAALAAAAFwzAAAAAAAAPUgAAB4CAAD0MwAA FgAAAAo0AAAAAAAACjQAAAAAAAAKNAAAAAAAAAo0AAAAAAAAPjUAACIAAABgNQAADAAAAGw1AAAI AAAAvEcAAAIAAAC+RwAAAAAAAL5HAAAAAAAAvkcAAAAAAAC+RwAAAAAAAL5HAAAAAAAAvkcAACQA AABbSgAAsgIAAA1NAADgAAAA4kcAABUAAAAAAAAAAAAAAAAAAAAAAAAASDMAAAAAAAB0NQAAAAAA AAAAAAAAAAAAAAAAAAAAAAA+NQAAAAAAAD41AAAAAAAAdDUAAAAAAAB0NQAAAAAAAOJHAAAAAAAA AAAAAAAAAABIMwAAAAAAAEgzAAAAAAAACjQAAAAAAAAAAAAAAAAAAAo0AAA0AQAA90cAABYAAABO OwAAAAAAAE47AAAAAAAATjsAAAAAAAB0NQAAjgAAAEgzAAAAAAAACjQAAAAAAABIMwAAAAAAAAo0 AAAAAAAAvEcAAAAAAAAAAAAAAAAAAE47AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdDUAAAAAAAC8RwAAAAAAAAAAAAAAAAAATjsAAAAAAABOOwAA igEAAApEAABYAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAykUAAAwAAAAKNAAAAAAAAP////8AAAAAwCmlGO5d zgEAAAAAAAAAAP////8AAAAAAjYAAJoAAABiRQAAIgAAAAAAAAAAAAAAqEcAABQAAAANSAAAMAAA AD1IAAAAAAAAhEUAAEYAAADtTQAAAAAAAJw2AABmAQAA7U0AAEQAAADWRQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADW RQAAbgAAAO1NAAAAAAAAAAAAAAAAAABIMwAAAAAAAERGAABkAQAAdDUAAAAAAAB0NQAAAAAAAE47 AAAAAAAAdDUAAAAAAAB0NQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdDUA AAAAAAB0NQAAAAAAAHQ1AAAAAAAA4kcAAAAAAADiRwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAjgAAEwDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHQ1AAAA AAAAdDUAAAAAAAB0NQAAAAAAAD1IAAAAAAAAdDUAAAAAAAB0NQAAAAAAAHQ1AAAAAAAAdDUAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAO1NAAAAAAAAdDUAAAAAAAB0 NQAAAAAAAHQ1AAAAAAAAdDUAAAAAAAB0NQAAAAAAAHQ1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0NQAAAAAAAHQ1AAAAAAAAdDUA AAAAAADqJQAAJAwAAA4yAAA6AQAABQASAQAACgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRydXN0 IG1vZGVscyBvZiB0aGUgV2ViIFBLSQ1BYnN0cmFjdA1UaGlzIGlzIG9uZSBvZiBhIHNldCBvZiBk b2N1bWVudHMgdG8gZGVmaW5lIHRoZSBvcGVyYXRpb24gb2YgdGhlIFdlYiBQS0kuICBJdCBkZXNj cmliZXMgdGhlIGN1cnJlbnRseSBkZXBsb3llZCBXZWIgUEtJIHRydXN0IG1vZGVsIGFuZCBjb21t b24gdmFyaWFudHMuDVN0YXR1cyBvZiB0aGlzIE1lbW8NVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz dWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5Lg1JbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhl ciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5l dC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBpcyBhdCBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg1JbnRlcm5ldC1EcmFmdHMg YXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50 cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0 cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndv cmsgaW4gcHJvZ3Jlc3MuIg1UaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE9jdG9i ZXIgMjAxMw1Db3B5cmlnaHQgTm90aWNlDUNvcHlyaWdodCAoYykgMjAxMyBJRVRGIFRydXN0IGFu ZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZSBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJp Z2h0cyByZXNlcnZlZC4NVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhl IElFVEYgVHJ1c3QncyBMZWdhbCBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRz IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUg ZGF0ZSBvZiBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVz ZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCBy ZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVu dHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0IGluY2x1ZGUgU2ltcGxpZmllZCBC U0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZiB0aGUgVHJ1c3Qg TGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMgZGVz Y3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg1JbnRyb2R1Y3Rpb24NVGhpcyBk b2N1bWVudCBkZWZpbmVzIHRoZSBXZWIgUEtJIHRydXN0IG1vZGVsIGFzIGl0IGlzIGN1cnJlbnRs eSBpbXBsZW1lbnRlZC4gVGhlIHRydXN0IG1vZGVsIGlzIHRvIHN1cHBvcnQgY29tbXVuaWNhdGlv bnMgYmV0d2VlbiB0aGUgc3Vic2NyaWJlciBhbmQgdGhlIHJlbHlpbmcgcGFydHkuDVRoaXMgZG9j dW1lbnQgZG9lcyBub3QgYWRkcmVzcyBmdXR1cmUgY2hhbmdlcyB0byB0aGUgaW1wbGVtZW50ZWQg dHJ1c3QgbW9kZWwuIA1SZXF1aXJlbWVudHMgTGFuZ2F1Z2UNVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhp cyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5 IFtSRkMyMTE5XS4NRGVmaW5pdGlvbg1UaGUgdXNlIG9mIFBLSSB0ZXJtaW5vbG9neSBpcyBhcyB1 c2VkIGFzIGRlZmluZWQgaW4gUkZDIDUyODAuIE90aGVyIGRlZmluaXRpb25zIGFyZSBkZWZpbmVk IGJlbG93IGZvciBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIGRvY3VtZW50Lg1Sb290IENBIC0gYSBD QSB3aXRoIGEgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUgYW5kIHdob3NlIHB1YmxpYyBrZXkgaXMg aW5jbHVkZWQgaW4gYSByb290IHN0b3JlLg1Sb290IGNlcnRpZmljYXRlIC0gYSBzZWxmLXNpZ25l ZCBjZXJ0aWZpY2F0ZSB0aGF0IGlkZW50aWZpZXMgdGhlIHJvb3QgQ0EuDVJvb3Qgc3RvcmUgLSBh IHNldCBvZiByb290IGNlcnRpZmljYXRlcyB3aGljaCBpcyBlbWJlZGRlZCBpbiBhIGNlcnRpZmlj YXRlLXVzaW5nIGNsaWVudC4NU3Vic2NyaWJlciAtIGEgc3ViamVjdCBvZiBhIGNlcnRpZmljYXRl IHdobyBpcyBpc3N1ZWQgYSBjZXJ0aWZpY2F0ZS4NVHJ1c3Qgc2VydmljZSAtIGEgc2VydmljZSB3 aGljaCBlbmhhbmNlcyB0cnVzdCBhbmQgY29uZmlkZW5jZSBpbiBlbGVjdHJvbmljIHRyYW5zYWN0 aW9ucy4NDXRydXN0IG1vZGVsDUluIHRoZSBXZWIgUEtJIHRydXN0IG1vZGVsLCBhIGNlcnRpZmlj YXRlLXVzaW5nIGNsaWVudCAoZS5nLiwgb3BlcmF0aW5nIHN5c3RlbSBvciBicm93c2VyKSB1c2Vz IGEgcm9vdCBzdG9yZSB0aGF0IGNvbnRhaW5zIG9uZSBvciBtb3JlIHJvb3QgQ0EgcHVibGljIGtl eXMsIGVhY2ggb2Ygd2hpY2ggaXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgYSBDQSBhbmQgbWFuYWdl ZCBpbiBjb25mb3JtYW5jZSB3aXRoIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY3kgYWNjZXB0ZWQgYnkg dGhlIGNlcnRpZmljYXRlLXVzaW5nIGNsaWVudCBzdXBwbGllci4gRWFjaCBzdWNoIHJvb3QgQ0Eg aXNzdWVzIGEgY2VydGlmaWNhdGUgdG8gb25lIG9yIG1vcmUgaXNzdWluZyBDQXMgdGhhdCBhcmUg dW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIHNhbWUgQ0EgZW50aXR5LiBFYWNoIGlzc3VpbmcgQ0Eg YWNjZXB0cyBhbmQgcmVzcG9uZHMgdG8gY2VydGlmaWNhdGUgcmVxdWVzdHMgZnJvbSBvbmUgb3Ig bW9yZSBzdWJzY3JpYmVycyB2aWEgb25lIG9yIG1vcmUgcmVnaXN0cmF0aW9uIGF1dGhvcml0aWVz Lg1UaGUgZm9sbG93aW5nIGdyYXBoaWMgc2hvd3MgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGUgcGFy dGllcyBpbiB0aGUgdHJ1c3QgbW9kZWwuDQENRmlndXJlIDEgliBXZWIgUEtJIHRydXN0IG1vZGVs DVJvb3QgU3RvcmUgUHJvdmlkZXINVGhlIHJvb3Qgc3RvcmUgcHJvdmlkZXIgKGUuZy4gTWljcm9z b2Z0IG9yIE1vemlsbGEpIGRldGVybWluZXMgYSBjZXJ0aWZpY2F0ZSBwb2xpY3kuIFRoZSByb290 IHN0b3JlIHByb3ZpZGVyIHN0b3JlcyBhbmQgbWFuYWdlcyByb290IGNlcnRpZmljYXRlcyBpbiBp dHMgY2VydGlmaWNhdGUtdXNpbmcgY2xpZW50IHRvIHN1cHBvcnQgdGhlIHRydXN0IG1vZGVsLiBU aGUgcm9vdCBzdG9yZSBwcm92aWRlciBkZXRlcm1pbmVzIGhvdyB0cnVzdCB3aWxsIGJlIHZhbGlk YXRlZCBhbmQgcHJvdmlkZXMgYSB0cnVzdCBpbmRpY2F0aW9uIHRocm91Z2ggaXRzIGNlcnRpZmlj YXRlLXVzaW5nIGNsaWVudCB0byB0aGUgcmVseWluZyBwYXJ0aWVzLg1DQSBJbmZyYXN0cnVjdHVy ZQ1DQQ1UaGUgQ0EgaW5mcmFzdHJ1Y3R1cmUgaXMgYSBtYWRlIHVwIG9mIGEgUEtJIGhpZXJhcmNo eS4gVGhlIENBIGVudGl0eSBpc3N1ZXMgb25lIG9yIG1vcmUgc2VsZi1zaWduZWQgY2VydGlmaWNh dGVzLiBUaGUgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUgaXMgY2FsbGVkIGEgcm9vdCBjZXJ0aWZp Y2F0ZSBvZiBhIHJvb3QgQ0EuDVRoZSByb290IENBcyBpc3N1ZSBjZXJ0aWZpY2F0ZXMgZm9yIHN1 Ym9yZGluYXRlIGlzc3VpbmcgQ0FzLiBUaGUgcm9vdCBDQSBtYXkgaGF2ZSBzdWJvcmRpbmF0ZSBp bnRlcm1lZGlhdGUgQ0FzIHRvIG1hbmFnZSBncm91cHMgb2Ygc3Vib3JkaW5hdGUgaXNzdWluZyBD QXMuIFRoZSBDQSBlbnRpdHkgbWFuYWdlcyByb290LCBpbnRlcm1lZGlhdGUgYW5kIGlzc3Vpbmcg Q0FzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgY2VydGlmaWNhdGUgcG9saWN5Lg1UaGUgQ0EgZW50 aXR5IG9wZXJhdGVzIHRoZSBjZXJ0aWZpY2F0ZSBpc3N1YW5jZSBhbmQgbWFuYWdlbWVudCBzeXN0 ZW0gaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY3kuDVJlZ2lzdHJhdGlv biBBdXRob3JpdHkNVGhlIENBIGVudGl0eSBvcGVyYXRlcyBhIHJlZ2lzdHJhdGlvbiBhdXRob3Jp dHkgd2hpY2ggYXV0aGVudGljYXRlcyByZXF1ZXN0cyBmb3IgY2VydGlmaWNhdGVzIGluIGFjY29y ZGFuY2Ugd2l0aCB0aGUgY2VydGlmaWNhdGUgcG9saWN5Lg1DZXJ0aWZpY2F0ZSBTdGF0dXMNRWFj aCBDQSBwcm92aWRlcyBjZXJ0aWZpY2F0ZSBzdGF0dXMgaW4gdGhlIGZvcm0gb2YgYSBjZXJ0aWZp Y2F0ZSByZXZvY2F0aW9uIGxpc3QgKENSTCkgYW5kL29yIGFuIG9ubGluZSBjZXJ0aWZpY2F0ZSBz dGF0dXMgcHJvdG9jb2wgKE9DU1ApIHJlc3BvbnNlLiBVcGRhdGVzIGFuZCB2YWxpZGl0eSBwZXJp b2RzIG9mIHRoZSBjZXJ0aWZpY2F0ZSBzdGF0dXMgYXJlIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUg Y2VydGlmaWNhdGUgcG9saWN5Lg1UaGUgbG9jYXRpb24gb2YgdGhlIENSTCBvciB0aGUgT0NTUCBy ZXNwb25zZSBpcyBwcm92aWRlZCBhcyBhIFVSTCBwb3N0ZWQgaW4gYW4gT0lEIG9mIHRoZSBpc3N1 ZWQgY2VydGlmaWNhdGUuDUNBIEF1ZGl0DVRoZSBDQSBpcyBzdWJqZWN0IHRvIGFuIGFubnVhbCBj b21wbGlhbmNlIGF1ZGl0IHBlcmZvcm1lZCBieSBhIHRoaXJkIHBhcnR5IGF1ZGl0IGFzIHByZXNj cmliZWQgYnkgdGhlIGNlcnRpZmljYXRlIHBvbGljeS4NU3Vic2NyaWJlcg1UaGUgc3Vic2NyaWJl ciBwcm92aWRlcyBzZXJ2aWNlcyB0aHJvdWdoIHRoZSBjZXJ0aWZpY2F0ZS11c2luZyBjbGllbnRz IHRvIHJlbHlpbmcgcGFydGllcy4gVGhlIHN1YnNjcmliZXIgaWRlbnRpZmllcyBhIHJlbGF0aW9u c2hpcCBvZiBpdHMgc2VydmljZSB0byBhIGRvbWFpbiBuYW1lIHRocm91Z2ggYSBjZXJ0aWZpY2F0 ZS4gDVRoZSBzdWJzY3JpYmVyIHN1Ym1pdHMgY2VydGlmaWNhdGUgcmVxdWVzdHMgaW4gYWNjb3Jk YW5jZSB3aXRoIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY3kuIE9uY2UgdGhlIGNlcnRpZmljYXRlIHJl cXVlc3QgaGFzIGJlZW4gYWNjZXB0ZWQsIHRoZSBzdWJzY3JpYmVyIHdpbGwgcmVjZWl2ZSB0aGUg Y2VydGlmaWNhdGUgYW5kIHdpbGwgbWFuYWdlIHRoZSBjZXJ0aWZpY2F0ZSBpbiBhY2NvcmRhbmNl IHdpdGggdGhlIGNlcnRpZmljYXRlIHBvbGljeS4NUmVseWluZyBQYXJ0eQ1UaGUgcmVseWluZyBw YXJ0eSB1c2VzIGEgY2VydGlmaWNhdGUtdXNpbmcgY2xpZW50IGluIGNvbW11bmljYXRpb24gd2l0 aCBhIHN1YnNjcmliZXIuIFRoZSByZWx5aW5nIHBhcnR5IGltcGxpY2l0bHkgYWNjZXB0cyB0aGUg Y2VydGlmaWNhdGUgcG9saWN5IGJ5IGNob29zaW5nIHRvIHVzZSBhIHBhcnRpY3VsYXIgY2VydGlm aWNhdGUtdXNpbmcgY2xpZW50Lg1UcnVzdCBNb2RlbCBWYXJpYW50cw1UaGlzIHNlY3Rpb24gZGVm aW5lcyB2YXJpYW50cyB0byB0aGUgcm9sZXMgb2YgdGhlIHBhcnRpZXMgYXMgZGVmaW5lZCBpbiBz ZWN0aW9uIDIuDVJvb3QgU3RvcmUgUHJvdmlkZXINQ2VydGlmaWNhdGUtdXNpbmcgY2xpZW50IGFk b3B0cyByb290IHN0b3JlDVRoZSBjZXJ0aWZpY2F0ZS11c2luZyBjbGllbnQgZG9lcyBub3QgdXNl IGl0cyBvd24gcm9vdCBzdG9yZSwgYnV0IHVzZXMgdGhlIHJvb3Qgc3RvcmUgbWFuYWdlZCBieSBh IHNlcGFyYXRlIHJvb3Qgc3RvcmUgcHJvdmlkZXIuIFRoZSBjZXJ0aWZpY2F0ZS11c2luZyBjbGll bnQgZXZhbHVhdGVzIHRoZSBzdWJzY3JpYmVyknMgY2VydGlmaWNhdGUgYW5kIG1heSBjaGVjayB0 aGUgY2VydGlmaWNhdGUgc3ViamVjdCdzIGRvbWFpbiBuYW1lIG1hdGNoZXMgdGhhdCByZXF1ZXN0 ZWQgYnkgdGhlIHN1YnNjcmliZXIuDUNlcnRpZmljYXRlLXVzaW5nIGNsaWVudCB1c2VzIFRydXN0 IFNlcnZpY2UgU3RhdHVzIExpc3QgSXNzdWVkIGJ5IFJlY29nbml6ZWQgQXV0aG9yaXRpZXMNT25l IG9yIG1vcmUgYXV0aG9yaXRpZXMgKGUuZy4sIEVVIG5hdGlvbmFsIHJlZ3VsYXRvcnkgYXV0aG9y aXRpZXMpIHByb3ZpZGUgYSBsaXN0IG9mIENBcyB3aGljaCBoYXZlIGJlZW4gYXNzZXNzZWQgZm9y IHRydXN0d29ydGhpbmVzcyBmb3Igc3BlY2lmaWMgcHVycG9zZXMgKGUuZy4gd2ViIHNpdGVzIG1l ZXRpbmcgRVUgcmVndWxhdGlvbnMpLCBjYWxsZWQgdGhlIFRydXN0IFNlcnZpY2UgU3RhdHVzIExp c3QgKFRTU0wpLiBUaGUgcm9vdCBzdG9yZSBwcm92aWRlciBhZG9wdHMgdGhlIFRTU0wgYXMgdGhl IGxpc3Qgb2Ygcm9vdCBjZXJ0aWZpY2F0ZXMgdG8gYmUgY29udGFpbmVkIGluIHRoZSByb290IHN0 b3JlLg1DQSBJbmZyYXN0cnVjdHVyZQ1PbmUgcm9vdCBDQSBjcm9zcy1jZXJ0aWZpZXMgYW5vdGhl ciByb290IENBDUEgc21hbGwgYnV0IHNpZ25pZmljYW50IHBvcnRpb24gb2YgdGhlIGNlcnRpZmlj YXRlLXVzaW5nIGNsaWVudHMgaW4gYWN0aXZlIHVzZSBkb2VzIG5vdCBwb3NzZXNzIHRoZSBjYXBh YmlsaXR5IHRvIGJlIHVwZGF0ZWQgaW4gdGhlIGZpZWxkLiAgQ29uc2VxdWVudGx5LCB0aGVzZSBw cm9kdWN0cyBkbyBub3QgYWNjZXB0IGNlcnRpZmljYXRlcyBpc3N1ZWQgYnkgQ0FzIHRoYXQgY2Ft ZSBpbnRvIGV4aXN0ZW5jZSBhZnRlciB0aGV5IHdlcmUgZmlyc3QgZGVwbG95ZWQuICBBbHRob3Vn aCB0aGVpciBjZXJ0aWZpY2F0ZXMgYXJlIGFjY2VwdGVkIGJ5IG5ld2VyIHByb2R1Y3RzIGFuZCBv bmVzIHRoYXQgY2FuIGJlIHVwZGF0ZWQgaW4gdGhlIGZpZWxkLCBuZXdlciBDQXMgb3BlcmF0ZSBh dCBhIGRpc2FkdmFudGFnZSB0byBvbGRlciBDQXMsIGFuZCB0aGV5IGNvbW1vbmx5IGFkZHJlc3Mg dGhpcyBkaXNhZHZhbnRhZ2UgYnkgaGF2aW5nIHRoZWlyIHB1YmxpYyBrZXkgY3Jvc3MtY2VydGlm aWVkIGJ5IGFuIG9sZGVyIENBLg1BcyB0aGUgY3Jvc3MtY2VydGlmaWVkIHJvb3QgQ0EgaXMgYWxz byByZWNvZ25pemVkIGRpcmVjdGx5IGJ5IHRoZSByb290IHN0b3JlIHByb3ZpZGVyLCBpdCBvcGVy YXRlcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIHJlcXVpcmVtZW50cyBvZiB0aGF0IGNlcnRpZmlj YXRlIHBvbGljeSwgcmVnYXJkbGVzcyBvZiBhbnkgcmVxdWlyZW1lbnRzIHBsYWNlZCB1cG9uIGl0 IGJ5IHRoZSBjb250cmFjdCBiZXR3ZWVuIGl0IGFuZCB0aGUgY3Jvc3MtY2VydGlmeWluZyByb290 IENBLg1Jc3N1aW5nIENBIGlzIGEgdGhpcmQgcGFydHkgdG8gdGhlIHJvb3QgQ0ENVGhlIGlzc3Vp bmcgQ0EgbWF5IG9wZXJhdGUgYXMgYSB0aGlyZCBwYXJ0eSB0byB0aGUgcm9vdCBDQS4gVGhlIGlz c3VpbmcgQ0EncyBiZWhhdmlvciBpcyBnb3Zlcm5lZCBieSBpdHMgY29udHJhY3Qgd2l0aCB0aGUg cm9vdCBDQSwgd2hpY2ggY29tbW9ubHkgc3RpcHVsYXRlcyBhZGhlcmVuY2UgdG8gdGhlIGNlcnRp ZmljYXRlIHBvbGljeSBvZiB0aGUgcm9vdCBzdG9yZSBwcm92aWRlci4NUmVnaXN0cmF0aW9uIGF1 dGhvcml0eSBpcyBhIHRoaXJkIHBhcnR5IHRvIHRoZSBpc3N1aW5nIENBDVRoZSByZWdpc3RyYXRp b24gYXV0aG9yaXR5IG1heSBvcGVyYXRlIGFzIGEgdGhpcmQgcGFydHkgdG8gdGhlIGlzc3Vpbmcg Q0EuIFRoZSByZWdpc3RyYXRpb24gYXV0aG9yaXR5J3MgYmVoYXZpb3IgaXMgZ292ZXJuZWQgYnkg aXRzIGNvbnRyYWN0IHdpdGggdGhlIGlzc3VpbmcgQ0EsIHdoaWNoIGNvbW1vbmx5IHN0aXB1bGF0 ZXMgYWRoZXJlbmNlIHRvIHRoZSBjZXJ0aWZpY2F0ZSBwb2xpY3kgb2YgdGhlIHJvb3Qgc3RvcmUg cHJvdmlkZXIuDVJvb3QgQ0EgaXMgb3BlcmF0ZWQgYnkgYSBnb3Zlcm5tZW50DUluIHRoZSBjYXNl IHdoZXJlIHRoZSByb290IENBIGlzIG9wZXJhdGVkIGJ5IGEgZ292ZXJubWVudCBkZXBhcnRtZW50 LCB0aGUgcm9vdCBzdG9yZSBwcm92aWRlciBtYXkgcmVsYXggdGhlIHJlcXVpcmVtZW50IGZvciBh IGZ1bGx5LWluZGVwZW5kZW50IHRoaXJkLXBhcnR5IGF1ZGl0LCByZWx5aW5nIGluc3RlYWQgdXBv biBhbiBhdWRpdCBjb25kdWN0ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBnb3Zlcm5tZW50J3Mg b3duIGludGVybmFsIGF1ZGl0IHByb2Nlc3MuDVN1YnNjcmliZXIgb3BlcmF0ZXMgaXNzdWluZyBD QQ1BIHN1YnNjcmliZXIgbWF5IG9wZXJhdGUgaXRzIG93biBpc3N1aW5nIENBLiAgVHlwaWNhbGx5 LCB0aGUgc3Vic2NyaWJlciBpcyBhcHByb3ZlZCB0byBpc3N1ZSBjZXJ0aWZpY2F0ZXMgb25seSB3 aXRoaW4gYSBzcGVjaWZpYyByZWdpb24gb2YgdGhlIG5hbWUtc3BhY2UsIGFuZCB0aGlzIGxpbWl0 YXRpb24gaXMgZW5mb3JjZWQgYnkgY29udHJhY3Qgb3IgdGVjaG5pY2FsIGNvbnN0cmFpbnRzLg1U aGUgcm9vdCBDQSBtYXkgdXNlIHRoZSBuYW1lIGNvbnN0cmFpbnRzIGNlcnRpZmljYXRlIGV4dGVu c2lvbiB0byBsaW1pdCB0aGUgcmVnaW9uIG9mIHRoZSBuYW1lLXNwYWNlIGluIHdoaWNoIHRoZSBp c3N1aW5nIENBIGNhbiBpc3N1ZSB2YWxpZCBjZXJ0aWZpY2F0ZXMuDVN1YnNjcmliZXIgc291cmNl cyBtYW5hZ2VtZW50IG9mIGlzc3VpbmcgQ0ENQSByb290IENBIG1heSBob3N0IGFuIGlzc3Vpbmcg Q0Egb24gYmVoYWxmIG9mIGEgc3Vic2NyaWJlci4gVHlwaWNhbGx5LCB0aGUgc3Vic2NyaWJlciBp cyBhcHByb3ZlZCB0byBpc3N1ZSBjZXJ0aWZpY2F0ZXMgb25seSB3aXRoaW4gYSBzcGVjaWZpYyBy ZWdpb24gb2YgdGhlIG5hbWUtc3BhY2UsIGFuZCB0aGlzIGxpbWl0YXRpb24gaXMgZW5mb3JjZWQg YnkgdGhlIGhvc3Qgcm9vdCBDQS4gIEV4YW1pbmF0aW9uIG9mIHRoZSBjZXJ0aWZpY2F0ZSBjaGFp biB3b3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSBpc3N1aW5nIENBIHdhcyBvd25lZCBhbmQgb3BlcmF0 ZWQgYnkgdGhlIHN1YnNjcmliZXIuDVN1YnNjcmliZXIgbWFuYWdlcyByZWdpc3RyYXRpb24gYXV0 aG9yaXR5DUEgc3Vic2NyaWJlciBtYXkgbWFuYWdlIGEgcmVnaXN0cmF0aW9uIGF1dGhvcml0eS4g IFRoZSBzdWJzY3JpYmVyIGlzIGFwcHJvdmVkIHRvIGlzc3VlIGNlcnRpZmljYXRlcyBvbmx5IHdp dGhpbiBhIHNwZWNpZmljIHJlZ2lvbiBvZiB0aGUgbmFtZS1zcGFjZSwgYW5kIHRoaXMgbGltaXRh dGlvbiBpcyBlbmZvcmNlZCBieSB0aGUgaXNzdWluZyBDQS4gIA1TdWJzY3JpYmVyIGNlcnRpZmlj YXRlIGlzc3VlZCBieSByb290IENBDVNvbWUgbGVnYWN5IHNpdHVhdGlvbnMgZGVtYW5kIHRoYXQg dGhlIGNlcnRpZmljYXRlIGJlIGlzc3VlZCBkaXJlY3RseSBieSB0aGUgcm9vdCBDQSwgd2l0aG91 dCB0aGUgaW52b2x2ZW1lbnQgb2YgaXNzdWluZyBDQXMuICBUaGlzIG1vZGVsIGlzIG5vdyBkZXBy ZWNhdGVkLCBidXQgdGhlIHByYWN0aWNlIHdpbGwgcmVtYWluIGluIGVmZmVjdCBpbmRlZmluaXRl bHkuDVN1QnNjcmliZXINU3Vic2NyaWJlciB1c2VzIGFnZW50DVRoZSBzdWJzY3JpYmVyIG1heSB1 c2UgYSB0aGlyZCBwYXJ0eSBhZ2VudCB0byBtYW5hZ2UgdGhlaXIgY2VydGlmaWNhdGVzLiBUaGUg dGhpcmQgcGFydHkgd2lsbCByZXF1ZXN0IGNlcnRpZmljYXRlcyBmcm9tIHRoZSByZWdpc3RyYXRp b24gYXV0aG9yaXR5IGFuZCBtYW5hZ2UgdGhlIGNlcnRpZmljYXRlcyBpbiBhY2NvcmRhbmNlIHdp dGggdGhlIGNlcnRpZmljYXRlIHBvbGljeS4NUmVseWluZyBwYXJ0eQ1SZWx5aW5nIHBhcnR5IGRp cmVjdGx5IHRydXN0cyBpc3N1aW5nIENBIGtleQ1UaGUgY2VydGlmaWNhdGUtdXNpbmcgY2xpZW50 IG1heSBhbGxvdyB0aGUgcmVseWluZyBwYXJ0eSB0byBkZXNpZ25hdGUgYSBDQSBrZXkgYXMgdHJ1 c3RlZCwgYSBwcmlvcmksIGZvciB0aGUgcHVycG9zZSBvZiBldmFsdWF0aW5nIHN1YnNjcmliZXIg Y2VydGlmaWNhdGVzLg1SZWx5aW5nIHBhcnR5IGRpcmVjdGx5IHRydXN0cyBTdWJzY3JpYmVyIGVu dGl0eSBrZXkNVGhlIGNlcnRpZmljYXRlLXVzaW5nIGNsaWVudCBtYXkgYWxsb3cgdGhlIHJlbHlp bmcgcGFydHkgdG8gZGVzaWduYXRlIGEgc3Vic2NyaWJlciBhcyB0cnVzdGVkLCBhIHByaW9yaS4N SUFOQSBDb25zaWRlcmF0aW9ucw1UaGlzIG1lbW8gaW5jbHVkZXMgbm8gcmVxdWVzdCB0byBJQU5B Lg1TZWN1cml0eSBDb25zaWRlcmF0aW9ucw1UaGUgdHJ1c3QgbW9kZWxzIGRlc2NyaWJlZCBoZXJl IGV4aGliaXQgc2V2ZXJhbCB2dWxuZXJhYmlsaXRpZXMgdGhhdCBjb3VsZCBhZHZlcnNlbHkgYWZm ZWN0IHRoZSByZWxpYWJpbGl0eSBvZiB0aGUgYXV0aGVudGljYXRpb24gdGhleSBwcm92aWRlLiAg VGhlIGZpcnN0IGNvbmNlcm5zIHRoZSBuYW1pbmcgb2Ygc3Vic2NyaWJlcnMuICBUaGUgc2Vjb25k IGNvbmNlcm5zIGNvbnRyb2xsYWJpbGl0eSBhbmQgb2JzZXJ2YWJpbGl0eSBvZiBpc3N1ZWQgY2Vy dGlmaWNhdGVzLg1TdWJzY3JpYmVyIG5hbWVzIHdpdGggYW55IG9mIHRoZSBmb2xsb3dpbmcgY2hh cmFjdGVyaXN0aWNzIGNhbiBiZSB1c2VkIGluIGFuIGltcGVyc29uYXRpb24gYXR0YWNrLg1ob21v Z3JhcGhpYyBuYW1lDW1peGVkLWFscGhhYmV0IG5hbWUNbmFtZSB0aGF0IGNvbnRhaW5zIGEgc3Ry aW5nIHRlcm1pbmF0aW9uIGNoYXJhY3Rlcg1ub24tdW5pcXVlIG5hbWUgKGUuZy4gYW4gaW50ZXJu YWwgc2VydmVyIG5hbWUpDVdpdGggdGhlIGV4Y2VwdGlvbiBvZiBub24tdW5pcXVlIG5hbWVzLCBD QXMgaW4gdGhlIFdlYiBQS0kgYXJlIHJlcXVpcmVkIHRvIHNjcmVlbiBvdXQgcmVxdWVzdHMgZm9y IGNlcnRpZmljYXRlcyB3aXRoIGFueSBvZiB0aGVzZSBjaGFyYWN0ZXJpc3RpY3MuICBDQXMgYXJl IHJlcXVpcmVkIHRvIHBoYXNlIG91dCB0aGUgcHJhY3RpY2Ugb2YgaXNzdWluZyBub24tdW5pcXVl IG5hbWVzIGJ5IDIwMTYuDVRlY2huaWNhbGx5LCB1bmxlc3MgY29uc3RyYWluZWQgYnkgYW4gdXBz dHJlYW0gQ0EgdG8gaXNzdWUgY2VydGlmaWNhdGVzIG9ubHkgaW4gYSBzcGVjaWZpYyByZWdpb24g b2YgdGhlIG5hbWUtc3BhY2UsIGFueSBDQSBpbiB0aGUgV2ViIFBLSSBjYW4gaXNzdWUgYW4gYXBw YXJlbnRseSBsZWdpdGltYXRlIGNlcnRpZmljYXRlIGZvciBhbnkgbmFtZSwgd2hldGhlciBvciBu b3QgdGhlIGxlZ2l0aW1hdGUgaG9sZGVyIG9mIHRoYXQgbmFtZSBpcyBhd2FyZSBvZiBvciBhcHBy b3ZlcyB0aGUgaXNzdWFuY2UuICBGdXJ0aGVybW9yZSwgdGhlIGxlZ2l0aW1hdGUgaG9sZGVyIG9m IHRoYXQgbmFtZSBtYXkgbm90IGRpc2NvdmVyIHRoYXQgc3VjaCBhIGNlcnRpZmljYXRlIGhhcyBi ZWVuIGlzc3VlZC4NSW4gdGhlIGV2ZW50IG9mIGEgY29tcHJvbWlzZSBvZiBhIHJvb3QgQ0EsIGl0 cyBrZXkgaXMgYmxhY2tsaXN0ZWQgYnkgY2VydGlmaWNhdGUtdXNpbmcgY2xpZW50cyBieSBtZWFu cyBvZiBhIHNvZnR3YXJlIHVwZGF0ZS4gIFRoaXMgaGFzIHRoZSBlZmZlY3Qgb2YgaW52YWxpZGF0 aW5nIGV2ZXJ5IG90aGVyd2lzZS12YWxpZCBjZXJ0aWZpY2F0ZSB0aGF0IGNoYWlucyB0byB0aGF0 IHJvb3QsIHdoZXRoZXIgb3Igbm90IGl0IHdhcyBpc3N1ZWQgd2hpbGUgdGhlIGNvbXByb21pc2Ug ZXhpc3RlZC4gIFRoaXMgc3RlcCB3b3VsZCBoYXZlIGEgc2V2ZXJlIGltcGFjdCB1cG9uIHRoZSBD QSBhbmQgaXRzIGNlcnRpZmljYXRlIGhvbGRlcnM7IGEgc3RlcCBub3QgbGlrZWx5IHRvIGJlIHRh a2VuIHdpdGhvdXQgdmVyeSBjYXJlZnVsIGRlbGliZXJhdGlvbiBhbmQgKHBlcmhhcHMpIGhlc2l0 YXRpb24uDU5vcm1hdGl2ZSBSZWZlcmVuY2VzDVtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkg d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVscyIsIEJD UCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDVtSRkM1MjgwXSAgQ29vcGVyLCBELiwgU2FudGVz c29uLCBTLiwgRmFycmVsbCwgUy4sIEJvZXllbiwgUy4sIEhvdXNsZXksIFIuLCBhbmQgVy4gUG9s aywgIkludGVybmV0IFguNTA5IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgQ2VydGlmaWNhdGUg YW5kIENlcnRpZmljYXRlIFJldm9jYXRpb24gTGlzdCAoQ1JMKSBQcm9maWxlIiwgUkZDIDUyODAs IE1heSAyMDA4Lg1BdXRob3JzJyBBZGRyZXNzZXMNSW5pZ28gQmFycmVpcmEgKGVkaXRvcikLSXpl bnBlC0MvQmVhdG8gVG9tYXMgZGUgWnVtYXJyYWdhIDcxLCAxby4gMDEwMDggVml0b3JpYS1HYXN0 ZWl6LiBTcGFpbg1QaG9uZTogKzM0IDk0NTA2NzcwNQtFbWFpbDogaS1iYXJyZWlyYUBpemVucGUu bmV0DQ1CcnVjZSBNb3J0b24gKGVkaXRvcikLRW50cnVzdAsxMDAwIElubm92YXRpb24gRHJpdmUu IE90dGF3YSwgT250YXJpby4gQ2FuYWRhIEsySyAzRTcNRW1haWw6IBMgSFlQRVJMSU5LICJtYWls dG86YnJ1Y2UubW9ydG9uQGVudHJ1c3QuY29tIiAUYnJ1Y2UubW9ydG9uQGVudHJ1c3QuY29tFQ0N Aw0NBA0NAw0NBA0NDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAABsIAAAcCAAAJQgAAEUIAABQCAAAfAgAAJMI AACUCAAArAgAALsIAAC8CAAAOgsAAGMLAACGCwAAhwsAAPQNAAD1DQAAAQ4AAAIOAAC+DgAAwg4A APkOAAD6DgAADw8AABAPAADbDwAA3A8AAOcPAAAjEAAAJBAAAGwQAABtEAAAbhAAAHUQAAB2EAAA dxAAAHgQAADNEAAAzhAAAN8QAADhEAAADxEAABYRAAAlEQAAJhEAAC4RAABJEQAAaREAAG8RAABx EQAAfhEAAH8RAAC2EQAAxBEAAMURAADGEQAAyREAAA8SAAAQEgAA+fXx7ent5e3p7ent4e317drW 0unl6fnW0u3a1svHy8PL5ce8x7jlsaqxprGmsaaxprGfm5+xvLGbsZcAAAAGFmjNQp4AAAYWaJIB 7gAADBVotVLDABZotVLDAAAGFmhQRR0AAAwVaJF7NwAWaH1PUQAADBVokXs3ABZozUKeAAAGFmiN JAkAAAwVaLVSwwAWaH1PUQAABhZoCk8zAAAGFmh9T1EAAAwVaApPMwAWaJF7NwAABhZo6hbBAAAG FmhhXM0AAAwVaJ15CAAWaJ15CAAABhZoen9LAAAGFmgEN6UAAAYWaLRYJQAABhZonXkIAAAGFmj2 Bv4AAAYWaJEjzAAADBVokSPMABZokSPMADsACAAAHAgAACUIAAC9CAAA0QgAADAJAAAvCgAANAsA AGQLAAB1CwAA3QsAAPUNAAACDgAAqw4AAPoOAAAQDwAA3A8AAOcPAABuEAAAzhAAABgRAABxEQAA thEAAPcAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADq AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA4gAAAAAA AAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANgAAAAAAAAAAAAA AADYAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAAzAAA AAAAAAAAAAAAAMcAAAAAAAAAAAAAAADHAAAAAAAAAAAAAAAAxwAAAAAAAAAAAAAAAMIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAQAAGdktVLDAAAEAABnZM1CngAABAAAZ2QKTzMAAAQCAGdkYVzNAAAB AgAABAAAZ2SRI8wAAAQBAGdkl3bpAAgBAAomAAtGAABnZJ15CAAABAAAZ2SdeQgACAEACiYAC0YA AGdk9gb+AAAHZAADJABhJABnZJEjzAAAFrYRAAAQEgAAERIAAB0SAABGFAAAlhQAAJgUAAC3FAAA yxQAADUWAABHFgAAShYAAAMXAAADGAAAdBgAAIsYAAAUGQAAJxkAACIaAACQGgAAmRoAABMbAAAe GwAA2hsAANgcAADmHAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAA AAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOsAAAAAAAAA AAAAAADmAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA 5gAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAAOEAAAAA AAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADmAAAAAAAAAAAA AAAA6wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAAAA BAAAZ2QXF14AAAQAAGdkfU9RAAAEAwBnZP4vgwAABAAAZ2T+L4MAAAQCAGdk/i+DAAAEAABnZGFc zQAABAEAZ2RhXM0AAAQAAGdkzUKeAAAZEBIAABESAAA7EgAAUxIAAFQSAAB4EgAAfRIAAKkSAACr EgAAGxMAACMTAAA2EwAANxMAAD0TAABDEwAAXRMAAF8TAAC5EwAAwBMAABAUAAAbFAAARBQAAEUU AABGFAAAZhQAAJUUAACWFAAAlxQAAJgUAAC3FAAAyhQAAMsUAADVFAAA1xQAANsUAADjFAAA/xQA AAAVAAAeFQAAOBUAAD8VAABLFQAAdhUAAHwVAACYFQAA4xUAAOQVAAD4FQAABBYAABYWAAAdFgAA MBYAADMWAAA0FgAANRYAAEoWAABLFgAAURYAAGAWAAByFgAAdhYAAIEWAACIFgAAjxYAANgWAADa FgAA2xYAAPUWAAD4FgAAAxcAABAXAAD8+PT48Oz46Pjs+PT49Pjo+OT44Pjc7NzY3NDM2Mj4xMjE yOTEyMTIxMj0yMTAxMD08MS8xLXIsczwzLzMsfCx8Lyx8LHMBhZomhlDAAAMFWj+L4MAFmj+L4MA AAYWaBR0RQAABhZoExpVAAAGFmhVD1wAAAYWaP4vgwAABhZoFxdeAAAPA2oAAAAAFmgXF14AVQgB BhZo5SmnAAAGFmhrcBIAAAYWaMh1AwAABhZojSQJAAAGFmgHKnsAAAYWaEl7RgAABhZoBDelAAAG Fmi0WCUAAAYWaGFczQAABhZosge/AEYQFwAAJxcAAEQXAABJFwAAnhcAAKYXAACtFwAAARgAAAIY AAADGAAAChgAABEYAABzGAAAdBgAAIsYAAATGQAAFBkAACcZAAAsGQAAhRkAAIgZAAC7GQAAIRoA ACIaAABgGgAAYxoAAGsaAABuGgAAjxoAAJAaAACvGgAA2BoAABIbAAATGwAAHRsAAB4bAABdGwAA ZRsAAHkbAADaGwAA1xwAANgcAADmHAAA/xwAABcdAAA8HQAAmB0AALAdAACxHQAAsh0AAMcdAAAZ HgAAGh4AAC4eAABGHgAARx4AAE0eAABZHgAAWh4AAF0eAAB1HgAAlR4AAJseAACvHgAA/Pj0+Pzw /Oz46PTo4ejd1ujw6Pzo0uj8zvzO/Mfo/Ojh6PjO8M7D+Lzo0rjS+Lj4vLSwqbS4paGlsKW4pbCl AAAABhZoyHUDAAAGFmjNQp4AAAwVaCATcQAWaCATcQAABhZoIBNxAAAGFmhhXM0AAAYWaLRYJQAA DBVoFxdeABZoFxdeAAAGFmhrcBIAAAwVaP4vgwAWaBR0RQAABhZok0eJAAAGFmhVD1wAAAwVaP4v gwAWaH1PUQAABhZofU9RAAAMFWj+L4MAFmj+L4MAAAYWaP4vgwAABhZo5SmnAAAGFmgEN6UAAAYW aI0kCQAABhZoFxdeAAAGFmgUdEUAP+YcAACyHQAAxx0AABoeAAAuHgAAWR4AAHwfAADVHwAAMyEA AEUhAABxIQAAfCMAAIokAAC1JAAAkyUAAM0lAADJJgAA7SYAAPgnAAAXKAAA+CgAAJMpAAC/KQAA ECsAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADm AAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA6wAAAAAA AAAAAAAAANQAAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAANQAAAAAAAAAAAAA AADPAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAAM8AAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAzwAA AAAAAAAAAAAAANQAAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAANQAAAAAAAAA AAAAAADPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABnZJcvRQAABAMAZ2SXL0UA AAcDAAMkAGEkAGdkzUKeAAAEAABnZM1CngAABAMAZ2TNQp4AAAQCAGdkYVzNAAAEAABnZCATcQAA BAEAZ2RhXM0AAAQAAGdkFxdeAAAXrx4AALweAADFHgAA2h4AAN4eAAD2HgAA9x4AAP8eAAAAHwAA BR8AABEfAAAdHwAAIh8AAHAfAAB6HwAAfB8AAJQfAAC+HwAAyB8AANUfAADWHwAA8h8AAPMfAADG IAAAMiEAADMhAABFIQAAmCEAALAhAAB8IwAAfiMAALojAADRIwAAmSQAALQkAADRJAAA4SQAAPAk AADxJAAAZCUAAHclAAB+JQAAkSUAAK4lAADMJQAA9CUAAAUmAAAXJgAAGCYAAG0mAADHJgAANycA AEonAAD4JwAAAigAABcoAAAjKAAAVCgAAF4oAADdKAAA9igAAJMpAACdKQAA7SkAAPkpAAAKKgAA FCoAAAQrAAAOKwAAECsAABorAAAjKwAAOSsAADsrAABVKwAAcSsAAHsrAAADLAAABCwAAPz4/PTw 9Oz07Pzs9Oz87PDs+Oz07Pjs6OHd2fDZ9Nno2fjZ9Nn02dXZ1dn42fTZ9NnV2dXZ0dnR2c3ZydnR 2dHZ0dnR2dHF+MXNxdHFzQYWaEFmtQAABhZoiw4wAAAGFmhHXtYAAAYWaGcdJwAABhZoEiM/AAAG FmiXL0UAAAYWaGFczQAADBVozUKeABZozUKeAAAGFmiTXL0AAAYWaM1CngAABhZotFglAAAGFmgg E3EAAAYWaJNHiQAABhZoyHUDAE4QKwAAOisAAAQsAAAtLAAA/ywAAAotAAAgLQAA+i0AAAguAAA1 LgAA0S4AAAUvAABuLwAAgi8AAKkvAADBLwAAzzAAADIxAABDMQAAVzEAAIkxAAC4MQAAnDIAAPoA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADmAAAAAAAA AAAAAAAA4QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAA ANcAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADNAAAA AAAAAAAAAAAA0gAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAxQAAAAAAAAAA AAAAAMUAAAAAAAAAAAAAAADFAAAAAAAAAAAAAAAAxQAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACAAACiYAC0YPAGdkJXc6AAAEAABnZEFmtQAABAEAZ2RhXM0AAAQAAGdk ly9FAAAEAwBnZJcvRQAABAMAZ2STR4kAAAQCAGdkYVzNAAAEAABnZGcdJwAABAMAZ2RHXtYAAAQA AGdkR17WAAAEAwBnZEFmtQAAFgQsAAD/LAAACS0AAAotAAAfLQAAIC0AAEQtAABKLQAAVS0AAFot AAD5LQAA+i0AAAguAAAVLgAAOS4AAFEuAABgLgAAbS4AALguAADCLgAA0S4AAN4uAADvLgAA+S4A AAAvAAAJLwAAIS8AADAvAAA9LwAASy8AAE0vAABYLwAAbi8AAIIvAACoLwAAqS8AAMEvAABzMAAA fjAAAM8wAADZMAAAbDQAAIQ0AADqNQAA/zUAAB44AABFOAAARjgAAHM4AAB0OAAAjDgAAI04AACO OAAAjzgAAJA4AACSOAAAkzgAAPz49PDp+PD48Pji9N7a1tre2vja3tr43trW2t7a3vja9NLL9NL4 0vjS1tL0x7y0vLSntLyclJCUAAAAAAYWaPJfuAAADwNqAAAAABZo8l+4AFUIARQVaHRJzwAWaPsK 5wBtSAoMc0gKDAAYFWh0Sc8AFmgldzoAMEpwAG1ICgxzSAoMAA8DagAAAAAWaCV3OgBVCAEUFWh0 Sc8AFmgldzoAbUgKDHNICgwABhZoJXc6AAAMFWhBZrUAFmhBZrUAAAYWaEFmtQAABhZotFglAAAG FmiXL0UAAAYWaOI8uAAADBVoR17WABZoR17WAAAMFWiTR4kAFmiTR4kAAAYWaJNHiQAABhZoYVzN AAAGFmhHXtYAAAYWaGcdJwA4nDIAACc0AADqNQAA/zUAAHE2AABENwAAVzcAALY3AADoNwAA6TcA AD44AACOOAAAjzgAAJE4AACSOAAAlDgAAJU4AACXOAAAmDgAAJo4AACbOAAAnDgAAJ04AACeOAAA nzgAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADw AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAA AAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOQAAAAAAAAAAAAA AADiAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA4gAA AAAAAAAAAAAAAOQAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAOIAAAAAAAAA AAAAAADiAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAEEABnZCV3OgAAAQAAAAMAABOkAAAIAQAKJgALRgAAZ2QldzoAAAQAAGdkJXc6AAAEAQBn ZGFczQAABAAAZ2RBZrUAABiTOAAAlTgAAJY4AACYOAAAmTgAAJs4AACcOAAAnTgAAJ44AACfOAAA /PT89Pzt6fzeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAUFWh0Sc8AFmj7CucAbUgKDHNICgwABhZoiw4wAAAMFWgldzoAFmiLDjAAAA8DagAAAAAW aPJfuABVCAEGFmjyX7gACUEBAtLUAAABCAAAAYAAAAEAaAEAAAAAAQgAAAGAAAABAGgBAAABAAAI AAABgAAAAQBoAQAAAwABCAAAAYAAAAEAaAEAAAABAQgAAAGAAAABANACAAAEAQEIAAABgAAAAQDQ AgAAAgEBCAAAAYAAAAEA0AIAAAQBAQgAAAGAAAABANACAAACAQEIAAABgAAAAQDQAgAAAAAAAC4A LgAuACgAKQAoACkAKAApACgAKQAoACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAJMAARMAEUMAocUAEAJlABAC9SIAAfsNAvILDgPSGwoAUisKAFI5BzBSSQYAMlsAAAF7Cw ARiw3AIMkNACONIkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/RHABAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAbSoAAEQAZAAAAAAAAAAIAAAAAAAAAAAAAAAAAO8gmRyVApYCAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwVAAAALIECvAIAAAAAQQAAAAKAABDAAvwMAAA AARBAQAAAAXBGAAAAAYBAgAAAP8BAAAIAHQAcgB1AHMAdABfAG0AbwBkAGUAbAAAAAAAEPAEAAAA AAAAgGIAB/DFKQAABgZyZCaMn6+TTFjIlhyxj4bU/wChKQAAAQAAAEQAAAAAACgAAG4e8JkpAABy ZCaMn6+TTFjIlhyxj4bU/4lQTkcNChoKAAAADUlIRFIAAAIyAAAB6AgDAAAAZF/1vwAAAAFzUkdC AK7OHOkAAAAEZ0FNQQAAsY8L/GEFAAAACXBIWXMAAA7DAAAOwwHHb6hkAAAApVBMVEVRp7VFobBd rLpRprVosr9os790uMRzuMSanJ6TlZiAvsiAvsmLxM6XytOLxM2WytK8vb+1trihoqWusLKnqau9 vsCi0Net1dyi0Niu1ty52+G53OHQ0NLJysvW19jd3t/CxMXJyszBwsTOztDe3t/S0tTQ5+vF4ebc 7fDF4ubQ6Ovz+fro8/Xr6+zx8vL4+Pnk5OXz8/Pu7+/7+/vm5+f39/f///9aIlpgAAAobElEQVR4 2u2d6WKqQJaAWUTUGM02BDUmt2chCNwkPd3D+z/aUAsoBpCl9qrz48aLqMD5OFvVKazciJFBYplL YMQgY8QgY8QgY8Qgo5Kk0VlSczkMMp2sBOu5ZdfFmq8DQ45B5rdk+7Vjt4uzfs3MRTLIVBLdd+FS YXP/aS6VQaaQ+N6y+4p1HxtkNEcm3c/sYTLb6x7YaI1MGlj2cLECvcMajZHJ1vZYWesMjbbIjLMw lQT6uiddkdlPAga4p71BRieJ5/Z0mWmaPWmJTGCTkcAgo4mJmdmkREtDox8yk6MY3SMa7ZBZ22Rl bZBRW9KZTVpmuqXbeiETOzZ5sTQLaLRCJrZs2zBjkOkvER1idAuCNUJmb9MTnZjRB5nIpikazb7S BpnYooqMRvGMLshQJkYnZjRBJnVs2uLoUp/RBJmZTV9mBhmF5N5mIZqMHWiBzN5mI3qk2jogk1mM kLG0mBKsAzIzm5VoEc5ogExgs5PAIKOAZDZL0aA6oz4yc6bIzA0y0sveZivqZ02qI8Og7HuVNSlf BFYdmcBmLYFBRm4jYzFHRnkzozgy7I2M+mZGbWQ4GBn1zYzayPAwMsqbGbWRcbggo7izV/r09jYf Ubs2ozQyzYXfEMjG66P7zSk5bIYjMzfISCoto0v43eQmNC4aMBrBjNKTIFRGpjn49W8QdU1M7g9H 5t4gI6c0B7+b4p3tKm5nYZckW+jAil1O4SG/2NRXHIOMlBI3qxOQgGxNCzJpnofYu5yKP6uLTb1F 5TkQCiPTUpQ5QZfUgUzxzgpbim19k/FMiiMzazUASeFqoK0p3NQh2UEH5m5PydYtWDoU7xx8BNUB RT/lJidMTiAY9ouMyz3swIeSQyN4Ks/oVBeZ1G41IruSBzeBuxZa92CSk7rQb8EsycF/7WrTBo4E JNBQxXHhqry02qfBuxlkZJPPZmK8CqnCpCBiiqjHxSre2RVEKB4BdgZvKlOtFY5UVqA/Mm5hU+Fq nrrItLS7lYqPPfR6W5iMHBiSdJUBE+IBx+W7AK4UQVRuKsiJVzkIhAFwIdywBfh4egUz6iIza0+Y gNnAkXCCAmGYEqFcKq6yI8SMjzd58HUCaoA5DIwdaGCS5jBa4WBGXWRaQhkQyoaIBGAtNhAZUKtx ADIZ3nhRzAvxJvRuAgLh4v+FGdoWyCRJ2lL/MchIJ20rEAEz4SMzgewGLO1BxA7QMeUXZgOEwAe8 CZokUKwJQxS/nPAvNcfZkUFGNtm3J0wHN4dVOh+CUqTbSQhxgP5nVTNQ+XlTAl6CT/oQLbhh5xfi aTaarSwyLYU8F0IQV+W8ym4k0KT42P+AONmGvqcIbiuXFEKTBFmxcRTj+H7zuERgkJFN5u0Jkw8D Gge+DuFLENysEEfYhBQG5hSCMDkuNxX/yVYpcFQ5KgsnIMI5NSdMKk+A0A2ZLYQF/Luq6m27qliz sksTUibjqVdu2uINDnRO6KvSGI1DGWRUkJZQBg0UePkFBYcqlN2g6AWOLK3glsyrNrkZRsjPUZKE JkfErt05LccgIzsymzAERIB5eXD0KNmh9GhzSkIYlBTvoOBktUt2KNvGm9xtcgKjUF7xfxQXbRM4 LGWQURoZdqLsKJOqyETckYkMMgYZg4xBxiBjkDHIGGQMMgYZg4xBxiBjkDHINIvr+75BxiAzQNCc GoOMxtVf1DcQh263bQmTVbV/MgQZU/1VDpkD3jHuZObcQZC0Dlo3i6oXVl1kbi55loCpu8AUdHVb w1kRiKlsYJOtQUY2mfdQKZrW22U7QH/Trtp/SJPt3CAjm9zdSoDysnmgM0JxQpwmgVky3gBk7gwy ssmtlRVxH39euhsP8tAy99vxq2nkjn+5tV0Cg4xs8tkjZ/bg9G8w6Tc8FF7HBVP2slVpUIrg5QCn h4OpfDGaM+6BCGiD2hI2pctqFNNhIJ3EN5ABePgh6KqG/bIFJHjVqtSxoQGC8zVD8P4mR3skuH8S NU2m3YGzuivMaNcteZEwIUI8mBVlCSzUAEVvQUnFR30FsN+tMDcpmPgbgum/2wMIiAE6aedqe8pe V4WRuZEy4RUQC7WDKGWHkqMQeiOA0xb1EQCfBd73QJPTZgveLKxPAt5MXD0TJoWRCW7m2AlayhX3 ywL348L+W2Bbwm3VoH2AXg4QBADyt7hDtzt9Mis/SCifNxOmTVUGTlBwk+CeyAKiMAbveyUoMCd3 y68OUVTcJZ8GGfkk7VQpULpfRTW4X/aAF3kAFgYaGZhZ53h9iBRglgDxw5vhtVnFSkaZ3xqUPLso 3C+LFpFxcKdkiH0WhGuH3FHcc7xpru5lVRmZ1y6dnqqloh1sb6CVQZvhMnlgYTTos4CVAbnSzkeu KzncHm96NcjIKNmNEerkHNW4eGQb5Ni4y7ZcJW8HyzYgv9oCklYHvPLZqk8+ZpCRTGbdCVN4LgOX 6GBSoMad0meVSw/5uJYT15ctahKV13BVGpnX7kkN26oMjOzNNgWrJpaxyqHyWV6aZ2jBCLjma+Je LVukmV/S8UkpHZl3c63FvRyJ7PVUMPOkFFnlzuYj6k58UB4ZXp0pCtfxVEeG07MllX60jurI8Hm4 pNqPllT90eo8zIx5TrbUwuNB2YHal1R1ZDiYGdWNjPLIsI9mFI9k1Eemc9TApEsGmQZhXZuJDDLS C9sSsNqFX02QSS2GxCgf+2qBzM0mOBP7GmSuhZ1r0sAt6YFMyqo4o4Nb0gMZZllTpMPF1AOZ7pnj xETpuXi6IZOvGRCz1uNS6oJMSr8IPNMikNEHGfrMaEOMNsjkMd2KnqXuejLaIkOXGY2I0QgZmszo RIxOyNBjRititEImz+jEwDOtiNELGTp5kz65ko7I0KjprTUjRjtkiI8daDJKoDMyeUxyXNuJtLt+ GiKTp+Tmz9zp5pQ0RSbPP8lk25ba7foGmZqhIREFaxf3ao1MnkdT0+1ZpOmV0xaZPN9PCYMdHeaF G2TIQaMzMHojU0AzM8AYZK7l79vfrrejoYHwOur8ua/jX4OMxPL1/rBYLh+6d0oHmJrZ/laWdFwu F49vXwYZCeX7488T0N7T4unmvtn+rkel5m7fY23W5+Xi/XGxfHp4/zbIyGVfnpfL5+NPnn8s35a9 XEUUzNuxseZB1O+Hi587Am9Y/P7Lh0FGJmSOH+guf3rMF299P5VFwf287qZm8/sg6r/y88fy+7hA v/yjalSjePh7XHzlD4+DPxZHQEbMnPrzkn8/Pah9TdVG5mtReIn3BbsffPkDLM2PQUZaeQCh7xc7 FX7Dn3p+NsjIKj9LGIE+HVn94PsS/Pt3+W6QkVRe0O3+h9ld/4B/cKFshq04Mu9LVFIr0hhGv/iE krPvxR+DjIxSKe6bVTDzVZaA3pYK138VRubsHv6ysjIVmi8KR8DqIsM1CMWBt0FGKnl+4fnrD0+i XAeDTF/hXFCDRUSDjEzCvWwPhioMMjLJcXJp5GNiNKLsUJOqI9mT/cL7cmL4rOxQk6LIPE6NPt+X i8VEZvjG3waZYfIz9Q5/Xz4cjw/TmPlavol0TQwynfI0sZJWEJMfj/lEZhQdalISman1ekAMQGYi M4oONamIzPfE2BcSA5GZyMz7UsW5nCoi8/A0ySEgYhAyE5lRcrKVgshMHFz6ixufEDIFMxMshZJD TQoiM/HW/sbJFkYm/5lisiYaPIMMEyEVQBxJDBJ9KzjUpBwy3wtChXoiyORH9SZbKYfMkVQxhAwy oPfOICO0kCu5EkLmR7mhJtWQeSY2tYkQMtOHuwwyVIXgPU0KGeWGmhRDhmDkQAoZctGVQYaCkJwK RwwZ1fr6lUKGaBWEGDL5u1oRsFLIEK21kkNGsaEmlZAhO6JDEBm1+vpVQoZsiyJBZPIHlSJghZAh PDuFJDJKDTWpgwzpOXAkkVGqr18dZEiXP4gio9JQkzLIEC+ykkVGoaEmZZB5Jj2UQxYZhYaaVEGG /F1MGBl1hppUQYZ8rEAYGXWGmhRBhkJGQhoZZbqa1ECGRt2DNDLVao8GGRGERisrcWRUWUBPCWS+ aIzhkEdGka4mJZChsiwHeWQUSbRVQIbO4j8UkFFjAT0VkKEz640CMmok2gogQ3ghwx8cGGFkiE6p U2JOp/zIEE+w8WIPCJn3JVElq7B8iPzIkO+UR8xAZAgTo8ScTumRoTFJEjIDkCFOjAqJtvTIULlt ATMFMuSJUWH5ENmRodTwUTBzPNIgRoE5nZIjQy0FeVi+vCzpJO+yr1QvOTL0Ch0PyyUlGmVPtOVG hmY59Q+tuQqyr1QvNzJyPvVI8kRbamQkzVglb56UGhlZb1e5mydlRkba6rvcibbEyBBbe5O9SN08 KTEyMs8kkLl5Ul5kpG4Mkrl5Ul5k5J4VKfEj4aRFRvIm5y95E21pkZG9w0PeR8LJioz0fWTyNk9K igytCx5Hr0EwL8SxC3HAqyDYR7GBXnpkyJv17DNAnDTL7C74zMj+oqyuVU5kCAeP8eudZfcQ5+6V oL2RNYCXExmCKWq6X/fCpRRrvU8J/bSkZQIpkSF2f6b7O3uE3JGhRtJipJTIECq3f47iBcn6k8AB yDnkISMyRAb1snvLniROMNnUyDmwKiEyJKYORGubgKyn5lBSTt+QEJnpE5SiuU1I5tG0I5Fxkph8 yEyeBkkOmOnQyDgVVT5kJt6YMVFgYP40xT1JOOFdOmSmtXSka5uC3I8PhCVcpUg6ZCY1jr1aNhWx 9qMPSb5EWzZkprSnxjObmszHeif5VimSDJkpCXZg0xTrdeRhSffkScmQGb/UBk0TM83QyJZoy4XM +Jx0b9nUxRo3iCBb86RcyIy9IekkSg2pE2PTaZC5JWPr69nMZiSzMem2ZM2TMiEzNrmILJuZWGPm YMm1SpFMyIwsYextljKqRCNVoi0RMiMLpfc2YxnBjFSrFEmEzLh5j2ubuYwIgmVqnpQHmXEJNgdi bHs93IJKlGjLg8yoHg4uxIxhRqLmSWmQGdUpxomYEcxIlGjLgsyo9khuxIxgRp5VimRBZkyCzZGY EcxIs0qRJMiMafnhSszwXFua5klJkBmRYO9tWy5mniWZ0ykHMiPuwE/exAweO5CleVIOZJ4GJ9ix xR0Z2xo4RinJnE4pkBmeTaQz/sTY9mzYQUuySpEMyIyoWdyJQMzgoQM5VimSAZnhldFXMYix7YHz 9KRYpUgCZIaPv8SiEGNbw+YDS5FoS4DM8FFeIQIZJPNhRy7DKkXiIzN8Lsm9OMTY9rBeFRmaJ8VH ZnAhPRKJmKGuSYJEW3hkhs+LFcgtDXdNEjRPio7M8AQ7EIuYoQMH4q9SJDoyg3t8MgHKvleuaVgR WPjmScGRGd5JKEgR71KGFfSEX6VIcGQG33Jixb5YhkXAojdPio3M8AR7LiIy80GnIHqiLTQyw9MH 7pNkmiUadBKCN08Kjczwa+eIicwwMyN486TIyAy30IIamaFmRuzmSZGRGb5apaBGZrCZETrRFhiZ 4dkm/8mbhMyM0KsUCYzM8FtNyHQJycAeFZETbXGRGV45F2eaTIMMq82I3DwpLDIjxufWIiMTDDsX gZsnhUVm+CyAVGRi7KEXWtzmSVGRGdHUI8yE32YZOA1Y3DmdoiIzYkajYPNkruVu4OkIu0qRoMiM uMcysYmx7YGNcMKuUiQoMiO6M4Sa8dskQ3u0RV2lSExkxvSACVv5HeuZRG2eFBKZMRdL6KLMKM8k aqItJDJjTLLg+dIYzyRo86SIyIxaNUPwfGmMZxI00RYRmTHppdh1PCTDr7WQzZMCIjPq3hJ4EPss g59vIOQqRQIiM6pULnyKDSQYfFoiNk+Kh8y4PEGCUGbwRKtczERbOGTGDfvLEMqMCWZEbJ4UDplx NU8h25cIBDMiJtqiITNyCqNwjdjNMuK5O+I1T4qGzMiJ0gK21ZKJf8dMmtcLmbHtGFJEv2PiXwGb JwVDZmzT10RVOqvQFzT+FS/RFguZsa2lrWOSju/20OQmzfOEiZkZc3KirVIkFDKj59U3J0zODkzr B+ZjW/wNa4rbXezngiHmAxNkojFnJ1iiLRQyo7t3gjbbkaN5NFkNEqcOkL0p/p9txUVGsOZJkZD5 GT11sQmZDX6veOmDv2fP42PbU8ruxixQx/e7Ih3P9z2aKZNozZMiITP+ZrprISb0bGBkDnVkwrw+ hy+54ZZ23ZFOXLdZFJARq3lSIGQmuOzfnbUgPknxze/mdWR2eT3FSm/ovEDq1B3S9vZq63HnJ1Tz pDjITEkMfiNzuFBkYXBOl5QkFT8uSKgAUdjxuCvgaKoky0UeJzsj5TtXLgtFRr/8lueV316X+cgT FGmVInGQmVJ+sJqMTHbhOTaXyKTAagB3sk3z1A2RDVoV/3hpbHtxnoLXG9sBnGUbH70PwFrFOQIE vC7ysIKlBH08hM4rBOk++OJD8bYLqN0RQkakVYqEQWZSkbMxkimNjFco3r/YCSg/BFpPwEf9A9I5 UH2KUMpBquU7KOFaoTA69OH2FPxxPMgN8G/5AX3ch/HQCXCDPu+5aAgyJISMQKsUCYPMpKGURr/k nV/vLpMk8HrllR/1QfEmTVYnaEs2ABCobPCxNIx39iaDb4DSTh7vwB8bWCH4NXG43YGgKfFgPAQM DPziLAH4HLa/iozjL7c4zZOiIDNtwLYpYs0vfJR3iQygwgNa34YQLBTdFupOHfgnAbRkwH3tbNe1 kbuBNmWFs6cQvJ9gHhK4X4791QZ88Q6ZNhgZEyj/QhEn0RYFmWnTQrqQ2QDlXSIDQEFah9YCR7c5 9GQOBCMEXADjEoL4FbqbMm2qHBCAZFPlW2d/FaL5XgVaJ98niIw4zZOCIDOxJt6IjHNRdQHKC8/v ZcCQ4HAVxbI470EQ7cDOMFSJ3bLugtMm+Kf4hhDs6dplvgXDa0jIAaVj5WSqhBgywiTaYiAzdYrr L2ROpQ2ALGRJfIEMyHOQO4H2A8WyPiIAGh/w5ha5IvAXfRUEC/8BW7A1QfYFwVf6qx3aL04K2RJD RpjmSTGQmTq+/wsZEKVmblm3QxKetRYiPwTtBzIsmADokspCjQez8TNSHgLEgxapRAbGw8htHXDC tEU/4rbU/UaLIKsUCYHM5HadxuJvHvu2d9EInVQ5d76pyisbbFiwP4H/2UJ9+9gLoYAEF3agTYGU hNDeuAgy6P1csHtZ2IO775LEJYiMIM2TQiAzuSnw992MKmx5ClTtIFVhZIBVgYGpi+xHFd3u8Mdg ZabYLcty7HPSMm1CA5w5iI5W8O8Gh8UJ3u5gBwdp2zaMTU06TTESbRGQmX73NHgAVGJLTjgVPiMD EyZoKJD9QNEtHmcqyzUJLuTtSvuDwELWC6XjcIlNH4fFmNAd9lPlhtQhVf0lY42VQWZ630VT1LAB 1qIKg7NqrxOwGmV5JcXZdTXOBOp+MMcKQYkuLOsu1XA1nISTgCqhl5UfL8JiF5gZsHs16g1iqMyz iSIjxpxOAZAhkAk0rxHt+iOWKfKqz7RMkvGrb63t4Fzv7jbNopmIjBDNk/yRIVFvEHhZ8brcTTzR dwESbf7IkKhqSoNMMPVMBWie5I4MkYUnJWmWJICMAIk2d2SIJI7SIPM5+VT5r1LEGxkyd40kXfxj OwzqVpn3UBNvZMgUwaVBJp1+rtwTbc7IHAllAJIQQ+Jqc2+e5IsMsQF94deJRjInca68myf5IkOs P0eSxULuiZws5+ZJrsiQm5woScr0SuRkOa9SxBUZcreLFGu4jlr4rNk464oMwUYLOZZXtAmdLd9V ingiQzL0lyL+nZM6W67NkxyRIXreQj+KtJRAyLtNHmTIWte9DMhExE6XZ/MkP2TIxnDCPyaQYCgD hGOizQ0Z0pmiig/X6RCOzZPckCF9m0jw3ItXkufLb5UiXsgQr3pL8KDAjOT58mue5IQMhbE1S3Ri ZmTP98hrTicnZCiM4AufZr8SPmFezZN8kKExT0h4z5QRPmFeczr5IENlNqLgBeAZ8RPm1DzJBRk6 94fgo9l74if8xSfR5oIMnc4Ksat5Vkr+jPmsUsQDGVr9W0LPs1pTOGE+iTYHZKh1iQo9aSamccZc VinigAy9KfICB8BzOmf8xGGoiT0yFFe8EHg4+5POGfNItNkjQzM1FLYC7NA6Yw7Nk8yRoXpfCJtn 72mdMYdVipgjQ7XMnQpqZhx6p8y+eZI1MpRjfEHNzJ7eGbNfpYgxMtQrCUImTTOaZ8x8lSLGyFCv VwqZNEVUT5n1KkVskWEw/VDACZ1zumfMunmSCTJ/S9PCYOxVwHVDMsqnfJ54z6RIwwSZBbYtTFop hJtqFdA+46q952epDDKPeNYmk4Yt0RJtJ6V+ymWifWRS12OCzNsCnxmT2F6w0cmI/hmXM6mfmeTb bGIZ2E7AbKheqEkQ9yzOGPVrfLOJg9lkTE+gqs2s80Yk18TALUH7AhLtjyWTC8wGmYdH4gn21+Nb ayeUQK6peZrM1/sDWYPwAy7uHzZzgdkg874k3h759bhYLh7fmlMwYVong0ZcnpbLZ8K5IzDhL2wc PxtkvpY/7zjB/nskdn/hi39suPqCFPTmV4f1960L9FHmBZ99ESh+MZo7w6j6+/IHBPVf4Io9ETXJ BTbLhqaoTIhw5jqQ+SkAfyPbWPzxslxCF31cHJlUZZgh82e5fCtMwuLxnXSe/be4Zg0QilAEtq4D me/lckF8xOQb2NrFw/tiyah7khEyH0vyNxi8Xn+Kr21MFF75I/N7ysPLQ3G8FFbthQ6P1WQrVsOS Ryp+9n1R3LUtNU/uAwdBg7F9BlbxSCUX/jkyqmEI8mj1UfL1vPxTXKbnlmEIzhW9daOxzUEt/OlD 4qsuMTLfx+ULNF1t9Z6Ua9rUuGTVN0xqvh+Wz2I8JV0vZD6eFsh3/22dlcaTmVlz1ReXTn6eFrwf kaMdMl+Py0fsut/ah2/5MdNCTP5Q1jOPiychnpOuDTKXF/yxY0YFL2baiIFlcAz98/JBgCcYa4JM 3ax3Vjr4MNNKTH5Zoa1cq0GGslwFj3+712nkwcy8Y/T66YISEMD/le76y4fMdYr6daPmmTJ/IHLn siD1Eba/qExgkKEoY64x45resDlVsBhpkKEm3+PK7UzHDvYjzkmuIo1MyHyMvSM/mY1rWyNWHvqh NYQgLjJZdBaK0xanZKUZoyB4Pu78qQ8hEFXRFGSyz2A9v76Bnfn9KwVyquGBcZIymacXjD67x+Uj Fe9EQ0VjkYlf77qs/Wy9J9oj+DO5hkHfOTnRtBMkPYRAS0WjkPlc91lgYXZPaknBLxI3Ie1s+26i aSU7hEBRRcORidb971fnnoStIXUx9xQNjTN9MTxyQwh0VTQQmTQYuoDLfOpyPCChIHTrpdRKNPdE ojciQwjUVTQImWzUJXeCCdeT8NySiErqNCflgb8nz/NkoCKL9tEAsUZD875YEE4/yXsnh+SyZtOG EJioyKJ/NOiI2F+/VsNNFBqL9Dp44+8SRirqi8zk69wnPvz4IWul6UMzyem2eadrX/z1Jo6KeiMT kVi18O5maF7rEKU5nSR9JbIMo0Nppc2rIYSfPgsoMlJRT2RIlU6tG4/K+76Yf0R90tp+cpnmLqJ3 dG+1usLtBRBYqagnMhG5hVG7x2A+zh2i04YH+kl2P+HEnIDuCni16uXzgygq6ocM0dWXra47s1rs gtkE/M/1KP9vrWP6x3ZxEY4voqioDzLEy+xB+2+9/Pl9g9GnZqitce4jRodWmdqfzrWGWKqoBzIx +dW628diUDv+G/N2jax7/O4SF8Kjrbe8UxnQda1oFs8Yqug2MhGNUZm2+ffwXuI13yj7DOadJ2vN g8+M+WHhWWUd6yYyVdFtZCit7u40RwKFx+Y8qzGN9sH9vI6OM5/fB58Rr0NCxan2Jc3YqugmMtSe B9A83fH5D/nhAQUElMDf24IZxiq6hQzFJ0g0HtByIWGHBgt5Wyxa1jRjraIbyFB95kjDAf0slw+y tinTla+3ZfP8D9YquoEM5afU/D6g7/bFEjWWckHGLxFU1I0M9bXmGoPyr/eHlwKbPxK2nVKQ7yPC 5a9IKmpFJqbf+dOWyH1//HmWrYGQkoV5fuhYjZKbipqRSVk8b29toJgg/FTUjAyb1vdXpXVKWfip qBEZVs+BjRVXK0XhqKImZJgts8zoMSIKCk8VNSCTsntw8J1R/ijhqqIGZFiul/upgX4pCFcVWfxs HhDLuCaR3VKjiiyONg+IybSFdktNKvqFTGCzlcggMFQ4q+gamYzx4dB+VL2CwvxZU/NuZNg/X2Sv i6pJCW8VWZyNTJH5GwiGGRneKrJ4E2zMjPBG5kpFFm+CjZkR3shcqcjiTrAxM8IbmbqKLO4Em6RJ eCNTV1ENmYDP8ZgR7f4igIpqyDicjseUgHuLACq6ROaT0+GYkabeIoKKLpHh95hgEwD3FBFUdIFM yu1wzLyZniKEii6Q2fM7Htt4pl4ihIosEYye8UzC+6ULFV0gY3E8HpMz9RIhVHRGJuJ4OLa0T3hn KmKo6KyrgOfxmGpeHxFDRWdk5lyPx7TB9RAxVHRGhuvhmDS7j1hCqKhCJuaLjJkBcVsEUVGFzJCU 3/V93yW0VymGiJuyJ3vFB0t6hUxXaOX4Xu3/ft5nfKzfXqVEBolbEpC94oMlukKmPbTykuLtdHux ZZPfCH3808G9vVdNTDHvplyqCOgkT5NN7RpeXXHncPK66Mrz7DCEsP0VMq0LDnvIHoUXm8IbfnVV 7L+9uVddgs6r9c//xfJPBVH4V3ly//uvzv0uVVQuQVy7wvUrDjrwT22Xe4M/n3qDVVQh0+ofsQfb 1BE/dX33qdh/d3OvunSmTP/+j1L+rSIy/yjP7h+dzFyFflnSrZdt3nHPFnTlCeCuSUWe73vtKrqJ zBYelnvw64iHXeoPYRPorb3qMteWmN7MXPmVje1dWf/6FQf7rNoudwLmhLpZ8+B43Ky5eR2ZqOO7 k+ttXceCzN7W7bFXTRx9ienJTHTl+n14icN2vfhhe6QSQ7UmzbYiB3FFq4puItNguwDcvovTObe0 YeUG23d+71VuvHp59UO6EtOPmejKryAdbs7X3kMcNegabfXc2tUOK3tw+Ya7gl/rt6uoDzI5hMKF XwRABohvUrgAgQPClqw4bB+MQIBdVnHuQgN5sZcdFgFR4trl+4OQ0YGYXsxE9Wix8Ci7HCbV7iEH sSO84hibgoXDAVxzcMV3EAzwWIJVaT88+MKBn/PiPIXKgp9P4xD+GlBZCNnMWpDZdzim4huxa3Tg EYHvTOGv4WWxVvBo88yHb6TIQJ73sg9wr8Qu3x+CjB7E9GFmX/crWYhJcdF4YYjUC5EBLDiF5nbg isMoGY0qZqX9gOxsMhhzxlhRWK8npC0/gchklwF2HZnWMhFK4DcoDoY/BROiGDJQfHsaxjuYVqXh DuySxztE+nmvYnO8KvZw8ftDkNGFmB7MBA0XK3ahxTmASwxeJKBEC+sb8FW4LXeEWTVkyykdG1Zs 9QbUWJ5sdkCZiXcCEUmh/dQdigzO4D0bmjcIcgy+rDy+ghcXp0jQUK4QwnZ9LwdYKx+/3yyZ3sTc ZiaoB6LYggMfk0FtokQHGocMhJE5uuLpCnqxGN/iKNxFliTPVnb1BtQrDCMS+MUh3h5eq+g2MjYw EIX2gXtECJR+J4HfEbrwZw/nukBYngTaawVcFoh1/M5KTaQ5MTeZCeqmf4eMP7hPTz7YYMMNhZJ3 4IqjQAIqDdzszllpZY4dbn1MH34jx4EOimI2wIbltRGIqC8yMFbKUNIPGHYgqiC4gmal+GIXWw9c F4BcnffaVcaxs1KTdhHzn/+lg1TINDIT1BMmH1uZcuZTghIdoPwTYGdbXfEEUZRDvA6lizmc03X4 RlgmSijPgchtq92GWRmci0EsAMg+LCoi6wVx2Po5yqowOdBAnvcCRCeFHLorNV3E6CcNzFyoCDqY FBV3wU0LLi/UggsQiMt0CisNWA1k+RN8zzp5dfNWb+DPV4ObLopxvNYku7MNr6DrALFwcGCdwC8E ZhGMQJ0wMhfk4AgM7pWUoJTv90RGZ2KamPm8uodPKDDBikY19zJdQTUXpBi3Ulp1z/p5VXmp9OSH uBS8xQEPsl3D6zKHFaq9rCB78NtgqBTCI/WRM0I20sUDqcjAnfcCga+9SRK/e2jbEHODmajmxA/I O6HA194liXtACob7ukgx8IpDzYE4GMLglVQ4F1YG/L/8fBXwwOR8NRwZnMckmF5wqAnOyg6FEczA +46L3sEDqcjAnfcqDuVUhNCp2z20bZDpjYybY9ePKycgl05wqABjwgOOEuAVh/d5WKXSNgqZ84uw CFZmys9Xg5uwSjui+lul/3hEu8jCcJyaOriQV9bqwhPCExm4aq8StpV9ahiuqmRmHNMNxxTVEiYf gnMqSyxILyE2Dg6OAk64MJLAFAZU8uKzYzvnNsgo4M9XSUqY18fJSxXdGMl2AWopyKPtDYAg8VB8 ksKJFiGs4IHdwHF6eAD0UEUxaC/4yXTTOkCKZG7C325iLlSEHQwKc6HJyLwy0SlvzM1lpQaRtavu 2cuZNAeUoRzKz1cBz7ZWxrN/jWS3BxnnUUT/cmyx3FTC2jjp1LevdmuXu86yzD/+Wwf5n05i2qc0 1Wa3ZG1jk27LPeu1jHcfrve+ni/Dt0emZVaeXqW8f/5nJzH9VLRpDBj9MESerP90FKdKxa5UVCFz xxmZ5rm/OjFzi5h+KsquApAqyN1d5kk95FAv49m/5/4GnJGJcs2ZuUlMLxVtmldgBHFJkv+C4IaR cRpVVCHzyRmZtiupCzO3iemlopYUAye3af8up93v9Da/QibjS8ws15uZHsT0UZHfhgXIt7Ndf2JA TcVvVtG5J5tvw2/HAjM6MNOHGFFUdEaGb/zb1fmmPjP9iBFERWdkXrkeT5ZrzExPYgRR0RkZrusK 3Fj4QW1m/q8nMYKo6GLFMYfj8Zi18nqJECoSZEVO8/DjXiKEii6Q4ViZMasr9hMhVHSpLH45nPFL PUUEFYnxDAPjl4T3TJ+NyHBbVtb4pb4igoqEeB7TvWGhrwigohoyvEpFmUGhrwigohoyKZ/oyqz5 218EUFE9jLjncjyRIaG/8FeRAM/JnhsOBgh/FV0lKzySOGNkBgl3FVncGTZGRngzU1fRdUmE/RRg Y2QGCm8VXSPDPCI36dJQ4a2iX4VX1om/qckMFs4q+l2rnzE9nMAQMFz4qug3MkynfpnHMI0Rvipq GBFkGV5FRv9jhKuKLK52z7gl4V3TbxU1IROzCslnRvcjhaeKGqeq7NkcjmWypdHCUUXNs5vYFKXN XLwJwk9FLRPiWPjKwOh9inBTUQsyKf3ZX2aK+DThpqK2abfU46tZarQ+TXipyOJ0QIYY4ZlpU1H7 5P7IECM8M1xU1NEPsjfEiC5cVGTxMHyGGGJ2hoOKLA4HZIgRnpkuFXU3KsY0kv+1IYYkM8xVdKO3 NSW/gnRg1ExUmKvoZjs04b4Zy4wSEBfGKrrdQf9J0lvOYqNh8sJWRT0WXcjIWT7Tr09HmKqo1zod r2QodiKjXFrCUEX9lnYhQnFgMiXRDU0vFfVdDehz6rjp3MynoiysVNR/AalgiumbRZLqQSqZpKLe YcOANcfS0Ufk7I06mQgTFQ1api59HWP75qYUwxAa+ioaurLh58BHL1hrU4lhLLRVNHwxzOy1/6jG 3d5kSRyEroqscYc07wOv4YUnNdRUNHrJ3SjoOCbn7tX4I+5CSUWTVmnOPoP1vG4D5/P718hYF3Gs DXkVkVnYO4JiDIvAQk5FZi14IwYZI3Tl/wHfsLnNbQEtdQAAAABJRU5ErkJgggAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABeBHQAEgAB AAsBDwAHAAAAAAAAAAAABAAIAAAACAAAAJgAAACYAAAAmAAAAJgAAACYAAAAmAAAAJgAAACYAAAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2 AgAAdgIAAHYCAAB2AgAANgYAADYGAAAGAAAANgYAADYGAAA2BgAAOAIAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAAKgAAAA2BgAANgYAABYAAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAALgAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAABoAQAASAEAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAAsAMAADYGAAAyBgAAGAAAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQA AFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA 6AEAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQ BAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAE AAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQA ACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAA IAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAg BAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAADgBAABYAQAA+AEAAAgCAAAYAgAAVgIAAH4C AAAUAAAAX0gBBG1ICgxuSAoMc0gKDHRICgwAAAAAQAAAYPH/AgBAAAwQAAAAAAAAAAAGAE4AbwBy AG0AYQBsAAAABgAAABOktAAUAENKFgBfSAEEbUgJBHNICQR0SAkEZAABQAEAAgBkAAwQAACXdukA AAAIAFQA7QB0AHUAbABvACAAMQAAACQAAQADJAMGJAEKJgALRgEADcYFAAHQAgATpJABMSQAQCYA YSQDFgA1CIE7CIFDShwAS0gYAE9KAgBRSgIASAACQBEAAgBIAAwQAAAAAAAAAAAIAFQA7QB0AHUA bABvACAAMgAAABkAAgAFJAEHJAAKJgELRgEAE6RoATEkAUAmAQAEAENKGABAAANAIQACAEAADBAA AJd26QAAAAgAVADtAHQAdQBsAG8AIAAzAAAADwADAAYkAAomAgtGAQBAJgIABgA7CIE+KgFGAARA AQACAEYADBAAAJd26QAAAAgAVADtAHQAdQBsAG8AIAA0AAAAFAAEAAomAwtGAQANxgUAAdACgEAm AwcAPioBQ0oYAABMAAVAAQACAEwADBAAAAAAAAAAAAgAVADtAHQAdQBsAG8AIAA1AAAAFgAFAAMk AwomBAtGAQATpDwAQCYEYSQDCwA1CIFPSgAAUUoAAABQAAZAAQACAFAADBAAAAAAAAAAAAgAVADt AHQAdQBsAG8AIAA2AAAAGgAGAAMkAwomBQtGAQATpPAAFKQ8AEAmBWEkAwsANgiBT0oAAFFKAAAA RAAHAAEAAgBEAAwQAAAAAAAAAAAIAFQA7QB0AHUAbABvACAANwAAABoABwADJAMKJgYLRgEAE6Tw ABSkPABAJgZhJAMAAEgACEABAAIASAAMEAAAAAAAAAAACABUAO0AdAB1AGwAbwAgADgAAAAaAAgA AyQDCiYHC0YBABOk8AAUpDwAQCYHYSQDAwA2CIEATgAJQAEAAgBOAAwQAAAAAAAAAAAIAFQA7QB0 AHUAbABvACAAOQAAABoACQADJAMKJggLRgEAE6TwABSkPABAJghhJAMKADUIgTYIgUNKEgBOAEEg 8v+hAE4ADAEAAAAAAAAAABsARgB1AGUAbgB0AGUAIABkAGUAIABwAOEAcgByAGEAZgBvACAAcABy AGUAZABlAHQAZQByAC4AAAAAAFYAaQDz/7MAVgAMAQAAAAAAAAAADABUAGEAYgBsAGEAIABuAG8A cgBtAGEAbAAAACAAOlYLABf2AwAANNYGAAEFAwAANNYGAAEKA2wAYfYDAAACAAsAAAAsAGsg9P/B ACwAAAEAAAAAAAAAAAkAUwBpAG4AIABsAGkAcwB0AGEAAAACAAwAAAAAAEAAHAABAPIAQAAMAAAA AAAAAAAADgBTAGEAbgBnAHIA7QBhACAAbgBvAHIAbQBhAGwAAAAKAA8AD4TQAl6E0AIAAE4AH0AB AAIBTgAMAAAAAAAAAAAACgBFAG4AYwBhAGIAZQB6AGEAZABvAAAAEAAQAAMkAw3GBQABkCQCYSQD DwA1CIFDShIAT0oCAFFKAgAAYgAgQAEAEgFiAAwAAAAAAAAAAAANAFAAaQBlACAAZABlACAAcADh AGcAaQBuAGEAAAAdABEAAyQDDcYIAAL8EpAkAQITpDwAJGQGAQABYSQDAA8ANQiBQ0oSAE9KAgBR SgIAAEIA/g8BACIBQgAMAAAAAAAAAAAABgBCAHUAbABsAGUAdAAAABsAEgAKJgALRg0ADcYHAWgB ATgEBg+EOARehDgEAAAAWAD+TwEAMgFYAAwAAAAAAAAAAAAQAEMAbwB2AGUAcgBQAHIAbwBqAGUA YwB0AE4AYQBtAGUAAAAUABMAAyQDDoQwBhOkKABdhDAGYSQDCgA1CIE7CIFDShwATAD+TwEAQgFM AAwAAAAAAAAAAAAQAEMAbwB2AGUAcgBEAGEAdABlAFYAZQByAHMAaQBvAG4AAAACABQADwA1CIFD ShQAT0oCAFFKAgAAPgD+TzEBUgE+AAwAAAAAAAAAAAAMAEMAbwB2AGUAcgBEAG8AYwBUAHkAcABl AAAABgAVABSkIAMGADYIgTsIgWwA/m/x/wIAbAAEAAAA7zOcAAAADgBIAGUAYQBkAGkAbgBnAFAA cgBlAGYAYQBjAGUAAAAMABYAAyQBE6SQAWEkASkANQiBOwiBQ0ocAE9KAwBRSgMAX0gBBG1IAARu SAAEc0gJBHRICQR1CAEAQAD+TwEAcgFAAAwAAAAAAAAAAAAKAHQAYQBiAGwAZQAgAHQAZQB4AHQA AAAKABcAE6Q8ABSkPAAIAE9KAABRSgAARAD+TwEAggFEAAwAAAAAAAAAAAAJAEMAbwB2AGUAcgBQ AHIAbwBwAAAADAAYAAMkAROkwBJhJAEMAENKHABPSgIAUUoCAEYA/k8BAJIBRgAMAAAAAAAAAAAA DABDAG8AdgBlAHIAUAByAG8AcABTAHUAYgAAAAwAGQADJAETpLQAYSQBBwA1CIFDShIAAGwA/k8B AKIBbAAMAAAAAAAAAAAACABDAG8AdgBlAHIAUwBJAFMAAAAsABoAAyQBE6QUABSkqAIkZAYBAQMl ZAYBAQMmZAYBAQMnZAYBAQMtRCEEYSQBFQA1CIE7CIFCKghDSiAAT0oDAFFKAwAAUAD+TwEAsgFQ AAwAAAAAAAAAAAANAEMAbwB2AGUAcgBDAHUAcwB0AG8AbQBlAHIAAAAMABsAAyQDE6SQAWEkAw8A OwiBQ0ogAE9KAwBRSgMAAFQAFkABAAIAVAAFAQAAAAAAAAAABQBUAEQAQwAgADQAAAAYABwAAyQD DcYFAAGQJAoPhNACXoTQAmEkAxcAQ0oSAE9KAgBRSgIAbUgABG5IAAR1CAEAPAAiQAEAAgA8AAwQ AAAAAAAAAAAIAEUAcADtAGcAcgBhAGYAZQAAAA4AHQAUpHgADcYFAAE4BAADADUIgQBGADEAAQDi AUYADAAAAAAAAAAAABEATABpAHMAdABhACAAYwBvAG4AIABuAPoAbQBlAHIAbwBzAAAACQAeAAom AAtGBwAAAABMABNAAQACAEwABAEAAAAAAAAAAAUAVABEAEMAIAAxAAAADQAfAA3GCAACaAGCJAAK ABkANQiBOwiBT0oCAFFKAgBtSAAEbkgABHUIAQBQABRAAQACAFAABAEAAAAAAAAAAAUAVABEAEMA IAAyAAAAFQAgAA3GCAAC0AKCJABKD4RoAV6EaAEAFgA7CIFPSgIAUUoCAG1IAARuSAAEdQgBUAAV QAEAAgBQAAQBAAAAAAAAAAAFAFQARABDACAAMwAAABgAIQANxgsAA0wEoAWGJAAACg+E0AJehNAC EwBPSgIAUUoCAG1IAARuSAAEdQgBADYAF0ABAAIANgANAQAAAAAAAAAABQBUAEQAQwAgADUAAAAK ACIAD4RwA16EcAMIAE9KAgBRSgIANgAYQAEAAgA2AA0BAAAAAAAAAAAFAFQARABDACAANgAAAAoA IwAPhEwEXoRMBAgAT0oCAFFKAgA2ABlAAQACADYADQEAAAAAAAAAAAUAVABEAEMAIAA3AAAACgAk AA+EKAVehCgFCABPSgIAUUoCADYAGkABAAIANgANAQAAAAAAAAAABQBUAEQAQwAgADgAAAAKACUA D4QEBl6EBAYIAE9KAgBRSgIANgAbQAEAAgA2AA0BAAAAAAAAAAAFAFQARABDACAAOQAAAAoAJgAP hOAGXoTgBggAT0oCAFFKAgBWAP5PAQByAlYADAAAAAAAAAAAAAwAYQBwAHAAZQBuAGQAaQB4ACAA LQAgADEAAAAXACcACiYAC0YMABJk8AAAABOkeAAUpHgAAAwAQIj7/09KAwBRSgMAQAD+T3ECggJA AAwAAAAAAAAAAAAMAEEAcABwAGUAbgBkAGkAeAAgAC0AIAAyAAAACQAoAAomAQtGDAAABABDShQA YAD+TwEAkgJgAAwAAAAAAAAAAAARAEMAbwB2AGUAcgBQAHIAbwBqAGUAYwB0ACAATgBhAG0AZQAA ABEAKQAxJAATpCgADcYFAAEwBgIAEgA1CIE7CIFDShwAT0oCAFFKAgBgAP5PAQCiAmAADAAAAAAA AAAAAAsAQgBsAG8AYwBrACAAcQB1AG8AdABlAAAAIAAqAAMkAw6EaAEPhGgBE6Q8ABSkPABdhGgB XoRoAWEkAxAAQ0oXAEtIHABPSgQAUUoEAD4A/g8BALICPgAMAAAAAAAAAAAADABCAHUAbABsAGUA dABJAG4AZABlAG4AdAAAAAwAKwAKJgALRjUCMSQAAABMAP5PAQDCAkwADAAAAAAAAAAAAA0AVABh AGIAbABlAEgAZQBhAGQAaQBuAGcAcwAAAAoALAATpHgAFKR4AA4ANQiBOwiBT0oCAFFKAgBOAFQA AQDSAk4ADAAAAAAAAAAAAA8AVABlAHgAdABvACAAZABlACAAYgBsAG8AcQB1AGUAAAAWAC0ADoSg BQ+EoAUUpHgAXYSgBV6EoAUAAEYAQgABAOICRgAMAAAAAAAAAAAAEwBUAGUAeAB0AG8AIABpAG4A ZABlAHAAZQBuAGQAaQBlAG4AdABlAAAABgAuABSkeAAAAFAAUAABAPICUAAMAAAAAAAAAAAAFQBU AGUAeAB0AG8AIABpAG4AZABlAHAAZQBuAGQAaQBlAG4AdABlACAAMgAAAAwALwASZOABAQAUpHgA AABOAFFAAQACA04ADAAAAAAAAAAAABUAVABlAHgAdABvACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBu AHQAZQAgADMAAAAGADAAFKR4AAQAQ0oQAGoATQDhAhIDagAMAAAAAAAAAAAAIwBUAGUAeAB0AG8A IABpAG4AZABlAHAAZQBuAGQAaQBlAG4AdABlACAAcAByAGkAbQBlAHIAYQAgAHMAYQBuAGcAcgDt AGEAAAAKADEAEYTSAGCE0gAAAFYAQwABACIDVgAMAAAAAAAAAAAAFwBTAGEAbgBnAHIA7QBhACAA ZABlACAAdABlAHgAdABvACAAbgBvAHIAbQBhAGwAAAAOADIAD4RoARSkeABehGgBAABuAE4AIQMy A24ADAAAAAAAAAAAACUAVABlAHgAdABvACAAaQBuAGQAZQBwAGUAbgBkAGkAZQBuAHQAZQAgAHAA cgBpAG0AZQByAGEAIABzAGEAbgBnAHIA7QBhACAAMgAAAAoAMwARhNIAYITSAAAAaABSAAEAQgNo AAwAAAAAAAAAAAAdAFMAYQBuAGcAcgDtAGEAIAAyACAAZABlACAAdAAuACAAaQBuAGQAZQBwAGUA bgBkAGkAZQBuAHQAZQAAABQANAAPhGgBEmTgAQEAFKR4AF6EaAEAAGYAU0ABAFIDZgAMAAAAAAAA AAAAHQBTAGEAbgBnAHIA7QBhACAAMwAgAGQAZQAgAHQALgAgAGkAbgBkAGUAcABlAG4AZABpAGUA bgB0AGUAAAAOADUAD4RoARSkeABehGgBBABDShAAMAA/AAEAYgMwAAwAAAAAAAAAAAAGAEMAaQBl AHIAcgBlAAAACgA2AA+E4BBehOAQAABAAB5AAQByA0AADAFsAAAAAAAAABAAVABlAHgAdABvACAA YwBvAG0AZQBuAHQAYQByAGkAbwAAAAIANwAEAENKFAAmAEwAAQACACYADAAAAAAAAAAAAAUARgBl AGMAaABhAAAAAgA4AAAATABZQAEAkgNMAAwBAAAAAAAAAAASAE0AYQBwAGEAIABkAGUAbAAgAGQA bwBjAHUAbQBlAG4AdABvAAAABgA5AC1EIAEIAE9KBQBRSgUARgArQAEAogNGAAwBAAAAAAAAAAAT AFQAZQB4AHQAbwAgAG4AbwB0AGEAIABhAGwAIABmAGkAbgBhAGwAAAACADoABABDShQAZgAkQAEA sgNmAAwAAAAAAAAAAAAPAEQAaQByAGUAYwBjAGkA8wBuACAAcwBvAGIAcgBlAAAAIQA7AA+EQAsY hPz/GYT0/xqE8B4bJoArRLwHL4S0AF6EQAsADABDShgAT0oCAFFKAgBGACVAAQDCA0YADAAAAAAA AAAAAA8AUgBlAG0AaQB0AGUAIABkAGUAIABzAG8AYgByAGUAAAACADwADABDShQAT0oCAFFKAgA8 AB1AAQDSAzwADAEAAAAAAAAAAA4AVABlAHgAdABvACAAbgBvAHQAYQAgAHAAaQBlAAAAAgA9AAQA Q0oUADwACgABAAIAPAANAQAAAAAAAAAACADNAG4AZABpAGMAZQAgADEAAAASAD4AD4TcABGEJP9e hNwAYIQk/wAAPAALAAEAAgA8AA0BAAAAAAAAAAAIAM0AbgBkAGkAYwBlACAAMgAAABIAPwAPhLgB EYQk/16EuAFghCT/AAA8AAwAAQACADwADQEAAAAAAAAAAAgAzQBuAGQAaQBjAGUAIAAzAAAAEgBA AA+ElAIRhCT/XoSUAmCEJP8AADwADQABAAIAPAANAQAAAAAAAAAACADNAG4AZABpAGMAZQAgADQA AAASAEEAD4RwAxGEJP9ehHADYIQk/wAAPAAOAAEAAgA8AA0BAAAAAAAAAAAIAM0AbgBkAGkAYwBl ACAANQAAABIAQgAPhEwEEYQk/16ETARghCT/AAA8AA8AAQACADwADQEAAAAAAAAAAAgAzQBuAGQA aQBjAGUAIAA2AAAAEgBDAA+EKAURhCT/XoQoBWCEJP8AADwAEAABAAIAPAANAQAAAAAAAAAACADN AG4AZABpAGMAZQAgADcAAAASAEQAD4QEBhGEJP9ehAQGYIQk/wAAPAARAAEAAgA8AA0BAAAAAAAA AAAIAM0AbgBkAGkAYwBlACAAOAAAABIARQAPhOAGEYQk/16E4AZghCT/AAA8ABIAAQACADwADQEA AAAAAAAAAAgAzQBuAGQAaQBjAGUAIAA5AAAAEgBGAA+EvAcRhCT/XoS8B2CEJP8AAEgAIUABAOID SAAMAQAAAAAAAAAAEABUAO0AdAB1AGwAbwAgAGQAZQAgAO0AbgBkAGkAYwBlAAAAAgBHAAsANQiB T0oCAFFKAgAANgAvAAEAggQ2AAwAAAAAAAAAAAAFAEwAaQBzAHQAYQAAABIASAAPhGgBEYSY/l6E aAFghJj+AAA6ADIAAQCSBDoADAAAAAAAAAAAAAcATABpAHMAdABhACAAMgAAABIASQAPhNACEYSY /l6E0AJghJj+AAA6ADMAAQCiBDoADAAAAAAAAAAAAAcATABpAHMAdABhACAAMwAAABIASgAPhDgE EYSY/l6EOARghJj+AAA6ADQAAQCyBDoADAAAAAAAAAAAAAcATABpAHMAdABhACAANAAAABIASwAP hKAFEYSY/l6EoAVghJj+AAA6ADUAAQDCBDoADAAAAAAAAAAAAAcATABpAHMAdABhACAANQAAABIA TAAPhAgHEYSY/l6ECAdghJj+AABGADAAAQDSBEYADQAAAAAAAAAAABEATABpAHMAdABhACAAYwBv AG4AIAB2AGkA8QBlAHQAYQBzAAAACQBNAAomAAtGAgAAAABKADYAAQDiBEoADQAAAAAAAAAAABMA TABpAHMAdABhACAAYwBvAG4AIAB2AGkA8QBlAHQAYQBzACAAMgAAAAkATgAKJgALRgMAAAAASgA3 AAEA8gRKAA0AAAAAAAAAAAATAEwAaQBzAHQAYQAgAGMAbwBuACAAdgBpAPEAZQB0AGEAcwAgADMA AAAJAE8ACiYAC0YEAAAAAEoAOAABAAIFSgANAAAAAAAAAAAAEwBMAGkAcwB0AGEAIABjAG8AbgAg AHYAaQDxAGUAdABhAHMAIAA0AAAACQBQAAomAAtGBQAAAABKADkAAQASBUoADQAAAAAAAAAAABMA TABpAHMAdABhACAAYwBvAG4AIAB2AGkA8QBlAHQAYQBzACAANQAAAAkAUQAKJgALRgYAAAAARgBE AAEAIgVGAAwAAAAAAAAAAAAPAEMAbwBuAHQAaQBuAHUAYQByACAAbABpAHMAdABhAAAADgBSAA+E aAEUpHgAXoRoAQAASgBFAAEAMgVKAAwAAAAAAAAAAAARAEMAbwBuAHQAaQBuAHUAYQByACAAbABp AHMAdABhACAAMgAAAA4AUwAPhNACFKR4AF6E0AIAAEoARgABAEIFSgAMAAAAAAAAAAAAEQBDAG8A bgB0AGkAbgB1AGEAcgAgAGwAaQBzAHQAYQAgADMAAAAOAFQAD4Q4BBSkeABehDgEAABKAEcAAQBS BUoADAAAAAAAAAAAABEAQwBvAG4AdABpAG4AdQBhAHIAIABsAGkAcwB0AGEAIAA0AAAADgBVAA+E oAUUpHgAXoSgBQAASgBIAAEAYgVKAAwAAAAAAAAAAAARAEMAbwBuAHQAaQBuAHUAYQByACAAbABp AHMAdABhACAANQAAAA4AVgAPhAgHFKR4AF6ECAcAAEoAOgABAHIFSgAMAAAAAAAAAAAAEwBMAGkA cwB0AGEAIABjAG8AbgAgAG4A+gBtAGUAcgBvAHMAIAAyAAAACQBXAAomAAtGCAAAAABKADsAAQCC BUoADAAAAAAAAAAAABMATABpAHMAdABhACAAYwBvAG4AIABuAPoAbQBlAHIAbwBzACAAMwAAAAkA WAAKJgALRgkAAAAASgA8AAEAkgVKAAwAAAAAAAAAAAATAEwAaQBzAHQAYQAgAGMAbwBuACAAbgD6 AG0AZQByAG8AcwAgADQAAAAJAFkACiYAC0YKAAAAAEoAPQABAKIFSgAMAAAAAAAAAAAAEwBMAGkA cwB0AGEAIABjAG8AbgAgAG4A+gBtAGUAcgBvAHMAIAA1AAAACQBaAAomAAtGCwAAAABuAC1g8f+y BW4ADAEAAAAAAAAAAAsAVABlAHgAdABvACAAbQBhAGMAcgBvAAAAJgBbAA3GHQAJ4AHAA6AFgAdg CUALIA0AD+AQAAAAAAAAAAAAE6S0ABgAT0oGAFFKBgBfSAEEbUgJBHNICQR0SAkEfgBJQAEAwgV+ AAwAAAAAAAAAAAAVAEUAbgBjAGEAYgBlAHoAYQBkAG8AIABkAGUAIABtAGUAbgBzAGEAagBlAAAA LgBcAA+EOAQRhMj7JGQGAQABJWQGAQABJmQGAQABJ2QGAQABLUQAEF6EOARghMj7DABDShgAT0oC AFFKAgBAAE8AAQACAEAADAAAAAAAAAAAABIARQBuAGMAYQBiAGUAegBhAGQAbwAgAGQAZQAgAG4A bwB0AGEAAAACAF0AAABKAFpAAQDiBUoADABzAAAAAAAwBhEAVABlAHgAdABvACAAcwBpAG4AIABm AG8AcgBtAGEAdABvAAAAAgBeAAwAQ0oUAE9KBgBRSgYAKABLAAEAAgAoAAwAAAAAAAAAAAAGAFMA YQBsAHUAZABvAAAAAgBfAAAALgBAAAEAAgYuAAwAAAAAAAAAAAAFAEYAaQByAG0AYQAAAAoAYAAP hOAQXoTgEAAASABKQAEAEgZIAAwQAAAAAAAAAAAJAFMAdQBiAHQA7QB0AHUAbABvAAAADwBhAAMk ARSkPABAJgFhJAEADABDShgAT0oCAFFKAgBOACwAAQACAE4ADAEAAAAAAAAAABEAVABlAHgAdABv ACAAYwBvAG4AIABzAGEAbgBnAHIA7QBhAAAAEgBiAA+E3AARhCT/XoTcAGCEJP8AAFgAIwABAAIA WAAMAQAAAAAAAAAAFgBUAGEAYgBsAGEAIABkAGUAIABpAGwAdQBzAHQAcgBhAGMAaQBvAG4AZQBz AAAAEgBjAA+EuAERhEj+XoS4AWCESP4AAE4APkABAEIGTgAMEAAAAAAAAAAABgBUAO0AdAB1AGwA bwAAABMAZAADJAETpPAAFKQ8AEAmAGEkAQATADUIgUNKIABLSBwAT0oCAFFKAgAAVgAuQAEAAgBW AAwBAAAAAAAAAAATAEUAbgBjAGEAYgBlAHoAYQBkAG8AIABkAGUAIABsAGkAcwB0AGEAAAAGAGUA E6R4AA8ANQiBQ0oYAE9KAgBRSgIAAFIAWwABAGIGUgAMAAAAAAAAAAAAGwBGAGkAcgBtAGEAIABk AGUAIABjAG8AcgByAGUAbwAgAGUAbABlAGMAdAByAPMAbgBpAGMAbwAAAAIAZgAAAD4AYEABAHIG PgAMAAAAAAAAAAAADgBEAGkAcgBlAGMAYwBpAPMAbgAgAEgAVABNAEwAAAACAGcABgA2CIFdCIFa AGVAAQCCBloADABxAAAAAAAwBhcASABUAE0ATAAgAGMAbwBuACAAZgBvAHIAbQBhAHQAbwAgAHAA cgBlAHYAaQBvAAAAAgBoABAAQ0oUAE9KBgBRSgYAXkoGADwAXkABAJIGPAAMAAAAAAAAAAAADABO AG8AcgBtAGEAbAAgACgAVwBlAGIAKQAAAAIAaQAIAENKGABhShgARAAnYPL/oQZEAAwNAABhXM0A MAYSAFIAZQBmAC4AIABkAGUAIABjAG8AbQBlAG4AdABhAHIAaQBvAAAACABDShAAYUoQAEwAakBx A3IDTAAMDW0AYVzNADAGFQBBAHMAdQBuAHQAbwAgAGQAZQBsACAAYwBvAG0AZQBuAHQAYQByAGkA bwAAAAIAawAGADUIgVwIgUAA/g+iAMEGQAAMATcAYVzNAAAAFABUAGUAeAB0AG8AIABjAG8AbQBl AG4AdABhAHIAaQBvACAAQwBhAHIAAAAAAFAA/m/y/9EGUAAMAWsAYVzNADAGGQBBAHMAdQBuAHQA bwAgAGQAZQBsACAAYwBvAG0AZQBuAHQAYQByAGkAbwAgAEMAYQByAAAABgA1CIFcCIFQAJlAAQDi BlAADA1vAGFczQAwBg4AVABlAHgAdABvACAAZABlACAAZwBsAG8AYgBvAAAABgBuABOkAAAUAENK EABPSgUAUUoFAF5KBQBhShAAUAD+b/L/8QZQAAwBbgBhXM0AMAYSAFQAZQB4AHQAbwAgAGQAZQAg AGcAbABvAGIAbwAgAEMAYQByAAAAFABDShAAT0oFAFFKBQBeSgUAYUoQADwAVWDy/wEHPAAMDAAA JXc6ADAGDABIAGkAcABlAHIAdgDtAG4AYwB1AGwAbwAAAAwAPioBQioAcGgAAP8AWgD+b/L/EQda AAwAaAAldzoAMAYbAEgAVABNAEwAIABjAG8AbgAgAGYAbwByAG0AYQB0AG8AIABwAHIAZQB2AGkA bwAgAEMAYQByAAAADABPSgYAUUoGAF5KBgBAALJg8f8iB0AADgUAAJNcvQAwBggAUgBlAHYAaQBz AGkA8wBuAAAAAgByABQAQ0oWAF9IAQRtSAkEc0gJBHRICQRWAP5v8v8xB1YADABeAHRJzwAwBhUA VABlAHgAdABvACAAcwBpAG4AIABmAG8AcgBtAGEAdABvACAAQwBhAHIAAAAUAE9KBgBRSgYAbUgJ BHNICQR0SAkEUEsDBBQABgAIAAAAIQDp3g+//wAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnht bKyRy07DMBBF90j8g+UtSpyyQAgl6YLHjseifMDImSQWydiyp1X790zSVEKoIBZsLNkz954743K9 Hwe1w5icp0qv8kIrJOsbR12l3zdP2a1WiYEaGDxhpQ+Y9Lq+vCg3h4BJiZpSpXvmcGdMsj2OkHIf kKTS+jgCyzV2JoD9gA7NdVHcGOuJkTjjyUPX5QO2sB1YPe7l+Zgk4pC0uj82TqxKQwiDs8CS1Oyo +UbJFkIuyrkn9S6kK4mhzVnCVPkZsOheZTXRNajeIPILjBLDsAyJX89nIBkt5r87nons29ZZbLzd jrKOfDZezE7B/xRg9T/oE9PMf1t/AgAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAA AF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiE pO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCV Eg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVF BG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoA AAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuu u/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSN E99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQA BgAIAAAAIQDDc3oZrAYAAKYbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZTW8bRRi+I/Ef RntvYyd2Gkd1qtixG0jTRrFb1ON4d7w7zezOamac1DfUHpGQEAVxoBI3Dgio1Epcyq8JFEGR+hd4 Z2Z3vROvSdJGUEFzaL2zz/v9Me/MXr12P2bokAhJedL26pdrHiKJzwOahG3v9rB/ac1DUuEkwIwn pO1NifSubbz/3lW8riISEwT0iVzHbS9SKl1fWpI+LGN5mackgXdjLmKs4FGES4HAR8A3ZkvLtdrq Uoxp4qEEx8B2CDQoIOjWeEx94m3k7HsMZCRK6gWfiYFmTjKaEjY4qGuEnMouE+gQs7YHkgJ+NCT3 lYcYlgpetL2a+fOWNq4u4fWMiKkFtCW6vvnL6DKC4GDZyBThqBBa7zdaV7YK/gbA1Dyu1+t1e/WC nwFg3wdLrS5lno3+Wr2T8yyB7M953t1as9Zw8SX+K3M6tzqdTrOV6WKZGpD92ZjDr9VWG5vLDt6A LL45h290NrvdVQdvQBa/OofvX2mtNly8AUWMJgdzaB3Qfj/jXkDGnG1XwtcAvlbL4DMUZEORXVrE mCdqUa7F+B4XfQBoIMOKJkhNUzLGPuRxF8cjQbEWgNcJLr2xS76cW9KykPQFTVXb+zDFUBMzfq+e f//q+VN0/ODZ8YOfjh8+PH7wo2XkUG3jJCxTvfz2sz8ff4z+ePrNy0dfVONlGf/rD5/88vPn1UAo n5k6L7588tuzJy+++vT37x5VwDcFHpXhQxoTiW6SI7TPYzDMeMXVnIzE+SiGEaZlis0klDjBWkoF /56KHPTNKWZZdBw9OsT14B0B7aMKeH1yz1F4EImJohWSd6LYAe5yzjpcVHphR8squXk4ScJq4WJS xu1jfFglu4sTJ769SQp9M09Lx/BuRBw19xhOFA5JQhTS7/gBIRXW3aXU8esu9QWXfKzQXYo6mFa6 ZEhHTjbNiLZpDHGZVtkM8XZ8s3sHdTirsnqLHLpIqArMKpQfEua48TqeKBxXsRzimJUdfgOrqErJ wVT4ZVxPKoh0SBhHvYBIWUVzS4C9paDvYOhYlWHfZdPYRQpFD6p43sCcl5Fb/KAb4Titwg5oEpWx H8gDSFGM9riqgu9yt0L0M8QBJwvDfYcSJ9ynd4PbNHRUmiWIfjMRFbG8TriTv4MpG2NiWg00dadX xzT5u8bNKHRuK+HiGje0yhdfP67Q+21t2Zuwe1XVzPaJRr0Id7I9d7kI6NvfnbfwJNkjUBDzW9S7 5vyuOXv/+ea8qJ4vviXPujA0aD2L2EHbjN3xwql7TBkbqCkjN6QZvCXsPUEfFjWdOXOS4hSWRvBT VzIIcHChwIYGCa4+oioaRDiFob3uaSahzFiHEqVcwmHRLFfy1ngY/JU9ajb1IcR2DonVLg/s8ope zs8aBRujVWgOtLmgFc3grMJWrmRMwbbXEVbXSp1ZWt2oZpqiI60wWbvYHMrB5YVpsFh4E4YaBKMQ eHkVTv1aNBx2MCOB9ruNUR4WE4WLDJGMMNwpmOuAprZ7PkZ1E6Q8V+YM0XbYZNAHx1O8VpLW0mzf QNpZglQW11ggLo/em0Qpz+BZlIDbyXJkSbk4WYKO2l6rudz0kI/TtjeGczL8jFOIutRzJGYhXDf5 Sti0P7WYTZXPotnKDXOLoA5XH9bvcwY7fSAVUm1hGdnUMK+yFGCJlmT1X26CWy/KgIpudDYtVtYg Gf41LcCPbmjJeEx8VQ52aUX7zj5mrZRPFBGDKDhCIzYR+xjCr1MV7AmohOsO0xH0A9zNaW+bV25z zoqufCNmcHYdszTCWbvVJZpXsoWbhlToYJ5K6oFtlbob485viin5CzKlnMb/M1P0fgK3DyuBjoAP l8MCI10pbY8LFXHoQmlE/b6AwcH0DsgWuN+F15BUcEVt/hfkUP9va87yMGUNh0i1T0MkKOxHKhKE 7EFbMtl3CrN6tndZlixjZDKqpK5MrdojckjYUPfAVb23eyiCVDfdJGsDBncy/9znrIJGoR5yyvXm dLJi77U18E9PPraYwSi3D5uBJvd/oWIxHsx2VUtvyPO9t2yIfjEbsxp5VYCw0lbQysr+NVU451Zr O9acxcvNXDmI4rzFsFgMRCncISH9D+x/VPjMfu3QG+qQ70NvRfDxQjODtIGsvmQHD6QbpF0cweBk F20yaVbWtdnopL2Wb9YXPOkWck84W2t2lnif09nFcOaKc2rxIp2dedjxtV1b6GqI7MkShaVxfpAx gTEfyspfsvjoHgR6C74ZTJiSJpngO5XAMEMPTB1A8VuJhnTjLwAAAP//AwBQSwMEFAAGAAgAAAAh AA3RkJ+2AAAAGwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOE j00KwjAUhPeCdwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoI OumVcZrBbbjsjkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKj pkHIu9BI93V9oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6 usTfAAAA//8DAFBLAQItABQABgAIAAAAIQDp3g+//wAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAA AAAAMAEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAA AAAAGQIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAw3N6GawG AACmGwAAFgAAAAAAAAAAAAAAAADWAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAI AAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAALYJAAB0aGVtZS90aGVtZS9fcmVscy90aGVt ZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAsQoAAAAAPD94bWwgdmVyc2lvbj0iMS4w IiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0KPGE6Y2xyTWFwIHhtbG5zOmE9 Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9tYWluIiBi ZzE9Imx0MSIgdHgxPSJkazEiIGJnMj0ibHQyIiB0eDI9ImRrMiIgYWNjZW50MT0iYWNjZW50MSIg YWNjZW50Mj0iYWNjZW50MiIgYWNjZW50Mz0iYWNjZW50MyIgYWNjZW50ND0iYWNjZW50NCIgYWNj ZW50NT0iYWNjZW50NSIgYWNjZW50Nj0iYWNjZW50NiIgaGxpbms9ImhsaW5rIiBmb2xIbGluaz0i Zm9sSGxpbmsiLz4AAAAAnzAAAAsAAFAAAAAA/////wAAAAADAAAABgAAAAYAAAAJAAAADAAAAAwA AAAMAAAADgAAAA4AAAAOAAAADgAAAA4AAAARAAAAAAgAABASAAAQFwAArx4AAAQsAACTOAAAnzgA AB0AAAAgAAAAIQAAACMAAAAlAAAAJwAAAAAIAAC2EQAA5hwAABArAACcMgAAnzgAAB4AAAAfAAAA IgAAACQAAAAmAAAARTAAAHMwAACMMAAAnzAAABNYFP8VgA8AAPBAAAAAAAAG8CAAAAABCAAAAwAA AAIAAAACAAAAAQAAAAIAAAACAAAAAQAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAEPAALwSAAA ACAACPAIAAAAAQAAAAAIAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAACAAABQAAAAAPAALwkgAAABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAA AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAAB BAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA //8BAAAADQBfAFQAbwBjADQAMwAxADYAMQA0ADgAMwA1AJswAACgMAAAAAAAAJswAACgMAAAAAAA AKkoAAC2KAAACi4AABEuAAB4LwAAfS8AAIcvAACQLwAApy8AAK4vAAAvMAAANTAAAI8wAACRMAAA kjAAAJQwAACVMAAAlzAAAJgwAACaMAAAmzAAAJ0wAACgMAAABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAHAAIABwACAAcAAgAHAAIABwACAAAAAACVCwAAmAsAAPMpAAD2KQAAUCoAAFMqAADsLAAA 9ywAAG0vAABuLwAAmS8AAK8vAAD9LwAA/i8AAI8wAACRMAAAkjAAAJQwAACVMAAAlzAAAJgwAACa MAAAmzAAAJ0wAACgMAAABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcABwACAAcAAgAHAAIA BwACAAcAAgAAAAAA9QUAAAIGAAD6BgAAEAcAANwHAADnBwAAEQoAAB0KAACYDAAAywwAADUOAABK DgAAdBAAAIsQAAAUEQAAJxEAAJASAACZEgAAExMAAB4TAADYFAAA5RQAALIVAADHFQAAGhYAAC4W AAAzGQAARRkAAPgfAAAXIAAAECMAADojAAD/JAAAICUAAPolAAAIJgAAbicAAIInAACpJwAAwScA ADIpAABXKQAA6i0AAP8tAABELwAAVy8AAD4wAACOMAAAjzAAAJEwAACSMAAAlDAAAJUwAACXMAAA mDAAAJowAACbMAAAnTAAAKAwAAAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAcAAgAHAAIABwACAAcAAgAHAAIAAAAAAHwAAACTAAAAlwAAAJcAAABXAwAAYwMAAL4GAADC BgAAygYAAMoGAAAjCAAAJAgAAG4IAADOCAAA3wgAAOEIAADiCAAA4ggAAMQJAADFCQAADgoAAA4K AAAPCgAAEAoAAFQKAAB4CgAATAsAAEwLAAC3CwAAtwsAALkLAADACwAARAwAAEQMAABFDAAAlQwA AJcMAAC2DAAA4wwAAP8MAAAWDgAAHA4AAB0OAAAdDgAAUQ4AAGAOAACADgAAgA4AAIgOAACPDgAA ug4AALoOAADYDgAA2g4AAPUOAAD4DgAAFQ8AABUPAAA+DwAAPg8AAEQPAABJDwAATA8AAEwPAABx DwAAcQ8AAKYPAACtDwAAARAAAAIQAAAKEAAAERAAAIsQAAAUEQAAJxEAACsRAAAsEQAALBEAAGsS AABrEgAAbhIAAG4SAACPEgAAjxIAAB4TAADaEwAA1xQAANcUAADlFAAA5hQAALwWAADFFgAAvhcA AMgXAADyFwAA8xcAAPQXAAD0FwAAmRwAALQcAACuHQAAzB0AAFoeAABaHgAAyB4AAMgeAADdIAAA 9iAAAPcgAAD3IAAASyEAAEshAAAjIwAAOSMAAAMkAAAEJAAACSUAAB8lAABEJQAASiUAAFUlAABa JQAATCcAAEwnAABDLwAARC8AAEUwAACNMAAAjjAAAI8wAACRMAAAkjAAAJQwAACVMAAAlzAAAJgw AACaMAAAmzAAAJ0wAACgMAAAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMAAgAHAAIABwAC AAcAAgAHAAIABwACAA4AfP///ywojG1aAP8P/w//D/8P/w//D/8P/w8BAH3///80ihZVWQD/D/8P /w//D/8P/w//D/8PAQB+////SEi0jFgA/w//D/8P/w//D/8P/w//DwEAf////x5iFI9XAP8P/w// D/8P/w//D/8P/w8BAID///9UtGJGUQD/D/8P/w//D/8P/w//D/8PAQCB////NlfUsFAA/w//D/8P /w//D/8P/w//DwEAgv///05MkOJPAP8P/w//D/8P/w//D/8P/w8BAIP////qQ8jmTgD/D/8P/w// D/8P/w//D/8PAQCI////LqB+3x4AAAAAAAAAAAAAAAAAAAAAAAEAif///6iQZixNAP8P/w//D/8P /w//D/8P/w8BAPv/////////AQACAAMABAAFAAYABwAIAAkAAAD6E9VOULRKW/8P/w//D/8P/w// D/8P/w//DxAAnToXVOrjhL0SAAAAAAAAAAAAAAAAAAAAAAABACdyVXKe97wU/w8AAAAAAAAAAAAA AAAAAAAAAQABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdg hJj+AgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAF YISY/gIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhDgEEYSY/hXGBQABOAQGXoQ4 BGCEmP4CAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E 0AJghJj+AgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZe hAgHYISY/k9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKAFEYSY /hXGBQABoAUGXoSgBWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAQBRSgEAbygAAQC38AEAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP4CAAAALgABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBv KAABALfwAQAAAABAAQAAAAAAAAAAAJAAAAAAAAAAAwAAAD4qAAIAAAAuAAEAAAAAQAEDAAAAAAAA AACQAAAAAAAAAAMAAAA+KgADAAAALgABAAEAAAAAQAEDBQAAAAAAAACQAAAAAAAAAAMAAAA+KgAF AAAALgABAC4AAgABAAAAAEABAwUHAAAAAAAAkAAAAAAAAAADAAAAPioABwAAAC4AAQAuAAIALgAD AAEAAAAAQAEDBQcJAAAAAACQAAAAAAAAAAAAAAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAQAED BQcJCwAAAACQAAAAAAAAAAAAAAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAEABAwUHCQsN AAAAkAAAAAAAAAAAAAAADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAQAEDBQcJCw0P AACQAAAAAAAAAAAAAAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAQAEDBQcJ Cw0PEQCQAAAAAAAAAAAAAAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAAVEAAAD4TQAhGEmP5ehNACYISY/k9KAQBRSgEAbygAh2gAAAAA iEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZEAAAD4SgBRGEmP5ehKAFYISY/k9KBgBR SgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRAAAA+EcAgR hJj+XoRwCGCEmP5PSgcAUUoHAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAFRAAAA+EQAsRhJj+XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAGRAAAA+EEA4RhJj+XoQQDmCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACI SAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhOAQEYSY/l6E4BBghJj+T0oHAFFK BwBvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUQAAAPhLATEYSY/l6E sBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkQ AAAPhIAWEYSY/l6EgBZghJj+T0oGAFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAAVEAAAD4RQGRGEmP5ehFAZYISY/k9KBwBRSgcAbygAh2gAAAAAiEgAAAEA p/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oB AFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EaAERhJj+FcYFAAFoAQZe hGgBYISY/kNKEgBPSgEAUUoBAG8oAAEAt/ARAAAA+////wAAAAAAAAAAAAAAAIn///8AAAAAAAAA AAAAAACD////AAAAAAAAAAAAAAAAgv///wAAAAAAAAAAAAAAAIH///8AAAAAAAAAAAAAAACA//// AAAAAAAAAAAAAAAAiP///wAAAAAAAAAAAAAAAH////8AAAAAAAAAAAAAAAB+////AAAAAAAAAAAA AAAAff///wAAAAAAAAAAAAAAAHz///8AAAAAAAAAAAAAAAAnclVyAAAAAAAAAAAAAAAAnToXVAAA AAAAAAAAAAAAAPv///8AAAAAAAAAAAAAAAD6E9VOAAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAA APv///8AAAAAAAAAAAAAAAD///////////////////////////////////////////////////// ////////////////////////////////////////DgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD//w4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgABAAkEAwAJBAUACQQBAAkEAwAJBAUA CQQBAAkEAwAJBAUACQQAAAAAAQAAAAIACQQBAggABgDGA1MbAAAAAAAAAAAAAQIAAgBWIHBJAAAA AAAAAAAAAQIAAgATREJXAAAAAAAAAAAAAQIAAgB0UCNoAAAAAAAAAAAAAQIAAgBRVjxtAAAAAAAA AAAAAQIAAgA8DSRzAAAAAAAAAAAAAQIAAgBTAAAABAAAAAgAAADlAAAAAAAAAFIAAADIdQMAqTsF AEItBgBLewcAnXkIAI0kCQBXRREAa3ASAFBFHQDYRCQAXAclALRYJQDyaCYAZx0nAIsOMAAKTzMA kXs3AHooOQDmbzkAJXc6ABIjPwCrPkEAmhlDAJcvRQAUdEUASXtGALdUSwB6f0sAzxlMALwvTQBr Z08AfU9RAHg/UgATGlUADGJXAL4pWwBuVVsAVQ9cABcXXgDxQ2YAIBNxACIueAAHKnsAHGaBAP4v gwCTR4kA0zWKAO8znADFVJ0AzUKeAAQ3pQDlKacA8F2pAJtnqgAZPLEATHOxAEFmtQDiPLgA8l+4 AAYluQCTXL0AQn6+ALIHvwB9Xb8A6hbBALVSwwCRI8wAYVzNAOwszwB0Sc8A8lXSAO5V1gBHXtYA 3ATYAPsK5wCXdukAoDrrAJIB7gBLDvIALx79AJxg/QD8BP4A9gb+AAAAAACPMAAAkTAAAAAAAAAB AAAA/0ADgAEAdAMAAHQDAAAAAAAAAQABAHQDAAAAAAAAdAMAAAAAAAACEAAAAAAAAACfMAAAWAAA EABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA //8AAAAA//8AAAIA//8AAAAACQAAAEcekAEAAAICBgMFBAUCAwT/KgDgQXgAwAkAAAAAAAAA/wEA AAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUekAECAAUFAQIBBwYCBQcAAAAA AAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMukAEAAAILBgQCAgICAgT/KgDgQ3gA wAkAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA/LoQDAAACCwoEAgECAgIEhwIAAAAAAAAAAAAA AAAAAJ8AAAAAAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAMx6QAQAAAgIGAwUEBQIDBP8qAOBB eADACQAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAAADUukAEAAAILBgQDBQQEAgT/LgDhW2AAwCkA AAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAAAD89kAEAAAIHAwkCAgUCBAT/KgDgQ3gAwAkAAAAA AAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7DpABAgAFAAAAAAAAAAAAAAAAAAAA ABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAABBHpABAAACBAUDBQQGAwIE/wIA 4P8kAEIAAAAAAAAAAJ8BAAAAAAAAQwBhAG0AYgByAGkAYQAgAE0AYQB0AGgAAAAiAAQAcQiIGADw aAHkBGgBAAAAAKXzFYdA+xWnWprGhgUADwAAAHgHAAAXKQAABgAYAAAABAADEFcAAAB4BwAAFykA AAYAGAAAAFcAAAAAAAAAwQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACA ADI0AAAAAAAAAAAAAAAAAAB3MAAAdzAAAAAAAAC5c9w5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAANM4NRAPAQAN/f//0BAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACEhQAAAAAAjw/w8BCAE/AADkBAAA////f////3////9/////f/// /3////9/////f2FczQAABAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAACEEAAAAAAAAAAAAAAAAAAAA AAAAEBwAAAgAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUAAAAAAAALAAAAAAAAANwAAAD//xIA AAAAAB8ARAA6AFwATQB5ACAARABhAHQAYQBcAEUAQwBTAFwARQBDAFMAIABUAGUAbQBwAGwAYQB0 AGUALgBkAG8AdAASAEUAbgB0AHIAdQBzAHQAIABEAGUAcABsAG8AeQBtAGUAbgB0ABAAUABLAEkA IABVAHAAZwByAGEAZABlACAAUABsAGEAbgAAAAAADABCAHIAdQBjAGUAIABNAG8AcgB0AG8AbgAO AEkA8QBpAGcAbwAgAEIAYQByAHIAZQBpAHIAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAAAGAAAA DgAAAAAADAABAAwAAgAMAAMADAAEAAwABQAMAAYADAAHAAwACAAMAAkADAAKAAwACwAMAAwADAAN AAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAGAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA AKABAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAAC0AAAABAAAANAAAAAFAAAA6AAAAAcAAAD0AAAA CAAAAAwBAAAJAAAAJAEAABIAAAAwAQAACgAAAFABAAALAAAAXAEAAAwAAABoAQAADQAAAHQBAAAO AAAAgAEAAA8AAACIAQAAEAAAAJABAAATAAAAmAEAAAIAAADkBAAAHgAAABQAAABFbnRydXN0IERl cGxveW1lbnQAAB4AAAAUAAAAUEtJIFVwZ3JhZGUgUGxhbgAAAAAeAAAAEAAAAEJydWNlIE1vcnRv bgAAAAAeAAAABAAAAAAAAAAeAAAAEAAAAEVDUyBUZW1wbGF0ZQAAAAAeAAAAEAAAAEnxaWdvIEJh cnJlaXJhAAAeAAAABAAAADUAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAA GnEYAgAAAEAAAAAANOS43dHIAUAAAAAAviZhMl3OAUAAAAAA+JL+7V3OAQMAAAAGAAAAAwAAAHgH AAADAAAAFykAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4b EJOXCAArLPmucAEAACwBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACAAAAABgAAAIgAAAARAAAA kAAAABcAAACYAAAACwAAAKAAAAAQAAAAqAAAABMAAACwAAAAFgAAALgAAAANAAAAwAAAAAwAAAD2 AAAAAgAAAOQEAAAeAAAACAAAAEVudHJ1c3QAAwAAAFcAAAADAAAAGAAAAAMAAAB3MAAAAwAAAAAA DgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAACAAAAEwAAAEVudHJ1c3QgRGVw bG95bWVudAATAAAARW50cnVzdCBEZXBsb3ltZW50AAwQAAAEAAAAHgAAAAcAAABU7XR1bG8AAwAA AAEAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAMAAAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABA AAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAAeAAAAAYAAAADAAAAcwAOAAMA AAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAAAgAAAAbQBhAGkAbAB0AG8AOgBiAHIAdQBjAGUALgBt AG8AcgB0AG8AbgBAAGUAbgB0AHIAdQBzAHQALgBjAG8AbQAAAB8AAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA AAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAA ABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAA HwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAAP7///8qAAAAKwAAACwAAAAt AAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsA AAA8AAAAPQAAAD4AAAD+////QAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAA AEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAA WAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABm AAAA/v///2gAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAAD+////cAAAAHEAAAByAAAAcwAAAHQA AAB1AAAAdgAAAP7////9////eQAAAHoAAAD+/////v///30AAAD+//////////////9SAG8AbwB0 ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACw5KkY7l3OAXwAAAAA AwAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKQAAAG0qAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgABAAAA//////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/AAAAMU4AAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4A dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQoAAAAFAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDUQAAAAAAAAUAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZwAAAAAQ AAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBv AG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABvAAAAABAAAAAAAABNAHMAbwBEAGEAdABhAFMAdABvAHIAZQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgABAP//////////BwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEDCGGO5dzgHAKaUY7l3OAQAAAAAAAAAAAAAAAM0ATQBJAMoA0wBSAFMAUgDXAFUASwDI ADAAWQDWANQA3wBRAEkA1QA0ANAAPQA9AAAAAAAAAAAAAAAAAAAAAAAyAAEB//////////8IAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAQMIYY7l3OAcAppRjuXc4BAAAAAAAAAAAAAAAASQB0AGUAbQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoA AgH/////CQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAA AAAAAABQAHIAbwBwAGUAcgB0AGkAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQAAABVAQAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAgAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAHYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMA AAD+////BQAAAAYAAAAHAAAACAAAAAkAAAD+////CwAAAP7///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////zxiOlNvdXJjZXMg U2VsZWN0ZWRTdHlsZT0iXEFQQS5YU0wiIFN0eWxlTmFtZT0iQVBBIiB4bWxuczpiPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvb2ZmaWNlRG9jdW1lbnQvMjAwNi9iaWJsaW9ncmFw aHkiIHhtbG5zPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvb2ZmaWNlRG9jdW1l bnQvMjAwNi9iaWJsaW9ncmFwaHkiPjwvYjpTb3VyY2VzPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCIgc3Rh bmRhbG9uZT0ibm8iPz4NCjxkczpkYXRhc3RvcmVJdGVtIGRzOml0ZW1JRD0ie0NEMkFDMkI0LTkx MTQtNDJERC1BODY5LThEQjRGRDAyMzU3Qn0iIHhtbG5zOmRzPSJodHRwOi8vc2NoZW1hcy5vcGVu eG1sZm9ybWF0cy5vcmcvb2ZmaWNlRG9jdW1lbnQvMjAwNi9jdXN0b21YbWwiPjxkczpzY2hlbWFS ZWZzPjxkczpzY2hlbWFSZWYgZHM6dXJpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0cy5v cmcvb2ZmaWNlRG9jdW1lbnQvMjAwNi9iaWJsaW9ncmFwaHkiLz48L2RzOnNjaGVtYVJlZnM+PC9k czpkYXRhc3RvcmVJdGVtPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGJAAAAERvY3VtZW50byBkZSBNaWNyb3NvZnQg V29yZCA5Ny0yMDAzAAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --Boundary_(ID_acUC1WdcePnj7ArvDgjp8A)-- From ben@digicert.com Mon Jun 3 16:56:24 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE2621E80A3 for ; Mon, 3 Jun 2013 16:56: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo2nU-p4HERa for ; Mon, 3 Jun 2013 16:56:06 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id A34C121F963F for ; Mon, 3 Jun 2013 16:43:54 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 912297FC064; Mon, 3 Jun 2013 17:43:27 -0600 (MDT) From: "Ben Wilson" To: , , , , , References: <073501ce5e17$0c8effc0$25acff40$@digicert.com> <452C99D20750E74083DBA441FF9323857BF92A9D@SOTTEXCH10.corp.ad.entrust.com> <51A8D80D.4030200@bogus.com> A <65DA4BEA501AFC409DF274CC71ED01A57C679C9F@SOTTEXCH10.corp.ad.entrust.com> <763539E260C37C46A0D6B340B5434C3B075366B8@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B075366B8@AEX06.ejsarea.net> Date: Mon, 3 Jun 2013 17:43:25 -0600 Organization: DigiCert Message-ID: <000901ce60b4$2474d7a0$6d5e86e0$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGXRqs2ttl2afARiZxJskoic5KFNAL+lb7nAdPubqIBySc0NQHbSiNeAVw7UtqZRDwbwA== Content-Language: en-us Cc: wpkops@ietf.org Subject: Re: [wpkops] Agenda Items for IETF 87 X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 23:56:25 -0000 Thanks, I=F1igo. =20 I will not be able to attend the IETF 87 meeting in person, but I have = an updated outline of the user agent behaviors that I have briefly = summarized below. The purpose of the following summary is to explain in = chronologic fashion the processing of an SSL certificate. The key reason I'm = sharing it here is to get feedback on whether I've explained anything incorrectly = or in a way that does not fit real-world implementation. The paragraphs below = are broad-brushed because I didn't want to dump a hierarchical list of complicated error conditions on everyone. Right now my plan is to use = the groupings below to organize the analysis of user agent behaviors. =20 There are several types of error conditions that one might encounter = while processing an SSL certificate. To accomplish an error-free SSL/TLS handshake the user agent has to negotiate the parameters of the session, obtain the server certificate, examine the signature, and determine: whether to trust the certificate and its issuer; whether the certificate = was properly issued; and whether it still remains valid. Communication errors due to misconfigurations or data corruption might immediately halt the process. Error messages during the SSL/TLS = handshake / session negotiation step include: internal errors, aborted = handshakes, certificate or public key unavailability, bad hash values, malformed handshake messages, and unsupported protocols. (Question - is there a difference between "handshake" and "session negotiation"? If anyone has told me, I can't remember.) Most user agents maintain a repository of trusted certificates, and some also keep track of bad certificates as well. Assuming that the = certificate is received by the user agent, then during the handshake a user agent = will examine the certificate presented and determine whether it can build an unbroken chain between the website certificate and a trusted = certificate. If it cannot, because a trusted CA cannot be found (and the user does = not affirmatively choose to trust the certificate), then the session should terminate. If the certificate can be examined for other reasons, then further processing occurs. Other errors encountered during this step include: signature does not verify content, unsupported certificate = type, corrupt certificate repository, name mismatch, same certificate in = multiple paths, and other indications that there are critical problems with the certificate chain. Assuming that a proper chain can be constructed, then the contents = within the certificate themselves can be analyzed. The user agent can determine whether the certificate has expired (or in some cases, whether the certificate is premature) based on the system clock. Some user agents provide better detailed explanation. For example, some will inform the = user to check his or her system clock to ensure that it is not indicating a = time that is earlier than the issuance date of the certificate. Some user agents will determine whether the server certificate=92s validity period = falls within the validity period of the issuing CA. If not, the user agent provides a warning that the certificate is outside the lifetime of the issuing CA. A user agent can examine whether the certificate has been revoked by checking a locally cached repository containing a CRL or an OCSP = response. If such revocation record is not cached locally, then it can usually be retrieved via an HTTP location specified by the issuing CA. Errors associated with obtaining and processing CRLs and OCSP include: CRL / = OCSP not available; signature on (or data within) CRL or OCSP response = fails; certificate revoked; and intermediate CA certificate revoked. Even assuming that the user agent can establish that the certificate is valid and has been revoked, there are certainly other errors that may = arise in the process of session negotiation. These errors include: transmission/receipt of bad data, hashes, or MACs; decryption and decompression errors; internal processing errors; incompatible = cryptographic and algorithmic functions between client and server; and inability to negotiate other parameters for session (key exchange, key size and = strength, session renegotiation, etc.). While client authentication errors can also prevent session = establishment, these types of mutual authentication errors will not be addressed in = this Internet Draft. Thanks, Ben -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf = Of i-barreira@izenpe.net Sent: Monday, June 03, 2013 3:51 PM To: sharon.boeyen@entrust.com; joelja@bogus.com; = bruce.morton@entrust.com; paul.hoffman@vpnc.org; jeremy.rowley@digicert.com Cc: wpkops@ietf.org Subject: Re: [wpkops] Agenda Items for IETF 87 Hi, Meanwhile I=B4m preparing the document to upload it, here=B4s a word = version for you to check in the meantime. Sorry for doing so late. regards I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea = gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi = erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente. -----Mensaje original----- De: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Enviado el: viernes, 31 de mayo de 2013 21:11 Para: joel jaeggli; Bruce Morton; Paul Hoffman; = jeremy.rowley@digicert.com CC: wpkops WG; Barreira Iglesias, I=F1igo Asunto: RE: [wpkops] Agenda Items for IETF 87 The WG milestone with respect to the Trust Models draft is that a draft = be adopted as the 1st WG draft in June 2013. In order to accomplish that, a draft needs to be submitted early next week to give the WG members time = to review, discuss and potentially an updated draft submitted for WG = adoption before the end of June. If you and Inigo have an updated draft it should = be submitted asap. If there are outstanding issues those could be = identified on the mail list and input soliticited from WG membership.=20 -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf = Of joel jaeggli Sent: Friday, May 31, 2013 1:04 PM To: Bruce Morton; Paul Hoffman; jeremy.rowley@digicert.com Cc: wpkops WG; "I=F1igo Barreira (i-barreira@izenpe.net)" Subject: Re: [wpkops] Agenda Items for IETF 87 On 5/31/13 9:59 AM, Bruce Morton wrote: > I=F1igo and I are working on a draft of the Trust Model document. I am = not sure that we will have time to get it prepared to a state that it will = be able to be published in the appropriate lead time before the Berlin = meeting. > > I will not be able to attend the Berlin meeting, but I=F1igo is seeing = if he can make it. > > I tend to agree with Paul that if the document has not been circulated = and there are no issues raised, then it will be difficult to have agenda = items for a meeting. It is the opinion of your AD that drafts that haven't been circulated shouldn't be presented. which is why it's worth having this dicussion = now. thanks joel > > Bruce. > > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 > Behalf Of Paul Hoffman > Sent: Friday, May 31, 2013 12:28 PM > To: jeremy.rowley@digicert.com > Cc: wpkops WG > Subject: Re: [wpkops] Agenda Items for IETF 87 > > On May 31, 2013, at 8:53 AM, Jeremy Rowley = wrote: > >> Please email wpkops-chairs@tools.ietf.org with your agenda items for = IETF 87 in Berlin. Also, if you are a document editor, please let us know whether you are attending the meeting and whether you plan to present an update. If you are not attending, please provide a status update on = where you are on your project. > The documents were presented at the last IETF meeting in anticipation = of the documents being published. IETF face-to-face meetings are normally = used for discussing issues in the WG documents and presenting new work, but = the WG still has no documents published (and essentially no discussion on = the list). > > Is there really a reason to meet face-to-face at the next meeting? = Will any of the WG documents be published before then? > > And yes, I ask this as a co-editor on one of the planned documents. It doesn't seem worth writing the documents if there is no real interest in them. > > --Paul Hoffman > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From hallam@gmail.com Tue Jun 4 14:36:38 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E04221F8B04 for ; Tue, 4 Jun 2013 14:36:38 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXcEQShV4a23 for ; Tue, 4 Jun 2013 14:36:37 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 27FA521F9A2C for ; Tue, 4 Jun 2013 13:20:59 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so634046wes.15 for ; Tue, 04 Jun 2013 13:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WjcFf8BScMJS4ERyWw9aYMB/Sdhp2aMYDZ/Ds7VuhFg=; b=zNl6qMlcdRrKRx1AuK4H86BnnU+gAp1nM000T/rK9k0UYEByHMxdjGRLAzC4vozS3p t3lf+deF/SDkwNQWlyidqj5QbkadmuCFS33R/LfKa8f1ZUvURgxngNPr1fEXtN82vi3N 8UJv2ictgl7d8Ts989e0dbVW8rChuICGizcnGXJFJ2KXmuCC8QzOn97xn7MPfasKX4F1 xSbAw6dWCKFoW2Kz3PqnCQtBEOErzuOeRI4kJC+o+6M53xL4bhNeUGnwHSEFxUFCtG21 AAEhZLZKamf5ee5/0kKbQzHYeyDNbNKX7rbD08p1oz7bUhFvm4yv/vkd+dJrf7GiA8bz sNbQ== MIME-Version: 1.0 X-Received: by 10.180.189.136 with SMTP id gi8mr3308537wic.11.1370377258314; Tue, 04 Jun 2013 13:20:58 -0700 (PDT) Received: by 10.194.60.195 with HTTP; Tue, 4 Jun 2013 13:20:58 -0700 (PDT) Date: Tue, 4 Jun 2013 16:20:58 -0400 Message-ID: From: Phillip Hallam-Baker To: "wpkops@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2412cb0b1f504de59d1bf Subject: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:36:38 -0000 --001a11c2412cb0b1f504de59d1bf Content-Type: text/plain; charset=ISO-8859-1 OK so working on the draft and trying to get a handle on how to sort out all these degrees of freedom. While I was doing so discovered that RFC 5280 doesn't really specify a certificate lifecycle as such, it describes a mechanism for reporting CRLs which is not quite the same thing. The other thing I was somewhat surprised to find is that the cACompromise reason code is defined but at no point in the document does the string cACompromise occur in the context of defining when it should be used. Same for the other reason codes. -- Website: http://hallambaker.com/ --001a11c2412cb0b1f504de59d1bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
OK so working on the draft and trying to get a handle on h= ow to sort out all these degrees of freedom.

While I was= doing so discovered that RFC 5280 doesn't really specify a certificate= lifecycle as such, it describes a mechanism for reporting CRLs which is no= t quite the same thing.

The other thing I was somewhat surprised to find = is that the cACompromise reason code is defined but at no point in the docu= ment does the string=A0cACompromise occur in the context of defining when i= t should be used. Same for the other reason codes.
--001a11c2412cb0b1f504de59d1bf-- From agl@google.com Tue Jun 4 14:44:43 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B0C21F949D for ; Tue, 4 Jun 2013 14:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT6f6SHWQHht for ; Tue, 4 Jun 2013 14:44:42 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C48AC21F99FB for ; Tue, 4 Jun 2013 14:39:12 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id 9so1697664iec.41 for ; Tue, 04 Jun 2013 14:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fAfa2KnySWojBWgo+flTVRF79osuH9MeBc8BkT7pBdQ=; b=EVWSsp3AEQptla7Irq/7/njIL4kVGe3aiy261bqbHWq+/qhilFo2Qp6+8/LFkDI78M 979tmWCkA4FzAnarUj1m/WnSiAlng8D97RL5H7qXsxo5aVJ2LTORGsn26kHe8vny8IPu FyFI6mxv4bjDO21pKopi3g7nHsJgiyd7SgMlhQ3dkKPoV5M1mjOY70WmEYyWEm9FKEp5 e3tdNHDpuV7UBZnWheMA0zUlKeXsycktY70VldSlsmju73636yqud8p4zlYm+JB5JjOZ YR3BBBmuGYOpNJz63/s6NiMd1+Ag6enBKqjB2uO34Xz4n8saRhoVnbQWAbwKTjkaag/t Vstw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fAfa2KnySWojBWgo+flTVRF79osuH9MeBc8BkT7pBdQ=; b=kC0oFxBmo41LpmG0kqXs+yDT9iXhmR+UFaBZKB2Y1BCHz3EO86Z6E5zbTHPlhbIa7v aVjmcByWDUfCFF+Fo0pQ38Rx8Arqz/Us7RybWg8iecb4hxnh5QKw1h+QQXj0Euc9IupR ai9meQHjJDZAMi6xOW7QFfXZyPDWtRt11kZyM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=fAfa2KnySWojBWgo+flTVRF79osuH9MeBc8BkT7pBdQ=; b=aw9EBmdsaFshPY6RjnZnAz/p07gRirl9dOv2L0wrjrumtXu3nTm+g8gAILNrkzKiIG E4Hfq3kMXZBFOuOOgr//trGYUZ/9PUUEU8iDoE6ILVoZLUWuQaIwaTeUT+LvOEqpnZPy 7NxEL8Z5yv3tq5XTYLJ4y5ZXDNVuDWyyqKxwhKAlqVJyuLqMnsb0fZwAUP+tv+owU6ok ZaiRqDpMKlJz6EPm31HBAnvkdFVPU6HQr/r9XzcW9K65JcAtxHK2yHlYn1yENqAW/SPF jQXWLDnSBX7lOf74C6A/lTesgvIrDY+gArT9EVQ/vtf78ezaMNgZsNyqEZ+yf3F9+3lh ehRQ== MIME-Version: 1.0 X-Received: by 10.50.18.42 with SMTP id t10mr1913014igd.23.1370381952283; Tue, 04 Jun 2013 14:39:12 -0700 (PDT) Sender: agl@google.com Received: by 10.231.151.138 with HTTP; Tue, 4 Jun 2013 14:39:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 17:39:12 -0400 X-Google-Sender-Auth: RyQZour1J2MNdqA-mljPEDjwZLo Message-ID: From: Adam Langley To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn8p3W+8f4YC4YNG+LteN7eDyZyuJ+Xm64zd8gHbHtEhu4pvz6ZLyOnGdDo+/UzpRW3Go79KBgJSZOPctHmKKo5PaCdDX452PlJvEp3rDa7rZrxzEQsH/9EZ3EZfp/+las0cA5MDw3xu9FHN6KQ9fxHYeN/3XNsOfFUPajQULLA+qinH6YdtkRxzdkE9BnBjARuBc2q Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:44:43 -0000 On Tue, Jun 4, 2013 at 4:20 PM, Phillip Hallam-Baker wrote: > OK so working on the draft and trying to get a handle on how to sort out all > these degrees of freedom. > > While I was doing so discovered that RFC 5280 doesn't really specify a > certificate lifecycle as such, it describes a mechanism for reporting CRLs > which is not quite the same thing. > > The other thing I was somewhat surprised to find is that the cACompromise > reason code is defined but at no point in the document does the string > cACompromise occur in the context of defining when it should be used. Same > for the other reason codes. Not to mention, does anyone have any idea what an aACompromise could mean? Cheers AGL From hallam@gmail.com Tue Jun 4 14:51:59 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BC621F8B21 for ; Tue, 4 Jun 2013 14:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoJB+Gs2gW02 for ; Tue, 4 Jun 2013 14:51:58 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 54AD221F8B04 for ; Tue, 4 Jun 2013 14:51:58 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so703208wes.35 for ; Tue, 04 Jun 2013 14:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Uf+yWJ6F4u7sEOp/81MjXduk0uNuN5TRTzka/AXk3aY=; b=BkdZ5qFnJmwtDgGSH/kBKKfhGixIlonlVBzDKUNor35R5gNMWDvg9/hyp7KWBd/EMh c/in0J0GBc/+saSyjf1ofB6mf4L+6TsTSQdCn2/hESm2Z7PJcl/2t4cx4YB7DpiEBqEb AIKl3e3GZO7W4vkRluNge+n4Qaql46z1KO0Nb5OzLGYrqlGj6Z1dU4fO15mDO3BRoAQK KlQQG0pAFw3hf/n5QNdGnWhozX6xH7qpUf2jKS//Lzn2Y66duvA3SJxJ8Hals/9K3s+p 4L/MEMopizlLBkNP5hLoaKbtvcUrzdwtRb4IhzutnKUmZEWNnWGE9a15eS8M0bZPOlWD H0Jw== MIME-Version: 1.0 X-Received: by 10.180.183.206 with SMTP id eo14mr3489807wic.36.1370382717491; Tue, 04 Jun 2013 14:51:57 -0700 (PDT) Received: by 10.194.60.195 with HTTP; Tue, 4 Jun 2013 14:51:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 17:51:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Adam Langley Content-Type: multipart/alternative; boundary=001a11c2297c15230104de5b17ea Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 21:51:59 -0000 --001a11c2297c15230104de5b17ea Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley wrote: > On Tue, Jun 4, 2013 at 4:20 PM, Phillip Hallam-Baker > wrote: > > OK so working on the draft and trying to get a handle on how to sort out > all > > these degrees of freedom. > > > > While I was doing so discovered that RFC 5280 doesn't really specify a > > certificate lifecycle as such, it describes a mechanism for reporting > CRLs > > which is not quite the same thing. > > > > The other thing I was somewhat surprised to find is that the cACompromise > > reason code is defined but at no point in the document does the string > > cACompromise occur in the context of defining when it should be used. > Same > > for the other reason codes. > > Not to mention, does anyone have any idea what an aACompromise could mean? > Its an attribute authority. For attribute certs. Well actually that is only a supposition because none of the terms seem to be defined. -- Website: http://hallambaker.com/ --001a11c2297c15230104de5b17ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley <agl@chromium= .org> wrote:
On T= ue, Jun 4, 2013 at 4:20 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> OK so working on the draft and trying to get a handle on how to sort o= ut all
> these degrees of freedom.
>
> While I was doing so discovered that RFC 5280 doesn't really speci= fy a
> certificate lifecycle as such, it describes a mechanism for reporting = CRLs
> which is not quite the same thing.
>
> The other thing I was somewhat surprised to find is that the cAComprom= ise
> reason code is defined but at no point in the document does the string=
> cACompromise occur in the context of defining when it should be used. = Same
> for the other reason codes.

Not to mention, does anyone have any idea what an aACompromise = could mean?

Its = an attribute authority. For attribute certs.

Well actually that is only a suppositi= on because none of the terms seem to be defined.

=
--
Website: http://hallambake= r.com/
--001a11c2297c15230104de5b17ea-- From rob.stradling@comodo.com Wed Jun 5 02:21:51 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0B521F9A66 for ; Wed, 5 Jun 2013 02:21: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je6oxiVt5ueK for ; Wed, 5 Jun 2013 02:21:46 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 31AFB21F9A67 for ; Wed, 5 Jun 2013 02:21:44 -0700 (PDT) Received: (qmail 2610 invoked from network); 5 Jun 2013 09:21:42 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 Jun 2013 09:21:42 -0000 Received: (qmail 12292 invoked by uid 1000); 5 Jun 2013 09:21:42 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 05 Jun 2013 10:21:42 +0100 Message-ID: <51AF031F.8030601@comodo.com> Date: Wed, 05 Jun 2013 10:21:35 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "wpkops@ietf.org" , Adam Langley Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 09:21:52 -0000 On 04/06/13 22:51, Phillip Hallam-Baker wrote: > On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley > wrote: > Not to mention, does anyone have any idea what an aACompromise could > mean? > > > Its an attribute authority. For attribute certs. > > Well actually that is only a supposition because none of the terms seem > to be defined. X.509 (11/2008) defines the reason codes as follows... "8.5.2.2 Reason code extension ... The following reason code values indicate why a certificate was revoked: - 'unspecified' can be used to revoke certificates for reasons other than the specific codes; - 'keyCompromise' is used in revoking an end-entity certificate; it indicates that it is known or suspected that the subject's private key, or other aspects of the subject validated in the certificate, have been compromised; - 'cACompromise' is used in revoking a CA-certificate; it indicates that it is known or suspected that the subject's private key, or other aspects of the subject validated in the certificate, have been compromised; - 'affiliationChanged' indicates that the subject's name or other information in the certificate has been modified but there is no cause to suspect that the private key has been compromised; - 'superseded' indicates that the certificate has been superseded but there is no cause to suspect that the private key has been compromised; - 'cessationOfOperation' indicates that the certificate is no longer needed for the purpose for which it was issued but there is no cause to suspect that the private key has been compromised; - 'privilegeWithdrawn' indicates that a certificate (public-key or attribute certificate) was revoked because a privilege contained within that certificate has been withdrawn; - 'aACompromise' indicates that it is known or suspected that aspects of the AA validated in the attribute certificate, have been compromised." -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From hallam@gmail.com Wed Jun 5 07:12:21 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3242921F9814 for ; Wed, 5 Jun 2013 07:12:21 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPvVynSvQtp9 for ; Wed, 5 Jun 2013 07:12:20 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id EA30621F957B for ; Wed, 5 Jun 2013 07:12:19 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id c10so1324419wiw.3 for ; Wed, 05 Jun 2013 07:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ug51g8Wuq790b/N9KgLcycw0NVLNgbSg3ETraWwUalI=; b=oqRZoCIiPRdLLysqlgJvUssCZZy6OsWAh2LXm12KOlEGpF6gqDJ8tD47nLheksweq7 XvMecqsvS9sYWwUkmgr8at8/knT41t6HE3mBofbFOcIoXP7xApE7EEDZMF/2+xbV2hJ8 X7kSEg7tZGB3JlSOv6UE3IazjeSJab1yJLQDB5GMn3MzEBx+tJ2z1ZikoyC7wsu2l28s MZWP+vCVPG6VrE0z0TpeNGWl5D5yL4gTIHmB1/KLl3yQLRE6noRZz+k8bJn/BlZaAlRC LqrZMjIj7EiajA2Gh37/QCXmEsYTBE5JKbsUHAI1UXbLrBHVLA2xGPnSxBwKnmj7acvn 8hhw== MIME-Version: 1.0 X-Received: by 10.180.183.206 with SMTP id eo14mr6860143wic.36.1370441539094; Wed, 05 Jun 2013 07:12:19 -0700 (PDT) Received: by 10.194.60.195 with HTTP; Wed, 5 Jun 2013 07:12:18 -0700 (PDT) In-Reply-To: <51AF031F.8030601@comodo.com> References: <51AF031F.8030601@comodo.com> Date: Wed, 5 Jun 2013 10:12:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Rob Stradling Content-Type: multipart/alternative; boundary=001a11c2297c1f902804de68c9d2 Cc: "wpkops@ietf.org" , Adam Langley Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:12:21 -0000 --001a11c2297c1f902804de68c9d2 Content-Type: text/plain; charset=ISO-8859-1 Heh, I was hoping not to have to reference that one. The RFCs are meant to specify everything needed to interpret the specs. On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling wrote: > On 04/06/13 22:51, Phillip Hallam-Baker wrote: > >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley > > wrote: >> > > > Not to mention, does anyone have any idea what an aACompromise could >> mean? >> >> >> Its an attribute authority. For attribute certs. >> >> Well actually that is only a supposition because none of the terms seem >> to be defined. >> > > X.509 (11/2008) defines the reason codes as follows... > > "8.5.2.2 Reason code extension > ... > The following reason code values indicate why a certificate was revoked: > - 'unspecified' can be used to revoke certificates for reasons other > than the specific codes; > - 'keyCompromise' is used in revoking an end-entity certificate; it > indicates that it is known or suspected that the subject's private key, or > other aspects of the subject validated in the certificate, have been > compromised; > - 'cACompromise' is used in revoking a CA-certificate; it indicates that > it is known or suspected that the subject's private key, or other aspects > of the subject validated in the certificate, have been compromised; > - 'affiliationChanged' indicates that the subject's name or other > information in the certificate has been modified but there is no cause to > suspect that the private key has been compromised; > - 'superseded' indicates that the certificate has been superseded but > there is no cause to suspect that the private key has been compromised; > - 'cessationOfOperation' indicates that the certificate is no longer > needed for the purpose for which it was issued but there is no cause to > suspect that the private key has been compromised; > - 'privilegeWithdrawn' indicates that a certificate (public-key or > attribute certificate) was revoked because a privilege contained within > that certificate has been withdrawn; > - 'aACompromise' indicates that it is known or suspected that aspects of > the AA validated in the attribute certificate, have been compromised." > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > -- Website: http://hallambaker.com/ --001a11c2297c1f902804de68c9d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Heh, I was hoping not to have to reference that one.
<= br>
The RFCs are meant to specify everything needed to inte= rpret the specs.




On Wed, Jun 5, 2013 at 5:21 AM, Rob Stra= dling <rob.stradling@comodo.com> wrote:
On 04/06/13 22:51, Phillip Hallam-Baker wrote:
On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley <agl@chromium.org
<mailto:agl@chromi= um.org>> wrote:
<snip>

=A0 =A0 Not to mention, does anyone have any idea what an aACompromise coul= d
=A0 =A0 mean?


Its an attribute authority. For attribute certs.

Well actually that is only a supposition because none of the terms seem
to be defined.

X.509 (11/2008) defines the reason codes as follows...

"8.5.2.2 =A0Reason code extension
...
The following reason code values indicate why a certificate was revoked: =A0 - 'unspecified' can be used to revoke certificates for reasons = other than the specific codes;
=A0 - 'keyCompromise' is used in revoking an end-entity certificate= ; it indicates that it is known or suspected that the subject's private= key, or other aspects of the subject validated in the certificate, have be= en compromised;
=A0 - 'cACompromise' is used in revoking a CA-certificate; it indic= ates that it is known or suspected that the subject's private key, or o= ther aspects of the subject validated in the certificate, have been comprom= ised;
=A0 - 'affiliationChanged' indicates that the subject's name or= other information in the certificate has been modified but there is no cau= se to suspect that the private key has been compromised;
=A0 - 'superseded' indicates that the certificate has been supersed= ed but there is no cause to suspect that the private key has been compromis= ed;
=A0 - 'cessationOfOperation' indicates that the certificate is no l= onger needed for the purpose for which it was issued but there is no cause = to suspect that the private key has been compromised;
=A0 - 'privilegeWithdrawn' indicates that a certificate (public-key= or attribute certificate) was revoked because a privilege contained within= that certificate has been withdrawn;
=A0 - 'aACompromise' indicates that it is known or suspected that a= spects of the AA validated in the attribute certificate, have been compromi= sed."

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online




-- Website: http://hallambaker.com/<= br>
--001a11c2297c1f902804de68c9d2-- From rob.stradling@comodo.com Wed Jun 5 07:16:57 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF4E21F99CF for ; Wed, 5 Jun 2013 07:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Wg2eiCkkaPH for ; Wed, 5 Jun 2013 07:16:54 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1E021F9A9D for ; Wed, 5 Jun 2013 07:16:50 -0700 (PDT) Received: (qmail 1881 invoked from network); 5 Jun 2013 14:16:46 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 Jun 2013 14:16:46 -0000 Received: (qmail 8224 invoked by uid 1000); 5 Jun 2013 14:16:46 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 05 Jun 2013 15:16:46 +0100 Message-ID: <51AF484D.6040207@comodo.com> Date: Wed, 05 Jun 2013 15:16:45 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <51AF031F.8030601@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "wpkops@ietf.org" , Adam Langley Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:16:58 -0000 On 05/06/13 15:12, Phillip Hallam-Baker wrote: > Heh, I was hoping not to have to reference that one. > > The RFCs are meant to specify everything needed to interpret the specs. Indeed. It seems odd to me that RFC5280 only references X.509 Informatively rather than Normatively. > On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling > wrote: > > On 04/06/13 22:51, Phillip Hallam-Baker wrote: > > On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley > >> wrote: > > > > Not to mention, does anyone have any idea what an > aACompromise could > mean? > > > Its an attribute authority. For attribute certs. > > Well actually that is only a supposition because none of the > terms seem > to be defined. > > > X.509 (11/2008) defines the reason codes as follows... > > "8.5.2.2 Reason code extension > ... > The following reason code values indicate why a certificate was revoked: > - 'unspecified' can be used to revoke certificates for reasons > other than the specific codes; > - 'keyCompromise' is used in revoking an end-entity certificate; > it indicates that it is known or suspected that the subject's > private key, or other aspects of the subject validated in the > certificate, have been compromised; > - 'cACompromise' is used in revoking a CA-certificate; it > indicates that it is known or suspected that the subject's private > key, or other aspects of the subject validated in the certificate, > have been compromised; > - 'affiliationChanged' indicates that the subject's name or other > information in the certificate has been modified but there is no > cause to suspect that the private key has been compromised; > - 'superseded' indicates that the certificate has been superseded > but there is no cause to suspect that the private key has been > compromised; > - 'cessationOfOperation' indicates that the certificate is no > longer needed for the purpose for which it was issued but there is > no cause to suspect that the private key has been compromised; > - 'privilegeWithdrawn' indicates that a certificate (public-key > or attribute certificate) was revoked because a privilege contained > within that certificate has been withdrawn; > - 'aACompromise' indicates that it is known or suspected that > aspects of the AA validated in the attribute certificate, have been > compromised." > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From carl@redhoundsoftware.com Wed Jun 5 08:07:14 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9315821F99A8 for ; Wed, 5 Jun 2013 08:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saXZKPRHeU58 for ; Wed, 5 Jun 2013 08:07:10 -0700 (PDT) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94D8121F999C for ; Wed, 5 Jun 2013 08:07:09 -0700 (PDT) Received: by mail-ye0-f172.google.com with SMTP id m15so391502yen.17 for ; Wed, 05 Jun 2013 08:07:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=AsbMZoIqEjVfniVk0MyAaw9etM0Q2NHhVxynXcEXYDw=; b=UAtQvo46m9yXq+nJdNX5XQfuZDXJfsbbzRPjzn/pQSUjJAm0a3B1iecZDICL4G64Yp wEbdx/ie94h17M/bgo6n/dBu7AG6qFnChO6pKLU8KXnjO5VOx4AvTi5+Lc5m1SqKh/Jb g14XQa4DOYYOzLUpgUOlAKDEc3+n7pIYr+rIV485hF71GmnjteMrcUG9qT1bSAxPeGt7 Haz8ARHNwCn5VOuYKBUXWebMN+CgFfdhTdvM4wwFptEnMoYevQ7x8YK1xiQjOfXrqZEY hYPy1QH0y9EMgX7JK6sZTFIeHipf8fNTIpzAwbGvmK9A/fY4a3yLoR4IV+R9WqaTUhCk 06RA== X-Received: by 10.236.86.243 with SMTP id w79mr25148262yhe.87.1370444826838; Wed, 05 Jun 2013 08:07:06 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-116-61.washdc.fios.verizon.net. [173.79.116.61]) by mx.google.com with ESMTPSA id x22sm11922816yhd.2.2013.06.05.08.07.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Jun 2013 08:07:06 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Wed, 05 Jun 2013 11:07:03 -0400 From: Carl Wallace To: Rob Stradling , Phillip Hallam-Baker Message-ID: Thread-Topic: [wpkops] Some questions about revocation reasons In-Reply-To: <51AF484D.6040207@comodo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkwy7IbZtrrj8FBx7uQdtmnBUy3CzFm3JqEp5d+cn2nGnfvIleFOD+uXHd/ycLopaxmg5Dx Cc: "wpkops@ietf.org" , Adam Langley Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:07:14 -0000 On 6/5/13 10:16 AM, "Rob Stradling" wrote: >On 05/06/13 15:12, Phillip Hallam-Baker wrote: >> Heh, I was hoping not to have to reference that one. >> >> The RFCs are meant to specify everything needed to interpret the specs. > >Indeed. It seems odd to me that RFC5280 only references X.509 >Informatively rather than Normatively. It'd be nice if your doc included a taxonomy of the various types of CRLs that can exist based on the combinations of {dp name/no dp name}, {some reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and perhaps indicated what combinations are present in the web pki. I assume one need not grapple with DSA parameter inheritance while processing indirect DP CRLs that use relative to issuer names and cover only EE certs for the keyCompromise reason code with a delta CRL stream available where the CRL issuer's certificate has been signed by a rolled over CA key and whose revocation status is checked using pregenerated OCSP responses signed by a delegated responder that requires signed OCSP requests with noCheck asserted in the responder's certificate. > >> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling > > wrote: >> >> On 04/06/13 22:51, Phillip Hallam-Baker wrote: >> >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley > >> >> wrote: >> >> >> >> Not to mention, does anyone have any idea what an >> aACompromise could >> mean? >> >> >> Its an attribute authority. For attribute certs. >> >> Well actually that is only a supposition because none of the >> terms seem >> to be defined. >> >> >> X.509 (11/2008) defines the reason codes as follows... >> >> "8.5.2.2 Reason code extension >> ... >> The following reason code values indicate why a certificate was >>revoked: >> - 'unspecified' can be used to revoke certificates for reasons >> other than the specific codes; >> - 'keyCompromise' is used in revoking an end-entity certificate; >> it indicates that it is known or suspected that the subject's >> private key, or other aspects of the subject validated in the >> certificate, have been compromised; >> - 'cACompromise' is used in revoking a CA-certificate; it >> indicates that it is known or suspected that the subject's private >> key, or other aspects of the subject validated in the certificate, >> have been compromised; >> - 'affiliationChanged' indicates that the subject's name or other >> information in the certificate has been modified but there is no >> cause to suspect that the private key has been compromised; >> - 'superseded' indicates that the certificate has been superseded >> but there is no cause to suspect that the private key has been >> compromised; >> - 'cessationOfOperation' indicates that the certificate is no >> longer needed for the purpose for which it was issued but there is >> no cause to suspect that the private key has been compromised; >> - 'privilegeWithdrawn' indicates that a certificate (public-key >> or attribute certificate) was revoked because a privilege contained >> within that certificate has been withdrawn; >> - 'aACompromise' indicates that it is known or suspected that >> aspects of the AA validated in the attribute certificate, have been >> compromised." >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online >> >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> > >-- >Rob Stradling >Senior Research & Development Scientist >COMODO - Creating Trust Online >Office Tel: +44.(0)1274.730505 >Office Fax: +44.(0)1274.730909 >www.comodo.com > >COMODO CA Limited, Registered in England No. 04058690 >Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > >This e-mail and any files transmitted with it are confidential and >intended solely for the use of the individual or entity to whom they are >addressed. If you have received this email in error please notify the >sender by replying to the e-mail containing this attachment. Replies to >this email may be monitored by COMODO for operational or business >reasons. Whilst every endeavour is taken to ensure that e-mails are free >from viruses, no liability can be accepted and the recipient is >requested to use their own virus checking software. >_______________________________________________ >wpkops mailing list >wpkops@ietf.org >https://www.ietf.org/mailman/listinfo/wpkops From hallam@gmail.com Wed Jun 5 09:02:52 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0852821F9AED for ; Wed, 5 Jun 2013 09:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svu8HlBVlXwh for ; Wed, 5 Jun 2013 09:02:51 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD1521F8A03 for ; Wed, 5 Jun 2013 09:02:46 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so1481907wes.10 for ; Wed, 05 Jun 2013 09:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8enTsfJH8Q/rcwDzPcCg++jmaDz5mn2JRzPYJRu2S74=; b=KCFSXP+hIo3Ry5G9ORYDXyLQWjnliKOYgJ7ZYtTljxtmLIU1mpMjdFD+wxsYNw9z5m fEy9Z8R2YJALesdKOPMheShIlKp9h1ld8Q0luzcxnco0bR857Mxo6Mf3VC4xG9YG6pon vI+pJX50i12NiV/6xoTIrhp1idkdBx+YJEWRoUKWuG/IbYpaHKBeolg7UMYl6z3QRhkQ k1PU/CHcAL+itG9NoKtXmyU3cHlpYxd4fqfYzGY9S/CTDYx/7Q6ZoX2iUF+LqmD8CEsT Z5jNwJQsyAIuBWkqS0lMRpdRDvx/gwBfDXH8mXzvO9WxpnrZ63wCe09qGAOQZMRMkIvZ ekHQ== MIME-Version: 1.0 X-Received: by 10.194.11.72 with SMTP id o8mr29571203wjb.0.1370448165188; Wed, 05 Jun 2013 09:02:45 -0700 (PDT) Received: by 10.194.60.195 with HTTP; Wed, 5 Jun 2013 09:02:45 -0700 (PDT) In-Reply-To: <51AF484D.6040207@comodo.com> References: <51AF031F.8030601@comodo.com> <51AF484D.6040207@comodo.com> Date: Wed, 5 Jun 2013 12:02:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Rob Stradling Content-Type: multipart/alternative; boundary=e89a8f234d4911b91004de6a545f Cc: "wpkops@ietf.org" , Adam Langley Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:02:52 -0000 --e89a8f234d4911b91004de6a545f Content-Type: text/plain; charset=ISO-8859-1 The historical reason for this is that we were too cheap to pay for a spec. But now there are political reasons that might well force a break with ITU-T. On Wed, Jun 5, 2013 at 10:16 AM, Rob Stradling wrote: > On 05/06/13 15:12, Phillip Hallam-Baker wrote: > >> Heh, I was hoping not to have to reference that one. >> >> The RFCs are meant to specify everything needed to interpret the specs. >> > > Indeed. It seems odd to me that RFC5280 only references X.509 > Informatively rather than Normatively. > > On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling > >> wrote: >> >> On 04/06/13 22:51, Phillip Hallam-Baker wrote: >> >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley > >> >> wrote: >> >> >> >> Not to mention, does anyone have any idea what an >> aACompromise could >> mean? >> >> >> Its an attribute authority. For attribute certs. >> >> Well actually that is only a supposition because none of the >> terms seem >> to be defined. >> >> >> X.509 (11/2008) defines the reason codes as follows... >> >> "8.5.2.2 Reason code extension >> ... >> The following reason code values indicate why a certificate was >> revoked: >> - 'unspecified' can be used to revoke certificates for reasons >> other than the specific codes; >> - 'keyCompromise' is used in revoking an end-entity certificate; >> it indicates that it is known or suspected that the subject's >> private key, or other aspects of the subject validated in the >> certificate, have been compromised; >> - 'cACompromise' is used in revoking a CA-certificate; it >> indicates that it is known or suspected that the subject's private >> key, or other aspects of the subject validated in the certificate, >> have been compromised; >> - 'affiliationChanged' indicates that the subject's name or other >> information in the certificate has been modified but there is no >> cause to suspect that the private key has been compromised; >> - 'superseded' indicates that the certificate has been superseded >> but there is no cause to suspect that the private key has been >> compromised; >> - 'cessationOfOperation' indicates that the certificate is no >> longer needed for the purpose for which it was issued but there is >> no cause to suspect that the private key has been compromised; >> - 'privilegeWithdrawn' indicates that a certificate (public-key >> or attribute certificate) was revoked because a privilege contained >> within that certificate has been withdrawn; >> - 'aACompromise' indicates that it is known or suspected that >> aspects of the AA validated in the attribute certificate, have been >> compromised." >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> COMODO - Creating Trust Online >> >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> ______________________________**_________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/**listinfo/wpkops >> >> > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > sender by replying to the e-mail containing this attachment. Replies to > this email may be monitored by COMODO for operational or business reasons. > Whilst every endeavour is taken to ensure that e-mails are free from > viruses, no liability can be accepted and the recipient is requested to use > their own virus checking software. > -- Website: http://hallambaker.com/ --e89a8f234d4911b91004de6a545f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The historical reason for this is that we were too cheap t= o pay for a spec.

But now there are political reasons th= at might well force a break with ITU-T.=A0


On Wed, Jun 5, 2013 at 10:16 AM, Rob Str= adling <rob.stradling@comodo.com> wrote:
On 05/06/13 15:12, Phillip Hallam-Baker wrote:
Heh, I was hoping not to have to reference that one.

The RFCs are meant to specify everything needed to interpret the specs.

Indeed. =A0It seems odd to me that RFC5280 only references X.509 Informativ= ely rather than Normatively.

On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <rob.stradling@comodo.com
=
<mailto:ro= b.stradling@comodo.com>> wrote:

=A0 =A0 On 04/06/13 22:51, Phillip Hallam-Baker wrote:

=A0 =A0 =A0 =A0 On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley <agl@chromium.org
=A0 =A0 =A0 =A0 <mailto:agl@chromium.org>
=A0 =A0 =A0 =A0 <mailto:agl@chromium.org <mailto:agl@chromium.org>>> wrote:

=A0 =A0 <snip>

=A0 =A0 =A0 =A0 =A0 =A0 =A0Not to mention, does anyone have any idea what a= n
=A0 =A0 =A0 =A0 aACompromise could
=A0 =A0 =A0 =A0 =A0 =A0 =A0mean?


=A0 =A0 =A0 =A0 Its an attribute authority. For attribute certs.

=A0 =A0 =A0 =A0 Well actually that is only a supposition because none of th= e
=A0 =A0 =A0 =A0 terms seem
=A0 =A0 =A0 =A0 to be defined.


=A0 =A0 X.509 (11/2008) defines the reason codes as follows...

=A0 =A0 "8.5.2.2 =A0Reason code extension
=A0 =A0 ...
=A0 =A0 The following reason code values indicate why a certificate was rev= oked:
=A0 =A0 =A0 =A0- 'unspecified' can be used to revoke certificates f= or reasons
=A0 =A0 other than the specific codes;
=A0 =A0 =A0 =A0- 'keyCompromise' is used in revoking an end-entity = certificate;
=A0 =A0 it indicates that it is known or suspected that the subject's =A0 =A0 private key, or other aspects of the subject validated in the
=A0 =A0 certificate, have been compromised;
=A0 =A0 =A0 =A0- 'cACompromise' is used in revoking a CA-certificat= e; it
=A0 =A0 indicates that it is known or suspected that the subject's priv= ate
=A0 =A0 key, or other aspects of the subject validated in the certificate,<= br> =A0 =A0 have been compromised;
=A0 =A0 =A0 =A0- 'affiliationChanged' indicates that the subject= 9;s name or other
=A0 =A0 information in the certificate has been modified but there is no =A0 =A0 cause to suspect that the private key has been compromised;
=A0 =A0 =A0 =A0- 'superseded' indicates that the certificate has be= en superseded
=A0 =A0 but there is no cause to suspect that the private key has been
=A0 =A0 compromised;
=A0 =A0 =A0 =A0- 'cessationOfOperation' indicates that the certific= ate is no
=A0 =A0 longer needed for the purpose for which it was issued but there is<= br> =A0 =A0 no cause to suspect that the private key has been compromised;
=A0 =A0 =A0 =A0- 'privilegeWithdrawn' indicates that a certificate = (public-key
=A0 =A0 or attribute certificate) was revoked because a privilege contained=
=A0 =A0 within that certificate has been withdrawn;
=A0 =A0 =A0 =A0- 'aACompromise' indicates that it is known or suspe= cted that
=A0 =A0 aspects of the AA validated in the attribute certificate, have been=
=A0 =A0 compromised."

=A0 =A0 --
=A0 =A0 Rob Stradling
=A0 =A0 Senior Research & Development Scientist
=A0 =A0 COMODO - Creating Trust Online




--
Website: http://halla= mbaker.com/


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


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
=A0 3rd Floor, 26 Office Village, Exchange Quay,
=A0 Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to whom they are addressed.= =A0If you have received this email in error please notify the sender by re= plying to the e-mail containing this attachment. Replies to this email may = be monitored by COMODO for operational or business reasons. Whilst every en= deavour is taken to ensure that e-mails are free from viruses, no liability= can be accepted and the recipient is requested to use their own virus chec= king software.



--
Website: http://hallambaker.com/
--e89a8f234d4911b91004de6a545f-- From hallam@gmail.com Wed Jun 5 09:04:59 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB25A21F9A87 for ; Wed, 5 Jun 2013 09:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOSaNZZCbYBV for ; Wed, 5 Jun 2013 09:04:58 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7BF21F9A52 for ; Wed, 5 Jun 2013 09:04:57 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so1446679wes.40 for ; Wed, 05 Jun 2013 09:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SISGZs7d4JyoKVjW9zdjThIpqSBA6eMyarRwwcmYxs0=; b=Yazfs8U3BgBuwxAjYKDAHV0x6wPnlLtniZIk9zlmLjWKll1cu3bsKPfleIARL3vXaz vjYzSWyDxkvVpeCqcQsB5Vd87bZvBeVPmA3OpYBubBe3AeaOktHJkY/dDhP7mCASy4I+ fcOXeCW+8jC/u57fHyq9vnpZx9ab8xsVgu3d6lY1upH8HEd7Wvv9jASJp0HoTbTZjpoZ B45+7kt701rSyg5SdB7ea1DVKFRA9sTyG+GRwE2BqDruvM3g7guu4Mt9n90HuzkpvBQh Idh/wYK1ZgwVakS47qKEggwDDFWcQd2kMYRqA9mlic9uT1QKRJkI9q9rcDsfD9/EBsmk ubIg== MIME-Version: 1.0 X-Received: by 10.180.160.197 with SMTP id xm5mr7097633wib.63.1370448296474; Wed, 05 Jun 2013 09:04:56 -0700 (PDT) Received: by 10.194.60.195 with HTTP; Wed, 5 Jun 2013 09:04:56 -0700 (PDT) In-Reply-To: References: <51AF484D.6040207@comodo.com> Date: Wed, 5 Jun 2013 12:04:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: multipart/alternative; boundary=047d7b604172e4ffa204de6a5b2a Cc: Rob Stradling , Adam Langley , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:05:00 -0000 --047d7b604172e4ffa204de6a5b2a Content-Type: text/plain; charset=ISO-8859-1 I am trying to unpack what you are saying here. The best way forward as far as I can see is to start of and ask CAs to describe what types of revocation they support and describe their implementation. Then ask what clients take notice of. On Wed, Jun 5, 2013 at 11:07 AM, Carl Wallace wrote: > > On 6/5/13 10:16 AM, "Rob Stradling" wrote: > > >On 05/06/13 15:12, Phillip Hallam-Baker wrote: > >> Heh, I was hoping not to have to reference that one. > >> > >> The RFCs are meant to specify everything needed to interpret the specs. > > > >Indeed. It seems odd to me that RFC5280 only references X.509 > >Informatively rather than Normatively. > > It'd be nice if your doc included a taxonomy of the various types of CRLs > that can exist based on the combinations of {dp name/no dp name}, {some > reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and > perhaps indicated what combinations are present in the web pki. I assume > one need not grapple with DSA parameter inheritance while processing > indirect DP CRLs that use relative to issuer names and cover only EE certs > for the keyCompromise reason code with a delta CRL stream available where > the CRL issuer's certificate has been signed by a rolled over CA key and > whose revocation status is checked using pregenerated OCSP responses > signed by a delegated responder that requires signed OCSP requests with > noCheck asserted in the responder's certificate. > > > > >> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling >> > wrote: > >> > >> On 04/06/13 22:51, Phillip Hallam-Baker wrote: > >> > >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley >> > >> >> wrote: > >> > >> > >> > >> Not to mention, does anyone have any idea what an > >> aACompromise could > >> mean? > >> > >> > >> Its an attribute authority. For attribute certs. > >> > >> Well actually that is only a supposition because none of the > >> terms seem > >> to be defined. > >> > >> > >> X.509 (11/2008) defines the reason codes as follows... > >> > >> "8.5.2.2 Reason code extension > >> ... > >> The following reason code values indicate why a certificate was > >>revoked: > >> - 'unspecified' can be used to revoke certificates for reasons > >> other than the specific codes; > >> - 'keyCompromise' is used in revoking an end-entity certificate; > >> it indicates that it is known or suspected that the subject's > >> private key, or other aspects of the subject validated in the > >> certificate, have been compromised; > >> - 'cACompromise' is used in revoking a CA-certificate; it > >> indicates that it is known or suspected that the subject's private > >> key, or other aspects of the subject validated in the certificate, > >> have been compromised; > >> - 'affiliationChanged' indicates that the subject's name or other > >> information in the certificate has been modified but there is no > >> cause to suspect that the private key has been compromised; > >> - 'superseded' indicates that the certificate has been superseded > >> but there is no cause to suspect that the private key has been > >> compromised; > >> - 'cessationOfOperation' indicates that the certificate is no > >> longer needed for the purpose for which it was issued but there is > >> no cause to suspect that the private key has been compromised; > >> - 'privilegeWithdrawn' indicates that a certificate (public-key > >> or attribute certificate) was revoked because a privilege contained > >> within that certificate has been withdrawn; > >> - 'aACompromise' indicates that it is known or suspected that > >> aspects of the AA validated in the attribute certificate, have been > >> compromised." > >> > >> -- > >> Rob Stradling > >> Senior Research & Development Scientist > >> COMODO - Creating Trust Online > >> > >> > >> > >> > >> -- > >> Website: http://hallambaker.com/ > >> > >> > >> _______________________________________________ > >> wpkops mailing list > >> wpkops@ietf.org > >> https://www.ietf.org/mailman/listinfo/wpkops > >> > > > >-- > >Rob Stradling > >Senior Research & Development Scientist > >COMODO - Creating Trust Online > >Office Tel: +44.(0)1274.730505 > >Office Fax: +44.(0)1274.730909 > >www.comodo.com > > > >COMODO CA Limited, Registered in England No. 04058690 > >Registered Office: > > 3rd Floor, 26 Office Village, Exchange Quay, > > Trafford Road, Salford, Manchester M5 3EQ > > > >This e-mail and any files transmitted with it are confidential and > >intended solely for the use of the individual or entity to whom they are > >addressed. If you have received this email in error please notify the > >sender by replying to the e-mail containing this attachment. Replies to > >this email may be monitored by COMODO for operational or business > >reasons. Whilst every endeavour is taken to ensure that e-mails are free > >from viruses, no liability can be accepted and the recipient is > >requested to use their own virus checking software. > >_______________________________________________ > >wpkops mailing list > >wpkops@ietf.org > >https://www.ietf.org/mailman/listinfo/wpkops > > > -- Website: http://hallambaker.com/ --047d7b604172e4ffa204de6a5b2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am trying to unpack what you are saying here.

The best way forward as far as I can see is to start of and = ask CAs to describe what types of revocation they support and describe thei= r implementation. Then ask what clients take notice of.





On Wed, Jun 5, 2013= at 11:07 AM, Carl Wallace <carl@redhoundsoftware.com> wrote:

On 6/5/13 10:16 AM, "Rob Stradling" <rob.stradling@comodo.com> wrote:

>On 05/06/13 15:12, Phillip Hallam-Baker wrote:
>> Heh, I was hoping not to have to reference that one.
>>
>> The RFCs are meant to specify everything needed to interpret the s= pecs.
>
>Indeed. =A0It seems odd to me that RFC5280 only references X.509
>Informatively rather than Normatively.

It'd be nice if your doc included a taxonomy of the various types= of CRLs
that can exist based on the combinations of {dp name/no dp name}, {some
reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and
perhaps indicated what combinations are present in the web pki. I assume one need not grapple with DSA parameter inheritance while processing
indirect DP CRLs that use relative to issuer names and cover only EE certs<= br> for the keyCompromise reason code with a delta CRL stream available where the CRL issuer's certificate has been signed by a rolled over CA key an= d
whose revocation status is checked using pregenerated OCSP responses
signed by a delegated responder that requires signed OCSP requests with
noCheck asserted in the responder's certificate.

>
>> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <rob.stradling@comodo.com
>> <mailto:rob.stradli= ng@comodo.com>> wrote:
>>
>> =A0 =A0 On 04/06/13 22:51, Phillip Hallam-Baker wrote:
>>
>> =A0 =A0 =A0 =A0 On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley <<= a href=3D"mailto:agl@chromium.org">agl@chromium.org
>> =A0 =A0 =A0 =A0 <mailto:agl= @chromium.org>
>> =A0 =A0 =A0 =A0 <mailto:agl= @chromium.org <mailto:agl@chromi= um.org>>> wrote:
>>
>> =A0 =A0 <snip>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Not to mention, does anyone have any id= ea what an
>> =A0 =A0 =A0 =A0 aACompromise could
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0mean?
>>
>>
>> =A0 =A0 =A0 =A0 Its an attribute authority. For attribute certs. >>
>> =A0 =A0 =A0 =A0 Well actually that is only a supposition because n= one of the
>> =A0 =A0 =A0 =A0 terms seem
>> =A0 =A0 =A0 =A0 to be defined.
>>
>>
>> =A0 =A0 X.509 (11/2008) defines the reason codes as follows...
>>
>> =A0 =A0 "8.5.2.2 =A0Reason code extension
>> =A0 =A0 ...
>> =A0 =A0 The following reason code values indicate why a certificat= e was
>>revoked:
>> =A0 =A0 =A0 =A0- 'unspecified' can be used to revoke certi= ficates for reasons
>> =A0 =A0 other than the specific codes;
>> =A0 =A0 =A0 =A0- 'keyCompromise' is used in revoking an en= d-entity certificate;
>> =A0 =A0 it indicates that it is known or suspected that the subjec= t's
>> =A0 =A0 private key, or other aspects of the subject validated in = the
>> =A0 =A0 certificate, have been compromised;
>> =A0 =A0 =A0 =A0- 'cACompromise' is used in revoking a CA-c= ertificate; it
>> =A0 =A0 indicates that it is known or suspected that the subject&#= 39;s private
>> =A0 =A0 key, or other aspects of the subject validated in the cert= ificate,
>> =A0 =A0 have been compromised;
>> =A0 =A0 =A0 =A0- 'affiliationChanged' indicates that the s= ubject's name or other
>> =A0 =A0 information in the certificate has been modified but there= is no
>> =A0 =A0 cause to suspect that the private key has been compromised= ;
>> =A0 =A0 =A0 =A0- 'superseded' indicates that the certifica= te has been superseded
>> =A0 =A0 but there is no cause to suspect that the private key has = been
>> =A0 =A0 compromised;
>> =A0 =A0 =A0 =A0- 'cessationOfOperation' indicates that the= certificate is no
>> =A0 =A0 longer needed for the purpose for which it was issued but = there is
>> =A0 =A0 no cause to suspect that the private key has been compromi= sed;
>> =A0 =A0 =A0 =A0- 'privilegeWithdrawn' indicates that a cer= tificate (public-key
>> =A0 =A0 or attribute certificate) was revoked because a privilege = contained
>> =A0 =A0 within that certificate has been withdrawn;
>> =A0 =A0 =A0 =A0- 'aACompromise' indicates that it is known= or suspected that
>> =A0 =A0 aspects of the AA validated in the attribute certificate, = have been
>> =A0 =A0 compromised."
>>
>> =A0 =A0 --
>> =A0 =A0 Rob Stradling
>> =A0 =A0 Senior Research & Development Scientist
>> =A0 =A0 COMODO - Creating Trust Online
>>
>>
>>
>>
>> --
>> Website: htt= p://hallambaker.com/
>>
>>
>> _______________________________________________
>> wpkops mailing list
>> wpkops@ietf.org
>> https://www.ietf.org/mailman/listinfo/wpkops
>>
>
>--
>Rob Stradling
>Senior Research & Development Scientist
>COMODO - Creating Trust Online
>Office Tel: +44.(0)1274.730505
>Office Fax: +44.(0)1274.730909
>www.comodo.com<= br> >
>COMODO CA Limited, Registered in England No. 04058690
>Registered Office:
> =A0 3rd Floor, 26 Office Village, Exchange Quay,
> =A0 Trafford Road, Salford, Manchester M5 3EQ
>
>This e-mail and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they ar= e
>addressed. =A0If you have received this email in error please notify th= e
>sender by replying to the e-mail containing this attachment. Replies to=
>this email may be monitored by COMODO for operational or business
>reasons. Whilst every endeavour is taken to ensure that e-mails are fre= e
>from viruses, no liability can be accepted and the recipient is
>requested to use their own virus checking software.
>_______________________________________________
>wpkops mailing list
>wpkops@ietf.org
>https://www.ietf.org/mailman/listinfo/wpkops





--
= Website: http://hallambaker.com/
--047d7b604172e4ffa204de6a5b2a-- From carl@redhoundsoftware.com Wed Jun 5 09:53:43 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0A21F9C20 for ; Wed, 5 Jun 2013 09:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTfv5PYmrgGA for ; Wed, 5 Jun 2013 09:53:42 -0700 (PDT) Received: from mail-gg0-x233.google.com (mail-gg0-x233.google.com [IPv6:2607:f8b0:4002:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id F196921F9C18 for ; Wed, 5 Jun 2013 09:53:41 -0700 (PDT) Received: by mail-gg0-f179.google.com with SMTP id c4so407872ggn.10 for ; Wed, 05 Jun 2013 09:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=fCz/4kkFAoAK6RXk/f5TFAXn7vdjhh6bPncOm7A+nFw=; b=nZgQKoWvCLbpn3uzTiu/T76xURKmTtpglsZMK32KGzKdSBq+MOr4IGmWGjJx4F7ASD Igz2aTrUr62NDTu/l3aXMDAbJMJ2U2uI4+YVjVmFJ3ibJrWSIaYYvqHgHtm76DqauS9i I7YQq6ZWDHCPvSFHZfRx1ur4fEctSj74POMicG7e4EhxFAtqXTDjZ+6bI4y6N4RjNXJr wHRHqO9awd7ej6v572HDiWxkoMPAbvHC2H3PdMB6SJDOrG20ME+UGVba1l7ezSrM1BH8 U+DA3e0+yIZmAj3aefHx0cJMNlgwWdSwLe94EyEd2T6D5mbXZDlwUyud6k3d/ShoqnVo Y7uw== X-Received: by 10.236.48.99 with SMTP id u63mr24460440yhb.188.1370451221266; Wed, 05 Jun 2013 09:53:41 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-116-61.washdc.fios.verizon.net. [173.79.116.61]) by mx.google.com with ESMTPSA id f30sm100410075yhi.21.2013.06.05.09.53.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Jun 2013 09:53:40 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Wed, 05 Jun 2013 12:53:37 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [wpkops] Some questions about revocation reasons In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3453281620_2548877" X-Gm-Message-State: ALoCoQmx8Ge2yVUj8uRKfj7vUSUMYM/Mr03H5t6CCTN8T6UwlbPBfCjwKqIdeWeMXSrF59jhYjkB Cc: Rob Stradling , Adam Langley , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 16:53:44 -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_3453281620_2548877 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Phillip Hallam-Baker Date: Wednesday, June 5, 2013 12:04 PM To: Carl Wallace Cc: Rob Stradling , "wpkops@ietf.org" , Adam Langley Subject: Re: [wpkops] Some questions about revocation reasons > I am trying to unpack what you are saying here. > > The best way forward as far as I can see is to start of and ask CAs to > describe what types of revocation they support and describe their > implementation. Then ask what clients take notice of. > Having some means of naming the combinations may be helpful. X.509 sort of has a scheme. Maybe something like: Full: CRL (all types), EPRL (ee only), CARL (CA only) Indirect: iCRL, iEPRL, iCARL Delta: dCRL, dEPRL, dCARL Indirect Delta: idCRL, idEPRL, idCARL Distribution Point: dpCRL, dpEPRL, dpCARL Indirect Distribution Point: idpCRL, idpEPRL, idpCARL Delta Distribution Point: ddpCRL, ddpEPRL, ddpCARL Indirect Delta Distribution Point: iddpCRL, iddpEPRL, iddpCARL Any of these types could be further subdivided by reason code. If you just accept there are two categories of reason code partitioning, some or all, then there are at least 48 types. This is ignoring the attribute certificate stuff entirely and assumes I have not missed a relevant knob. > > > > > On Wed, Jun 5, 2013 at 11:07 AM, Carl Wallace > wrote: >> >> On 6/5/13 10:16 AM, "Rob Stradling" wrote: >> >>> >On 05/06/13 15:12, Phillip Hallam-Baker wrote: >>>> >> Heh, I was hoping not to have to reference that one. >>>> >> >>>> >> The RFCs are meant to specify everything needed to interpret the specs. >>> > >>> >Indeed. It seems odd to me that RFC5280 only references X.509 >>> >Informatively rather than Normatively. >> >> It'd be nice if your doc included a taxonomy of the various types of CRLs >> that can exist based on the combinations of {dp name/no dp name}, {some >> reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and >> perhaps indicated what combinations are present in the web pki. I assume >> one need not grapple with DSA parameter inheritance while processing >> indirect DP CRLs that use relative to issuer names and cover only EE certs >> for the keyCompromise reason code with a delta CRL stream available where >> the CRL issuer's certificate has been signed by a rolled over CA key and >> whose revocation status is checked using pregenerated OCSP responses >> signed by a delegated responder that requires signed OCSP requests with >> noCheck asserted in the responder's certificate. >> >>> > >>>> >> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling >>> >> > wrote: >>>> >> >>>> >> On 04/06/13 22:51, Phillip Hallam-Baker wrote: >>>> >> >>>> >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley >>> >> >>>> >> >> wrote: >>>> >> >>>> >> >>>> >> >>>> >> Not to mention, does anyone have any idea what an >>>> >> aACompromise could >>>> >> mean? >>>> >> >>>> >> >>>> >> Its an attribute authority. For attribute certs. >>>> >> >>>> >> Well actually that is only a supposition because none of the >>>> >> terms seem >>>> >> to be defined. >>>> >> >>>> >> >>>> >> X.509 (11/2008) defines the reason codes as follows... >>>> >> >>>> >> "8.5.2.2 Reason code extension >>>> >> ... >>>> >> The following reason code values indicate why a certificate was >>>> >>revoked: >>>> >> - 'unspecified' can be used to revoke certificates for reasons >>>> >> other than the specific codes; >>>> >> - 'keyCompromise' is used in revoking an end-entity certificate; >>>> >> it indicates that it is known or suspected that the subject's >>>> >> private key, or other aspects of the subject validated in the >>>> >> certificate, have been compromised; >>>> >> - 'cACompromise' is used in revoking a CA-certificate; it >>>> >> indicates that it is known or suspected that the subject's private >>>> >> key, or other aspects of the subject validated in the certificate, >>>> >> have been compromised; >>>> >> - 'affiliationChanged' indicates that the subject's name or other >>>> >> information in the certificate has been modified but there is no >>>> >> cause to suspect that the private key has been compromised; >>>> >> - 'superseded' indicates that the certificate has been superseded >>>> >> but there is no cause to suspect that the private key has been >>>> >> compromised; >>>> >> - 'cessationOfOperation' indicates that the certificate is no >>>> >> longer needed for the purpose for which it was issued but there is >>>> >> no cause to suspect that the private key has been compromised; >>>> >> - 'privilegeWithdrawn' indicates that a certificate (public-key >>>> >> or attribute certificate) was revoked because a privilege contained >>>> >> within that certificate has been withdrawn; >>>> >> - 'aACompromise' indicates that it is known or suspected that >>>> >> aspects of the AA validated in the attribute certificate, have been >>>> >> compromised." >>>> >> >>>> >> -- >>>> >> Rob Stradling >>>> >> Senior Research & Development Scientist >>>> >> COMODO - Creating Trust Online >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Website: http://hallambaker.com/ >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> wpkops mailing list >>>> >> wpkops@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/wpkops >>>> >> >>> > >>> >-- >>> >Rob Stradling >>> >Senior Research & Development Scientist >>> >COMODO - Creating Trust Online >>> >Office Tel: +44.(0)1274.730505 >>> >Office Fax: +44.(0)1274.730909 >>> >www.comodo.com >>> > >>> >COMODO CA Limited, Registered in England No. 04058690 >>> >Registered Office: >>> > 3rd Floor, 26 Office Village, Exchange Quay, >>> > Trafford Road, Salford, Manchester M5 3EQ >>> > >>> >This e-mail and any files transmitted with it are confidential and >>> >intended solely for the use of the individual or entity to whom they are >>> >addressed. If you have received this email in error please notify the >>> >sender by replying to the e-mail containing this attachment. Replies to >>> >this email may be monitored by COMODO for operational or business >>> >reasons. Whilst every endeavour is taken to ensure that e-mails are free >>> >from viruses, no liability can be accepted and the recipient is >>> >requested to use their own virus checking software. >>> >_______________________________________________ >>> >wpkops mailing list >>> >wpkops@ietf.org >>> >https://www.ietf.org/mailman/listinfo/wpkops >> >> > > > > -- > Website: http://hallambaker.com/ --B_3453281620_2548877 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Wednesday, June 5, 2013 12:04 PM
To: <= /span> Carl Wallace <carl@redh= oundsoftware.com>
Cc: Rob S= tradling <rob.stradling@comodo.= com>, "wpkops@ietf.org" <wpkops@ietf.org>, Adam Langley <agl@chromium.org>
Subject: Re: [wpkops] Some questions about revocation re= asons

I am trying to unpack what you are saying here.

The best way forward as far as I can see is to start of and = ask CAs to describe what types of revocation they support and describe their= implementation. Then ask what clients take notice of.

Having some means= of naming the combinations may be helpful.  X.509 sort of has a scheme= .  Maybe something like:

Full:  CRL (all types)= , EPRL (ee only), CARL (CA only)
Indirect:  iCRL, iEPRL, iCARL
=
Delta:  = dCRL, dEPRL, dCARL
Indirect Delta: idCRL, idEPRL, idCARL
=

Distribution Point:  dpCRL, dpEPRL, dpCARL
Indirec= t Distribution Point:  idpCRL, idpEPRL, idpCARL 
Delta Distribution= Point:  = ; ddpCRL, d= dpEPRL, ddpCARL
Indirect Delta Distribution Point: iddpCRL, iddpEPRL, iddpCARL=

Any of these types could be further subdivided by = reason code.  If you just accept there are two categories of reason cod= e partitioning, some or all, then there are at least 48 types.  This is= ignoring the attribute certificate stuff entirely and assumes I have not mi= ssed a relevant knob.  






On Wed, Jun 5, 2013 at 11:07= AM, Carl Wallace <carl@redhoundsoftware.com> wrote:

On 6/5/13 10:16 AM, "Rob Stradling" <rob.stradling@comodo.com> wrote:

>On 05/06/13 15:12, Phillip Hallam-Baker wrote:
>> Heh, I was hoping not to have to reference that one.
>>
>> The RFCs are meant to specify everything needed to interpret the s= pecs.
>
>Indeed.  It seems odd to me that RFC5280 only references X.509
= >Informatively rather than Normatively.

It'd be nice if you= r doc included a taxonomy of the various types of CRLs
that can exist based on the combinations of {dp name/no dp name}, {some
= reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and
= perhaps indicated what combinations are present in the web pki. I assume one need not grapple with DSA parameter inheritance while processing
indirect DP CRLs that use relative to issuer names and cover only EE certs<= br> for the keyCompromise reason code with a delta CRL stream available where the CRL issuer's certificate has been signed by a rolled over CA key and whose revocation status is checked using pregenerated OCSP responses
signed by a delegated responder that requires signed OCSP requests with
= noCheck asserted in the responder's certificate.

>
>> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <rob.stradling@comodo.com
>> <mailto:rob.stradling= @comodo.com>> wrote:
>>
>>     On 04/06/13 22:51, Phillip Hallam-Baker wrote:
>>
>>         On Tue, Jun 4, 2013 at 5:39 PM, Adam L= angley <agl@chromium.org
>>         <mailto:agl@chromium.org>
>>         <mailto:agl@chromium.org <mailto:agl= @chromium.org>>> wrote:
>>
>>     <snip>
>>
>>              Not to mention, do= es anyone have any idea what an
>>         aACompromise could
>>              mean?
>>
>>
>>         Its an attribute authority. For attrib= ute certs.
>>
>>         Well actually that is only a suppositi= on because none of the
>>         terms seem
>>         to be defined.
>>
>>
>>     X.509 (11/2008) defines the reason codes as follows.= ..
>>
>>     "8.5.2.2  Reason code extension
>>     ...
>>     The following reason code values indicate why a cert= ificate was
>>revoked:
>>        - 'unspecified' can be used to revoke c= ertificates for reasons
>>     other than the specific codes;
>>        - 'keyCompromise' is used in revoking a= n end-entity certificate;
>>     it indicates that it is known or suspected that the = subject's
>>     private key, or other aspects of the subject validat= ed in the
>>     certificate, have been compromised;
>>        - 'cACompromise' is used in revoking a = CA-certificate; it
>>     indicates that it is known or suspected that the sub= ject's private
>>     key, or other aspects of the subject validated in th= e certificate,
>>     have been compromised;
>>        - 'affiliationChanged' indicates that t= he subject's name or other
>>     information in the certificate has been modified but= there is no
>>     cause to suspect that the private key has been compr= omised;
>>        - 'superseded' indicates that the certi= ficate has been superseded
>>     but there is no cause to suspect that the private ke= y has been
>>     compromised;
>>        - 'cessationOfOperation' indicates that= the certificate is no
>>     longer needed for the purpose for which it was issue= d but there is
>>     no cause to suspect that the private key has been co= mpromised;
>>        - 'privilegeWithdrawn' indicates that a= certificate (public-key
>>     or attribute certificate) was revoked because a priv= ilege contained
>>     within that certificate has been withdrawn;
>>        - 'aACompromise' indicates that it is k= nown or suspected that
>>     aspects of the AA validated in the attribute certifi= cate, have been
>>     compromised."
>>
>>     --
>>     Rob Stradling
>>     Senior Research & Development Scientist
>>     COMODO - Creating Trust Online
>>
>>
>>
>>
>> --
>> Website: http://= hallambaker.com/
>>
>>
>> _______________________________________________
>> wpkops mailing list
>> wpkops@ietf.org
>> https://www.ietf.org/mailman/listinfo/wpkops
>>
>
>--
>Rob Stradling
>Senior Research & Development Scientist
>COMODO - Creating Trust Online
>Office Tel: +44.(0)1274.730505
>Office Fax: +44.(0)1274.730909
>www.comodo.com
>
>COMODO CA Limited, Registered in England No. 04058690
>Registered Office:
>   3rd Floor, 26 Office Village, Exchange Quay,
>   Trafford Road, Salford, Manchester M5 3EQ
>
>This e-mail and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they ar= e
>addressed.  If you have received this email in error please notify= the
>sender by replying to the e-mail containing this attachment. Replies to=
>this email may be monitored by COMODO for operational or business
>reasons. Whilst every endeavour is taken to ensure that e-mails are fre= e
>from viruses, no liability can be accepted and the recipient is
>requested to use their own virus checking software.
>_______________________________________________
>wpkops mailing list
>wpkops@ietf.org
>= https://www.ietf.org/mailman/listinfo/wpkops





--
Website: http://hallambaker.com/
--B_3453281620_2548877-- From hallam@gmail.com Wed Jun 5 10:26:46 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027E621F99ED for ; Wed, 5 Jun 2013 10:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyiw-pw0PKak for ; Wed, 5 Jun 2013 10:26:35 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8B47821F9AEE for ; Wed, 5 Jun 2013 10:26:29 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so5053034wib.6 for ; Wed, 05 Jun 2013 10:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/b8WKihqbk+YSLAY+jiAUK3LSjAkx2y0PJaA2yPal7Q=; b=tzwdh3TOPIR7RjvFuSZgB2CrosEujvhPK1iIZdu2GzlUT9KI1rtoxi2L0DQzzyDZda dC1VzL0/1pGjKWLO/fmPWN8DNJhiHWB2L2XeQ9SV4ZniUOK9TOrCXtxcmDCcYWcDlwrG MSJYUVSDopKkxSu9IG+M7FzWT2eY6l3GJVEYyVX9kJv4X6kPZJKeDM2kW41yeaXEQlbH D4IEiJp7qwC4+xAxULDku2tKEoRNR9f2uFzKSfeb7KYNij7FH3m9QJLgcLuihvXhPZff 8DKeqYh3ZsvLIfmTnhmqO46y67x4s1uov7MpOTOjJFljWmWDCd0N0BHRmB2s5h0K95OV DB5w== MIME-Version: 1.0 X-Received: by 10.180.109.84 with SMTP id hq20mr7699472wib.11.1370453188586; Wed, 05 Jun 2013 10:26:28 -0700 (PDT) Received: by 10.194.60.195 with HTTP; Wed, 5 Jun 2013 10:26:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Jun 2013 13:26:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: multipart/alternative; boundary=e89a8f3b9db17cb74d04de6b7f52 Cc: Rob Stradling , Adam Langley , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:26:46 -0000 --e89a8f3b9db17cb74d04de6b7f52 Content-Type: text/plain; charset=ISO-8859-1 Probably better to just ask what CRLs they issue and for each whether the frequency of issue for full and deltas, and whether they use distribution points Indirect raises another issue. By definition an indirect CRL is not issued by the issuing CA. But that gets us into some complex semantic games. What does it mean if the GeoTrust CRL is signed by Thawte? Is that indirect or direct? What I am getting at here is that maybe the issues are going to be a little more complex than a binary choice. The term CA can get rather slippery. It is an organizational concept and PKIX only deals in certificates and trust anchors. From a processing standpoint it seems 'obvious' to me that there 'should' be a CRL associated with every certificate signing cert. But the spec was originally written from the assumption that a CA was identical to a trust anchor. So it gets rather murky, particularly as trust anchors were rolled over. Some points to ponder: * Could DigiNotar have issued a CRL that clients would have accepted as validating certs of other CAs? * There is no hierarchy of severity specified for revocation reasons, let alone a duty on CAs to update the reason code if they revoke a cert to correct an error and subsequently find that the certificate application was fraudulent. So relying on the partitioning of CRLs by reason code as defined in the spec looks unsafe to me. On Wed, Jun 5, 2013 at 12:53 PM, Carl Wallace wrote: > > From: Phillip Hallam-Baker > Date: Wednesday, June 5, 2013 12:04 PM > To: Carl Wallace > Cc: Rob Stradling , "wpkops@ietf.org" < > wpkops@ietf.org>, Adam Langley > Subject: Re: [wpkops] Some questions about revocation reasons > > I am trying to unpack what you are saying here. > > The best way forward as far as I can see is to start of and ask CAs to > describe what types of revocation they support and describe their > implementation. Then ask what clients take notice of. > > > Having some means of naming the combinations may be helpful. X.509 sort > of has a scheme. Maybe something like: > > Full: CRL (all types), EPRL (ee only), CARL (CA only) > Indirect: iCRL, iEPRL, iCARL > Delta: dCRL, dEPRL, dCARL > Indirect Delta: idCRL, idEPRL, idCARL > > Distribution Point: dpCRL, dpEPRL, dpCARL > Indirect Distribution Point: idpCRL, idpEPRL, idpCARL > Delta Distribution Point: ddpCRL, ddpEPRL, ddpCARL > Indirect Delta Distribution Point: iddpCRL, iddpEPRL, iddpCARL > > Any of these types could be further subdivided by reason code. If you > just accept there are two categories of reason code partitioning, some or > all, then there are at least 48 types. This is ignoring the attribute > certificate stuff entirely and assumes I have not missed a relevant knob. > > > > > > > On Wed, Jun 5, 2013 at 11:07 AM, Carl Wallace wrote: > >> >> On 6/5/13 10:16 AM, "Rob Stradling" wrote: >> >> >On 05/06/13 15:12, Phillip Hallam-Baker wrote: >> >> Heh, I was hoping not to have to reference that one. >> >> >> >> The RFCs are meant to specify everything needed to interpret the specs. >> > >> >Indeed. It seems odd to me that RFC5280 only references X.509 >> >Informatively rather than Normatively. >> >> It'd be nice if your doc included a taxonomy of the various types of CRLs >> that can exist based on the combinations of {dp name/no dp name}, {some >> reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and >> perhaps indicated what combinations are present in the web pki. I assume >> one need not grapple with DSA parameter inheritance while processing >> indirect DP CRLs that use relative to issuer names and cover only EE certs >> for the keyCompromise reason code with a delta CRL stream available where >> the CRL issuer's certificate has been signed by a rolled over CA key and >> whose revocation status is checked using pregenerated OCSP responses >> signed by a delegated responder that requires signed OCSP requests with >> noCheck asserted in the responder's certificate. >> >> > >> >> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling < >> rob.stradling@comodo.com >> >> > wrote: >> >> >> >> On 04/06/13 22:51, Phillip Hallam-Baker wrote: >> >> >> >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley > >> >> >> >> wrote: >> >> >> >> >> >> >> >> Not to mention, does anyone have any idea what an >> >> aACompromise could >> >> mean? >> >> >> >> >> >> Its an attribute authority. For attribute certs. >> >> >> >> Well actually that is only a supposition because none of the >> >> terms seem >> >> to be defined. >> >> >> >> >> >> X.509 (11/2008) defines the reason codes as follows... >> >> >> >> "8.5.2.2 Reason code extension >> >> ... >> >> The following reason code values indicate why a certificate was >> >>revoked: >> >> - 'unspecified' can be used to revoke certificates for reasons >> >> other than the specific codes; >> >> - 'keyCompromise' is used in revoking an end-entity certificate; >> >> it indicates that it is known or suspected that the subject's >> >> private key, or other aspects of the subject validated in the >> >> certificate, have been compromised; >> >> - 'cACompromise' is used in revoking a CA-certificate; it >> >> indicates that it is known or suspected that the subject's private >> >> key, or other aspects of the subject validated in the certificate, >> >> have been compromised; >> >> - 'affiliationChanged' indicates that the subject's name or >> other >> >> information in the certificate has been modified but there is no >> >> cause to suspect that the private key has been compromised; >> >> - 'superseded' indicates that the certificate has been >> superseded >> >> but there is no cause to suspect that the private key has been >> >> compromised; >> >> - 'cessationOfOperation' indicates that the certificate is no >> >> longer needed for the purpose for which it was issued but there is >> >> no cause to suspect that the private key has been compromised; >> >> - 'privilegeWithdrawn' indicates that a certificate (public-key >> >> or attribute certificate) was revoked because a privilege contained >> >> within that certificate has been withdrawn; >> >> - 'aACompromise' indicates that it is known or suspected that >> >> aspects of the AA validated in the attribute certificate, have been >> >> compromised." >> >> >> >> -- >> >> Rob Stradling >> >> Senior Research & Development Scientist >> >> COMODO - Creating Trust Online >> >> >> >> >> >> >> >> >> >> -- >> >> Website: http://hallambaker.com/ >> >> >> >> >> >> _______________________________________________ >> >> wpkops mailing list >> >> wpkops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/wpkops >> >> >> > >> >-- >> >Rob Stradling >> >Senior Research & Development Scientist >> >COMODO - Creating Trust Online >> >Office Tel: +44.(0)1274.730505 >> >Office Fax: +44.(0)1274.730909 >> >www.comodo.com >> > >> >COMODO CA Limited, Registered in England No. 04058690 >> >Registered Office: >> > 3rd Floor, 26 Office Village, Exchange Quay, >> > Trafford Road, Salford, Manchester M5 3EQ >> > >> >This e-mail and any files transmitted with it are confidential and >> >intended solely for the use of the individual or entity to whom they are >> >addressed. If you have received this email in error please notify the >> >sender by replying to the e-mail containing this attachment. Replies to >> >this email may be monitored by COMODO for operational or business >> >reasons. Whilst every endeavour is taken to ensure that e-mails are free >> >from viruses, no liability can be accepted and the recipient is >> >requested to use their own virus checking software. >> >_______________________________________________ >> >wpkops mailing list >> >wpkops@ietf.org >> >https://www.ietf.org/mailman/listinfo/wpkops >> >> >> > > > -- > Website: http://hallambaker.com/ > > -- Website: http://hallambaker.com/ --e89a8f3b9db17cb74d04de6b7f52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Probably better to just ask what CRLs they issue and for e= ach whether the frequency of issue for full and deltas, and whether they us= e distribution points=A0

Indirect raises another i= ssue. By definition an indirect CRL is not issued by the issuing CA. But th= at gets us into some complex semantic games. What does it mean if the GeoTr= ust CRL is signed by Thawte? Is that indirect or direct?

What I am getting at here is that maybe the= issues are going to be a little more complex than a binary choice. The ter= m CA can get rather slippery. It is an organizational concept and PKIX only= deals in certificates and trust anchors. From a processing standpoint it s= eems 'obvious' to me that there 'should' be a CRL associate= d with every certificate signing cert. But the spec was originally written = from the assumption that a CA was identical to a trust anchor. So it gets r= ather murky, particularly as trust anchors were rolled over.

Some points to ponder:

=
* Could DigiNotar have issued a CRL that clients would hav= e accepted as validating certs of other CAs?=A0

* There is no hierarchy of severity specified for revocation rea= sons, let alone a duty on CAs to update the reason code if they revoke a ce= rt to correct an error and subsequently find that the certificate applicati= on was fraudulent. So relying on the partitioning of CRLs by reason code as= defined in the spec looks unsafe to me.=A0


=

On Wed, Jun 5, 2013 at 12:53 PM, Carl Wa= llace <carl@redhoundsoftware.com> wrote:

From: Phillip Hallam-Baker <hallam@gmail.com>=
Date: Wednesday, June 5, 2013 = 12:04 PM
To: Carl Wallace <carl@redhoundsoftware.com= >
Cc: Rob Stradling <= rob.stradling= @comodo.com>, "wpkops@ietf.org" <wpkops@ietf.org>, Adam Langley <agl@chromium.org>
Subject: Re: [wpkops] Some questio= ns about revocation reasons

I am trying to unpack what you are saying here.

The best= way forward as far as I can see is to start of and ask CAs to describe wha= t types of revocation they support and describe their implementation. Then = ask what clients take notice of.


Hav= ing some means of naming the combinations may be helpful. =A0X.509 sort of = has a scheme. =A0Maybe something like:

Full:=A0 CRL (all types), EPRL (ee = only), CARL (CA only)
Indirect:=A0 iCRL, i= EPRL, iCARL
Delta:=A0 = dCRL, dEPRL, dCARL
Indirect Delta: idCRL, idEPRL, idCARL

Distribution Point:=A0 dpCRL, dpEPRL, dpCARL
Indirect Distribution Point= :=A0 idpCRL, idpEPRL, idpCARL= =A0
Delta Distribution Point: = =A0 ddpCRL, ddpEPRL, ddpCARL<= /div>
Indirect Delta Distribution Point: iddpCRL, iddpEPRL, iddpCARL

Any of these types could be further subdivided by reaso= n code. =A0If you just accept there are two categories of reason code parti= tioning, some or all, then there are at least 48 types. =A0This is ignoring= the attribute certificate stuff entirely and assumes I have not missed a r= elevant knob. =A0






On Wed, Jun 5, 2013 at 11:07 AM, Carl Wallac= e <carl@redhoundsoftware.com> wrote:

On 6/5/13 10:16 AM, "Rob Stradling" <rob.stradling@comodo.com> wrote= :

>On 05/06/13 15:12, Phillip Hallam-Baker wrote:
>> Heh, I was hoping not to have to reference that one.
>>
>> The RFCs are meant to specify everything needed to interpret the s= pecs.
>
>Indeed. =A0It seems odd to me that RFC5280 only references X.509
>Informatively rather than Normatively.

It'd be nice if= your doc included a taxonomy of the various types of CRLs
that can exist based on the combinations of {dp name/no dp name}, {some
reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and
perhaps indicated what combinations are present in the web pki. I assume one need not grapple with DSA parameter inheritance while processing
indirect DP CRLs that use relative to issuer names and cover only EE certs<= br> for the keyCompromise reason code with a delta CRL stream available where the CRL issuer's certificate has been signed by a rolled over CA key an= d
whose revocation status is checked using pregenerated OCSP responses
signed by a delegated responder that requires signed OCSP requests with
noCheck asserted in the responder's certificate.

>
>> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <rob.stradling@comodo.com<= br> >> <mailto:rob.stradling@comodo.com>> wrote:
>>
>> =A0 =A0 On 04/06/13 22:51, Phillip Hallam-Baker wrote:
>>
>> =A0 =A0 =A0 =A0 On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley <<= a href=3D"mailto:agl@chromium.org" target=3D"_blank">agl@chromium.org >> =A0 =A0 =A0 =A0 <mailto:agl@chromium.org>
>> =A0 =A0 =A0 =A0 <mailto:agl@chromium.org <mailto:agl@chromium.org>>> wrote:
>>
>> =A0 =A0 <snip>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Not to mention, does anyone have any id= ea what an
>> =A0 =A0 =A0 =A0 aACompromise could
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0mean?
>>
>>
>> =A0 =A0 =A0 =A0 Its an attribute authority. For attribute certs. >>
>> =A0 =A0 =A0 =A0 Well actually that is only a supposition because n= one of the
>> =A0 =A0 =A0 =A0 terms seem
>> =A0 =A0 =A0 =A0 to be defined.
>>
>>
>> =A0 =A0 X.509 (11/2008) defines the reason codes as follows...
>>
>> =A0 =A0 "8.5.2.2 =A0Reason code extension
>> =A0 =A0 ...
>> =A0 =A0 The following reason code values indicate why a certificat= e was
>>revoked:
>> =A0 =A0 =A0 =A0- 'unspecified' can be used to revoke certi= ficates for reasons
>> =A0 =A0 other than the specific codes;
>> =A0 =A0 =A0 =A0- 'keyCompromise' is used in revoking an en= d-entity certificate;
>> =A0 =A0 it indicates that it is known or suspected that the subjec= t's
>> =A0 =A0 private key, or other aspects of the subject validated in = the
>> =A0 =A0 certificate, have been compromised;
>> =A0 =A0 =A0 =A0- 'cACompromise' is used in revoking a CA-c= ertificate; it
>> =A0 =A0 indicates that it is known or suspected that the subject&#= 39;s private
>> =A0 =A0 key, or other aspects of the subject validated in the cert= ificate,
>> =A0 =A0 have been compromised;
>> =A0 =A0 =A0 =A0- 'affiliationChanged' indicates that the s= ubject's name or other
>> =A0 =A0 information in the certificate has been modified but there= is no
>> =A0 =A0 cause to suspect that the private key has been compromised= ;
>> =A0 =A0 =A0 =A0- 'superseded' indicates that the certifica= te has been superseded
>> =A0 =A0 but there is no cause to suspect that the private key has = been
>> =A0 =A0 compromised;
>> =A0 =A0 =A0 =A0- 'cessationOfOperation' indicates that the= certificate is no
>> =A0 =A0 longer needed for the purpose for which it was issued but = there is
>> =A0 =A0 no cause to suspect that the private key has been compromi= sed;
>> =A0 =A0 =A0 =A0- 'privilegeWithdrawn' indicates that a cer= tificate (public-key
>> =A0 =A0 or attribute certificate) was revoked because a privilege = contained
>> =A0 =A0 within that certificate has been withdrawn;
>> =A0 =A0 =A0 =A0- 'aACompromise' indicates that it is known= or suspected that
>> =A0 =A0 aspects of the AA validated in the attribute certificate, = have been
>> =A0 =A0 compromised."
>>
>> =A0 =A0 --
>> =A0 =A0 Rob Stradling
>> =A0 =A0 Senior Research & Development Scientist
>> =A0 =A0 COMODO - Creating Trust Online
>>
>>
>>
>>
>> --
>> Website: htt= p://hallambaker.com/
>>
>>
>> _______________________________________________
>> wpkops mailing list
>> wpkops@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/wpkops
>>
>
>--
>Rob Stradling
>Senior Research & Development Scientist
>COMODO - Creating Trust Online
>Office Tel: +44.(0)1274.730505
>Office Fax: +44.(0)1274.730909
>www.comodo.com<= br> >
>COMODO CA Limited, Registered in England No. 04058690
>Registered Office:
> =A0 3rd Floor, 26 Office Village, Exchange Quay,
> =A0 Trafford Road, Salford, Manchester M5 3EQ
>
>This e-mail and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they ar= e
>addressed. =A0If you have received this email in error please notify th= e
>sender by replying to the e-mail containing this attachment. Replies to=
>this email may be monitored by COMODO for operational or business
>reasons. Whilst every endeavour is taken to ensure that e-mails are fre= e
>from viruses, no liability can be accepted and the recipient is
>requested to use their own virus checking software.
>_______________________________________________
>wpkops mailing list
>wpkops@ietf.org
>https://www.ietf.org/mailman/listinfo/wpkops





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



--
Website: http://hallambaker.com/
--e89a8f3b9db17cb74d04de6b7f52-- From carl@redhoundsoftware.com Wed Jun 5 10:33:28 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373C821F9A19 for ; Wed, 5 Jun 2013 10:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vcqcrxcpota1 for ; Wed, 5 Jun 2013 10:33:17 -0700 (PDT) Received: from mail-ye0-f174.google.com (mail-ye0-f174.google.com [209.85.213.174]) by ietfa.amsl.com (Postfix) with ESMTP id F106021F99ED for ; Wed, 5 Jun 2013 10:33:16 -0700 (PDT) Received: by mail-ye0-f174.google.com with SMTP id m10so426707yen.33 for ; Wed, 05 Jun 2013 10:33:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=3DlYl1lvnK4GLsPP2+mBrJD3Q7qReiCfIBk2boFm5X8=; b=FlaqBO1gV71zla+OXfzVFmtqwO0Wz8zABoMbYCKIASIMfalJU8qb/B/jX4tF35wPZL tMGt+JtoVtzQ4vUsx5apmyH6HmncPHAzF9yvDsfhacAc+/op7YfECBmJ5WjS9aWq9KfO KBaSuCbj25rsHwdIf0P35H5UNG5duI6QupDwgyHHRaxH4M7yd4+3OjQZRdJX8Yxh6ELN ghPey3bhYBxAPh5/cr/9yx+ABti9kygh0/ryNrKT3P8h1EbzVtpbbX3VRRntZrexqQNA 80VXgTaVDhsVMw2z7o90VSVL3StL6dVNmTve6QuiLiQD/QBGG9R1X/P6nbporCe2S2w3 NNAg== X-Received: by 10.236.185.106 with SMTP id t70mr21470652yhm.48.1370453596429; Wed, 05 Jun 2013 10:33:16 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-116-61.washdc.fios.verizon.net. [173.79.116.61]) by mx.google.com with ESMTPSA id v27sm108570809yhj.12.2013.06.05.10.33.13 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Jun 2013 10:33:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Wed, 05 Jun 2013 13:33:11 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [wpkops] Some questions about revocation reasons In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3453283995_2737369" X-Gm-Message-State: ALoCoQn8Gqdxl4ZFmFcqH33eFyKu8+507XqG+7caQFBpRfr9Rjh72DdMXLRvvJMJioR072t8kjjj Cc: Rob Stradling , Adam Langley , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:33:28 -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_3453283995_2737369 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Phillip Hallam-Baker Date: Wednesday, June 5, 2013 1:26 PM To: Carl Wallace Cc: Rob Stradling , "wpkops@ietf.org" , Adam Langley Subject: Re: [wpkops] Some questions about revocation reasons > Probably better to just ask what CRLs they issue and for each whether the > frequency of issue for full and deltas, and whether they use distribution > points I don't think so. Part of the point could be to identify and stamp out some of the unused corners. Denying the existence of such things does not seem helpful. Documenting pervasive lack of support (which I thought was part of this effort) may help. > > Indirect raises another issue. By definition an indirect CRL is not issued by > the issuing CA. But that gets us into some complex semantic games. What does > it mean if the GeoTrust CRL is signed by Thawte? Is that indirect or direct? > > What I am getting at here is that maybe the issues are going to be a little > more complex than a binary choice. The term CA can get rather slippery. It is > an organizational concept and PKIX only deals in certificates and trust > anchors. From a processing standpoint it seems 'obvious' to me that there > 'should' be a CRL associated with every certificate signing cert. But the spec > was originally written from the assumption that a CA was identical to a trust > anchor. So it gets rather murky, particularly as trust anchors were rolled > over. > > Some points to ponder: > > * Could DigiNotar have issued a CRL that clients would have accepted as > validating certs of other CAs? Or if not a CRL, could DigiNotar have issued an OCSP responder certificate that was authorized to provide responses for any CA? > > * There is no hierarchy of severity specified for revocation reasons, let > alone a duty on CAs to update the reason code if they revoke a cert to correct > an error and subsequently find that the certificate application was > fraudulent. So relying on the partitioning of CRLs by reason code as defined > in the spec looks unsafe to me. > > > > > On Wed, Jun 5, 2013 at 12:53 PM, Carl Wallace > wrote: >> >> From: Phillip Hallam-Baker >> Date: Wednesday, June 5, 2013 12:04 PM >> To: Carl Wallace >> Cc: Rob Stradling , "wpkops@ietf.org" >> , Adam Langley >> Subject: Re: [wpkops] Some questions about revocation reasons >> >>> I am trying to unpack what you are saying here. >>> >>> The best way forward as far as I can see is to start of and ask CAs to >>> describe what types of revocation they support and describe their >>> implementation. Then ask what clients take notice of. >>> >> >> Having some means of naming the combinations may be helpful. X.509 sort of >> has a scheme. Maybe something like: >> >> Full: CRL (all types), EPRL (ee only), CARL (CA only) >> Indirect: iCRL, iEPRL, iCARL >> Delta: dCRL, dEPRL, dCARL >> Indirect Delta: idCRL, idEPRL, idCARL >> >> Distribution Point: dpCRL, dpEPRL, dpCARL >> Indirect Distribution Point: idpCRL, idpEPRL, idpCARL >> Delta Distribution Point: ddpCRL, ddpEPRL, ddpCARL >> Indirect Delta Distribution Point: iddpCRL, iddpEPRL, iddpCARL >> >> Any of these types could be further subdivided by reason code. If you just >> accept there are two categories of reason code partitioning, some or all, >> then there are at least 48 types. This is ignoring the attribute certificate >> stuff entirely and assumes I have not missed a relevant knob. >> >> >>> >>> >>> >>> >>> On Wed, Jun 5, 2013 at 11:07 AM, Carl Wallace >>> wrote: >>>> >>>> On 6/5/13 10:16 AM, "Rob Stradling" wrote: >>>> >>>>> >On 05/06/13 15:12, Phillip Hallam-Baker wrote: >>>>>> >> Heh, I was hoping not to have to reference that one. >>>>>> >> >>>>>> >> The RFCs are meant to specify everything needed to interpret the >>>>>> specs. >>>>> > >>>>> >Indeed. It seems odd to me that RFC5280 only references X.509 >>>>> >Informatively rather than Normatively. >>>> >>>> It'd be nice if your doc included a taxonomy of the various types of CRLs >>>> that can exist based on the combinations of {dp name/no dp name}, {some >>>> reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and >>>> perhaps indicated what combinations are present in the web pki. I assume >>>> one need not grapple with DSA parameter inheritance while processing >>>> indirect DP CRLs that use relative to issuer names and cover only EE certs >>>> for the keyCompromise reason code with a delta CRL stream available where >>>> the CRL issuer's certificate has been signed by a rolled over CA key and >>>> whose revocation status is checked using pregenerated OCSP responses >>>> signed by a delegated responder that requires signed OCSP requests with >>>> noCheck asserted in the responder's certificate. >>>> >>>>> > >>>>>> >> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling >>>>>> >>>>> >> > wrote: >>>>>> >> >>>>>> >> On 04/06/13 22:51, Phillip Hallam-Baker wrote: >>>>>> >> >>>>>> >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley >>>>> >> >>>>>> >> >> wrote: >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> Not to mention, does anyone have any idea what an >>>>>> >> aACompromise could >>>>>> >> mean? >>>>>> >> >>>>>> >> >>>>>> >> Its an attribute authority. For attribute certs. >>>>>> >> >>>>>> >> Well actually that is only a supposition because none of the >>>>>> >> terms seem >>>>>> >> to be defined. >>>>>> >> >>>>>> >> >>>>>> >> X.509 (11/2008) defines the reason codes as follows... >>>>>> >> >>>>>> >> "8.5.2.2 Reason code extension >>>>>> >> ... >>>>>> >> The following reason code values indicate why a certificate was >>>>>> >>revoked: >>>>>> >> - 'unspecified' can be used to revoke certificates for reasons >>>>>> >> other than the specific codes; >>>>>> >> - 'keyCompromise' is used in revoking an end-entity >>>>>> certificate; >>>>>> >> it indicates that it is known or suspected that the subject's >>>>>> >> private key, or other aspects of the subject validated in the >>>>>> >> certificate, have been compromised; >>>>>> >> - 'cACompromise' is used in revoking a CA-certificate; it >>>>>> >> indicates that it is known or suspected that the subject's private >>>>>> >> key, or other aspects of the subject validated in the certificate, >>>>>> >> have been compromised; >>>>>> >> - 'affiliationChanged' indicates that the subject's name or >>>>>> other >>>>>> >> information in the certificate has been modified but there is no >>>>>> >> cause to suspect that the private key has been compromised; >>>>>> >> - 'superseded' indicates that the certificate has been >>>>>> superseded >>>>>> >> but there is no cause to suspect that the private key has been >>>>>> >> compromised; >>>>>> >> - 'cessationOfOperation' indicates that the certificate is no >>>>>> >> longer needed for the purpose for which it was issued but there is >>>>>> >> no cause to suspect that the private key has been compromised; >>>>>> >> - 'privilegeWithdrawn' indicates that a certificate (public-key >>>>>> >> or attribute certificate) was revoked because a privilege >>>>>> contained >>>>>> >> within that certificate has been withdrawn; >>>>>> >> - 'aACompromise' indicates that it is known or suspected that >>>>>> >> aspects of the AA validated in the attribute certificate, have >>>>>> been >>>>>> >> compromised." >>>>>> >> >>>>>> >> -- >>>>>> >> Rob Stradling >>>>>> >> Senior Research & Development Scientist >>>>>> >> COMODO - Creating Trust Online >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> -- >>>>>> >> Website: http://hallambaker.com/ >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> wpkops mailing list >>>>>> >> wpkops@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/wpkops >>>>>> >> >>>>> > >>>>> >-- >>>>> >Rob Stradling >>>>> >Senior Research & Development Scientist >>>>> >COMODO - Creating Trust Online >>>>> >Office Tel: +44.(0)1274.730505 >>>>> >Office Fax: +44.(0)1274.730909 >>>>> >www.comodo.com >>>>> > >>>>> >COMODO CA Limited, Registered in England No. 04058690 >>>>> >Registered Office: >>>>> > 3rd Floor, 26 Office Village, Exchange Quay, >>>>> > Trafford Road, Salford, Manchester M5 3EQ >>>>> > >>>>> >This e-mail and any files transmitted with it are confidential and >>>>> >intended solely for the use of the individual or entity to whom they are >>>>> >addressed. If you have received this email in error please notify the >>>>> >sender by replying to the e-mail containing this attachment. Replies to >>>>> >this email may be monitored by COMODO for operational or business >>>>> >reasons. Whilst every endeavour is taken to ensure that e-mails are free >>>>> >from viruses, no liability can be accepted and the recipient is >>>>> >requested to use their own virus checking software. >>>>> >_______________________________________________ >>>>> >wpkops mailing list >>>>> >wpkops@ietf.org >>>>> >https://www.ietf.org/mailman/listinfo/wpkops >>>> >>>> >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ > > > > -- > Website: http://hallambaker.com/ --B_3453283995_2737369 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Wednesday, June 5, 2013 1:26 PM
To: Carl Wallace <carl@redho= undsoftware.com>
Cc: Rob St= radling <rob.stradling@comodo.c= om>, "wpkops@ietf.org" <wpkops@ietf.org>, Adam Langley <agl@chromium.org>
Subject: Re: [wpkops] Some questions about revocation rea= sons

=
Probably better to just ask what CRLs they issue and for each= whether the frequency of issue for full and deltas, and whether they use di= stribution points 

I don't= think so.  Part of the point could be to identify and stamp out some o= f the unused corners.  Denying the existence of such things does not se= em helpful.  Documenting pervasive lack of support (which I thought was= part of this effort) may help.  


Indirect raises another issue. By definition a= n indirect CRL is not issued by the issuing CA. But that gets us into some c= omplex semantic games. What does it mean if the GeoTrust CRL is signed by Th= awte? Is that indirect or direct?

What I am getting at here is that maybe the issues are going to be a little= more complex than a binary choice. The term CA can get rather slippery. It = is an organizational concept and PKIX only deals in certificates and trust a= nchors. From a processing standpoint it seems 'obvious' to me that there 'sh= ould' be a CRL associated with every certificate signing cert. But the spec = was originally written from the assumption that a CA was identical to a trus= t anchor. So it gets rather murky, particularly as trust anchors were rolled= over.

Some points to ponder:

* Could DigiNotar have issued a CRL = that clients would have accepted as validating certs of other CAs? 

Or if not a CRL, could DigiN= otar have issued an OCSP responder certificate that was authorized to provid= e responses for any CA?

=
=
* There is no hierarchy of severity specified for re= vocation reasons, let alone a duty on CAs to update the reason code if they = revoke a cert to correct an error and subsequently find that the certificate= application was fraudulent. So relying on the partitioning of CRLs by reaso= n code as defined in the spec looks unsafe to me. 
<= br>



On Wed, Jun 5, 2013 at 12:53 PM, Carl Wallace <carl@r= edhoundsoftware.com> wrote:
<= div>
From: P= hillip Hallam-Baker <ha= llam@gmail.com>
Date: Wedne= sday, June 5, 2013 12:04 PM
To: Ca= rl Wallace <ca= rl@redhoundsoftware.com>
Cc: Rob Stradling <rob.stradling@comodo.com>, "wpkops@ietf.org" <wpkops@ietf.org>, Adam Langley <agl@chromium.org>
Subject: Re: [wpkops] Some questions about revocation reasons=

I am trying to unpack what you are saying here.

The best= way forward as far as I can see is to start of and ask CAs to describe what= types of revocation they support and describe their implementation. Then as= k what clients take notice of.

=

Having some means of naming the combinations= may be helpful.  X.509 sort of has a scheme.  Maybe something lik= e:

Full:  = CRL (all types), EPRL (ee only), CARL (CA only)
Indir= ect:  iCRL, iEPRL, iCAR= L
Delta:  dC= RL, dEPRL, dCARL
Indirect Delta: idCRL, idEPRL, idCARL

Distribution Po= int:  dpCRL, dpEPRL, dpCA= RL
Indirect Distribution Point:  idpCRL, idpEPRL, idpCARL 
Delta Distribution = Point:   ddpCRL, ddpEPRL, ddpCARL
Indirect Delta Di= stribution Point: iddpCRL, iddpEP= RL, iddpCARL

Any of these types could be further su= bdivided by reason code.  If you just accept there are two categories o= f reason code partitioning, some or all, then there are at least 48 types. &= nbsp;This is ignoring the attribute certificate stuff entirely and assumes I= have not missed a relevant knob.  




<= /div>


On Wed,= Jun 5, 2013 at 11:07 AM, Carl Wallace <carl@redhoundsoftware.com><= /span> wrote:

On 6/5/13 10:16 AM, "Rob Stradling" <rob.stradling@comodo.com> wrote:

>On 05/06/13 15:12, Phillip Hallam-Baker wrote:
>> Heh, I was hoping not to have to reference that one.
>>
>> The RFCs are meant to specify everything needed to interpret the s= pecs.
>
>Indeed.  It seems odd to me that RFC5280 only references X.509
= >Informatively rather than Normatively.

It'd be nice if you= r doc included a taxonomy of the various types of CRLs
that can exist based on the combinations of {dp name/no dp name}, {some
= reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and
= perhaps indicated what combinations are present in the web pki. I assume one need not grapple with DSA parameter inheritance while processing
indirect DP CRLs that use relative to issuer names and cover only EE certs<= br> for the keyCompromise reason code with a delta CRL stream available where the CRL issuer's certificate has been signed by a rolled over CA key and whose revocation status is checked using pregenerated OCSP responses
signed by a delegated responder that requires signed OCSP requests with
= noCheck asserted in the responder's certificate.

>
>> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <rob.stradling@comodo.com
>> <mailto:rob.stradling@comodo.com>> wrote:
>>
>>     On 04/06/13 22:51, Phillip Hallam-Baker wrote:
>>
>>         On Tue, Jun 4, 2013 at 5:39 PM, Adam L= angley <agl@chromium.or= g
>>         <mailto:agl@chromium.org>
>>         <mailto:agl@chromium.org <mailto:agl@chromium.org>>> wrote:
>>
>>     <snip>
>>
>>              Not to mention, do= es anyone have any idea what an
>>         aACompromise could
>>              mean?
>>
>>
>>         Its an attribute authority. For attrib= ute certs.
>>
>>         Well actually that is only a suppositi= on because none of the
>>         terms seem
>>         to be defined.
>>
>>
>>     X.509 (11/2008) defines the reason codes as follows.= ..
>>
>>     "8.5.2.2  Reason code extension
>>     ...
>>     The following reason code values indicate why a cert= ificate was
>>revoked:
>>        - 'unspecified' can be used to revoke c= ertificates for reasons
>>     other than the specific codes;
>>        - 'keyCompromise' is used in revoking a= n end-entity certificate;
>>     it indicates that it is known or suspected that the = subject's
>>     private key, or other aspects of the subject validat= ed in the
>>     certificate, have been compromised;
>>        - 'cACompromise' is used in revoking a = CA-certificate; it
>>     indicates that it is known or suspected that the sub= ject's private
>>     key, or other aspects of the subject validated in th= e certificate,
>>     have been compromised;
>>        - 'affiliationChanged' indicates that t= he subject's name or other
>>     information in the certificate has been modified but= there is no
>>     cause to suspect that the private key has been compr= omised;
>>        - 'superseded' indicates that the certi= ficate has been superseded
>>     but there is no cause to suspect that the private ke= y has been
>>     compromised;
>>        - 'cessationOfOperation' indicates that= the certificate is no
>>     longer needed for the purpose for which it was issue= d but there is
>>     no cause to suspect that the private key has been co= mpromised;
>>        - 'privilegeWithdrawn' indicates that a= certificate (public-key
>>     or attribute certificate) was revoked because a priv= ilege contained
>>     within that certificate has been withdrawn;
>>        - 'aACompromise' indicates that it is k= nown or suspected that
>>     aspects of the AA validated in the attribute certifi= cate, have been
>>     compromised."
>>
>>     --
>>     Rob Stradling
>>     Senior Research & Development Scientist
>>     COMODO - Creating Trust Online
>>
>>
>>
>>
>> --
>> Website: http://= hallambaker.com/
>>
>>
>> _______________________________________________
>> wpkops mailing list
>> wpkops@ietf.org
>> https://www.ietf.org/mailman/listinfo/wpkops
>>
>
>--
>Rob Stradling
>Senior Research & Development Scientist
>COMODO - Creating Trust Online
>Office Tel: +44.(0)1274.730505
>Office Fax: +44.(0)1274.730909
>www.comodo.com
>
>COMODO CA Limited, Registered in England No. 04058690
>Registered Office:
>   3rd Floor, 26 Office Village, Exchange Quay,
>   Trafford Road, Salford, Manchester M5 3EQ
>
>This e-mail and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they ar= e
>addressed.  If you have received this email in error please notify= the
>sender by replying to the e-mail containing this attachment. Replies to=
>this email may be monitored by COMODO for operational or business
>reasons. Whilst every endeavour is taken to ensure that e-mails are fre= e
>from viruses, no liability can be accepted and the recipient is
>requested to use their own virus checking software.
>_______________________________________________
>wpkops mailing list
>wpkops@ietf.org >= https://www.ietf.org/mailman/listinfo/wpkops





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



--
Website: http://ha= llambaker.com/
 --B_3453283995_2737369-- From eabalea@gmail.com Wed Jun 5 10:45:13 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C006221F9347 for ; Wed, 5 Jun 2013 10:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZKBLSKYYnnL for ; Wed, 5 Jun 2013 10:45:13 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6646B21F92F5 for ; Wed, 5 Jun 2013 10:45:04 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so1290150vbb.23 for ; Wed, 05 Jun 2013 10:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NHyJSLWDnkkVzTY6OkaOBctawqvNJ2Ow9soIaEyXDiA=; b=zeZsl2B2nZ3V8AdTVRnTOtwUPKE1FbArLSa3M6vrguo6jgp3oyPKvKAbBK15/ftUmR xQVIrCQZ4TGcbTDTGST5t+s4W+7z76CVAZezkjkJK2F7MFA10t2z+FYvJhKOytwfVEEb Jnm12L++6N5j6EjQhedKXL0PfBAVjgTbvGNO4GMFgqEfTAjNFZMbZl+j4rMaidAQ1UHd uav77SjZ3WBgb50Gt+DL2EMYvp+3CuRtkKqRqkiNTAPLz8JOAGQkj5V3Ui83oM2FqhHj zPcBKHm3T+E+gjtQG7G/HaL0KSXfLK+WpCW4p6v8JHXFajbd9DjAx0IRfQ1DnsvrZFaW D9XA== MIME-Version: 1.0 X-Received: by 10.52.16.201 with SMTP id i9mr17596946vdd.58.1370454303747; Wed, 05 Jun 2013 10:45:03 -0700 (PDT) Sender: eabalea@gmail.com Received: by 10.52.22.49 with HTTP; Wed, 5 Jun 2013 10:45:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Jun 2013 19:45:03 +0200 X-Google-Sender-Auth: TTFkwCPWNgE3U6tCkCqcPwXfWwM Message-ID: From: Erwann ABALEA To: Carl Wallace Content-Type: text/plain; charset=UTF-8 Cc: Adam Langley , Rob Stradling , Phillip Hallam-Baker , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:45:13 -0000 2013/6/5 Carl Wallace : > > From: Phillip Hallam-Baker > Date: Wednesday, June 5, 2013 1:26 PM > > To: Carl Wallace > Cc: Rob Stradling , "wpkops@ietf.org" > , Adam Langley > Subject: Re: [wpkops] Some questions about revocation reasons > > Probably better to just ask what CRLs they issue and for each whether the > frequency of issue for full and deltas, and whether they use distribution > points > > I don't think so. Part of the point could be to identify and stamp out some > of the unused corners. Denying the existence of such things does not seem > helpful. Documenting pervasive lack of support (which I thought was part of > this effort) may help. Do we only consider pure web PKI here, or can we also consider specific PKIs that are based on RFC5280 but choose to deviate from it? I'm thinking of CSCA PKIs and recent changes in CRL production, with implied indirect CRLs not indicated by an adhoc extension. Ugly, but it does exist in the wild. > Indirect raises another issue. By definition an indirect CRL is not issued > by the issuing CA. But that gets us into some complex semantic games. What > does it mean if the GeoTrust CRL is signed by Thawte? Is that indirect or > direct? > > What I am getting at here is that maybe the issues are going to be a little > more complex than a binary choice. The term CA can get rather slippery. It > is an organizational concept and PKIX only deals in certificates and trust > anchors. From a processing standpoint it seems 'obvious' to me that there > 'should' be a CRL associated with every certificate signing cert. But the > spec was originally written from the assumption that a CA was identical to a > trust anchor. So it gets rather murky, particularly as trust anchors were > rolled over. > > Some points to ponder: > > * Could DigiNotar have issued a CRL that clients would have accepted as > validating certs of other CAs? > > Or if not a CRL, could DigiNotar have issued an OCSP responder certificate > that was authorized to provide responses for any CA? Because an OCSP responder can also be accepted based on local client configuration, then local configuration does matter (that problem doesn't exist with CRL). On Windows, it has yet to be confirmed if a CA for which an effective id-kp-ocspSigning EKU is associated can be considered as a valid OCSP responder for all the CAs. There are 81 of them. From hallam@gmail.com Wed Jun 5 10:45:32 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC4F21F9BA6 for ; Wed, 5 Jun 2013 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ULvPLOD41Ca for ; Wed, 5 Jun 2013 10:45:31 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id DE13821F9BA4 for ; Wed, 5 Jun 2013 10:45:30 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id j13so1572014wgh.33 for ; Wed, 05 Jun 2013 10:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JX/jQLPYaQXLNr6JJviRIcxfTkqxKz7aGUOd4P8TYi4=; b=Qltyd5ecvsvqqhQ/3SDY3KviJ2CPP5SIewh6TDtQC4ni4zZaN38IqJkNMOZzhA1shU zNzAAanJUH9da3hjRMe1u/J2YAAhd/l/lJrM8OsckTaKrpIg1kE4xOiSbfLmeehRqm8N QpbYToA0vmUam9W+dTrduRvxNAfF4Ujs4hWzm/RcKJR3ODf/dThSM6IQ1JCoM9l7SOc2 7jEfIq2t62UX1xjh6td95qByZYngP1Eg6BUbEd8B1YaLvxWMa8tYGBfqQsOAvYpFMgIF K9X7d8pPYtzU2OAlL1Wuoe/7hieIxiPmReWIhwIrXOsESQDTLBIRqQHfTHIHldsknQMo KQFg== MIME-Version: 1.0 X-Received: by 10.180.185.225 with SMTP id ff1mr7666983wic.36.1370454330020; Wed, 05 Jun 2013 10:45:30 -0700 (PDT) Received: by 10.194.60.195 with HTTP; Wed, 5 Jun 2013 10:45:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Jun 2013 13:45:29 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: multipart/alternative; boundary=001a11c34ed2859c7c04de6bc32b Cc: Rob Stradling , Adam Langley , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:45:32 -0000 --001a11c34ed2859c7c04de6bc32b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 5, 2013 at 1:33 PM, Carl Wallace wrote: > > From: Phillip Hallam-Baker > Date: Wednesday, June 5, 2013 1:26 PM > > To: Carl Wallace > Cc: Rob Stradling , "wpkops@ietf.org" < > wpkops@ietf.org>, Adam Langley > Subject: Re: [wpkops] Some questions about revocation reasons > > Probably better to just ask what CRLs they issue and for each whether the > frequency of issue for full and deltas, and whether they use distribution > points > > > I don't think so. Part of the point could be to identify and stamp out > some of the unused corners. Denying the existence of such things does not > seem helpful. Documenting pervasive lack of support (which I thought was > part of this effort) may help. > I thought we were talking about the CAs... For the Clients I would expect the situation to be binary, either they support a feature or not. If they support direct delta CRLs and indirect but not indirect deltas we are in trouble. > Indirect raises another issue. By definition an indirect CRL is not issued > by the issuing CA. But that gets us into some complex semantic games. What > does it mean if the GeoTrust CRL is signed by Thawte? Is that indirect or > direct? > > What I am getting at here is that maybe the issues are going to be a > little more complex than a binary choice. The term CA can get rather > slippery. It is an organizational concept and PKIX only deals in > certificates and trust anchors. From a processing standpoint it seems > 'obvious' to me that there 'should' be a CRL associated with every > certificate signing cert. But the spec was originally written from the > assumption that a CA was identical to a trust anchor. So it gets rather > murky, particularly as trust anchors were rolled over. > > Some points to ponder: > > * Could DigiNotar have issued a CRL that clients would have accepted as > validating certs of other CAs? > > > Or if not a CRL, could DigiNotar have issued an OCSP responder certificate > that was authorized to provide responses for any CA? > Another good question. Easy to say what we think they should do in that one situation. But there are many corner cases that the clients have to support. Very easy to assume that we know the answers. > > -- Website: http://hallambaker.com/ --001a11c34ed2859c7c04de6bc32b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 5, 2013 at 1:33 PM, Carl Wallace <= carl@redhoun= dsoftware.com> wrote:

From: Phillip Hallam-Baker <hallam@gmail.com>=
Date: Wednesday, June 5, 2013 = 1:26 PM

To: Carl Wallace <carl@redhoundsoftwa= re.com>
Cc: Rob Stradlin= g <rob.str= adling@comodo.com>, "wpkops@ietf.org" <wpkops@ietf.org>, Adam Langley <agl@chromium.org>
Subject: Re: [wpkops] Some questio= ns about revocation reasons

Probably better to just ask what CRLs they issue and for e= ach whether the frequency of issue for full and deltas, and whether they us= e distribution points=A0

I don't think so. =A0Part of the point could be to identify and stamp o= ut some of the unused corners. =A0Denying the existence of such things does= not seem helpful. =A0Documenting pervasive lack of support (which I though= t was part of this effort) may help.=A0

I thought we were talking abou= t the CAs...

For the Clients I would e= xpect the situation to be binary, either they support a feature or not. If = they support direct delta CRLs =A0and indirect but not indirect deltas we a= re in trouble.

=A0
Indirect raises another issue. By definit= ion an indirect CRL is not issued by the issuing CA. But that gets us into = some complex semantic games. What does it mean if the GeoTrust CRL is signe= d by Thawte? Is that indirect or direct?

What I am getting at here is that maybe the issues are = going to be a little more complex than a binary choice. The term CA can get= rather slippery. It is an organizational concept and PKIX only deals in ce= rtificates and trust anchors. From a processing standpoint it seems 'ob= vious' to me that there 'should' be a CRL associated with every= certificate signing cert. But the spec was originally written from the ass= umption that a CA was identical to a trust anchor. So it gets rather murky,= particularly as trust anchors were rolled over.

Some points to ponder:

* Could= DigiNotar have issued a CRL that clients would have accepted as validating= certs of other CAs?=A0

Or if not a CRL, could DigiNotar have issued an OCSP responder certifi= cate that was authorized to provide responses for any CA?

Another good question.

Easy to say what we think they should do in that one s= ituation. But there are many corner cases that the clients have to support.=

Very easy to assume that we know the = answers.

=A0

--
Website: http://hallambaker.com/
--001a11c34ed2859c7c04de6bc32b-- From carl@redhoundsoftware.com Wed Jun 5 10:51:57 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB9821F9B41 for ; Wed, 5 Jun 2013 10:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGocBi5oYSVU for ; Wed, 5 Jun 2013 10:51:56 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7580321F9B32 for ; Wed, 5 Jun 2013 10:51:56 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id b12so487393yha.2 for ; Wed, 05 Jun 2013 10:51:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=HIbEjJ0cWYaFhnvOkRhbMqHblpao6xeT7o+H2EHZBTg=; b=efKQhzBUY42/PfUKodq44AyTJFZFzmzODBbK/s1QGJwTsf2ED5+xiiogvXVs8W1DtT d8DJXZ7D229qWtWAlvDWisB26mQgMHC0XCfBpJdPZozlGHh4GTaBKE8V38ss7Gk+3uZ4 BMfCjhni3Xr3arlEtcrIqZWiI4fywizRJRjjGsfBfjNtAA3SYexHyIR7jOQV+f+YoRKG mhb8AQdEcRJb3+HFDfkDFUXiKR4bIzTqYdjpWK3c3AWI7bZ/wkPIltJksWkDTbY6eBbC oe15rBjwTY6iIX0DQAlOHYpreXxmjlBSFqCQw7xehgjlzH2xjhSmI3reSwJES9QsEO5d fEfA== X-Received: by 10.236.84.6 with SMTP id r6mr25582426yhe.9.1370454715468; Wed, 05 Jun 2013 10:51:55 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-116-61.washdc.fios.verizon.net. [173.79.116.61]) by mx.google.com with ESMTPSA id z65sm108661852yhc.9.2013.06.05.10.51.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Jun 2013 10:51:54 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Wed, 05 Jun 2013 13:51:49 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [wpkops] Some questions about revocation reasons In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3453285115_2749302" X-Gm-Message-State: ALoCoQk4Fg4MXtUdDsLyKT3po78BThAOw+jFQIdFEc6xjQwFfLBDiEcsAuGQkTq1OLxVT2Cp8l9/ Cc: Rob Stradling , Adam Langley , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:51:57 -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_3453285115_2749302 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Phillip Hallam-Baker Date: Wednesday, June 5, 2013 1:45 PM >> > I thought we were talking about the CAs... > > For the Clients I would expect the situation to be binary, either they support > a feature or not. If they support direct delta CRLs and indirect but not > indirect deltas we are in trouble. You can limit the scope to CAs and identify the same subset of possibilities which could be used to prune what (new) implementations ought to be required to support. Maybe a taxonomy is not required and simply asking on a per feature basis is good enough. The combinations can get pretty nasty though. > >> Another good question. > > Easy to say what we think they should do in that one situation. But there are > many corner cases that the clients have to support. > > Very easy to assume that we know the answers. I think we can safely say that nothing in a mass market trust anchor store ought to be configured by default such that subordinate OCSP responders can issue responses for any CA. --B_3453285115_2749302 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Wednesday, June 5, 2013 1:45 PM

<snip= >

I thought we were talking about the CAs...

=
For the Clients I would expect the situation to be binary, eit= her they support a feature or not. If they support direct delta CRLs  a= nd indirect but not indirect deltas we are in trouble.

You can limit the scope to CAs and= identify the same subset of possibilities which could be used to prune what= (new) implementations ought to be required to support.  Maybe a taxono= my is not required and simply asking on a per feature basis is good enough. =  The combinations can get pretty nasty though.  

=  <snip>
Another good ques= tion.

Easy to = say what we think they should do in that one situation. But there are many c= orner cases that the clients have to support.

<= div style=3D"">Very easy to assume that we know the answers.
=

I think we can safely say that= nothing in a mass market trust anchor store ought to be configured by defau= lt such that subordinate OCSP responders can issue responses for any CA. &nb= sp;
--B_3453285115_2749302-- From rob.stradling@comodo.com Wed Jun 5 11:13:37 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D817F21F9B4A for ; Wed, 5 Jun 2013 11:13:37 -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, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFEj+bJS95-y for ; Wed, 5 Jun 2013 11:13:32 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id D808521F9B5E for ; Wed, 5 Jun 2013 11:12:34 -0700 (PDT) Received: (qmail 31381 invoked from network); 5 Jun 2013 18:12:03 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 Jun 2013 18:12:03 -0000 Received: (qmail 16633 invoked by uid 1000); 5 Jun 2013 18:12:03 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 05 Jun 2013 19:12:03 +0100 Message-ID: <51AF7F72.7000609@comodo.com> Date: Wed, 05 Jun 2013 19:12:02 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Erwann ABALEA References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , "wpkops@ietf.org" , Carl Wallace , Adam Langley Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:13:38 -0000 On 05/06/13 18:45, Erwann ABALEA wrote: >> Or if not a CRL, could DigiNotar have issued an OCSP responder certificate >> that was authorized to provide responses for any CA? > > Because an OCSP responder can also be accepted based on local client > configuration, then local configuration does matter (that problem > doesn't exist with CRL). > On Windows, it has yet to be confirmed if a CA for which an effective > id-kp-ocspSigning EKU is associated can be considered as a valid OCSP > responder for all the CAs. There are 81 of them. Until November 2008, the "DigiNotar Root CA" was enabled for the OCSP Signing trust purpose in the Microsoft Root Certificate Program. After then, it wasn't. (I have a record of all authroot.stl files since January 2007). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From hallam@gmail.com Thu Jun 6 09:22:35 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD94321F88FB for ; Thu, 6 Jun 2013 09:22:35 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws2O3Mr2VuHg for ; Thu, 6 Jun 2013 09:22:35 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 121EE21F999E for ; Thu, 6 Jun 2013 09:22:30 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so394006wiw.5 for ; Thu, 06 Jun 2013 09:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ps9g2Wp41LqlDRQAodR6nga+1qagMhRjJKakwNKd9M8=; b=n9WJqMHEFHV1oJjHabZ3MsAZVuQ2CLF5AHinKmsyCcWNnIWm/WwwIvFDjhfaAwEugc kgx+0Pe9DKnj5xf7U9VgJWSL4VbuULCMtq2E/QqR/1sm2t2sJzBvxiksVzBjm40t98mC ZmxkkUkSjX5taX9kxXODwkwACPeLiPZezCYVr2/GGNO1fyDHl43W9DGpmag3O+jpixGM E79DXwYVBVKgsxcUaIZq3edhN1QxNUVQVl8zkSKzO4FGTJr/RQ1QHxkNlYTpBriN2xIx w2eBy9P5hDhaL/KwSlDimT+yXIIS5sONV9wNwe0GSciXBk++7lJCVyrBW28D8S/GFiIG qTQQ== MIME-Version: 1.0 X-Received: by 10.194.104.105 with SMTP id gd9mr32990046wjb.1.1370535722213; Thu, 06 Jun 2013 09:22:02 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Thu, 6 Jun 2013 09:22:02 -0700 (PDT) In-Reply-To: <51AF7F72.7000609@comodo.com> References: <51AF7F72.7000609@comodo.com> Date: Thu, 6 Jun 2013 12:22:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Rob Stradling Content-Type: multipart/alternative; boundary=089e0102fddcdfe95304de7eb661 Cc: Adam Langley , Erwann ABALEA , Carl Wallace , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:22:36 -0000 --089e0102fddcdfe95304de7eb661 Content-Type: text/plain; charset=ISO-8859-1 This is getting to be a little more complicated than I thought. Rather than plough on into yet more weeds, perhaps it might help to put out a very early albeit very incomplete draft tomorrow so people can see what the weeds look like? OK more fun out in revocation land... Indirect CRLs. Should these be considered a substitute for the direct CRL or could they be merely an adjunct? Reading through RFC 5280 it seems like indirect CRLs are just thrown in there without much thought as to the implications of allowing someone else to sign the CRL. The problem is that a CRL is both an explicit assertion that a set of certs is invalid and an implicit assertion that all unlisted certs are valid. What is an RP to assume from an indirect CRL? RFC 5280 seems to suggest that an indirect CRL is just like a direct CRL but it really doesn't seem to anticipate the issue. Which is going to make marking them as indirect utterly pointless. To the extent that the indirect flag has a meaning it becomes an evil bit. Working out if a CRL is direct is something a client should CHECK and arrive at as a conclusion. If it matters it should be configured into the trust anchor metadata. The only reason for telling the RP that the CRL is indirect that I can see would be to warn them that it is incomplete. [Now Rob is going to tell me X.509... But I don't want to read that because I am pretty certain the majority of client side implementers did not.] --089e0102fddcdfe95304de7eb661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is getting to be a little more complicated= than I thought. Rather than plough on into yet more weeds, perhaps it migh= t help to put out a very early albeit very incomplete draft tomorrow so peo= ple can see what the weeds look like?


OK more fun out in revocation land...
Indirect CRLs. Should these be considered a substitute fo= r the direct CRL or could they be merely an adjunct?


Reading through RFC 5280 it seems lik= e indirect CRLs are just thrown in there without much thought as to the imp= lications of allowing someone else to sign the CRL. The problem is that a C= RL is both an explicit assertion that a set of certs is invalid and an impl= icit assertion that all unlisted certs are valid.

What is an RP to assume from an indirect CR= L?


RFC 5280 seems= to suggest that an indirect CRL is just like a direct CRL but it really do= esn't seem to anticipate the issue. Which is going to make marking them= as indirect utterly pointless. To the extent that the indirect flag has a = meaning it becomes an evil bit. Working out if a CRL is direct is something= a client should CHECK and arrive at as a conclusion. If it matters it shou= ld be configured into the trust anchor metadata.

The only reason for telling the RP that the= CRL is indirect that I can see would be to warn them that it is incomplete= .


[Now Rob is goi= ng to tell me X.509... But I don't want to read that because I am prett= y certain the majority of client side implementers did not.]
--089e0102fddcdfe95304de7eb661-- From rob.stradling@comodo.com Thu Jun 6 12:03:24 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB18A21F96EA for ; Thu, 6 Jun 2013 12:03: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnk0IIrs+dBr for ; Thu, 6 Jun 2013 12:03:19 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3684721E808E for ; Thu, 6 Jun 2013 12:03:18 -0700 (PDT) Received: (qmail 5587 invoked from network); 6 Jun 2013 19:03:15 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Jun 2013 19:03:15 -0000 Received: (qmail 29630 invoked by uid 1000); 6 Jun 2013 19:03:15 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 06 Jun 2013 20:03:15 +0100 Message-ID: <51B0DCF2.2090606@comodo.com> Date: Thu, 06 Jun 2013 20:03:14 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <51AF7F72.7000609@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Langley , Erwann ABALEA , Carl Wallace , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:03:25 -0000 On 06/06/13 17:22, Phillip Hallam-Baker wrote: > [Now Rob is going to tell me X.509... But I don't want to read that > because I am pretty certain the majority of client side implementers did > not.] I'll keep quiet then. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From carl@redhoundsoftware.com Thu Jun 6 12:20:19 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568D621E80C3 for ; Thu, 6 Jun 2013 12:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9p1tJdbjCsQ for ; Thu, 6 Jun 2013 12:20:18 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id A6ACF11E80ED for ; Thu, 6 Jun 2013 12:20:15 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w15so34529vbf.35 for ; Thu, 06 Jun 2013 12:20:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=eS6leZ72vIAI8pLkLAEZ9fRMtOXUh5pSM9MD6hZZo8M=; b=TYIopLERZzvIKWDnWn97+msss0FN2LjSDyh2cglvVvugtwBwKr7tEFHsgZs2aNgbfF 7Yyrx5KGtSaLQ20yQeMCZ+tVBPJH49IuCOXETnXeAaGr14pF5I4GAxk2rDKw1mO1whH7 K/yCq4ywyavTWFWBoRPZ9P0eiLOtNw0vTPGS8dKlo01cHZzs8MokF8cNPp9debkLQbuD PXQ8IlOzjPtGCEJl/q+RcUO/0FAOvPoUbG14Ylm1p8FTQn283uGdeN/jkGvIN+KAz/DD qYdAUlTDpcuE8pic7Gvn2Vc9F2yWTLVB3S5Jbg+uf9dfx1zhGYmbsG5UYEMnLJiWZ6UC 011w== X-Received: by 10.52.157.138 with SMTP id wm10mr19233627vdb.57.1370546414759; Thu, 06 Jun 2013 12:20:14 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-116-61.washdc.fios.verizon.net. [173.79.116.61]) by mx.google.com with ESMTPSA id aq10sm49551346ved.2.2013.06.06.12.20.11 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 06 Jun 2013 12:20:14 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Thu, 06 Jun 2013 15:20:04 -0400 From: Carl Wallace To: Phillip Hallam-Baker , Rob Stradling Message-ID: Thread-Topic: [wpkops] Some questions about revocation reasons In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3453376813_2485959" X-Gm-Message-State: ALoCoQmVuIszFS0gtRw648CBnHz/LA+/8Gtf3x7zXbrj6zRwMrey8p3Ji0ku0Qi8uXet7Syl/f68 Cc: Erwann ABALEA , Adam Langley , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:20:19 -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_3453376813_2485959 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Phillip Hallam-Baker Date: Thursday, June 6, 2013 12:22 PM To: Rob Stradling Cc: Erwann ABALEA , Carl Wallace , Adam Langley , "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons > > What is an RP to assume from an indirect CRL? > Is this relevant to the tasks this working group is currently working on? I thought the task being discussed here was the (possibly) easier task of identifying what is actually used in the web PKI w.r.t. revocation status determination. I suggested a taxonomy be used to identify what is actually used to give some structure to the discussion and to potentially serve as a precursor to deprecating options no one uses so client code could lose some needless complexity. --B_3453376813_2485959 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thursday, June 6, 2013 12:22 PM
To: Rob Stradling <rob.stradl= ing@comodo.com>
Cc: Erwann = ABALEA <erwann@abalea.com>, Car= l Wallace <carl@redhoundsoftwa= re.com>, Adam Langley <agl@chrom= ium.org>, "wpkops@ietf.org" <= wpkops@ietf.org>
Subject: Re: [wpkops] Some questions about revocation= reasons

<snip= >
What is an RP to assume from an indirect CRL?
<= div style=3D"">

Is= this relevant to the tasks this working group is currently working on? &nbs= p;I thought the task being discussed here was the (possibly) easier task of = identifying what is actually used in the web PKI w.r.t. revocation status de= termination.  I suggested a taxonomy be used to identify what is actual= ly used to give some structure to the discussion and to potentially serve as= a precursor to deprecating options no one uses so client code could lose so= me needless complexity.

<snip>
--B_3453376813_2485959-- From pgut001@cs.auckland.ac.nz Thu Jun 6 19:33:32 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFD321F9133 for ; Thu, 6 Jun 2013 19:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4qQ9J9JR3TJ for ; Thu, 6 Jun 2013 19:33:22 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36121F9121 for ; Thu, 6 Jun 2013 19:33:22 -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=1370572402; x=1402108402; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=W5u0jF8va5SVTjHDloePkQZpion+t2ISrml1v+yA65k=; b=g1UDbZXOOvDF0tcGcQZkiiWSO3bm5XUD1ejzGsvkmr5YY53EFHkI3YaT bqWWZLccXTwYdT33JUl3iE79+L05OEqxK4Zn/dy7bHVpKqZ1B1LGp/VkG V5JncgrNvc6JxycLxsfruIzzm4mGYtkSGcJ9TCoVUHGwS2i4/cAhy/EjT 4=; X-IronPort-AV: E=Sophos;i="4.87,818,1363086000"; d="scan'208";a="193027144" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 07 Jun 2013 14:33:21 +1200 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.204]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Fri, 7 Jun 2013 14:33:20 +1200 From: Peter Gutmann To: "wpkops@ietf.org" Thread-Topic: [wpkops] Some questions about revocation reasons Thread-Index: Ac5jJ1/KBTw/qiBhT8KKU7GNtX4ZbQ== Date: Fri, 7 Jun 2013 02:33:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D5DD81@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 02:33:32 -0000 Phillip Hallam-Baker writes:=0A= =0A= >This is getting to be a little more complicated than I thought. Rather tha= n=0A= >plough on into yet more weeds, perhaps it might help to put out a very ear= ly=0A= >albeit very incomplete draft tomorrow so people can see what the weeds loo= k=0A= >like?=0A= =0A= You'd have to be sure to cover all the types, CRLs, indirect CRLs, delta CR= Ls,=0A= authority CRLs, chipotle CRLs, streaky-bacon CRLs, thousand-island CRLs,=0A= chunky CRLs, extra-chunky CRLs, barbeque CRLs, salt-and-vinegar CRLs,=0A= balsamic-vinaigrette CRLs, organic-sea-salt CRLs, and barium-enema CRLs (th= e=0A= latter for CAs like Diginotar).=0A= =0A= >Now Rob is going to tell me X.509... But I don't want to read that because= I=0A= >am pretty certain the majority of client side implementers did not.=0A= =0A= Given some of the certificate implementations I've had to interop with, I'm= =0A= not sure how many client side implementers have read 5280.=0A= =0A= Peter.=0A= From hallam@gmail.com Thu Jun 6 20:05:53 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E9311E80BA for ; Thu, 6 Jun 2013 20:05:53 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7NGPWUeie6A for ; Thu, 6 Jun 2013 20:05:52 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DDA5F21E804B for ; Thu, 6 Jun 2013 20:05:50 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so2683522wes.34 for ; Thu, 06 Jun 2013 20:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uapeCN7wWky16qjM0TduupLTGWf9eZs36UM1QVaWPkE=; b=MQ4uSS/LMJXuV6JH7m2bX+3tFKFKzAVckQnJVp58cOr7OlfFEfI37cdVBgD41Xy1Q+ UgNu2dWxJ+65ej55q417Jl+lVGdbPyOz+R7izb/eURUKjopBGllQlMfi0DqS8hu6F6rm C+pA1CFLVTuyBWGMIUlYbVt7f49mIkgX1zvrpq3tYmwLiJqSAiqX/CXScRiKHJoXduIX Go0/+IdpBogCLIHrRTVdWVg4Yd5riLEJQgfV6PHLtSl4s3p6d5UCDJNv0wXKfKNT0D4n HR0uW5Xawl2sNG2uw3ahwqNRRo4Q7Z/uoFi3+NES4mV44wLJqc0SA9Q82fqWXSDKaPKU KvHg== MIME-Version: 1.0 X-Received: by 10.180.160.170 with SMTP id xl10mr523960wib.56.1370574349868; Thu, 06 Jun 2013 20:05:49 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Thu, 6 Jun 2013 20:05:49 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D5DD81@uxcn10-tdc02.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C7343D5DD81@uxcn10-tdc02.UoA.auckland.ac.nz> Date: Thu, 6 Jun 2013 23:05:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=047d7b624e8c43247904de87b50b Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Some questions about revocation reasons X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 03:05:54 -0000 --047d7b624e8c43247904de87b50b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 6, 2013 at 10:33 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > > >This is getting to be a little more complicated than I thought. Rather > than > >plough on into yet more weeds, perhaps it might help to put out a very > early > >albeit very incomplete draft tomorrow so people can see what the weeds > look > >like? > > You'd have to be sure to cover all the types, CRLs, indirect CRLs, delta > CRLs, > authority CRLs, chipotle CRLs, streaky-bacon CRLs, thousand-island CRLs, > chunky CRLs, extra-chunky CRLs, barbeque CRLs, salt-and-vinegar CRLs, > balsamic-vinaigrette CRLs, organic-sea-salt CRLs, and barium-enema CRLs > (the > latter for CAs like Diginotar). > > >Now Rob is going to tell me X.509... But I don't want to read that > because I > >am pretty certain the majority of client side implementers did not. > > Given some of the certificate implementations I've had to interop with, I'm > not sure how many client side implementers have read 5280. Well I know that the number who have read 5280 is greater than zero which means that it is more than have read X.509v3. -- Website: http://hallambaker.com/ --047d7b624e8c43247904de87b50b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 6, 2013 at 10:33 PM, Peter Gutmann &l= t;pgut001@cs= .auckland.ac.nz> wrote:
Phillip Hallam-Baker <<= a href=3D"mailto:hallam@gmail.com">hallam@gmail.com> writes:

>This is getting to be a little more complicated than I thought. Rather = than
>plough on into yet more weeds, perhaps it might help to put out a very = early
>albeit very incomplete draft tomorrow so people can see what the weeds = look
>like?

You'd have to be sure to cover all the types, CRLs, indirect CRLs= , delta CRLs,
authority CRLs, chipotle CRLs, streaky-bacon CRLs, thousand-island CRLs, chunky CRLs, extra-chunky CRLs, barbeque CRLs, salt-and-vinegar CRLs,
balsamic-vinaigrette CRLs, organic-sea-salt CRLs, and barium-enema CRLs (th= e
latter for CAs like Diginotar).

>Now Rob is going to tell me X.509... But I don't want to read that = because I
>am pretty certain the majority of client side implementers did not.

Given some of the certificate implementations I've had to interop= with, I'm
not sure how many client side implementers have read 5280.

Well I know that the number who have read 5280 is gre= ater than zero which means that it is more than have read X.509v3.



=A0
--
Website: http://hallambaker.co= m/
--047d7b624e8c43247904de87b50b-- From hallam@gmail.com Fri Jun 7 13:20:53 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7699521F99C4 for ; Fri, 7 Jun 2013 13:20:53 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv1I0rlF1CX9 for ; Fri, 7 Jun 2013 13:20:52 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6A421F99C2 for ; Fri, 7 Jun 2013 13:20:51 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so1687513wib.6 for ; Fri, 07 Jun 2013 13:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=esWSRwcEvgGzxktJufB25Q2pIBgX2wfd9FQyFHNXPlo=; b=Bq/ctquMOLF5nDK4fyaRLUZhQuEe3B1zy0bvTE69f0AWlt+aLDifO8cXyGl85JOaP3 X75q+lU7WmW7j6CpwuJAvK4xDvm69c51Gda/lZtA1imh9dIsrlICK7UBIohtWdmEcZrl 8cJdpVZxAar48YxgkX7EUBE4czZBuMTerutdMqtNTH+n515prO9wshjz+LcrJwmQDtDC SP5HnE6Vrb1tODsUCov/SIOlX0RXMmZL9XTxWDo62jS4C7g334ipQaOLfKFVeyeGu2Dw ESh3iGAbLPNF+FBIACOdoQvTwpsBKvow54v+3AUDko4l7fG48zjGrpCtqKl4IqDDqe7A 9Cqw== MIME-Version: 1.0 X-Received: by 10.194.157.2 with SMTP id wi2mr133470wjb.77.1370636450351; Fri, 07 Jun 2013 13:20:50 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Fri, 7 Jun 2013 13:20:50 -0700 (PDT) Date: Fri, 7 Jun 2013 16:20:50 -0400 Message-ID: From: Phillip Hallam-Baker To: wpkops@ietf.org Content-Type: multipart/alternative; boundary=089e0122f540bd51bf04de962acd Subject: [wpkops] Initial draft of the revocation document. X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 20:20:53 -0000 --089e0122f540bd51bf04de962acd Content-Type: text/plain; charset=ISO-8859-1 http://www.ietf.org/id/draft-hallambaker-pkixstatus-00.txt This is a very very drafty draft. At this stage I am still trying to describe the ground we want to measure. But I did say I would post what I had today. Need to decide on terminology across all the drafts. Are we talking about clients or Relying parties etc. Needs to be the same. Probably should be RPs but have not changed mine yet. Also have to go back to the minutes to see if I left any dimensions of the revocation world out. -- Website: http://hallambaker.com/ --089e0122f540bd51bf04de962acd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
= =A0
This is a very very drafty draft. At this stage I am still tr= ying to describe the ground we want to measure. But I did say I would post = what I had today.
=A0
=A0
Need to decide on terminology across all t= he drafts. Are we talking about clients or Relying parties etc. Needs to be= the same. Probably should be RPs but have not changed mine yet.
=A0
Also have to go back to the minutes to see if I left any dime= nsions of the revocation world out.

--
Website: http://hallambaker.com/
--089e0122f540bd51bf04de962acd-- From rob.stradling@comodo.com Fri Jun 7 13:37:37 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C44221F926E for ; Fri, 7 Jun 2013 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtY2ZGy3zwiV for ; Fri, 7 Jun 2013 13:37:33 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEF421F925A for ; Fri, 7 Jun 2013 13:37:32 -0700 (PDT) Received: (qmail 21716 invoked from network); 7 Jun 2013 20:37:29 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Jun 2013 20:37:29 -0000 Received: (qmail 16202 invoked by uid 1000); 7 Jun 2013 20:37:29 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 07 Jun 2013 21:37:29 +0100 Message-ID: <51B24489.6020301@comodo.com> Date: Fri, 07 Jun 2013 21:37:29 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: wpkops@ietf.org Subject: Re: [wpkops] Initial draft of the revocation document. X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 20:37:37 -0000 On 07/06/13 21:20, Phillip Hallam-Baker wrote: > http://www.ietf.org/id/draft-hallambaker-pkixstatus-00.txt > This is a very very drafty draft. At this stage I am still trying to > describe the ground we want to measure. But I did say I would post what > I had today. > Need to decide on terminology across all the drafts. Are we talking > about clients or Relying parties etc. Needs to be the same. Probably > should be RPs but have not changed mine yet. Clients and Relying Parties are terms used outside of the Web PKI. Wouldn't it be better to pick a term that only refers to all Clients of the Web PKI? http://en.wikipedia.org/wiki/Web_browser "A web browser (commonly referred to as a browser) is a software application for retrieving, presenting and traversing information resources on the World Wide Web." > Also have to go back to the minutes to see if I left any dimensions of > the revocation world out. > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From hallam@gmail.com Fri Jun 7 13:39:11 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D245221F9298 for ; Fri, 7 Jun 2013 13:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpg2EbaS12TU for ; Fri, 7 Jun 2013 13:39:11 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A9C1221F926E for ; Fri, 7 Jun 2013 13:39:10 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so2596286wes.32 for ; Fri, 07 Jun 2013 13:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PF8cDQ/Rekj+QJVTSUQNQTFbyQIndQTPUE9UXR6ja/I=; b=ajGIFXZo9YNPnZPXH4OgAEEs5IJgbWdBS7Nhihi0PuOGNJB6tyOiupLHCqPefOvTvu 6pO6LT5bmSjyRGdT7tJmOC5evRCpG/lEDQdk6EUB0ZmNBZAJFU41Ma/p54Fb0vXuAvei JNg1PGX/9UNP9E16k5zAJ5HnWF3EIW/qB9VUAiKVhAF6xRLJohu+rcLdbNLnArnLULFV nTQXCXgdifV0uobjK5PUL4WSj1bKSTnjyZiwOkjICObsyj43MJs66eNKeZZtKMip9J7Y /Ob61voYxxZWJa/8geMl2TUvyV9IDXInqLCPTugPKCRu15CrbfrGQoOEBe07pBZ6CAC6 B7pQ== MIME-Version: 1.0 X-Received: by 10.180.206.205 with SMTP id lq13mr2461907wic.56.1370637549834; Fri, 07 Jun 2013 13:39:09 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Fri, 7 Jun 2013 13:39:09 -0700 (PDT) In-Reply-To: <51B24489.6020301@comodo.com> References: <51B24489.6020301@comodo.com> Date: Fri, 7 Jun 2013 16:39:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Rob Stradling Content-Type: multipart/alternative; boundary=001a11c382d4461eec04de966c8b Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Initial draft of the revocation document. X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 20:39:11 -0000 --001a11c382d4461eec04de966c8b Content-Type: text/plain; charset=ISO-8859-1 That is a good idea. I dislike using RP as it comes with baggage. There is an advantage to having some distance when considering operations. Web Browser would address that. On Fri, Jun 7, 2013 at 4:37 PM, Rob Stradling wrote: > On 07/06/13 21:20, Phillip Hallam-Baker wrote: > >> http://www.ietf.org/id/draft-**hallambaker-pkixstatus-00.txt >> This is a very very drafty draft. At this stage I am still trying to >> describe the ground we want to measure. But I did say I would post what >> I had today. >> Need to decide on terminology across all the drafts. Are we talking >> about clients or Relying parties etc. Needs to be the same. Probably >> should be RPs but have not changed mine yet. >> > > Clients and Relying Parties are terms used outside of the Web PKI. > > Wouldn't it be better to pick a term that only refers to all Clients of > the Web PKI? > > http://en.wikipedia.org/wiki/**Web_browser > "A web browser (commonly referred to as a browser) is a software > application for retrieving, presenting and traversing information resources > on the World Wide Web." > > Also have to go back to the minutes to see if I left any dimensions of >> the revocation world out. >> >> -- >> Website: http://hallambaker.com/ >> >> >> ______________________________**_________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/**listinfo/wpkops >> >> > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > -- Website: http://hallambaker.com/ --001a11c382d4461eec04de966c8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That is a good idea.=A0

I dislike= using RP as it comes with baggage. There is an advantage to having some di= stance when considering operations.

We= b Browser would address that.=A0


On Fri,= Jun 7, 2013 at 4:37 PM, Rob Stradling <rob.stradling@comodo.com> wrote:
On 07/06/13 21:20, Phillip= Hallam-Baker wrote:
http://www.ietf.org/id/draft-hallambaker-pkixstatus-00= .txt
This is a very very drafty draft. At this stage I am still trying to
describe the ground we want to measure. But I did say I would post what
I had today.
Need to decide on terminology across all the drafts. Are we talking
about clients or Relying parties etc. Needs to be the same. Probably
should be RPs but have not changed mine yet.

Clients and Relying Parties are terms used outside of the Web PKI.

Wouldn't it be better to pick a term that only refers to all Clients of= the Web PKI?

http= ://en.wikipedia.org/wiki/Web_browser
"A web browser (commonly referred to as a browser) is a software appli= cation for retrieving, presenting and traversing information resources on t= he World Wide Web."

Also have to go back to the minutes to see if I left any dimensions of
the revocation world out.

--
Website: http://halla= mbaker.com/


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


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online



-- Website: http://hallambaker.com/<= br>
--001a11c382d4461eec04de966c8b-- From dkg@fifthhorseman.net Sat Jun 8 10:09:50 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA9B21F9371 for ; Sat, 8 Jun 2013 10:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb9uIKypIAke for ; Sat, 8 Jun 2013 10:09:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5277921F92E3 for ; Sat, 8 Jun 2013 10:09:44 -0700 (PDT) Received: from [192.168.13.172] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id B8483F97F; Sat, 8 Jun 2013 13:09:39 -0400 (EDT) Message-ID: <51B36550.6060106@fifthhorseman.net> Date: Sat, 08 Jun 2013 13:09:36 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <51B24489.6020301@comodo.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2MPGKMSTSOINCSXWNULAG" Cc: Rob Stradling , "wpkops@ietf.org" Subject: Re: [wpkops] Initial draft of the revocation document. X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 17:09:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MPGKMSTSOINCSXWNULAG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/07/2013 04:39 PM, Phillip Hallam-Baker wrote: > I dislike using RP as it comes with baggage. There is an advantage to > having some distance when considering operations. >=20 > Web Browser would address that. Are we just talking about web browsers in this WG, though? there are more clients that use the web other than web browsers, and those clients seem like they should be covered by the guidance that this working group can offer. For example, software update retrieval mechanisms should probably be considering certificate revocation status when they establish https connections to their origin host. Do they? --dkg ------enig2MPGKMSTSOINCSXWNULAG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRs2VQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc1MkP/2+Da2SyOUlWakhzJvqyTyuG izQ5adFz1s5tWDT8jFtZBgYIiAR2Fysh00PkkIQy9dgC+RBjhn/h65IC55hu9oi6 NeYFl0YjLArJJj89roY69AD3hKr6CeTQobevwFhW5cZCKEMv9c407d7F0y8oqa7l W4lkoe9jPw8LpIYW6xK/gRvHhqzCxkMPqWwwwDl9X8Gocm7UOpP5wn2vas1yWUWJ FQ/0Fp/c9dYdyNVQyDZ+seHtxqNeQGO9jivDRfLtm63ovQHCJRf0RjQ6Q4P0KoZg OIE2Sb70nLdyiIstoFkT/9Qe5tAeuvgwi7MqRQYlHQgmp75uPnXGg2CYGKtOQ9xG cQSTAta6NJZzacn2ommwvR9JD3ADd1J2MySfZ4txvfpKnjoTfPSDg8ZTMnR/wHvP jzzjqgyPSGk4N8jgxSuf1PMHYHbdMh1kG1Ztj6K9m8aVCjrwvbDj7cTO9qh2WEc1 wONS2wy7KKrMuCvt27+f9abyG1cOhEqY9o5svm0j7uYD1tu2RVtP/hLsc99RoO8t r6YC+iFGW3HCH4uRzQkOCXSKfknPQgeN+LxLVv8JH2yiaVuSL+KduAwHMc4sBkTV OlXvStDNYtE84jMp7rM7m5nxSuR62zRwnCHzy92tsDaQKDv2Yo7CUr44JoCp5gHb 4443fYNfR0qlld+5mpzg =vs1E -----END PGP SIGNATURE----- ------enig2MPGKMSTSOINCSXWNULAG-- From paul.hoffman@vpnc.org Sat Jun 8 10:39:31 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6FA21F921F for ; Sat, 8 Jun 2013 10:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yedPS2mlzPM2 for ; Sat, 8 Jun 2013 10:39:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7401121F91B7 for ; Sat, 8 Jun 2013 10:39:30 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r58HdRpS045074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Jun 2013 10:39:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B36550.6060106@fifthhorseman.net> Date: Sat, 8 Jun 2013 10:39:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51B24489.6020301@comodo.com> <51B36550.6060106@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1508) Cc: wpkops@ietf.org Subject: Re: [wpkops] Initial draft of the revocation document. X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 17:39:31 -0000 On Jun 8, 2013, at 10:09 AM, Daniel Kahn Gillmor = wrote: > On 06/07/2013 04:39 PM, Phillip Hallam-Baker wrote: >> I dislike using RP as it comes with baggage. There is an advantage to >> having some distance when considering operations. >>=20 >> Web Browser would address that. >=20 > Are we just talking about web browsers in this WG, though? =20 https://datatracker.ietf.org/wg/wpkops/charter/ --Paul Hoffman= From bruce.morton@entrust.com Tue Jun 11 10:10:08 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE7C21F9965 for ; Tue, 11 Jun 2013 10:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYlcm1wBuch2 for ; Tue, 11 Jun 2013 10:09:54 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFAD21F9931 for ; Tue, 11 Jun 2013 10:09:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,846,1363147200"; d="scan'208,217";a="5953813" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 11 Jun 2013 13:09:53 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 13:09:53 -0400 From: Bruce Morton To: "wpkops WG (wpkops@ietf.org) (wpkops@ietf.org)" Thread-Topic: Trust Model Thread-Index: Ac5mxny3P0LgLMC3Szapooez4TG9yA== Date: Tue, 11 Jun 2013 17:09:52 +0000 Message-ID: <452C99D20750E74083DBA441FF9323857BF9FA04@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.137.14] Content-Type: multipart/alternative; boundary="_000_452C99D20750E74083DBA441FF9323857BF9FA04SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] Trust Model X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 17:10:08 -0000 --_000_452C99D20750E74083DBA441FF9323857BF9FA04SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Trust Model document is available in draft, https://tools.ietf.org/html= /draft-webpki-trustmodel-00. Please provide comments and feedback as soon as possible. We would like to = adopt or update this draft as the first WPKOPS working group draft by the e= nd of June. Please note that the draft was not named in accordance with the guidelines,= but subsequent versions will be named correctly. Thanks, Bruce Morton --_000_452C99D20750E74083DBA441FF9323857BF9FA04SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Trust Model document is available in draft, https://tools.ietf.org/html/draft-webpki-trustmodel-00.

 

Please provide comments and feedback as soon as poss= ible. We would like to adopt or update this draft as the first WPKOPS worki= ng group draft by the end of June.

 

Please note that the draft was not named in accordan= ce with the guidelines, but subsequent versions will be named correctly.

 

Thanks,

 

Bruce Morton

 

--_000_452C99D20750E74083DBA441FF9323857BF9FA04SOTTEXCH10corpa_-- From tom@ritter.vg Tue Jun 11 16:31:38 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EFA21F9B15 for ; Tue, 11 Jun 2013 16:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztJCZV3RQ959 for ; Tue, 11 Jun 2013 16:31:36 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 75BCA21F9B14 for ; Tue, 11 Jun 2013 16:31:36 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so8937668pbb.8 for ; Tue, 11 Jun 2013 16:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qsy+38fF+9L7aCyVuhQY77RWVAP2atA3A7kp5jWenZo=; b=yBkZQ7WRD2Q4xS1QwhMpHfTU7cNz88sQI77gYUEXi+9L85OylKB/2w/cpJNejckDhQ /JMxU6bo27DDdWEFJa9QjWIZ1ylj6LD3JYKbKJC0RsyFzB6afK3nDqY74H38UfiwhAcy e/P93Dq1rJXGKXIgWBpdBEucmKZfNGeVoZtgE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=qsy+38fF+9L7aCyVuhQY77RWVAP2atA3A7kp5jWenZo=; b=Mho3eNWa4WSUgl4DmpWhRl6mu6Q69JJHdI9rcJaFCu9apodsGhL4yQwAUq1THYOViB 7F3nXi6Ismc4hDKAGjmi1uZbBwQIb8l11rAteauxtLWxFA75R8dBcIwQOTPlhVJjtyxm MVXFy/5aKbZcSrLbGPv2qcpvSqEStIp509Sn5Jky7r1jPSYMEYlVgM1ETv9FJgYYX+Fi 4J00EOWMOMaB6Ra5+01K9WuhBsdwwBww6VZ5b9tuXjUCHuPAmcDl5Z3N7VpPPmYNIa8e qpXt/pK8C9fjXIyjnSCEKNdu6pIocbCHO4K4QZYBtWUUVFc4YbUi2G6RjiGLEpI6bH31 2FyQ== X-Received: by 10.66.150.40 with SMTP id uf8mr21427152pab.66.1370993496201; Tue, 11 Jun 2013 16:31:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.128.231 with HTTP; Tue, 11 Jun 2013 16:31:16 -0700 (PDT) In-Reply-To: <452C99D20750E74083DBA441FF9323857BF9FA04@SOTTEXCH10.corp.ad.entrust.com> References: <452C99D20750E74083DBA441FF9323857BF9FA04@SOTTEXCH10.corp.ad.entrust.com> From: Tom Ritter Date: Tue, 11 Jun 2013 19:31:16 -0400 Message-ID: To: Bruce Morton Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmePV9/04KFTmip1ndEgKaAMIr9gG6B1zh9CBlgG6we6Yys7lLkIWhfeijEOk1JnFq5RqR3 Cc: "wpkops WG \(wpkops@ietf.org\) \(wpkops@ietf.org\)" Subject: Re: [wpkops] Trust Model X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 23:31:38 -0000 Some thoughts on a first read-through: each of which is under the control of a CA and managed in conformance with the certificate policy accepted by the certificate-using client supplier. This confused the heck out of me on first read-through. Also, in (2) you say "certificate policy" meaning the policy created by the CA (I think), in (2.1) you say "certificate policy" meaning the policy created by the root store. (At least, AFAICT) The following graphic shows the relationship of the parties in the trust model. There is no graphic. "certificate-using client" This seems to be used a lot - maybe we can define a term for this in the beginning, e.g. "Client" The root store provider stores and manages root certificates in its certificate-using client to support the trust model. What trust model? We're trying to define the trust model, did you mean 'trust service'? The root store provider determines how trust will be validated It's not obvious to me what you mean by the noun 'trust' in this sentence. The root CAs issue certificates for subordinate issuing CAs It may be obvious, but perhaps we should specify here (and in the following sentences) who signs whom? The CA entity manages root, intermediate and issuing CAs in accordance with the certificate policy. The CA entity operates the certificate issuance and management system in accordance with the certificate policy. . These sentences seem awkward because they have the same verb and second half. Also, stray period =) The CA entity operates a registration authority which authenticates requests for certificates in accordance with the certificate policy. Which certificate policy? Once the certificate request has been accepted, the subscriber will receive the certificate and will manage the certificate in accordance with the certificate policy. Wait, now there's another certificate policy, this one applying to the subscriber. The relying party implicitly accepts the certificate policy by choosing to use a particular certificate-using client. I guess technically they're implicitly accepting all three.... but the ambiguity still bothers me. The certificate-using client does not use its own root store, but uses the root store managed by a separate root store provider. The certificate-using client evaluates the subscriber's certificate and may check the certificate subject's domain name matches that requested by the subscriber. The last sentence describes the checks done. 'evaluate' is super ambiguous. And nowhere does it say it actually uses the root store. Obviously client behavior is all over the place, but I feel like there should be a 'Usually, the client...' As the cross-certified root CA is also recognized directly by the root store provider, it operates in accordance with the requirements of that certificate policy, regardless of any requirements placed upon it by the contract between it and the cross- certifying root CA. This is another one of those "read it five times aloud slowly and I think I got now" sentences. Also, I have no idea what those requirements placed upon via contract might be. Maybe an example would help me? -tom From richard.smith@comodo.com Wed Jun 12 06:29:39 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207C421F9B15 for ; Wed, 12 Jun 2013 06:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoAWRiZgmyPt for ; Wed, 12 Jun 2013 06:29:35 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 212D121F997C for ; Wed, 12 Jun 2013 06:29:28 -0700 (PDT) Received: (qmail 1501 invoked from network); 12 Jun 2013 13:29:26 -0000 Received: from jcofcomail2.jc.office.comodo.net (HELO mail.nj.office.comodo.net) (10.104.70.204) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 12 Jun 2013 13:29:26 -0000 Received: (qmail 8643 invoked by uid 1012); 12 Jun 2013 13:29:25 -0000 Received: from Unknown (HELO CGIJC1DWWI1A5) (10.104.68.19) by mail.nj.office.comodo.net (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Wed, 12 Jun 2013 09:29:25 -0400 From: "Rich Smith" To: "'Tom Ritter'" , "'Bruce Morton'" References: <452C99D20750E74083DBA441FF9323857BF9FA04@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Date: Wed, 12 Jun 2013 09:29:23 -0400 Organization: Comodo Group, Inc. Message-ID: <01cb01ce6770$db0f8ab0$912ea010$@smith@comodo.com> X-Mailer: Microsoft Office Outlook 12.0 MIME-Version: 1.0 Thread-Index: Ac5m+9vAdciGW3O5SECjg1wkzPIliAAc2OQg Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_01C6_01CE674F.532E3EA0"; micalg=SHA1 X-Virus-Checked: Checked by ClamAV on mail.nj.office.comodo.net Cc: wpkops@ietf.org Subject: Re: [wpkops] Trust Model X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: richard.smith@comodo.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 13:29:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01C6_01CE674F.532E3EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In order to clarify many of Tom's points below, I suggest the following terms/definitions: Certificate Policy - The policy authored and followed by the Certificate Authority Trust Store Policy - The policy authored by the various Trust Store operators governing CA certificate inclusion in their Trust Store Subscriber Agreement - The terms and conditions placed upon the subscriber of an end-entity certificate Relying Party Agreement - The terms and conditions to which the relying party/end-user either implicitly or explicitly agrees to when making use of a particular end-entity certificate. Regards, Rich Smith Validation Manager Comodo > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On > Behalf Of Tom Ritter > Sent: Tuesday, June 11, 2013 7:31 PM > To: Bruce Morton > Cc: wpkops WG (wpkops@ietf.org) (wpkops@ietf.org) > Subject: Re: [wpkops] Trust Model > > Some thoughts on a first read-through: > > each of which is under the control of a CA > and managed in conformance with the certificate policy accepted by > the certificate-using client supplier. > > This confused the heck out of me on first read-through. Also, in (2) > you say "certificate policy" meaning the policy created by the CA (I > think), in (2.1) you say "certificate policy" meaning the policy > created by the root store. (At least, AFAICT) > > The following graphic shows the > relationship of the parties in the trust model. > > There is no graphic. > > "certificate-using client" > > This seems to be used a lot - maybe we can define a term for this in > the beginning, e.g. "Client" > > The root store provider stores and manages root > certificates in its certificate-using client to support the trust > model. > > What trust model? We're trying to define the trust model, did you mean > 'trust service'? > > The root store provider determines how trust will be > validated > > It's not obvious to me what you mean by the noun 'trust' in this > sentence. > > The root CAs > issue certificates for subordinate issuing CAs > > It may be obvious, but perhaps we should specify here (and in the > following sentences) who signs whom? > > The CA entity manages root, intermediate and issuing CAs in > accordance with the certificate policy. The CA entity operates the > certificate issuance and management system in accordance with the > certificate policy. . > > These sentences seem awkward because they have the same verb and second > half. Also, stray period =) > > The CA entity operates a registration authority which authenticates > requests for certificates in accordance with the certificate policy. > > Which certificate policy? > > Once the certificate request has been accepted, > the subscriber will receive the certificate and will manage the > certificate in accordance with the certificate policy. > > Wait, now there's another certificate policy, this one applying to the > subscriber. > > The relying party implicitly accepts the > certificate policy by choosing to use a particular certificate-using > client. > > I guess technically they're implicitly accepting all three.... but the > ambiguity still bothers me. > > The certificate-using client does not use its own root store, but > uses the root store managed by a separate root store provider. The > certificate-using client evaluates the subscriber's certificate and > may check the certificate subject's domain name matches that > requested by the subscriber. > > The last sentence describes the checks done. 'evaluate' is super > ambiguous. And nowhere does it say it actually uses the root store. > Obviously client behavior is all over the place, but I feel like there > should be a 'Usually, the client...' > > As the cross-certified root CA is also recognized directly by > the root store provider, it operates in accordance with the > requirements of that certificate policy, regardless of any > requirements placed upon it by the contract between it and the > cross- > certifying root CA. > > This is another one of those "read it five times aloud slowly and I > think I got now" sentences. Also, I have no idea what those > requirements placed upon via contract might be. Maybe an example would > help me? > > -tom > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops ------=_NextPart_000_01C6_01CE674F.532E3EA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUUTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggZUMIIFPKADAgECAhEAqDR0 NPXZ6UURhku5W7S0lTANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTAeFw0xMTA2MTAwMDAwMDBaFw0xNDA2MDkyMzU5NTlaMIIBKTELMAkGA1UEBhMCVVMx DjAMBgNVBBETBTA3MzEwMQswCQYDVQQIEwJOSjEUMBIGA1UEBxMLSmVyc2V5IENpdHkxEjAQBgNV BAkTCVN1aXRlMTQwMDEcMBoGA1UECRMTNTI1IFdhc2hpbmd0b24gQmx2ZDEaMBgGA1UEChMRQ29t b2RvIEdyb3VwIEluYy4xNzA1BgNVBAsTLklzc3VlZCB0aHJvdWdoIENvbW9kbyBHcm91cCBJbmMu IEUtUEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJpY2hhcmQgU21pdGgxJzAlBgkqhkiG9w0BCQEWGHJpY2hhcmQuc21pdGhAY29tb2RvLmNvbTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMPjP+Ri13hHVrQkDXKpGcoQKrjJ6qGLrOy fTCeyOLlxU0Xk362WTnYfUjDlMBppwDGIFqboM8EwlFr9xh5vhUULy4uU5oiEQeLoDGxVsmmxCZ7 OR2TBdFt9b8YizN01/QeAVbj8JSFtWwiwFtntLEAg8DIG2+Vw/LYxYs8LaT6XySFCX/tCZJSurAO VLIr83xT3yxySkOM0iCXk450FPFSGUaIL1k7oxRgiMD7m8Sj3bHgkT1EZfIcuZVcJfoeqAT1XHlj G6ewQIfStVb2JNTeuIxmu2HDvjdAEVN0bvyVvMoeWpLtAvrI1/VDZzBiwgcTmBjCh2Bt/hLvtbKh fUMCAwEAAaOCAggwggIEMB8GA1UdIwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQW BBS68Ixj5XXWDJB8tE3V+7n7k0gEXjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADApBgNV HSUEIjAgBggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcUAgIwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYD VR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAC hkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wTQYD VR0RBEYwRIEYcmljaGFyZC5zbWl0aEBjb21vZG8uY29toCgGCisGAQQBgjcUAgOgGgwYcmljaGFy ZC5zbWl0aEBjb21vZG8uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAFmeOXSnZsiT8YXbkbodhT82mh 3FvMKehuDnAD6t5f+MeEOUthUw4SCSHM2kCCVUzNeZ3qFsLA1oCJ/PCgwXgwkmPoHaBk8RBteGp2 E6IVrnlJ4QzCfY5h31uhQo7qxcnm0OEpSSIOd/xRyh/LV4I6+qLZz4aB0/FfBV3WaDOfkzuBOYGU kVD0A8lKCIZIbmvhcte5U+6LIrh7suu96RmWwHvAaCBNF7qNEgX20KEtHdW+1IPeNO2C6LlRMcOl zi4pXyc/gD09AaEGI9vMlG/Q81pyHwccUWDVQ+29zjsQ9s4o7q/waHHeuBBnND8YWqGbMrk8DcdJ tqWU3RQ5XaUsMYIEaDCCBGQCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCoNHQ09dnpRRGGS7lbtLSVMAkGBSsOAwIaBQCgggKTMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYxMjEzMjkyM1owIwYJKoZIhvcNAQkEMRYEFDgr6L/8 W8o70iDN4QiabU2Wd8C+MIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCoNHQ09dnpRRGGS7lbtLSVMIG8BgsqhkiG 9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMT MENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAKg0dDT1 2elFEYZLuVu0tJUwDQYJKoZIhvcNAQEBBQAEggEAFGpia91qshuXZw7NTgZVyIes0baVK5qmee59 AfnqBj8W23APmdY+ClymkxCWzxV3E844krbef+bKRhaWTi+dnvZu0+S0yhznECWID+zpA6poWVu4 LD0GH8H5pP/4CG1qnxE8cytQXSdHcu7pg513Pva1j5A7hxgRA9/ZtvZiw7q7xArxYuiUz9XEENmj D836Esk63unCDI0/bvd0iHRFTRdZtQg7NGSVcBf4apgV+B4cBi4MoVh7p1DOW23sFBzslj6eS7b+ g2oV1a8Ci+gsfwRpfXJbJXcfJ6UzHwDXs9bAnXnLBfvrfpDi6aUmSLsbFTJ1iQzyHWoeTGs7Wf5o EwAAAAAAAA== ------=_NextPart_000_01C6_01CE674F.532E3EA0-- From palmer@google.com Wed Jun 12 14:30:42 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD49311E8104 for ; Wed, 12 Jun 2013 14:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S93P9DlCUnIG for ; Wed, 12 Jun 2013 14:30:42 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4709211E80FF for ; Wed, 12 Jun 2013 14:30:42 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id p13so5300474vbe.0 for ; Wed, 12 Jun 2013 14:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dOXFemCetlfDgJ8ivaDC5uai4qhAR7JYWBfpzfYbM1c=; b=T8GQ7K2S0igCqqF02TVG1ZpI5IQIKFxgS21+JAdaxkrxlq+ZYj1sdnUueFqDpB2I4s hLO/XWJFMtLlvM7U2GiNv0UIaV2s2QrFoF0cW1KvgT0y4TT3zz0qfDFH5SilapAB0/F/ CW+dY8D7HboQyYdfXjh+I/WDbwlab2PZcm69pn3AEQM1jPSk89CTl8rz582GM69DEazd F5EeLZOA/7Kib4sTOuAbX8NnMaMU37E0F7MXR699FnLScmm3n2t3W/bH8P4F6pZpuLHJ UtKhYvch4mtLAdvlLxa60TImDbb9TlYVaPQ9IRiJdHZ4gcEzU3Kd1kuOeNDZ1spK+bmK QMAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=dOXFemCetlfDgJ8ivaDC5uai4qhAR7JYWBfpzfYbM1c=; b=GllgzOX0NwxlrmjeTploAm6ZvrRKwEzavbNJDInTYfWtvCzVArNOI4w57cYWNBYbYO rdYpcxkkdmZyVgej+oQvHvoWXc8tcrA19DPMCdHh8uf52pM6psm2MY7NjvCK9ikvddej TODbN9uACYylR/f5WxqbgSgO5cQhKkZMWIrvuV1qdjaXa2a0WbOrwLgFN4F9Kc+HHoI7 hwH5fh+m8hXtEsJhE1wokr+w+0V0h2NlkXaX8mU7IP3lyw8xeWcCU/3LqYeqJ86AS0uF JWQEakjw4kCAN/2MJqVSYD8dOKsNTxkbnMPh6BK5hkXq5wIFBi8Sh+wcs6fVHkNguInz D3ZA== MIME-Version: 1.0 X-Received: by 10.52.67.1 with SMTP id j1mr8919099vdt.84.1371072641475; Wed, 12 Jun 2013 14:30:41 -0700 (PDT) Received: by 10.220.192.199 with HTTP; Wed, 12 Jun 2013 14:30:41 -0700 (PDT) Received: by 10.220.192.199 with HTTP; Wed, 12 Jun 2013 14:30:41 -0700 (PDT) In-Reply-To: References: <452C99D20750E74083DBA441FF9323857BF9FA04@SOTTEXCH10.corp.ad.entrust.com> Date: Wed, 12 Jun 2013 14:30:41 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: multipart/alternative; boundary=20cf307cfbdac1bf3b04defbb917 X-Gm-Message-State: ALoCoQnam576PwhLYjO5IBLl0MU6IYXQ0c3P8RlpGyq1CtqfXlUizowIc4Y+FchXLuomsjURAQl4B1zr+Ogg1991xDNFzSLdSqOrmEmUCVOF2KGkZdqDWkFj0SMBDZLs3YisW9i7yzLCDFVrJnXXkhgtLN6tj4/AnxA8T2Ss6TFU5m4NCz+Xw9TAUrmpxZfYdPASUf0Uqr5h Cc: wpkops@ietf.org, Bruce Morton Subject: Re: [wpkops] Trust Model X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 21:30:42 -0000 --20cf307cfbdac1bf3b04defbb917 Content-Type: text/plain; charset=UTF-8 On Jun 11, 2013 4:31 PM, "Tom Ritter" wrote: > The root store provider determines how trust will be > validated > > It's not obvious to me what you mean by the noun 'trust' in this sentence. Agreed. I would say "...how trustworthiness will be established." --20cf307cfbdac1bf3b04defbb917 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jun 11, 2013 4:31 PM, "Tom Ritter" <tom@ritter.vg> wrote:

> The root store provider determines how trust will be > =C2=A0 =C2=A0validated
>
> It's not obvious to me what you mean by the noun 'trust' i= n this sentence.

Agreed. I would say "...how trustworthiness will be est= ablished."

--20cf307cfbdac1bf3b04defbb917-- From bruce.morton@entrust.com Mon Jun 17 11:12:23 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9423521F9D73 for ; Mon, 17 Jun 2013 11:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXdfIqymKclF for ; Mon, 17 Jun 2013 11:12:18 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id E1C9721F9D5A for ; Mon, 17 Jun 2013 11:12:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,882,1363147200"; d="scan'208,217";a="6004644" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 17 Jun 2013 14:12:16 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 14:12:16 -0400 From: Bruce Morton To: "wpkops WG (wpkops@ietf.org) (wpkops@ietf.org)" Thread-Topic: [wpkops] Trust Model Thread-Index: Ac5mxny3P0LgLMC3Szapooez4TG9yAAVs7cAARBbjhA= Date: Mon, 17 Jun 2013 18:12:14 +0000 Message-ID: <452C99D20750E74083DBA441FF9323857BFA62AC@SOTTEXCH10.corp.ad.entrust.com> References: <452C99D20750E74083DBA441FF9323857BF9FA04@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.137.14] Content-Type: multipart/alternative; boundary="_000_452C99D20750E74083DBA441FF9323857BFA62ACSOTTEXCH10corpa_" MIME-Version: 1.0 Subject: Re: [wpkops] Trust Model X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 18:12:23 -0000 --_000_452C99D20750E74083DBA441FF9323857BFA62ACSOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for the feedback on the document. If there are no objections, we will proceed with an update based on the fol= lowing in this email. There is some confusion about certificate policy. As such we can break this= down into three items that may provide more clarification: - Root store policy - policy provided by the root store provider f= or the CA to follow - Certificate policy - policy developed by the CA which will incor= porate applicable requirements for one or many root store policies - Subscriber agreement - agreement provided to the Subscriber whic= h may include applicable requirements from the root store and the certifica= te policies. The definition will be taken from RFC 3647. More responses to Tom's comments below. Thanks, Bruce. -----Original Message----- From: Tom Ritter [mailto:tom@ritter.vg] Sent: Tuesday, June 11, 2013 7:31 PM To: Bruce Morton Cc: wpkops WG (wpkops@ietf.org) (wpkops@ietf.org) Subject: Re: [wpkops] Trust Model Some thoughts on a first read-through: each of which is under the control of a CA and managed in conformance with the certificate policy accepted by the certificate-using client supplier. [Bruce Morton] Will change the wording. This confused the heck out of me on first read-through. Also, in (2) you s= ay "certificate policy" meaning the policy created by the CA (I think), in = (2.1) you say "certificate policy" meaning the policy created by the root s= tore. (At least, AFAICT) [Bruce Morton] Hopefully the changes above will clarify this item. The following graphic shows the relationship of the parties in the trust model. There is no graphic. [Bruce Morton] Will have to understand how to include a graphic in the docu= ment. For now, the graphic and references will be removed. "certificate-using client" This seems to be used a lot - maybe we can define a term for this in the be= ginning, e.g. "Client" [Bruce Morton] I was trying to stay away from definitions and just use term= s already accepted in RFC 5280. If this would help to clarify the Trust Mod= el document, then it can be defined. The root store provider stores and manages root certificates in its certificate-using client to support the trust model. What trust model? We're trying to define the trust model, did you mean 'tr= ust service'? [Bruce Morton] To avoid confusion, I will change this to 'the trust model' = to 'trust'. The root store provider determines how trust will be validated It's not obvious to me what you mean by the noun 'trust' in this sentence. [Bruce Morton] Will change to 'how trustworthiness will be established' per= Chris' suggestion. The root CAs issue certificates for subordinate issuing CAs It may be obvious, but perhaps we should specify here (and in the following= sentences) who signs whom? [Bruce Morton] Will change 'issue' to 'sign'. The CA entity manages root, intermediate and issuing CAs in accordance with the certificate policy. The CA entity operates the certificate issuance and management system in accordance with the certificate policy. . These sentences seem awkward because they have the same verb and second hal= f. Also, stray period =3D) The CA entity operates a registration authority which authenticates requests for certificates in accordance with the certificate policy. [Bruce Morton] Will re-edit. Which certificate policy? [Bruce Morton] This will be the certificate policy developed by the CA enti= ty. Once the certificate request has been accepted, the subscriber will receive the certificate and will manage the certificate in accordance with the certificate policy. Wait, now there's another certificate policy, this one applying to the subs= criber. [Bruce Morton] We will change this to subscriber agreement. The relying party implicitly accepts the certificate policy by choosing to use a particular certificate-using client. I guess technically they're implicitly accepting all three.... but the ambi= guity still bothers me. [Bruce Morton] The relying party will implicitly accept the root store poli= cy and the certificate policy. The certificate-using client does not use its own root store, but uses the root store managed by a separate root store provider. The certificate-using client evaluates the subscriber's certificate and may check the certificate subject's domain name matches that requested by the subscriber. The last sentence describes the checks done. 'evaluate' is super ambiguous= . And nowhere does it say it actually uses the root store. Obviously client behavior is all over the place, but I feel like there shou= ld be a 'Usually, the client...' [Bruce Morton] We can add in 'Usually.' As the cross-certified root CA is also recognized directly by the root store provider, it operates in accordance with the requirements of that certificate policy, regardless of any requirements placed upon it by the contract between it and the cross- certifying root CA. This is another one of those "read it five times aloud slowly and I think I= got now" sentences. Also, I have no idea what those requirements placed up= on via contract might be. Maybe an example would help me? [Bruce Morton] The point here is to say that the cross-certified root CA al= so directly follows then root store provider's certificate policy. I don't = think an example of what would go in the contract is required here as we ar= e saying the contract is not necessarily relevant. -tom --_000_452C99D20750E74083DBA441FF9323857BFA62ACSOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for the feedback on the document.<= /o:p>

 

If there are no objections, we will proceed with = an update based on the following in this email.

 

There is some confusion about certificate policy.= As such we can break this down into three items that may provide more clar= ification:

-       = ;   Root store policy – policy provided by the ro= ot store provider for the CA to follow

-       = ;   Certificate policy – policy developed by the = CA which will incorporate applicable requirements for one or many root stor= e policies

-       = ;   Subscriber agreement – agreement provided to = the Subscriber which may include applicable requirements from the root stor= e and the certificate policies. The definition will be taken from RFC 3647.=

 

More responses to Tom’s comments below.

 

Thanks, Bruce.

 

-----Original Message-----
From: Tom Ritter [mailto:tom@ritter.vg]
Sent: Tuesday, June 11, 2013 7:31 PM
To: Bruce Morton
Cc: wpkops WG (wpkops@ietf.org) (wpkops@ietf.org)
Subject: Re: [wpkops] Trust Model

 

Some thoughts on a first read-through:=

 

each of which is under the control of a CA

    and managed in conformance wit= h the certificate policy accepted by

    the certificate-using client s= upplier.

[Bruce Morton] = Will change the wording.

 

This confused the heck out of me on first read-th= rough.  Also, in (2) you say "certificate policy" meaning th= e policy created by the CA (I think), in (2.1) you say "certificate po= licy" meaning the policy created by the root store.  (At least, AFAICT)

[Bruce Morton] = Hopefully the changes above will clarify this item.

 

The following graphic shows the

   relationship of the parties in the t= rust model.

 

There is no graphic.

[Bruce Morton] = Will have to understand how to include a graphic in the document. For now, = the graphic and references will be removed.

 

"certificate-using client"

 

This seems to be used a lot - maybe we can define= a term for this in the beginning, e.g. "Client"

[Bruce Morton] = I was trying to stay away from definitions and just use terms already accep= ted in RFC 5280. If this would help to clarify the Trust Model document, th= en it can be defined.

 

The root store provider stores and manages root

   certificates in its certificate-usin= g client to support the trust

   model.

 

What trust model?  We're trying to define th= e trust model, did you mean 'trust service'?

[Bruce Morton] = To avoid confusion, I will change this to 'the trust model' to 'trust'.

 

The root store provider determines how trust will= be

   validated

 

It's not obvious to me what you mean by the noun = 'trust' in this sentence.

[Bruce Morton] = Will change to ‘how trustworthiness will be established’ per Ch= ris’ suggestion.

 

The root CAs

   issue certificates for subordinate i= ssuing CAs

 

It may be obvious, but perhaps we should specify = here (and in the following sentences) who signs whom?

[Bruce Morton] = Will change 'issue' to 'sign'.

 

The CA entity manages root, intermediate and issu= ing CAs in

   accordance with the certificate poli= cy.  The CA entity operates the

   certificate issuance and management = system in accordance with the

   certificate policy.  .

 

These sentences seem awkward because they have th= e same verb and second half.  Also, stray period =3D)

 

   The CA entity operates a registratio= n authority which authenticates

   requests for certificates in accorda= nce with the certificate policy.

[Bruce Morton] = Will re-edit.

 

Which certificate policy?

[Bruce Morton] = This will be the certificate policy developed by the CA entity.<= /span>

 

Once the certificate request has been accepted,

   the subscriber will receive the cert= ificate and will manage the

   certificate in accordance with the c= ertificate policy.

 

Wait, now there's another certificate policy, thi= s one applying to the subscriber.

[Bruce Morton] = We will change this to subscriber agreement.

 

The relying party implicitly accepts the

   certificate policy by choosing to us= e a particular certificate-using

   client.

 

I guess technically they're implicitly accepting = all three.... but the ambiguity still bothers me.

[Bruce Morton] = The relying party will implicitly accept the root store policy and the cert= ificate policy.

 

The certificate-using client does not use its own= root store, but

   uses the root store managed by a sep= arate root store provider.  The

   certificate-using client evaluates t= he subscriber's certificate and

   may check the certificate subject's = domain name matches that

   requested by the subscriber.

 

The last sentence describes the checks done. = ; 'evaluate' is super ambiguous.  And nowhere does it say it actually = uses the root store.

Obviously client behavior is all over the place, = but I feel like there should be a 'Usually, the client...'

[Bruce Morton] = We can add  in ‘Usually.’

 

As the cross-certified root CA is also recognized= directly by

   the root store provider, it operates= in accordance with the

   requirements of that certificate pol= icy, regardless of any

   requirements placed upon it by the c= ontract between it and the cross-

   certifying root CA.

 

This is another one of those "read it five t= imes aloud slowly and I think I got now" sentences. Also, I have no id= ea what those requirements placed upon via contract might be.  Maybe a= n example would help me?

[Bruce Morton] = The point here is to say that the cross-certified root CA also directly fol= lows then root store provider’s certificate policy. I don’t thi= nk an example of what would go in the contract is required here as we are saying the contract is not necessarily relevant.

 

-tom

--_000_452C99D20750E74083DBA441FF9323857BFA62ACSOTTEXCH10corpa_-- From sharon.boeyen@entrust.com Wed Jun 19 07:23:15 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C187821F9C02 for ; Wed, 19 Jun 2013 07:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP7kLtqkWKNV for ; Wed, 19 Jun 2013 07:23:10 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD1621F9C03 for ; Wed, 19 Jun 2013 07:23:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,896,1363147200"; d="scan'208,217";a="9308590" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 19 Jun 2013 10:23:08 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 10:23:07 -0400 From: Sharon Boeyen To: "wpkops WG (wpkops@ietf.org)" Thread-Topic: Adoption of Trust Model paper as WG draft Thread-Index: Ac5s+IHpV1YwOVU9TsSqlKZdZHTESw== Date: Wed, 19 Jun 2013 14:23:07 +0000 Message-ID: <65DA4BEA501AFC409DF274CC71ED01A57C67F004@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.161.12] Content-Type: multipart/alternative; boundary="_000_65DA4BEA501AFC409DF274CC71ED01A57C67F004SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] Adoption of Trust Model paper as WG draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:23:15 -0000 --_000_65DA4BEA501AFC409DF274CC71ED01A57C67F004SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our WG charter includes a milestone for adoption of the 1st WG draft of the= trust models paper this month. Only a few comments on the current individual draft have been received and = a response on how they will be addressed was sent to the list yesterday. Please comment on whether or not you are prepared to adopt the paper (with = the promised changes) as the first wpkops WG draft. In order to give the au= thors time to update the draft and submit before the cutoff in early July i= t is important to get the WG feedback asap. Please provide a Yes/No indicat= ion to the mail list within the next week. Also, if you have any additional= comments on the draft please submit them asap as well. Cheers, Sharon --_000_65DA4BEA501AFC409DF274CC71ED01A57C67F004SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our WG charter includes a milestone for adoption of = the 1st WG draft of the trust models paper this month.

 

Only a few comments on the current individual draft = have been received and a response on how they will be addressed was sent to= the list yesterday.

 

Please comment on whether or not you are prepared to= adopt the paper (with the promised changes) as the first wpkops WG draft. = In order to give the authors time to update the draft and submit before the= cutoff in early July it is important to get the WG feedback asap. Please provide a Yes/No indication to the mai= l list within the next week. Also, if you have any additional comments on t= he draft please submit them asap as well.

 

Cheers,

Sharon

--_000_65DA4BEA501AFC409DF274CC71ED01A57C67F004SOTTEXCH10corpa_-- From sharon.boeyen@entrust.com Wed Jun 19 07:29:31 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE3B21F9C35 for ; Wed, 19 Jun 2013 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f98znwlS7fi2 for ; Wed, 19 Jun 2013 07:29:26 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 86EEB21F9C32 for ; Wed, 19 Jun 2013 07:29:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,896,1363147200"; d="scan'208,217";a="6024085" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 19 Jun 2013 10:29:19 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Wed, 19 Jun 2013 10:29:19 -0400 From: Sharon Boeyen To: "wpkops WG (wpkops@ietf.org)" Thread-Topic: No agenda items for Berlin Thread-Index: Ac5s+WFWW3QQjtjYTE6LtvLtKLIGIQ== Date: Wed, 19 Jun 2013 14:29:18 +0000 Message-ID: <65DA4BEA501AFC409DF274CC71ED01A57C67F066@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.161.12] Content-Type: multipart/alternative; boundary="_000_65DA4BEA501AFC409DF274CC71ED01A57C67F066SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] No agenda items for Berlin X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:29:32 -0000 --_000_65DA4BEA501AFC409DF274CC71ED01A57C67F066SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jeremy sent out a call for agenda items on May 31st for the Berlin IETF mee= ting of this WG. To date no agenda item submissions have been received. Alt= hough there are two individual drafts sent to the mail list in the past wee= ks, there has also been little in the way of feedback or comment on those p= apers and no obvious contentious issues that would require face-to-face deb= ate. As a result, Jeremy and I are considering cancelling the face-to-face meeti= ng we were planning for the Berlin IETF. We will probably do that by the end of this week, unless there is a sudden = flood of agenda item requests by then. We'll send an email to the list once= the decision is finalized (likely Friday or Monday). Cheers, Sharon --_000_65DA4BEA501AFC409DF274CC71ED01A57C67F066SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeremy sent out a call for agenda items on May 31st for the Berlin IETF meeting of this WG. To date no agenda item s= ubmissions have been received. Although there are two individual drafts sen= t to the mail list in the past weeks, there has also been little in the way of feedback or comment on those pape= rs and no obvious contentious issues that would require face-to-face debate= .

 

As a result, Jeremy and I are considering cancelling= the face-to-face meeting we were planning for the Berlin IETF.

 

We will probably do that by the end of this week, un= less there is a sudden flood of agenda item requests by then. We’ll s= end an email to the list once the decision is finalized (likely Friday or M= onday).

 

Cheers,

Sharon

--_000_65DA4BEA501AFC409DF274CC71ED01A57C67F066SOTTEXCH10corpa_-- From joelja@bogus.com Wed Jun 19 07:39:28 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A2121F9CC5 for ; Wed, 19 Jun 2013 07:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x6HGGEUXXqT for ; Wed, 19 Jun 2013 07:39:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DC7E421F9CA1 for ; Wed, 19 Jun 2013 07:39:27 -0700 (PDT) Received: from joels-MacBook-Air.local ([199.108.68.6]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5JEdNJk060950 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 14:39:25 GMT (envelope-from joelja@bogus.com) Message-ID: <51C1C295.9070709@bogus.com> Date: Wed, 19 Jun 2013 07:39:17 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Sharon Boeyen , "wpkops WG (wpkops@ietf.org)" References: <65DA4BEA501AFC409DF274CC71ED01A57C67F066@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <65DA4BEA501AFC409DF274CC71ED01A57C67F066@SOTTEXCH10.corp.ad.entrust.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 19 Jun 2013 14:39:26 +0000 (UTC) Subject: Re: [wpkops] No agenda items for Berlin X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:39:28 -0000 On 6/19/13 7:29 AM, Sharon Boeyen wrote: > > Jeremy sent out a call for agenda items on May 31^st for the Berlin > IETF meeting of this WG. To date no agenda item submissions have been > received. Although there are two individual drafts sent to the mail > list in the past weeks, there has also been little in the way of > feedback or comment on those papers and no obvious contentious issues > that would require face-to-face debate. > > As a result, Jeremy and I are considering cancelling the face-to-face > meeting we were planning for the Berlin IETF. > > We will probably do that by the end of this week, unless there is a > sudden flood of agenda item requests by then. We’ll send an email to > the list once the decision is finalized (likely Friday or Monday). > > I'd opine that we should avail ourselves of deadlines where appropriate to encourage submission. 00 draft submission deadline for the 87 meeting is 7/8 and that's a useful deadline to shoot for, whether we are meeting or not. It means we can discuss them while people have IETF on the mind. Thanks joel > Cheers, > > Sharon > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops From sharon.boeyen@entrust.com Mon Jun 24 09:40:58 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34A621E8127 for ; Mon, 24 Jun 2013 09:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbX4wKmQHNGK for ; Mon, 24 Jun 2013 09:40:53 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 97A5521E810D for ; Mon, 24 Jun 2013 09:40:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,929,1363147200"; d="scan'208,217";a="6065685" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 24 Jun 2013 12:40:52 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 12:40:52 -0400 From: Sharon Boeyen To: "wpkops WG (wpkops@ietf.org)" Thread-Topic: Silence is deafening - Trust Model Paper Thread-Index: Ac5w+ZSoQsntgfnhSwGtPfDMuxnBDw== Date: Mon, 24 Jun 2013 16:40:51 +0000 Message-ID: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.161.12] Content-Type: multipart/alternative; boundary="_000_65DA4BEA501AFC409DF274CC71ED01A57C69DCE7SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:40:58 -0000 --_000_65DA4BEA501AFC409DF274CC71ED01A57C69DCE7SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has everyone lost interest in this work and this WG? The silence is deafening! We are going to miss our milestone of adoption of a first WG draft of the T= rust Model paper if we don't get some more feedback immediately. Please take a minute to send a brief email to the list indication whether o= r not you are in favour of adopting the current draft (with the promised up= dates) as the first WG draft of the Trust Model paper. If we get no feedback in the next day or two we'll need to seriously questi= on whether to continue the activity or not. --_000_65DA4BEA501AFC409DF274CC71ED01A57C69DCE7SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Has everyone lost interest in this work and this WG?=

 

The silence is deafening!

 

We are going to miss our milestone of adoption of a = first WG draft of the Trust Model paper if we don’t get some more fee= dback immediately.

 

Please take a minute to send a brief email to the li= st indication whether or not you are in favour of adopting the current draf= t (with the promised updates) as the first WG draft of the Trust Model pape= r.

 

If we get no feedback in the next day or two we̵= 7;ll need to seriously question whether to continue the activity or not.

--_000_65DA4BEA501AFC409DF274CC71ED01A57C69DCE7SOTTEXCH10corpa_-- From joncallas@me.com Mon Jun 24 10:18:51 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5F421E811C for ; Mon, 24 Jun 2013 10:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCzLT4bP4FBp for ; Mon, 24 Jun 2013 10:18:46 -0700 (PDT) Received: from st11p01mm-asmtp001.mac.com (st11p01mm-asmtp001.mac.com [17.172.204.236]) by ietfa.amsl.com (Postfix) with ESMTP id DA59221E8119 for ; Mon, 24 Jun 2013 10:18:45 -0700 (PDT) Received: from [10.0.23.15] (media.merrymeet.com [173.164.244.98]) by st11p01mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.06(7.0.4.27.5) 64bit (built May 31 2013)) with ESMTPSA id <0MOW00JUCQR68OB0@st11p01mm-asmtp001.mac.com> for wpkops@ietf.org; Mon, 24 Jun 2013 17:18:44 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-06-24_04:2013-06-24, 2013-06-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1306240157 Content-type: multipart/alternative; boundary="Apple-Mail=_DE3C1246-4442-44C0-82C2-4AE97DD04CA3" MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jon Callas In-reply-to: <65DA4BEA501AFC409DF274CC71ED01A57C67F004@SOTTEXCH10.corp.ad.entrust.com> Date: Mon, 24 Jun 2013 10:18:42 -0700 Message-id: References: <65DA4BEA501AFC409DF274CC71ED01A57C67F004@SOTTEXCH10.corp.ad.entrust.com> To: Sharon Boeyen X-Mailer: Apple Mail (2.1508) Cc: "wpkops WG \(wpkops@ietf.org\)" , Jon Callas Subject: Re: [wpkops] Adoption of Trust Model paper as WG draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 17:18:51 -0000 --Apple-Mail=_DE3C1246-4442-44C0-82C2-4AE97DD04CA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 19, 2013, at 7:23 AM, Sharon Boeyen = wrote: > Our WG charter includes a milestone for adoption of the 1st WG draft = of the trust models paper this month. > =20 > Only a few comments on the current individual draft have been received = and a response on how they will be addressed was sent to the list = yesterday. > =20 > Please comment on whether or not you are prepared to adopt the paper = (with the promised changes) as the first wpkops WG draft. In order to = give the authors time to update the draft and submit before the cutoff = in early July it is important to get the WG feedback asap. Please = provide a Yes/No indication to the mail list within the next week. Also, = if you have any additional comments on the draft please submit them asap = as well. > =20 Yes. Go for it. Jon --Apple-Mail=_DE3C1246-4442-44C0-82C2-4AE97DD04CA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii sharon.boeyen@entrust.com>= ; wrote:
Our WG charter includes a milestone for adoption = of the 1st WG= draft of the trust models paper this month.
 
Only = a few comments on the current individual draft have been received and a = response on how they will be addressed was sent to the list = yesterday.
Please comment on = whether or not you are prepared to adopt the paper (with the promised = changes) as the first wpkops WG draft. In order to give the authors time = to update the draft and submit before the cutoff in early July it is = important to get the WG feedback asap. Please provide a Yes/No = indication to the mail list within the next week. Also, if you have any = additional comments on the draft please submit them asap as = well.
= Jon

= --Apple-Mail=_DE3C1246-4442-44C0-82C2-4AE97DD04CA3-- From ynir@checkpoint.com Mon Jun 24 15:38:45 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F5011E817C for ; Mon, 24 Jun 2013 15:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.605 X-Spam-Level: X-Spam-Status: No, score=-10.605 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz2qehF6Gixv for ; Mon, 24 Jun 2013 15:38:39 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E7CF321F9D4D for ; Mon, 24 Jun 2013 15:38:38 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5OMcRfx007841; Tue, 25 Jun 2013 01:38:31 +0300 X-CheckPoint: {51C8CA63-28-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 01:38:27 +0300 From: Yoav Nir To: Sharon Boeyen Thread-Topic: [wpkops] Adoption of Trust Model paper as WG draft Thread-Index: Ac5s+IHpV1YwOVU9TsSqlKZdZHTESwEGeKaA Date: Mon, 24 Jun 2013 22:38:26 +0000 Message-ID: References: <65DA4BEA501AFC409DF274CC71ED01A57C67F004@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <65DA4BEA501AFC409DF274CC71ED01A57C67F004@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.170] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1115fdad0716c24b3067d1aa2e9b917ecc3256eec3 Content-Type: multipart/alternative; boundary="_000_B326C709EFE54EF6B1D6B485FF7E709Ccheckpointcom_" MIME-Version: 1.0 Cc: "wpkops WG \(wpkops@ietf.org\)" Subject: Re: [wpkops] Adoption of Trust Model paper as WG draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 22:38:45 -0000 --_000_B326C709EFE54EF6B1D6B485FF7E709Ccheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've read the draft, and I think it is appropriate as a starting point for = a trust model document in WPKOPS. The draft says (section 1.2) that root CAs have root certificates, which ar= e self-signed certificates. That last bit is not required by either RFC 528= 0 or RFC 6024. RFC 5280 defines cross-certificates (which are CAs) as certi= ficates having different subject and issuer. IOW they're just not self-issu= ed. What makes a CA (and its certificate) "root"is not that they're self-is= sued or self-signed, but the fact that they are present in the trust anchor= store. It's common for the public CAs to be self-signed, but I've tested Firefox, = Microsoft, and Apple's store, and they all accept non-self-signed certifica= tes as trusted roots. So I'd replace "a self-signed certificate" with "a certificate, typically s= elf-signed" But this does not detract from my opinion that this draft should be adopted= . Yoav On Jun 19, 2013, at 5:23 PM, Sharon Boeyen > wrote: Our WG charter includes a milestone for adoption of the 1st WG draft of the= trust models paper this month. Only a few comments on the current individual draft have been received and = a response on how they will be addressed was sent to the list yesterday. Please comment on whether or not you are prepared to adopt the paper (with = the promised changes) as the first wpkops WG draft. In order to give the au= thors time to update the draft and submit before the cutoff in early July i= t is important to get the WG feedback asap. Please provide a Yes/No indicat= ion to the mail list within the next week. Also, if you have any additional= comments on the draft please submit them asap as well. Cheers, Sharon --_000_B326C709EFE54EF6B1D6B485FF7E709Ccheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <47958753400C6F41A4B7267B22370F44@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable I've read the draft, and I think it is appropriate as a starting point for = a trust model document in WPKOPS.

The draft says (section 1.2) that root CAs have root certificates, whi= ch are self-signed certificates. That last bit is not required by either RF= C 5280 or RFC 6024. RFC 5280 defines cross-certificates (which are CAs) as = certificates having different subject and issuer. IOW they're just not self-issued. What makes a CA (and its cer= tificate) "root"is not that they're self-issued or self-signed, b= ut the fact that they are present in the trust anchor store.

It's common for the public CAs to be self-signed, but I've tested Fire= fox, Microsoft, and Apple's store, and they all accept non-self-signed cert= ificates as trusted roots.

So I'd replace "a self-signed certificate" with "a cert= ificate, typically self-signed"

But this does not detract from my opinion that this draft should be ad= opted.

Yoav

On Jun 19, 2013, at 5:23 PM, Sharon Boeyen <sharon.boeyen@entrust.com> wrote:

Our WG charter includes a milestone for adoption of the 1st WG draft of the trust models = paper this month.
 
Only a few comments on the current individual draft have been received and = a response on how they will be addressed was sent to the list yesterday.
 
Please comment on whether or not you are prepared to adopt the paper (with = the promised changes) as the first wpkops WG draft. In order to give the au= thors time to update the draft and submit before the cutoff in early July i= t is important to get the WG feedback asap. Please provide a Yes/No indication to the mail list within the next = week. Also, if you have any additional comments on the draft please submit = them asap as well.
 
Cheers,
Sharon

--_000_B326C709EFE54EF6B1D6B485FF7E709Ccheckpointcom_-- From ilari.liusvaara@elisanet.fi Mon Jun 24 15:47:34 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAFE11E817C for ; Mon, 24 Jun 2013 15:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H3UYKwlxs-0 for ; Mon, 24 Jun 2013 15:47:27 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by ietfa.amsl.com (Postfix) with ESMTP id 1678111E8167 for ; Mon, 24 Jun 2013 15:47:27 -0700 (PDT) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh04.mail.saunalahti.fi (Postfix) with SMTP id 93DF11A25C4; Tue, 25 Jun 2013 01:47:25 +0300 (EEST) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A016208D36B; Tue, 25 Jun 2013 01:47:25 +0300 Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 0A7DF1A25C4; Tue, 25 Jun 2013 01:47:24 +0300 (EEST) Date: Tue, 25 Jun 2013 01:47:24 +0300 From: Ilari Liusvaara To: Sharon Boeyen Message-ID: <20130624224724.GA1448@LK-Perkele-VII> References: <65DA4BEA501AFC409DF274CC71ED01A57C67F004@SOTTEXCH10.corp.ad.entrust.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <65DA4BEA501AFC409DF274CC71ED01A57C67F004@SOTTEXCH10.corp.ad.entrust.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: "wpkops WG \(wpkops@ietf.org\)" Subject: Re: [wpkops] Adoption of Trust Model paper as WG draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 22:47:34 -0000 On Wed, Jun 19, 2013 at 02:23:07PM +0000, Sharon Boeyen wrote: > Our WG charter includes a milestone for adoption of the 1st WG draft of the trust models paper this month. > > Only a few comments on the current individual draft have been received and a response on how they will be addressed was sent to the list yesterday. > > Please comment on whether or not you are prepared to adopt the paper (with the promised changes) as the first wpkops WG draft. In order to give the authors time to update the draft and submit before the cutoff in early July it is important to get the WG feedback asap. Please provide a Yes/No indication to the mail list within the next week. Also, if you have any additional comments on the draft please submit them asap as well. Yes, adapt it. Some comments: > 1.1. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119] None of these words seem to be used anywhere. And given the nature of this document ("what is" instead of "what should"), I don' think those words would see much use... > 2.2.4. CA audit > > The CA is subject to an annual compliance audit performed by a third > party audit as prescribed by the certificate policy. Annual? I guess that is just customary to have annual audits. Also, "audit" seems to be duplicated? -Ilari From paul.hoffman@vpnc.org Mon Jun 24 15:56:20 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F4621E8156 for ; Mon, 24 Jun 2013 15:56:20 -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.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAcVfOMxRoZp for ; Mon, 24 Jun 2013 15:56:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 207E721E8151 for ; Mon, 24 Jun 2013 15:56:20 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5OMuH9S089291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 15:56:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> Date: Mon, 24 Jun 2013 15:56:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> To: Sharon Boeyen X-Mailer: Apple Mail (2.1508) Cc: "wpkops WG \(wpkops@ietf.org\)" Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 22:56:20 -0000 The model in draft draft-webpki-trustmodel does not match the charter = for this WG. It over-reaches by talking about "certificate-using = clients" that are not web browsers. Even if the document is more narrowly scoped to meet the charter, it = still has many problems. It blithely assumes that all CAs follow their = certificate policies (which we have seen is not true), and states that = such certificate polices are "accepted" by client suppliers, which is = only true if "accepted" means "without any real checking, and generally = without any punishment after lapses are found". The draft also says that "the relying party implicitly accepts" the root = store without discussing what this implicit acceptance means. There is = no discussion of what user expectations might be (such as surprise that = governments can cause certificates issued for sites of enemy = governments).=20 The WG should consider instead requiring the draft apply to the = real-world Web PKI where browsers makers do not hold CAs accountable = when lapses are found and users do not understand anything about the = role of the root store. In other words, the WG should consider a much more realistic draft. = Otherwise, a reader might think that the WG's eventual RFC describes = something operationally useful. --Paul Hoffman= From bruce.morton@entrust.com Mon Jun 24 19:09:10 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD7021E8050 for ; Mon, 24 Jun 2013 19:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYlr3TknEBbI for ; Mon, 24 Jun 2013 19:09:06 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id D1CF421E804C for ; Mon, 24 Jun 2013 19:09:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,932,1363147200"; d="scan'208,217";a="6069650" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 24 Jun 2013 22:09:04 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 22:09:04 -0400 From: Bruce Morton To: Paul Hoffman , Sharon Boeyen Thread-Topic: [wpkops] Silence is deafening - Trust Model Paper Thread-Index: Ac5w+ZSoQsntgfnhSwGtPfDMuxnBDwAVfqUAAANhouA= Date: Tue, 25 Jun 2013 02:09:03 +0000 Message-ID: <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.25.128] Content-Type: multipart/alternative; boundary="_000_452C99D20750E74083DBA441FF9323857BFCBB43SOTTEXCH10corpa_" MIME-Version: 1.0 Cc: "wpkops WG \(wpkops@ietf.org\)" Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 02:09:10 -0000 --_000_452C99D20750E74083DBA441FF9323857BFCBB43SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just wanted to say that the approach to the Trust Model document was to s= how how the actions of the browser and the CA provide trust between the sub= scriber and the relying party. A basic model was shown and then some varian= ts. The reason was to show the reality out there that may help people under= stand the realities and develop better policies. For instance, many people = did not understand the issues of a CA issuing a CA certificate. This was n= ot discussed in browser policies and not referenced in WebTrust 1.0. Howeve= r, when DigiNotar and Digicert Malaysia were blacklisted, this reality had = to be accounted for. Some general comments on this approach would be useful. I have also provided some responses to Paul's comments below. Thanks, Bruce. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Paul Hoffman Sent: Monday, June 24, 2013 6:56 PM To: Sharon Boeyen Cc: wpkops WG (wpkops@ietf.org) Subject: Re: [wpkops] Silence is deafening - Trust Model Paper The model in draft draft-webpki-trustmodel does not match the charter for t= his WG. It over-reaches by talking about "certificate-using clients" that a= re not web browsers. [Bruce Morton] Sorry if this is outside the charter. We might want to consi= der opening up the charter just a little bit as the relying parties might b= e using something other than a browser. This might be opening up more and m= ore in the mobile world. Even if the document is more narrowly scoped to meet the charter, it still = has many problems. It blithely assumes that all CAs follow their certificat= e policies (which we have seen is not true), and states that such certifica= te polices are "accepted" by client suppliers, which is only true if "accep= ted" means "without any real checking, and generally without any punishment= after lapses are found". [Bruce Morton] I think the CAs would concur that a CP and/or CPS is develo= ped based on the requirements from the OS/browser developers. Most CAs have= a policy authority to define policy. They may have internal auditors to en= sure they are meeting policy and they are annually audited to show complian= ce to their policies. There are cases where a CA does not meet their policy= . There are also cases where the policy is incorrect. In general all CAs en= deavor to meet their policies and put corrective action in place where a mi= stake has been made. The draft also says that "the relying party implicitly accepts" the root st= ore without discussing what this implicit acceptance means. There is no dis= cussion of what user expectations might be (such as surprise that governmen= ts can cause certificates issued for sites of enemy governments). [Bruce Morton] I agree that Relying Party is an issue which is why the word= implicit is used. In reality, the Relying Party uses a browser and may res= pond to a trust dialogue if it appears. The WG should consider instead requiring the draft apply to the real-world = Web PKI where browsers makers do not hold CAs accountable when lapses are f= ound and users do not understand anything about the role of the root store. [Bruce Morton] We have seen that OS/browsers do hold CAs accountable. In th= e past we have seen that DigiNotar and Digicert Malaysia CA certificates ha= ve been blacklisted. The browsers also take other actions is counteract the= actions of the CAs. Microsoft has rejected all certificates with keys less= than 1024-bit RSA. Chrome uses CRLsets rather than the full CRL issued by = the CA. CA certificates with MD2/MD5 signatures have been untrusted. I also= expect to see CAs with 1024-bit RSA keys to be untrusted in some browsers = in the next year. In other words, the WG should consider a much more realistic draft. Otherwi= se, a reader might think that the WG's eventual RFC describes something ope= rationally useful. --Paul Hoffman _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops --_000_452C99D20750E74083DBA441FF9323857BFCBB43SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just wanted to say that the approach to the Tru= st Model document was to show how the actions of the browser and the CA pro= vide trust between the subscriber and the relying party. A basic model was = shown and then some variants. The reason was to show the reality out there that may help people understand t= he realities and develop better policies. For instance, many people did not= understand the issues of a CA issuing a CA certificate.  This was not= discussed in browser policies and not referenced in WebTrust 1.0. However, when DigiNotar and Digicert Malaysia = were blacklisted, this reality had to be accounted for.

 

Some general comments on this approach would be u= seful.

 

I have also provided some responses to Paul’= ;s comments below.

 

Thanks, Bruce.

 

-----Original Message-----
From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Paul Hoffman
Sent: Monday, June 24, 2013 6:56 PM
To: Sharon Boeyen
Cc: wpkops WG (wpkops@ietf.org)
Subject: Re: [wpkops] Silence is deafening - Trust Model Paper

 

The model in draft draft-webpki-trustmodel does n= ot match the charter for this WG. It over-reaches by talking about "ce= rtificate-using clients" that are not web browsers.

[Bruce Morton] = Sorry if this is outside the charter. We might want to consider opening up = the charter just a little bit as the relying parties might be using somethi= ng other than a browser. This might be opening up more and more in the mobile world.=

 

Even if the document is more narrowly scoped to m= eet the charter, it still has many problems. It blithely assumes that all C= As follow their certificate policies (which we have seen is not true), and = states that such certificate polices are "accepted" by client suppliers, which is only true if "= accepted" means "without any real checking, and generally without= any punishment after lapses are found".

[Bruce Morton] =  I think the CAs would concur that a CP and/or CPS is developed based = on the requirements from the OS/browser developers. Most CAs have a policy = authority to define policy. They may have internal auditors to ensure they are meeting policy and they are annually = audited to show compliance to their policies. There are cases where a CA do= es not meet their policy. There are also cases where the policy is incorrec= t. In general all CAs endeavor to meet their policies and put corrective action in place where a mistake has= been made.

 

The draft also says that "the relying party = implicitly accepts" the root store without discussing what this implic= it acceptance means. There is no discussion of what user expectations might= be (such as surprise that governments can cause certificates issued for sites of enemy governments).

[Bruce Morton] = I agree that Relying Party is an issue which is why the word implicit is us= ed. In reality, the Relying Party uses a browser and may respond to a trust= dialogue if it appears.

 

The WG should consider instead requiring the draf= t apply to the real-world Web PKI where browsers makers do not hold CAs acc= ountable when lapses are found and users do not understand anything about t= he role of the root store.

[Bruce Morton] = We have seen that OS/browsers do hold CAs accountable. In the past we have = seen that DigiNotar and Digicert Malaysia CA certificates have been blackli= sted. The browsers also take other actions is counteract the actions of the CAs. Microsoft has rejected all certifica= tes with keys less than 1024-bit RSA. Chrome uses CRLsets rather than the f= ull CRL issued by the CA. CA certificates with MD2/MD5 signatures have been= untrusted. I also expect to see CAs with 1024-bit RSA keys to be untrusted in some browsers in the next ye= ar.

 

In other words, the WG should consider a much mor= e realistic draft. Otherwise, a reader might think that the WG's eventual R= FC describes something operationally useful.

 

--Paul Hoffman

_______________________________________________

wpkops mailing list

wpkops@ietf.org

https://www.i= etf.org/mailman/listinfo/wpkops

--_000_452C99D20750E74083DBA441FF9323857BFCBB43SOTTEXCH10corpa_-- From paul.hoffman@vpnc.org Mon Jun 24 21:02:42 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3BD21E8095 for ; Mon, 24 Jun 2013 21:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAbSn1vtrENB for ; Mon, 24 Jun 2013 21:02:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ED55721E8094 for ; Mon, 24 Jun 2013 21:02:40 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5P42bnw000102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 21:02:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> Date: Mon, 24 Jun 2013 20:56:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> To: Bruce Morton X-Mailer: Apple Mail (2.1508) Cc: "wpkops WG \(wpkops@ietf.org\)" Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 04:02:42 -0000 On Jun 24, 2013, at 7:09 PM, Bruce Morton = wrote: > The model in draft draft-webpki-trustmodel does not match the charter = for this WG. It over-reaches by talking about "certificate-using = clients" that are not web browsers. > [Bruce Morton] Sorry if this is outside the charter. We might want to = consider opening up the charter just a little bit as the relying parties = might be using something other than a browser. This might be opening up = more and more in the mobile world. Stopping our work and revisiting the charter discussion is certainly a = possibility. It seems like a bad idea to me, but others might like it. > Even if the document is more narrowly scoped to meet the charter, it = still has many problems. It blithely assumes that all CAs follow their = certificate policies (which we have seen is not true), and states that = such certificate polices are "accepted" by client suppliers, which is = only true if "accepted" means "without any real checking, and generally = without any punishment after lapses are found". > [Bruce Morton] I think the CAs would concur that a CP and/or CPS is = developed based on the requirements from the OS/browser developers. This WG is supposed to be documenting "how the Web PKI actually works in = the set of browsers and servers that are in common use today", not on = what CAs would concur about. Your document seems to be about the latter. = Maybe we should stop work and recharter to change the focus of the WG to = be what CAs would concur about; if the charter changes to that, I = suspect a good percentage of the few people who wanted to participate in = the WG would walk away; I certainly would. > Most CAs have a policy authority to define policy. They may have = internal auditors to ensure they are meeting policy and they are = annually audited to show compliance to their policies. There are cases = where a CA does not meet their policy. There are also cases where the = policy is incorrect. And what is the operational effect of the latter two? *That's* much more = germane to "how the Web PKI actually works in the set of browsers and = servers that are in common use today". > In general all CAs endeavor to meet their policies and put corrective = action in place where a mistake has been made. How can that statement be measured? Is there a public repository of CA = mistakes (not just those discovered by the public) and the corrective = action that took place? If so, great; if not, such assurances have = little do with ho the Web PKI actually works. > The draft also says that "the relying party implicitly accepts" the = root store without discussing what this implicit acceptance means. There = is no discussion of what user expectations might be (such as surprise = that governments can cause certificates issued for sites of enemy = governments). > [Bruce Morton] I agree that Relying Party is an issue which is why the = word implicit is used. In reality, the Relying Party uses a browser and = may respond to a trust dialogue if it appears. None of the browsers that I am familiar with display a dialog that says = "The certificate for the site you are visiting, www.cia.gov, is issued = by a CA that is generally believed to be controlled by the government of = . Sound good to you?" The = trust model allows such issuance; the "implicitly accepts" needs to deal = with that, not with dialog boxes that a browser *could* show be never = does in this reality. > The WG should consider instead requiring the draft apply to the = real-world Web PKI where browsers makers do not hold CAs accountable = when lapses are found and users do not understand anything about the = role of the root store. > [Bruce Morton] We have seen that OS/browsers do hold CAs accountable. It seems you forgot the word "sometimes" in there. > In the past we have seen that DigiNotar and Digicert Malaysia CA = certificates have been blacklisted. ...but not some CAs that were found to have defective oversight of = subordinate CAs, for example. > The browsers also take other actions is counteract the actions of the = CAs. Microsoft has rejected all certificates with keys less than = 1024-bit RSA. That is not a lapse on Microsoft's part, it is an explicit policy. > Chrome uses CRLsets rather than the full CRL issued by the CA. That's unrelated to lapses, yes? > CA certificates with MD2/MD5 signatures have been untrusted. How on earth is that considered a "lapse"? > I also expect to see CAs with 1024-bit RSA keys to be untrusted in = some browsers in the next year. Again: that's a policy, not a lapse. In summary, it really doesn't feel like this draft meets the current = charter. If folks want to have a recharter discussion, fine, but maybe = it would be better to ask the editor to stick to the current charter. --Paul Hoffman From sharon.boeyen@entrust.com Tue Jun 25 04:30:42 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AED821F9EEE for ; Tue, 25 Jun 2013 04:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbXlrqawxf3x for ; Tue, 25 Jun 2013 04:30:37 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 13FB421F9E56 for ; Tue, 25 Jun 2013 04:30:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,936,1363147200"; d="scan'208,217";a="6072322" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 25 Jun 2013 07:30:31 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 07:30:30 -0400 From: Sharon Boeyen To: "wpkops WG (wpkops@ietf.org)" Thread-Topic: No meeting of wpkops at Berlin IETF Thread-Index: Ac5xl2WSs3aBK3M0Sf2OvPWlHPCbsQ== Date: Tue, 25 Jun 2013 11:30:30 +0000 Message-ID: <65DA4BEA501AFC409DF274CC71ED01A57C69E83D@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.161.12] Content-Type: multipart/alternative; boundary="_000_65DA4BEA501AFC409DF274CC71ED01A57C69E83DSOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] No meeting of wpkops at Berlin IETF X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:30:42 -0000 --_000_65DA4BEA501AFC409DF274CC71ED01A57C69E83DSOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jeremy and I have received zero requests for agenda items for a Berlin meet= ing. As a result there will be no face-to-face meeting of wpkops at IETF 87= in Berlin. It is possible that our cancellation request may not get through before the= preliminary agenda for IETF 87 is published Thursday. If that agenda does = include a time slot for wpkops, please ignore it as there will be no meetin= g. Cheers, Sharon --_000_65DA4BEA501AFC409DF274CC71ED01A57C69E83DSOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeremy and I have received zero requests for agenda = items for a Berlin meeting. As a result there will be no face-to-face meeti= ng of wpkops at IETF 87 in Berlin.

 

It is possible that our cancellation request may not= get through before the preliminary agenda for IETF 87 is published Thursda= y. If that agenda does include a time slot for wpkops, please ignore it as = there will be no meeting.

 

Cheers,

Sharon

--_000_65DA4BEA501AFC409DF274CC71ED01A57C69E83DSOTTEXCH10corpa_-- From bergtau@gmail.com Tue Jun 25 09:34:54 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC7221E80A7 for ; Tue, 25 Jun 2013 09:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzR7ysSnqc1g for ; Tue, 25 Jun 2013 09:34:52 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AD79421E80A3 for ; Tue, 25 Jun 2013 09:34:49 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id jw11so10316869veb.18 for ; Tue, 25 Jun 2013 09:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Jll0kb9jdj3ld7mI4G5fPjUQ1R4EqshRGl2SyaUjj80=; b=NjfBJMijlWyObcTrJuCdTqDOy7ostTh3l5l49kGsgieLsDxGfoLYm8rfko7pb4DjhF hWz2wxYbUGVLTPQPuorAeY4yHM0QgnFnJniyh8eocZyd6WSpcxciMYYg003+uKPfWqPb TpSW2CU9pxMgX5wl6hBubSqW8rwW6RmO3XM/4pSAi64aX15xTIdL55x63EFfMttrg7uA 03B8gN/QfF11b7SzEElPyM6e1AENIxqt/uh/6FNIDcXnyTQmlkzDzjnSuSAPkpKxkX5w nJJCOb3kX7A3pQFrQOUz0aUFEQJW+eINdxTTKTvhYBJAJJHbgQLJq+iM2eLVcDHqU8+1 uP0g== MIME-Version: 1.0 X-Received: by 10.220.142.210 with SMTP id r18mr14307563vcu.5.1372178087943; Tue, 25 Jun 2013 09:34:47 -0700 (PDT) Received: by 10.58.165.8 with HTTP; Tue, 25 Jun 2013 09:34:47 -0700 (PDT) In-Reply-To: <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> Date: Tue, 25 Jun 2013 12:34:47 -0400 Message-ID: From: Michael Jenkins To: "wpkops WG (wpkops@ietf.org)" Content-Type: multipart/alternative; boundary=047d7b343f348022a704dffd1b38 Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:34:54 -0000 --047d7b343f348022a704dffd1b38 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To cut Bruce ein bi=DFchen of slack :) he's writing about the trust model, not an observation of all the wonderful and glorious ways PKI has failed. Models don't necessarily reflect reality, so I don't think this paper needs to document how elements have failed to meet the model /as part of the model/. It just needs to extract from current operation where trust relationships exist. So I agree with Paul, mostly: the trust model paper should talk about browsers explicitly and solely, and how they store and use certificates for SSL specifically. It should describe the CA and its CP/CPS, how the auditor is supposed to use it, how the browser-vendor/trust-store-manager is supposed to use it. It should probably leave the browser-operator out of the trust model, because the indications presented to the browser-operator are disconnected from certificate processing. The paper should not go halves, trying to put what's out there in the context of traditional concepts of PKI. Anticipating a comment, I use "is supposed to" rather than "should". Since we're describing a model, that's appropriate. If you're going to "work to improve the consistency of web security behavior", then you've got to have a target. Substitute "could effectively" if you prefer. I also think the paper could describe the ways the model doesn't support security or inspire trust. Browser-vendors do vet CAs for entry into trust-stores, and do react to catastrophic failures, but don't have an on-going role in CA accountability. Auditors do inspect CA operations, but serve a guidance role, are in the employ of the CA itself, and the audit report is private. These things are inherent to the model, and are problems. The gaps created by PKI elements not supporting or actually subverting trust by violating the model don't really belong in the paper unless the paper increases in scope. I think those issues would still fit within the charter, but go beyond describing a model. On Mon, Jun 24, 2013 at 11:56 PM, Paul Hoffman wrote= : > On Jun 24, 2013, at 7:09 PM, Bruce Morton > wrote: > > > The model in draft draft-webpki-trustmodel does not match the charter > for this WG. It over-reaches by talking about "certificate-using clients" > that are not web browsers. > > [Bruce Morton] Sorry if this is outside the charter. We might want to > consider opening up the charter just a little bit as the relying parties > might be using something other than a browser. This might be opening up > more and more in the mobile world. > > Stopping our work and revisiting the charter discussion is certainly a > possibility. It seems like a bad idea to me, but others might like it. > > > Even if the document is more narrowly scoped to meet the charter, it > still has many problems. It blithely assumes that all CAs follow their > certificate policies (which we have seen is not true), and states that su= ch > certificate polices are "accepted" by client suppliers, which is only tru= e > if "accepted" means "without any real checking, and generally without any > punishment after lapses are found". > > [Bruce Morton] I think the CAs would concur that a CP and/or CPS is > developed based on the requirements from the OS/browser developers. > > This WG is supposed to be documenting "how the Web PKI actually works in > the set of browsers and servers that are in common use today", not on wha= t > CAs would concur about. Your document seems to be about the latter. Maybe > we should stop work and recharter to change the focus of the WG to be wha= t > CAs would concur about; if the charter changes to that, I suspect a good > percentage of the few people who wanted to participate in the WG would wa= lk > away; I certainly would. > > > Most CAs have a policy authority to define policy. They may have > internal auditors to ensure they are meeting policy and they are annually > audited to show compliance to their policies. There are cases where a CA > does not meet their policy. There are also cases where the policy is > incorrect. > > And what is the operational effect of the latter two? *That's* much more > germane to "how the Web PKI actually works in the set of browsers and > servers that are in common use today". > > > In general all CAs endeavor to meet their policies and put corrective > action in place where a mistake has been made. > > How can that statement be measured? Is there a public repository of CA > mistakes (not just those discovered by the public) and the corrective > action that took place? If so, great; if not, such assurances have little > do with ho the Web PKI actually works. > > > The draft also says that "the relying party implicitly accepts" the > root store without discussing what this implicit acceptance means. There = is > no discussion of what user expectations might be (such as surprise that > governments can cause certificates issued for sites of enemy governments)= . > > [Bruce Morton] I agree that Relying Party is an issue which is why the > word implicit is used. In reality, the Relying Party uses a browser and m= ay > respond to a trust dialogue if it appears. > > None of the browsers that I am familiar with display a dialog that says > "The certificate for the site you are visiting, www.cia.gov, is issued by > a CA that is generally believed to be controlled by the government of > . Sound good to you?" The trust > model allows such issuance; the "implicitly accepts" needs to deal with > that, not with dialog boxes that a browser *could* show be never does in > this reality. > > > The WG should consider instead requiring the draft apply to the > real-world Web PKI where browsers makers do not hold CAs accountable when > lapses are found and users do not understand anything about the role of t= he > root store. > > [Bruce Morton] We have seen that OS/browsers do hold CAs accountable. > > It seems you forgot the word "sometimes" in there. > > > In the past we have seen that DigiNotar and Digicert Malaysia CA > certificates have been blacklisted. > > ...but not some CAs that were found to have defective oversight of > subordinate CAs, for example. > > > The browsers also take other actions is counteract the actions of the > CAs. Microsoft has rejected all certificates with keys less than 1024-bit > RSA. > > That is not a lapse on Microsoft's part, it is an explicit policy. > > > Chrome uses CRLsets rather than the full CRL issued by the CA. > > That's unrelated to lapses, yes? > > > CA certificates with MD2/MD5 signatures have been untrusted. > > How on earth is that considered a "lapse"? > > > I also expect to see CAs with 1024-bit RSA keys to be untrusted in some > browsers in the next year. > > Again: that's a policy, not a lapse. > > In summary, it really doesn't feel like this draft meets the current > charter. If folks want to have a recharter discussion, fine, but maybe it > would be better to ask the editor to stick to the current charter. > > --Paul Hoffman > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > --047d7b343f348022a704dffd1b38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To cut Bruce ein bi=DFchen of slack :) he's writing ab= out the trust model, not an observation of all the wonderful and glorious ways PKI has=20 failed. Models don't necessarily reflect reality, so I don't think = this=20 paper needs to document how elements have failed to meet the model /as=20 part of the model/. It just needs to extract from current operation=20 where trust relationships exist.

So I agree with Paul, mostly: the trust model paper=20 should talk about browsers explicitly and solely, and how they store and use certificates for SSL specifically. It should describe the CA and=20 its CP/CPS, how the auditor is supposed to use it, how the=20 browser-vendor/trust-store-manager is supposed to use it. It should probably leave the browser-operator out of the trust model, because the indications presented to the browser-operator are disconnected from=20 certificate processing. The paper should not go halves, trying to put=20 what's out there in the context of traditional concepts of PKI.

Anticipating a comment, I use "is supposed to"= ;=20 rather than "should". Since we're describing a model, that= 9;s=20 appropriate. If you're going to "work to improve the consistency o= f web=20 security behavior", then you've got to have a target. Substitute &= quot;could=20 effectively" if you prefer.

I also think the paper could describe the ways the=20 model doesn't support security or inspire trust. Browser-vendors do vet= =20 CAs for entry into trust-stores, and do react to catastrophic failures,=20 but don't have an on-going role in CA accountability. Auditors do=20 inspect CA operations, but serve a guidance role, are in the employ of=20 the CA itself, and the audit report is private. These things are=20 inherent to the model, and are problems.=A0

The gaps created by PKI elements not supporting or=20 actually subverting trust by violating the model don't really belong in= =20 the paper unless the paper increases in scope. I think those issues=20 would still fit within the charter, but go beyond describing a model.
=


On Mon,= Jun 24, 2013 at 11:56 PM, Paul Hoffman <paul.hoffman@vpnc.org>= wrote:
On Jun 24, 2013, at 7:09 P= M, Bruce Morton <bruce.morto= n@entrust.com> wrote:

> The model in draft draft-webpki-trustmodel does not match the charter = for this WG. It over-reaches by talking about "certificate-using clien= ts" that are not web browsers.
> [Bruce Morton] Sorry if this is outside the charter. We might want to = consider opening up the charter just a little bit as the relying parties mi= ght be using something other than a browser. This might be opening up more = and more in the mobile world.

Stopping our work and revisiting the charter discussion is certainly = a possibility. It seems like a bad idea to me, but others might like it.

> Even if the document is more narrowly scoped to meet the charter, it s= till has many problems. It blithely assumes that all CAs follow their certi= ficate policies (which we have seen is not true), and states that such cert= ificate polices are "accepted" by client suppliers, which is only= true if "accepted" means "without any real checking, and ge= nerally without any punishment after lapses are found".
> [Bruce Morton] =A0I think the CAs would concur that a CP and/or CPS is= developed based on the requirements from the OS/browser developers.

This WG is supposed to be documenting "how the Web PKI actually = works in the set of browsers and servers that are in common use today"= , not on what CAs would concur about. Your document seems to be about the l= atter. Maybe we should stop work and recharter to change the focus of the W= G to be what CAs would concur about; if the charter changes to that, I susp= ect a good percentage of the few people who wanted to participate in the WG= would walk away; I certainly would.

> Most CAs have a policy authority to define policy. They may have inter= nal auditors to ensure they are meeting policy and they are annually audite= d to show compliance to their policies. There are cases where a CA does not= meet their policy. There are also cases where the policy is incorrect.

And what is the operational effect of the latter two? *That's* mu= ch more germane to "how the Web PKI actually works in the set of brows= ers and servers that are in common use today".

> In general all CAs endeavor to meet their policies and put corrective = action in place where a mistake has been made.

How can that statement be measured? Is there a public repository of C= A mistakes (not just those discovered by the public) and the corrective act= ion that took place? If so, great; if not, such assurances have little do w= ith ho the Web PKI actually works.

> =A0The draft also says that "the relying party implicitly accepts= " the root store without discussing what this implicit acceptance mean= s. There is no discussion of what user expectations might be (such as surpr= ise that governments can cause certificates issued for sites of enemy gover= nments).
> [Bruce Morton] I agree that Relying Party is an issue which is why the= word implicit is used. In reality, the Relying Party uses a browser and ma= y respond to a trust dialogue if it appears.

None of the browsers that I am familiar with display a dialog that sa= ys "The certificate for the site you are visiting, www.cia.gov, is issued by a CA that is ge= nerally believed to be controlled by the government of <country sometime= s unfriendly with the US>. Sound good to you?" The trust model allo= ws such issuance; the "implicitly accepts" needs to deal with tha= t, not with dialog boxes that a browser *could* show be never does in this = reality.

> The WG should consider instead requiring the draft apply to the real-w= orld Web PKI where browsers makers do not hold CAs accountable when lapses = are found and users do not understand anything about the role of the root s= tore.
> [Bruce Morton] We have seen that OS/browsers do hold CAs accountable.<= br>
It seems you forgot the word "sometimes" in there.

> In the past we have seen that DigiNotar and Digicert Malaysia CA certi= ficates have been blacklisted.

...but not some CAs that were found to have defective oversight of su= bordinate CAs, for example.

> The browsers also take other actions is counteract the actions of the = CAs. Microsoft has rejected all certificates with keys less than 1024-bit R= SA.

That is not a lapse on Microsoft's part, it is an explicit policy= .

> Chrome uses CRLsets rather than the full CRL issued by the CA.

That's unrelated to lapses, yes?

> CA certificates with MD2/MD5 signatures have been untrusted.

How on earth is that considered a "lapse"?

> I also expect to see CAs with 1024-bit RSA keys to be untrusted in som= e browsers in the next year.

Again: that's a policy, not a lapse.

In summary, it really doesn't feel like this draft meets the current ch= arter. If folks want to have a recharter discussion, fine, but maybe it wou= ld be better to ask the editor to stick to the current charter.

--Paul Hoffman

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

--047d7b343f348022a704dffd1b38-- From paul.hoffman@vpnc.org Tue Jun 25 10:06:44 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB83E21F9E02 for ; Tue, 25 Jun 2013 10:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-nLBbeqnR2y for ; Tue, 25 Jun 2013 10:06:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD5EA21F9D3B for ; Tue, 25 Jun 2013 10:06:43 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5PH6dHG030150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 10:06:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 25 Jun 2013 10:06:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10A7683E-4034-4779-B891-78803D5953ED@vpnc.org> References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> To: Michael Jenkins X-Mailer: Apple Mail (2.1508) Cc: "wpkops WG \(wpkops@ietf.org\)" Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:06:44 -0000 On Jun 25, 2013, at 9:34 AM, Michael Jenkins wrote: > I also think the paper could describe the ways the model doesn't = support security or inspire trust. Browser-vendors do vet CAs for entry = into trust-stores, and do react to catastrophic failures, but don't have = an on-going role in CA accountability. Auditors do inspect CA = operations, but serve a guidance role, are in the employ of the CA = itself, and the audit report is private. These things are inherent to = the model, and are problems.=20 Adding these would go a long way towards making the document meet the = requirements. A "model" section followed by a "operational reality" = section seems reasonable. I was probably unclear in my earlier messages = on this thread, making it seem like I wanted to mix the two. > The gaps created by PKI elements not supporting or actually subverting = trust by violating the model don't really belong in the paper unless the = paper increases in scope. I think those issues would still fit within = the charter, but go beyond describing a model. My hope is that the document increases in scope to match the top part of = the charter. Knowing only the model doesn't help an operator; talking = about the model and the operational realities does. --Paul Hoffman= From kent@bbn.com Tue Jun 25 10:24:30 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CB621E80C4 for ; Tue, 25 Jun 2013 10:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.3 X-Spam-Level: X-Spam-Status: No, score=-105.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymb8QmIBHWar for ; Tue, 25 Jun 2013 10:24:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 594EB21E80BD for ; Tue, 25 Jun 2013 10:24:01 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50514) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UrWyF-000GjT-F1; Tue, 25 Jun 2013 13:23:59 -0400 Message-ID: <51C9D230.4060300@bbn.com> Date: Tue, 25 Jun 2013 13:24:00 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: bergtau@gmail.com References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:24:30 -0000 Michael, I agree with Paul's observations. The charter for the WG is intentionally narrow. If folks decide to revise it to be broader, there is no guarantee that a new, broader charter will be approved. With that in mind, the trust model doc needs a LOT of work. Phrases like "is supposed to" may be appropriate, but they ought not figure prominently, as the goal here is to document how browsers and the public TA/CA really work. Steve From joelja@bogus.com Tue Jun 25 10:35:58 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9F021F9B91 for ; Tue, 25 Jun 2013 10:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ll-OTY+-rqN for ; Tue, 25 Jun 2013 10:35:58 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2F021F9B76 for ; Tue, 25 Jun 2013 10:35:57 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r5PHZoYH053097 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 25 Jun 2013 17:35:50 GMT (envelope-from joelja@bogus.com) Message-ID: <51C9D4F1.8080905@bogus.com> Date: Tue, 25 Jun 2013 10:35:45 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Stephen Kent , wpkops WG References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <51C9D230.4060300@bbn.com> In-Reply-To: <51C9D230.4060300@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 25 Jun 2013 17:35:50 +0000 (UTC) Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 17:35:59 -0000 I came on as AD right after this WG was chartered effectively. If we seriously consider rechartering at this point we're basically declaring the original a failure, which is fine I guess, but I think the IESG is going to turn a pretty jaundiced eye on that. If something truly does not fit under our charter it might well advance as individual submission (I'd have to consider that), socialize it through and bring it up through opsawg or other alternatives. imho it's premature to really explore this. On 6/25/13 10:24 AM, Stephen Kent wrote: > Michael, > > I agree with Paul's observations. The charter for the WG is > intentionally narrow. > If folks decide to revise it to be broader, there is no guarantee that > a new, broader > charter will be approved. With that in mind, the trust model doc needs > a LOT of work. > Phrases like "is supposed to" may be appropriate, but they ought not > figure prominently, > as the goal here is to document how browsers and the public TA/CA > really work. > > Steve > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From ynir@checkpoint.com Tue Jun 25 22:22:54 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C7711E819B for ; Tue, 25 Jun 2013 22:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAsHGdDd8E+v for ; Tue, 25 Jun 2013 22:22:48 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EF82721E8053 for ; Tue, 25 Jun 2013 22:22:46 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5Q5MYNQ017051; Wed, 26 Jun 2013 08:22:42 +0300 X-CheckPoint: {51CA7A9A-4-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 08:22:34 +0300 From: Yoav Nir To: joel jaeggli Thread-Topic: [wpkops] Silence is deafening - Trust Model Paper Thread-Index: Ac5w+ZSoQsntgfnhSwGtPfDMuxnBDwAG044AAAa7noAAA8QbgAAaeCeAAAG4CAAAAGkOgAAYr0mA Date: Wed, 26 Jun 2013 05:22:34 +0000 Message-ID: <4304DE38-B450-407E-B019-81DC5EC7E87E@checkpoint.com> References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <51C9D230.4060300@bbn.com> <51C9D4F1.8080905@bogus.com> In-Reply-To: <51C9D4F1.8080905@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.240] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 110a02b78978acab90d32daa82b7af9e92d9898b19 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: wpkops WG Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 05:22:54 -0000 There is some weirdness in the charter, in that on the one had it is about = documenting real-world behavior ('The working group's goal is to describe h= ow the Web PKI "actually" works in the set of browsers and servers that are= in common use today.'), and on the other hand the charter explicitly calls= for documenting trust models. I took this to mean that each participant in the web PKI (CA, server admini= strator, server developer, browser developer, and browser user) has a menta= l model of how the whole thing works, and that model guides their actions. = For example, the browser user might believe that CAs are supposed to (and u= nlike Steve, I believe that is a good phrase to use here) verify domain nam= es before issuing certificates. So if a server presents a certificate that = says "C=3DUS,ST=3DWA,L=3DRedmond,O=3DMicrosoft Corporation,OU=3DMSCOM,CN=3D= www.microsoft.com", that means that this server is really controlled by Mic= rosoft. This guides their actions, in that when they want to reach Microsof= t's website, they'll type "https://www.microsoft.com" and if the padlock ap= pears, they can trust that this is actually Microsoft. People more versed in protocols will have a more complex model in mind, one= that involves the DNS (which pointed the browser at the server), the whois= database, registrars, CAs, and email verification. But everyone has some i= dea in their head about what this WebPKI means, and this informs their acti= ons. It's a real-world mental model and some real-world actions. I think it= 's well worth it to document this model (although I'm not sure where we cou= ld reliably get this information - we're not distributing questionnaires an= d conducting in-depth interviews with end-users, right?). I also think that= the current charter covers this. Yoav On Jun 25, 2013, at 8:35 PM, joel jaeggli wrote: > I came on as AD right after this WG was chartered effectively. >=20 > If we seriously consider rechartering at this point we're basically decla= ring the original a failure, which is fine I guess, but I think the IESG is= going to turn a pretty jaundiced eye on that. >=20 > If something truly does not fit under our charter it might well advance a= s individual submission (I'd have to consider that), socialize it through a= nd bring it up through opsawg or other alternatives. imho it's premature to= really explore this. >=20 > On 6/25/13 10:24 AM, Stephen Kent wrote: >> Michael, >>=20 >> I agree with Paul's observations. The charter for the WG is intentionall= y narrow. >> If folks decide to revise it to be broader, there is no guarantee that a= new, broader >> charter will be approved. With that in mind, the trust model doc needs a= LOT of work. >> Phrases like "is supposed to" may be appropriate, but they ought not fig= ure prominently, >> as the goal here is to document how browsers and the public TA/CA really= work. >>=20 >> Steve From i-barreira@izenpe.net Wed Jun 26 03:34:45 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4E221E8130 for ; Wed, 26 Jun 2013 03:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPrEPbxVMoFC for ; Wed, 26 Jun 2013 03:34:41 -0700 (PDT) Received: from correo.euskaltel.es (ektmail2mta2.euskaltel.es [212.55.8.119]) by ietfa.amsl.com (Postfix) with ESMTP id 60A5D11E80D1 for ; Wed, 26 Jun 2013 03:34:39 -0700 (PDT) Received: from ejlp024.ejgv ([194.30.48.247]) by ektmail2mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MOZ00DG2XDPYR80@ektmail2mta2.euskaltel.es> for wpkops@ietf.org; Wed, 26 Jun 2013 12:34:37 +0200 (MEST) Received: from AFE03.ejsarea.net (afe03 [10.200.192.20]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id r5QAYbRu030509; Wed, 26 Jun 2013 12:34:37 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by AFE03.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jun 2013 12:34:37 +0200 Date: Wed, 26 Jun 2013 12:34:36 +0200 From: i-barreira@izenpe.net In-reply-to: To: bergtau@gmail.com, wpkops@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/related; boundary="Boundary_(ID_x14LavIeq48ICurSC4nfyQ)"; type="multipart/alternative" Content-class: urn:content-classes:message Thread-topic: [wpkops] Silence is deafening - Trust Model Paper Thread-index: Ac5xwfC8E37TEXErRzS7KpqqSMk2QAAk0nfQ X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> X-OriginalArrivalTime: 26 Jun 2013 10:34:37.0031 (UTC) FILETIME=[C18DD770:01CE7258] Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:34:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_x14LavIeq48ICurSC4nfyQ) Content-type: multipart/alternative; boundary="Boundary_(ID_s6IK9r7ZcTfbEhZlgG8YSQ)" --Boundary_(ID_s6IK9r7ZcTfbEhZlgG8YSQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi all, =20 A new draft has been posted for you to check. It includes some new = definitions regarding browsers and CAs policies, and some other = contributions. =20 Regarding what Michael and Paul are saying, I=B4m disagree. The trust = models in the web PKI are not only browsers and are not only related to = SSL certificates, this is a widely assumption that it=B4s not true at = all. For example, in the EU there=B4s a so called Trust Service Status List = (commonly called TSL) which is another trust store managed by every EU = member state and regulated by law in which there=B4s a list with all CAs = (and issuing CAs and services) that fulfill the requirements imposed by = law that follow some ETSI standards. This is mandate for all the CAs = offering qualified certificates but it=B4s also possible for non = qualified certs, like SSL. This is also web PKI because these services = are consumed thru web services for example on a machine readable process = or thru a web site for human readable process. There are browsers like Microsoft and other RP like Adobe that are = thinking on using these TSLs to adapt their root stores and not doing = that job, they will rely on what the EU has implemented and managed by = law. Other example could be all the services that can be used with a = qualified certificate issued in a SSCD (smartcard or USB token, we can = leave HSM apart) in a web client. =20 So, in my opinion, the web PKI is more than browsers (and their = policies) and SSL certificates. CAs are actually (and this is what this = is about, to explain what is out there today) a key factor in this = because they feed up the browsers with their certs. The browsers have = their policies to indicate what they request the CAs to be admitted = (mainly to be audited with some standards, ETSI or Webtrust) and the CAs = have their own policies to indicate how they produce those certs and = according to the same standards that are going to be used to be audited = and presented to the browsers. So I think that in this trust model = document, the trust is between the CAs and the browsers, not just the = browsers imposing something to the CAs. And both have to be presented. =20 =20 OTOH I=B4m agree that a rewording to meet these suggestions shall be = included and as I see these are focused on auditing (which is already = included), vetting, security measures, etc. but are these necessary to = explain in depth? After this first draft on trust model some other are = coming to meet also these ones. =20 regards =20 =20 I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 =20 =20 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. =20 De: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] En nombre = de Michael Jenkins Enviado el: martes, 25 de junio de 2013 18:35 Para: wpkops WG (wpkops@ietf.org) Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper =20 To cut Bruce ein bi=DFchen of slack :) he's writing about the trust = model, not an observation of all the wonderful and glorious ways PKI has = failed. Models don't necessarily reflect reality, so I don't think this = paper needs to document how elements have failed to meet the model /as = part of the model/. It just needs to extract from current operation = where trust relationships exist. =20 So I agree with Paul, mostly: the trust model paper should talk about = browsers explicitly and solely, and how they store and use certificates = for SSL specifically. It should describe the CA and its CP/CPS, how the = auditor is supposed to use it, how the = browser-vendor/trust-store-manager is supposed to use it. It should = probably leave the browser-operator out of the trust model, because the = indications presented to the browser-operator are disconnected from = certificate processing. The paper should not go halves, trying to put = what's out there in the context of traditional concepts of PKI. =20 Anticipating a comment, I use "is supposed to" rather than "should". = Since we're describing a model, that's appropriate. If you're going to = "work to improve the consistency of web security behavior", then you've = got to have a target. Substitute "could effectively" if you prefer. =20 I also think the paper could describe the ways the model doesn't support = security or inspire trust. Browser-vendors do vet CAs for entry into = trust-stores, and do react to catastrophic failures, but don't have an = on-going role in CA accountability. Auditors do inspect CA operations, = but serve a guidance role, are in the employ of the CA itself, and the = audit report is private. These things are inherent to the model, and are = problems.=20 =20 The gaps created by PKI elements not supporting or actually subverting = trust by violating the model don't really belong in the paper unless the = paper increases in scope. I think those issues would still fit within = the charter, but go beyond describing a model. =20 On Mon, Jun 24, 2013 at 11:56 PM, Paul Hoffman = wrote: On Jun 24, 2013, at 7:09 PM, Bruce Morton = wrote: > The model in draft draft-webpki-trustmodel does not match the charter = for this WG. It over-reaches by talking about "certificate-using = clients" that are not web browsers. > [Bruce Morton] Sorry if this is outside the charter. We might want to = consider opening up the charter just a little bit as the relying parties = might be using something other than a browser. This might be opening up = more and more in the mobile world. Stopping our work and revisiting the charter discussion is certainly a = possibility. It seems like a bad idea to me, but others might like it. > Even if the document is more narrowly scoped to meet the charter, it = still has many problems. It blithely assumes that all CAs follow their = certificate policies (which we have seen is not true), and states that = such certificate polices are "accepted" by client suppliers, which is = only true if "accepted" means "without any real checking, and generally = without any punishment after lapses are found". > [Bruce Morton] I think the CAs would concur that a CP and/or CPS is = developed based on the requirements from the OS/browser developers. This WG is supposed to be documenting "how the Web PKI actually works in = the set of browsers and servers that are in common use today", not on = what CAs would concur about. Your document seems to be about the latter. = Maybe we should stop work and recharter to change the focus of the WG to = be what CAs would concur about; if the charter changes to that, I = suspect a good percentage of the few people who wanted to participate in = the WG would walk away; I certainly would. > Most CAs have a policy authority to define policy. They may have = internal auditors to ensure they are meeting policy and they are = annually audited to show compliance to their policies. There are cases = where a CA does not meet their policy. There are also cases where the = policy is incorrect. And what is the operational effect of the latter two? *That's* much more = germane to "how the Web PKI actually works in the set of browsers and = servers that are in common use today". > In general all CAs endeavor to meet their policies and put corrective = action in place where a mistake has been made. How can that statement be measured? Is there a public repository of CA = mistakes (not just those discovered by the public) and the corrective = action that took place? If so, great; if not, such assurances have = little do with ho the Web PKI actually works. > The draft also says that "the relying party implicitly accepts" the = root store without discussing what this implicit acceptance means. There = is no discussion of what user expectations might be (such as surprise = that governments can cause certificates issued for sites of enemy = governments). > [Bruce Morton] I agree that Relying Party is an issue which is why the = word implicit is used. In reality, the Relying Party uses a browser and = may respond to a trust dialogue if it appears. None of the browsers that I am familiar with display a dialog that says = "The certificate for the site you are visiting, www.cia.gov, is issued = by a CA that is generally believed to be controlled by the government of = . Sound good to you?" The = trust model allows such issuance; the "implicitly accepts" needs to deal = with that, not with dialog boxes that a browser *could* show be never = does in this reality. > The WG should consider instead requiring the draft apply to the = real-world Web PKI where browsers makers do not hold CAs accountable = when lapses are found and users do not understand anything about the = role of the root store. > [Bruce Morton] We have seen that OS/browsers do hold CAs accountable. It seems you forgot the word "sometimes" in there. > In the past we have seen that DigiNotar and Digicert Malaysia CA = certificates have been blacklisted. ...but not some CAs that were found to have defective oversight of = subordinate CAs, for example. > The browsers also take other actions is counteract the actions of the = CAs. Microsoft has rejected all certificates with keys less than = 1024-bit RSA. That is not a lapse on Microsoft's part, it is an explicit policy. > Chrome uses CRLsets rather than the full CRL issued by the CA. That's unrelated to lapses, yes? > CA certificates with MD2/MD5 signatures have been untrusted. How on earth is that considered a "lapse"? > I also expect to see CAs with 1024-bit RSA keys to be untrusted in = some browsers in the next year. Again: that's a policy, not a lapse. In summary, it really doesn't feel like this draft meets the current = charter. If folks want to have a recharter discussion, fine, but maybe = it would be better to ask the editor to stick to the current charter. --Paul Hoffman _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops =20 --Boundary_(ID_s6IK9r7ZcTfbEhZlgG8YSQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi all,

 

A new draft has been posted for you to check. It includes some new = definitions regarding browsers and CAs policies, and some other = contributions.

 

Regarding what Michael and Paul are saying, I=B4m disagree. The trust = models in the web PKI are not only browsers and are not only related to = SSL certificates, this is a widely assumption that it=B4s not true at = all.

For example, in the EU there=B4s a so called Trust Service Status = List (commonly called TSL) which is another trust store managed by every = EU member state and regulated by law in which there=B4s a list with all = CAs (and issuing CAs and services) that fulfill the requirements imposed = by law that follow some ETSI standards. This is mandate for all the CAs = offering qualified certificates but it=B4s also possible for non = qualified certs, like SSL. This is also web PKI because these services = are consumed thru web services for example on a machine readable process = or thru a web site for human readable process.

There are browsers like Microsoft and other RP like Adobe that are = thinking on using these TSLs to adapt their root stores and not doing = that job, they will rely on what the EU has implemented and managed by = law.

Other example could be all the services that can be used with a = qualified certificate issued in a SSCD (smartcard or USB token, we can = leave HSM apart) in a web client.

 

So, in my opinion, the web PKI is more than browsers (and their = policies) and SSL certificates. CAs are actually (and this is what this = is about, to explain what is out there today) a key factor in this = because they feed up the browsers with their certs. The browsers have = their policies to indicate what they request the CAs to be admitted = (mainly to be audited with some standards, ETSI or Webtrust) and the CAs = have their own policies to indicate how they produce those certs and = according to the same standards that are going to be used to be audited = and presented to the browsers. So I think that in this trust model = document, the trust is between the CAs and the browsers, not just the = browsers imposing something to the CAs. And both have to be = presented.

 

 

OTOH I=B4m agree that a rewording to meet these suggestions shall be = included and as I see these are focused on auditing (which is already = included), vetting, security measures, etc. but are these necessary to = explain in depth? After this first draft on trust model some other are = coming to meet also these ones.

 

regards

 

 

I= =F1igo Barreira<= br>Responsable del =C1rea t=E9cnica
<= a = href=3D"mailto:i-barreira@izenpe.net">i-barreira@izenpe.net

9= 45067705

 

3D"Descripci=F3n:

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

 

De: = wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] En nombre de = Michael Jenkins
Enviado el: martes, 25 de junio de 2013 = 18:35
Para: wpkops WG (wpkops@ietf.org)
Asunto: Re: = [wpkops] Silence is deafening - Trust Model = Paper

 

To cut = Bruce ein bi=DFchen of slack :) he's writing about the trust model, not = an observation of all the wonderful and glorious ways PKI has failed. = Models don't necessarily reflect reality, so I don't think this paper = needs to document how elements have failed to meet the model /as part of = the model/. It just needs to extract from current operation where trust = relationships exist.

 

So I agree with Paul, mostly: the trust model paper = should talk about browsers explicitly and solely, and how they store and = use certificates for SSL specifically. It should describe the CA and its = CP/CPS, how the auditor is supposed to use it, how the = browser-vendor/trust-store-manager is supposed to use it. It should = probably leave the browser-operator out of the trust model, because the = indications presented to the browser-operator are disconnected from = certificate processing. The paper should not go halves, trying to put = what's out there in the context of traditional concepts of = PKI.

 

Anticipating a comment, I use "is supposed = to" rather than "should". Since we're describing a model, = that's appropriate. If you're going to "work to improve the = consistency of web security behavior", then you've got to have a = target. Substitute "could effectively" if you = prefer.

 

I = also think the paper could describe the ways the model doesn't support = security or inspire trust. Browser-vendors do vet CAs for entry into = trust-stores, and do react to catastrophic failures, but don't have an = on-going role in CA accountability. Auditors do inspect CA operations, = but serve a guidance role, are in the employ of the CA itself, and the = audit report is private. These things are inherent to the model, and are = problems. 

 

The gaps created by PKI elements not supporting or = actually subverting trust by violating the model don't really belong in = the paper unless the paper increases in scope. I think those issues = would still fit within the charter, but go beyond describing a = model.

 

On Mon, Jun 24, 2013 at 11:56 PM, Paul Hoffman <paul.hoffman@vpnc.org> = wrote:

On Jun 24, 2013, at 7:09 PM, Bruce Morton = <bruce.morton@entrust.com>= wrote:

> The model in draft draft-webpki-trustmodel does not = match the charter for this WG. It over-reaches by talking about = "certificate-using clients" that are not web browsers.
> = [Bruce Morton] Sorry if this is outside the charter. We might want to = consider opening up the charter just a little bit as the relying parties = might be using something other than a browser. This might be opening up = more and more in the mobile world.

Stopping our work and revisiting the charter = discussion is certainly a possibility. It seems like a bad idea to me, = but others might like it.


> Even if the document is more = narrowly scoped to meet the charter, it still has many problems. It = blithely assumes that all CAs follow their certificate policies (which = we have seen is not true), and states that such certificate polices are = "accepted" by client suppliers, which is only true if = "accepted" means "without any real checking, and = generally without any punishment after lapses are found".
> = [Bruce Morton]  I think the CAs would concur that a CP and/or CPS = is developed based on the requirements from the OS/browser = developers.

This WG is supposed = to be documenting "how the Web PKI actually works in the set of = browsers and servers that are in common use today", not on what CAs = would concur about. Your document seems to be about the latter. Maybe we = should stop work and recharter to change the focus of the WG to be what = CAs would concur about; if the charter changes to that, I suspect a good = percentage of the few people who wanted to participate in the WG would = walk away; I certainly would.


> Most CAs have a policy authority = to define policy. They may have internal auditors to ensure they are = meeting policy and they are annually audited to show compliance to their = policies. There are cases where a CA does not meet their policy. There = are also cases where the policy is incorrect.

And what is the operational effect of the latter two? = *That's* much more germane to "how the Web PKI actually works in = the set of browsers and servers that are in common use = today".


> In general all CAs endeavor to = meet their policies and put corrective action in place where a mistake = has been made.

How can that = statement be measured? Is there a public repository of CA mistakes (not = just those discovered by the public) and the corrective action that took = place? If so, great; if not, such assurances have little do with ho the = Web PKI actually works.


>  The draft also says that = "the relying party implicitly accepts" the root store without = discussing what this implicit acceptance means. There is no discussion = of what user expectations might be (such as surprise that governments = can cause certificates issued for sites of enemy governments).
> = [Bruce Morton] I agree that Relying Party is an issue which is why the = word implicit is used. In reality, the Relying Party uses a browser and = may respond to a trust dialogue if it appears.

None of the browsers that I am familiar with display a = dialog that says "The certificate for the site you are visiting, www.cia.gov, is issued = by a CA that is generally believed to be controlled by the government of = <country sometimes unfriendly with the US>. Sound good to = you?" The trust model allows such issuance; the "implicitly = accepts" needs to deal with that, not with dialog boxes that a = browser *could* show be never does in this = reality.


> The WG should consider instead = requiring the draft apply to the real-world Web PKI where browsers = makers do not hold CAs accountable when lapses are found and users do = not understand anything about the role of the root store.
> [Bruce = Morton] We have seen that OS/browsers do hold CAs = accountable.

It seems you = forgot the word "sometimes" in there.


> In the past we = have seen that DigiNotar and Digicert Malaysia CA certificates have been = blacklisted.

...but not some = CAs that were found to have defective oversight of subordinate CAs, for = example.


> The browsers also take other = actions is counteract the actions of the CAs. Microsoft has rejected all = certificates with keys less than 1024-bit RSA.

That is not a lapse on Microsoft's part, it is an = explicit policy.


> Chrome uses CRLsets rather than = the full CRL issued by the CA.

That's unrelated to lapses, yes?


> CA = certificates with MD2/MD5 signatures have been = untrusted.

How on earth is that = considered a "lapse"?


> I also expect to see CAs with = 1024-bit RSA keys to be untrusted in some browsers in the next = year.

Again: that's a policy, = not a lapse.

In summary, it really doesn't feel like this draft = meets the current charter. If folks want to have a recharter discussion, = fine, but maybe it would be better to ask the editor to stick to the = current charter.


--Paul = Hoffman

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

 

= --Boundary_(ID_s6IK9r7ZcTfbEhZlgG8YSQ)-- --Boundary_(ID_x14LavIeq48ICurSC4nfyQ) Content-id: Content-type: image/png; name=image001.png Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.png Content-description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAkkAAABvCAIAAAB3iMNhAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAASlZJREFUeF7tXQd4HNXVndned7XqvViSZcm9yLiC7RgwNtWAA0looSUhBUJI QjUtTk8I+UO3DQSMjQEbN9yrbElWsXrvva2k7bNl5j9vV5ZFM8Je2RDe++z9dmfmvXlzZjVn7333 nssKgsB8/eZEF55h3AwjYRgMgH9442IYOcNgH17x3r8Lh0m/ZBftNRIoigZFg/6l0OcGfYp+jlNY JyNXfG2WYkfDbV5e6Lc7KlsGdxY1HK5rKWjocnJ2xmxj5DKG9zAMyzAiRvAwUilj5xi1gnFyjFTG eD2MyLfL42FkUobjGKWCcXCMjPaiaNDvBv1Loc8N+jwcHTsYDXqFPD0uaGZs3NWzkiZFG0PVCrFI dHa6+2puy2vo3phTtvFkZVePOUynzkgwZiYnxwWLtHIDy/JiMetyE8tPLmPdboEXWJYR5HLW6RQY lpVJsIXxeLFNUCpZh4NsFIsE2ouiQb8b9C+FPjfo8/Ar2QHWUb/d1tlrzaprruswt1sHNFrNbTPT blswaWpc2Fno7Wzc1tRvfetQ4Yu7i9Qa8YqpKddMTZmTFqeR4NcWbRQBigBFgCJAEbigCMB6OlLV vr2k7uPcSpPd8ZPFk++7dFZ8iPYLJ/Gl3La/ouFX/z3Y0Wv5xbJZP1g4aZzxi/tf0CujJ6MIUAQo AhSB7zwCzf3mV/YU/mdfXnhYyJ9XzrlmeurnIfkCbnN5mN9/tO+F3afunJ9+/2UzZyScze77zoNM AaAIUAQoAhSBi4BAcXP3K0fL1h48efe8SU/fssSokI2cxGe5DVGNd7+8fd3BvH/df9MDi9JZEidC G0WAIkARoAhQBL6JCKzPKb/31Y/vWjDt5TuuGDm/z4aaPLclZ93+ovd+e8vPF2VQYvsm3kk6J4oA RYAiQBE4jcAds9M/eODGd46XP78950u5bX9l4592ZP3nZ9etmj6eQkcRoAhQBCgCFIFvPgJXT0v+ /fK5j288sKe6eXi2Z+y2xr7BX7y2Y2VG3I/npX3zL4bOkCJAEaAIUAQoAn4EfnXljGvSU+7524eN Xf3+LUPcxvP8S3tOdbvFD96wUCYVU7woAhQBigBFgCLwbUFAJZf8+a6lvEL63NYTbg/iRk5zW3Zt x2t78x5dMWPaWbPhvi3XSedJEaAIUAQoAt8pBMaH65+6Yd4bh/Nz63uGuM3DCxvza0KD1DdmUm/k d+rLQC+WIkARoAj87yDwo4WTJsdE/emT40Pc1mNzfpBbsWxmcqyBJmj/79xmeiUUAYoAReA7hYCc FX9/Yfq2E5Vmp4ustxW29pp6rCumJo8WBbeHqalg6uuZ+hqmvo6pryVvqqtH250eRxGgCFAEKAIU gTFA4ObMCQwv7K5oIbnbD75zcEt+TcUff6yQjSKKZNDiWvM009PA8HJGyjMeXxYchnF65NNmMA/+ zqf9TxtFgCJAEaAIfLMQQP2cxh6ryW4XeN7LeyVSqZtzyRRyvOK91+th0RiRb5fk07u8vl2sl/ec Wy+xRCpnhHC9IVwvH2tN4omPvj4jJZJw28yn3o4O02z92fWjuQ+ubR/ya551qFVKGSO4Ga8YEv+M FJUAxAzXO6h77Q12yuzhcewe3mrj7Dy/v7xOyogUMklUsGFKbOjewpp+jnN7RIvS4iQ8o9LKInVK zu1tNNkTQpQnqjpru3qlUtHl0yZEqqVHG1qrG828IATrFAvSIkM1qtHMkx5DEaAIUAQoAn4EPsiv eS+7orStx+L0eJwO1NcUJAzr4XiJVOQWC1Iv6/EIYjzTWVZwCWKW9Uh5qSByOQWpgvWwgtiNYpys IBHE596LlcnlUqlep8pMCnvkiktTojRjdHd++c6+A5WNxCdZ2TEwOzpqlKeRoU6bRKLQGRhWyar1 YolaItcwSi0jUko1WqbPPnKcqq7+LUW1LsGjlqvUWvmJ2u5nP86q7jOvz6mWyFWMSGRUqd4rrLzp Xx+jV7+DeyentKDR9H5upc3NdNtdN/xrA7a/erC022pXaFivIEjB/bRRBCgCFAGKwOgQQIHNm1/e fuOfN2w+VlzZ0tPW2dPlcHV53N2Dli6X0MN5ujxcd7+1y8t0u9zdNmuX3d3N8V1eV0/fYBcv6na6 ujhHt8XR7eLPq5db6OwdbDLbMInXd5Ze8vjrj24/6hJIsH7AW2ZCbGOfU4Qq2TbOEWL8ijpvw6fn nC4YaazT4ZXxTpeTFcMp6ea8Lnxk3S5G/SmHpEQQBm12NSv6/szklZNTiuo6V1+7kPe6p40LvT0z 5f5LM0L1Up1CUd7S2tFnlqGwm8DwIiEyXHPdrJTfXD7zkrio9cfKgsTiX62Y+aPM9JtmJRvko/Ca BhwqOiBFgCJAEfgWInCkplV9+5r39+SSpSIlnIJeUhoajIKa0goF4/UyYjGD5zacYR5YZnDBiRmx r2asy8XoNAznYsSgBvSCUcGTctPn3MvjZfQaxolhlYzcY/I417y2O+P3r1WbLAHHNTRE7bDbRaR4 6IA5wmAc5QnkSgUpP6pQil3wMcoFrxh4yMUyfBRQ99v22WHkKFQqIoT0QXGNSMrMSQzlHF67xc3x /IAdxMqIJbKfXj3rxSNFGplUIfASN8/yEouD7OowWydE6txyRVNXv83psnFueCZHOU96GEWAIkAR +C4jsD6natFj77i8DBNsYFRKQlRgJgmWkWCdiAhpKRWM3UF24ZkOhyQITyIl5OfmUGyaQIcDnHgf oF42B6PGuUSMBIMLTJC2tqpt2u9eKu40BfY2GZUK1MMGP+M6FU7XaG1DF7lUhsMrCSRx8WLg4WG8 bkYiuMD/n44jwSe32836DM8/vJ/9n3uW4o3g5neeqrl37Z6fvHugvt86YLX+aNbktgFHSYtJLpcw SqGso2vdkVP3vLkjMSRo9rjY9o6uhzYee+DNQy/sLTT56JA2igBFgCJAETgLAltO1f7m9S08lpDA ZLDPQGyw2ziOQZS7CKaYwMCQwmMcZANDAgfgQS6W4nlNLDZYaTiM58eyl4SYiXqVvdN+2ZP/bekP pPXGC5yE2J5ShpG4Ry+zJZFJGSejkEkFD+sVS8U8iyARr0gCY1culjCiT9lV+CCTyvRa1eotWdfO Sk01BuFm8DLm6ksy3rz7yg13X5UUpOFcLjfPPLZs7t/25Mrwk4EXJ+h1105Pe+GHl6+56VIcL1fK X7/jynX3Xf7oiswQ3AnaKAIUAYoAReDLETjZ0v3wO/t6BznGoGBgMLjceBDDiGHgQoOlAW6TSAif +W04qZTwHLb4Q9xJpCTLSC9IL5w9XNff27v87+8H9H6S6EYRXKm4YO9ozTaGd3KCl/C8AHcm70Xo DOhXEMhH8qNACwTPNOyQidiS1p681t4nVwzFT3o8vFjkHj4Isah9DmdqhEYiEo5XNklYiUohjwnS qfAjwtc8do9aRZfZAnrr6WAUAYrA/ygCHoH/KLesrrEDJgiDStMeD7HY8AqbDOQFryN57yFsBwbA Rthn8ECC3rARy29gPmy8YL1gJmpVJSdrcxo6AndDwNt+PUmXMPqUNMmM6bKISM4+yFo5iZPz2hwe h13sdLEDNiEhgUn6lGqXVCLVKqRbT1bwHuHVrOK/78t783jloM2JcJ0XDxT+ZfdJBFIGBSlEWPNj mFvmT7HbPSqpWAnQQZmnm1ot++OO4y/uK1qfVdpt+dyCXuDwoCNRBCgCFIFvOwLtfZaDBc2MSMZI fL7HoYWizz/jTxfo/OKnv3/rhekF/57qiQ/3Bw55Mm3W7uZVN67+4Kkf3jAtZbRDnyrgOmolXgWA E8QkukOEYEmsTCYmiiZMHAmG3eUZdHD9VnuP2Sng14DHo1bK4oO0DT2DLp73ePn0qFCs2ukVKr1S xnn5mnZTYri+x+oI16mUsJF9rbitu3PQLhZEMoVoSnSoTkHTAEZ7o+hxFAGKwHcNgQM1LUueeZf4 HhHxCH8jzDL4JPEGj2hYZtiO9+A8/8IbHrMw0eC4gxMS3ki8R7vwvewusUzW8OIvYvUBeLznNnXP Xb2etTt51e3Pb/r1qptmjZrbvmtfFnq9FAGKAEXg24CAIPB/3JX76Kt7GQNYTSAeSDgYsa4GJoOL EhElWHLDchoYDvGK8EPCVEAsCYiN5ANIGCwzwVrx+y0RhcG5P9sLrj6/uxJhfYQCfb1IUgE/dC7/ Qh05l5twJzkXsr6RKfa5XsPnwgxxrj7zusduvyMzADSU29Q2b/U7IkbGMi6OEDltFAGKAEWAIvBt RsDh5suasHCFOHYZieZ3cYTYsIqGFTUHQtwhlAgCAxWxjMnB9FuZzh6G8zB9g0hzZvrNjMXOWJ2M aYAZsDAdVkaOyEHXmV5YvMJooENE8yM9gIwsYWx2ZsBKuvf1Mw4X09NPBuzuZ+wcM2hlzDYyFI7H BIZ7gV+RKgfWOTNDCSOTnKhuDQj2LBLoiE/SxqtuXfPeozeuykwNyLh0EIoARYAiQBG4KAggEfiq v27MLqkn6djgMHAPgjXAQ4RXENmPXGwpY7YyCuk1C6atSI9PDg0TWAQxIP4c2WD+kD3E+kmru3r3 VzVt3JFLtqkUQ8YZLDB0B1/6B0RgRG9/9ITEe+ZNzEwOV0hUAtHyQgbb0IAsK7E57SebetceLGqt qmUiw0nWAfoi6hDjsKBYDHh6hmbrtUtmbrlv+fnjltvUMnf1BtbOC6obHt+y+vZrpwTAGDz/adER KAIUAYoAReDcEBh0uK7/50cHT1YzOoRB+kL54Q+02gnVgZncSHTj5s9M2Xz/1eEa9VefQmCu/dtH H2efIj5GJfhPIA5MGFtwNrrcRqVk3S+vuyZ9VAVk/rQv/3drd/kSw92ELP0hmohV8c/QZmO8yitn x+166OavntVXHZHb1Dd39VoRwwlIO4cbdowaLsFFAjLPqxEcvDzPC17fv/Maa3Sd/WdEbXIEvIyu xzf3KDvngRTnyPmRpEy42mmjCFAE/rcQwHqbC6oiImRnnU7QBhuB2KA/gnUyzrny0qnbf75yVMQG ZFhm68PXP7zqMkKKMLnAE/60bs4drpbnP3fvKIkNI/32ezN2PvEDpt9JolcwFAYBpflTyDFDtZoR rJCwCtDdcPIMghex0uZ0gzvHotncnl0VzRtO1mwsqG7sM5/9FOCsL+OtTgf3fn7duyfK3swuP9nU 5/J+Nb15BOFYXY/5rE9wkGV1d38XXMyfa302bkd5y5bCxnePVxyu6RwLcL5yzD6rM6+ho7C5K7+x s23AimRBdLFy7n44xL+q2d0eCxzlvrajuHnXqfrhHg09ls25de+frPmgtMHs9EDJ7GjDWS8QIp9I YvyqM9L9FAGKwMVHAH5ARILwPkmt4QRt/PnCf2h3Th8X9ddVC/VYRRvROgZt3WZ754AdT8JOi717 0IbfviPbU9fMv3beJLJ+hkASf1q3zb7nydsSQnUjDxu0uzoG7N0Wu/+1a9BuR1DJiLZsQuKfHljG mJxDHk6sAp6ZITnuU0efF5TDudvM18jd/lpnrG437cipcjrcDa1997+15+x9TzWbaroGvvAY3ut1 OJx7ShqOV7WzrFc0Ivvty8Z0ssLRyqZPy6R89liRiN1Z3Fjc3P35QQQkpyNjQcVuKak9WHGGGL7W 5Z/nwV1m54Gq9uyGjr/tztmLUnss2z5ge2pb9sHytrOPbOFcL+4vOFRDFmb7nEKf0/pRbgXsc387 WNW0u7JWLhHvK2z61678+h77q3uLzjKgyeo8UX9x2P08AaTdKQLfOQTwS9QvqeHPxfYnaCOD2+2R KmT3L5mZYNQPY1LR3vvsjtx7Xt9x76u77n5t172vk3/3vbbzyQ+PFLee0XjUyKU3Zo6XoMwLFKRg /FlsC6amTI4MHh4HysDrskp/sW7f3a9+ct+ru+7BUK+Q10c2Hny/oBq/noePfGTprEmTEhkU2flM CjlhQcRKBuonNGqvMeLHnnzq+S2HV82flB51Zq6B+kK0DliR+Xb/ZZPnj49ds+Xoz5bOhKn0YW5N YUtvhE6tkon3V7TsKqmNC9GrxLKf/ndPTYfpsvT4xr6BD/KqBjh3Yojeny2nk0mnJ4T32byT40KW TojrHrRvzqssazdNjgn1er2Hq1uza9ttnKekpa+4tXd8hMHs4t84VCBiJZMiDQqp9HB12yflDRzn jTJowGcYEDbQ7uKmo9VtNZ29U2NCgvXqDdllBQ2dGTHhYt8Barl0QqQxTK0+UtH4k0XT4biu7eoP 16vbzJbOQWe/3XmsprW0rRf3YmtxHVSegzXKwubujwuq+51cfIiupd9W0tp9qKplamzYiYbOnPp2 EnDrZrYUVhe19iSGojyfpKyj/8O8ig6LQyWDNCe/rajmWE17lEGrhWvb10K1innJUbMSIvrM9ilx EVEGdZ/N9cax4vHhQVPjQs9yjwYcrvdzKsJ16imxYbnVHV1ms5uVTk4I1/pqz5Y0d6eGByN0aPq4 yDUfHF0+PaW4u/uq9IR3TlScau2JNGhw7QXNnTmN7Sdq26bFhX9UUPXXHTmzk6PNTuf2wvpTTZ2T 4sJpAdpA/Y3QcSgCAUTA6fZuOFHRDPVhSG2Rspo+kS24fAQmKcz47x8vQ7kV/+mK2nrufWnL24dL auo7qtpNNW0dVc291c3dla3dR8tqD5R1XDMzzaAasvDkEtGJqub23gFCQFbnYzctnZEU5h/H6Xb/ 7eOch97eV1TTikEqW/tqWtur2kzVrR0na9o/zq9XKWQzkyIkRMSSNJgmu3IrSdikv8CNf4bEOcmk xgbfOifj/NFoG7S9cahIRBLPBRSkO/8Bv2AEhVxa2Nzz5MfHb/i/j+5aPBNHHChv6rU5OI9n66l6 VGhDBrdepXrqg+MiCVYrxWqFvMVk+aCgTiWXbS2oyhrhDHS6vEj9hjWFQf59IE+ukFV3mtZlVZjd 3rezKixu70sHC9vNtl2ldbW91rYBW6IhKCJEufZEaVl7T259e7RRZ/bwWELzz3J3WeuWUw06tcKG 7wIrXpdVolaonYL373vyRl7Ga8cqEsODUyOC9pY17ipowK78ut7dJfUbcyoq2vvzm3v/vPukQa9c e6wMuwbsrgidNqe2s7LN9EFu6dvZJSFBpPje3z/JaewdDNEoe6xOvVLR3NMP2sD2pz/ICtFqTzZ0 bjpZbXF7QGlegX05q+wz/r8KMKiYjQsmC78JwZofzkjjEF901hauVV4+McmABVuGidBr2gfMYoHt s1pPd2Lz6rq2F9c+8eGRmxdmiNRSKS8ARqlE3GtxbC2pxWF/2HXSw/KNXeb1x4vDdBqNVCEXifvs HH4clHda3s6uGJOvCx2UIkAROE8EiBik72lOPH6++jV4ZIJIXK6kSKNmhHDw/+0vOVHfRXyMBi1j UJE1OY2MMagZgwYRGNUVtX/Zmzs8lzCtJj40iJiDWJ9QiqaMixjeVdza9+bxMgEx/VoZ1LOYIBWj 1TAgRZTI0ao4u/3/9uTWdw8MHz9zXIwvYRxZd5IzM0SMCfSxvkAG5dzgYH2aW0gE8IyVTxI/F3Ry 0ezYyO/PmJDV2Fbd278xrzqvsaugpePjkgqHy33FxPhIvWoXIlYZZl5y5KyEYIvFFqSQ/vCS9MtS YuFJ8y8yobFiVpCyuF9Hqto5QXTdtNSnr5u79lARFqUmxQVfOTEuRKO+NDUmOdxQ3WXKCNdNjw9F hdnSlj6T2dnYPRCr1y9Lj1XKyLoiCuVsPVV99fTolTPGTRsXU9LUtyWr4lR9W/uA88VD2cNYVnaa Kto6l8GCxiqXx9vvJBn7cPdZHA6pVHLZhLjp0eFqlfzGScmNbcSruSA5Jik0BHexpm+g085dnpqw fEI8AmAYr/TGmWkoFz4x1jg9LooXRB0D5u0FLcF62Y0zUzKTwnud9jidZnZCRJBacrCoAabtyPuZ 29gG1g/RDgU1sWLvSEerh/cWtfbtLmnsRaTviCaWoDA8+ZwWrbv3smk/XTwpKUjr3y8SC5Aua+q3 Ls8Y99PFU+wDVt7jMcglizPiUAk9v7bd6RvqhsnjV05LOV7eOTEmZPb46CijNjM+fHyckefdB6vq zu0bR3tRBCgCY4uAIOCZ4JP59eVTw1/kD+VjWZPL+UkpftM37ihs3Jhbvb+igezF2ptfi4QczJJX HA+m0auOFJ/5M5eKWZnSF9BIzC+JUXsm6KO139yA/DYilI9z4aHD+tLAfeclYvmi1g4TftYPX7VB haB/n8olSbMbMcPTKQiBwAclbsBtyN1mXGMUS+LkXLEG3ZyUyJsvSVs4Lur/duWzvOyni2f+etms N398NeS4fvPegT6HEI4gGQDGimRyKQgsNFiFjwmhIYMCB3Paf6kQZsbTWiqS9NmcCcFqCDUDRJ6V WLzexGAdUgr1CrlMxEvEknCtauOJmr8fLtGgBLpIesn42FVz0188lP/UtmN+zy/IY9BsnxZPSMuo kjf2D85MTrhr4aQ756cXPHbXMLK7SlumxAXPSAjHFjEnUfrKrqo1ChaVDTQajUwiEbGRGgM2aoOV +Pr8cW/W3qo6vUqOSeK8GfEx5FwCo1WwMfhlxDBvZVf8N6dEJVEaNZqipq65afHYGKLVqFn50er2 f+wpQd6IUacY+tnlm0froL2m154YHDz8VZIpZaSE63Bjmazy5o+Lapq6PhWqg+IK7Omgo3ijPiZY oyZC4KR5eNGcCQl3zJ10w4wkOArc+L0AB0X74D935bFSXieXOwUmLAhfXlau12CVzu3xSiS8WCp6 aV/p+3mVBq1OTKoX0kYRoAh84xDAX70MqWOCmNAG0fiHQwyp1iQHIK+0+drVb928eu0Nz6794ZqN 9XVtREAEaWqIfoROL0LPkNwNtRHyz4E/e9PpYDTy+BWLPHiWIaCx3wEvpA1xiKebAxyGHANkbaMj hkLyHDriPUbDeW1Eo9lNCloPNbHLF40y5Cw9PUO7nWHVqI4aIEBleGD6cgBUSm7EuQM0OhlGjB/5 HrdCSp7MB6pap8SFJ0UoecGVGKSXK8QbcstmxcXdPD0BhgsOcHi8bt7rcXlqGwfwMa+tOUIm9/lM fU0QcQ6R3emKVMuKajvhIjORSNTBUIm81+5wcW6bA1GWYthkfeaBZ7Zm/fPG+UsmJ3V2dOO3waUp 0W/8aOmxivbGASK1jCW34BDt4fIGl9tbUNcapVX0W7kYoy4p2NB1Opgzp6qlsrntmtMamzK5t7+f TDKnspGz2bycEwSJ1MBBX4yl1cFUtvSX1fU+tHRGmFFts7nABzZfqTmyjotPLndFZ9/JqpaV05LT EoNaBhxLp8e+l008mQW1La3dvXvLaq6YGL18crzV2o+YkeFbUNrcgV9BMxPOeACsNpz2zC2SsOL7 l0598dbvzYgJGXnjCPIItP2ir4qXd3k9nOK0291ud+CLmlfTdP2MlDkJEVavC6UbLD3kunANWDwG pKwgFHf0lHV2/3j2pJgg5GMG8DtCh6IIUAQChgBsAKeHY1iiy+Ez3XyEhOUJu1Mil4ZEaUPHhRkT w4JjDHHRoRGJhoT4yPAQfXx8eESCMTYyJDoyJCohOD4+VBVmiI8dWlEjjwKvN0ynDooKDUsKU0WF GKRnao0ZJLKI2IjQZCN6RYQZEmIjwxP18THhEeHG2PiQ0JRQY1Q4nvZnrlBGMpAYjy80f3iGKJoq 2OUB80k68Az15W5f//iWp8ckd7uhz7p6S3aDyQSv748WpP904USTy3P7S9s9Hs+9Syddlprw8zf3 hQYpTtX2PHT1PGQC/n7ToZfvuOpYQ8f6I4Xjw0NeuW2JjEhZk4Z8rJ1ljYgMWTQ+7p0TVf89WTbY 5zz+9K39LndeVduUhIiPSxquSI9DTOOs5KR+c899Gw4vTkq0elwTgoNq+00VnabbF2TcNmuCxFcE vN/tuevlHbDrkmJ0v7xsckWr+S+7822841dXzbt5UhwO+Ki4ds22Y9FaTb8NBeTY7Q+svH39ToSQ ZEQbZiXGKKXyjHBtfb+ta8Dxw9mpf9ya/7trZzyxLaegpjUyWJkOmhGYG6ZPSTDKkZX3l70nf3nF LCUj+iC/9rX9pWnRxi6bdcO9V72UVb6toCI5WJ8YGjw3OfL57cdTooJyansfW5G5LIOYdCab/cO8 2snREZnJZ75kO2vbXAP262Z+RaL9/oomsVR+WfIZUhz+bm0rqBHJJFdNTPRTaHWf45Oi8sVpyb98 d2daWEhbv+OBZVNPNQ88/L3JLQ772p35D14166H3DlyaluR1uT7Ir8yIi95fVH/42R+qAvZFDNgf Nh2IIvAdR2DQ6brhHx8dQO62b4WecUA9REaMpEHz9ZdO/fBn1110fGr6LKkP/AtuOlIE/NMzvHLO xF0P3nj+M0SeWObqtazdzqtu+cPGx26++VullUzUNb/tGpg+CdHdpY3Hazuevm7O+d9ROgJFgCLw HUdgwOZc/rdNx4uhuaUc0i8mdbSlcC5dOyd9SyCY4zwRruo1p937d1SyJhEufoXlQM8wt6l13up3 sd5GVpPGaL3tPFE4S/dvO7F5Be9fPjm5v6Jrb0nLorSosQOKjkwRoAh8hxAQsTKwBUQ54DvCijvC IH1BkoiVDNxq1nnBKcdaILgWkxzDGcpJ2To7x6t+9Oz7v7kFMXvnNWXa+WsisKWwpr7TOislfEEy 5baviR09nCJAEfgiBJBGffXfNx8rrEOgo281yxcAiXCSQfPVcyZ+fNpuwyL6J+VIR3KK5V7GJWGk WACDqD/CT7BKh6B0xup2hml0109J8p8Eays5TZ3VbYPY5fHwN89I1qqGCq01mayHq1pxIhHEQDwQ uvIP6CXvhwZEdU98RE6CFyrMNV29T711gLhJFSKSePclMzyf25vb1DF79dus3cWrbnpm85O3rpxO ue188KR9KQIUAYrARUZgwM5d+/fNRwprScoamMPjC2iE6TZoXjFn4rbT3Nbv4OY8v6GqspmwDgvf Hewc/MPB/qAPD+P0RCbEtP/zfv/1mJ3c3Wt3vL+3kJR/4xxF/3l48mn5iLdyq27/2yafor+/u28d X4BcpF/I0ReuibQEF9yP/txdMaNRkHQCEqH9pTM8Hxxzmzpnr37LH4c4Vrnb5zM/2pciQBGgCFAE vh4CJECQ/CepZiA2f7lthEwzipECHVqF3KCC5YQMARVRMIE5BjkkBHeQfGoJkfxnJSGqM8GQIhZW GawxKemiVJOc69NNDSUn+BiROixXkkFAXQocpiQH+0YTySW3Xj770TuueGTV8j/cd80vr188JFCL 5IFPzzBwsrW4HuQAIDNLLj5vpf6vh3/gjg5UPsRnZ9TQPQC54cDNk45EEaAIUATGHgEUAiC52/78 M5AFUaD3UZFnwHZG3gFRipemxJAoSn+pUhKjLxCbDDtgbnkh1e+869IJw9NFMhD0K3zyXTIoVTpH PBtTwg0TooNJZhuGwumQmo0z4r0IryLG6poYEf7E8kuev37+H1bO+f0VmbcunMxAXmqIaT81Q3HA Qq/9udtSVPseq9xtQHOqyXTfm7sf25w1DBMSqE81dfk/muzcw5uP/Pj1Hf6Pg07u8a0nHn4vq91E BKJAXD99d/997+xr7hvKqHJ5+A3ZtY29Q3nK339l97bCutxGIgtyFpbbUVy/Kb9mlKV2HG7vrzYf e+iDw797/1hVe//Zvox+O35EO1HX8WpWmcVFy8eM/d8wPQNFgCLwOQSQuy1B7jbqAMBmIsXSUIwU 615iRimt6+jrsp95ND1xzbxFs1OZ5rahlG0UzrbaSM410le7e5YszvzJkunDw3db7U3dZiypEepi +P0VZyRLIOr78PLZUqTQdQyQmt1IBkfWNjK4rRzTZZHo5Y+vnJsWZcRQPpUIpqC+mXAqaNJfd9s/ Q8yWyHAFpiE5HHaJL3ebV3DuMTGArHZ+Z3ntg1fM8Iq5B7ceIezl4H767t5txU3+i/jt1sPLp8fP TYn9wb8Jvb18sCgkSD0x0fjvA4X4BXD/mzsXp4y7Zcq4n67b5j8e6W5N3abWfvIDpM3haWzunD8l Lsao3FfU9Elh9ZcBkxEdMjHaKDmdrXx2/HaXVIdIRB/95NrV182PCzV82cH7SlvX5pRy/Kdsu1i9 JjM6yi9JTBtFgCJAEbjACMBqcyF3GzYTBB4RHkki7N3ESOK4botl04lTw/PRyGX7H/rRvx+/c2pG 3LSUuGlpUdPGx01LjZk6If7x+6/Z+ouroec+fHBxc2tRYxMxB8FJbsnmvKEHuP+AOxdM3vLrm5ct mTEtPWpaasK0CZF4nTEp5raVc7Ofvuum2WfsPxy87kAJI0iJQBdkt4Zn6LMShqJTzhsygeF8uiQK lmEdCqK8Ffh2orEpVK2JNwb98frF2SVEa1giEUfodUoI3zMMZOb1jHJGZOSPL53c63U299p6zI67 Z6TeOC1ZJBV3DFp7+l0LJkcumJiogWv4dAsOUpS2NePTh1lFV88bHySSmjjPa9mlGwpQIc5p8XBP bT/61pFyHABl5K1F9e/mVJocriijXiSwb+VU/WzDXovjS7WGEQ60s7Bp1ZzJ6G6EOpaULe80Pbbl KESTsQVG+Xs5Tc9tOV7bP1De1vWfT0rKWgax/bWjFc/sPGF2C0atMsKoPtna84+9eS8cKnphT37g MaUjUgQoAhSBL0GAFYsUUgXDQ1zflwMA7Qssm8Eg06o9Ds8/9xU195wR50O0x88WTip8+q6C5+4o ePaegmfvLHjux4XP3PnsdXNRDGT4DD0253+zqiAcxSgV4EgmXF1wtKC0zTJyCldNSdr50HUFz95b 8OxtBc/eV/Dc7Xmr737zx8v8moXD7d9ZlbmFZUyYdsiBOTxDqHOxGmfANLeUYDWf3aZQYsJj0SCN D5FHqU9bxCBTW5yCWipZNStFpSSKkU19VqNRKfaZU4la9e6KZhkr1qgVKBkDkSeocjyz6pLbXtq2 4oUPf79i8fD0UkNDyhsGcONQO+bWSybuLGk8XtaSFhUUHSxDZdnfbjoyPiTkUFX9uydLUWTvF2s/ jtAr86tb3jl8qtpkgT94UXLcz9bvHB4N0lkuLz9clhrDtlndoQZ5vcla2NaHwzrN9kVpSeuPlByu 6vmkquW93MIFE+PtVhfczvHBsjCNYv3xytKWrkiN9jfv7D5R077+0CnBI6TGhH6SV7fuRNVYoErH pAhQBCgCX4iA4OWdI+tuo142xCE1auJp1Cjr61p/+Oq2yk7yZBtlQ5XRx98/sOtICaNTE1sQdbdh CBrU0594JbtxaGlplEN9VFzz8zVvk3GcTiKX7K+77Z+hv+52wNbbHFjH8623OTjpUMmwUU5y1Ifx ZE3Pv2w46HXwWKjEOiUCaXyVexRysdynVUiGk0gFkdcnPEkaZEdQj62x17FkQvx1k1L+cyCbKHX6 2qVpUW4JW9lhNlmsiUatyytKjNDNT4tdlJxQ3tQXqpB/P3P82ntWvH6w3OkWvj9v6uK0eI1GIVap orTK6UnhvEwYgHzn6YYiaq8cLjpc2+U+XWtWLfe6Ge/RmuZfv71ve2Hd3ITwUIMqWCOqbOtJNKiN aqXI45kcGzY9KuLyjJSYEPWftp8I1ytMDqtepe60OhUqcWZ86IzIsIggzYnffX/USNEDKQIUAYrA eSPgz90mdbf9Va09ZFkLz1iSwe2GsOTRUzVL12zacLwCJbZtLvywR/AJeRzjDakBgDdkg2BzeWAb bCmtm/3cf1/ddpLRKocMQSSDIypSKkXFsTlPrPvte0fKOgcHHBycZHhAk9GIGrtvKDIOKIzvtzlR pvK2V3fc8NibDFZ51Kqhutv+mEz/DH3tU6VMzgMJ5KvjiuD0JGLRYxQnGaxTOTxO6GxinlY7q/f5 bz1uVGEg3Bam1nSYYYqSjbUd3QuSovs5j8XjtnAeXHKjyfb2gbJHrph13+JJTq+wq6Jx+GIzonX/ 3nti9rgEbBEkgsvjdjggR4xCbB5BKuNZFuVoZLwgJfn5ZHSxIChFzFtZpRuPl6cHh8AsHB5KBA+y 282jPoCPOsHCkUFQTLbdPjv9uqkpvQ7nkx8ebWzrSYkIt7tsGVHGJ5bP2lXcuO5oCQro+O4jvi3S XyyZ8esrMv9884IYg9IliEyc9w87cm+dk6yE1DNtFAGKAEXggiGAGjd43qIOFlazYCIgWAMPW7zH PwToI4RSpWzt6r31Xx+u+OvmhzYdeGZH9l925qzZnfeH7Tlrtp9csyt3za6Tz+/I+fWmQzf8bfP1 T73diLg/NQwqX3UbPDgRIQmOVMoJ1THCnzfuWfj8unvX7nlm6/E1u/P/gKH25K/Znr1me94fduX8 cVfe0x8cv+eNXQueWff2zhNMmGFoViBT1MTB9IZniDfETRmYBmMQQ/nrbh9ctWBy+oga4YE5A577 MkVBU9egw721sDbJYFiUQcq+NPcPNvcMzk2ODter9lQ1upzuwgYUlHbfsSCjrMt0sr6ztLVDJZEt nTAuq75VKRHVdfVXtffdNDfNIB9aaxTEkl9tOvLUtZfEG7WlTQMyiRixMCjDPT8t8Uhlq0xgNmSX XzI+ZlxU8JHKpmWTk04196JYTk1377hwQ1JYyMuHTt42b6rMZ0SGaVWoKJ0UpveX20Z9GTfL7Cys cXj4HWX1UTptR99gZkrk4fI2u5uZGhfW1G+WyST9DrdRr0SJ0Zmx4TaPs8XE4UtT3zsIi6/XbCtq 62wdsE+LC2vrs0WjHM8YFX4N1E2i41AEKAL/Kwig1jIqJzd1jKi7jUsDvWHpByH+/sI3kClh+Y62 /vyatsMVzfvyqw8U1B8srT1QWn8wv/ZgYe3B8sb80oaWHgsKdJGD/b0wgr/AGx6VMAqJfcKC5BwW Z3l925HShgPF9QdP1R7Iqz9YXHOgouFgXu2BU3VHK+sqmjodoC4s+yEV4cxQECXxjeCPniQEzKbE GgNUd9uOuts+bvvgMLhtwhhwm0YukQni4yRGn31gyVSlL4AQV6FVKeONGtBJUoguu767y2x/6MoZ KDwdE6Sp7BgURMKKKUmJodowgyq3uqPTbr9mRuqkiDM1XLDKBSfm92eOE6NcjUQcqlPrldKmXvPM hLCYIFVBY69CJdw3fwpuJYqtpUQYvIIoyqhbkBJV0ABD3B1u0MSG6ELIIF/Q4oy6um5Lh8mCVdAr 0uOD9JqSzr4pMSFQpEHh2kNlLbC1l00ZNyEyqLS9M0itXTlj/N5TzR0WS5RelxCq0ysUUrEINdwG 7Z66voH5ydH/K3819DooAhSBbzoCTo/3vRM+boMmFkjIH1cPhyRyzuD98xfjhg0HllIjU9sXcgJ7 juRZg2YgLywj1UpR2hRdNPJP9YI5CCej33+I1TI8XmFoYVj0QowJHJXohS1YkEP1NFgKGAEHY50J r8QsIQ7K070wFHIAxL5oSf8M5QxnT40Nv3VO+vlD3DZoe/VQEWt38qpVz216/Ps3jZmeJByPQWrF cMEwn1uWxO/4W5+NQ5FPvXJoxc/OeeBHVPsKZJO9FgeW54JHZMj7txMpzBEYACizg1NiAU8i6bY4 gkg4CuFRn9Q+yRTEXcbxA04Osi8oYsp5PMO1Oj8PpcsrWB2c8TT59docIWplv80VpJah0hsGCoKR TvIZHCKRVCuXWJ0eq5OLQDl238zwBbByTi8v4nh3xOl62ed/w+gIFAGKAEXg7AgQPcm/vX/sFPQk 1UNGEknNlpGcMz+TEesNWdg+loKDkRTL9hI+w7oMnpL4iF1EJSsQvUClpPr2aM71WcXL87nRuU3t s1f/1xdLwrgD5un8ohlF6lTDxIb9ON8wseFjsFo+TGz4qJJLhomN7NUqP09s/kFGNtwRg1ruT8gI 0yJ0fyhnwO8ORJlo//EGhVyjlINKz0JsOEwmZoeJDR9BbHgFsZFXjdxPbGh6pRLEhjcahWSI2Hwz w2R0SgWOp8R2Pl9Q2pciQBH4ugigsrEES1kIpCAE5lvDgkWFjGxYUXg8IjDeH7uBjcgtI0nTPvML lbJ9ESJnqnUHpBcMxNGey8GwKk/AcgBgEvpzt5VyCKbQRhGgCFAEKALfagQQm+jyuHyaW6frbuPh jjUzVN+G/QQRENCbP8wEFEjSuhmiNumnOiTwovlrYY/sBbfhBeglOGUBywHgfJpbyN12OHDttFEE KAIUAYrAtxqBM7nb/lUul4+34L9SKkScOzg0TARbjYQ4wmMn9qV120lQPnxNUOoi6WtYbxvRC0pa YD5IJ2ORyN8Ldt5Y9MIEGD5QWda4WqwoQiIaM1bCJB2LVtk5uCm3eltJ3TvHKrMbPpXoZ3MJdT02 x1mlF5Ez0WFzmuAIHtE8Xh7b/RvsLne/jesZcJGw10+3TgfXZMLC6tCRgiD0OFwNJnIoDjQ7Xd0O F+qvm5zYcEamBGH9/Xau1+myOhG/SdLgkLHRMmButTpIsgZZwBNMdkfbgGV4DmOBGx2TIkARoAic AwK+3G0nI/ISywySHP5Ua9CSzRERGfz3m+cnhgQRxyM8lk43Y7ER7X9oP+JZhyBvWHLogkxq8BzW 5/CoxAFwZvpTrYnsMhIAPIQOETwyaCHj+HvhgKFeThJMYR7RC9dAtLXcRBvF3wvPan8vWIrDMyRR l6JAWVgC4wAVix97ZvXzm/f9YNGUtIjgc4Dy7F26zdaD5W1vHC4OM+pDg6Tjgg3Dxxe39a7NKkiL CEI29BcOggXNP+zI33iiKKuibXpyvBaxN772jz0Fpe2+wEWR6JqXNufU9ZS39QVr5RF6zfA45W39 T3x05HB5bV2PZU5yFHzQW4vrX9iRl1XdHIxoxmDtC3sLP86rO1rf+sqB4nC1MjkiyN+33eFY/dHx /Iau9cdLK9oG5qfE5rf0rD9U/EFeRWOPeW5KdJ/d+caJ0tcOFNf2WifHhijHdKEy4PeDDkgRoAj8 TyPAeb3v51Y3QuRd7ltygpmFgA5ieykgUn+iormt34w1sPBgfTgCHYw6nYjR4FUqsvisA6nARgcH GY3qUJ0mCKF5MpkValhiiZgV9GqVXq0MD9FGRoSGaJQSVrBayDIetJkNKnmQVmM0kF4GvVonl8Jq 4WE4CXgRh6sVocGKUIM+SKPRKcRWuxupx0NZBERz6/QMBXlSjOEHczLO//60DXJvHDolfuzRp57f mrVyzsSMqMBzW6hWNT7a0G6x/X7ZjAnhwTB8sqpbId4RpVea7K7y9u4ZceF+bsMuiO6LRCLl6QjJ rcW1p2ra3rh7uVcie/VQ/tWTSQXY6u7BVw+cNCqV81KjwW3rDhZt/tl1i9JjRhIbDrvlpQ//dfvl d8ydtLuivs/mFouE7YW1z69csGr2hOggLUJL5qVEXTUlYWJEcKfZmpkcGQEZGF/TSaXLJyd9b0Kc ye5B6tv0BNxE0dVTUlbOHH/Huo9vWzjJKFfOGxe9KjNtY3ZFnFGD0c7/TtARKAIUAYpAQBCAt+md rNLmThNJr8ZjlVRx85L3DmeIUfPbKy8pa+zgnK5rZ46/anpqWrghOTrkj9fPnzQ+esuBEhEv+sHC CTfNnRhjUMcFGyclRfxgzrQu62Brc++4SOPjKy9bkhY3NdY4NSJ4bkL0nd+bcbKxs6+9JypI+9iq Sy9Li0kI0k6IDJ2ZGHHdnAytUlVUA21lFrJQ9yyZnhRqjDEaMsJDr5uXGmEIKiivJ15Q4of0Bc2T GcL5aZ0QG35LYHIABl89VIwTMAyHUt8BAfYLBnG4ebeHh4AW9r15smJHUf3ekvqdpU1yZIGJpOzp gEaIFL9xpLSwpXd4CN7J8D4pMKNcVtbSjjfwFubUdk6PjY4I1vs1QeBK3VhYuSG3qsdiH+7Y7eTE MmmcjrDOgtSklh5zTUdvuF53sqFzU245bPXhI7Nr24JVikkxZzLn/LvqekyNPb0Lx0fivQEF91jm YFXL1NhILebDMv02x1vZ5UkRxoQQw1ihRselCFAEKALngACK3CDKH88pv5IIAkMQ2e/LvEacf0ZC hFKu4FyejScqHn1rz7ObjsHAsrj5t6HNz3smRBtunT+lsq13Q1bprtLa1w8UuAT+sRsug3aVQa6a Fh9W1NDxyIajj7x38IF/b3FwnjsWTmTsHo1ckRxqzClvXLP5+F8/Ob763cOv7MlZNWc8HJsKiWjV 3Axeym7KrdxZUvVW7qnjZV1PXjdPq9OQqBY/vfln6GtfqmH/tXEgcfJDnDYmFW6GJkTG9sfiP7Pp UEyI3uly7Str8V/W8JzFLHtTZnJaxBm2WDIpQSRyv7jvZFZ9cxAWMxnmYEUjFkTnpMbZOZcfjWsz M7RiWWlbz9sniE6/vyERTQcvs68p4UD2egfc/MmG9n6b/VSr6e87h7T5uwat5W2mqfER/tLjZ5rA FLf0aVWyxFC9f+Oeypa3jhaj3JHvhwBjcbqrugYHOLdf5Zk2igBFgCLwTUHAFxVAJkOqWnsZ8nNc RFa2kFktSBFcQDQWeZ4bNCul4jW3Xf69ifF3vLR134lSOCohqaGUKVOiQn64cMrtcyb+ZGlm96Al v74bGcZilq/pGjhW1eC12wU4vjg+q645GDW7BbgrmdYecwWU5XmvlyfBmdnVbYNWm1Qk0kilSoUi WKm6MTP99rnTHlg8My5Eu6OkXuVXmBo5Q6LW7zM0A9R8DlmMJhf7tIvHppH0aaJlhTMoRdJ5KXGX jY/9yWWTOYRw8EM6yTgxlsQykyKj/enPvgapkd8tuyQ9KmTJxOQwJVlLK2zo+eRU7TvHimB0Q5oL W359xdSrJietmpnW3DvQT+qmkxahVvdZSWlTtD6HRyoWq8QiENX1M9Oeum7u5pyhMm913WaO9c5N /axuSL/VkV3dcmk6cYGi5Ta27z5V+5urLpkUHerfEmvUPXZVJqr0HK5qRWjJ2KBGR6UIUAQoAueA AHSKySPX14jko08lC2lt5BGPD2A6kFBcTNhzty7tHbDe9df3G8rq/OLFkDjusVn251a+uTV73bbD /91y/L3s0rKWbpAQj6wCAX42sJwvzFJJHG68XGDEPE8UmMVihJ9YOGbQzJjtYlakUcncgtsjCFDJ OFbZtHZ7zrqPj6/7OHv93uysqmabg6hHDk1veIZE4DlQpdb8dbchteJxk2y/MWq82GGD7eQlNo5S MjUmaElGItjb6+IEr0cqYRv7Lf0AhWFQKc2M6gwjWnywfkl6YlZZS2w44bb7Fk95dMWcmSkRc1Mi E/xGlY9ZOqwcFCaDTucx6BUis5NF0Ad2najtjA1BBQAdIlPcXg/E/lHqHNuxrHqwoi01MmiEbPLQ iQdcnFytmne67NDGo5W3LZycfnoxEoJbsEFVUjEv8tq8nE+KmTaKAEWAIvDNQIDkbkN5hCWZ2kgD gMUGYiPv4WZyG5Qq1isYDfq37l8xPzUa0d4rF8741R1X3LAkg5GzVV19iDS5aX76ghnjMqelz5ge 8+KtyxKjtAwrkYskGgUp6U1YkAiaCDoUKmMhRo+4SUdUkObBK+bevjzztuXzV10xY8Mvr23tQ+wl D5GU/Mb2KyYlXzM7bc701IkTYp68+XvXTkuzEocktKl82eL+GRIpL19geiCav+62+LHfPfX8+ydu mJeRER34WBLME4tktQPmOUlRKpk0WKP6887c7Jp2nUYRrFOignZmYtRrh8rsEnZCqP5v2wuRcTEu bChkEX3fOFH+0sEiKc89fcOl+KhTQhNEYXF71ChvHRcmEYn+ceDU2zlF7b3W++ZPhILJMCzzJ0Y9 ueHI7oqmlDDNnfMmxQZrW3ttbxwt3Zxf/fBVs5NCdb0Wx6HKhp8vnYFBRoKJXzyHyjtTQnXjwoYc kqjyUN3Ul93UdqS4dda4GIeHe/lI8SsHi4L1ypump2pPyzcH4o7QMSgCFAGKwHkhgJymt7NKWrpN PrFHFAQQ+7T2EdOPOH0xXF/1PSb8Lm8csBU19jldFkEkQY6Vzemt7uriXCwezr0WZ7ABQQZimVa+ 7Vjl+8eLvWJ2gBVKWzrqOk1OlEUjCeCKeou1rLWzvc8cGmLIiIs4VN9idjslrEStkRwoqV9/pNSF 0H+JtKSxs6bfFKRXgHP1Wump1r6X9ubaHXZCtyRJHDalb4bgNo7LiA37fmBiSfrXHiph7byguv7x LU/ffu2UlPMCdXSdYWjB9Tv6PIY+hx3u2i8bGy7BAY4LQorGF7UBDpEgZ3ZYOI7ITBKb/Gs32IAk DdDXD7GyuIQvTlz42gPTDhQBigBFIGAIIGf3+n98dPBkNWK+SYUvEnbOktwylCcluiQektmGH/T+ jOZhtxMIBmnaaMj15uAahNkD7X+BlAzFMfjJT6RJEJ8CfUhf3RyMAFpCDpxYOjk85OGb5v1nW042 oh9J4gGelUpGzDFyBTkYvXCu4ROR/G+kHeCRDulkeCZPz9BmY7zKKy+J3/XgTeePRW5T39zVa325 2yqlE8pbF6QReeivc6KzEBu5NSz7ZcSGvSOJDR9hY50bsaEvbvswmeHuUWL7OveQHksRoAhcIARO 5277lP5hGHl4X91tFYM0NX/Ktn/9CUGTkCOB8QTOA7EhSQB2HZFORvEUosJIDtNqhpS6QGz4SAb0 kmRwyHGB9hDfADr0cO22wfeyyluQ5a3zFR3FgCA2xPRD+gujkSe+lFGdPhf8pejlcAzV3R6eISYj WBUBW2/z192Ws1DSlMvowtEF+vLR01AEKAIUgTFCQCyRGBFhD28kaAYGFmgJDklYLghHgJ1EFJN9 phXcV4g19+tMgsnAW6SSM9bAsJzm7+WjQOz6fC+Si+ZjL/RSKHptzp0FUMswE+L098Kw4D//uUjF li8/1/AMwWq8oAWbBqKdrrvtxsllAVvFC8TM6BgUAYoARYAicA4IoFxarAEeP58gMsI0QFSkchvS en11t7G25q9r46+gDQaCFYVXHDxcC/vr9gIpkgoDiHw8j3ORyuDu1NAzwRbncO3DXfx1tyGRiZIz Y5i7fc5THHRyZpt/nYs2igBFgCJAEfhqBBRSySXjExnU3iLpSb4MbkTtI9GNlLc+XZ7tTNK0L/gA 1pW/xOhQDvW59fJlMZ/buVDzzOFFrdQFk2K++gpHdYTYp+tMEDiTZzaqjhfkoN2lTQdrIK9MnaUX BG56EooAReB/AoHMuPDk2HBiq4G0EIII3oLFBrMM3kWwF2wsYiT507qRhQ0lZV+NbKzMwZIjhbkR CXlhe2Eh0CnEx4VfmvTZbONzvSFYGPRzmxvFwL9xbUZc2JS4z6phBXCWPll/2igCFAGKwP8UAjEh mvmpsUPK/SQAxPekIwndvuiSM54wxFv4Fbn8G/0Z39joP/JC9mIYh+XhKzMDdxvI5MWPPfXU8xsP 3roYdQCMgRt6aKR9VS2QH8lv7DbZuWiD5qUjFSaHU6VQnGru7LPZLS7vidr2uq6BlIigN7KKtBIF 0qsPVzSnRpKZFHf0CQIfqVM/8Obhg9UNW0saY3XqYJ3q9azSF3bn67W6xGDNwcr2t44WbSlscri9 EyKD0HdLcdXLB4pYqRQyoChP8+qRitcP5aukssTT+WoYuY/jf/n2riNlnXqVPMaoWX+i7B978hAu Oikq2OJintxyZE9JU2lH95Ha9l2lzROjQjSI86GNIkARoAh8GxCQS8RYYdtW2ODhvIxCSvyECNZH RAnxPUKZBBabb+NwWjcuCiYdiezHAajWjdRn6PRfqF4IP3Fw8hD9x7+4IVDotpudrx06hZR1JEWL TLZAlYX71PSa+war2vu2FNTvLK5r6TXXNHR63WxxS+vOkrqcus6C2lYHLxyra0Sfl3YXn2xoqe42 t5jM/iFO1XXkljfjzZPXzbpsUnJeQxPkibfm1Tis3IPLL3l6y2Hs2llaVdPdd/v8tKO1TYNOx66i OruTf3TF/Gc2HcDeY5XdFW3dP14ydUthdWHjmepxv1q/Y8GEcb+/bta0pPBtxXV9Zvufb1y48ViZ yeo2WxzHqtpumTEhp7Jtaky4x+Eoae0PFOJ0HIoARYAicAEQuHJSys1zJ5HqaHD3+UMW/YH7IDZE LRIhR7gf4ZzER59bEmSGjGxSRG1E3e0L0AtZdAjX77P++cbFAYTF7XSLBEaEBHSpTD+I5IYxaOND DW0Wp0orqOSS/cXti2fFZSYH9dk5o0zBu4XWfm5eQkSITn2sqS0zOabVYms3mTNihmQbYUTzPsnj ML3qrQP5f73pCo1Mktvac7yhd/vxSrUv2FSpVC6fkgqLUCGSmm0ejUExe1x8agRURaJqBu0Hqmpq 2/q35tU5iL7LmZRtqUpz2yXjQzQKuYit6bCkhhrC9ZpFE6M/PFku14umRxvjItXJMUGZcRGhQSqR aGzKto4B2nRIigBFgCIABFQy8R9XLVo0P4PpMpMFNhhhJIONI5VIhypowzhDWpuCpHWjyhiW2URS X+j/iLrbCDkhxXHGoBep8e07F+zIrq67b7nsF1dOC+CN6+I4qRz5bQyTGmc4UdIWwKGHh5qSGNVm GpgdnSCTSrZUVq2YME7OSvPru8JD9Danq2XApFaIp0ZF/nNH/m2zx7tcfF5j+7SkqKHuyJdmHXh/ yyufXDktaUFypM3JoYbez5dOfOLGuTt/RQxYq82G9G2ILoN/3Iju4VgF0vWIb9mqRAKiTHzvorTn rp/32q2XT4sJhYiJX9rYbrcNz5BlUKSWdOnutSnVagF71AqvF3n5yD/kkPvh5b9WrvlYoEjHpAhQ BCgCXw+BCL38wEM3PXDHUsY8QNbebA6SduZE0rTPVhuZ1o062qSCtutTtbBh52HtDaq8hN4+l2qN ZPDz6YW0bkicICWO8f7nqVtfu3PZ17u2rzr6YH5jmtFIuG16dOSp7p6vOv5c9mskIq+Tjw/VRqmD OrqtIBHI/3ea7BFKmU6pUIvVKpl8TnrsgYKmS8ZHIWyTF0kHbM6/7MlFARo5L9ZLNGYH39RnWT4x rarLppTIJ0YHQ30/v7EH9bIxIa1Y6wanMV6ZCFrMLIovFFT3HqhsHXAwMQbVpWmJW0415TWYNkFG ze54L7fqT/tz0MugVj7/cV5tv7l1wDopMaKh25LT3FnRNbhyerzJ7ZGSEuxeidfndRazHmq3ncud p30oAhSBi4/AizctfOf3d4YrZYS9LDAVfKJZsORgM5E1Nl9aNzHp4LeUD6VaI8AQASYw6ZCChew3 EtkvJd3PvxeCFxGxSVTsSQDnlPTYw0/f/ZP5gbTY/IifaG5OiQ8Rr1692up2bjxQfsWM5Cj9mRIz gbotKo08NUxnVKvSEkLGhxlgZoUoFRNjQ8NQpDUmOFqvQh0CvU49MyHMYNSmBmsNKpmL45PDjBqd NCbMKIiZ7sHBwubOorbOEJ3q0tTYlkHbrqLqWXERyRFBvJjJiA4J0SrVcnVKuOFkTUu9ydRmGvzz LYsQABITpPYy3h2FtRkxwVOiQuwer4KRpEUal4xP2F9dn1/XnhIRPCchomvQ/HFB7T2XzYSGMu8R gvRqFMRRq6RJQahFKkoJN+pxP2ijCFAEKALfQgQmRQfftWhy7SCqXjK8y84hYBKx/ojydyPWH7qR UM9yMV5wHjK4kSfgk+kiq3Qc44WXEit2EH7E8TD1zq8XySXnJWIBK0hpUaEPLJ/z8h3LUk/XyAwg ribO++C6XfcvnYnMNqG2Z2DKU28/tWLmI1fNCeA5LvxQv99yZEVG0ryUQCUAXvgroGekCFAEKAJj gkBNjym7obeipat90AqigRdSIpK4vW6ZWObi3VIWviovbA+s7Xh53y7BLRPJXF63VCzBFpLRjQUg +LTOqZeIlUil3rSwsJQw3YK0pFDNWAWfr8sqveuFzQ0vP0S4DWURbn91R7NpYM8jt2oRM/qtbW9l l82MjUyPDnwyw7cWEjpxigBFgCLwHUJgyfPvWThX7jO3kfU2hUxy9+Kp1R3964+WfasxWDktNTXC 8K2+BDp5igBFgCJAETg3BDZmlx8ra37ixsvQfSgyfkFqzPLpKf/cm1PT/S1O51LLEf1xLuXZzg1H 2osiQBGgCFAEviEI9Frsf92StXR6yvfSiXbXEBMoJOL7Fk23DLrePHCKyhN/Q24VnQZFgCJAEaAI jBKB57edKG/vf/SaTKWvjs8ZK2decuTvbpjzwpGigpZvsek2ShToYRQBigBFgCLwP4PArpLmf+7M eeyWS+emDgkuf8qD99AVM5emR899dn2TmSRN00YRoAhQBCgCFIFvOAINXf33vfjBylkTH142e3iq n12devXOayeFG9MfeWFfdec3/Hro9CgCFAGKAEXgO47AyfreBX/dlJIUuf6nK0ZmIn+W20LUspPP 3rF8etrSX7+4evOxfkiQ0UYRoAhQBCgCFIFvGAJWzvP89uzMR/41JTzoowdv1KDo+IhG8tu+cMJ/ 3Z33u7X7p2ZE/uMHSzMTIuRiWiP0G3Zj6XQoAhQBisB3EgFopxyuaX1u0+FDpQ1Prlz05M3zSPTI p9uXchsO+6S06U9bj6H62vXTk6+ZPn52amRMkPY7iSS9aIoARYAiQBG4+Ah0Wux5DR1bsyveya2Z Gq57ctX3rpwc/4XTOhu3oYPF6V5/tGhDVml5tyVep5oyLnparCE5NjJMrlAoJR6PRyxCoRxi+4lE Iq/HI5FJ3ZxbKvPvkvh28SKR2OvxSmQSN+eSymS0F0WDfjfoXwp9btDn4WjYQSqTujh3l9lZ2dZT 0dZb2Nxd3d0/MVx/95Lp189KN6q+VEjrK7jNz4fQyy9s7Dla3ZTT0NljcXAOHjnSXqmb9/AsL2XI 4B7WzfIiiUjK826PiJfwEhGLQjEelCeHUBnP8x6RR8yLJSIx7UXRoN8N+pdCnxv0eThadvBC09kj 0cnFWrV0dmLM3KSIzNTomCDN2a3IUXGbfwivIPTbnLDknE6XVRAkDO9mWGKasSxexLzgFolkjIDg ExkPjWkWB8Ceg0UnZgU32ShwIjGq0dFeFA363aB/KfS5QZ+Ho2cHrUislktUcmmQWgm7aTS+0a/B baMZjh5DEaAIUAQoAhSBi44AVV+86LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+ C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQ BCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAE AowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG67 6LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiK AEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoA RSDACPw/jRlMVUNEDuMAAAAASUVORK5CYII= --Boundary_(ID_x14LavIeq48ICurSC4nfyQ)-- From i-barreira@izenpe.net Wed Jun 26 03:43:20 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4987F11E81B0 for ; Wed, 26 Jun 2013 03:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKLo8txAwuQ3 for ; Wed, 26 Jun 2013 03:43:15 -0700 (PDT) Received: from correo.euskaltel.es (ektmail1mta2.euskaltel.es [212.55.8.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4930811E81B5 for ; Wed, 26 Jun 2013 03:43:14 -0700 (PDT) Received: from ejlp023.ejgv ([195.77.108.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MOZ00A4CXRZWU10@ektmail1mta2.euskaltel.es> for wpkops@ietf.org; Wed, 26 Jun 2013 12:43:11 +0200 (CEST) Received: from afe02.ejsarea.net (afe02 [10.200.192.15]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id r5QAhAEN006112; Wed, 26 Jun 2013 12:43:10 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe02.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jun 2013 12:43:10 +0200 Date: Wed, 26 Jun 2013 12:43:09 +0200 From: i-barreira@izenpe.net In-reply-to: <4304DE38-B450-407E-B019-81DC5EC7E87E@checkpoint.com> To: ynir@checkpoint.com, joelja@bogus.com Message-id: <763539E260C37C46A0D6B340B5434C3B076D42C9@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [wpkops] Silence is deafening - Trust Model Paper Thread-index: Ac5w+ZSoQsntgfnhSwGtPfDMuxnBDwAG044AAAa7noAAA8QbgAAaeCeAAAG4CAAAAGkOgAAYr0mAABFINhA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <51C9D230.4060300@bbn.com> <51C9D4F1.8080905@bogus.com> <4304DE38-B450-407E-B019-81DC5EC7E87E@checkpoint.com> X-OriginalArrivalTime: 26 Jun 2013 10:43:10.0682 (UTC) FILETIME=[F3B6C3A0:01CE7259] Cc: wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:43:20 -0000 Agreed. Recently, in the last CAB Forum F2F meeting, an issue arised regarding = some certificates that didn=B4t meet the criteria but claimed to be = non-web PKI so not affecting the browsers. The problem came then on how = to define/distinguish web PKI and non-web PKI and there=B4s nothing out = there. All of us understand what a webPKI could mean more or less but = this chapter is a good opportunity to define. If we are talking about = the same topics that are covered in the CAB Forum, well, it=B4s better = to stop now that working for nothing.=20 Besides, ETSI has a set of documents (standards) that also "work" in = this direction. There are documents which defines policies for CAS = issuing different types of certificates, profiles for these type of = certificates, guidance to CAs and auditors on how to implement and audit = these policies, checklists, governance document on browser behaviours, = TSL implementations, definitions, etc. Regards I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. -----Mensaje original----- De: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] En nombre = de Yoav Nir Enviado el: mi=E9rcoles, 26 de junio de 2013 7:23 Para: joel jaeggli CC: wpkops WG Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper There is some weirdness in the charter, in that on the one had it is = about documenting real-world behavior ('The working group's goal is to = describe how the Web PKI "actually" works in the set of browsers and = servers that are in common use today.'), and on the other hand the = charter explicitly calls for documenting trust models. I took this to mean that each participant in the web PKI (CA, server = administrator, server developer, browser developer, and browser user) = has a mental model of how the whole thing works, and that model guides = their actions. For example, the browser user might believe that CAs are = supposed to (and unlike Steve, I believe that is a good phrase to use = here) verify domain names before issuing certificates. So if a server = presents a certificate that says = "C=3DUS,ST=3DWA,L=3DRedmond,O=3DMicrosoft = Corporation,OU=3DMSCOM,CN=3Dwww.microsoft.com", that means that this = server is really controlled by Microsoft. This guides their actions, in = that when they want to reach Microsoft's website, they'll type = "https://www.microsoft.com" and if the padlock appears, they can trust = that this is actually Microsoft. People more versed in protocols will have a more complex model in mind, = one that involves the DNS (which pointed the browser at the server), the = whois database, registrars, CAs, and email verification. But everyone = has some idea in their head about what this WebPKI means, and this = informs their actions. It's a real-world mental model and some = real-world actions. I think it's well worth it to document this model = (although I'm not sure where we could reliably get this information - = we're not distributing questionnaires and conducting in-depth interviews = with end-users, right?). I also think that the current charter covers = this. Yoav On Jun 25, 2013, at 8:35 PM, joel jaeggli wrote: > I came on as AD right after this WG was chartered effectively. >=20 > If we seriously consider rechartering at this point we're basically = declaring the original a failure, which is fine I guess, but I think the = IESG is going to turn a pretty jaundiced eye on that. >=20 > If something truly does not fit under our charter it might well = advance as individual submission (I'd have to consider that), socialize = it through and bring it up through opsawg or other alternatives. imho = it's premature to really explore this. >=20 > On 6/25/13 10:24 AM, Stephen Kent wrote: >> Michael, >>=20 >> I agree with Paul's observations. The charter for the WG is = intentionally narrow. >> If folks decide to revise it to be broader, there is no guarantee=20 >> that a new, broader charter will be approved. With that in mind, the = trust model doc needs a LOT of work. >> Phrases like "is supposed to" may be appropriate, but they ought not=20 >> figure prominently, as the goal here is to document how browsers and = the public TA/CA really work. >>=20 >> Steve _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From i-barreira@izenpe.net Wed Jun 26 03:44:58 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39D711E81B6 for ; Wed, 26 Jun 2013 03:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWnUDPmffcNQ for ; Wed, 26 Jun 2013 03:44:53 -0700 (PDT) Received: from correo.euskaltel.es (ektmail1mta2.euskaltel.es [212.55.8.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3652611E81B5 for ; Wed, 26 Jun 2013 03:44:53 -0700 (PDT) Received: from ejlp023.ejgv ([195.77.108.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MOZ00AI5XUJWU10@ektmail1mta2.euskaltel.es> for wpkops@ietf.org; Wed, 26 Jun 2013 12:44:44 +0200 (CEST) Received: from afe02.ejsarea.net (afe02 [10.200.192.15]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id r5QAihRS006533 for ; Wed, 26 Jun 2013 12:44:43 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe02.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jun 2013 12:44:43 +0200 Date: Wed, 26 Jun 2013 12:44:42 +0200 From: i-barreira@izenpe.net In-reply-to: <20130626094733.32212.17086.idtracker@ietfa.amsl.com> To: wpkops@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B076D42CE@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Content-class: urn:content-classes:message Thread-topic: New Version Notification for draft-barreira-wpkops-trustmodel-00.txt Thread-index: Ac5yUjBZDaj2SWu6QOCkGAibcxovEQAB+dZQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20130626094733.32212.17086.idtracker@ietfa.amsl.com> X-OriginalArrivalTime: 26 Jun 2013 10:44:43.0431 (UTC) FILETIME=[2AFF2370:01CE725A] Subject: [wpkops] RV: New Version Notification for draft-barreira-wpkops-trustmodel-00.txt X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:44:58 -0000 Sorry, forgot to send it to the list A new version of I-D, draft-barreira-wpkops-trustmodel-00.txt has been successfully submitted by Inigo Barreira and posted to the IETF repository. Filename: draft-barreira-wpkops-trustmodel Revision: 00 Title: Trust models of the Web PKI Creation date: 2013-06-26 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-barreira-wpkops-trustmodel-00.txt Status: http://datatracker.ietf.org/doc/draft-barreira-wpkops-trustmodel Htmlized: http://tools.ietf.org/html/draft-barreira-wpkops-trustmodel-00 Abstract: This is one of a set of documents to define the operation of the Web PKI. It describes the currently deployed Web PKI trust model and common variants. The IETF Secretariat From stephen.farrell@cs.tcd.ie Wed Jun 26 03:51:53 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6972021F9BB2 for ; Wed, 26 Jun 2013 03:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgbubMc6tFUY for ; Wed, 26 Jun 2013 03:51:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BC24B21F9D50 for ; Wed, 26 Jun 2013 03:51:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F5C1BE75; Wed, 26 Jun 2013 11:51:04 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDN+kCwT46RP; Wed, 26 Jun 2013 11:51:04 +0100 (IST) Received: from [IPv6:2001:770:10:203:f41a:f073:48c6:77b5] (unknown [IPv6:2001:770:10:203:f41a:f073:48c6:77b5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06D93BE70; Wed, 26 Jun 2013 11:51:04 +0100 (IST) Message-ID: <51CAC798.60005@cs.tcd.ie> Date: Wed, 26 Jun 2013 11:51:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: i-barreira@izenpe.net References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: bergtau@gmail.com, wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:51:53 -0000 Hi, On 06/26/2013 11:34 AM, i-barreira@izenpe.net wrote: > For example, in the EU there´s a so called Trust Service Status List > (commonly called TSL) which is another trust store managed by every > EU member state and regulated by law in which there´s a list with all > CAs (and issuing CAs and services) that fulfill the requirements > imposed by law that follow some ETSI standards. This is mandate for > all the CAs offering qualified certificates but it´s also possible > for non qualified certs, like SSL. This is also web PKI because these > services are consumed thru web services for example on a machine > readable process or thru a web site for human readable process. How does that square with the charter requirement that this wg not delve into stuff that's not much used? The charter says: Only server-authentication behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers is to be considered. While it is not intended to apply the threshold with any precision, it will be used to justify the inclusion or exclusion of a technique. Is there any evidence as to the level of use of all that ETSI stuff? My impression is that it'd not meet the rough threshold above. BTW: I'd really like to know, I'm not (only) trying to simplify the work here:-) But simplifying the work here seems like something that is needed for progress given the relative lack of activity. Thanks, S. From sharon.boeyen@entrust.com Wed Jun 26 06:04:32 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED1211E81BF for ; Wed, 26 Jun 2013 06:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24WgwJoyUW6m for ; Wed, 26 Jun 2013 06:04:28 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4BC11E81BB for ; Wed, 26 Jun 2013 06:04:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,944,1363147200"; d="scan'208";a="9385402" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 26 Jun 2013 09:04:27 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 09:04:27 -0400 From: Sharon Boeyen To: wpkops WG Thread-Topic: [wpkops] Silence is deafening - Trust Model Paper Thread-Index: Ac5w+ZSoQsntgfnhSwGtPfDMuxnBDwAVfqUAAANhouAABx4XgAAaeCiAAAG4CAAAAGkNgAAgMIFg Date: Wed, 26 Jun 2013 13:04:26 +0000 Message-ID: <65DA4BEA501AFC409DF274CC71ED01A57C6A0859@SOTTEXCH10.corp.ad.entrust.com> References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <51C9D230.4060300@bbn.com> <51C9D4F1.8080905@bogus.com> In-Reply-To: <51C9D4F1.8080905@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.161.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:04:32 -0000 I also came on as WG co-chair after the group was chartered. I do not belie= ve that even considering any attempt to expand the charter at this point i= s a good idea. The documents need to fit within the charter as it is curren= tly stated. If additional work is desirable that can be noted and put on th= e back burner for the future (whether that be as part of an eventual re-cha= rtering of this group or done in a different WG).=20 At the March meeting it was evident to me that this WG has a huge amount of= work on its plate already. Since that meeting the group has been quite ina= ctive - not a good combination! We finally have some good discussion going = on that I hope will lead us to the point where we get a solid trust model d= raft that fits within the charter scope (describes current situation and is= restricted to web pki) that will form the basis for future work.=20 Cheers, Sharon -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= joel jaeggli Sent: Tuesday, June 25, 2013 1:36 PM To: Stephen Kent; wpkops WG Subject: Re: [wpkops] Silence is deafening - Trust Model Paper I came on as AD right after this WG was chartered effectively. If we seriously consider rechartering at this point we're basically declari= ng the original a failure, which is fine I guess, but I think the IESG is g= oing to turn a pretty jaundiced eye on that. If something truly does not fit under our charter it might well advance as = individual submission (I'd have to consider that), socialize it through and= bring it up through opsawg or other alternatives. imho it's premature to r= eally explore this. On 6/25/13 10:24 AM, Stephen Kent wrote: > Michael, > > I agree with Paul's observations. The charter for the WG is=20 > intentionally narrow. > If folks decide to revise it to be broader, there is no guarantee that=20 > a new, broader charter will be approved. With that in mind, the trust=20 > model doc needs a LOT of work. > Phrases like "is supposed to" may be appropriate, but they ought not=20 > figure prominently, as the goal here is to document how browsers and=20 > the public TA/CA really work. > > Steve > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From d.w.chadwick@kent.ac.uk Wed Jun 26 08:22:11 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5411E812C for ; Wed, 26 Jun 2013 08:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ziS3vbaSo2W for ; Wed, 26 Jun 2013 08:22:06 -0700 (PDT) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7511E8121 for ; Wed, 26 Jun 2013 08:22:06 -0700 (PDT) Received: from [41.221.86.210] (helo=[172.16.0.169]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UrrXh-0002Ws-0G; Wed, 26 Jun 2013 16:21:57 +0100 Message-ID: <51CB0704.2010206@kent.ac.uk> Date: Wed, 26 Jun 2013 16:21:40 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sharon Boeyen , "wpkops WG \(wpkops@ietf.org\)" Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:22:11 -0000 I agree with everything Paul says, and in addition, I would add that you need to separate the human user (who is actually the RP and who will suffer any loss) from the certificate using client, which is not the RP but is only the software acting on behalf of the RP, and which is implicitly trusted by the RP (and this trust is often misplaced) regards David On 24/06/2013 23:56, Paul Hoffman wrote: > The model in draft draft-webpki-trustmodel does not match the charter > for this WG. It over-reaches by talking about "certificate-using > clients" that are not web browsers. > > Even if the document is more narrowly scoped to meet the charter, it > still has many problems. It blithely assumes that all CAs follow > their certificate policies (which we have seen is not true), and > states that such certificate polices are "accepted" by client > suppliers, which is only true if "accepted" means "without any real > checking, and generally without any punishment after lapses are > found". > > The draft also says that "the relying party implicitly accepts" the > root store without discussing what this implicit acceptance means. > There is no discussion of what user expectations might be (such as > surprise that governments can cause certificates issued for sites of > enemy governments). > > The WG should consider instead requiring the draft apply to the > real-world Web PKI where browsers makers do not hold CAs accountable > when lapses are found and users do not understand anything about the > role of the root store. > > In other words, the WG should consider a much more realistic draft. > Otherwise, a reader might think that the WG's eventual RFC describes > something operationally useful. > > --Paul Hoffman _______________________________________________ wpkops > mailing list wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From i-barreira@izenpe.net Thu Jun 27 00:04:23 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F6621F9C45 for ; Thu, 27 Jun 2013 00:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+kJn4ZLpMFS for ; Thu, 27 Jun 2013 00:04:17 -0700 (PDT) Received: from correo.euskaltel.es (ektmail2mta2.euskaltel.es [212.55.8.119]) by ietfa.amsl.com (Postfix) with ESMTP id AE0E821F9C42 for ; Thu, 27 Jun 2013 00:04:17 -0700 (PDT) Received: from ejlp024.ejgv ([194.30.48.247]) by ektmail2mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MP100ILKIB4KGB0@ektmail2mta2.euskaltel.es> for wpkops@ietf.org; Thu, 27 Jun 2013 09:04:16 +0200 (MEST) Received: from afe02.ejsarea.net (afe02 [10.200.192.15]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id r5R74G21020100; Thu, 27 Jun 2013 09:04:16 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe02.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jun 2013 09:04:15 +0200 Date: Thu, 27 Jun 2013 09:04:15 +0200 From: i-barreira@izenpe.net In-reply-to: <51CAC798.60005@cs.tcd.ie> To: stephen.farrell@cs.tcd.ie Message-id: <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [wpkops] Silence is deafening - Trust Model Paper Thread-index: Ac5yWxLDh+pF+l6wSAW6dPf+lKK4pAAp6Y9w X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> X-OriginalArrivalTime: 27 Jun 2013 07:04:15.0879 (UTC) FILETIME=[892CA170:01CE7304] Cc: bergtau@gmail.com, wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 07:04:23 -0000 Hi, I don=B4t know the numbers because I=B4m not managing it, this is = typically done at the ministers in the national governments which are = the responsible for managing the TSL, but in any case, I sent an email = asking for these numbers, which in any case it=B4s only for one country. OTOH, I think this is not about percentages (or at least I don=B4t see = that way) since these TSL are mandated by law. But, if numbers are = needed, there are 27 (EU member states) reliable trust stores that must = be considered, not just 5 (browsers) and you can add Adobe and Oracle = (also have root stores). IMHO, this document has to take into account all options because if we = are only dealing with browsers then I think the CAB forum is doing it = now and it will be a useless or repeated (similar) work. Here=B4s a link on recent news of Adobe if it=B4s of interest. http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approved-t= rust-list-aatl-and-eu-trust-list-eutl/ Regards I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. -----Mensaje original----- De: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Enviado el: mi=E9rcoles, 26 de junio de 2013 12:51 Para: Barreira Iglesias, I=F1igo CC: bergtau@gmail.com; wpkops@ietf.org Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper Hi, On 06/26/2013 11:34 AM, i-barreira@izenpe.net wrote: > For example, in the EU there=B4s a so called Trust Service Status List = > (commonly called TSL) which is another trust store managed by every EU = > member state and regulated by law in which there=B4s a list with all = CAs=20 > (and issuing CAs and services) that fulfill the requirements imposed=20 > by law that follow some ETSI standards. This is mandate for all the=20 > CAs offering qualified certificates but it=B4s also possible for non=20 > qualified certs, like SSL. This is also web PKI because these services = > are consumed thru web services for example on a machine readable=20 > process or thru a web site for human readable process. How does that square with the charter requirement that this wg not delve = into stuff that's not much used? The charter says: Only server-authentication behavior encountered in more than 0.1 percent of connections made by desktop and mobile browsers is to be considered. While it is not intended to apply the threshold with any precision, it will be used to justify the inclusion or exclusion of a technique. Is there any evidence as to the level of use of all that ETSI stuff? My = impression is that it'd not meet the rough threshold above. BTW: I'd really like to know, I'm not (only) trying to simplify the work = here:-) But simplifying the work here seems like something that is = needed for progress given the relative lack of activity. Thanks, S. From stephen.farrell@cs.tcd.ie Thu Jun 27 02:10:36 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B0621F9CAA for ; Thu, 27 Jun 2013 02:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1pYHIeJPabh for ; Thu, 27 Jun 2013 02:10:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0441D21F9CB2 for ; Thu, 27 Jun 2013 02:10:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 182FFBE6E; Thu, 27 Jun 2013 10:10:03 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgFNeNowco0M; Thu, 27 Jun 2013 10:09:56 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.16.114]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 342D4BE61; Thu, 27 Jun 2013 10:09:56 +0100 (IST) Message-ID: <51CC0164.2050505@cs.tcd.ie> Date: Thu, 27 Jun 2013 10:09:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: i-barreira@izenpe.net References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: bergtau@gmail.com, wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 09:10:36 -0000 Hiya, On 06/27/2013 08:04 AM, i-barreira@izenpe.net wrote: > Hi, > > I don´t know the numbers because I´m not managing it, this is > typically done at the ministers in the national governments which are > the responsible for managing the TSL, Those would be the wrong numbers I think. The numbers of interest relate to real-world usage in TLS sessions. I'd be very surprised if any of the ETSI stuff showed up in anything near 0.1% of TLS sessions. If it does not then this WG should just ignore it and concentrate on the 99.9% of stuff that actually happens. Is anyone claiming that the ETSI stuff shows up in >0.1% of TLS sessions? > but in any case, I sent an > email asking for these numbers, which in any case it´s only for one > country. > > OTOH, I think this is not about percentages (or at least I don´t see > that way) since these TSL are mandated by law. So what? There are loads of digital signature related laws in the world. They are all irrelevant for this wg unless they impact on what is actually used to a non-negligible extent in the real web pki. > But, if numbers are > needed, there are 27 (EU member states) reliable trust stores that > must be considered, not just 5 (browsers) and you can add Adobe and > Oracle (also have root stores). Wrong numbers again. This has nothing to do with how many implementations exist but rather with what is really commonly used. > IMHO, this document has to take into account all options because if > we are only dealing with browsers then I think the CAB forum is doing > it now and it will be a useless or repeated (similar) work. That ("take into account all the options") sounds like a recipe for failure to me given the lack of activity here and the history that the PKI community has of spending way too much time on niche corner cases and ignoring what's actually commonly done. (Sorry that's a bit of a rant and I'm as guilty as anyone, or was in the past - I'm reformed now:-) S. > > Here´s a link on recent news of Adobe if it´s of interest. > http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approved-trust-list-aatl-and-eu-trust-list-eutl/ > > Regards > > > Ińigo Barreira Responsable del Área técnica i-barreira@izenpe.net > 945067705 > > > ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta > egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada > (helbidea gaizki idatzi, transmisioak huts egin) eman abisu > igorleari, korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje > contiene informacion privilegiada o confidencial a la que solo tiene > derecho a acceder el destinatario. Si usted lo recibe por error le > agradeceriamos que no hiciera uso de la informacion y que se pusiese > en contacto con el remitente. > > > -----Mensaje original----- De: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Enviado el: miércoles, 26 de junio > de 2013 12:51 Para: Barreira Iglesias, Ińigo CC: bergtau@gmail.com; > wpkops@ietf.org Asunto: Re: [wpkops] Silence is deafening - Trust > Model Paper > > > Hi, > > On 06/26/2013 11:34 AM, i-barreira@izenpe.net wrote: >> For example, in the EU there´s a so called Trust Service Status >> List (commonly called TSL) which is another trust store managed by >> every EU member state and regulated by law in which there´s a list >> with all CAs (and issuing CAs and services) that fulfill the >> requirements imposed by law that follow some ETSI standards. This >> is mandate for all the CAs offering qualified certificates but it´s >> also possible for non qualified certs, like SSL. This is also web >> PKI because these services are consumed thru web services for >> example on a machine readable process or thru a web site for human >> readable process. > > How does that square with the charter requirement that this wg not > delve into stuff that's not much used? > > The charter says: > > Only server-authentication behavior encountered in more than 0.1 > percent of connections made by desktop and mobile browsers is to be > considered. While it is not intended to apply the threshold with any > precision, it will be used to justify the inclusion or exclusion of a > technique. > > Is there any evidence as to the level of use of all that ETSI stuff? > My impression is that it'd not meet the rough threshold above. > > BTW: I'd really like to know, I'm not (only) trying to simplify the > work here:-) But simplifying the work here seems like something that > is needed for progress given the relative lack of activity. > > Thanks, S. > > From i-barreira@izenpe.net Thu Jun 27 05:27:38 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E245321F9B65 for ; Thu, 27 Jun 2013 05:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q+Ia7zjWUoa for ; Thu, 27 Jun 2013 05:27:33 -0700 (PDT) Received: from correo.euskaltel.es (ektmail2mta2.euskaltel.es [212.55.8.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD4221F9A84 for ; Thu, 27 Jun 2013 05:27:31 -0700 (PDT) Received: from ejlp024.ejgv ([194.30.48.247]) by ektmail2mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MP1005TEX9U01I0@ektmail2mta2.euskaltel.es> for wpkops@ietf.org; Thu, 27 Jun 2013 14:27:30 +0200 (MEST) Received: from EJWP052.ejsarea.net ([10.200.192.73]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id r5RCRUip006768; Thu, 27 Jun 2013 14:27:30 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by EJWP052.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jun 2013 14:27:30 +0200 Date: Thu, 27 Jun 2013 14:27:29 +0200 From: i-barreira@izenpe.net In-reply-to: <51CC0164.2050505@cs.tcd.ie> To: stephen.farrell@cs.tcd.ie Message-id: <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="Boundary_(ID_eQVHfC9ZGZYw/EMeGGZaow)" Content-class: urn:content-classes:message Thread-topic: [wpkops] Silence is deafening - Trust Model Paper Thread-index: Ac5zFh/ALj7nfwfHR0qY6OIYGfXTUwAGraPg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> X-OriginalArrivalTime: 27 Jun 2013 12:27:30.0432 (UTC) FILETIME=[B13A9000:01CE7331] Cc: bergtau@gmail.com, wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:27:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_eQVHfC9ZGZYw/EMeGGZaow) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi =20 Then we=B4re assuming that web PKI means only TLS connections, am I = right? So "web" is used only in "browsers"? I think this is not fair. We = are talking about trust models and browsers root stores is only "one" of = these models, not the only one and we should consider the others.=20 I don=B4t get why we are assuming that web PKI is only referred to the = browsers, and if so, the document could be very simple, just pointing to = the browsers policies or leave it to the CAB Forum, which is not a = standards body like it can be IETF.=20 If we=B4re to produce a standard on trust models we should consider all = options, not just one because it=B4s the most used. That is not an = standard. =20 Regards =20 Hiya, =20 On 06/27/2013 08:04 AM, i-barreira@izenpe.net = wrote: > Hi, >=20 > I don=B4t know the numbers because I=B4m not managing it, this is=20 > typically done at the ministers in the national governments which are=20 > the responsible for managing the TSL, =20 Those would be the wrong numbers I think. =20 The numbers of interest relate to real-world usage in TLS sessions. I'd = be very surprised if any of the ETSI stuff showed up in anything near = 0.1% of TLS sessions. =20 If it does not then this WG should just ignore it and concentrate on the = 99.9% of stuff that actually happens. =20 Is anyone claiming that the ETSI stuff shows up in >0.1% of TLS = sessions? =20 > but in any case, I sent an > email asking for these numbers, which in any case it=B4s only for one=20 > country. >=20 > OTOH, I think this is not about percentages (or at least I don=B4t see = > that way) since these TSL are mandated by law. =20 So what? There are loads of digital signature related laws in the world. = They are all irrelevant for this wg unless they impact on what is = actually used to a non-negligible extent in the real web pki. =20 > But, if numbers are > needed, there are 27 (EU member states) reliable trust stores that=20 > must be considered, not just 5 (browsers) and you can add Adobe and=20 > Oracle (also have root stores). =20 Wrong numbers again. This has nothing to do with how many = implementations exist but rather with what is really commonly used. =20 > IMHO, this document has to take into account all options because if we = > are only dealing with browsers then I think the CAB forum is doing it=20 > now and it will be a useless or repeated (similar) work. =20 That ("take into account all the options") sounds like a recipe for = failure to me given the lack of activity here and the history that the = PKI community has of spending way too much time on niche corner cases = and ignoring what's actually commonly done. (Sorry that's a bit of a = rant and I'm as guilty as anyone, or was in the past - I'm reformed = now:-) =20 S. =20 >=20 > Here=B4s a link on recent news of Adobe if it=B4s of interest.=20 > http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approve = = > d-trust-list-aatl-and-eu-trust-list-eutl/ >=20 > Regards >=20 >=20 > I=F1igo Barreira Responsable del =C1rea t=E9cnica = i-barreira@izenpe.net =20 > 945067705 >=20 >=20 > ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta=20 > egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada=20 > (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = > korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene=20 > informacion privilegiada o confidencial a la que solo tiene derecho a=20 > acceder el destinatario. Si usted lo recibe por error le=20 > agradeceriamos que no hiciera uso de la informacion y que se pusiese=20 > en contacto con el remitente. >=20 >=20 > -----Mensaje original----- De: Stephen Farrell=20 > [mailto:stephen.farrell@cs.tcd.ie] = Enviado el: mi=E9rcoles, 26 = de junio=20 > de 2013 12:51 Para: Barreira Iglesias, I=F1igo CC: bergtau@gmail.com = ;=20 > wpkops@ietf.org Asunto: Re: [wpkops] Silence = is deafening - Trust=20 > Model Paper >=20 >=20 > Hi, >=20 > On 06/26/2013 11:34 AM, i-barreira@izenpe.net = wrote: >> For example, in the EU there=B4s a so called Trust Service Status = List=20 >> (commonly called TSL) which is another trust store managed by every=20 >> EU member state and regulated by law in which there=B4s a list with = all=20 >> CAs (and issuing CAs and services) that fulfill the requirements=20 >> imposed by law that follow some ETSI standards. This is mandate for=20 >> all the CAs offering qualified certificates but it=B4s also possible=20 >> for non qualified certs, like SSL. This is also web PKI because these = >> services are consumed thru web services for example on a machine=20 >> readable process or thru a web site for human readable process. >=20 > How does that square with the charter requirement that this wg not=20 > delve into stuff that's not much used? >=20 > The charter says: >=20 > Only server-authentication behavior encountered in more than 0.1=20 > percent of connections made by desktop and mobile browsers is to be=20 > considered. While it is not intended to apply the threshold with any=20 > precision, it will be used to justify the inclusion or exclusion of a=20 > technique. >=20 > Is there any evidence as to the level of use of all that ETSI stuff? > My impression is that it'd not meet the rough threshold above. >=20 > BTW: I'd really like to know, I'm not (only) trying to simplify the=20 > work here:-) But simplifying the work here seems like something that=20 > is needed for progress given the relative lack of activity. >=20 > Thanks, S. >=20 >=20 =20 --Boundary_(ID_eQVHfC9ZGZYw/EMeGGZaow) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi

 

Then we=B4re assuming that web PKI means only TLS = connections, am I right? So “web” is used only in = “browsers”? I think this is not fair. We are talking about = trust models and browsers root stores is only “one” of these = models, not the only one and we should consider the others. =

I = don=B4t get why we are assuming that web PKI is only referred to the = browsers, and if so, the document could be very simple, just pointing to = the browsers policies or leave it to the CAB Forum, which is not a = standards body like it can be IETF.

If we=B4re to produce a standard = on trust models we should consider all options, not just one because = it=B4s the most used. That is not an standard.

 

Regards

 

Hiya,

 

On 06/27/2013 08:04 AM, = i-barreira@izenpe.net wrote:

> = Hi,

>

> I don=B4t know the numbers because I=B4m not = managing it, this is

> = typically done at the ministers in the national governments which are =

> the responsible for managing = the TSL,

 

Those would be the wrong numbers I = think.

 

The numbers of interest relate to real-world usage = in TLS sessions. I'd be very surprised if any of the ETSI stuff showed = up in anything near 0.1% of TLS sessions.

 

If it = does not then this WG should just ignore it and concentrate on the 99.9% = of stuff that actually happens.

 

Is = anyone claiming that the ETSI stuff shows up in >0.1% of TLS = sessions?

 

> but in any case, I sent an

> email asking for these numbers, which in any = case it=B4s only for one

> = country.

>

> OTOH, I think this is not about percentages = (or at least I don=B4t see

> = that way) since these TSL are mandated by law.

 

So = what? There are loads of digital signature related laws in the world. = They are all irrelevant for this wg unless they impact on what is = actually used to a non-negligible extent in the real web = pki.

 

> But, if numbers are

> needed, there are 27 (EU member states) = reliable trust stores that

> = must be considered, not just 5 (browsers) and you can add Adobe and =

> Oracle (also have root = stores).

 

Wrong numbers again. This has nothing to do with = how many implementations exist but rather with what is really commonly = used.

 

> IMHO, this document has to take into account = all options because if we

> = are only dealing with browsers then I think the CAB forum is doing it =

> now and it will be a useless = or repeated (similar) work.

 

That = ("take into account all the options") sounds like a recipe for = failure to me given the lack of activity here and the history that the = PKI community has of spending way too much time on niche corner cases = and ignoring what's actually commonly done. (Sorry that's a bit of a = rant and I'm as guilty as anyone, or was in the past - I'm reformed = now:-)

 

S.

 

> =

> Here=B4s a link on recent = news of Adobe if it=B4s of interest.

> http://blogs.adobe.com/st= andards/2013/06/25/alignment-of-adobe-approve

> = d-trust-list-aatl-and-eu-trust-list-eutl/

> 

>=A0 Regards

>

> =

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

> = 945067705

>

>

> = ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta =

> egotea. Mezua badu bere = hartzailea. Okerreko helbidera heldu bada

> (helbidea gaizki idatzi, transmisioak huts = egin) eman abisu igorleari,

> = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene =

> informacion privilegiada o = confidencial a la que solo tiene derecho a

> acceder el destinatario. Si usted lo recibe = por error le

> agradeceriamos = que no hiciera uso de la informacion y que se pusiese

> en contacto con el remitente.

>

> =

> -----Mensaje original----- = De: Stephen Farrell

> [mailto:stephen.farrell@c= s.tcd.ie] Enviado el: mi=E9rcoles, 26 de junio =

> de 2013 12:51 Para: Barreira = Iglesias, I=F1igo CC: bergtau@gmail.com<= /a>;

> wpkops@ietf.org Asunto: Re: [wpkops] Silence is deafening - Trust

> Model Paper

>

> =

> Hi,

>

> On = 06/26/2013 11:34 AM, i-barreira@izenpe.net wrote:

>> For = example, in the EU there=B4s a so called Trust Service Status List =

>> (commonly called TSL) = which is another trust store managed by every

>> EU member state and regulated by law in = which there=B4s a list with all

>> CAs (and issuing CAs and services) that = fulfill the requirements

>> = imposed by law that follow some ETSI standards. This is mandate for =

>> all the CAs offering = qualified certificates but it=B4s also possible

>> for non qualified certs, like SSL. This is = also web PKI because these

>> services are consumed thru web services = for example on a machine

>> = readable process or thru a web site for human readable = process.

>

> How does that square with the charter = requirement that this wg not

> = delve into stuff that's not much used?

>

> = The charter says:

> =

> Only server-authentication = behavior encountered in more than 0.1

> percent of connections made by desktop and = mobile browsers is to be

> = considered.=A0 While it is not intended to apply the threshold with any =

> precision, it will be used = to justify the inclusion or exclusion of a

> technique.

>

> Is = there any evidence as to the level of use of all that ETSI = stuff?

> My impression is that = it'd not meet the rough threshold above.

>

> = BTW: I'd really like to know, I'm not (only) trying to simplify the =

> work here:-) But simplifying = the work here seems like something that

> is needed for progress given the relative lack = of activity.

> =

> Thanks, S.

>

> =

 

= --Boundary_(ID_eQVHfC9ZGZYw/EMeGGZaow)-- From i-barreira@izenpe.net Thu Jun 27 05:31:41 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A6C21F997E for ; Thu, 27 Jun 2013 05:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qneueARtJyJ7 for ; Thu, 27 Jun 2013 05:31:35 -0700 (PDT) Received: from correo.euskaltel.es (ektmail1mta2.euskaltel.es [212.55.8.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4764221F8BB7 for ; Thu, 27 Jun 2013 05:31:34 -0700 (PDT) Received: from ejlp023.ejgv ([195.77.108.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MP1005DKXGL7Q00@ektmail1mta2.euskaltel.es> for wpkops@ietf.org; Thu, 27 Jun 2013 14:31:34 +0200 (CEST) Received: from afe02.ejsarea.net (afe02 [10.200.192.15]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id r5RCVXg4016811; Thu, 27 Jun 2013 14:31:33 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe02.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Jun 2013 14:31:33 +0200 Date: Thu, 27 Jun 2013 14:31:32 +0200 From: i-barreira@izenpe.net In-reply-to: <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> To: stephen.farrell@cs.tcd.ie Message-id: <763539E260C37C46A0D6B340B5434C3B076D458F@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/related; boundary="Boundary_(ID_aJc0zcBwFnXUxnWQ2rZCRQ)"; type="multipart/alternative" Content-class: urn:content-classes:message Thread-topic: [wpkops] Silence is deafening - Trust Model Paper Thread-index: Ac5zFh/ALj7nfwfHR0qY6OIYGfXTUwAGraPgAABUcmA= X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> X-OriginalArrivalTime: 27 Jun 2013 12:31:33.0356 (UTC) FILETIME=[4205D2C0:01CE7332] Cc: bergtau@gmail.com, wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:31:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_aJc0zcBwFnXUxnWQ2rZCRQ) Content-type: multipart/alternative; boundary="Boundary_(ID_RjjWV2mKAqe9sIYiSOA3ew)" --Boundary_(ID_RjjWV2mKAqe9sIYiSOA3ew) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable About the use of the EU TL, some other points to talk about =20 1. New proposal for e-procurement Directive (COM(2011) 896 final), of 20 = December 2011 E-procurement related provisions: Article 19, Annex IV. = Obligatory recognition of tenders accompanied by a qualified electronic = certificate included in the "Trusted List", if CA asks for any advanced = e-signature. =20 2. Revision of Professional Qualifications Directive (2005/36/EC), = COM(2011) 883 final, 19.12.2011. New Article 57 for PSCs and 57a for = e-procedures, where reference made to Decision 2009/767/EC and 2011/130/EU (for cases where = advanced e-signatures required). =20 =20 =20 I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 =20 =20 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. =20 De: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] En nombre = de i-barreira@izenpe.net Enviado el: jueves, 27 de junio de 2013 14:27 Para: stephen.farrell@cs.tcd.ie CC: bergtau@gmail.com; wpkops@ietf.org Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper =20 Hi =20 Then we=B4re assuming that web PKI means only TLS connections, am I = right? So "web" is used only in "browsers"? I think this is not fair. We = are talking about trust models and browsers root stores is only "one" of = these models, not the only one and we should consider the others.=20 I don=B4t get why we are assuming that web PKI is only referred to the = browsers, and if so, the document could be very simple, just pointing to = the browsers policies or leave it to the CAB Forum, which is not a = standards body like it can be IETF.=20 If we=B4re to produce a standard on trust models we should consider all = options, not just one because it=B4s the most used. That is not an = standard. =20 Regards =20 Hiya, =20 On 06/27/2013 08:04 AM, i-barreira@izenpe.net = wrote: > Hi, >=20 > I don=B4t know the numbers because I=B4m not managing it, this is=20 > typically done at the ministers in the national governments which are=20 > the responsible for managing the TSL, =20 Those would be the wrong numbers I think. =20 The numbers of interest relate to real-world usage in TLS sessions. I'd = be very surprised if any of the ETSI stuff showed up in anything near = 0.1% of TLS sessions. =20 If it does not then this WG should just ignore it and concentrate on the = 99.9% of stuff that actually happens. =20 Is anyone claiming that the ETSI stuff shows up in >0.1% of TLS = sessions? =20 > but in any case, I sent an > email asking for these numbers, which in any case it=B4s only for one=20 > country. >=20 > OTOH, I think this is not about percentages (or at least I don=B4t see = > that way) since these TSL are mandated by law. =20 So what? There are loads of digital signature related laws in the world. = They are all irrelevant for this wg unless they impact on what is = actually used to a non-negligible extent in the real web pki. =20 > But, if numbers are > needed, there are 27 (EU member states) reliable trust stores that=20 > must be considered, not just 5 (browsers) and you can add Adobe and=20 > Oracle (also have root stores). =20 Wrong numbers again. This has nothing to do with how many = implementations exist but rather with what is really commonly used. =20 > IMHO, this document has to take into account all options because if we = > are only dealing with browsers then I think the CAB forum is doing it=20 > now and it will be a useless or repeated (similar) work. =20 That ("take into account all the options") sounds like a recipe for = failure to me given the lack of activity here and the history that the = PKI community has of spending way too much time on niche corner cases = and ignoring what's actually commonly done. (Sorry that's a bit of a = rant and I'm as guilty as anyone, or was in the past - I'm reformed = now:-) =20 S. =20 >=20 > Here=B4s a link on recent news of Adobe if it=B4s of interest.=20 > http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approve = = > d-trust-list-aatl-and-eu-trust-list-eutl/ >=20 > Regards >=20 >=20 > I=F1igo Barreira Responsable del =C1rea t=E9cnica = i-barreira@izenpe.net =20 > 945067705 >=20 >=20 > ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta=20 > egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada=20 > (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = > korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene=20 > informacion privilegiada o confidencial a la que solo tiene derecho a=20 > acceder el destinatario. Si usted lo recibe por error le=20 > agradeceriamos que no hiciera uso de la informacion y que se pusiese=20 > en contacto con el remitente. >=20 >=20 > -----Mensaje original----- De: Stephen Farrell=20 > [mailto:stephen.farrell@cs.tcd.ie] = Enviado el: mi=E9rcoles, 26 = de junio=20 > de 2013 12:51 Para: Barreira Iglesias, I=F1igo CC: bergtau@gmail.com = ;=20 > wpkops@ietf.org Asunto: Re: [wpkops] Silence = is deafening - Trust=20 > Model Paper >=20 >=20 > Hi, >=20 > On 06/26/2013 11:34 AM, i-barreira@izenpe.net = wrote: >> For example, in the EU there=B4s a so called Trust Service Status = List=20 >> (commonly called TSL) which is another trust store managed by every=20 >> EU member state and regulated by law in which there=B4s a list with = all=20 >> CAs (and issuing CAs and services) that fulfill the requirements=20 >> imposed by law that follow some ETSI standards. This is mandate for=20 >> all the CAs offering qualified certificates but it=B4s also possible=20 >> for non qualified certs, like SSL. This is also web PKI because these = >> services are consumed thru web services for example on a machine=20 >> readable process or thru a web site for human readable process. >=20 > How does that square with the charter requirement that this wg not=20 > delve into stuff that's not much used? >=20 > The charter says: >=20 > Only server-authentication behavior encountered in more than 0.1=20 > percent of connections made by desktop and mobile browsers is to be=20 > considered. While it is not intended to apply the threshold with any=20 > precision, it will be used to justify the inclusion or exclusion of a=20 > technique. >=20 > Is there any evidence as to the level of use of all that ETSI stuff? > My impression is that it'd not meet the rough threshold above. >=20 > BTW: I'd really like to know, I'm not (only) trying to simplify the=20 > work here:-) But simplifying the work here seems like something that=20 > is needed for progress given the relative lack of activity. >=20 > Thanks, S. >=20 >=20 =20 --Boundary_(ID_RjjWV2mKAqe9sIYiSOA3ew) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

About the use of the EU TL, some = other points to talk about

 

1. New = proposal for e-procurement Directive (COM(2011) 896 final), of 20 = December 2011 E-procurement related provisions: Article 19, Annex IV. = Obligatory recognition of tenders accompanied by a qualified electronic = certificate included in the “Trusted List”, if CA asks for = any advanced e-signature.

 

2. Revision = of Professional Qualifications Directive (2005/36/EC), COM(2011) 883 = final, 19.12.2011. New Article 57 for PSCs and 57a for e-procedures, = where

reference made to Decision 2009/767/EC and = 2011/130/EU (for cases where advanced e-signatures = required).

 

 

 <= /p>

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

945067705

 <= /p>

3D"Descripci=F3n:

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

 

De: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] = En nombre de i-barreira@izenpe.net
Enviado el: jueves, = 27 de junio de 2013 14:27
Para: = stephen.farrell@cs.tcd.ie
CC: bergtau@gmail.com; = wpkops@ietf.org
Asunto: Re: [wpkops] Silence is deafening - = Trust Model Paper

 

Hi

 

Then we=B4re assuming that web PKI means only TLS = connections, am I right? So “web” is used only in = “browsers”? I think this is not fair. We are talking about = trust models and browsers root stores is only “one” of these = models, not the only one and we should consider the others. =

I = don=B4t get why we are assuming that web PKI is only referred to the = browsers, and if so, the document could be very simple, just pointing to = the browsers policies or leave it to the CAB Forum, which is not a = standards body like it can be IETF.

If we=B4re to produce a standard = on trust models we should consider all options, not just one because = it=B4s the most used. That is not an standard.

 

Regards

 

Hiya,

 

On 06/27/2013 08:04 AM, = i-barreira@izenpe.net wrote:

> = Hi,

>

> I don=B4t know the numbers because I=B4m not = managing it, this is

> = typically done at the ministers in the national governments which are =

> the responsible for managing = the TSL,

 

Those would be the wrong numbers I = think.

 

The numbers of interest relate to real-world usage = in TLS sessions. I'd be very surprised if any of the ETSI stuff showed = up in anything near 0.1% of TLS sessions.

 

If it = does not then this WG should just ignore it and concentrate on the 99.9% = of stuff that actually happens.

 

Is = anyone claiming that the ETSI stuff shows up in >0.1% of TLS = sessions?

 

> but in any case, I sent an

> email asking for these numbers, which in any = case it=B4s only for one

> = country.

>

> OTOH, I think this is not about percentages = (or at least I don=B4t see

> = that way) since these TSL are mandated by law.

 

So = what? There are loads of digital signature related laws in the world. = They are all irrelevant for this wg unless they impact on what is = actually used to a non-negligible extent in the real web = pki.

 

> But, if numbers are

> needed, there are 27 (EU member states) = reliable trust stores that

> = must be considered, not just 5 (browsers) and you can add Adobe and =

> Oracle (also have root = stores).

 

Wrong numbers again. This has nothing to do with = how many implementations exist but rather with what is really commonly = used.

 

> IMHO, this document has to take into account = all options because if we

> = are only dealing with browsers then I think the CAB forum is doing it =

> now and it will be a useless = or repeated (similar) work.

 

That = ("take into account all the options") sounds like a recipe for = failure to me given the lack of activity here and the history that the = PKI community has of spending way too much time on niche corner cases = and ignoring what's actually commonly done. (Sorry that's a bit of a = rant and I'm as guilty as anyone, or was in the past - I'm reformed = now:-)

 

S.

 

> =

> Here=B4s a link on recent = news of Adobe if it=B4s of interest.

> http://blogs.adobe.com/st= andards/2013/06/25/alignment-of-adobe-approve

> = d-trust-list-aatl-and-eu-trust-list-eutl/

> 

>  Regards

>

> =

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

> = 945067705

>

>

> = ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta =

> egotea. Mezua badu bere = hartzailea. Okerreko helbidera heldu bada

> (helbidea gaizki idatzi, transmisioak huts = egin) eman abisu igorleari,

> = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene =

> informacion privilegiada o = confidencial a la que solo tiene derecho a

> acceder el destinatario. Si usted lo recibe = por error le

> agradeceriamos = que no hiciera uso de la informacion y que se pusiese

> en contacto con el remitente.

>

> =

> -----Mensaje original----- = De: Stephen Farrell

> [mailto:stephen.farrell@c= s.tcd.ie] Enviado el: mi=E9rcoles, 26 de junio =

> de 2013 12:51 Para: Barreira = Iglesias, I=F1igo CC: bergtau@gmail.com<= /a>;

> wpkops@ietf.org Asunto: Re: [wpkops] Silence is deafening - Trust

> Model Paper

>

> =

> Hi,

>

> On = 06/26/2013 11:34 AM, i-barreira@izenpe.net wrote:

>> For = example, in the EU there=B4s a so called Trust Service Status List =

>> (commonly called TSL) = which is another trust store managed by every

>> EU member state and regulated by law in = which there=B4s a list with all

>> CAs (and issuing CAs and services) that = fulfill the requirements

>> = imposed by law that follow some ETSI standards. This is mandate for =

>> all the CAs offering = qualified certificates but it=B4s also possible

>> for non qualified certs, like SSL. This is = also web PKI because these

>> services are consumed thru web services = for example on a machine

>> = readable process or thru a web site for human readable = process.

>

> How does that square with the charter = requirement that this wg not

> = delve into stuff that's not much used?

>

> = The charter says:

> =

> Only server-authentication = behavior encountered in more than 0.1

> percent of connections made by desktop and = mobile browsers is to be

> = considered.  While it is not intended to apply the threshold with = any

> precision, it will be = used to justify the inclusion or exclusion of a

> technique.

>

> Is = there any evidence as to the level of use of all that ETSI = stuff?

> My impression is that = it'd not meet the rough threshold above.

>

> = BTW: I'd really like to know, I'm not (only) trying to simplify the =

> work here:-) But simplifying = the work here seems like something that

> is needed for progress given the relative lack = of activity.

> =

> Thanks, S.

>

> =

 

= --Boundary_(ID_RjjWV2mKAqe9sIYiSOA3ew)-- --Boundary_(ID_aJc0zcBwFnXUxnWQ2rZCRQ) Content-id: Content-type: image/png; name=image001.png Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.png Content-description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAkkAAABvCAIAAAB3iMNhAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAASlZJREFUeF7tXQd4HNXVndned7XqvViSZcm9yLiC7RgwNtWAA0looSUhBUJI QjUtTk8I+UO3DQSMjQEbN9yrbElWsXrvva2k7bNl5j9vV5ZFM8Je2RDe++z9dmfmvXlzZjVn7333 nssKgsB8/eZEF55h3AwjYRgMgH9442IYOcNgH17x3r8Lh0m/ZBftNRIoigZFg/6l0OcGfYp+jlNY JyNXfG2WYkfDbV5e6Lc7KlsGdxY1HK5rKWjocnJ2xmxj5DKG9zAMyzAiRvAwUilj5xi1gnFyjFTG eD2MyLfL42FkUobjGKWCcXCMjPaiaNDvBv1Loc8N+jwcHTsYDXqFPD0uaGZs3NWzkiZFG0PVCrFI dHa6+2puy2vo3phTtvFkZVePOUynzkgwZiYnxwWLtHIDy/JiMetyE8tPLmPdboEXWJYR5HLW6RQY lpVJsIXxeLFNUCpZh4NsFIsE2ouiQb8b9C+FPjfo8/Ar2QHWUb/d1tlrzaprruswt1sHNFrNbTPT blswaWpc2Fno7Wzc1tRvfetQ4Yu7i9Qa8YqpKddMTZmTFqeR4NcWbRQBigBFgCJAEbigCMB6OlLV vr2k7uPcSpPd8ZPFk++7dFZ8iPYLJ/Gl3La/ouFX/z3Y0Wv5xbJZP1g4aZzxi/tf0CujJ6MIUAQo AhSB7zwCzf3mV/YU/mdfXnhYyJ9XzrlmeurnIfkCbnN5mN9/tO+F3afunJ9+/2UzZyScze77zoNM AaAIUAQoAhSBi4BAcXP3K0fL1h48efe8SU/fssSokI2cxGe5DVGNd7+8fd3BvH/df9MDi9JZEidC G0WAIkARoAhQBL6JCKzPKb/31Y/vWjDt5TuuGDm/z4aaPLclZ93+ovd+e8vPF2VQYvsm3kk6J4oA RYAiQBE4jcAds9M/eODGd46XP78950u5bX9l4592ZP3nZ9etmj6eQkcRoAhQBCgCFIFvPgJXT0v+ /fK5j288sKe6eXi2Z+y2xr7BX7y2Y2VG3I/npX3zL4bOkCJAEaAIUAQoAn4EfnXljGvSU+7524eN Xf3+LUPcxvP8S3tOdbvFD96wUCYVU7woAhQBigBFgCLwbUFAJZf8+a6lvEL63NYTbg/iRk5zW3Zt x2t78x5dMWPaWbPhvi3XSedJEaAIUAQoAt8pBMaH65+6Yd4bh/Nz63uGuM3DCxvza0KD1DdmUm/k d+rLQC+WIkARoAj87yDwo4WTJsdE/emT40Pc1mNzfpBbsWxmcqyBJmj/79xmeiUUAYoAReA7hYCc FX9/Yfq2E5Vmp4ustxW29pp6rCumJo8WBbeHqalg6uuZ+hqmvo6pryVvqqtH250eRxGgCFAEKAIU gTFA4ObMCQwv7K5oIbnbD75zcEt+TcUff6yQjSKKZNDiWvM009PA8HJGyjMeXxYchnF65NNmMA/+ zqf9TxtFgCJAEaAIfLMQQP2cxh6ryW4XeN7LeyVSqZtzyRRyvOK91+th0RiRb5fk07u8vl2sl/ec Wy+xRCpnhHC9IVwvH2tN4omPvj4jJZJw28yn3o4O02z92fWjuQ+ubR/ya551qFVKGSO4Ga8YEv+M FJUAxAzXO6h77Q12yuzhcewe3mrj7Dy/v7xOyogUMklUsGFKbOjewpp+jnN7RIvS4iQ8o9LKInVK zu1tNNkTQpQnqjpru3qlUtHl0yZEqqVHG1qrG828IATrFAvSIkM1qtHMkx5DEaAIUAQoAn4EPsiv eS+7orStx+L0eJwO1NcUJAzr4XiJVOQWC1Iv6/EIYjzTWVZwCWKW9Uh5qSByOQWpgvWwgtiNYpys IBHE596LlcnlUqlep8pMCnvkiktTojRjdHd++c6+A5WNxCdZ2TEwOzpqlKeRoU6bRKLQGRhWyar1 YolaItcwSi0jUko1WqbPPnKcqq7+LUW1LsGjlqvUWvmJ2u5nP86q7jOvz6mWyFWMSGRUqd4rrLzp Xx+jV7+DeyentKDR9H5upc3NdNtdN/xrA7a/erC022pXaFivIEjB/bRRBCgCFAGKwOgQQIHNm1/e fuOfN2w+VlzZ0tPW2dPlcHV53N2Dli6X0MN5ujxcd7+1y8t0u9zdNmuX3d3N8V1eV0/fYBcv6na6 ujhHt8XR7eLPq5db6OwdbDLbMInXd5Ze8vjrj24/6hJIsH7AW2ZCbGOfU4Qq2TbOEWL8ijpvw6fn nC4YaazT4ZXxTpeTFcMp6ea8Lnxk3S5G/SmHpEQQBm12NSv6/szklZNTiuo6V1+7kPe6p40LvT0z 5f5LM0L1Up1CUd7S2tFnlqGwm8DwIiEyXHPdrJTfXD7zkrio9cfKgsTiX62Y+aPM9JtmJRvko/Ca BhwqOiBFgCJAEfgWInCkplV9+5r39+SSpSIlnIJeUhoajIKa0goF4/UyYjGD5zacYR5YZnDBiRmx r2asy8XoNAznYsSgBvSCUcGTctPn3MvjZfQaxolhlYzcY/I417y2O+P3r1WbLAHHNTRE7bDbRaR4 6IA5wmAc5QnkSgUpP6pQil3wMcoFrxh4yMUyfBRQ99v22WHkKFQqIoT0QXGNSMrMSQzlHF67xc3x /IAdxMqIJbKfXj3rxSNFGplUIfASN8/yEouD7OowWydE6txyRVNXv83psnFueCZHOU96GEWAIkAR +C4jsD6natFj77i8DBNsYFRKQlRgJgmWkWCdiAhpKRWM3UF24ZkOhyQITyIl5OfmUGyaQIcDnHgf oF42B6PGuUSMBIMLTJC2tqpt2u9eKu40BfY2GZUK1MMGP+M6FU7XaG1DF7lUhsMrCSRx8WLg4WG8 bkYiuMD/n44jwSe32836DM8/vJ/9n3uW4o3g5neeqrl37Z6fvHugvt86YLX+aNbktgFHSYtJLpcw SqGso2vdkVP3vLkjMSRo9rjY9o6uhzYee+DNQy/sLTT56JA2igBFgCJAETgLAltO1f7m9S08lpDA ZLDPQGyw2ziOQZS7CKaYwMCQwmMcZANDAgfgQS6W4nlNLDZYaTiM58eyl4SYiXqVvdN+2ZP/bekP pPXGC5yE2J5ShpG4Ry+zJZFJGSejkEkFD+sVS8U8iyARr0gCY1culjCiT9lV+CCTyvRa1eotWdfO Sk01BuFm8DLm6ksy3rz7yg13X5UUpOFcLjfPPLZs7t/25Mrwk4EXJ+h1105Pe+GHl6+56VIcL1fK X7/jynX3Xf7oiswQ3AnaKAIUAYoAReDLETjZ0v3wO/t6BznGoGBgMLjceBDDiGHgQoOlAW6TSAif +W04qZTwHLb4Q9xJpCTLSC9IL5w9XNff27v87+8H9H6S6EYRXKm4YO9ozTaGd3KCl/C8AHcm70Xo DOhXEMhH8qNACwTPNOyQidiS1p681t4nVwzFT3o8vFjkHj4Isah9DmdqhEYiEo5XNklYiUohjwnS qfAjwtc8do9aRZfZAnrr6WAUAYrA/ygCHoH/KLesrrEDJgiDStMeD7HY8AqbDOQFryN57yFsBwbA Rthn8ECC3rARy29gPmy8YL1gJmpVJSdrcxo6AndDwNt+PUmXMPqUNMmM6bKISM4+yFo5iZPz2hwe h13sdLEDNiEhgUn6lGqXVCLVKqRbT1bwHuHVrOK/78t783jloM2JcJ0XDxT+ZfdJBFIGBSlEWPNj mFvmT7HbPSqpWAnQQZmnm1ot++OO4y/uK1qfVdpt+dyCXuDwoCNRBCgCFIFvOwLtfZaDBc2MSMZI fL7HoYWizz/jTxfo/OKnv3/rhekF/57qiQ/3Bw55Mm3W7uZVN67+4Kkf3jAtZbRDnyrgOmolXgWA E8QkukOEYEmsTCYmiiZMHAmG3eUZdHD9VnuP2Sng14DHo1bK4oO0DT2DLp73ePn0qFCs2ukVKr1S xnn5mnZTYri+x+oI16mUsJF9rbitu3PQLhZEMoVoSnSoTkHTAEZ7o+hxFAGKwHcNgQM1LUueeZf4 HhHxCH8jzDL4JPEGj2hYZtiO9+A8/8IbHrMw0eC4gxMS3ki8R7vwvewusUzW8OIvYvUBeLznNnXP Xb2etTt51e3Pb/r1qptmjZrbvmtfFnq9FAGKAEXg24CAIPB/3JX76Kt7GQNYTSAeSDgYsa4GJoOL EhElWHLDchoYDvGK8EPCVEAsCYiN5ANIGCwzwVrx+y0RhcG5P9sLrj6/uxJhfYQCfb1IUgE/dC7/ Qh05l5twJzkXsr6RKfa5XsPnwgxxrj7zusduvyMzADSU29Q2b/U7IkbGMi6OEDltFAGKAEWAIvBt RsDh5suasHCFOHYZieZ3cYTYsIqGFTUHQtwhlAgCAxWxjMnB9FuZzh6G8zB9g0hzZvrNjMXOWJ2M aYAZsDAdVkaOyEHXmV5YvMJooENE8yM9gIwsYWx2ZsBKuvf1Mw4X09NPBuzuZ+wcM2hlzDYyFI7H BIZ7gV+RKgfWOTNDCSOTnKhuDQj2LBLoiE/SxqtuXfPeozeuykwNyLh0EIoARYAiQBG4KAggEfiq v27MLqkn6djgMHAPgjXAQ4RXENmPXGwpY7YyCuk1C6atSI9PDg0TWAQxIP4c2WD+kD3E+kmru3r3 VzVt3JFLtqkUQ8YZLDB0B1/6B0RgRG9/9ITEe+ZNzEwOV0hUAtHyQgbb0IAsK7E57SebetceLGqt qmUiw0nWAfoi6hDjsKBYDHh6hmbrtUtmbrlv+fnjltvUMnf1BtbOC6obHt+y+vZrpwTAGDz/adER KAIUAYoAReDcEBh0uK7/50cHT1YzOoRB+kL54Q+02gnVgZncSHTj5s9M2Xz/1eEa9VefQmCu/dtH H2efIj5GJfhPIA5MGFtwNrrcRqVk3S+vuyZ9VAVk/rQv/3drd/kSw92ELP0hmohV8c/QZmO8yitn x+166OavntVXHZHb1Dd39VoRwwlIO4cbdowaLsFFAjLPqxEcvDzPC17fv/Maa3Sd/WdEbXIEvIyu xzf3KDvngRTnyPmRpEy42mmjCFAE/rcQwHqbC6oiImRnnU7QBhuB2KA/gnUyzrny0qnbf75yVMQG ZFhm68PXP7zqMkKKMLnAE/60bs4drpbnP3fvKIkNI/32ezN2PvEDpt9JolcwFAYBpflTyDFDtZoR rJCwCtDdcPIMghex0uZ0gzvHotncnl0VzRtO1mwsqG7sM5/9FOCsL+OtTgf3fn7duyfK3swuP9nU 5/J+Nb15BOFYXY/5rE9wkGV1d38XXMyfa302bkd5y5bCxnePVxyu6RwLcL5yzD6rM6+ho7C5K7+x s23AimRBdLFy7n44xL+q2d0eCxzlvrajuHnXqfrhHg09ls25de+frPmgtMHs9EDJ7GjDWS8QIp9I YvyqM9L9FAGKwMVHAH5ARILwPkmt4QRt/PnCf2h3Th8X9ddVC/VYRRvROgZt3WZ754AdT8JOi717 0IbfviPbU9fMv3beJLJ+hkASf1q3zb7nydsSQnUjDxu0uzoG7N0Wu/+1a9BuR1DJiLZsQuKfHljG mJxDHk6sAp6ZITnuU0efF5TDudvM18jd/lpnrG437cipcjrcDa1997+15+x9TzWbaroGvvAY3ut1 OJx7ShqOV7WzrFc0Ivvty8Z0ssLRyqZPy6R89liRiN1Z3Fjc3P35QQQkpyNjQcVuKak9WHGGGL7W 5Z/nwV1m54Gq9uyGjr/tztmLUnss2z5ge2pb9sHytrOPbOFcL+4vOFRDFmb7nEKf0/pRbgXsc387 WNW0u7JWLhHvK2z61678+h77q3uLzjKgyeo8UX9x2P08AaTdKQLfOQTwS9QvqeHPxfYnaCOD2+2R KmT3L5mZYNQPY1LR3vvsjtx7Xt9x76u77n5t172vk3/3vbbzyQ+PFLee0XjUyKU3Zo6XoMwLFKRg /FlsC6amTI4MHh4HysDrskp/sW7f3a9+ct+ru+7BUK+Q10c2Hny/oBq/noePfGTprEmTEhkU2flM CjlhQcRKBuonNGqvMeLHnnzq+S2HV82flB51Zq6B+kK0DliR+Xb/ZZPnj49ds+Xoz5bOhKn0YW5N YUtvhE6tkon3V7TsKqmNC9GrxLKf/ndPTYfpsvT4xr6BD/KqBjh3Yojeny2nk0mnJ4T32byT40KW TojrHrRvzqssazdNjgn1er2Hq1uza9ttnKekpa+4tXd8hMHs4t84VCBiJZMiDQqp9HB12yflDRzn jTJowGcYEDbQ7uKmo9VtNZ29U2NCgvXqDdllBQ2dGTHhYt8Barl0QqQxTK0+UtH4k0XT4biu7eoP 16vbzJbOQWe/3XmsprW0rRf3YmtxHVSegzXKwubujwuq+51cfIiupd9W0tp9qKplamzYiYbOnPp2 EnDrZrYUVhe19iSGojyfpKyj/8O8ig6LQyWDNCe/rajmWE17lEGrhWvb10K1innJUbMSIvrM9ilx EVEGdZ/N9cax4vHhQVPjQs9yjwYcrvdzKsJ16imxYbnVHV1ms5uVTk4I1/pqz5Y0d6eGByN0aPq4 yDUfHF0+PaW4u/uq9IR3TlScau2JNGhw7QXNnTmN7Sdq26bFhX9UUPXXHTmzk6PNTuf2wvpTTZ2T 4sJpAdpA/Y3QcSgCAUTA6fZuOFHRDPVhSG2Rspo+kS24fAQmKcz47x8vQ7kV/+mK2nrufWnL24dL auo7qtpNNW0dVc291c3dla3dR8tqD5R1XDMzzaAasvDkEtGJqub23gFCQFbnYzctnZEU5h/H6Xb/ 7eOch97eV1TTikEqW/tqWtur2kzVrR0na9o/zq9XKWQzkyIkRMSSNJgmu3IrSdikv8CNf4bEOcmk xgbfOifj/NFoG7S9cahIRBLPBRSkO/8Bv2AEhVxa2Nzz5MfHb/i/j+5aPBNHHChv6rU5OI9n66l6 VGhDBrdepXrqg+MiCVYrxWqFvMVk+aCgTiWXbS2oyhrhDHS6vEj9hjWFQf59IE+ukFV3mtZlVZjd 3rezKixu70sHC9vNtl2ldbW91rYBW6IhKCJEufZEaVl7T259e7RRZ/bwWELzz3J3WeuWUw06tcKG 7wIrXpdVolaonYL373vyRl7Ga8cqEsODUyOC9pY17ipowK78ut7dJfUbcyoq2vvzm3v/vPukQa9c e6wMuwbsrgidNqe2s7LN9EFu6dvZJSFBpPje3z/JaewdDNEoe6xOvVLR3NMP2sD2pz/ICtFqTzZ0 bjpZbXF7QGlegX05q+wz/r8KMKiYjQsmC78JwZofzkjjEF901hauVV4+McmABVuGidBr2gfMYoHt s1pPd2Lz6rq2F9c+8eGRmxdmiNRSKS8ARqlE3GtxbC2pxWF/2HXSw/KNXeb1x4vDdBqNVCEXifvs HH4clHda3s6uGJOvCx2UIkAROE8EiBik72lOPH6++jV4ZIJIXK6kSKNmhHDw/+0vOVHfRXyMBi1j UJE1OY2MMagZgwYRGNUVtX/Zmzs8lzCtJj40iJiDWJ9QiqaMixjeVdza9+bxMgEx/VoZ1LOYIBWj 1TAgRZTI0ao4u/3/9uTWdw8MHz9zXIwvYRxZd5IzM0SMCfSxvkAG5dzgYH2aW0gE8IyVTxI/F3Ry 0ezYyO/PmJDV2Fbd278xrzqvsaugpePjkgqHy33FxPhIvWoXIlYZZl5y5KyEYIvFFqSQ/vCS9MtS YuFJ8y8yobFiVpCyuF9Hqto5QXTdtNSnr5u79lARFqUmxQVfOTEuRKO+NDUmOdxQ3WXKCNdNjw9F hdnSlj6T2dnYPRCr1y9Lj1XKyLoiCuVsPVV99fTolTPGTRsXU9LUtyWr4lR9W/uA88VD2cNYVnaa Kto6l8GCxiqXx9vvJBn7cPdZHA6pVHLZhLjp0eFqlfzGScmNbcSruSA5Jik0BHexpm+g085dnpqw fEI8AmAYr/TGmWkoFz4x1jg9LooXRB0D5u0FLcF62Y0zUzKTwnud9jidZnZCRJBacrCoAabtyPuZ 29gG1g/RDgU1sWLvSEerh/cWtfbtLmnsRaTviCaWoDA8+ZwWrbv3smk/XTwpKUjr3y8SC5Aua+q3 Ls8Y99PFU+wDVt7jMcglizPiUAk9v7bd6RvqhsnjV05LOV7eOTEmZPb46CijNjM+fHyckefdB6vq zu0bR3tRBCgCY4uAIOCZ4JP59eVTw1/kD+VjWZPL+UkpftM37ihs3Jhbvb+igezF2ptfi4QczJJX HA+m0auOFJ/5M5eKWZnSF9BIzC+JUXsm6KO139yA/DYilI9z4aHD+tLAfeclYvmi1g4TftYPX7VB haB/n8olSbMbMcPTKQiBwAclbsBtyN1mXGMUS+LkXLEG3ZyUyJsvSVs4Lur/duWzvOyni2f+etms N398NeS4fvPegT6HEI4gGQDGimRyKQgsNFiFjwmhIYMCB3Paf6kQZsbTWiqS9NmcCcFqCDUDRJ6V WLzexGAdUgr1CrlMxEvEknCtauOJmr8fLtGgBLpIesn42FVz0188lP/UtmN+zy/IY9BsnxZPSMuo kjf2D85MTrhr4aQ756cXPHbXMLK7SlumxAXPSAjHFjEnUfrKrqo1ChaVDTQajUwiEbGRGgM2aoOV +Pr8cW/W3qo6vUqOSeK8GfEx5FwCo1WwMfhlxDBvZVf8N6dEJVEaNZqipq65afHYGKLVqFn50er2 f+wpQd6IUacY+tnlm0froL2m154YHDz8VZIpZaSE63Bjmazy5o+Lapq6PhWqg+IK7Omgo3ijPiZY oyZC4KR5eNGcCQl3zJ10w4wkOArc+L0AB0X74D935bFSXieXOwUmLAhfXlau12CVzu3xSiS8WCp6 aV/p+3mVBq1OTKoX0kYRoAh84xDAX70MqWOCmNAG0fiHQwyp1iQHIK+0+drVb928eu0Nz6794ZqN 9XVtREAEaWqIfoROL0LPkNwNtRHyz4E/e9PpYDTy+BWLPHiWIaCx3wEvpA1xiKebAxyGHANkbaMj hkLyHDriPUbDeW1Eo9lNCloPNbHLF40y5Cw9PUO7nWHVqI4aIEBleGD6cgBUSm7EuQM0OhlGjB/5 HrdCSp7MB6pap8SFJ0UoecGVGKSXK8QbcstmxcXdPD0BhgsOcHi8bt7rcXlqGwfwMa+tOUIm9/lM fU0QcQ6R3emKVMuKajvhIjORSNTBUIm81+5wcW6bA1GWYthkfeaBZ7Zm/fPG+UsmJ3V2dOO3waUp 0W/8aOmxivbGASK1jCW34BDt4fIGl9tbUNcapVX0W7kYoy4p2NB1Opgzp6qlsrntmtMamzK5t7+f TDKnspGz2bycEwSJ1MBBX4yl1cFUtvSX1fU+tHRGmFFts7nABzZfqTmyjotPLndFZ9/JqpaV05LT EoNaBhxLp8e+l008mQW1La3dvXvLaq6YGL18crzV2o+YkeFbUNrcgV9BMxPOeACsNpz2zC2SsOL7 l0598dbvzYgJGXnjCPIItP2ir4qXd3k9nOK0291ud+CLmlfTdP2MlDkJEVavC6UbLD3kunANWDwG pKwgFHf0lHV2/3j2pJgg5GMG8DtCh6IIUAQChgBsAKeHY1iiy+Ez3XyEhOUJu1Mil4ZEaUPHhRkT w4JjDHHRoRGJhoT4yPAQfXx8eESCMTYyJDoyJCohOD4+VBVmiI8dWlEjjwKvN0ynDooKDUsKU0WF GKRnao0ZJLKI2IjQZCN6RYQZEmIjwxP18THhEeHG2PiQ0JRQY1Q4nvZnrlBGMpAYjy80f3iGKJoq 2OUB80k68Az15W5f//iWp8ckd7uhz7p6S3aDyQSv748WpP904USTy3P7S9s9Hs+9Syddlprw8zf3 hQYpTtX2PHT1PGQC/n7ToZfvuOpYQ8f6I4Xjw0NeuW2JjEhZk4Z8rJ1ljYgMWTQ+7p0TVf89WTbY 5zz+9K39LndeVduUhIiPSxquSI9DTOOs5KR+c899Gw4vTkq0elwTgoNq+00VnabbF2TcNmuCxFcE vN/tuevlHbDrkmJ0v7xsckWr+S+7822841dXzbt5UhwO+Ki4ds22Y9FaTb8NBeTY7Q+svH39ToSQ ZEQbZiXGKKXyjHBtfb+ta8Dxw9mpf9ya/7trZzyxLaegpjUyWJkOmhGYG6ZPSTDKkZX3l70nf3nF LCUj+iC/9rX9pWnRxi6bdcO9V72UVb6toCI5WJ8YGjw3OfL57cdTooJyansfW5G5LIOYdCab/cO8 2snREZnJZ75kO2vbXAP262Z+RaL9/oomsVR+WfIZUhz+bm0rqBHJJFdNTPRTaHWf45Oi8sVpyb98 d2daWEhbv+OBZVNPNQ88/L3JLQ772p35D14166H3DlyaluR1uT7Ir8yIi95fVH/42R+qAvZFDNgf Nh2IIvAdR2DQ6brhHx8dQO62b4WecUA9REaMpEHz9ZdO/fBn1110fGr6LKkP/AtuOlIE/NMzvHLO xF0P3nj+M0SeWObqtazdzqtu+cPGx26++VullUzUNb/tGpg+CdHdpY3Hazuevm7O+d9ROgJFgCLw HUdgwOZc/rdNx4uhuaUc0i8mdbSlcC5dOyd9SyCY4zwRruo1p937d1SyJhEufoXlQM8wt6l13up3 sd5GVpPGaL3tPFE4S/dvO7F5Be9fPjm5v6Jrb0nLorSosQOKjkwRoAh8hxAQsTKwBUQ54DvCijvC IH1BkoiVDNxq1nnBKcdaILgWkxzDGcpJ2To7x6t+9Oz7v7kFMXvnNWXa+WsisKWwpr7TOislfEEy 5baviR09nCJAEfgiBJBGffXfNx8rrEOgo281yxcAiXCSQfPVcyZ+fNpuwyL6J+VIR3KK5V7GJWGk WACDqD/CT7BKh6B0xup2hml0109J8p8Eays5TZ3VbYPY5fHwN89I1qqGCq01mayHq1pxIhHEQDwQ uvIP6CXvhwZEdU98RE6CFyrMNV29T711gLhJFSKSePclMzyf25vb1DF79dus3cWrbnpm85O3rpxO ue188KR9KQIUAYrARUZgwM5d+/fNRwprScoamMPjC2iE6TZoXjFn4rbT3Nbv4OY8v6GqspmwDgvf Hewc/MPB/qAPD+P0RCbEtP/zfv/1mJ3c3Wt3vL+3kJR/4xxF/3l48mn5iLdyq27/2yafor+/u28d X4BcpF/I0ReuibQEF9yP/txdMaNRkHQCEqH9pTM8Hxxzmzpnr37LH4c4Vrnb5zM/2pciQBGgCFAE vh4CJECQ/CepZiA2f7lthEwzipECHVqF3KCC5YQMARVRMIE5BjkkBHeQfGoJkfxnJSGqM8GQIhZW GawxKemiVJOc69NNDSUn+BiROixXkkFAXQocpiQH+0YTySW3Xj770TuueGTV8j/cd80vr188JFCL 5IFPzzBwsrW4HuQAIDNLLj5vpf6vh3/gjg5UPsRnZ9TQPQC54cDNk45EEaAIUATGHgEUAiC52/78 M5AFUaD3UZFnwHZG3gFRipemxJAoSn+pUhKjLxCbDDtgbnkh1e+869IJw9NFMhD0K3zyXTIoVTpH PBtTwg0TooNJZhuGwumQmo0z4r0IryLG6poYEf7E8kuev37+H1bO+f0VmbcunMxAXmqIaT81Q3HA Qq/9udtSVPseq9xtQHOqyXTfm7sf25w1DBMSqE81dfk/muzcw5uP/Pj1Hf6Pg07u8a0nHn4vq91E BKJAXD99d/997+xr7hvKqHJ5+A3ZtY29Q3nK339l97bCutxGIgtyFpbbUVy/Kb9mlKV2HG7vrzYf e+iDw797/1hVe//Zvox+O35EO1HX8WpWmcVFy8eM/d8wPQNFgCLwOQSQuy1B7jbqAMBmIsXSUIwU 615iRimt6+jrsp95ND1xzbxFs1OZ5rahlG0UzrbaSM410le7e5YszvzJkunDw3db7U3dZiypEepi +P0VZyRLIOr78PLZUqTQdQyQmt1IBkfWNjK4rRzTZZHo5Y+vnJsWZcRQPpUIpqC+mXAqaNJfd9s/ Q8yWyHAFpiE5HHaJL3ebV3DuMTGArHZ+Z3ntg1fM8Iq5B7ceIezl4H767t5txU3+i/jt1sPLp8fP TYn9wb8Jvb18sCgkSD0x0fjvA4X4BXD/mzsXp4y7Zcq4n67b5j8e6W5N3abWfvIDpM3haWzunD8l Lsao3FfU9Elh9ZcBkxEdMjHaKDmdrXx2/HaXVIdIRB/95NrV182PCzV82cH7SlvX5pRy/Kdsu1i9 JjM6yi9JTBtFgCJAEbjACMBqcyF3GzYTBB4RHkki7N3ESOK4botl04lTw/PRyGX7H/rRvx+/c2pG 3LSUuGlpUdPGx01LjZk6If7x+6/Z+ouroec+fHBxc2tRYxMxB8FJbsnmvKEHuP+AOxdM3vLrm5ct mTEtPWpaasK0CZF4nTEp5raVc7Ofvuum2WfsPxy87kAJI0iJQBdkt4Zn6LMShqJTzhsygeF8uiQK lmEdCqK8Ffh2orEpVK2JNwb98frF2SVEa1giEUfodUoI3zMMZOb1jHJGZOSPL53c63U299p6zI67 Z6TeOC1ZJBV3DFp7+l0LJkcumJiogWv4dAsOUpS2NePTh1lFV88bHySSmjjPa9mlGwpQIc5p8XBP bT/61pFyHABl5K1F9e/mVJocriijXiSwb+VU/WzDXovjS7WGEQ60s7Bp1ZzJ6G6EOpaULe80Pbbl KESTsQVG+Xs5Tc9tOV7bP1De1vWfT0rKWgax/bWjFc/sPGF2C0atMsKoPtna84+9eS8cKnphT37g MaUjUgQoAhSBL0GAFYsUUgXDQ1zflwMA7Qssm8Eg06o9Ds8/9xU195wR50O0x88WTip8+q6C5+4o ePaegmfvLHjux4XP3PnsdXNRDGT4DD0253+zqiAcxSgV4EgmXF1wtKC0zTJyCldNSdr50HUFz95b 8OxtBc/eV/Dc7Xmr737zx8v8moXD7d9ZlbmFZUyYdsiBOTxDqHOxGmfANLeUYDWf3aZQYsJj0SCN D5FHqU9bxCBTW5yCWipZNStFpSSKkU19VqNRKfaZU4la9e6KZhkr1qgVKBkDkSeocjyz6pLbXtq2 4oUPf79i8fD0UkNDyhsGcONQO+bWSybuLGk8XtaSFhUUHSxDZdnfbjoyPiTkUFX9uydLUWTvF2s/ jtAr86tb3jl8qtpkgT94UXLcz9bvHB4N0lkuLz9clhrDtlndoQZ5vcla2NaHwzrN9kVpSeuPlByu 6vmkquW93MIFE+PtVhfczvHBsjCNYv3xytKWrkiN9jfv7D5R077+0CnBI6TGhH6SV7fuRNVYoErH pAhQBCgCX4iA4OWdI+tuo142xCE1auJp1Cjr61p/+Oq2yk7yZBtlQ5XRx98/sOtICaNTE1sQdbdh CBrU0594JbtxaGlplEN9VFzz8zVvk3GcTiKX7K+77Z+hv+52wNbbHFjH8623OTjpUMmwUU5y1Ifx ZE3Pv2w46HXwWKjEOiUCaXyVexRysdynVUiGk0gFkdcnPEkaZEdQj62x17FkQvx1k1L+cyCbKHX6 2qVpUW4JW9lhNlmsiUatyytKjNDNT4tdlJxQ3tQXqpB/P3P82ntWvH6w3OkWvj9v6uK0eI1GIVap orTK6UnhvEwYgHzn6YYiaq8cLjpc2+U+XWtWLfe6Ge/RmuZfv71ve2Hd3ITwUIMqWCOqbOtJNKiN aqXI45kcGzY9KuLyjJSYEPWftp8I1ytMDqtepe60OhUqcWZ86IzIsIggzYnffX/USNEDKQIUAYrA eSPgz90mdbf9Va09ZFkLz1iSwe2GsOTRUzVL12zacLwCJbZtLvywR/AJeRzjDakBgDdkg2BzeWAb bCmtm/3cf1/ddpLRKocMQSSDIypSKkXFsTlPrPvte0fKOgcHHBycZHhAk9GIGrtvKDIOKIzvtzlR pvK2V3fc8NibDFZ51Kqhutv+mEz/DH3tU6VMzgMJ5KvjiuD0JGLRYxQnGaxTOTxO6GxinlY7q/f5 bz1uVGEg3Bam1nSYYYqSjbUd3QuSovs5j8XjtnAeXHKjyfb2gbJHrph13+JJTq+wq6Jx+GIzonX/ 3nti9rgEbBEkgsvjdjggR4xCbB5BKuNZFuVoZLwgJfn5ZHSxIChFzFtZpRuPl6cHh8AsHB5KBA+y 282jPoCPOsHCkUFQTLbdPjv9uqkpvQ7nkx8ebWzrSYkIt7tsGVHGJ5bP2lXcuO5oCQro+O4jvi3S XyyZ8esrMv9884IYg9IliEyc9w87cm+dk6yE1DNtFAGKAEXggiGAGjd43qIOFlazYCIgWAMPW7zH PwToI4RSpWzt6r31Xx+u+OvmhzYdeGZH9l925qzZnfeH7Tlrtp9csyt3za6Tz+/I+fWmQzf8bfP1 T73diLg/NQwqX3UbPDgRIQmOVMoJ1THCnzfuWfj8unvX7nlm6/E1u/P/gKH25K/Znr1me94fduX8 cVfe0x8cv+eNXQueWff2zhNMmGFoViBT1MTB9IZniDfETRmYBmMQQ/nrbh9ctWBy+oga4YE5A577 MkVBU9egw721sDbJYFiUQcq+NPcPNvcMzk2ODter9lQ1upzuwgYUlHbfsSCjrMt0sr6ztLVDJZEt nTAuq75VKRHVdfVXtffdNDfNIB9aaxTEkl9tOvLUtZfEG7WlTQMyiRixMCjDPT8t8Uhlq0xgNmSX XzI+ZlxU8JHKpmWTk04196JYTk1377hwQ1JYyMuHTt42b6rMZ0SGaVWoKJ0UpveX20Z9GTfL7Cys cXj4HWX1UTptR99gZkrk4fI2u5uZGhfW1G+WyST9DrdRr0SJ0Zmx4TaPs8XE4UtT3zsIi6/XbCtq 62wdsE+LC2vrs0WjHM8YFX4N1E2i41AEKAL/Kwig1jIqJzd1jKi7jUsDvWHpByH+/sI3kClh+Y62 /vyatsMVzfvyqw8U1B8srT1QWn8wv/ZgYe3B8sb80oaWHgsKdJGD/b0wgr/AGx6VMAqJfcKC5BwW Z3l925HShgPF9QdP1R7Iqz9YXHOgouFgXu2BU3VHK+sqmjodoC4s+yEV4cxQECXxjeCPniQEzKbE GgNUd9uOuts+bvvgMLhtwhhwm0YukQni4yRGn31gyVSlL4AQV6FVKeONGtBJUoguu767y2x/6MoZ KDwdE6Sp7BgURMKKKUmJodowgyq3uqPTbr9mRuqkiDM1XLDKBSfm92eOE6NcjUQcqlPrldKmXvPM hLCYIFVBY69CJdw3fwpuJYqtpUQYvIIoyqhbkBJV0ABD3B1u0MSG6ELIIF/Q4oy6um5Lh8mCVdAr 0uOD9JqSzr4pMSFQpEHh2kNlLbC1l00ZNyEyqLS9M0itXTlj/N5TzR0WS5RelxCq0ysUUrEINdwG 7Z66voH5ydH/K3819DooAhSBbzoCTo/3vRM+boMmFkjIH1cPhyRyzuD98xfjhg0HllIjU9sXcgJ7 juRZg2YgLywj1UpR2hRdNPJP9YI5CCej33+I1TI8XmFoYVj0QowJHJXohS1YkEP1NFgKGAEHY50J r8QsIQ7K070wFHIAxL5oSf8M5QxnT40Nv3VO+vlD3DZoe/VQEWt38qpVz216/Ps3jZmeJByPQWrF cMEwn1uWxO/4W5+NQ5FPvXJoxc/OeeBHVPsKZJO9FgeW54JHZMj7txMpzBEYACizg1NiAU8i6bY4 gkg4CuFRn9Q+yRTEXcbxA04Osi8oYsp5PMO1Oj8PpcsrWB2c8TT59docIWplv80VpJah0hsGCoKR TvIZHCKRVCuXWJ0eq5OLQDl238zwBbByTi8v4nh3xOl62ed/w+gIFAGKAEXg7AgQPcm/vX/sFPQk 1UNGEknNlpGcMz+TEesNWdg+loKDkRTL9hI+w7oMnpL4iF1EJSsQvUClpPr2aM71WcXL87nRuU3t s1f/1xdLwrgD5un8ohlF6lTDxIb9ON8wseFjsFo+TGz4qJJLhomN7NUqP09s/kFGNtwRg1ruT8gI 0yJ0fyhnwO8ORJlo//EGhVyjlINKz0JsOEwmZoeJDR9BbHgFsZFXjdxPbGh6pRLEhjcahWSI2Hwz w2R0SgWOp8R2Pl9Q2pciQBH4ugigsrEES1kIpCAE5lvDgkWFjGxYUXg8IjDeH7uBjcgtI0nTPvML lbJ9ESJnqnUHpBcMxNGey8GwKk/AcgBgEvpzt5VyCKbQRhGgCFAEKALfagQQm+jyuHyaW6frbuPh jjUzVN+G/QQRENCbP8wEFEjSuhmiNumnOiTwovlrYY/sBbfhBeglOGUBywHgfJpbyN12OHDttFEE KAIUAYrAtxqBM7nb/lUul4+34L9SKkScOzg0TARbjYQ4wmMn9qV120lQPnxNUOoi6WtYbxvRC0pa YD5IJ2ORyN8Ldt5Y9MIEGD5QWda4WqwoQiIaM1bCJB2LVtk5uCm3eltJ3TvHKrMbPpXoZ3MJdT02 x1mlF5Ez0WFzmuAIHtE8Xh7b/RvsLne/jesZcJGw10+3TgfXZMLC6tCRgiD0OFwNJnIoDjQ7Xd0O F+qvm5zYcEamBGH9/Xau1+myOhG/SdLgkLHRMmButTpIsgZZwBNMdkfbgGV4DmOBGx2TIkARoAic AwK+3G0nI/ISywySHP5Ua9CSzRERGfz3m+cnhgQRxyM8lk43Y7ER7X9oP+JZhyBvWHLogkxq8BzW 5/CoxAFwZvpTrYnsMhIAPIQOETwyaCHj+HvhgKFeThJMYR7RC9dAtLXcRBvF3wvPan8vWIrDMyRR l6JAWVgC4wAVix97ZvXzm/f9YNGUtIjgc4Dy7F26zdaD5W1vHC4OM+pDg6Tjgg3Dxxe39a7NKkiL CEI29BcOggXNP+zI33iiKKuibXpyvBaxN772jz0Fpe2+wEWR6JqXNufU9ZS39QVr5RF6zfA45W39 T3x05HB5bV2PZU5yFHzQW4vrX9iRl1XdHIxoxmDtC3sLP86rO1rf+sqB4nC1MjkiyN+33eFY/dHx /Iau9cdLK9oG5qfE5rf0rD9U/EFeRWOPeW5KdJ/d+caJ0tcOFNf2WifHhijHdKEy4PeDDkgRoAj8 TyPAeb3v51Y3QuRd7ltygpmFgA5ieykgUn+iormt34w1sPBgfTgCHYw6nYjR4FUqsvisA6nARgcH GY3qUJ0mCKF5MpkValhiiZgV9GqVXq0MD9FGRoSGaJQSVrBayDIetJkNKnmQVmM0kF4GvVonl8Jq 4WE4CXgRh6sVocGKUIM+SKPRKcRWuxupx0NZBERz6/QMBXlSjOEHczLO//60DXJvHDolfuzRp57f mrVyzsSMqMBzW6hWNT7a0G6x/X7ZjAnhwTB8sqpbId4RpVea7K7y9u4ZceF+bsMuiO6LRCLl6QjJ rcW1p2ra3rh7uVcie/VQ/tWTSQXY6u7BVw+cNCqV81KjwW3rDhZt/tl1i9JjRhIbDrvlpQ//dfvl d8ydtLuivs/mFouE7YW1z69csGr2hOggLUJL5qVEXTUlYWJEcKfZmpkcGQEZGF/TSaXLJyd9b0Kc ye5B6tv0BNxE0dVTUlbOHH/Huo9vWzjJKFfOGxe9KjNtY3ZFnFGD0c7/TtARKAIUAYpAQBCAt+md rNLmThNJr8ZjlVRx85L3DmeIUfPbKy8pa+zgnK5rZ46/anpqWrghOTrkj9fPnzQ+esuBEhEv+sHC CTfNnRhjUMcFGyclRfxgzrQu62Brc++4SOPjKy9bkhY3NdY4NSJ4bkL0nd+bcbKxs6+9JypI+9iq Sy9Li0kI0k6IDJ2ZGHHdnAytUlVUA21lFrJQ9yyZnhRqjDEaMsJDr5uXGmEIKiivJ15Q4of0Bc2T GcL5aZ0QG35LYHIABl89VIwTMAyHUt8BAfYLBnG4ebeHh4AW9r15smJHUf3ekvqdpU1yZIGJpOzp gEaIFL9xpLSwpXd4CN7J8D4pMKNcVtbSjjfwFubUdk6PjY4I1vs1QeBK3VhYuSG3qsdiH+7Y7eTE MmmcjrDOgtSklh5zTUdvuF53sqFzU245bPXhI7Nr24JVikkxZzLn/LvqekyNPb0Lx0fivQEF91jm YFXL1NhILebDMv02x1vZ5UkRxoQQw1ihRselCFAEKALngACK3CDKH88pv5IIAkMQ2e/LvEacf0ZC hFKu4FyejScqHn1rz7ObjsHAsrj5t6HNz3smRBtunT+lsq13Q1bprtLa1w8UuAT+sRsug3aVQa6a Fh9W1NDxyIajj7x38IF/b3FwnjsWTmTsHo1ckRxqzClvXLP5+F8/Ob763cOv7MlZNWc8HJsKiWjV 3Axeym7KrdxZUvVW7qnjZV1PXjdPq9OQqBY/vfln6GtfqmH/tXEgcfJDnDYmFW6GJkTG9sfiP7Pp UEyI3uly7Str8V/W8JzFLHtTZnJaxBm2WDIpQSRyv7jvZFZ9cxAWMxnmYEUjFkTnpMbZOZcfjWsz M7RiWWlbz9sniE6/vyERTQcvs68p4UD2egfc/MmG9n6b/VSr6e87h7T5uwat5W2mqfER/tLjZ5rA FLf0aVWyxFC9f+Oeypa3jhaj3JHvhwBjcbqrugYHOLdf5Zk2igBFgCLwTUHAFxVAJkOqWnsZ8nNc RFa2kFktSBFcQDQWeZ4bNCul4jW3Xf69ifF3vLR134lSOCohqaGUKVOiQn64cMrtcyb+ZGlm96Al v74bGcZilq/pGjhW1eC12wU4vjg+q645GDW7BbgrmdYecwWU5XmvlyfBmdnVbYNWm1Qk0kilSoUi WKm6MTP99rnTHlg8My5Eu6OkXuVXmBo5Q6LW7zM0A9R8DlmMJhf7tIvHppH0aaJlhTMoRdJ5KXGX jY/9yWWTOYRw8EM6yTgxlsQykyKj/enPvgapkd8tuyQ9KmTJxOQwJVlLK2zo+eRU7TvHimB0Q5oL W359xdSrJietmpnW3DvQT+qmkxahVvdZSWlTtD6HRyoWq8QiENX1M9Oeum7u5pyhMm913WaO9c5N /axuSL/VkV3dcmk6cYGi5Ta27z5V+5urLpkUHerfEmvUPXZVJqr0HK5qRWjJ2KBGR6UIUAQoAueA AHSKySPX14jko08lC2lt5BGPD2A6kFBcTNhzty7tHbDe9df3G8rq/OLFkDjusVn251a+uTV73bbD /91y/L3s0rKWbpAQj6wCAX42sJwvzFJJHG68XGDEPE8UmMVihJ9YOGbQzJjtYlakUcncgtsjCFDJ OFbZtHZ7zrqPj6/7OHv93uysqmabg6hHDk1veIZE4DlQpdb8dbchteJxk2y/MWq82GGD7eQlNo5S MjUmaElGItjb6+IEr0cqYRv7Lf0AhWFQKc2M6gwjWnywfkl6YlZZS2w44bb7Fk95dMWcmSkRc1Mi E/xGlY9ZOqwcFCaDTucx6BUis5NF0Ad2najtjA1BBQAdIlPcXg/E/lHqHNuxrHqwoi01MmiEbPLQ iQdcnFytmne67NDGo5W3LZycfnoxEoJbsEFVUjEv8tq8nE+KmTaKAEWAIvDNQIDkbkN5hCWZ2kgD gMUGYiPv4WZyG5Qq1isYDfq37l8xPzUa0d4rF8741R1X3LAkg5GzVV19iDS5aX76ghnjMqelz5ge 8+KtyxKjtAwrkYskGgUp6U1YkAiaCDoUKmMhRo+4SUdUkObBK+bevjzztuXzV10xY8Mvr23tQ+wl D5GU/Mb2KyYlXzM7bc701IkTYp68+XvXTkuzEocktKl82eL+GRIpL19geiCav+62+LHfPfX8+ydu mJeRER34WBLME4tktQPmOUlRKpk0WKP6887c7Jp2nUYRrFOignZmYtRrh8rsEnZCqP5v2wuRcTEu bChkEX3fOFH+0sEiKc89fcOl+KhTQhNEYXF71ChvHRcmEYn+ceDU2zlF7b3W++ZPhILJMCzzJ0Y9 ueHI7oqmlDDNnfMmxQZrW3ttbxwt3Zxf/fBVs5NCdb0Wx6HKhp8vnYFBRoKJXzyHyjtTQnXjwoYc kqjyUN3Ul93UdqS4dda4GIeHe/lI8SsHi4L1ypump2pPyzcH4o7QMSgCFAGKwHkhgJymt7NKWrpN PrFHFAQQ+7T2EdOPOH0xXF/1PSb8Lm8csBU19jldFkEkQY6Vzemt7uriXCwezr0WZ7ABQQZimVa+ 7Vjl+8eLvWJ2gBVKWzrqOk1OlEUjCeCKeou1rLWzvc8cGmLIiIs4VN9idjslrEStkRwoqV9/pNSF 0H+JtKSxs6bfFKRXgHP1Wump1r6X9ubaHXZCtyRJHDalb4bgNo7LiA37fmBiSfrXHiph7byguv7x LU/ffu2UlPMCdXSdYWjB9Tv6PIY+hx3u2i8bGy7BAY4LQorGF7UBDpEgZ3ZYOI7ITBKb/Gs32IAk DdDXD7GyuIQvTlz42gPTDhQBigBFIGAIIGf3+n98dPBkNWK+SYUvEnbOktwylCcluiQektmGH/T+ jOZhtxMIBmnaaMj15uAahNkD7X+BlAzFMfjJT6RJEJ8CfUhf3RyMAFpCDpxYOjk85OGb5v1nW042 oh9J4gGelUpGzDFyBTkYvXCu4ROR/G+kHeCRDulkeCZPz9BmY7zKKy+J3/XgTeePRW5T39zVa325 2yqlE8pbF6QReeivc6KzEBu5NSz7ZcSGvSOJDR9hY50bsaEvbvswmeHuUWL7OveQHksRoAhcIARO 5277lP5hGHl4X91tFYM0NX/Ktn/9CUGTkCOB8QTOA7EhSQB2HZFORvEUosJIDtNqhpS6QGz4SAb0 kmRwyHGB9hDfADr0cO22wfeyyluQ5a3zFR3FgCA2xPRD+gujkSe+lFGdPhf8pejlcAzV3R6eISYj WBUBW2/z192Ws1DSlMvowtEF+vLR01AEKAIUgTFCQCyRGBFhD28kaAYGFmgJDklYLghHgJ1EFJN9 phXcV4g19+tMgsnAW6SSM9bAsJzm7+WjQOz6fC+Si+ZjL/RSKHptzp0FUMswE+L098Kw4D//uUjF li8/1/AMwWq8oAWbBqKdrrvtxsllAVvFC8TM6BgUAYoARYAicA4IoFxarAEeP58gMsI0QFSkchvS en11t7G25q9r46+gDQaCFYVXHDxcC/vr9gIpkgoDiHw8j3ORyuDu1NAzwRbncO3DXfx1tyGRiZIz Y5i7fc5THHRyZpt/nYs2igBFgCJAEfhqBBRSySXjExnU3iLpSb4MbkTtI9GNlLc+XZ7tTNK0L/gA 1pW/xOhQDvW59fJlMZ/buVDzzOFFrdQFk2K++gpHdYTYp+tMEDiTZzaqjhfkoN2lTQdrIK9MnaUX BG56EooAReB/AoHMuPDk2HBiq4G0EIII3oLFBrMM3kWwF2wsYiT507qRhQ0lZV+NbKzMwZIjhbkR CXlhe2Eh0CnEx4VfmvTZbONzvSFYGPRzmxvFwL9xbUZc2JS4z6phBXCWPll/2igCFAGKwP8UAjEh mvmpsUPK/SQAxPekIwndvuiSM54wxFv4Fbn8G/0Z39joP/JC9mIYh+XhKzMDdxvI5MWPPfXU8xsP 3roYdQCMgRt6aKR9VS2QH8lv7DbZuWiD5qUjFSaHU6VQnGru7LPZLS7vidr2uq6BlIigN7KKtBIF 0qsPVzSnRpKZFHf0CQIfqVM/8Obhg9UNW0saY3XqYJ3q9azSF3bn67W6xGDNwcr2t44WbSlscri9 EyKD0HdLcdXLB4pYqRQyoChP8+qRitcP5aukssTT+WoYuY/jf/n2riNlnXqVPMaoWX+i7B978hAu Oikq2OJintxyZE9JU2lH95Ha9l2lzROjQjSI86GNIkARoAh8GxCQS8RYYdtW2ODhvIxCSvyECNZH RAnxPUKZBBabb+NwWjcuCiYdiezHAajWjdRn6PRfqF4IP3Fw8hD9x7+4IVDotpudrx06hZR1JEWL TLZAlYX71PSa+war2vu2FNTvLK5r6TXXNHR63WxxS+vOkrqcus6C2lYHLxyra0Sfl3YXn2xoqe42 t5jM/iFO1XXkljfjzZPXzbpsUnJeQxPkibfm1Tis3IPLL3l6y2Hs2llaVdPdd/v8tKO1TYNOx66i OruTf3TF/Gc2HcDeY5XdFW3dP14ydUthdWHjmepxv1q/Y8GEcb+/bta0pPBtxXV9Zvufb1y48ViZ yeo2WxzHqtpumTEhp7Jtaky4x+Eoae0PFOJ0HIoARYAicAEQuHJSys1zJ5HqaHD3+UMW/YH7IDZE LRIhR7gf4ZzER59bEmSGjGxSRG1E3e0L0AtZdAjX77P++cbFAYTF7XSLBEaEBHSpTD+I5IYxaOND DW0Wp0orqOSS/cXti2fFZSYH9dk5o0zBu4XWfm5eQkSITn2sqS0zOabVYms3mTNihmQbYUTzPsnj ML3qrQP5f73pCo1Mktvac7yhd/vxSrUv2FSpVC6fkgqLUCGSmm0ejUExe1x8agRURaJqBu0Hqmpq 2/q35tU5iL7LmZRtqUpz2yXjQzQKuYit6bCkhhrC9ZpFE6M/PFku14umRxvjItXJMUGZcRGhQSqR aGzKto4B2nRIigBFgCIABFQy8R9XLVo0P4PpMpMFNhhhJIONI5VIhypowzhDWpuCpHWjyhiW2URS X+j/iLrbCDkhxXHGoBep8e07F+zIrq67b7nsF1dOC+CN6+I4qRz5bQyTGmc4UdIWwKGHh5qSGNVm GpgdnSCTSrZUVq2YME7OSvPru8JD9Danq2XApFaIp0ZF/nNH/m2zx7tcfF5j+7SkqKHuyJdmHXh/ yyufXDktaUFypM3JoYbez5dOfOLGuTt/RQxYq82G9G2ILoN/3Iju4VgF0vWIb9mqRAKiTHzvorTn rp/32q2XT4sJhYiJX9rYbrcNz5BlUKSWdOnutSnVagF71AqvF3n5yD/kkPvh5b9WrvlYoEjHpAhQ BCgCXw+BCL38wEM3PXDHUsY8QNbebA6SduZE0rTPVhuZ1o062qSCtutTtbBh52HtDaq8hN4+l2qN ZPDz6YW0bkicICWO8f7nqVtfu3PZ17u2rzr6YH5jmtFIuG16dOSp7p6vOv5c9mskIq+Tjw/VRqmD OrqtIBHI/3ea7BFKmU6pUIvVKpl8TnrsgYKmS8ZHIWyTF0kHbM6/7MlFARo5L9ZLNGYH39RnWT4x rarLppTIJ0YHQ30/v7EH9bIxIa1Y6wanMV6ZCFrMLIovFFT3HqhsHXAwMQbVpWmJW0415TWYNkFG ze54L7fqT/tz0MugVj7/cV5tv7l1wDopMaKh25LT3FnRNbhyerzJ7ZGSEuxeidfndRazHmq3ncud p30oAhSBi4/AizctfOf3d4YrZYS9LDAVfKJZsORgM5E1Nl9aNzHp4LeUD6VaI8AQASYw6ZCChew3 EtkvJd3PvxeCFxGxSVTsSQDnlPTYw0/f/ZP5gbTY/IifaG5OiQ8Rr1692up2bjxQfsWM5Cj9mRIz gbotKo08NUxnVKvSEkLGhxlgZoUoFRNjQ8NQpDUmOFqvQh0CvU49MyHMYNSmBmsNKpmL45PDjBqd NCbMKIiZ7sHBwubOorbOEJ3q0tTYlkHbrqLqWXERyRFBvJjJiA4J0SrVcnVKuOFkTUu9ydRmGvzz LYsQABITpPYy3h2FtRkxwVOiQuwer4KRpEUal4xP2F9dn1/XnhIRPCchomvQ/HFB7T2XzYSGMu8R gvRqFMRRq6RJQahFKkoJN+pxP2ijCFAEKALfQgQmRQfftWhy7SCqXjK8y84hYBKx/ojydyPWH7qR UM9yMV5wHjK4kSfgk+kiq3Qc44WXEit2EH7E8TD1zq8XySXnJWIBK0hpUaEPLJ/z8h3LUk/XyAwg ribO++C6XfcvnYnMNqG2Z2DKU28/tWLmI1fNCeA5LvxQv99yZEVG0ryUQCUAXvgroGekCFAEKAJj gkBNjym7obeipat90AqigRdSIpK4vW6ZWObi3VIWviovbA+s7Xh53y7BLRPJXF63VCzBFpLRjQUg +LTOqZeIlUil3rSwsJQw3YK0pFDNWAWfr8sqveuFzQ0vP0S4DWURbn91R7NpYM8jt2oRM/qtbW9l l82MjUyPDnwyw7cWEjpxigBFgCLwHUJgyfPvWThX7jO3kfU2hUxy9+Kp1R3964+WfasxWDktNTXC 8K2+BDp5igBFgCJAETg3BDZmlx8ra37ixsvQfSgyfkFqzPLpKf/cm1PT/S1O51LLEf1xLuXZzg1H 2osiQBGgCFAEviEI9Frsf92StXR6yvfSiXbXEBMoJOL7Fk23DLrePHCKyhN/Q24VnQZFgCJAEaAI jBKB57edKG/vf/SaTKWvjs8ZK2decuTvbpjzwpGigpZvsek2ShToYRQBigBFgCLwP4PArpLmf+7M eeyWS+emDgkuf8qD99AVM5emR899dn2TmSRN00YRoAhQBCgCFIFvOAINXf33vfjBylkTH142e3iq n12devXOayeFG9MfeWFfdec3/Hro9CgCFAGKAEXgO47AyfreBX/dlJIUuf6nK0ZmIn+W20LUspPP 3rF8etrSX7+4evOxfkiQ0UYRoAhQBCgCFIFvGAJWzvP89uzMR/41JTzoowdv1KDo+IhG8tu+cMJ/ 3Z33u7X7p2ZE/uMHSzMTIuRiWiP0G3Zj6XQoAhQBisB3EgFopxyuaX1u0+FDpQ1Prlz05M3zSPTI p9uXchsO+6S06U9bj6H62vXTk6+ZPn52amRMkPY7iSS9aIoARYAiQBG4+Ah0Wux5DR1bsyveya2Z Gq57ctX3rpwc/4XTOhu3oYPF6V5/tGhDVml5tyVep5oyLnparCE5NjJMrlAoJR6PRyxCoRxi+4lE Iq/HI5FJ3ZxbKvPvkvh28SKR2OvxSmQSN+eSymS0F0WDfjfoXwp9btDn4WjYQSqTujh3l9lZ2dZT 0dZb2Nxd3d0/MVx/95Lp189KN6q+VEjrK7jNz4fQyy9s7Dla3ZTT0NljcXAOHjnSXqmb9/AsL2XI 4B7WzfIiiUjK826PiJfwEhGLQjEelCeHUBnP8x6RR8yLJSIx7UXRoN8N+pdCnxv0eThadvBC09kj 0cnFWrV0dmLM3KSIzNTomCDN2a3IUXGbfwivIPTbnLDknE6XVRAkDO9mWGKasSxexLzgFolkjIDg ExkPjWkWB8Ceg0UnZgU32ShwIjGq0dFeFA363aB/KfS5QZ+Ho2cHrUislktUcmmQWgm7aTS+0a/B baMZjh5DEaAIUAQoAhSBi44AVV+86LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+ C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQ BCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAE AowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG67 6LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiK AEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoA RSDACPw/jRlMVUNEDuMAAAAASUVORK5CYII= --Boundary_(ID_aJc0zcBwFnXUxnWQ2rZCRQ)-- From rob.stradling@comodo.com Thu Jun 27 05:53:27 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BC121F9D47 for ; Thu, 27 Jun 2013 05:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiKFME7LFcTT for ; Thu, 27 Jun 2013 05:53:23 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5691B21F9D4E for ; Thu, 27 Jun 2013 05:53:22 -0700 (PDT) Received: (qmail 30911 invoked from network); 27 Jun 2013 12:53:20 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 27 Jun 2013 12:53:20 -0000 Received: (qmail 28136 invoked by uid 1000); 27 Jun 2013 12:53:20 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 27 Jun 2013 13:53:20 +0100 Message-ID: <51CC35C0.8030609@comodo.com> Date: Thu, 27 Jun 2013 13:53:20 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: i-barreira@izenpe.net References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: bergtau@gmail.com, wpkops@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:53:27 -0000 On 27/06/13 13:27, i-barreira@izenpe.net wrote: > Hi > > Then we´re assuming that web PKI means only TLS connections, am I right? I think we're assuming HTTPS specifically, rather than all TLS connections. "Web" implies HTTP. > So “web” is used only in “browsers”? Yes. http://en.wikipedia.org/wiki/World_Wide_Web says: "Not to be confused with the Internet. The World Wide Web (abbreviated as WWW or W3, commonly known as the web), is a system of interlinked hypertext documents accessed via the Internet. With a web browser, one can view web pages that may contain text, images, videos, and other multimedia, and navigate between them via hyperlinks." http://en.wikipedia.org/wiki/Web_browser says: "A web browser (commonly referred to as a browser) is a software application for retrieving, presenting and traversing information resources on the World Wide Web." IMHO, any client that accesses resources on the Web is by definition a Browser. > I think this is not fair. We are > talking about trust models and browsers root stores is only “one” of > these models, not the only one and we should consider the others. > > I don´t get why we are assuming that web PKI is only referred to the > browsers, See above. > and if so, the document could be very simple, just pointing to > the browsers policies or leave it to the CAB Forum, which is not a > standards body like it can be IETF. > > If we´re to produce a standard on trust models we should consider all > options, not just one because it´s the most used. That is not an standard. All options within the "web PKI"? Yes. All options outside the "web PKI"? No. > Regards > > Hiya, > > On 06/27/2013 08:04 AM, i-barreira@izenpe.net > wrote: > > > Hi, > > > > > > I don´t know the numbers because I´m not managing it, this is > > > typically done at the ministers in the national governments which are > > > the responsible for managing the TSL, > > Those would be the wrong numbers I think. > > The numbers of interest relate to real-world usage in TLS sessions. I'd > be very surprised if any of the ETSI stuff showed up in anything near > 0.1% of TLS sessions. > > If it does not then this WG should just ignore it and concentrate on the > 99.9% of stuff that actually happens. > > Is anyone claiming that the ETSI stuff shows up in >0.1% of TLS sessions? > > > but in any case, I sent an > > > email asking for these numbers, which in any case it´s only for one > > > country. > > > > > > OTOH, I think this is not about percentages (or at least I don´t see > > > that way) since these TSL are mandated by law. > > So what? There are loads of digital signature related laws in the world. > They are all irrelevant for this wg unless they impact on what is > actually used to a non-negligible extent in the real web pki. > > > But, if numbers are > > > needed, there are 27 (EU member states) reliable trust stores that > > > must be considered, not just 5 (browsers) and you can add Adobe and > > > Oracle (also have root stores). > > Wrong numbers again. This has nothing to do with how many > implementations exist but rather with what is really commonly used. > > > IMHO, this document has to take into account all options because if we > > > are only dealing with browsers then I think the CAB forum is doing it > > > now and it will be a useless or repeated (similar) work. > > That ("take into account all the options") sounds like a recipe for > failure to me given the lack of activity here and the history that the > PKI community has of spending way too much time on niche corner cases > and ignoring what's actually commonly done. (Sorry that's a bit of a > rant and I'm as guilty as anyone, or was in the past - I'm reformed now:-) > > S. > > > > > > Here´s a link on recent news of Adobe if it´s of interest. > > > http://blogs.adobe.com/standards/2013/06/25/alignment-of-adobe-approve > > > d-trust-list-aatl-and-eu-trust-list-eutl/ > > > > > > Regards > > > > > > > > > Ińigo Barreira Responsable del Área técnica i-barreira@izenpe.net > > > > 945067705 > > > > > > > > > ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta > > > egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada > > > (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, > > > korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene > > > informacion privilegiada o confidencial a la que solo tiene derecho a > > > acceder el destinatario. Si usted lo recibe por error le > > > agradeceriamos que no hiciera uso de la informacion y que se pusiese > > > en contacto con el remitente. > > > > > > > > > -----Mensaje original----- De: Stephen Farrell > > > [mailto:stephen.farrell@cs.tcd.ie] > Enviado el: miércoles, 26 de > junio > > > de 2013 12:51 Para: Barreira Iglesias, Ińigo CC: bergtau@gmail.com > ; > > > wpkops@ietf.org Asunto: Re: [wpkops] Silence > is deafening - Trust > > > Model Paper > > > > > > > > > Hi, > > > > > > On 06/26/2013 11:34 AM, i-barreira@izenpe.net > wrote: > > >> For example, in the EU there´s a so called Trust Service Status List > > >> (commonly called TSL) which is another trust store managed by every > > >> EU member state and regulated by law in which there´s a list with all > > >> CAs (and issuing CAs and services) that fulfill the requirements > > >> imposed by law that follow some ETSI standards. This is mandate for > > >> all the CAs offering qualified certificates but it´s also possible > > >> for non qualified certs, like SSL. This is also web PKI because these > > >> services are consumed thru web services for example on a machine > > >> readable process or thru a web site for human readable process. > > > > > > How does that square with the charter requirement that this wg not > > > delve into stuff that's not much used? > > > > > > The charter says: > > > > > > Only server-authentication behavior encountered in more than 0.1 > > > percent of connections made by desktop and mobile browsers is to be > > > considered. While it is not intended to apply the threshold with any > > > precision, it will be used to justify the inclusion or exclusion of a > > > technique. > > > > > > Is there any evidence as to the level of use of all that ETSI stuff? > > > My impression is that it'd not meet the rough threshold above. > > > > > > BTW: I'd really like to know, I'm not (only) trying to simplify the > > > work here:-) But simplifying the work here seems like something that > > > is needed for progress given the relative lack of activity. > > > > > > Thanks, S. > > > > > > > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From stephen.farrell@cs.tcd.ie Thu Jun 27 06:00:52 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A4E21F996A for ; Thu, 27 Jun 2013 06:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbxI5pxGtg6T for ; Thu, 27 Jun 2013 06:00:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF7F21F9D4D for ; Thu, 27 Jun 2013 06:00:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 79487BEAF; Thu, 27 Jun 2013 14:00:14 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbwKONiHkNUt; Thu, 27 Jun 2013 14:00:14 +0100 (IST) Received: from [IPv6:2001:770:10:203:24df:5689:4b1e:394b] (unknown [IPv6:2001:770:10:203:24df:5689:4b1e:394b]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 56D98BEA1; Thu, 27 Jun 2013 14:00:14 +0100 (IST) Message-ID: <51CC375E.9080607@cs.tcd.ie> Date: Thu, 27 Jun 2013 14:00:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Rob Stradling References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> <51CC35C0.8030609@comodo.com> In-Reply-To: <51CC35C0.8030609@comodo.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bergtau@gmail.com, i-barreira@izenpe.net, wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:00:52 -0000 On 06/27/2013 01:53 PM, Rob Stradling wrote: > > All options within the "web PKI"? Yes. Modulo the charter's 0.1% threshold thingy, right? If folks here start delving into smartcard based this or that for client auth for example, then this'll fail. S. From ynir@checkpoint.com Thu Jun 27 06:05:29 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468B921F9A58 for ; Thu, 27 Jun 2013 06:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Fu+ANEDn2B for ; Thu, 27 Jun 2013 06:05:23 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7221E21F9D59 for ; Thu, 27 Jun 2013 06:05:06 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5RD4rdR002191; Thu, 27 Jun 2013 16:04:53 +0300 X-CheckPoint: {51CC3875-2-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 16:04:53 +0300 From: Yoav Nir To: Rob Stradling Thread-Topic: [wpkops] Silence is deafening - Trust Model Paper Thread-Index: Ac5w+ZSoQsntgfnhSwGtPfDMuxnBDwAG044AAAa7noAAA8QbgAAaeCeAACW2UAAAAJM6AAAqXrSAAARjsgAABuY8gAAA5x4AAABnagA= Date: Thu, 27 Jun 2013 13:04:53 +0000 Message-ID: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> <51CC35C0.8030609@comodo.com> In-Reply-To: <51CC35C0.8030609@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.29.34.101] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1131960c28e7c41776e6547d30cca4ff13088dbfd1 Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:05:29 -0000 On Jun 27, 2013, at 3:53 PM, Rob Stradling wrote= : > On 27/06/13 13:27, i-barreira@izenpe.net wrote: >> Hi >>=20 >> Then we=B4re assuming that web PKI means only TLS connections, am I righ= t? >=20 > I think we're assuming HTTPS specifically, rather than all TLS connection= s. "Web" implies HTTP. >=20 >> So =93web=94 is used only in =93browsers=94? >=20 > Yes. >=20 > http://en.wikipedia.org/wiki/World_Wide_Web says: > "Not to be confused with the Internet. > The World Wide Web (abbreviated as WWW or W3, commonly known as the web),= is a system of interlinked hypertext documents accessed via the Internet. = With a web browser, one can view web pages that may contain text, images, v= ideos, and other multimedia, and navigate between them via hyperlinks." >=20 > http://en.wikipedia.org/wiki/Web_browser says: > "A web browser (commonly referred to as a browser) is a software applicat= ion for retrieving, presenting and traversing information resources on the = World Wide Web." >=20 > IMHO, any client that accesses resources on the Web is by definition a Br= owser. I disagree. The world wide web is called that because of the hyperlinks. So= my OS downloading an updated using HTTP is not part of the web. Also cURL = is not "the web", although it's similar enough that in terms of PKI that I'= m not sure we need the distinction. To be "on the web" you need to be able = to click hyperlinks. So lynx qualifies but web services do not. Yoav From rob.stradling@comodo.com Thu Jun 27 06:16:03 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F4D21F9D9A for ; Thu, 27 Jun 2013 06:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TQMLv9vPlZJ for ; Thu, 27 Jun 2013 06:15:57 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA7921F9D96 for ; Thu, 27 Jun 2013 06:15:56 -0700 (PDT) Received: (qmail 8958 invoked from network); 27 Jun 2013 13:15:55 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 27 Jun 2013 13:15:55 -0000 Received: (qmail 32690 invoked by uid 1000); 27 Jun 2013 13:15:55 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 27 Jun 2013 14:15:55 +0100 Message-ID: <51CC3B0A.8020405@comodo.com> Date: Thu, 27 Jun 2013 14:15:54 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Farrell References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> <51CC35C0.8030609@comodo.com> <51CC375E.9080607@cs.tcd.ie> In-Reply-To: <51CC375E.9080607@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bergtau@gmail.com, i-barreira@izenpe.net, wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:16:04 -0000 On 27/06/13 14:00, Stephen Farrell wrote: > On 06/27/2013 01:53 PM, Rob Stradling wrote: >> >> All options within the "web PKI"? Yes. > > Modulo the charter's 0.1% threshold thingy, right? Sure. > If folks here start delving into smartcard based this > or that for client auth for example, then this'll fail. > > S. > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rob.stradling@comodo.com Thu Jun 27 06:30:50 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971A921F9DED for ; Thu, 27 Jun 2013 06:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pim2xsgwWFD6 for ; Thu, 27 Jun 2013 06:30:46 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 59A2821F9DF2 for ; Thu, 27 Jun 2013 06:30:44 -0700 (PDT) Received: (qmail 17993 invoked from network); 27 Jun 2013 13:30:43 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 27 Jun 2013 13:30:43 -0000 Received: (qmail 22058 invoked by uid 1000); 27 Jun 2013 13:30:43 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 27 Jun 2013 14:30:43 +0100 Message-ID: <51CC3E82.4070903@comodo.com> Date: Thu, 27 Jun 2013 14:30:42 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yoav Nir References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> <51CC35C0.8030609@comodo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "" , "" , "" , "" Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:30:50 -0000 On 27/06/13 14:04, Yoav Nir wrote: > > On Jun 27, 2013, at 3:53 PM, Rob Stradling wrote: > >> On 27/06/13 13:27, i-barreira@izenpe.net wrote: >>> Hi >>> >>> Then we´re assuming that web PKI means only TLS connections, am I right? >> >> I think we're assuming HTTPS specifically, rather than all TLS connections. "Web" implies HTTP. >> >>> So “web” is used only in “browsers”? >> >> Yes. >> >> http://en.wikipedia.org/wiki/World_Wide_Web says: >> "Not to be confused with the Internet. >> The World Wide Web (abbreviated as WWW or W3, commonly known as the web), is a system of interlinked hypertext documents accessed via the Internet. With a web browser, one can view web pages that may contain text, images, videos, and other multimedia, and navigate between them via hyperlinks." >> >> http://en.wikipedia.org/wiki/Web_browser says: >> "A web browser (commonly referred to as a browser) is a software application for retrieving, presenting and traversing information resources on the World Wide Web." >> >> IMHO, any client that accesses resources on the Web is by definition a Browser. > > I disagree. The world wide web is called that because of the hyperlinks. So my OS downloading an updated using HTTP is not part of the web. Also cURL is not "the web", although it's similar enough that in terms of PKI that I'm not sure we need the distinction. To be "on the web" you need to be able to click hyperlinks. So lynx qualifies but web services do not. Sure. (Sorry, "accesses resources" was imprecise). Just "retrieving" doesn't make an application a Browser. A Browser needs to do "retrieving, presenting and traversing". -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From kent@bbn.com Thu Jun 27 07:35:38 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256AD21F9E1A for ; Thu, 27 Jun 2013 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CzjIPA4T5sY for ; Thu, 27 Jun 2013 07:35:32 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 28FA321F9E0C for ; Thu, 27 Jun 2013 07:35:32 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:52966) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UsDII-000OH8-AI; Thu, 27 Jun 2013 10:35:30 -0400 Message-ID: <51CC4DB2.70200@bbn.com> Date: Thu, 27 Jun 2013 10:35:30 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: i-barreira@izenpe.net References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> Content-Type: multipart/alternative; boundary="------------000600060902010907080208" Cc: wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:35:38 -0000 This is a multi-part message in MIME format. --------------000600060902010907080208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Please re-read the charter. The scope of the WG is narrower than you seem to wish. If this is going to be a persistent problem, then maybe you ought not be a co-author for this document. Steve ------ On 6/27/13 8:27 AM, i-barreira@izenpe.net wrote: > > Hi > > Then we´re assuming that web PKI means only TLS connections, am I > right? So "web" is used only in "browsers"? I think this is not fair. > We are talking about trust models and browsers root stores is only > "one" of these models, not the only one and we should consider the > others. > > I don´t get why we are assuming that web PKI is only referred to the > browsers, and if so, the document could be very simple, just pointing > to the browsers policies or leave it to the CAB Forum, which is not a > standards body like it can be IETF. > > If we´re to produce a standard on trust models we should consider all > options, not just one because it´s the most used. That is not an standard. > > Regards > > Hiya, > > --------------000600060902010907080208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please re-read the charter. The scope of the WG is narrower than you seem to wish.
If this is going to be a persistent problem, then maybe you ought not be a co-author for
this document.

Steve
------
On 6/27/13 8:27 AM, i-barreira@izenpe.net wrote:

Hi

 

Then we´re assuming that web PKI means only TLS connections, am I right? So “web” is used only in “browsers”? I think this is not fair. We are talking about trust models and browsers root stores is only “one” of these models, not the only one and we should consider the others.

I don´t get why we are assuming that web PKI is only referred to the browsers, and if so, the document could be very simple, just pointing to the browsers policies or leave it to the CAB Forum, which is not a standards body like it can be IETF.

If we´re to produce a standard on trust models we should consider all options, not just one because it´s the most used. That is not an standard.

 

Regards

 

Hiya,



--------------000600060902010907080208-- From i-barreira@izenpe.net Fri Jun 28 02:15:20 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B5D21F84B6 for ; Fri, 28 Jun 2013 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGZzhWInJkDi for ; Fri, 28 Jun 2013 02:15:08 -0700 (PDT) Received: from correo.euskaltel.es (ektmail1mta2.euskaltel.es [212.55.8.13]) by ietfa.amsl.com (Postfix) with ESMTP id B3C2321F8F6E for ; Fri, 28 Jun 2013 02:13:35 -0700 (PDT) Received: from ejlp023.ejgv ([195.77.108.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MP3001PEIYKVTJ0@ektmail1mta2.euskaltel.es> for wpkops@ietf.org; Fri, 28 Jun 2013 11:13:33 +0200 (CEST) Received: from afe02.ejsarea.net (afe02 [10.200.192.15]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id r5S9DWB4027785; Fri, 28 Jun 2013 11:13:32 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe02.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Jun 2013 11:13:32 +0200 Date: Fri, 28 Jun 2013 11:13:30 +0200 From: i-barreira@izenpe.net In-reply-to: <51CC4DB2.70200@bbn.com> To: kent@bbn.com Message-id: <763539E260C37C46A0D6B340B5434C3B076D46C2@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/related; boundary="Boundary_(ID_zp2Ti81A6JDWOQWbYQGxUw)"; type="multipart/alternative" Content-class: urn:content-classes:message Thread-topic: [wpkops] Silence is deafening - Trust Model Paper Thread-index: Ac5zQ5WF5QCdNaNeTjCo6IqHFbosQQAm/O3A X-MS-Has-Attach: yes X-MS-TNEF-Correlator: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> <51CC4DB2.70200@bbn.com> X-OriginalArrivalTime: 28 Jun 2013 09:13:32.0534 (UTC) FILETIME=[C2EA0160:01CE73DF] Cc: wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 09:15:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_zp2Ti81A6JDWOQWbYQGxUw) Content-type: multipart/alternative; boundary="Boundary_(ID_N34OdVDAe2EZr+8jyoZ9Sg)" --Boundary_(ID_N34OdVDAe2EZr+8jyoZ9Sg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Ok, I=B4m fine, no problem if this is only for SSL certs. But maybe = sometime in the near future there=B4s a need to deal with a complete = trust model in the web. =20 =20 I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 =20 =20 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. =20 De: Stephen Kent [mailto:kent@bbn.com]=20 Enviado el: jueves, 27 de junio de 2013 16:36 Para: Barreira Iglesias, I=F1igo CC: wpkops@ietf.org Asunto: Re: [wpkops] Silence is deafening - Trust Model Paper =20 Please re-read the charter. The scope of the WG is narrower than you = seem to wish. If this is going to be a persistent problem, then maybe you ought not be = a co-author for=20 this document. Steve ------ On 6/27/13 8:27 AM, i-barreira@izenpe.net wrote: Hi =20 Then we=B4re assuming that web PKI means only TLS connections, am I = right? So "web" is used only in "browsers"? I think this is not fair. We = are talking about trust models and browsers root stores is only "one" of = these models, not the only one and we should consider the others.=20 I don=B4t get why we are assuming that web PKI is only referred to the = browsers, and if so, the document could be very simple, just pointing to = the browsers policies or leave it to the CAB Forum, which is not a = standards body like it can be IETF.=20 If we=B4re to produce a standard on trust models we should consider all = options, not just one because it=B4s the most used. That is not an = standard. =20 Regards =20 Hiya, =20 =20 --Boundary_(ID_N34OdVDAe2EZr+8jyoZ9Sg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Ok, I=B4m = fine, no problem if this is only for SSL certs. But maybe sometime in = the near future there=B4s a need to deal with a complete trust model in = the web.

 

 <= /p>

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

945067705

 <= /p>

3D"Descripci=F3n:

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

 

De: Stephen Kent [mailto:kent@bbn.com] =
Enviado el: jueves, 27 de junio de 2013 16:36
Para: = Barreira Iglesias, I=F1igo
CC: = wpkops@ietf.org
Asunto: Re: [wpkops] Silence is deafening - = Trust Model Paper

 

Please = re-read the charter. The scope of the WG is narrower than you seem to = wish.
If this is going to be a persistent problem, then maybe you = ought not be a co-author for
this = document.

Steve
------

On 6/27/13 8:27 AM, i-barreira@izenpe.net = wrote:

Hi

 

Then we=B4re assuming that web PKI means only TLS = connections, am I right? So “web” is used only in = “browsers”? I think this is not fair. We are talking about = trust models and browsers root stores is only “one” of these = models, not the only one and we should consider the others. =

I = don=B4t get why we are assuming that web PKI is only referred to the = browsers, and if so, the document could be very simple, just pointing to = the browsers policies or leave it to the CAB Forum, which is not a = standards body like it can be IETF.

If we=B4re to produce a standard = on trust models we should consider all options, not just one because = it=B4s the most used. That is not an standard.

 

Regards

 

Hiya,

 

 

= --Boundary_(ID_N34OdVDAe2EZr+8jyoZ9Sg)-- --Boundary_(ID_zp2Ti81A6JDWOQWbYQGxUw) Content-id: Content-type: image/png; name=image001.png Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.png Content-description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAkkAAABvCAIAAAB3iMNhAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAASlZJREFUeF7tXQd4HNXVndned7XqvViSZcm9yLiC7RgwNtWAA0looSUhBUJI QjUtTk8I+UO3DQSMjQEbN9yrbElWsXrvva2k7bNl5j9vV5ZFM8Je2RDe++z9dmfmvXlzZjVn7333 nssKgsB8/eZEF55h3AwjYRgMgH9442IYOcNgH17x3r8Lh0m/ZBftNRIoigZFg/6l0OcGfYp+jlNY JyNXfG2WYkfDbV5e6Lc7KlsGdxY1HK5rKWjocnJ2xmxj5DKG9zAMyzAiRvAwUilj5xi1gnFyjFTG eD2MyLfL42FkUobjGKWCcXCMjPaiaNDvBv1Loc8N+jwcHTsYDXqFPD0uaGZs3NWzkiZFG0PVCrFI dHa6+2puy2vo3phTtvFkZVePOUynzkgwZiYnxwWLtHIDy/JiMetyE8tPLmPdboEXWJYR5HLW6RQY lpVJsIXxeLFNUCpZh4NsFIsE2ouiQb8b9C+FPjfo8/Ar2QHWUb/d1tlrzaprruswt1sHNFrNbTPT blswaWpc2Fno7Wzc1tRvfetQ4Yu7i9Qa8YqpKddMTZmTFqeR4NcWbRQBigBFgCJAEbigCMB6OlLV vr2k7uPcSpPd8ZPFk++7dFZ8iPYLJ/Gl3La/ouFX/z3Y0Wv5xbJZP1g4aZzxi/tf0CujJ6MIUAQo AhSB7zwCzf3mV/YU/mdfXnhYyJ9XzrlmeurnIfkCbnN5mN9/tO+F3afunJ9+/2UzZyScze77zoNM AaAIUAQoAhSBi4BAcXP3K0fL1h48efe8SU/fssSokI2cxGe5DVGNd7+8fd3BvH/df9MDi9JZEidC G0WAIkARoAhQBL6JCKzPKb/31Y/vWjDt5TuuGDm/z4aaPLclZ93+ovd+e8vPF2VQYvsm3kk6J4oA RYAiQBE4jcAds9M/eODGd46XP78950u5bX9l4592ZP3nZ9etmj6eQkcRoAhQBCgCFIFvPgJXT0v+ /fK5j288sKe6eXi2Z+y2xr7BX7y2Y2VG3I/npX3zL4bOkCJAEaAIUAQoAn4EfnXljGvSU+7524eN Xf3+LUPcxvP8S3tOdbvFD96wUCYVU7woAhQBigBFgCLwbUFAJZf8+a6lvEL63NYTbg/iRk5zW3Zt x2t78x5dMWPaWbPhvi3XSedJEaAIUAQoAt8pBMaH65+6Yd4bh/Nz63uGuM3DCxvza0KD1DdmUm/k d+rLQC+WIkARoAj87yDwo4WTJsdE/emT40Pc1mNzfpBbsWxmcqyBJmj/79xmeiUUAYoAReA7hYCc FX9/Yfq2E5Vmp4ustxW29pp6rCumJo8WBbeHqalg6uuZ+hqmvo6pryVvqqtH250eRxGgCFAEKAIU gTFA4ObMCQwv7K5oIbnbD75zcEt+TcUff6yQjSKKZNDiWvM009PA8HJGyjMeXxYchnF65NNmMA/+ zqf9TxtFgCJAEaAIfLMQQP2cxh6ryW4XeN7LeyVSqZtzyRRyvOK91+th0RiRb5fk07u8vl2sl/ec Wy+xRCpnhHC9IVwvH2tN4omPvj4jJZJw28yn3o4O02z92fWjuQ+ubR/ya551qFVKGSO4Ga8YEv+M FJUAxAzXO6h77Q12yuzhcewe3mrj7Dy/v7xOyogUMklUsGFKbOjewpp+jnN7RIvS4iQ8o9LKInVK zu1tNNkTQpQnqjpru3qlUtHl0yZEqqVHG1qrG828IATrFAvSIkM1qtHMkx5DEaAIUAQoAn4EPsiv eS+7orStx+L0eJwO1NcUJAzr4XiJVOQWC1Iv6/EIYjzTWVZwCWKW9Uh5qSByOQWpgvWwgtiNYpys IBHE596LlcnlUqlep8pMCnvkiktTojRjdHd++c6+A5WNxCdZ2TEwOzpqlKeRoU6bRKLQGRhWyar1 YolaItcwSi0jUko1WqbPPnKcqq7+LUW1LsGjlqvUWvmJ2u5nP86q7jOvz6mWyFWMSGRUqd4rrLzp Xx+jV7+DeyentKDR9H5upc3NdNtdN/xrA7a/erC022pXaFivIEjB/bRRBCgCFAGKwOgQQIHNm1/e fuOfN2w+VlzZ0tPW2dPlcHV53N2Dli6X0MN5ujxcd7+1y8t0u9zdNmuX3d3N8V1eV0/fYBcv6na6 ujhHt8XR7eLPq5db6OwdbDLbMInXd5Ze8vjrj24/6hJIsH7AW2ZCbGOfU4Qq2TbOEWL8ijpvw6fn nC4YaazT4ZXxTpeTFcMp6ea8Lnxk3S5G/SmHpEQQBm12NSv6/szklZNTiuo6V1+7kPe6p40LvT0z 5f5LM0L1Up1CUd7S2tFnlqGwm8DwIiEyXHPdrJTfXD7zkrio9cfKgsTiX62Y+aPM9JtmJRvko/Ca BhwqOiBFgCJAEfgWInCkplV9+5r39+SSpSIlnIJeUhoajIKa0goF4/UyYjGD5zacYR5YZnDBiRmx r2asy8XoNAznYsSgBvSCUcGTctPn3MvjZfQaxolhlYzcY/I417y2O+P3r1WbLAHHNTRE7bDbRaR4 6IA5wmAc5QnkSgUpP6pQil3wMcoFrxh4yMUyfBRQ99v22WHkKFQqIoT0QXGNSMrMSQzlHF67xc3x /IAdxMqIJbKfXj3rxSNFGplUIfASN8/yEouD7OowWydE6txyRVNXv83psnFueCZHOU96GEWAIkAR +C4jsD6natFj77i8DBNsYFRKQlRgJgmWkWCdiAhpKRWM3UF24ZkOhyQITyIl5OfmUGyaQIcDnHgf oF42B6PGuUSMBIMLTJC2tqpt2u9eKu40BfY2GZUK1MMGP+M6FU7XaG1DF7lUhsMrCSRx8WLg4WG8 bkYiuMD/n44jwSe32836DM8/vJ/9n3uW4o3g5neeqrl37Z6fvHugvt86YLX+aNbktgFHSYtJLpcw SqGso2vdkVP3vLkjMSRo9rjY9o6uhzYee+DNQy/sLTT56JA2igBFgCJAETgLAltO1f7m9S08lpDA ZLDPQGyw2ziOQZS7CKaYwMCQwmMcZANDAgfgQS6W4nlNLDZYaTiM58eyl4SYiXqVvdN+2ZP/bekP pPXGC5yE2J5ShpG4Ry+zJZFJGSejkEkFD+sVS8U8iyARr0gCY1culjCiT9lV+CCTyvRa1eotWdfO Sk01BuFm8DLm6ksy3rz7yg13X5UUpOFcLjfPPLZs7t/25Mrwk4EXJ+h1105Pe+GHl6+56VIcL1fK X7/jynX3Xf7oiswQ3AnaKAIUAYoAReDLETjZ0v3wO/t6BznGoGBgMLjceBDDiGHgQoOlAW6TSAif +W04qZTwHLb4Q9xJpCTLSC9IL5w9XNff27v87+8H9H6S6EYRXKm4YO9ozTaGd3KCl/C8AHcm70Xo DOhXEMhH8qNACwTPNOyQidiS1p681t4nVwzFT3o8vFjkHj4Isah9DmdqhEYiEo5XNklYiUohjwnS qfAjwtc8do9aRZfZAnrr6WAUAYrA/ygCHoH/KLesrrEDJgiDStMeD7HY8AqbDOQFryN57yFsBwbA Rthn8ECC3rARy29gPmy8YL1gJmpVJSdrcxo6AndDwNt+PUmXMPqUNMmM6bKISM4+yFo5iZPz2hwe h13sdLEDNiEhgUn6lGqXVCLVKqRbT1bwHuHVrOK/78t783jloM2JcJ0XDxT+ZfdJBFIGBSlEWPNj mFvmT7HbPSqpWAnQQZmnm1ot++OO4y/uK1qfVdpt+dyCXuDwoCNRBCgCFIFvOwLtfZaDBc2MSMZI fL7HoYWizz/jTxfo/OKnv3/rhekF/57qiQ/3Bw55Mm3W7uZVN67+4Kkf3jAtZbRDnyrgOmolXgWA E8QkukOEYEmsTCYmiiZMHAmG3eUZdHD9VnuP2Sng14DHo1bK4oO0DT2DLp73ePn0qFCs2ukVKr1S xnn5mnZTYri+x+oI16mUsJF9rbitu3PQLhZEMoVoSnSoTkHTAEZ7o+hxFAGKwHcNgQM1LUueeZf4 HhHxCH8jzDL4JPEGj2hYZtiO9+A8/8IbHrMw0eC4gxMS3ki8R7vwvewusUzW8OIvYvUBeLznNnXP Xb2etTt51e3Pb/r1qptmjZrbvmtfFnq9FAGKAEXg24CAIPB/3JX76Kt7GQNYTSAeSDgYsa4GJoOL EhElWHLDchoYDvGK8EPCVEAsCYiN5ANIGCwzwVrx+y0RhcG5P9sLrj6/uxJhfYQCfb1IUgE/dC7/ Qh05l5twJzkXsr6RKfa5XsPnwgxxrj7zusduvyMzADSU29Q2b/U7IkbGMi6OEDltFAGKAEWAIvBt RsDh5suasHCFOHYZieZ3cYTYsIqGFTUHQtwhlAgCAxWxjMnB9FuZzh6G8zB9g0hzZvrNjMXOWJ2M aYAZsDAdVkaOyEHXmV5YvMJooENE8yM9gIwsYWx2ZsBKuvf1Mw4X09NPBuzuZ+wcM2hlzDYyFI7H BIZ7gV+RKgfWOTNDCSOTnKhuDQj2LBLoiE/SxqtuXfPeozeuykwNyLh0EIoARYAiQBG4KAggEfiq v27MLqkn6djgMHAPgjXAQ4RXENmPXGwpY7YyCuk1C6atSI9PDg0TWAQxIP4c2WD+kD3E+kmru3r3 VzVt3JFLtqkUQ8YZLDB0B1/6B0RgRG9/9ITEe+ZNzEwOV0hUAtHyQgbb0IAsK7E57SebetceLGqt qmUiw0nWAfoi6hDjsKBYDHh6hmbrtUtmbrlv+fnjltvUMnf1BtbOC6obHt+y+vZrpwTAGDz/adER KAIUAYoAReDcEBh0uK7/50cHT1YzOoRB+kL54Q+02gnVgZncSHTj5s9M2Xz/1eEa9VefQmCu/dtH H2efIj5GJfhPIA5MGFtwNrrcRqVk3S+vuyZ9VAVk/rQv/3drd/kSw92ELP0hmohV8c/QZmO8yitn x+166OavntVXHZHb1Dd39VoRwwlIO4cbdowaLsFFAjLPqxEcvDzPC17fv/Maa3Sd/WdEbXIEvIyu xzf3KDvngRTnyPmRpEy42mmjCFAE/rcQwHqbC6oiImRnnU7QBhuB2KA/gnUyzrny0qnbf75yVMQG ZFhm68PXP7zqMkKKMLnAE/60bs4drpbnP3fvKIkNI/32ezN2PvEDpt9JolcwFAYBpflTyDFDtZoR rJCwCtDdcPIMghex0uZ0gzvHotncnl0VzRtO1mwsqG7sM5/9FOCsL+OtTgf3fn7duyfK3swuP9nU 5/J+Nb15BOFYXY/5rE9wkGV1d38XXMyfa302bkd5y5bCxnePVxyu6RwLcL5yzD6rM6+ho7C5K7+x s23AimRBdLFy7n44xL+q2d0eCxzlvrajuHnXqfrhHg09ls25de+frPmgtMHs9EDJ7GjDWS8QIp9I YvyqM9L9FAGKwMVHAH5ARILwPkmt4QRt/PnCf2h3Th8X9ddVC/VYRRvROgZt3WZ754AdT8JOi717 0IbfviPbU9fMv3beJLJ+hkASf1q3zb7nydsSQnUjDxu0uzoG7N0Wu/+1a9BuR1DJiLZsQuKfHljG mJxDHk6sAp6ZITnuU0efF5TDudvM18jd/lpnrG437cipcjrcDa1997+15+x9TzWbaroGvvAY3ut1 OJx7ShqOV7WzrFc0Ivvty8Z0ssLRyqZPy6R89liRiN1Z3Fjc3P35QQQkpyNjQcVuKak9WHGGGL7W 5Z/nwV1m54Gq9uyGjr/tztmLUnss2z5ge2pb9sHytrOPbOFcL+4vOFRDFmb7nEKf0/pRbgXsc387 WNW0u7JWLhHvK2z61678+h77q3uLzjKgyeo8UX9x2P08AaTdKQLfOQTwS9QvqeHPxfYnaCOD2+2R KmT3L5mZYNQPY1LR3vvsjtx7Xt9x76u77n5t172vk3/3vbbzyQ+PFLee0XjUyKU3Zo6XoMwLFKRg /FlsC6amTI4MHh4HysDrskp/sW7f3a9+ct+ru+7BUK+Q10c2Hny/oBq/noePfGTprEmTEhkU2flM CjlhQcRKBuonNGqvMeLHnnzq+S2HV82flB51Zq6B+kK0DliR+Xb/ZZPnj49ds+Xoz5bOhKn0YW5N YUtvhE6tkon3V7TsKqmNC9GrxLKf/ndPTYfpsvT4xr6BD/KqBjh3Yojeny2nk0mnJ4T32byT40KW TojrHrRvzqssazdNjgn1er2Hq1uza9ttnKekpa+4tXd8hMHs4t84VCBiJZMiDQqp9HB12yflDRzn jTJowGcYEDbQ7uKmo9VtNZ29U2NCgvXqDdllBQ2dGTHhYt8Barl0QqQxTK0+UtH4k0XT4biu7eoP 16vbzJbOQWe/3XmsprW0rRf3YmtxHVSegzXKwubujwuq+51cfIiupd9W0tp9qKplamzYiYbOnPp2 EnDrZrYUVhe19iSGojyfpKyj/8O8ig6LQyWDNCe/rajmWE17lEGrhWvb10K1innJUbMSIvrM9ilx EVEGdZ/N9cax4vHhQVPjQs9yjwYcrvdzKsJ16imxYbnVHV1ms5uVTk4I1/pqz5Y0d6eGByN0aPq4 yDUfHF0+PaW4u/uq9IR3TlScau2JNGhw7QXNnTmN7Sdq26bFhX9UUPXXHTmzk6PNTuf2wvpTTZ2T 4sJpAdpA/Y3QcSgCAUTA6fZuOFHRDPVhSG2Rspo+kS24fAQmKcz47x8vQ7kV/+mK2nrufWnL24dL auo7qtpNNW0dVc291c3dla3dR8tqD5R1XDMzzaAasvDkEtGJqub23gFCQFbnYzctnZEU5h/H6Xb/ 7eOch97eV1TTikEqW/tqWtur2kzVrR0na9o/zq9XKWQzkyIkRMSSNJgmu3IrSdikv8CNf4bEOcmk xgbfOifj/NFoG7S9cahIRBLPBRSkO/8Bv2AEhVxa2Nzz5MfHb/i/j+5aPBNHHChv6rU5OI9n66l6 VGhDBrdepXrqg+MiCVYrxWqFvMVk+aCgTiWXbS2oyhrhDHS6vEj9hjWFQf59IE+ukFV3mtZlVZjd 3rezKixu70sHC9vNtl2ldbW91rYBW6IhKCJEufZEaVl7T259e7RRZ/bwWELzz3J3WeuWUw06tcKG 7wIrXpdVolaonYL373vyRl7Ga8cqEsODUyOC9pY17ipowK78ut7dJfUbcyoq2vvzm3v/vPukQa9c e6wMuwbsrgidNqe2s7LN9EFu6dvZJSFBpPje3z/JaewdDNEoe6xOvVLR3NMP2sD2pz/ICtFqTzZ0 bjpZbXF7QGlegX05q+wz/r8KMKiYjQsmC78JwZofzkjjEF901hauVV4+McmABVuGidBr2gfMYoHt s1pPd2Lz6rq2F9c+8eGRmxdmiNRSKS8ARqlE3GtxbC2pxWF/2HXSw/KNXeb1x4vDdBqNVCEXifvs HH4clHda3s6uGJOvCx2UIkAROE8EiBik72lOPH6++jV4ZIJIXK6kSKNmhHDw/+0vOVHfRXyMBi1j UJE1OY2MMagZgwYRGNUVtX/Zmzs8lzCtJj40iJiDWJ9QiqaMixjeVdza9+bxMgEx/VoZ1LOYIBWj 1TAgRZTI0ao4u/3/9uTWdw8MHz9zXIwvYRxZd5IzM0SMCfSxvkAG5dzgYH2aW0gE8IyVTxI/F3Ry 0ezYyO/PmJDV2Fbd278xrzqvsaugpePjkgqHy33FxPhIvWoXIlYZZl5y5KyEYIvFFqSQ/vCS9MtS YuFJ8y8yobFiVpCyuF9Hqto5QXTdtNSnr5u79lARFqUmxQVfOTEuRKO+NDUmOdxQ3WXKCNdNjw9F hdnSlj6T2dnYPRCr1y9Lj1XKyLoiCuVsPVV99fTolTPGTRsXU9LUtyWr4lR9W/uA88VD2cNYVnaa Kto6l8GCxiqXx9vvJBn7cPdZHA6pVHLZhLjp0eFqlfzGScmNbcSruSA5Jik0BHexpm+g085dnpqw fEI8AmAYr/TGmWkoFz4x1jg9LooXRB0D5u0FLcF62Y0zUzKTwnud9jidZnZCRJBacrCoAabtyPuZ 29gG1g/RDgU1sWLvSEerh/cWtfbtLmnsRaTviCaWoDA8+ZwWrbv3smk/XTwpKUjr3y8SC5Aua+q3 Ls8Y99PFU+wDVt7jMcglizPiUAk9v7bd6RvqhsnjV05LOV7eOTEmZPb46CijNjM+fHyckefdB6vq zu0bR3tRBCgCY4uAIOCZ4JP59eVTw1/kD+VjWZPL+UkpftM37ihs3Jhbvb+igezF2ptfi4QczJJX HA+m0auOFJ/5M5eKWZnSF9BIzC+JUXsm6KO139yA/DYilI9z4aHD+tLAfeclYvmi1g4TftYPX7VB haB/n8olSbMbMcPTKQiBwAclbsBtyN1mXGMUS+LkXLEG3ZyUyJsvSVs4Lur/duWzvOyni2f+etms N398NeS4fvPegT6HEI4gGQDGimRyKQgsNFiFjwmhIYMCB3Paf6kQZsbTWiqS9NmcCcFqCDUDRJ6V WLzexGAdUgr1CrlMxEvEknCtauOJmr8fLtGgBLpIesn42FVz0188lP/UtmN+zy/IY9BsnxZPSMuo kjf2D85MTrhr4aQ756cXPHbXMLK7SlumxAXPSAjHFjEnUfrKrqo1ChaVDTQajUwiEbGRGgM2aoOV +Pr8cW/W3qo6vUqOSeK8GfEx5FwCo1WwMfhlxDBvZVf8N6dEJVEaNZqipq65afHYGKLVqFn50er2 f+wpQd6IUacY+tnlm0froL2m154YHDz8VZIpZaSE63Bjmazy5o+Lapq6PhWqg+IK7Omgo3ijPiZY oyZC4KR5eNGcCQl3zJ10w4wkOArc+L0AB0X74D935bFSXieXOwUmLAhfXlau12CVzu3xSiS8WCp6 aV/p+3mVBq1OTKoX0kYRoAh84xDAX70MqWOCmNAG0fiHQwyp1iQHIK+0+drVb928eu0Nz6794ZqN 9XVtREAEaWqIfoROL0LPkNwNtRHyz4E/e9PpYDTy+BWLPHiWIaCx3wEvpA1xiKebAxyGHANkbaMj hkLyHDriPUbDeW1Eo9lNCloPNbHLF40y5Cw9PUO7nWHVqI4aIEBleGD6cgBUSm7EuQM0OhlGjB/5 HrdCSp7MB6pap8SFJ0UoecGVGKSXK8QbcstmxcXdPD0BhgsOcHi8bt7rcXlqGwfwMa+tOUIm9/lM fU0QcQ6R3emKVMuKajvhIjORSNTBUIm81+5wcW6bA1GWYthkfeaBZ7Zm/fPG+UsmJ3V2dOO3waUp 0W/8aOmxivbGASK1jCW34BDt4fIGl9tbUNcapVX0W7kYoy4p2NB1Opgzp6qlsrntmtMamzK5t7+f TDKnspGz2bycEwSJ1MBBX4yl1cFUtvSX1fU+tHRGmFFts7nABzZfqTmyjotPLndFZ9/JqpaV05LT EoNaBhxLp8e+l008mQW1La3dvXvLaq6YGL18crzV2o+YkeFbUNrcgV9BMxPOeACsNpz2zC2SsOL7 l0598dbvzYgJGXnjCPIItP2ir4qXd3k9nOK0291ud+CLmlfTdP2MlDkJEVavC6UbLD3kunANWDwG pKwgFHf0lHV2/3j2pJgg5GMG8DtCh6IIUAQChgBsAKeHY1iiy+Ez3XyEhOUJu1Mil4ZEaUPHhRkT w4JjDHHRoRGJhoT4yPAQfXx8eESCMTYyJDoyJCohOD4+VBVmiI8dWlEjjwKvN0ynDooKDUsKU0WF GKRnao0ZJLKI2IjQZCN6RYQZEmIjwxP18THhEeHG2PiQ0JRQY1Q4nvZnrlBGMpAYjy80f3iGKJoq 2OUB80k68Az15W5f//iWp8ckd7uhz7p6S3aDyQSv748WpP904USTy3P7S9s9Hs+9Syddlprw8zf3 hQYpTtX2PHT1PGQC/n7ToZfvuOpYQ8f6I4Xjw0NeuW2JjEhZk4Z8rJ1ljYgMWTQ+7p0TVf89WTbY 5zz+9K39LndeVduUhIiPSxquSI9DTOOs5KR+c899Gw4vTkq0elwTgoNq+00VnabbF2TcNmuCxFcE vN/tuevlHbDrkmJ0v7xsckWr+S+7822841dXzbt5UhwO+Ki4ds22Y9FaTb8NBeTY7Q+svH39ToSQ ZEQbZiXGKKXyjHBtfb+ta8Dxw9mpf9ya/7trZzyxLaegpjUyWJkOmhGYG6ZPSTDKkZX3l70nf3nF LCUj+iC/9rX9pWnRxi6bdcO9V72UVb6toCI5WJ8YGjw3OfL57cdTooJyansfW5G5LIOYdCab/cO8 2snREZnJZ75kO2vbXAP262Z+RaL9/oomsVR+WfIZUhz+bm0rqBHJJFdNTPRTaHWf45Oi8sVpyb98 d2daWEhbv+OBZVNPNQ88/L3JLQ772p35D14166H3DlyaluR1uT7Ir8yIi95fVH/42R+qAvZFDNgf Nh2IIvAdR2DQ6brhHx8dQO62b4WecUA9REaMpEHz9ZdO/fBn1110fGr6LKkP/AtuOlIE/NMzvHLO xF0P3nj+M0SeWObqtazdzqtu+cPGx26++VullUzUNb/tGpg+CdHdpY3Hazuevm7O+d9ROgJFgCLw HUdgwOZc/rdNx4uhuaUc0i8mdbSlcC5dOyd9SyCY4zwRruo1p937d1SyJhEufoXlQM8wt6l13up3 sd5GVpPGaL3tPFE4S/dvO7F5Be9fPjm5v6Jrb0nLorSosQOKjkwRoAh8hxAQsTKwBUQ54DvCijvC IH1BkoiVDNxq1nnBKcdaILgWkxzDGcpJ2To7x6t+9Oz7v7kFMXvnNWXa+WsisKWwpr7TOislfEEy 5baviR09nCJAEfgiBJBGffXfNx8rrEOgo281yxcAiXCSQfPVcyZ+fNpuwyL6J+VIR3KK5V7GJWGk WACDqD/CT7BKh6B0xup2hml0109J8p8Eays5TZ3VbYPY5fHwN89I1qqGCq01mayHq1pxIhHEQDwQ uvIP6CXvhwZEdU98RE6CFyrMNV29T711gLhJFSKSePclMzyf25vb1DF79dus3cWrbnpm85O3rpxO ue188KR9KQIUAYrARUZgwM5d+/fNRwprScoamMPjC2iE6TZoXjFn4rbT3Nbv4OY8v6GqspmwDgvf Hewc/MPB/qAPD+P0RCbEtP/zfv/1mJ3c3Wt3vL+3kJR/4xxF/3l48mn5iLdyq27/2yafor+/u28d X4BcpF/I0ReuibQEF9yP/txdMaNRkHQCEqH9pTM8Hxxzmzpnr37LH4c4Vrnb5zM/2pciQBGgCFAE vh4CJECQ/CepZiA2f7lthEwzipECHVqF3KCC5YQMARVRMIE5BjkkBHeQfGoJkfxnJSGqM8GQIhZW GawxKemiVJOc69NNDSUn+BiROixXkkFAXQocpiQH+0YTySW3Xj770TuueGTV8j/cd80vr188JFCL 5IFPzzBwsrW4HuQAIDNLLj5vpf6vh3/gjg5UPsRnZ9TQPQC54cDNk45EEaAIUATGHgEUAiC52/78 M5AFUaD3UZFnwHZG3gFRipemxJAoSn+pUhKjLxCbDDtgbnkh1e+869IJw9NFMhD0K3zyXTIoVTpH PBtTwg0TooNJZhuGwumQmo0z4r0IryLG6poYEf7E8kuev37+H1bO+f0VmbcunMxAXmqIaT81Q3HA Qq/9udtSVPseq9xtQHOqyXTfm7sf25w1DBMSqE81dfk/muzcw5uP/Pj1Hf6Pg07u8a0nHn4vq91E BKJAXD99d/997+xr7hvKqHJ5+A3ZtY29Q3nK339l97bCutxGIgtyFpbbUVy/Kb9mlKV2HG7vrzYf e+iDw797/1hVe//Zvox+O35EO1HX8WpWmcVFy8eM/d8wPQNFgCLwOQSQuy1B7jbqAMBmIsXSUIwU 615iRimt6+jrsp95ND1xzbxFs1OZ5rahlG0UzrbaSM410le7e5YszvzJkunDw3db7U3dZiypEepi +P0VZyRLIOr78PLZUqTQdQyQmt1IBkfWNjK4rRzTZZHo5Y+vnJsWZcRQPpUIpqC+mXAqaNJfd9s/ Q8yWyHAFpiE5HHaJL3ebV3DuMTGArHZ+Z3ntg1fM8Iq5B7ceIezl4H767t5txU3+i/jt1sPLp8fP TYn9wb8Jvb18sCgkSD0x0fjvA4X4BXD/mzsXp4y7Zcq4n67b5j8e6W5N3abWfvIDpM3haWzunD8l Lsao3FfU9Elh9ZcBkxEdMjHaKDmdrXx2/HaXVIdIRB/95NrV182PCzV82cH7SlvX5pRy/Kdsu1i9 JjM6yi9JTBtFgCJAEbjACMBqcyF3GzYTBB4RHkki7N3ESOK4botl04lTw/PRyGX7H/rRvx+/c2pG 3LSUuGlpUdPGx01LjZk6If7x+6/Z+ouroec+fHBxc2tRYxMxB8FJbsnmvKEHuP+AOxdM3vLrm5ct mTEtPWpaasK0CZF4nTEp5raVc7Ofvuum2WfsPxy87kAJI0iJQBdkt4Zn6LMShqJTzhsygeF8uiQK lmEdCqK8Ffh2orEpVK2JNwb98frF2SVEa1giEUfodUoI3zMMZOb1jHJGZOSPL53c63U299p6zI67 Z6TeOC1ZJBV3DFp7+l0LJkcumJiogWv4dAsOUpS2NePTh1lFV88bHySSmjjPa9mlGwpQIc5p8XBP bT/61pFyHABl5K1F9e/mVJocriijXiSwb+VU/WzDXovjS7WGEQ60s7Bp1ZzJ6G6EOpaULe80Pbbl KESTsQVG+Xs5Tc9tOV7bP1De1vWfT0rKWgax/bWjFc/sPGF2C0atMsKoPtna84+9eS8cKnphT37g MaUjUgQoAhSBL0GAFYsUUgXDQ1zflwMA7Qssm8Eg06o9Ds8/9xU195wR50O0x88WTip8+q6C5+4o ePaegmfvLHjux4XP3PnsdXNRDGT4DD0253+zqiAcxSgV4EgmXF1wtKC0zTJyCldNSdr50HUFz95b 8OxtBc/eV/Dc7Xmr737zx8v8moXD7d9ZlbmFZUyYdsiBOTxDqHOxGmfANLeUYDWf3aZQYsJj0SCN D5FHqU9bxCBTW5yCWipZNStFpSSKkU19VqNRKfaZU4la9e6KZhkr1qgVKBkDkSeocjyz6pLbXtq2 4oUPf79i8fD0UkNDyhsGcONQO+bWSybuLGk8XtaSFhUUHSxDZdnfbjoyPiTkUFX9uydLUWTvF2s/ jtAr86tb3jl8qtpkgT94UXLcz9bvHB4N0lkuLz9clhrDtlndoQZ5vcla2NaHwzrN9kVpSeuPlByu 6vmkquW93MIFE+PtVhfczvHBsjCNYv3xytKWrkiN9jfv7D5R077+0CnBI6TGhH6SV7fuRNVYoErH pAhQBCgCX4iA4OWdI+tuo142xCE1auJp1Cjr61p/+Oq2yk7yZBtlQ5XRx98/sOtICaNTE1sQdbdh CBrU0594JbtxaGlplEN9VFzz8zVvk3GcTiKX7K+77Z+hv+52wNbbHFjH8623OTjpUMmwUU5y1Ifx ZE3Pv2w46HXwWKjEOiUCaXyVexRysdynVUiGk0gFkdcnPEkaZEdQj62x17FkQvx1k1L+cyCbKHX6 2qVpUW4JW9lhNlmsiUatyytKjNDNT4tdlJxQ3tQXqpB/P3P82ntWvH6w3OkWvj9v6uK0eI1GIVap orTK6UnhvEwYgHzn6YYiaq8cLjpc2+U+XWtWLfe6Ge/RmuZfv71ve2Hd3ITwUIMqWCOqbOtJNKiN aqXI45kcGzY9KuLyjJSYEPWftp8I1ytMDqtepe60OhUqcWZ86IzIsIggzYnffX/USNEDKQIUAYrA eSPgz90mdbf9Va09ZFkLz1iSwe2GsOTRUzVL12zacLwCJbZtLvywR/AJeRzjDakBgDdkg2BzeWAb bCmtm/3cf1/ddpLRKocMQSSDIypSKkXFsTlPrPvte0fKOgcHHBycZHhAk9GIGrtvKDIOKIzvtzlR pvK2V3fc8NibDFZ51Kqhutv+mEz/DH3tU6VMzgMJ5KvjiuD0JGLRYxQnGaxTOTxO6GxinlY7q/f5 bz1uVGEg3Bam1nSYYYqSjbUd3QuSovs5j8XjtnAeXHKjyfb2gbJHrph13+JJTq+wq6Jx+GIzonX/ 3nti9rgEbBEkgsvjdjggR4xCbB5BKuNZFuVoZLwgJfn5ZHSxIChFzFtZpRuPl6cHh8AsHB5KBA+y 282jPoCPOsHCkUFQTLbdPjv9uqkpvQ7nkx8ebWzrSYkIt7tsGVHGJ5bP2lXcuO5oCQro+O4jvi3S XyyZ8esrMv9884IYg9IliEyc9w87cm+dk6yE1DNtFAGKAEXggiGAGjd43qIOFlazYCIgWAMPW7zH PwToI4RSpWzt6r31Xx+u+OvmhzYdeGZH9l925qzZnfeH7Tlrtp9csyt3za6Tz+/I+fWmQzf8bfP1 T73diLg/NQwqX3UbPDgRIQmOVMoJ1THCnzfuWfj8unvX7nlm6/E1u/P/gKH25K/Znr1me94fduX8 cVfe0x8cv+eNXQueWff2zhNMmGFoViBT1MTB9IZniDfETRmYBmMQQ/nrbh9ctWBy+oga4YE5A577 MkVBU9egw721sDbJYFiUQcq+NPcPNvcMzk2ODter9lQ1upzuwgYUlHbfsSCjrMt0sr6ztLVDJZEt nTAuq75VKRHVdfVXtffdNDfNIB9aaxTEkl9tOvLUtZfEG7WlTQMyiRixMCjDPT8t8Uhlq0xgNmSX XzI+ZlxU8JHKpmWTk04196JYTk1377hwQ1JYyMuHTt42b6rMZ0SGaVWoKJ0UpveX20Z9GTfL7Cys cXj4HWX1UTptR99gZkrk4fI2u5uZGhfW1G+WyST9DrdRr0SJ0Zmx4TaPs8XE4UtT3zsIi6/XbCtq 62wdsE+LC2vrs0WjHM8YFX4N1E2i41AEKAL/Kwig1jIqJzd1jKi7jUsDvWHpByH+/sI3kClh+Y62 /vyatsMVzfvyqw8U1B8srT1QWn8wv/ZgYe3B8sb80oaWHgsKdJGD/b0wgr/AGx6VMAqJfcKC5BwW Z3l925HShgPF9QdP1R7Iqz9YXHOgouFgXu2BU3VHK+sqmjodoC4s+yEV4cxQECXxjeCPniQEzKbE GgNUd9uOuts+bvvgMLhtwhhwm0YukQni4yRGn31gyVSlL4AQV6FVKeONGtBJUoguu767y2x/6MoZ KDwdE6Sp7BgURMKKKUmJodowgyq3uqPTbr9mRuqkiDM1XLDKBSfm92eOE6NcjUQcqlPrldKmXvPM hLCYIFVBY69CJdw3fwpuJYqtpUQYvIIoyqhbkBJV0ABD3B1u0MSG6ELIIF/Q4oy6um5Lh8mCVdAr 0uOD9JqSzr4pMSFQpEHh2kNlLbC1l00ZNyEyqLS9M0itXTlj/N5TzR0WS5RelxCq0ysUUrEINdwG 7Z66voH5ydH/K3819DooAhSBbzoCTo/3vRM+boMmFkjIH1cPhyRyzuD98xfjhg0HllIjU9sXcgJ7 juRZg2YgLywj1UpR2hRdNPJP9YI5CCej33+I1TI8XmFoYVj0QowJHJXohS1YkEP1NFgKGAEHY50J r8QsIQ7K070wFHIAxL5oSf8M5QxnT40Nv3VO+vlD3DZoe/VQEWt38qpVz216/Ps3jZmeJByPQWrF cMEwn1uWxO/4W5+NQ5FPvXJoxc/OeeBHVPsKZJO9FgeW54JHZMj7txMpzBEYACizg1NiAU8i6bY4 gkg4CuFRn9Q+yRTEXcbxA04Osi8oYsp5PMO1Oj8PpcsrWB2c8TT59docIWplv80VpJah0hsGCoKR TvIZHCKRVCuXWJ0eq5OLQDl238zwBbByTi8v4nh3xOl62ed/w+gIFAGKAEXg7AgQPcm/vX/sFPQk 1UNGEknNlpGcMz+TEesNWdg+loKDkRTL9hI+w7oMnpL4iF1EJSsQvUClpPr2aM71WcXL87nRuU3t s1f/1xdLwrgD5un8ohlF6lTDxIb9ON8wseFjsFo+TGz4qJJLhomN7NUqP09s/kFGNtwRg1ruT8gI 0yJ0fyhnwO8ORJlo//EGhVyjlINKz0JsOEwmZoeJDR9BbHgFsZFXjdxPbGh6pRLEhjcahWSI2Hwz w2R0SgWOp8R2Pl9Q2pciQBH4ugigsrEES1kIpCAE5lvDgkWFjGxYUXg8IjDeH7uBjcgtI0nTPvML lbJ9ESJnqnUHpBcMxNGey8GwKk/AcgBgEvpzt5VyCKbQRhGgCFAEKALfagQQm+jyuHyaW6frbuPh jjUzVN+G/QQRENCbP8wEFEjSuhmiNumnOiTwovlrYY/sBbfhBeglOGUBywHgfJpbyN12OHDttFEE KAIUAYrAtxqBM7nb/lUul4+34L9SKkScOzg0TARbjYQ4wmMn9qV120lQPnxNUOoi6WtYbxvRC0pa YD5IJ2ORyN8Ldt5Y9MIEGD5QWda4WqwoQiIaM1bCJB2LVtk5uCm3eltJ3TvHKrMbPpXoZ3MJdT02 x1mlF5Ez0WFzmuAIHtE8Xh7b/RvsLne/jesZcJGw10+3TgfXZMLC6tCRgiD0OFwNJnIoDjQ7Xd0O F+qvm5zYcEamBGH9/Xau1+myOhG/SdLgkLHRMmButTpIsgZZwBNMdkfbgGV4DmOBGx2TIkARoAic AwK+3G0nI/ISywySHP5Ua9CSzRERGfz3m+cnhgQRxyM8lk43Y7ER7X9oP+JZhyBvWHLogkxq8BzW 5/CoxAFwZvpTrYnsMhIAPIQOETwyaCHj+HvhgKFeThJMYR7RC9dAtLXcRBvF3wvPan8vWIrDMyRR l6JAWVgC4wAVix97ZvXzm/f9YNGUtIjgc4Dy7F26zdaD5W1vHC4OM+pDg6Tjgg3Dxxe39a7NKkiL CEI29BcOggXNP+zI33iiKKuibXpyvBaxN772jz0Fpe2+wEWR6JqXNufU9ZS39QVr5RF6zfA45W39 T3x05HB5bV2PZU5yFHzQW4vrX9iRl1XdHIxoxmDtC3sLP86rO1rf+sqB4nC1MjkiyN+33eFY/dHx /Iau9cdLK9oG5qfE5rf0rD9U/EFeRWOPeW5KdJ/d+caJ0tcOFNf2WifHhijHdKEy4PeDDkgRoAj8 TyPAeb3v51Y3QuRd7ltygpmFgA5ieykgUn+iormt34w1sPBgfTgCHYw6nYjR4FUqsvisA6nARgcH GY3qUJ0mCKF5MpkValhiiZgV9GqVXq0MD9FGRoSGaJQSVrBayDIetJkNKnmQVmM0kF4GvVonl8Jq 4WE4CXgRh6sVocGKUIM+SKPRKcRWuxupx0NZBERz6/QMBXlSjOEHczLO//60DXJvHDolfuzRp57f mrVyzsSMqMBzW6hWNT7a0G6x/X7ZjAnhwTB8sqpbId4RpVea7K7y9u4ZceF+bsMuiO6LRCLl6QjJ rcW1p2ra3rh7uVcie/VQ/tWTSQXY6u7BVw+cNCqV81KjwW3rDhZt/tl1i9JjRhIbDrvlpQ//dfvl d8ydtLuivs/mFouE7YW1z69csGr2hOggLUJL5qVEXTUlYWJEcKfZmpkcGQEZGF/TSaXLJyd9b0Kc ye5B6tv0BNxE0dVTUlbOHH/Huo9vWzjJKFfOGxe9KjNtY3ZFnFGD0c7/TtARKAIUAYpAQBCAt+md rNLmThNJr8ZjlVRx85L3DmeIUfPbKy8pa+zgnK5rZ46/anpqWrghOTrkj9fPnzQ+esuBEhEv+sHC CTfNnRhjUMcFGyclRfxgzrQu62Brc++4SOPjKy9bkhY3NdY4NSJ4bkL0nd+bcbKxs6+9JypI+9iq Sy9Li0kI0k6IDJ2ZGHHdnAytUlVUA21lFrJQ9yyZnhRqjDEaMsJDr5uXGmEIKiivJ15Q4of0Bc2T GcL5aZ0QG35LYHIABl89VIwTMAyHUt8BAfYLBnG4ebeHh4AW9r15smJHUf3ekvqdpU1yZIGJpOzp gEaIFL9xpLSwpXd4CN7J8D4pMKNcVtbSjjfwFubUdk6PjY4I1vs1QeBK3VhYuSG3qsdiH+7Y7eTE MmmcjrDOgtSklh5zTUdvuF53sqFzU245bPXhI7Nr24JVikkxZzLn/LvqekyNPb0Lx0fivQEF91jm YFXL1NhILebDMv02x1vZ5UkRxoQQw1ihRselCFAEKALngACK3CDKH88pv5IIAkMQ2e/LvEacf0ZC hFKu4FyejScqHn1rz7ObjsHAsrj5t6HNz3smRBtunT+lsq13Q1bprtLa1w8UuAT+sRsug3aVQa6a Fh9W1NDxyIajj7x38IF/b3FwnjsWTmTsHo1ckRxqzClvXLP5+F8/Ob763cOv7MlZNWc8HJsKiWjV 3Axeym7KrdxZUvVW7qnjZV1PXjdPq9OQqBY/vfln6GtfqmH/tXEgcfJDnDYmFW6GJkTG9sfiP7Pp UEyI3uly7Str8V/W8JzFLHtTZnJaxBm2WDIpQSRyv7jvZFZ9cxAWMxnmYEUjFkTnpMbZOZcfjWsz M7RiWWlbz9sniE6/vyERTQcvs68p4UD2egfc/MmG9n6b/VSr6e87h7T5uwat5W2mqfER/tLjZ5rA FLf0aVWyxFC9f+Oeypa3jhaj3JHvhwBjcbqrugYHOLdf5Zk2igBFgCLwTUHAFxVAJkOqWnsZ8nNc RFa2kFktSBFcQDQWeZ4bNCul4jW3Xf69ifF3vLR134lSOCohqaGUKVOiQn64cMrtcyb+ZGlm96Al v74bGcZilq/pGjhW1eC12wU4vjg+q645GDW7BbgrmdYecwWU5XmvlyfBmdnVbYNWm1Qk0kilSoUi WKm6MTP99rnTHlg8My5Eu6OkXuVXmBo5Q6LW7zM0A9R8DlmMJhf7tIvHppH0aaJlhTMoRdJ5KXGX jY/9yWWTOYRw8EM6yTgxlsQykyKj/enPvgapkd8tuyQ9KmTJxOQwJVlLK2zo+eRU7TvHimB0Q5oL W359xdSrJietmpnW3DvQT+qmkxahVvdZSWlTtD6HRyoWq8QiENX1M9Oeum7u5pyhMm913WaO9c5N /axuSL/VkV3dcmk6cYGi5Ta27z5V+5urLpkUHerfEmvUPXZVJqr0HK5qRWjJ2KBGR6UIUAQoAueA AHSKySPX14jko08lC2lt5BGPD2A6kFBcTNhzty7tHbDe9df3G8rq/OLFkDjusVn251a+uTV73bbD /91y/L3s0rKWbpAQj6wCAX42sJwvzFJJHG68XGDEPE8UmMVihJ9YOGbQzJjtYlakUcncgtsjCFDJ OFbZtHZ7zrqPj6/7OHv93uysqmabg6hHDk1veIZE4DlQpdb8dbchteJxk2y/MWq82GGD7eQlNo5S MjUmaElGItjb6+IEr0cqYRv7Lf0AhWFQKc2M6gwjWnywfkl6YlZZS2w44bb7Fk95dMWcmSkRc1Mi E/xGlY9ZOqwcFCaDTucx6BUis5NF0Ad2najtjA1BBQAdIlPcXg/E/lHqHNuxrHqwoi01MmiEbPLQ iQdcnFytmne67NDGo5W3LZycfnoxEoJbsEFVUjEv8tq8nE+KmTaKAEWAIvDNQIDkbkN5hCWZ2kgD gMUGYiPv4WZyG5Qq1isYDfq37l8xPzUa0d4rF8741R1X3LAkg5GzVV19iDS5aX76ghnjMqelz5ge 8+KtyxKjtAwrkYskGgUp6U1YkAiaCDoUKmMhRo+4SUdUkObBK+bevjzztuXzV10xY8Mvr23tQ+wl D5GU/Mb2KyYlXzM7bc701IkTYp68+XvXTkuzEocktKl82eL+GRIpL19geiCav+62+LHfPfX8+ydu mJeRER34WBLME4tktQPmOUlRKpk0WKP6887c7Jp2nUYRrFOignZmYtRrh8rsEnZCqP5v2wuRcTEu bChkEX3fOFH+0sEiKc89fcOl+KhTQhNEYXF71ChvHRcmEYn+ceDU2zlF7b3W++ZPhILJMCzzJ0Y9 ueHI7oqmlDDNnfMmxQZrW3ttbxwt3Zxf/fBVs5NCdb0Wx6HKhp8vnYFBRoKJXzyHyjtTQnXjwoYc kqjyUN3Ul93UdqS4dda4GIeHe/lI8SsHi4L1ypump2pPyzcH4o7QMSgCFAGKwHkhgJymt7NKWrpN PrFHFAQQ+7T2EdOPOH0xXF/1PSb8Lm8csBU19jldFkEkQY6Vzemt7uriXCwezr0WZ7ABQQZimVa+ 7Vjl+8eLvWJ2gBVKWzrqOk1OlEUjCeCKeou1rLWzvc8cGmLIiIs4VN9idjslrEStkRwoqV9/pNSF 0H+JtKSxs6bfFKRXgHP1Wump1r6X9ubaHXZCtyRJHDalb4bgNo7LiA37fmBiSfrXHiph7byguv7x LU/ffu2UlPMCdXSdYWjB9Tv6PIY+hx3u2i8bGy7BAY4LQorGF7UBDpEgZ3ZYOI7ITBKb/Gs32IAk DdDXD7GyuIQvTlz42gPTDhQBigBFIGAIIGf3+n98dPBkNWK+SYUvEnbOktwylCcluiQektmGH/T+ jOZhtxMIBmnaaMj15uAahNkD7X+BlAzFMfjJT6RJEJ8CfUhf3RyMAFpCDpxYOjk85OGb5v1nW042 oh9J4gGelUpGzDFyBTkYvXCu4ROR/G+kHeCRDulkeCZPz9BmY7zKKy+J3/XgTeePRW5T39zVa325 2yqlE8pbF6QReeivc6KzEBu5NSz7ZcSGvSOJDR9hY50bsaEvbvswmeHuUWL7OveQHksRoAhcIARO 5277lP5hGHl4X91tFYM0NX/Ktn/9CUGTkCOB8QTOA7EhSQB2HZFORvEUosJIDtNqhpS6QGz4SAb0 kmRwyHGB9hDfADr0cO22wfeyyluQ5a3zFR3FgCA2xPRD+gujkSe+lFGdPhf8pejlcAzV3R6eISYj WBUBW2/z192Ws1DSlMvowtEF+vLR01AEKAIUgTFCQCyRGBFhD28kaAYGFmgJDklYLghHgJ1EFJN9 phXcV4g19+tMgsnAW6SSM9bAsJzm7+WjQOz6fC+Si+ZjL/RSKHptzp0FUMswE+L098Kw4D//uUjF li8/1/AMwWq8oAWbBqKdrrvtxsllAVvFC8TM6BgUAYoARYAicA4IoFxarAEeP58gMsI0QFSkchvS en11t7G25q9r46+gDQaCFYVXHDxcC/vr9gIpkgoDiHw8j3ORyuDu1NAzwRbncO3DXfx1tyGRiZIz Y5i7fc5THHRyZpt/nYs2igBFgCJAEfhqBBRSySXjExnU3iLpSb4MbkTtI9GNlLc+XZ7tTNK0L/gA 1pW/xOhQDvW59fJlMZ/buVDzzOFFrdQFk2K++gpHdYTYp+tMEDiTZzaqjhfkoN2lTQdrIK9MnaUX BG56EooAReB/AoHMuPDk2HBiq4G0EIII3oLFBrMM3kWwF2wsYiT507qRhQ0lZV+NbKzMwZIjhbkR CXlhe2Eh0CnEx4VfmvTZbONzvSFYGPRzmxvFwL9xbUZc2JS4z6phBXCWPll/2igCFAGKwP8UAjEh mvmpsUPK/SQAxPekIwndvuiSM54wxFv4Fbn8G/0Z39joP/JC9mIYh+XhKzMDdxvI5MWPPfXU8xsP 3roYdQCMgRt6aKR9VS2QH8lv7DbZuWiD5qUjFSaHU6VQnGru7LPZLS7vidr2uq6BlIigN7KKtBIF 0qsPVzSnRpKZFHf0CQIfqVM/8Obhg9UNW0saY3XqYJ3q9azSF3bn67W6xGDNwcr2t44WbSlscri9 EyKD0HdLcdXLB4pYqRQyoChP8+qRitcP5aukssTT+WoYuY/jf/n2riNlnXqVPMaoWX+i7B978hAu Oikq2OJintxyZE9JU2lH95Ha9l2lzROjQjSI86GNIkARoAh8GxCQS8RYYdtW2ODhvIxCSvyECNZH RAnxPUKZBBabb+NwWjcuCiYdiezHAajWjdRn6PRfqF4IP3Fw8hD9x7+4IVDotpudrx06hZR1JEWL TLZAlYX71PSa+war2vu2FNTvLK5r6TXXNHR63WxxS+vOkrqcus6C2lYHLxyra0Sfl3YXn2xoqe42 t5jM/iFO1XXkljfjzZPXzbpsUnJeQxPkibfm1Tis3IPLL3l6y2Hs2llaVdPdd/v8tKO1TYNOx66i OruTf3TF/Gc2HcDeY5XdFW3dP14ydUthdWHjmepxv1q/Y8GEcb+/bta0pPBtxXV9Zvufb1y48ViZ yeo2WxzHqtpumTEhp7Jtaky4x+Eoae0PFOJ0HIoARYAicAEQuHJSys1zJ5HqaHD3+UMW/YH7IDZE LRIhR7gf4ZzER59bEmSGjGxSRG1E3e0L0AtZdAjX77P++cbFAYTF7XSLBEaEBHSpTD+I5IYxaOND DW0Wp0orqOSS/cXti2fFZSYH9dk5o0zBu4XWfm5eQkSITn2sqS0zOabVYms3mTNihmQbYUTzPsnj ML3qrQP5f73pCo1Mktvac7yhd/vxSrUv2FSpVC6fkgqLUCGSmm0ejUExe1x8agRURaJqBu0Hqmpq 2/q35tU5iL7LmZRtqUpz2yXjQzQKuYit6bCkhhrC9ZpFE6M/PFku14umRxvjItXJMUGZcRGhQSqR aGzKto4B2nRIigBFgCIABFQy8R9XLVo0P4PpMpMFNhhhJIONI5VIhypowzhDWpuCpHWjyhiW2URS X+j/iLrbCDkhxXHGoBep8e07F+zIrq67b7nsF1dOC+CN6+I4qRz5bQyTGmc4UdIWwKGHh5qSGNVm GpgdnSCTSrZUVq2YME7OSvPru8JD9Danq2XApFaIp0ZF/nNH/m2zx7tcfF5j+7SkqKHuyJdmHXh/ yyufXDktaUFypM3JoYbez5dOfOLGuTt/RQxYq82G9G2ILoN/3Iju4VgF0vWIb9mqRAKiTHzvorTn rp/32q2XT4sJhYiJX9rYbrcNz5BlUKSWdOnutSnVagF71AqvF3n5yD/kkPvh5b9WrvlYoEjHpAhQ BCgCXw+BCL38wEM3PXDHUsY8QNbebA6SduZE0rTPVhuZ1o062qSCtutTtbBh52HtDaq8hN4+l2qN ZPDz6YW0bkicICWO8f7nqVtfu3PZ17u2rzr6YH5jmtFIuG16dOSp7p6vOv5c9mskIq+Tjw/VRqmD OrqtIBHI/3ea7BFKmU6pUIvVKpl8TnrsgYKmS8ZHIWyTF0kHbM6/7MlFARo5L9ZLNGYH39RnWT4x rarLppTIJ0YHQ30/v7EH9bIxIa1Y6wanMV6ZCFrMLIovFFT3HqhsHXAwMQbVpWmJW0415TWYNkFG ze54L7fqT/tz0MugVj7/cV5tv7l1wDopMaKh25LT3FnRNbhyerzJ7ZGSEuxeidfndRazHmq3ncud p30oAhSBi4/AizctfOf3d4YrZYS9LDAVfKJZsORgM5E1Nl9aNzHp4LeUD6VaI8AQASYw6ZCChew3 EtkvJd3PvxeCFxGxSVTsSQDnlPTYw0/f/ZP5gbTY/IifaG5OiQ8Rr1692up2bjxQfsWM5Cj9mRIz gbotKo08NUxnVKvSEkLGhxlgZoUoFRNjQ8NQpDUmOFqvQh0CvU49MyHMYNSmBmsNKpmL45PDjBqd NCbMKIiZ7sHBwubOorbOEJ3q0tTYlkHbrqLqWXERyRFBvJjJiA4J0SrVcnVKuOFkTUu9ydRmGvzz LYsQABITpPYy3h2FtRkxwVOiQuwer4KRpEUal4xP2F9dn1/XnhIRPCchomvQ/HFB7T2XzYSGMu8R gvRqFMRRq6RJQahFKkoJN+pxP2ijCFAEKALfQgQmRQfftWhy7SCqXjK8y84hYBKx/ojydyPWH7qR UM9yMV5wHjK4kSfgk+kiq3Qc44WXEit2EH7E8TD1zq8XySXnJWIBK0hpUaEPLJ/z8h3LUk/XyAwg ribO++C6XfcvnYnMNqG2Z2DKU28/tWLmI1fNCeA5LvxQv99yZEVG0ryUQCUAXvgroGekCFAEKAJj gkBNjym7obeipat90AqigRdSIpK4vW6ZWObi3VIWviovbA+s7Xh53y7BLRPJXF63VCzBFpLRjQUg +LTOqZeIlUil3rSwsJQw3YK0pFDNWAWfr8sqveuFzQ0vP0S4DWURbn91R7NpYM8jt2oRM/qtbW9l l82MjUyPDnwyw7cWEjpxigBFgCLwHUJgyfPvWThX7jO3kfU2hUxy9+Kp1R3964+WfasxWDktNTXC 8K2+BDp5igBFgCJAETg3BDZmlx8ra37ixsvQfSgyfkFqzPLpKf/cm1PT/S1O51LLEf1xLuXZzg1H 2osiQBGgCFAEviEI9Frsf92StXR6yvfSiXbXEBMoJOL7Fk23DLrePHCKyhN/Q24VnQZFgCJAEaAI jBKB57edKG/vf/SaTKWvjs8ZK2decuTvbpjzwpGigpZvsek2ShToYRQBigBFgCLwP4PArpLmf+7M eeyWS+emDgkuf8qD99AVM5emR899dn2TmSRN00YRoAhQBCgCFIFvOAINXf33vfjBylkTH142e3iq n12devXOayeFG9MfeWFfdec3/Hro9CgCFAGKAEXgO47AyfreBX/dlJIUuf6nK0ZmIn+W20LUspPP 3rF8etrSX7+4evOxfkiQ0UYRoAhQBCgCFIFvGAJWzvP89uzMR/41JTzoowdv1KDo+IhG8tu+cMJ/ 3Z33u7X7p2ZE/uMHSzMTIuRiWiP0G3Zj6XQoAhQBisB3EgFopxyuaX1u0+FDpQ1Prlz05M3zSPTI p9uXchsO+6S06U9bj6H62vXTk6+ZPn52amRMkPY7iSS9aIoARYAiQBG4+Ah0Wux5DR1bsyveya2Z Gq57ctX3rpwc/4XTOhu3oYPF6V5/tGhDVml5tyVep5oyLnparCE5NjJMrlAoJR6PRyxCoRxi+4lE Iq/HI5FJ3ZxbKvPvkvh28SKR2OvxSmQSN+eSymS0F0WDfjfoXwp9btDn4WjYQSqTujh3l9lZ2dZT 0dZb2Nxd3d0/MVx/95Lp189KN6q+VEjrK7jNz4fQyy9s7Dla3ZTT0NljcXAOHjnSXqmb9/AsL2XI 4B7WzfIiiUjK826PiJfwEhGLQjEelCeHUBnP8x6RR8yLJSIx7UXRoN8N+pdCnxv0eThadvBC09kj 0cnFWrV0dmLM3KSIzNTomCDN2a3IUXGbfwivIPTbnLDknE6XVRAkDO9mWGKasSxexLzgFolkjIDg ExkPjWkWB8Ceg0UnZgU32ShwIjGq0dFeFA363aB/KfS5QZ+Ho2cHrUislktUcmmQWgm7aTS+0a/B baMZjh5DEaAIUAQoAhSBi44AVV+86LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+ C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQ BCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG676LeAToAiQBGgCFAE AowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiKAEWAIkARuOgIUG67 6LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoARSDACFBuCzCgdDiK AEWAIkARuOgIUG676LeAToAiQBGgCFAEAowA5bYAA0qHowhQBCgCFIGLjgDltot+C+gEKAIUAYoA RSDACPw/jRlMVUNEDuMAAAAASUVORK5CYII= --Boundary_(ID_zp2Ti81A6JDWOQWbYQGxUw)-- From paul.hoffman@vpnc.org Fri Jun 28 08:20:21 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7AB21F9BA3 for ; Fri, 28 Jun 2013 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGxu+y853gaf for ; Fri, 28 Jun 2013 08:20:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7987D21F9B87 for ; Fri, 28 Jun 2013 08:20:20 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5SFKHGA063572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Jun 2013 08:20:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <763539E260C37C46A0D6B340B5434C3B076D46C2@AEX06.ejsarea.net> Date: Fri, 28 Jun 2013 08:20:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> <51CC4DB2.70200@bbn.com> <763539E260C37C46A0D6B340B5434C3B076D46C2@AEX06.ejsarea.net> To: i-barreira@izenpe.net X-Mailer: Apple Mail (2.1508) Cc: wpkops@ietf.org Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 15:20:21 -0000 On Jun 28, 2013, at 2:13 AM, i-barreira@izenpe.net wrote: > Ok, I=B4m fine, no problem if this is only for SSL certs. Just to be clear: it's not just "SSL certs", it is SSL/TLS certs for the = web. The charter for this WG can be found at = > But maybe sometime in the near future there=B4s a need to deal with a = complete trust model in the web. Let's see if we can even deal with this limited one first. --Paul Hoffman= From joncallas@me.com Fri Jun 28 17:09:41 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BF321F9D5C for ; Fri, 28 Jun 2013 17:09: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+4UlWgwF-Fo for ; Fri, 28 Jun 2013 17:09:36 -0700 (PDT) Received: from st11p01mm-asmtp005.mac.com (st11p01mm-asmtpout005.mac.com [17.172.204.240]) by ietfa.amsl.com (Postfix) with ESMTP id 55A1121F9CE6 for ; Fri, 28 Jun 2013 17:09:36 -0700 (PDT) Received: from [172.19.131.158] (unknown [12.130.123.85]) by st11p01mm-asmtp005.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MP4002QOOEU8A20@st11p01mm-asmtp005.mac.com> for wpkops@ietf.org; Sat, 29 Jun 2013 00:09:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-06-28_09:2013-06-28, 2013-06-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1306280250 Content-type: text/plain; charset=iso-8859-1 MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jon Callas In-reply-to: Date: Fri, 28 Jun 2013 17:08:49 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> <51CC4DB2.70200@bbn.com> <763539E260C37C46A0D6B340B5434C3B076D46C2@AEX06.ejsarea.net> To: wpkops@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 00:09:41 -0000 On Jun 28, 2013, at 8:20 AM, Paul Hoffman wrote: > Just to be clear: it's not just "SSL certs", it is SSL/TLS certs for = the web. The charter for this WG can be found at = >=20 >> But maybe sometime in the near future there=B4s a need to deal with a = complete trust model in the web. >=20 > Let's see if we can even deal with this limited one first. I almost think that what I'm going to say goes without saying. However, = many things that go without saying ought to be said once or twice = anyway. I'm willing to buy into this if my software that does (e.g.) REST = services over SSL are "Web" and my client is a "Browser" even if it's = not going to render HTML, but (e.g.) parse some JSON. When I do that, = I'm buying into the Web PKI, even though I'm not doing WWW in the way = that a True Browser like Chrome/IE/Firefox/Safari might. Jon From ynir@checkpoint.com Sat Jun 29 00:49:11 2013 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E936721F9D6A for ; Sat, 29 Jun 2013 00:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5PVqX1bEozP for ; Sat, 29 Jun 2013 00:49:07 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4F63721F9BAD for ; Sat, 29 Jun 2013 00:49:01 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5T7mwbr014775; Sat, 29 Jun 2013 10:48:58 +0300 X-CheckPoint: {51CE916A-5-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Sat, 29 Jun 2013 10:48:57 +0300 From: Yoav Nir To: Jon Callas Thread-Topic: [wpkops] Silence is deafening - Trust Model Paper Thread-Index: Ac5w+ZSoQsntgfnhSwGtPfDMuxnBDwAG044AAAa7noAAA8QbgAAaeCeAACW2UAAAAJM6AAAqXrSAAARjsgAABuY8gAAEeI8AACcLswAADM9zAAASdU6AABASEAA= Date: Sat, 29 Jun 2013 07:48:57 +0000 Message-ID: <2A7008C6-EF69-499D-BFFE-24EFB67844F0@checkpoint.com> References: <65DA4BEA501AFC409DF274CC71ED01A57C69DCE7@SOTTEXCH10.corp.ad.entrust.com> <452C99D20750E74083DBA441FF9323857BFCBB43@SOTTEXCH10.corp.ad.entrust.com> <1E15EF86-207B-4012-9B27-F7357D2AE068@vpnc.org> <763539E260C37C46A0D6B340B5434C3B076D42BF@AEX06.ejsarea.net> <51CAC798.60005@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D43F8@AEX06.ejsarea.net> <51CC0164.2050505@cs.tcd.ie> <763539E260C37C46A0D6B340B5434C3B076D4589@AEX06.ejsarea.net> <51CC4DB2.70200@bbn.com> <763539E260C37C46A0D6B340B5434C3B076D46C2@AEX06.ejsarea.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.118] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 119555a84bfe8114ef312a319169689eec26f4e65e Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [wpkops] Silence is deafening - Trust Model Paper X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 07:49:12 -0000 On Jun 29, 2013, at 3:08 AM, Jon Callas wrote: > On Jun 28, 2013, at 8:20 AM, Paul Hoffman wrote: >=20 >> Just to be clear: it's not just "SSL certs", it is SSL/TLS certs for the= web. The charter for this WG can be found at >>=20 >>> But maybe sometime in the near future there=B4s a need to deal with a c= omplete trust model in the web. >>=20 >> Let's see if we can even deal with this limited one first. >=20 >=20 > I almost think that what I'm going to say goes without saying. However, m= any things that go without saying ought to be said once or twice anyway. >=20 > I'm willing to buy into this if my software that does (e.g.) REST service= s over SSL are "Web" and my client is a "Browser" even if it's not going to= render HTML, but (e.g.) parse some JSON. When I do that, I'm buying into t= he Web PKI, even though I'm not doing WWW in the way that a True Browser li= ke Chrome/IE/Firefox/Safari might. I don't think this goes without saying. Your client is not a browser, so it= 's not part of the charter. It may, however, be along for the ride. Some of web services use their own single-purpose CA, and even if they use = a public CA, some of the clients have hard-coded in them the chain they exp= ect to see. This is not like the Web PKI, where you have many root CAs, all= of which are equally trusted to sign certificates for any server on the we= b. If your client is like that, then it's more secure than the web PKI, but= it's not part of the web PKI. If, OTOH, your client trusts the server base= d on the operating system's list of trusted CAs, this makes your client clo= ser to the Web PKI. But even if your client trusts the big list, and does a DNS lookup, there a= re still a whole bunch of vulnerabilities that do not apply to it. It's pro= bably impossible to downgrade it to HTTP. It's impossible to confuse it wit= h look-alike domain names. It's impossible to get it to follow a link into = an insecure site. So I think the security properties of your web service ar= e different from those of the web, although some of what could be discussed= here might apply. Yoav