From nobody Wed Jun 4 14:38:13 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FAF1A032B for ; Wed, 4 Jun 2014 14:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pwCxtoSwoym for ; Wed, 4 Jun 2014 14:38:09 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF961A0309 for ; Wed, 4 Jun 2014 14:38:09 -0700 (PDT) Received: from [192.168.1.119] (host86-131-197-101.range86-131.btcentralplus.com [86.131.197.101]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 2E488F244C; Wed, 4 Jun 2014 14:38:00 -0700 (PDT) Message-ID: <538F795F.3020008@mozilla.org> Date: Wed, 04 Jun 2014 20:54:07 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0a2 MIME-Version: 1.0 To: ben@digicert.com, wpkops@ietf.org References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> In-Reply-To: <059501cf79f0$69ba9060$3d2fb120$@digicert.com> X-Enigmail-Version: 1.7a1pre OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/nHhAWPSiqL64Nf0Q74rmvghpUSY Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 21:38:11 -0000 Hi Ben, On 27/05/14 22:12, Ben Wilson wrote: > Here is another draft with suggested changes from Santosh accepted, and > the addition of “Security Considerations” subsections, based on our > discussions of May 13^th . Sorry if I'm missing context here, but the intro to the document suggests that it's documentation of observed browser behaviour (i.e. a record of reality), but then as early as section 1.4 it starts by saying browsers "should" do X or Y. E.g.: "A browser should only use its trust anchor store to determine the trust anchor for a Server’s certification path." Taking this particular statement as an example: what happens if the browser wants to use the OS store? Or both its own and the OSes? Or a remote store with auto-download such as Windows uses? To take another example from 1.4: "Specifically, the browser should be able to use unsecure HTTP and unsecure LDAP method." I can confidently say that we have no plans to reintroduce LDAP fetching to Firefox, and the publication of an RFC would be unlikely (British understatement) to change that. (We are also pretty unlikely to do caIssuers chasing, but I am 0.1% less adamant about that.) As more constructive input: many of the behaviours you note are features of the underlying SSL implementation rather than the browser. This is, I believe, why Chrome and Safari on OS X don't do name constraints (they use the system SSL library) but Firefox does (which uses NSS). I agree it's difficult because the exact user experience _is_ defined by the individual browsers. But the document might be easier to understand and follow if you acknowledged the connection with the library being used. Gerv From nobody Thu Jun 5 06:37:38 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38F81A0163 for ; Thu, 5 Jun 2014 06:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlJe1n1ibxZm for ; Thu, 5 Jun 2014 06:37:36 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4EF1A0143 for ; Thu, 5 Jun 2014 06:37:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,981,1392181200"; d="scan'208";a="1188557" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP/TLS/AES128-SHA; 05 Jun 2014 09:37:30 -0400 Received: from SOTTEXCH11.corp.ad.entrust.com ([fe80::303b:8584:c6f4:be18]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 09:37:29 -0400 From: Tim Moses To: "ben@digicert.com" Thread-Topic: [wpkops] Preliminary Next Version of Browser Behavior Draft Thread-Index: Ac9uwg5tUjGh+edRQh2AER9r67oKVQLT+HEAAY+VWIAAHLZlEA== Date: Thu, 5 Jun 2014 13:37:27 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> In-Reply-To: <538F795F.3020008@mozilla.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/s4UpEITFT0vehBd_UM9nWv9YQUY Cc: "wpkops@ietf.org" , Gervase Markham Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:37:38 -0000 SGkgQmVuLiAgV2Ugd2FudCB0byBtb3ZlIHRoaXMgZG9jdW1lbnQgdG8gV0cgZHJhZnQgc3RhdHVz LiAgRG8geW91IHdhbnQgdG8gYWRkcmVzcyBHZXJ2J3MgY29tbWVudHMgYmVmb3JlIHdlIGhvbGQg YSBiYWxsb3Q/ICBJIHN1Z2dlc3Qgd2UgZG8gdGhhdC4NCg0KQWxsICB0aGUgYmVzdC4gIFRpbS4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHdwa29wcyBbbWFpbHRvOndwa29w cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2VydmFzZSBNYXJraGFtDQpTZW50OiBX ZWRuZXNkYXksIEp1bmUgMDQsIDIwMTQgMzo1NCBQTQ0KVG86IGJlbkBkaWdpY2VydC5jb207IHdw a29wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt3cGtvcHNdIFByZWxpbWluYXJ5IE5leHQgVmVy c2lvbiBvZiBCcm93c2VyIEJlaGF2aW9yIERyYWZ0DQoNCkhpIEJlbiwNCg0KT24gMjcvMDUvMTQg MjI6MTIsIEJlbiBXaWxzb24gd3JvdGU6DQo+IEhlcmUgaXMgYW5vdGhlciBkcmFmdCB3aXRoIHN1 Z2dlc3RlZCBjaGFuZ2VzIGZyb20gU2FudG9zaCBhY2NlcHRlZCwgDQo+IGFuZCB0aGUgYWRkaXRp b24gb2Yg4oCcU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnPigJ0gc3Vic2VjdGlvbnMsIGJhc2VkIG9u IA0KPiBvdXIgZGlzY3Vzc2lvbnMgb2YgTWF5IDEzXnRoIC4NCg0KU29ycnkgaWYgSSdtIG1pc3Np bmcgY29udGV4dCBoZXJlLCBidXQgdGhlIGludHJvIHRvIHRoZSBkb2N1bWVudCBzdWdnZXN0cyB0 aGF0IGl0J3MgZG9jdW1lbnRhdGlvbiBvZiBvYnNlcnZlZCBicm93c2VyIGJlaGF2aW91ciAoaS5l LiBhIHJlY29yZCBvZiByZWFsaXR5KSwgYnV0IHRoZW4gYXMgZWFybHkgYXMgc2VjdGlvbiAxLjQg aXQgc3RhcnRzIGJ5IHNheWluZyBicm93c2VycyAic2hvdWxkIiBkbyBYIG9yIFkuIEUuZy46DQoN CiJBIGJyb3dzZXIgc2hvdWxkIG9ubHkgdXNlIGl0cyB0cnVzdCBhbmNob3Igc3RvcmUgdG8gZGV0 ZXJtaW5lIHRoZSB0cnVzdCBhbmNob3IgZm9yIGEgU2VydmVy4oCZcyBjZXJ0aWZpY2F0aW9uIHBh dGguIg0KDQpUYWtpbmcgdGhpcyBwYXJ0aWN1bGFyIHN0YXRlbWVudCBhcyBhbiBleGFtcGxlOiB3 aGF0IGhhcHBlbnMgaWYgdGhlIGJyb3dzZXIgd2FudHMgdG8gdXNlIHRoZSBPUyBzdG9yZT8gT3Ig Ym90aCBpdHMgb3duIGFuZCB0aGUgT1Nlcz8gT3IgYSByZW1vdGUgc3RvcmUgd2l0aCBhdXRvLWRv d25sb2FkIHN1Y2ggYXMgV2luZG93cyB1c2VzPw0KDQpUbyB0YWtlIGFub3RoZXIgZXhhbXBsZSBm cm9tIDEuNDogIlNwZWNpZmljYWxseSwgdGhlIGJyb3dzZXIgc2hvdWxkIGJlIGFibGUgdG8gdXNl IHVuc2VjdXJlIEhUVFAgYW5kIHVuc2VjdXJlIExEQVAgbWV0aG9kLiIgSSBjYW4gY29uZmlkZW50 bHkgc2F5IHRoYXQgd2UgaGF2ZSBubyBwbGFucyB0byByZWludHJvZHVjZSBMREFQIGZldGNoaW5n IHRvIEZpcmVmb3gsIGFuZCB0aGUgcHVibGljYXRpb24gb2YgYW4gUkZDIHdvdWxkIGJlIHVubGlr ZWx5IChCcml0aXNoIHVuZGVyc3RhdGVtZW50KSB0byBjaGFuZ2UgdGhhdC4gKFdlIGFyZSBhbHNv IHByZXR0eSB1bmxpa2VseSB0byBkbyBjYUlzc3VlcnMgY2hhc2luZywgYnV0IEkgYW0gMC4xJSBs ZXNzIGFkYW1hbnQgYWJvdXQgdGhhdC4pDQoNCkFzIG1vcmUgY29uc3RydWN0aXZlIGlucHV0OiBt YW55IG9mIHRoZSBiZWhhdmlvdXJzIHlvdSBub3RlIGFyZSBmZWF0dXJlcyBvZiB0aGUgdW5kZXJs eWluZyBTU0wgaW1wbGVtZW50YXRpb24gcmF0aGVyIHRoYW4gdGhlIGJyb3dzZXIuIFRoaXMgaXMs IEkgYmVsaWV2ZSwgd2h5IENocm9tZSBhbmQgU2FmYXJpIG9uIE9TIFggZG9uJ3QgZG8gbmFtZSBj b25zdHJhaW50cyAodGhleSB1c2UgdGhlIHN5c3RlbSBTU0wgbGlicmFyeSkgYnV0IEZpcmVmb3gg ZG9lcyAod2hpY2ggdXNlcyBOU1MpLiBJIGFncmVlIGl0J3MgZGlmZmljdWx0IGJlY2F1c2UgdGhl IGV4YWN0IHVzZXIgZXhwZXJpZW5jZSBfaXNfIGRlZmluZWQgYnkgdGhlIGluZGl2aWR1YWwgYnJv d3NlcnMuIEJ1dCB0aGUgZG9jdW1lbnQgbWlnaHQgYmUgZWFzaWVyIHRvIHVuZGVyc3RhbmQgYW5k IGZvbGxvdyBpZiB5b3UgYWNrbm93bGVkZ2VkIHRoZSBjb25uZWN0aW9uIHdpdGggdGhlIGxpYnJh cnkgYmVpbmcgdXNlZC4NCg0KR2Vydg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kd3Brb3BzIG1haWxpbmcgbGlzdA0Kd3Brb3BzQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dwa29wcw0K From nobody Thu Jun 5 07:10:35 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CDD1A01A5 for ; Thu, 5 Jun 2014 07:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkTK2XiFB3DV for ; Thu, 5 Jun 2014 07:10:30 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2D91A01A7 for ; Thu, 5 Jun 2014 07:10:30 -0700 (PDT) Received: from [192.168.1.119] (host86-131-197-101.range86-131.btcentralplus.com [86.131.197.101]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C0BD7F234B; Thu, 5 Jun 2014 07:10:22 -0700 (PDT) Message-ID: <53907A4C.7070307@mozilla.org> Date: Thu, 05 Jun 2014 15:10:20 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0a2 MIME-Version: 1.0 To: Tim Moses , "ben@digicert.com" References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> X-Enigmail-Version: 1.7a1pre OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/FLsrS7DRNvLOUChHC8g0RkR_WwY Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:10:32 -0000 On 05/06/14 14:37, Tim Moses wrote: > Hi Ben. We want to move this document to WG draft status. Do you > want to address Gerv's comments before we hold a ballot? I suggest > we do that. Again, apologies for lack of knowledge of the process, but: the doc is full of "to be expanded", "we plan to..." etc. So there will be lots of further change. Is that what "Draft" means? My two examples were two of many; they were actually given to try and get clarity on the purpose and goals of the document. If that's written up somewhere, do point me to it. :-) Gerv From nobody Thu Jun 5 07:19:44 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8864F1A01EB for ; Thu, 5 Jun 2014 07:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wrq4qoVggMOy for ; Thu, 5 Jun 2014 07:19:41 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9F01A0205 for ; Thu, 5 Jun 2014 07:19:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,981,1392181200"; d="scan'208";a="1189182" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP/TLS/AES128-SHA; 05 Jun 2014 10:19:12 -0400 Received: from SOTTEXCH11.corp.ad.entrust.com ([fe80::303b:8584:c6f4:be18]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 10:19:11 -0400 From: Tim Moses To: Gervase Markham Thread-Topic: [wpkops] Preliminary Next Version of Browser Behavior Draft Thread-Index: Ac9uwg5tUjGh+edRQh2AER9r67oKVQLT+HEAAY+VWIAAHLZlEAAJkowAAAhODMA= Date: Thu, 5 Jun 2014 14:19:10 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62CE819E1A5@SOTTEXCH11.corp.ad.entrust.com> References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org> In-Reply-To: <53907A4C.7070307@mozilla.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/-vi1bAmY5GN497oYUTltmLKqTYQ Cc: "wpkops@ietf.org" , "ben@digicert.com" Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:19:43 -0000 R2VydjogIFlvdSBoYXZlIHRvIGxvb2sgZm9yIHRoYXQgaW4gdGhlIGNoYXJ0ZXIgLi4uDQoNCmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy93cGtvcHMvY2hhcnRlci8NCg0KVGhlIHNpZ25p ZmljYW5jZSBvZiBXRyBEcmFmdCBpcyB0aGF0IGl0IGlkZW50aWZpZXMgdGhlIHNpbmdsZSBkb2N1 bWVudCAob3Igc2VxdWVuY2Ugb2YgZG9jdW1lbnRzKSBvZiB0aGUgZGVjbGFyZWQgc2NvcGUgb24g d2hpY2ggdGhlIGdyb3VwIHdpbGwgZm9jdXMgaXRzIGVmZm9ydHMuICBJdCBpcyBub3QgZXhwZWN0 ZWQgdGhhdCB0aGUgZmlyc3QgV0cgRHJhZnQgd2lsbCBiZSBjb21wbGV0ZSBvciBpbnRlcm5hbGx5 IGNvbnNpc3RlbnQuDQoNCkl0IGlzIG9mdGVuIHN0YXRlZCB0aGF0IHRoZSBleHBlcnRzIGluIHRo ZSBjb21tdW5pdHkgd2lsbCBub3QgZW5nYWdlIHVudGlsIGEgZG9jdW1lbnQgYWNoaWV2ZXMgV0cg RHJhZnQgc3RhdHVzLiAgU28sIHdlIGFyZSBob3BpbmcgZm9yLCBhbmQgZXhwZWN0aW5nLCBhIG1v cmUgdmlnb3JvdXMgZGViYXRlIG9uY2UgdGhlIGRvY3VtZW50IGFkdmFuY2VzIHRvIFdHIERyYWZ0 IHN0YXR1cy4NCg0KQWxsIHRoZSBiZXN0LiAgVGltLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBHZXJ2YXNlIE1hcmtoYW0gW21haWx0bzpnZXJ2QG1vemlsbGEub3JnXSAN ClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA1LCAyMDE0IDEwOjEwIEFNDQpUbzogVGltIE1vc2VzOyBi ZW5AZGlnaWNlcnQuY29tDQpDYzogd3Brb3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3dwa29w c10gUHJlbGltaW5hcnkgTmV4dCBWZXJzaW9uIG9mIEJyb3dzZXIgQmVoYXZpb3IgRHJhZnQNCg0K T24gMDUvMDYvMTQgMTQ6MzcsIFRpbSBNb3NlcyB3cm90ZToNCj4gSGkgQmVuLiAgV2Ugd2FudCB0 byBtb3ZlIHRoaXMgZG9jdW1lbnQgdG8gV0cgZHJhZnQgc3RhdHVzLiAgRG8geW91IA0KPiB3YW50 IHRvIGFkZHJlc3MgR2VydidzIGNvbW1lbnRzIGJlZm9yZSB3ZSBob2xkIGEgYmFsbG90PyAgSSBz dWdnZXN0IHdlIA0KPiBkbyB0aGF0Lg0KDQpBZ2FpbiwgYXBvbG9naWVzIGZvciBsYWNrIG9mIGtu b3dsZWRnZSBvZiB0aGUgcHJvY2VzcywgYnV0OiB0aGUgZG9jIGlzIGZ1bGwgb2YgInRvIGJlIGV4 cGFuZGVkIiwgIndlIHBsYW4gdG8uLi4iIGV0Yy4gU28gdGhlcmUgd2lsbCBiZSBsb3RzIG9mIGZ1 cnRoZXIgY2hhbmdlLiBJcyB0aGF0IHdoYXQgIkRyYWZ0IiBtZWFucz8NCg0KTXkgdHdvIGV4YW1w bGVzIHdlcmUgdHdvIG9mIG1hbnk7IHRoZXkgd2VyZSBhY3R1YWxseSBnaXZlbiB0byB0cnkgYW5k IGdldCBjbGFyaXR5IG9uIHRoZSBwdXJwb3NlIGFuZCBnb2FscyBvZiB0aGUgZG9jdW1lbnQuIElm IHRoYXQncyB3cml0dGVuIHVwIHNvbWV3aGVyZSwgZG8gcG9pbnQgbWUgdG8gaXQuIDotKQ0KDQpH ZXJ2DQo= From nobody Thu Jun 5 07:23:05 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137D51A016E for ; Thu, 5 Jun 2014 07:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.953 X-Spam-Level: X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT10s0t6srI5 for ; Thu, 5 Jun 2014 07:22:57 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 784511A01CF for ; Thu, 5 Jun 2014 07:22:33 -0700 (PDT) Received: from BWILSONL1 (unknown [67.137.52.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 039327FA0DC; Thu, 5 Jun 2014 08:22:26 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1401978147; bh=3FfpppTQ2uHzF5FuI+tX2NalnPZ5WP8jjnLBZMeUrHM=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=UA4WxoZgNy/W7bShR53Y/uhsPjqjBjVVHCwDXB1hLeVdNWwEkvlKZOZvGcNlkKafW U/LAWM6RR9dEHUFI05toUiE2iGtbGKoRT6GhZwWPGcjWqVyt789uNVxK1kn+wlTt/7 mH4XGiOu2OeKTXcT7Pb+bv3L1Ep18mVJznU8p1+w= From: "Ben Wilson" To: "'Tim Moses'" , "'Gervase Markham'" References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819E1A5@SOTTEXCH11.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62CE819E1A5@SOTTEXCH11.corp.ad.entrust.com> Date: Thu, 5 Jun 2014 08:22:22 -0600 Message-ID: <013101cf80c9$91fdb9a0$b5f92ce0$@digicert.com> X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Thread-index: AQHAGq9YUAUY845vOYYDLXX689oZPAIbE3NYATl0SmABw3ilUgIjEPfBArB9/m+bMgEiUA== Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_012C_01CF8097.45DAADD0" Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/0UTBxRNl_GAeJvE0azG9g_4qi_Y Cc: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:23:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012C_01CF8097.45DAADD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks. I'll take a look and create another draft. -----Original Message----- From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses Sent: Thursday, June 5, 2014 8:19 AM To: Gervase Markham Cc: wpkops@ietf.org; ben@digicert.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Gerv: You have to look for that in the charter ... http://datatracker.ietf.org/wg/wpkops/charter/ The significance of WG Draft is that it identifies the single document (or sequence of documents) of the declared scope on which the group will focus its efforts. It is not expected that the first WG Draft will be complete or internally consistent. It is often stated that the experts in the community will not engage until a document achieves WG Draft status. So, we are hoping for, and expecting, a more vigorous debate once the document advances to WG Draft status. All the best. Tim. -----Original Message----- From: Gervase Markham [mailto:gerv@mozilla.org] Sent: Thursday, June 05, 2014 10:10 AM To: Tim Moses; ben@digicert.com Cc: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft On 05/06/14 14:37, Tim Moses wrote: > Hi Ben. We want to move this document to WG draft status. Do you > want to address Gerv's comments before we hold a ballot? I suggest we > do that. Again, apologies for lack of knowledge of the process, but: the doc is full of "to be expanded", "we plan to..." etc. So there will be lots of further change. Is that what "Draft" means? My two examples were two of many; they were actually given to try and get clarity on the purpose and goals of the document. If that's written up somewhere, do point me to it. :-) Gerv _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ------=_NextPart_000_012C_01CF8097.45DAADD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRRjCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggbBMIIFqaADAgECAhAHv9Jd b6GmlTp/jguOyky8MA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMTAeFw0xMzA2MDMwMDAwMDBaFw0xNjA4MzExMjAwMDBaMHQxCzAJBgNVBAYT AlVTMQ0wCwYDVQQIEwRVdGFoMQ0wCwYDVQQHEwRMZWhpMREwDwYDVQQKEwhEaWdpQ2VydDETMBEG A1UEAxMKQmVuIFdpbHNvbjEfMB0GCSqGSIb3DQEJARMQYmVuQGRpZ2ljZXJ0LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8EX23kpIJWkjmY6Sx23gtdJWUZ7R7xzitGNquNhRQs fVeKvt0/pvRdc+TSKtj58kQ0tQ1BISUuOjr5bB4TeICooUMryRzQ98Qla7SkKwREX6YtySqZl+vj c+JuW0X95Ax0aHjYe13pD+zLHmbGTumwNfxbNi2/j1EeO/tIWml1saD/nMLovWWuChPd0w4Cy4Ex v3Y6Bsl0OEIehbTAw1Mb2kBAioP/6cd70DVgBqrLz8C+kWaIfLpobTwD8/wwrGs0ANtNFx3Dxz8x sfMRHkE140Fkmhf8ogO1M/hne2OzQJUVARLYa15yIDlp5rcRDIFRfjTRXDaETUq3dPHeApcCAwEA AaOCA18wggNbMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSUK0wr DI2kT+SUkmzvXtMaNBtUIzAbBgNVHREEFDASgRBiZW5AZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0g BIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdp Y2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBu AHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABE AGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkA bgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBp AHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIA YQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEF BQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcw AoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAG2NW/zRakbPATZt2m3+Xq7P/YdUzO1R8 6vcG49KkiuNGbExefzzMJnDK67LOzHpuqIyZmbe1ssg8swdenzRsRPoOt9hY7XFwwo8JJxiElddu NPWERMBQWeIPDnfpry3ZC4bMrEPsCsVa0ClPrG2RgGpq5JkPIdgiWngnHyl3ZajiqYca7faWU8eq SDjsyHj6KSF0M9gXhuTjZ20aMA3DZ0exTE2XAYYJUXLSg49szMy28LRW6i0rLfAfx1uNXjGfzdnf gYFRdkdSXqRgdXgCHtSmbAOi077oIvyVeBb2W7P9o+G29sZ/x8bLYoE/K2uliJ8fBAswrsdcirv3 Jqo+fDCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoX DTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sM NP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0Pd Aug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtP QLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9 BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggr BgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIB tQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBl ACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQA dQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBl AHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEA cgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBh AGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAA aABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8w fQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYI KwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVk SURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcN K2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEA hGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOK ZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYC gNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dG OHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qd lWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCA74wggO6AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UE AxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAHv9Jdb6GmlTp/jguOyky8MAkGBSsOAwIaBQCg ggIdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwNTE0MjIy MVowIwYJKoZIhvcNAQkEMRYEFDOW4NCMCNmRUeDOmBDOb9/5Q8EDMIGFBgkrBgEEAYI3EAQxeDB2 MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44L jspMvDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3Vy ZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44LjspMvDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFl AwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIA gDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgB ZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQA++4xCZfzE C9BkG9VrzJFoDp/1TRIqqqGm6cDocBjowkEaEzWinlz9sD2AU0WfZGUEldZ7vk0OnZOcSq2Xb9Pj iabrIQEHI7knyeIawqoDgGc/NhgA4vBLdaSrUucHQ0dN6dUPV+4DCk7AjwiP2lmpEbSZoDhzjV8T Elo0Fsyaqqo4Woq3nwR6Wcx7yy/W6NQRM08Er8K5dN/jrZpSA08Dbm5DUfz2hNnZnaftwau9mODL Hb0+ZZhXLvuMC/M28nf495d2EuMSy+OSiBRCQgoVzQWGPG+o6amuevlzR0jDPZ47SSkMEhg2HAMV DSDqjDG7GNhm0vzI+ueHm94sF7owAAAAAAAA ------=_NextPart_000_012C_01CF8097.45DAADD0-- From nobody Thu Jun 5 07:55:23 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFB21A0241 for ; Thu, 5 Jun 2014 07:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 461lwvKFnMKv for ; Thu, 5 Jun 2014 07:55:17 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AA21A0179 for ; Thu, 5 Jun 2014 07:54:56 -0700 (PDT) Received: from [85.158.137.67:43521] by server-8.bemta-3.messagelabs.com id 22/AF-21547-8B480935; Thu, 05 Jun 2014 14:54:48 +0000 X-Env-Sender: rob.horne@trustis.com X-Msg-Ref: server-12.tower-139.messagelabs.com!1401980088!6062464!2 X-Originating-IP: [217.28.140.9] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28649 invoked from network); 5 Jun 2014 14:54:48 -0000 Received: from smtp.hs20.net (HELO outlook.hs20.net) (217.28.140.9) by server-12.tower-139.messagelabs.com with AES256-SHA encrypted SMTP; 5 Jun 2014 14:54:48 -0000 Received: from THHSTE15D1BE5.hs20.net (192.168.251.26) by THHSTE15D1BE1.hs20.net (192.168.251.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 5 Jun 2014 15:54:14 +0100 Received: from THHSTE15D1BE5.hs20.net ([fe80::4064:274f:d635:873e]) by THHSTE15D1BE5.hs20.net ([fe80::4064:274f:d635:873e%15]) with mapi id 15.00.0847.030; Thu, 5 Jun 2014 15:54:14 +0100 From: "Horne, Rob" To: "wpkops@ietf.org" Thread-Topic: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt Thread-Index: AQHPeyZFDyYFwnLMcUy7s1i6Lj94AJtipRxA Date: Thu, 5 Jun 2014 14:54:13 +0000 Message-ID: <8bb8a25e698a450988b79c058705f1cb@THHSTE15D1BE5.hs20.net> References: <20140529101033.15865.72439.idtracker@ietfa.amsl.com> In-Reply-To: <20140529101033.15865.72439.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.6.167.196] x-exclaimer-md-config: 266e7a57-cddd-49fd-bdea-19bca6d40303 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/e-NN-o2CiV-yvIS3GIQHNhcQ5lg Subject: Re: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:55:21 -0000 Hi, I've taken a look at this and have a few comments. Although the security issues are addressed in section 5, I think it could b= enefit from a little more detail and clarification in sections 2 and 3. 2.1 Root store provider Does the audit reporting and updating method described conform to any stand= ard? I've seen auditors follow their own procedures which do not match this= description. 3.2.1. One root CA cross-certifies another root CA Is there a defined and agreed way for older CAs to cross certify newer CAs = particularly if they're not owned by the same organisation? For example if = the criterion for cross certification is less than that required by the roo= t store for the original CA there could be some interesting issues. 3.2.2 r= efers to adherence to the root store policy so should that also be in 3.2.1= ? 3.2.5 to 3.2.7 I'd have expected more emphasis on technically constraining third party and= subscriber RAs and CAs. For one thing legal contracts may be subject to no= n-disclosure which could make it difficult to audit properly but if they're= not technically constrained that will be what's required. 5.3. Root CA compromise The last sentence is incomplete ;-) A further thought: although potentially contentious should the scope be exp= anded to include other applications which use https but are not, in the tra= ditional sense, web browsers? I'm thinking in particular of applications th= at utilise the protocol but don't have or use any form of trusted root stor= e. To my mind this is a much bigger security issue than is covered in the d= raft as it stands. Of course this gets us into a discussion of how synonymo= us "web" is with "http/s". Regards, Rob -----Original Message----- From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 29 May 2014 11:11 To: i-d-announce@ietf.org Cc: wpkops@ietf.org Subject: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web PKI OPS Working Group of the IETF. Title : Trust models of the Web PKI Authors : Inigo Barreira Bruce Morton Filename : draft-ietf-wpkops-trustmodel-02.txt Pages : 11 Date : 2014-05-29 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-wpkops-trustmodel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-wpkops-trustmodel-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-wpkops-trustmodel-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From nobody Fri Jun 6 01:29:13 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591C11A0409 for ; Fri, 6 Jun 2014 01:29:11 -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=[BAYES_20=-0.001, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQZyF7Ldni4m for ; Fri, 6 Jun 2014 01:29:07 -0700 (PDT) Received: from ektmail1iron2.euskaltel.es (ektmail1iron2.euskaltel.es [212.142.144.27]) by ietfa.amsl.com (Postfix) with ESMTP id D19E61A00EC for ; Fri, 6 Jun 2014 01:29:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAJAFl7kVPUNwh3/2dsb2JhbABZgkaBGVK6doFRAYZqUQGBHXWEAwEBAQQBAQEqAw0NCBwXBAIBCBEEAQELBhcBBgEmHwkIAgUSCAGIPQEDBbJ4mV8XjgcRAR8XFgsGgyWBFgSaFoFBkX+DPoF0 X-IPAS-Result: AqAJAFl7kVPUNwh3/2dsb2JhbABZgkaBGVK6doFRAYZqUQGBHXWEAwEBAQQBAQEqAw0NCBwXBAIBCBEEAQELBhcBBgEmHwkIAgUSCAGIPQEDBbJ4mV8XjgcRAR8XFgsGgyWBFgSaFoFBkX+DPoF0 X-IronPort-AV: E=Sophos;i="4.98,987,1392159600"; d="scan'208,217";a="173095466" Received: from ektmail2mta2.euskaltel.es (HELO correo.euskaltel.es) ([212.55.8.119]) by ektmail1iron2.euskaltel.es with ESMTP; 06 Jun 2014 10:13:19 +0200 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 <0N6Q004C3NK9G3L0@ektmail2mta2.euskaltel.es> for wpkops@ietf.org; Fri, 06 Jun 2014 10:28:57 +0200 (MEST) Received: from afe01.ejsarea.net (afe01 [10.200.192.14]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id s568SvBg011115; Fri, 06 Jun 2014 10:28:57 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe01.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 06 Jun 2014 10:28:56 +0200 Date: Fri, 06 Jun 2014 10:28:55 +0200 From: i-barreira@izenpe.net In-reply-to: <8bb8a25e698a450988b79c058705f1cb@THHSTE15D1BE5.hs20.net> To: rob.horne@trustis.com, wpkops@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B099397E8@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="Boundary_(ID_vxJHBkBrIwlM941J+7M1aQ)" Content-class: urn:content-classes:message Thread-topic: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt Thread-index: AQHPeyZFDyYFwnLMcUy7s1i6Lj94AJtipRxAgAEXKhA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20140529101033.15865.72439.idtracker@ietfa.amsl.com> <8bb8a25e698a450988b79c058705f1cb@THHSTE15D1BE5.hs20.net> X-OriginalArrivalTime: 06 Jun 2014 08:28:56.0479 (UTC) FILETIME=[5B8CAAF0:01CF8161] Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/UlvR1aGZ9lJaswp0YZrYjp0Zykg Subject: Re: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:29:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_vxJHBkBrIwlM941J+7M1aQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Rob, =20 In your email =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 =20 -----Mensaje original----- De: wpkops [mailto:wpkops-bounces@ietf.org] En nombre de Horne, Rob Enviado el: jueves, 05 de junio de 2014 16:54 Para: wpkops@ietf.org Asunto: Re: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt =20 Hi, I've taken a look at this and have a few comments. =20 Although the security issues are addressed in section 5, I think it = could benefit from a little more detail and clarification in sections 2 = and 3. =20 2.1 Root store provider =20 Does the audit reporting and updating method described conform to any = standard? I've seen auditors follow their own procedures which do not = match this description. =20 IB: The Baseline Requirements developed by the CABF indicates which = standards are suitable to be used by the auditors and also indicates a = procedure to perform the audit but some auditors prefer to use their own = procedure to perform audits which is valid meanwhile they follow what = the standard requires. =20 3.2.1. One root CA cross-certifies another root CA =20 Is there a defined and agreed way for older CAs to cross certify newer = CAs particularly if they're not owned by the same organisation? For = example if the criterion for cross certification is less than that = required by the root store for the original CA there could be some = interesting issues. 3.2.2 refers to adherence to the root store policy = so should that also be in 3.2.1? =20 IB: The Baseline Requirements indicates it in section 8.4 as in general. = There=B4s no clear distinction if they shall be owned by the same = organization. About the criterion is up to the root CA that signs the = other root CA to define it but once is done it "belongs" to the = organization and the same audit rules apply. For the second question is = similar, but in this case by contract and it=B4s also indicated in how = to audit delegated functions. Maybe a rewording is needed to clarify it=20 =20 3.2.5 to 3.2.7 =20 I'd have expected more emphasis on technically constraining third party = and subscriber RAs and CAs. For one thing legal contracts may be subject = to non-disclosure which could make it difficult to audit properly but if = they're not technically constrained that will be what's required. =20 IB: Will check it again =20 5.3. Root CA compromise =20 The last sentence is incomplete ;-) =20 IB: Yes, you=B4re right. Sean Mullan told me so. It=B4s already = corrected but not published =20 =20 A further thought: although potentially contentious should the scope be = expanded to include other applications which use https but are not, in = the traditional sense, web browsers? I'm thinking in particular of = applications that utilise the protocol but don't have or use any form of = trusted root store. To my mind this is a much bigger security issue than = is covered in the draft as it stands. Of course this gets us into a = discussion of how synonymous "web" is with "http/s". =20 IB: In the introduction is indicated that this trust model is to support = the communication between the subscriber and the browser. This = thought=B4s been discussed if the scope should be wider but it was = decided to keep it as it is now.=20 =20 =20 Regards, Rob =20 =20 =20 =20 -----Original Message----- From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org Sent: 29 May 2014 11:11 To: i-d-announce@ietf.org Cc: wpkops@ietf.org Subject: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Web PKI OPS Working Group of the IETF. =20 Title : Trust models of the Web PKI Authors : Inigo Barreira Bruce Morton Filename : draft-ietf-wpkops-trustmodel-02.txt Pages : 11 Date : 2014-05-29 =20 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. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-wpkops-trustmodel/ = =20 =20 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-wpkops-trustmodel-02 = =20 =20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-wpkops-trustmodel-02 = =20 =20 =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ = =20 =20 _______________________________________________ wpkops mailing list wpkops@ietf.org =20 https://www.ietf.org/mailman/listinfo/wpkops = =20 =20 _______________________________________________ wpkops mailing list wpkops@ietf.org =20 https://www.ietf.org/mailman/listinfo/wpkops = =20 --Boundary_(ID_vxJHBkBrIwlM941J+7M1aQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi = Rob,

 

In your email

 

 

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 [mailto:wpkops-bounces@ietf.org] En nombre de Horne, = Rob
Enviado el: jueves, 05 de junio de 2014 16:54
Para: = wpkops@ietf.org
Asunto: Re: [wpkops] I-D Action: = draft-ietf-wpkops-trustmodel-02.txt

 

Hi, = I've taken a look at this and have a few comments.

 

Although the security issues are addressed in = section 5, I think it could benefit from a little more detail and = clarification in sections 2 and 3.

 

2.1 = Root store provider

 

Does = the audit reporting and updating method described conform to any = standard? I've seen auditors follow their own procedures which do not = match this description.

 

IB: The = Baseline Requirements developed by the CABF indicates which standards = are suitable to be used by the auditors and also indicates a procedure = to perform the audit but some auditors prefer to use their own procedure = to perform audits which is valid meanwhile they follow what the standard = requires.

 

3.2.1. = One root CA cross-certifies another root CA

 

Is = there a defined and agreed way for older CAs to cross certify newer CAs = particularly if they're not owned by the same organisation? For example = if the criterion for cross certification is less than that required by = the root store for the original CA there could be some interesting = issues. 3.2.2 refers to adherence to the root store policy so should = that also be in 3.2.1?

 

IB: The = Baseline Requirements indicates it in section 8.4 as in general. = There=B4s no clear distinction if they shall be owned by the same = organization. About the criterion is up to the root CA that signs the = other root CA to define it but once is done it “belongs” to = the organization and the same audit rules apply. For the second question = is similar, but in this case by contract and it=B4s also indicated in = how to audit delegated functions. Maybe a rewording is needed to clarify = it

 

3.2.5 = to 3.2.7

 

I'd have expected more emphasis on technically = constraining third party and subscriber RAs and CAs. For one thing legal = contracts may be subject to non-disclosure which could make it difficult = to audit properly but if they're not technically constrained that will = be what's required.

 

IB: Will = check it again

 

5.3. = Root CA compromise

 

The = last sentence is incomplete ;-)

 

IB: Yes, = you=B4re right. Sean Mullan told me so. It=B4s already corrected but not = published

 

 

A = further thought: although potentially contentious should the scope be = expanded to include other applications which use https but are not, in = the traditional sense, web browsers? I'm thinking in particular of = applications that utilise the protocol but don't have or use any form of = trusted root store. To my mind this is a much bigger security issue than = is covered in the draft as it stands. Of course this gets us into a = discussion of how synonymous "web" is with = "http/s".

 

IB: In the introduction is = indicated that this trust model is to support the communication between = the subscriber and the browser. This thought=B4s been discussed if the = scope should be wider but it was decided to keep it as it is now. =

 

 

Regards, Rob

 

 

 

 

-----Original Message-----

From: wpkops [mailto:wpkops-bounces@ietf.org] On = Behalf Of internet-drafts@ietf.org

Sent: 29 May 2014 11:11

To: i-d-announce@ietf.org

Cc: wpkops@ietf.org

Subject: [wpkops] I-D Action: = draft-ietf-wpkops-trustmodel-02.txt

 

 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

This draft is a work = item of the Web PKI OPS Working Group of the IETF.

 

=A0=A0=A0=A0=A0=A0=A0 = Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Trust models of the Web = PKI

=A0=A0=A0=A0=A0=A0=A0 = Authors=A0=A0=A0=A0=A0=A0=A0=A0 : Inigo Barreira

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Bruce Morton

=A0 =A0=A0=A0=A0=A0=A0Filename=A0=A0=A0=A0=A0=A0=A0 = : draft-ietf-wpkops-trustmodel-02.txt

=A0=A0=A0=A0=A0=A0=A0 = Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 11

=A0=A0=A0=A0=A0=A0=A0 = Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2014-05-29

 

Abstract:

=A0=A0 This is one of a set of documents to define = the operation of the Web

=A0=A0 = PKI.=A0 It describes the currently deployed Web PKI = trust.

 

 

The = IETF datatracker status page for this draft is:

<= span = style=3D'color:windowtext;text-decoration:none'>https://datatracker.ietf.= org/doc/draft-ietf-wpkops-trustmodel/

 

There's also a htmlized version available = at:

http://tools.ietf.org/htm= l/draft-ietf-wpkops-trustmodel-02

 

A diff = from the previous version is available at:

http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-wpkops-trustmodel-02

 

 

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

 

Internet-Drafts are also available by anonymous FTP = at:

ftp://ftp.ietf.org/intern= et-drafts/

 

_______________________________________________=

wpkops mailing list

wpkops@ietf.org

https://www.ietf.org/mail= man/listinfo/wpkops

 

_______________________________________________=

wpkops mailing list

wpkops@ietf.org

https://www.ietf.org/mail= man/listinfo/wpkops

= --Boundary_(ID_vxJHBkBrIwlM941J+7M1aQ)-- From nobody Fri Jun 6 05:29:52 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0321F1A0479 for ; Fri, 6 Jun 2014 05:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okpZ_VWrPN-Q for ; Fri, 6 Jun 2014 05:29:50 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D939D1A0068 for ; Fri, 6 Jun 2014 05:29:49 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j15so3625366qaq.9 for ; Fri, 06 Jun 2014 05:29:42 -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=xjrPKln5uMVVCaDbvBuwpT9damvHswbPi4nTGnUhy5g=; b=pY4ZXYNoCvAk95ikjXY4aWICN3JxU2IZDOTitG53w3Xz0C0r13GAjOtYHqV79Mj72H Ck4BLrpR4l3sY71gOnt9XHhTi/5Jmn9qneNJXFVJPl73koDxnwAxY60b5+xN5yw4VMXI gcEQGvB0lQynwXack+ByLuDNUPYPm/roGnawPCrLxjEzkID5D8v4Jrl8Zlue3Q6kyYua Zn09PNdPm/OO5d4ZwM640OKqZOlgFKJLiVbSAN56fEznAHt9RfZKPMK8pl8SkBWZl1hn 34pSO8YYmbkM/iwF4L0H6fm8AimZRL9Ax0oMo1geHR2ZLZFKcYlr84GyUK48KNcLwPnA DNXA== MIME-Version: 1.0 X-Received: by 10.140.29.34 with SMTP id a31mr7435687qga.95.1402057782666; Fri, 06 Jun 2014 05:29:42 -0700 (PDT) Received: by 10.229.155.13 with HTTP; Fri, 6 Jun 2014 05:29:42 -0700 (PDT) Date: Fri, 6 Jun 2014 08:29:42 -0400 Message-ID: From: Michael Jenkins To: wpkops@ietf.org Content-Type: multipart/alternative; boundary=001a113a5ace1733c604fb2a04de Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/3ElYYfos5MovNyarT4oODiIATzQ Subject: [wpkops] Fwd: NIST Requests Comments on 2nd Draft of NISTIR 7924: Reference Certificate Policy X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 12:29:51 -0000 --001a113a5ace1733c604fb2a04de Content-Type: text/plain; charset=UTF-8 Saw this posted on the PKIX mail-list, thought it might be of interest here as well. Mike Jenkins NIST announces the public comment release of the second draft of Interagency Report 7924, Reference Certificate Policy . The purpose of this document is to identify a set of security controls and practices to support the secure issuance of certificates. It was written in the form of a Certificate Policy (CP), a standard format for defining the expectations and requirements of the relying party community that will trust the certificates issued by its Certificate Authorities (CAs). NIST released the first draft of this publication in April 2013 and received extensive public comments. This revised draft incorporates changes requested by commenters, many intended to improve the security controls identified in the document, provide additional flexibility for CAs, and clarify ambiguities in the previous release. NIST requests comments on Draft IR 7924 by *Friday, August 1, 2014*. Please send comments to nistir7924-comments@nist.gov, using the public comment template found at the link above. If the in-line link above does not work, please use the URL: http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-7924 --001a113a5ace1733c604fb2a04de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Saw this posted on the PKIX mail-list, thought it might= be of interest here as well.

Mike Jenkins

NIST announces t= he public comment release of the second draft of Interagency Report 7924, Reference Certificate Policy= . The purpose of this document is to identify a set of security controls=20 and practices to support the secure issuance of certificates. It was written in the form of a Certificate Policy (CP), a standard=20 format for defining the expectations and requirements of the relying=20 party community that will trust the certificates issued by its=20 Certificate Authorities (CAs).
=C2=A0
NIST released the first draft of this publication in April 2013 and=20 received extensive public comments. This revised draft incorporates=20 changes requested by commenters, many intended to improve the security=20 controls identified in the document, provide additional flexibility for CAs, and clarify ambiguities in the previous release.
=C2=A0
NIST requests comments on Draft IR 7924 by Friday, August 1, 2014. Please send comments to nistir792= 4-comments@nist.gov, using the public comment template found at the lin= k above.


If the in-line link above does not work, please use the URL:=C2=A0 http://csrc.nist.gov/publications/PubsDrafts.html#NIST-IR-7924

--001a113a5ace1733c604fb2a04de-- From nobody Fri Jun 6 09:03:38 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E371A0080 for ; Fri, 6 Jun 2014 09:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjP39zd4cTC0 for ; Fri, 6 Jun 2014 09:03:33 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF0C1A007A for ; Fri, 6 Jun 2014 09:03:32 -0700 (PDT) Received: from [194.106.220.51:62318] by server-16.bemta-14.messagelabs.com id 94/30-16986-C46E1935; Fri, 06 Jun 2014 16:03:24 +0000 X-Env-Sender: rob.horne@trustis.com X-Msg-Ref: server-5.tower-92.messagelabs.com!1402070602!16057849!7 X-Originating-IP: [217.28.140.9] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15171 invoked from network); 6 Jun 2014 16:03:23 -0000 Received: from smtp.hs20.net (HELO outlook.hs20.net) (217.28.140.9) by server-5.tower-92.messagelabs.com with AES256-SHA encrypted SMTP; 6 Jun 2014 16:03:23 -0000 Received: from THHSTE15D1BE5.hs20.net (192.168.251.26) by thhste15d1be5.hs20.net (192.168.251.26) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 6 Jun 2014 17:03:08 +0100 Received: from THHSTE15D1BE5.hs20.net ([fe80::4064:274f:d635:873e]) by THHSTE15D1BE5.hs20.net ([fe80::4064:274f:d635:873e%15]) with mapi id 15.00.0847.030; Fri, 6 Jun 2014 17:03:08 +0100 From: "Horne, Rob" To: "i-barreira@izenpe.net" , "wpkops@ietf.org" Thread-Topic: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt Thread-Index: AQHPeyZFDyYFwnLMcUy7s1i6Lj94AJtipRxAgAEXKhCAAI22gA== Date: Fri, 6 Jun 2014 16:03:08 +0000 Message-ID: <241793dc995244e4aa719ecc679fa70e@THHSTE15D1BE5.hs20.net> References: <20140529101033.15865.72439.idtracker@ietfa.amsl.com> <8bb8a25e698a450988b79c058705f1cb@THHSTE15D1BE5.hs20.net> <763539E260C37C46A0D6B340B5434C3B099397E8@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B099397E8@AEX06.ejsarea.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.6.167.196] x-exclaimer-md-config: 266e7a57-cddd-49fd-bdea-19bca6d40303 Content-Type: multipart/alternative; boundary="_000_241793dc995244e4aa719ecc679fa70eTHHSTE15D1BE5hs20net_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/orEghqWKXWsf7A-jXFf-_NoMLQs Subject: Re: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 16:03:37 -0000 --_000_241793dc995244e4aa719ecc679fa70eTHHSTE15D1BE5hs20net_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I=F1igo, Thank you for your responses which have provided excellent clarification. M= aybe 3.2.1 needs a reference to the BRs? It's not something to get excited = about so I'll leave it up to you whether you agree or not. Regards, Rob From: i-barreira@izenpe.net [mailto:i-barreira@izenpe.net] Sent: 06 June 2014 09:29 To: Horne, Rob; wpkops@ietf.org Subject: RE: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt Hi Rob, In your email 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 erantzun= a. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial a l= a 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 pusie= se en contacto con el remitente. -----Mensaje original----- De: wpkops [mailto:wpkops-bounces@ietf.org] En nombre de Horne, Rob Enviado el: jueves, 05 de junio de 2014 16:54 Para: wpkops@ietf.org Asunto: Re: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt Hi, I've taken a look at this and have a few comments. Although the security issues are addressed in section 5, I think it could b= enefit from a little more detail and clarification in sections 2 and 3. 2.1 Root store provider Does the audit reporting and updating method described conform to any stand= ard? I've seen auditors follow their own procedures which do not match this= description. IB: The Baseline Requirements developed by the CABF indicates which standar= ds are suitable to be used by the auditors and also indicates a procedure t= o perform the audit but some auditors prefer to use their own procedure to = perform audits which is valid meanwhile they follow what the standard requi= res. 3.2.1. One root CA cross-certifies another root CA Is there a defined and agreed way for older CAs to cross certify newer CAs = particularly if they're not owned by the same organisation? For example if = the criterion for cross certification is less than that required by the roo= t store for the original CA there could be some interesting issues. 3.2.2 r= efers to adherence to the root store policy so should that also be in 3.2.1= ? IB: The Baseline Requirements indicates it in section 8.4 as in general. Th= ere=B4s no clear distinction if they shall be owned by the same organizatio= n. About the criterion is up to the root CA that signs the other root CA to= define it but once is done it "belongs" to the organization and the same a= udit rules apply. For the second question is similar, but in this case by c= ontract and it=B4s also indicated in how to audit delegated functions. Mayb= e a rewording is needed to clarify it 3.2.5 to 3.2.7 I'd have expected more emphasis on technically constraining third party and= subscriber RAs and CAs. For one thing legal contracts may be subject to no= n-disclosure which could make it difficult to audit properly but if they're= not technically constrained that will be what's required. IB: Will check it again 5.3. Root CA compromise The last sentence is incomplete ;-) IB: Yes, you=B4re right. Sean Mullan told me so. It=B4s already corrected b= ut not published A further thought: although potentially contentious should the scope be exp= anded to include other applications which use https but are not, in the tra= ditional sense, web browsers? I'm thinking in particular of applications th= at utilise the protocol but don't have or use any form of trusted root stor= e. To my mind this is a much bigger security issue than is covered in the d= raft as it stands. Of course this gets us into a discussion of how synonymo= us "web" is with "http/s". IB: In the introduction is indicated that this trust model is to support th= e communication between the subscriber and the browser. This thought=B4s be= en discussed if the scope should be wider but it was decided to keep it as = it is now. Regards, Rob -----Original Message----- From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 29 May 2014 11:11 To: i-d-announce@ietf.org Cc: wpkops@ietf.org Subject: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web PKI OPS Working Group of the IETF. Title : Trust models of the Web PKI Authors : Inigo Barreira Bruce Morton Filename : draft-ietf-wpkops-trustmodel-02.txt Pages : 11 Date : 2014-05-29 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-wpkops-trustmodel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-wpkops-trustmodel-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-wpkops-trustmodel-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_241793dc995244e4aa719ecc679fa70eTHHSTE15D1BE5hs20net_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi I=F1igo,

 

Thank you for y= our responses which have provided excellent clarification. Maybe 3.2.1 need= s a reference to the BRs? It’s not something to get excited about so I’ll leave it up to you whether you agree or not.

 

Regards, Rob

 

 

 

From:= i-barreira@izenpe.net [mailto:i-barreira@izenpe.net]
Sent: 06 June 2014 09:29
To: Horne, Rob; wpkops@ietf.org
Subject: RE: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.tx= t

 

Hi Rob,

 

In your email=

 

 

I=F1igo Barreira

Responsable del =C1rea t=E9cnica

i-barreira@izenpe.net<= /o:p>

945067705

 

 

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egot= ea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gai= zki 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 p= or error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.<= /o:p>

 

 

-----Mensaje original-----
De: wpkops [mailto:wpkops-bounce= s@ietf.org] En nombre de Horne, Rob
Enviado el: jueves, 05 de junio de 2014 16:54
Para: wpkops@ietf.org
Asunto: Re: [wpkops] I-D Action: draft-ietf-wpkops-trustmodel-02.txt=

 

Hi, I've taken a look at this a= nd have a few comments.

 

Although the security issues ar= e addressed in section 5, I think it could benefit from a little more detai= l and clarification in sections 2 and 3.

 

2.1 Root store provider

 

Does the audit reporting and up= dating method described conform to any standard? I've seen auditors follow = their own procedures which do not match this description.=

&nbs= p;

IB: = The Baseline Requirements developed by the CABF indicates which standards a= re suitable to be used by the auditors and also indicates a procedure to pe= rform the audit but some auditors prefer to use their own procedure to perform audits which is valid meanwhile they= follow what the standard requires.

 

3.2.1. One root CA cross-certif= ies another root CA

 

Is there a defined and agreed w= ay for older CAs to cross certify newer CAs particularly if they're not own= ed by the same organisation? For example if the criterion for cross certifi= cation is less than that required by the root store for the original CA there could be some interesting issues.= 3.2.2 refers to adherence to the root store policy so should that also be = in 3.2.1?

&nbs= p;

IB: = The Baseline Requirements indicates it in section 8.4 as in general. There= =B4s no clear distinction if they shall be owned by the same organization. = About the criterion is up to the root CA that signs the other root CA to define it but once is done it “belon= gs” to the organization and the same audit rules apply. For the secon= d question is similar, but in this case by contract and it=B4s also indicat= ed in how to audit delegated functions. Maybe a rewording is needed to clarify it

 

3.2.5 to 3.2.7

 

I'd have expected more emphasis= on technically constraining third party and subscriber RAs and CAs. For on= e thing legal contracts may be subject to non-disclosure which could make i= t difficult to audit properly but if they're not technically constrained that will be what's required.

&nbs= p;

IB: = Will check it again

 

5.3. Root CA compromise

 

The last sentence is incomplete= ;-)

&nbs= p;

IB: = Yes, you=B4re right. Sean Mullan told me so. It=B4s already corrected but n= ot published

 

 

A further thought: although pot= entially contentious should the scope be expanded to include other applicat= ions which use https but are not, in the traditional sense, web browsers? I= 'm thinking in particular of applications that utilise the protocol but don't have or use any form of trusted root s= tore. To my mind this is a much bigger security issue than is covered in th= e draft as it stands. Of course this gets us into a discussion of how synon= ymous "web" is with "http/s".

 

IB: = In the introduction is indicated that this trust model is to support the co= mmunication between the subscriber and the browser. This thought=B4s been d= iscussed if the scope should be wider but it was decided to keep it as it is now.

&= nbsp;

&= nbsp;

Regards, Rob<= /p>

 

 

 

 

-----Original Message-----=

From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org

Sent: 29 May 2014 11:11

To: i-d-announce@ietf.org

Cc: wpkops@ietf.org

Subject: [wpkops] I-D Action: d= raft-ietf-wpkops-trustmodel-02.txt

 

 

A New Internet-Draft is availab= le from the on-line Internet-Drafts directories.

This draft is a work item of th= e Web PKI OPS Working Group of the IETF.

 

     &= nbsp;  Title         &nbs= p; : Trust models of the Web PKI

     &= nbsp;  Authors         : Inigo= Barreira

     &= nbsp;           &nbs= p;        Bruce Morton=

      =   Filename        : draft-ietf= -wpkops-trustmodel-02.txt

     &= nbsp;  Pages         &nbs= p; : 11

     &= nbsp;  Date          = ;  : 2014-05-29

 

Abstract:

   This is one of a s= et of documents to define the operation of the Web

   PKI.  It desc= ribes the currently deployed Web PKI trust.

 

 

The IETF datatracker status pag= e for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-wpkops-t= rustmodel/

 

There's also a htmlized version= available at:

http://tools.ietf.org/html/draft-ietf-wpkops-trustmodel-= 02

 

A diff from the previous versio= n is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-wp= kops-trustmodel-02

 

 

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

 

Internet-Drafts are also availa= ble by anonymous FTP at:

ftp:= //ftp.ietf.org/internet-drafts/

 

_______________________________= ________________

wpkops mailing list<= /span>

wpkops@ietf.org

https://www.ietf.org/mailman/listinfo/wpkops

 

_______________________________= ________________

wpkops mailing list<= /span>

wpkops@ietf.org

https://www.ietf.org/mailman/listinfo/wpkops

--_000_241793dc995244e4aa719ecc679fa70eTHHSTE15D1BE5hs20net_-- From nobody Fri Jun 6 11:48:03 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C514E1A0223 for ; Fri, 6 Jun 2014 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.953 X-Spam-Level: X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5L1Io19HEOT for ; Fri, 6 Jun 2014 11:48:00 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB281A021E for ; Fri, 6 Jun 2014 11:48:00 -0700 (PDT) Received: from BWILSONL1 (unknown [67.137.52.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 2C1A98FA045; Fri, 6 Jun 2014 12:47:53 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1402080473; bh=QMfyQ8/3z4+mmbhTF9BzjTtOI0k4b3JaK6t1QGmmM9g=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=F2dqaspi98I5FJkTFXlKDnKU++gLLekGwPIS/abr4P+es16fKL162SgFfnivySjAE jRvP6pkjpKV4MgyKG7jt0vm9NeY39sypHLVpnT/U91NmdKVFzmz5hEEwtnauTRjhXu YaE5xcctGkJr5uXxbYT8FrkJ619w6bNekLKOYcis= From: "Ben Wilson" To: , References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org> In-Reply-To: <53907A4C.7070307@mozilla.org> Date: Fri, 6 Jun 2014 12:47:49 -0600 Message-ID: <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Thread-Index: AQHAGq9YUAUY845vOYYDLXX689oZPAIbE3NYATl0SmABw3ilUgIjEPfBm0lfIVA= Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0033_01CF8185.85ADD830" Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/rszX-YKqor4CTKx63UfS5qqTSTA Cc: wpkops@ietf.org, 'Gervase Markham' , 'Tim Moses' Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 18:48:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0033_01CF8185.85ADD830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I=F1igo and Bruce, Perhaps we should revise the Trust Model document to describe how = browser, root store, and cryptolibrary are related? In addressing Gerv's = comments, I am thinking of starting with the following "This document reviews the current processing behaviors of cryptolibraries, and the browsers they support, with respect to SSL/TLS session establishment between a server = and a browser, ..." or something along those lines. Thoughts? Thanks, Ben >-----Original Message----- >From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Gervase = Markham >Sent: Thursday, June 5, 2014 8:10 AM >To: Tim Moses; ben@digicert.com >Cc: wpkops@ietf.org >Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior = Draft > >On 05/06/14 14:37, Tim Moses wrote: >> Hi Ben. We want to move this document to WG draft status. Do you=20 >> want to address Gerv's comments before we hold a ballot? I suggest = we=20 >> do that. > >Again, apologies for lack of knowledge of the process, but: the doc is = full of "to be expanded", > "we plan to..." etc. So there will be lots of further change. Is that = what "Draft" means? > >My two examples were two of many; they were actually given to try and = get clarity on the=20 >purpose and goals of the document. If that's written up somewhere, do = point me to it. :-) > >Gerv > > ------=_NextPart_000_0033_01CF8185.85ADD830 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRRjCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggbBMIIFqaADAgECAhAHv9Jd b6GmlTp/jguOyky8MA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMTAeFw0xMzA2MDMwMDAwMDBaFw0xNjA4MzExMjAwMDBaMHQxCzAJBgNVBAYT AlVTMQ0wCwYDVQQIEwRVdGFoMQ0wCwYDVQQHEwRMZWhpMREwDwYDVQQKEwhEaWdpQ2VydDETMBEG A1UEAxMKQmVuIFdpbHNvbjEfMB0GCSqGSIb3DQEJARMQYmVuQGRpZ2ljZXJ0LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8EX23kpIJWkjmY6Sx23gtdJWUZ7R7xzitGNquNhRQs fVeKvt0/pvRdc+TSKtj58kQ0tQ1BISUuOjr5bB4TeICooUMryRzQ98Qla7SkKwREX6YtySqZl+vj c+JuW0X95Ax0aHjYe13pD+zLHmbGTumwNfxbNi2/j1EeO/tIWml1saD/nMLovWWuChPd0w4Cy4Ex v3Y6Bsl0OEIehbTAw1Mb2kBAioP/6cd70DVgBqrLz8C+kWaIfLpobTwD8/wwrGs0ANtNFx3Dxz8x sfMRHkE140Fkmhf8ogO1M/hne2OzQJUVARLYa15yIDlp5rcRDIFRfjTRXDaETUq3dPHeApcCAwEA AaOCA18wggNbMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSUK0wr DI2kT+SUkmzvXtMaNBtUIzAbBgNVHREEFDASgRBiZW5AZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0g BIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdp Y2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBu AHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABE AGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkA bgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBp AHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIA YQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEF BQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcw AoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAG2NW/zRakbPATZt2m3+Xq7P/YdUzO1R8 6vcG49KkiuNGbExefzzMJnDK67LOzHpuqIyZmbe1ssg8swdenzRsRPoOt9hY7XFwwo8JJxiElddu NPWERMBQWeIPDnfpry3ZC4bMrEPsCsVa0ClPrG2RgGpq5JkPIdgiWngnHyl3ZajiqYca7faWU8eq SDjsyHj6KSF0M9gXhuTjZ20aMA3DZ0exTE2XAYYJUXLSg49szMy28LRW6i0rLfAfx1uNXjGfzdnf gYFRdkdSXqRgdXgCHtSmbAOi077oIvyVeBb2W7P9o+G29sZ/x8bLYoE/K2uliJ8fBAswrsdcirv3 Jqo+fDCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoX DTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sM NP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0Pd Aug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtP QLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9 BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggr BgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIB tQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBl ACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQA dQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBl AHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEA cgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBh AGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAA aABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8w fQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYI KwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVk SURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcN K2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEA hGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOK ZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYC gNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dG OHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qd lWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCA74wggO6AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UE AxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAHv9Jdb6GmlTp/jguOyky8MAkGBSsOAwIaBQCg ggIdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwNjE4NDc0 OVowIwYJKoZIhvcNAQkEMRYEFDm6Fs6JQNQ0zQs+e5YLIQ45Z8UoMIGFBgkrBgEEAYI3EAQxeDB2 MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44L jspMvDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3Vy ZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44LjspMvDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFl AwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIA gDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgB ZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQCVeN0TpIzx E7iW7+L97qRvivccuGEf+XJrGJItximT6k25iM4rFQ6osLu+0KZVcKsv+54DvUbPhXbevYGsbn48 frUtN8x8i2i8uNQijFNlaNVcKdYo4hv23FstZ4cZcL/qDAQSSnVbekKnDZXs1Mgud0PKq7DO801h 5O5ilX1L8ZArrVtXxxIYMzFnJeSv6RzEKwwGIsNBzp/t6WCK3yBxFK4n3zU0UkyDOXYv8YRCTOWH JbcnskeV6zqRT+Nh9ao1yx9mpnAAco8uP5EBk8L37gK3UwE5NFvcunaRqKN/MLlyTri5Ypog26k3 AYRh8lUmJ4VcCNaeds/iYWAv7jh8AAAAAAAA ------=_NextPart_000_0033_01CF8185.85ADD830-- From nobody Fri Jun 6 13:01:59 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E331A0086 for ; Fri, 6 Jun 2014 13:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD2y_5j6Lyis for ; Fri, 6 Jun 2014 13:01:57 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB801A0078 for ; Fri, 6 Jun 2014 13:01:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,991,1392181200"; d="scan'208";a="1203767" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP/TLS/AES128-SHA; 06 Jun 2014 16:01:49 -0400 Received: from SOTTEXCH11.corp.ad.entrust.com ([fe80::303b:8584:c6f4:be18]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.03.0174.001; Fri, 6 Jun 2014 16:01:49 -0400 From: Tim Moses To: Ben Wilson Thread-Topic: [wpkops] Preliminary Next Version of Browser Behavior Draft Thread-Index: Ac9uwg5tUjGh+edRQh2AER9r67oKVQLT+HEAAY+VWIAAHLZlEAAJkowAADv7f4D//9Gd+A== Date: Fri, 6 Jun 2014 20:01:47 +0000 Message-ID: <4CC654C4-4A26-4284-A231-6C0D60B81A1E@entrust.com> References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org>, <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> In-Reply-To: <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/426BT469kbPvCujJbrKDQoxnSNc Cc: Gervase Markham , "i-barreira@izenpe.net" , Bruce Morton , "wpkops@ietf.org" Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:01:58 -0000 Bruce/Inigo - Do you think the Transparency section in the revocation doc f= rom Phill and David belongs in the Trust Model doc? =20 All the best. Tim.=20 > On Jun 6, 2014, at 2:47 PM, "Ben Wilson" wrote: >=20 > I=F1igo and Bruce, > Perhaps we should revise the Trust Model document to describe how browser= , > root store, and cryptolibrary are related? In addressing Gerv's comments= , I > am thinking of starting with the following "This document reviews the > current processing behaviors of cryptolibraries, and the browsers they > support, with respect to SSL/TLS session establishment between a server a= nd > a browser, ..." or something along those lines. > Thoughts? > Thanks, > Ben >=20 >> -----Original Message----- >> From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Gervase Markh= am >> Sent: Thursday, June 5, 2014 8:10 AM >> To: Tim Moses; ben@digicert.com >> Cc: wpkops@ietf.org >> Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft >>=20 >>> On 05/06/14 14:37, Tim Moses wrote: >>> Hi Ben. We want to move this document to WG draft status. Do you=20 >>> want to address Gerv's comments before we hold a ballot? I suggest we= =20 >>> do that. >>=20 >> Again, apologies for lack of knowledge of the process, but: the doc is f= ull > of "to be expanded", >> "we plan to..." etc. So there will be lots of further change. Is that wh= at > "Draft" means? >>=20 >> My two examples were two of many; they were actually given to try and ge= t > clarity on the=20 >> purpose and goals of the document. If that's written up somewhere, do po= int > me to it. :-) >>=20 >> Gerv >>=20 >>=20 From nobody Mon Jun 9 01:29:10 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067AD1A0012 for ; Mon, 9 Jun 2014 01:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP9C91sJh6Jy for ; Mon, 9 Jun 2014 01:29:06 -0700 (PDT) Received: from ektmail2iron2.euskaltel.es (ektmail2iron2.euskaltel.es [212.142.144.26]) by ietfa.amsl.com (Postfix) with ESMTP id 51ABD1A001E for ; Mon, 9 Jun 2014 01:29:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEADZvlVPUNwh3/2dsb2JhbABZyHEBgSd1hAMBAQEEMAwBNQcMBAIBCBEEAQEBCgYXAQYBRQkIAgUSCIg+AclKF447HRQHBoMlgRYBA5ohk0WDPg X-IPAS-Result: AqEEADZvlVPUNwh3/2dsb2JhbABZyHEBgSd1hAMBAQEEMAwBNQcMBAIBCBEEAQEBCgYXAQYBRQkIAgUSCIg+AclKF447HRQHBoMlgRYBA5ohk0WDPg X-IronPort-AV: E=Sophos;i="4.98,1001,1392159600"; d="scan'208";a="165382584" Received: from ektmail2mta2.euskaltel.es (HELO correo.euskaltel.es) ([212.55.8.119]) by ektmail2iron2.euskaltel.es with ESMTP; 09 Jun 2014 10:13:06 +0200 Received: from ejlp024.ejgv ([62.99.63.247]) by ektmail2mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0N6W000E47KFQVL0@ektmail2mta2.euskaltel.es> for wpkops@ietf.org; Mon, 09 Jun 2014 10:29:03 +0200 (MEST) Received: from afe02.ejsarea.net (afe02 [10.200.192.15]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id s598T3oC025278; Mon, 09 Jun 2014 10:29:03 +0200 Received: from AEX06.ejsarea.net ([10.200.198.17]) by afe02.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 09 Jun 2014 10:29:02 +0200 Date: Mon, 09 Jun 2014 10:29:01 +0200 From: i-barreira@izenpe.net In-reply-to: <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> To: ben@digicert.com, bruce.morton@entrust.com Message-id: <763539E260C37C46A0D6B340B5434C3B09939A2F@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] Preliminary Next Version of Browser Behavior Draft Thread-index: AQHAGq9YUAUY845vOYYDLXX689oZPAIbE3NYATl0SmABw3ilUgIjEPfBm0lfIVCABAsYEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org> <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> X-OriginalArrivalTime: 09 Jun 2014 08:29:02.0604 (UTC) FILETIME=[DE7084C0:01CF83BC] Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/kyD_4CK-koDZBDoUSIn8lFwdEsE Cc: wpkops@ietf.org, gerv@mozilla.org, tim.moses@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 08:29:09 -0000 Hi Ben, The current text of the trust models document already identifies the way = a browser and a root store provider work together but not the relation = with the crypto libraries. I don=B4t understand your question exactly = because I don=B4t see why these libraries are of interest for a trust = model. Do you mean that a trust model can differ depending on which = library is used? The trust model document is more on a "functional" view than a technical = one. I need more clarification on what you think to be added 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: Ben Wilson [mailto:ben@digicert.com]=20 Enviado el: viernes, 06 de junio de 2014 20:48 Para: Barreira Iglesias, I=F1igo; bruce.morton@entrust.com CC: wpkops@ietf.org; 'Gervase Markham'; 'Tim Moses' Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft I=F1igo and Bruce, Perhaps we should revise the Trust Model document to describe how = browser, root store, and cryptolibrary are related? In addressing Gerv's = comments, I am thinking of starting with the following "This document reviews the current processing behaviors of cryptolibraries, and the browsers they support, with respect to SSL/TLS session establishment between a server = and a browser, ..." or something along those lines. Thoughts? Thanks, Ben >-----Original Message----- >From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Gervase = Markham >Sent: Thursday, June 5, 2014 8:10 AM >To: Tim Moses; ben@digicert.com >Cc: wpkops@ietf.org >Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior = Draft > >On 05/06/14 14:37, Tim Moses wrote: >> Hi Ben. We want to move this document to WG draft status. Do you=20 >> want to address Gerv's comments before we hold a ballot? I suggest = we=20 >> do that. > >Again, apologies for lack of knowledge of the process, but: the doc is = full of "to be expanded", > "we plan to..." etc. So there will be lots of further change. Is that = what "Draft" means? > >My two examples were two of many; they were actually given to try and = get clarity on the=20 >purpose and goals of the document. If that's written up somewhere, do = point me to it. :-) > >Gerv > > From nobody Mon Jun 9 02:00:59 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C381A0023 for ; Mon, 9 Jun 2014 02:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA9xILI77q74 for ; Mon, 9 Jun 2014 02:00:55 -0700 (PDT) Received: from ektmail1iron2.euskaltel.es (ektmail1iron2.euskaltel.es [212.142.144.27]) by ietfa.amsl.com (Postfix) with ESMTP id A76FE1A0027 for ; Mon, 9 Jun 2014 02:00:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAGR3lVPUNwgN/2dsb2JhbABZyHQBgSd1hAMBAQEDATAMATwFBwQCAQgRBAEBAQoGFwEGAUUJCAIFEgiIMgwByWYXjjsdFAcGgyWBFgEDhGAClT+TRYM+ X-IPAS-Result: AqEEAGR3lVPUNwgN/2dsb2JhbABZyHQBgSd1hAMBAQEDATAMATwFBwQCAQgRBAEBAQoGFwEGAUUJCAIFEgiIMgwByWYXjjsdFAcGgyWBFgEDhGAClT+TRYM+ X-IronPort-AV: E=Sophos;i="4.98,1001,1392159600"; d="scan'208";a="174091687" Received: from ektmail1mta2.euskaltel.es (HELO correo.euskaltel.es) ([212.55.8.13]) by ektmail1iron2.euskaltel.es with ESMTP; 09 Jun 2014 10:44:43 +0200 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 <0N6W0037T90VO1A0@ektmail1mta2.euskaltel.es> for wpkops@ietf.org; Mon, 09 Jun 2014 11:00:31 +0200 (CEST) Received: from afe01.ejsarea.net (afe01 [10.200.192.14]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id s5990Vh9001518; Mon, 09 Jun 2014 11:00:31 +0200 Received: from AEX06.ejsarea.net ([10.200.198.17]) by afe01.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 09 Jun 2014 11:00:30 +0200 Date: Mon, 09 Jun 2014 11:00:30 +0200 From: i-barreira@izenpe.net In-reply-to: <4CC654C4-4A26-4284-A231-6C0D60B81A1E@entrust.com> To: tim.moses@entrust.com, ben@digicert.com Message-id: <763539E260C37C46A0D6B340B5434C3B09939A5B@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] Preliminary Next Version of Browser Behavior Draft Thread-index: Ac9uwg5tUjGh+edRQh2AER9r67oKVQLT+HEAAY+VWIAAHLZlEAAJkowAADv7f4D//9Gd+P/8BSmw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org> <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> <4CC654C4-4A26-4284-A231-6C0D60B81A1E@entrust.com> X-OriginalArrivalTime: 09 Jun 2014 09:00:30.0464 (UTC) FILETIME=[43B11800:01CF83C1] Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/P4elO8iZP57vlS2Q0opaanGkVS4 Cc: gerv@mozilla.org, wpkops@ietf.org, bruce.morton@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 09:00:58 -0000 Hi Tim, Well, I have my doubts. The trust model document is about the webPKI = working as today and CT is not deployed at all. Google plans to = incorporate by the beginning of 2015 officially and make it mandatory = for Chrome (of course, CAs can use it today on a voluntary basis). OTOH, CT is about issuing a certificate from a CA and how to let the = others know that a certificate has not been issued properly but I think = this is on the CA operations rather than on a trust model document but = it also has implications on the trust you can have. Google uses in Chrome, when running on windows, the MS root store so it = relies on what MS has stated in his root store program independently of = the CT. But, in section 3.4 of the trust model document, it=B4s described how a = browser can support public key pinning, so CT can be a new section = 3.4.5, but again, it=B4s not yet deployed. The same can happen with CAA, = there=B4s a RFC but none is using it at the moment and there=B4s a = minimum of % to be considered. Initially was also considered the EU Trusted List and were removed = because not "widely" used and maintained by the browser, so the % was = very low. So, IMHO, right now, the CT is not part of the trust model document. = We=B4ll see next year. 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: Tim Moses [mailto:tim.moses@entrust.com]=20 Enviado el: viernes, 06 de junio de 2014 22:02 Para: Ben Wilson CC: Barreira Iglesias, I=F1igo; Bruce Morton; wpkops@ietf.org; Gervase = Markham Asunto: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Bruce/Inigo - Do you think the Transparency section in the revocation = doc from Phill and David belongs in the Trust Model doc? =20 All the best. Tim.=20 > On Jun 6, 2014, at 2:47 PM, "Ben Wilson" wrote: >=20 > I=F1igo and Bruce, > Perhaps we should revise the Trust Model document to describe how=20 > browser, root store, and cryptolibrary are related? In addressing=20 > Gerv's comments, I am thinking of starting with the following "This=20 > document reviews the current processing behaviors of cryptolibraries,=20 > and the browsers they support, with respect to SSL/TLS session=20 > establishment between a server and a browser, ..." or something along = those lines. > Thoughts? > Thanks, > Ben >=20 >> -----Original Message----- >> From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Gervase=20 >> Markham >> Sent: Thursday, June 5, 2014 8:10 AM >> To: Tim Moses; ben@digicert.com >> Cc: wpkops@ietf.org >> Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior=20 >> Draft >>=20 >>> On 05/06/14 14:37, Tim Moses wrote: >>> Hi Ben. We want to move this document to WG draft status. Do you=20 >>> want to address Gerv's comments before we hold a ballot? I suggest=20 >>> we do that. >>=20 >> Again, apologies for lack of knowledge of the process, but: the doc=20 >> is full > of "to be expanded", >> "we plan to..." etc. So there will be lots of further change. Is that = >> what > "Draft" means? >>=20 >> My two examples were two of many; they were actually given to try and = >> get > clarity on the >> purpose and goals of the document. If that's written up somewhere, do = >> point > me to it. :-) >>=20 >> Gerv >>=20 >>=20 From nobody Mon Jun 9 09:03:34 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771941A021E for ; Mon, 9 Jun 2014 09:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y98a9T5vBoGD for ; Mon, 9 Jun 2014 09:03:21 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by ietfa.amsl.com (Postfix) with ESMTP id 52F2A1A020A for ; Mon, 9 Jun 2014 09:02:56 -0700 (PDT) Received: from [192.168.0.10] (unknown [88.182.125.39]) by smtp3-g21.free.fr (Postfix) with ESMTP id D6181A61C2 for ; Mon, 9 Jun 2014 18:02:54 +0200 (CEST) Message-ID: <5395DAAD.1050901@free.fr> Date: Mon, 09 Jun 2014 18:02:53 +0200 From: Denis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: wpkops@ietf.org References: <5395DA45.9080105@free.fr> In-Reply-To: <5395DA45.9080105@free.fr> X-Forwarded-Message-Id: <5395DA45.9080105@free.fr> Content-Type: multipart/alternative; boundary="------------090201080504010606020301" Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/566V5a2v_Q6EVIhJDNTuTtmNij0 Subject: [wpkops] Fwd: Re: I-D Action: draft-ietf-wpkops-trustmodel-02.txt X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:03:23 -0000 This is a multi-part message in MIME format. --------------090201080504010606020301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Comments on draft-ietf-wpkops-trustmodel-02* * * *1.** Change :* * * * Root CA - a CA with a self signed certificate and whose public key* * is included as a trust anchor in a root store.* *into:* * Root CA - a CA with a self signed certificate and whose public key* * is included as a trust anchor in a root_certificates_ store.* * * * * *2.** Change :* * Root store - a set of root certificates which can be trusted by a* * browser.* *into:* * Root_certificates_ store - a set of root certificates which can be trusted by_the operating system and/or_a browser.* * * *3.** Change :* * Root store policy - the governance policy provided by the root* * store provider.* *into:* * Root_certificates_ store policy - the governance policy that is applicable to the Root_certificates_ store.* * * * * *4.** Change "Root store provider" into Root store_manager_". If the user prevents updates to the root certificate store, then he becomes the root store manager. The computer department of a organisation to which an employee belongs to may also be a root store manager.* * * * * *5.** The current draft only describes multiples variations around what is called in this draft "a basic Web PKI trust model". However it omits to present an overview of trust models and hence the limitations of the current trust model are well hidden. If web browser providers are going to read this RFC it would be beneficial to provide more information so that the next generation of web browsers will meet the user needs, which is not the case today.* * * *It is thus proposed :* * * *(a) to have a section 2 called "2.Trust model_s_", and* *(b) to change section 2 into section 3 and rename it: "3. Basic Web PKI trust model".* * * * * *6.** Text proposal for a new section 2 called "2.Trust model_s_"* * * *The trust model of current web browsers is well suited to be used with inexperience users from home or while travelling. However, it is not really suited to be used for business purposes. When used by business people, there needs to be a clear separation between business activities and personal activities: trust conditions that apply to business web sites are not the same than those that apply to web sites accessed for personal use.* * * *At a coarse level of granularity, there should be at least two different root certificates stores: one for business use and one for personal use.* * * *At a finer level of granularity, there may be different contexts for business use as well as for personal use. As a consequence, more than two root certificates stores may be needed in practice.* * * *Since current browsers are using one and only one certificate store, the only current way to circumvent the problem is to use different web browsers, each one using a different root certificates store. However, this is not sufficient, since by default every root certificates store is updated either by the Operating System (OS) provider or by the web browser provider.* * * *When a root certificates store is used for business purposes, either the management of the company or the end user himself should have the ability to define which root certificates it trusts. As a consequence, automatic updates from the OS provider or from the web browser provider must be disabled. Such operation is currently not really easy to be made, even for experienced users.* * * *The next section describes a basic Web PKI trust model which is a model where a web browser can only use one root certificates store, which is by default updated by an OS provider or by a web browser provider.* * * * * *7.** Section 2.1 is currently called2.1: "Root store provider"* * * *It is proposed to rename it: "2.1 Root store manager". Modified text proposal:* * * *A root certificates store manager establishes criteria or requirements for accepting a given root certificate in a given root certificates store. A root certificates manager may be:* - *the provider of an OS,* - *the provider of a web browser,* - *the computer department of a organisation,* - *the end-user himself.* * * *The provider of an OS or of a web browser usually determines the root certificates store policy for the root certificates placed under his control. It establishes requirements for accepting a root certificate.* *These requirements must be met by a candidate root CA in order to be included in their root certificate store. In such a case, the root certificates store manager may require the candidate root CA to be subject to an annual compliance audit performed by a third party auditor as specified in [BR-certs]. The audit requirements are defined by the root certificates store manager. The audit is based on an accepted schema of the standards (e.g., WebTrust or ETSI). A third party auditor generates an audit report which is provided to the root store provider. If the audit report states the root CA did not comply with the auditing standards, then the root CA will be required to take corrective actions. Once the corrective actions are completed, then an updated report is submitted to the root store provider. If the status of the root CA is not acceptable to the root store provider, then the root CA certificates may be removed from the root store or the indications from the browser (e.g., removal of https indicator) may change for certificates verified under that root CA.* * * *The computer department of an organisation may take control of the workstations of the employees. In such a case, the employees are no more able to perform management actions, e.g. installing new applications, and among the many controls performed by the computer department of the organisation, root certificates stores are directly managed by the computer department of the organisation.* * * *The end-user, if correctly educated, may manage himself the various root certificates stores that are present on his workstation by adding root certificates or by deleting root certificates that were initially present. In such case, any external automatic updates of these root certificates stores must be disabled.* * * * * *8.** Section3.1.1 "Browser adopts root store" mentions on page 6:* * * * The browser will provide its own trust and security indications. The* * browser may determine whether it will provide extended validation* * indications. * * * *In this document it is the first time that the expression "extended validation" is being used, but without any explanation. Please provide more explanations and indicate an external reference.* * * * * *9.** Section5 "Security Considerations" is missing to address one important security issue.* * * *There is a problem with the automatic updates of root certificates: when an end-user carefully removes root certificates in a given root certificates store and add others root certificates without knowing that at the next automatic update (which will happen at an unknown date) all his efforts will be annihilated. This will then create a denial of service (for the root certificates that have been added) and may introduce some vulnerabilities (for the root certificates that have been suppressed). Please add a new sub-section and text.* * * * * *10.** The problem with such a draft is that it will not really help the end-user, since there is no indication of which root certificates store is being used by each web browser.* * * *The following table should be added, with the X replaced by an indicator stating whether the web browser is using its own root certificates store or the root certificates store from the supporting OS.* * * * | | IExplorer | Firefox | Opera | Chrome | Safari |* * | Windows XP | X | X | X | X | X |* * | Windows 7+ | X | X | X | X | X |* * | Mac OS X | N/A | X | N/A | X | X |* * | Linux | N/A | X | X | X | N/A |* * * Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web PKI OPS Working Group of the IETF. > > Title : Trust models of the Web PKI > Authors : Inigo Barreira > Bruce Morton > Filename : draft-ietf-wpkops-trustmodel-02.txt > Pages : 11 > Date : 2014-05-29 > > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-wpkops-trustmodel/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-wpkops-trustmodel-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-wpkops-trustmodel-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops --------------090201080504010606020301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Comments on draft-ietf-wpkops-trustmodel-02 
 
1. Change : 
 
      Root CA - a CA with a self signed certificate and whose public key
      is included as a trust anchor in a root store. 
into: 
      Root CA - a CA with a self signed certificate and whose public key
      is included as a trust anchor in a root certificates store.
 
 
2. Change :  
      Root store - a set of root certificates which can be trusted by a
      browser. 
into: 
      Root certificates store - a set of root certificates which 

      can be trusted by the operating system and/or a browser.
 
3. Change :  
      Root store policy - the governance policy provided by the root
      store provider. 
into: 
      Root certificates store policy - the governance policy that is
      applicable to the Root certificates store.
 
 
4. Change "Root store provider" into Root store manager". If the user prevents updates to the root certificate store, 
then he becomes the root store manager. The computer department of a organisation to which an employee belongs to
 may also be a root store manager.
 
 
5. The current draft only describes multiples variations around what is called in this draft "a basic Web PKI trust model". 
However it omits to present an overview of trust models and hence the limitations of the current trust model are well hidden. 
If web browser providers are going to read this RFC it would be beneficial to provide more information so that the next generation 
of web browsers will meet the user needs, which is not the case today.
 
It is thus proposed :
 
(a) to have a section 2 called "2. Trust models", and 
(b) to change section 2 into section 3 and rename it: "3. Basic Web PKI trust model".
 
 
6. Text proposal for a new section 2 called "2. Trust models"
 
The trust model of current web browsers is well suited to be used with inexperience users from home or while travelling. 
However, it is not really suited to be used for business purposes. When used by business people, there needs to be 
a clear separation between business activities and personal activities: trust conditions that apply to business web sites 
are not the same than those that apply to web sites accessed for personal use.
 
At a coarse level of granularity, there should be at least two different root certificates stores: one for business use 
and one for personal use.
 
At a finer level of granularity, there may be different contexts for business use as well as for personal use. 
As a consequence, more than two root certificates stores may be needed in practice.
 
Since current browsers are using one and only one certificate store, the only current way to circumvent the problem is to use 
different web browsers, each one using a different root certificates store. However, this is not sufficient, since by default 
every root certificates store is updated either by the Operating System (OS) provider or by the web browser provider.
 
When a root certificates store is used for business purposes, either the management of the company or the end user himself 
should have the ability to define which root certificates it trusts. As a consequence, automatic updates from the OS provider 
or from the web browser provider must be disabled. Such operation is currently not really easy to be made, even for experienced users.
 
The next section describes a basic Web PKI trust model which is a model where a web browser can only use one root certificates store, 
which is by default updated by an OS provider or by a web browser provider.
 
 
7. Section 2.1 is currently called 2.1:  "Root store provider"
 
It is proposed to rename it: "2.1 Root store manager". Modified text proposal:
 
A root certificates store manager establishes criteria or requirements for accepting a given root certificate 
in a given root certificates store. A root certificates manager may be:
-          the provider of an OS,
-          the provider of a web browser,
-          the computer department of a organisation,
-          the end-user himself.
 
The provider of an OS or of a web browser usually determines the root certificates store policy for the root certificates 
placed under his control. It establishes requirements for accepting a root certificate. 
These requirements must be met by a candidate root CA in order to be included in their root certificate store. 
In such a case, the root certificates store manager may require the candidate root CA to be subject to an annual compliance audit 
performed by a third party auditor as specified in [BR-certs].  The audit requirements are defined by the root certificates store manager. 
The audit is based on an accepted schema of the standards (e.g., WebTrust or ETSI).  A third party auditor generates an audit report 
which is provided to the root store provider.  If the audit report states the root CA did not comply with the auditing standards, 
then the root CA will be required to take corrective actions.  Once the corrective actions are completed, then an updated report 
is submitted to the root store provider.  If the status of the root CA is not acceptable to the root store provider, then 
the root CA certificates may be removed from the root store or the indications from the browser (e.g., removal of https indicator) 
may change for certificates verified under that root CA.
 
The computer department of an organisation may take control of the workstations of the employees. In such a case, the employees 
are no more able to perform management actions, e.g. installing new applications, and among the many controls performed 
by the computer department of the organisation, root certificates stores are directly managed by the computer department of the organisation.
 
The end-user, if correctly educated, may manage himself the various root certificates stores that are present on his workstation 
by adding root certificates or by deleting root certificates that were initially present. In such case, any external automatic updates 
of these root certificates stores must be disabled.
 
 
8. Section 3.1.1 "Browser adopts root store" mentions on page 6:
 
   The browser will provide its own trust and security indications.  The
   browser may determine whether it will provide extended validation
   indications.  
 
In this document it is the first time that the expression "extended validation" is being used, but without any explanation. 
Please provide more explanations and indicate an external reference.
 
 
9. Section 5 "Security Considerations" is missing to address one important security issue.
 
There is a problem with the automatic updates of root certificates: when an end-user carefully removes root certificates 
in a given root certificates store and add others root certificates without knowing that at the next automatic update 
(which will happen at an unknown date) all his efforts will be annihilated. This will then create a denial of service 
(for the root certificates that have been added) and may introduce some vulnerabilities (for the root certificates that 
have been suppressed). Please add a new sub-section and text.
 
 
10. The problem with such a draft is that it will not really help the end-user, since there is no indication of which 
root certificates store is being used by each web browser.
 
The following table should be added, with the X replaced by an indicator stating whether the web browser is using 
its own root certificates store or the root certificates store from the supporting OS.
 
   |             | IExplorer | Firefox |  Opera  |  Chrome  |  Safari  |
   | Windows XP  |     X     |    X    |    X    |     X    |     X    |
   | Windows 7+  |     X     |    X    |    X    |     X    |     X    |
   | Mac OS X    |    N/A    |    X    |   N/A   |     X    |     X    |
   | Linux       |    N/A    |    X    |    X    |     X    |    N/A   |
 

Denis

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web PKI OPS Working Group of the IETF.

        Title           : Trust models of the Web PKI
        Authors         : Inigo Barreira
                          Bruce Morton
	Filename        : draft-ietf-wpkops-trustmodel-02.txt
	Pages           : 11
	Date            : 2014-05-29

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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-wpkops-trustmodel/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-wpkops-trustmodel-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-wpkops-trustmodel-02


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

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

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



--------------090201080504010606020301-- From nobody Mon Jun 9 09:24:34 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785641A0264 for ; Mon, 9 Jun 2014 09:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.953 X-Spam-Level: X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxo5yGMgzfNJ for ; Mon, 9 Jun 2014 09:24:30 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA341A01D0 for ; Mon, 9 Jun 2014 09:24:30 -0700 (PDT) Received: from BWILSONL1 (unknown [67.137.52.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id B0A857FA126; Mon, 9 Jun 2014 10:24:29 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1402331070; bh=RLM5y5WN0y9nU1uXcUrHJxr0pSOYdT6hjtikK6SbbRs=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=ohQfPNmtluVcbwPV13dhUfhXKx4DyO73qa9r+fVCcdn/vL3+OUJf2MyMAGh1S6b8+ knlEll+b5pIU8tkxDyYX6FLicJtouWUAVVXBf8eU1o7L3tLiFFxHLIT5QJzlnJwlsv RTy4XtevGtLLGtU6MeAaCoZSgHbm6fsoldADwnaM= From: "Ben Wilson" To: , References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org> <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> <763539E260C37C46A0D6B340B5434C3B09939A2F@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B09939A2F@AEX06.ejsarea.net> Date: Mon, 9 Jun 2014 10:24:25 -0600 Message-ID: <007301cf83ff$4810e680$d832b380$@digicert.com> X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Thread-Index: AQHAGq9YUAUY845vOYYDLXX689oZPAIbE3NYATl0SmABw3ilUgIjEPfBAtMvZiMCR6D4R5slGUwg Content-Language: en-us Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_006F_01CF83CC.FB833200"; protocol="application/x-pkcs7-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/9WjlV1FqqHUtHI54Fcqh3AlQuSM Cc: wpkops@ietf.org, gerv@mozilla.org, tim.moses@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:24:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006F_01CF83CC.FB833200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I=F1igo, Yes, the cryptolibraries are functional subcomponents of browsers, so = they ought to be mentioned. Providing the functional introduction will lay = the groundwork for technical background. I'll send you (or post to the IETF site) the next version of the working document on non-revocation = behavior. Cheers, Ben=20 -----Original Message----- From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of i-barreira@izenpe.net Sent: Monday, June 9, 2014 2:29 AM To: ben@digicert.com; bruce.morton@entrust.com Cc: wpkops@ietf.org; gerv@mozilla.org; tim.moses@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, The current text of the trust models document already identifies the way = a browser and a root store provider work together but not the relation = with the crypto libraries. I don=B4t understand your question exactly because = I don=B4t see why these libraries are of interest for a trust model. Do = you mean that a trust model can differ depending on which library is used? The trust model document is more on a "functional" view than a technical one. I need more clarification on what you think to be added 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: Ben Wilson [mailto:ben@digicert.com] Enviado el: viernes, 06 de = junio de 2014 20:48 Para: Barreira Iglesias, I=F1igo; bruce.morton@entrust.com CC: wpkops@ietf.org; 'Gervase Markham'; 'Tim Moses' Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft I=F1igo and Bruce, Perhaps we should revise the Trust Model document to describe how = browser, root store, and cryptolibrary are related? In addressing Gerv's = comments, I am thinking of starting with the following "This document reviews the current processing behaviors of cryptolibraries, and the browsers they support, with respect to SSL/TLS session establishment between a server = and a browser, ..." or something along those lines. Thoughts? Thanks, Ben >-----Original Message----- >From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Gervase=20 >Markham >Sent: Thursday, June 5, 2014 8:10 AM >To: Tim Moses; ben@digicert.com >Cc: wpkops@ietf.org >Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior=20 >Draft > >On 05/06/14 14:37, Tim Moses wrote: >> Hi Ben. We want to move this document to WG draft status. Do you=20 >> want to address Gerv's comments before we hold a ballot? I suggest=20 >> we do that. > >Again, apologies for lack of knowledge of the process, but: the doc is=20 >full of "to be expanded", > "we plan to..." etc. So there will be lots of further change. Is that=20 > what "Draft" means? > >My two examples were two of many; they were actually given to try and=20 >get clarity on the=20 >purpose and goals of the document. If that's written up somewhere, do=20 >point me to it. :-) > >Gerv > > _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops ------=_NextPart_000_006F_01CF83CC.FB833200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRRjCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggbBMIIFqaADAgECAhAHv9Jd b6GmlTp/jguOyky8MA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMTAeFw0xMzA2MDMwMDAwMDBaFw0xNjA4MzExMjAwMDBaMHQxCzAJBgNVBAYT AlVTMQ0wCwYDVQQIEwRVdGFoMQ0wCwYDVQQHEwRMZWhpMREwDwYDVQQKEwhEaWdpQ2VydDETMBEG A1UEAxMKQmVuIFdpbHNvbjEfMB0GCSqGSIb3DQEJARMQYmVuQGRpZ2ljZXJ0LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8EX23kpIJWkjmY6Sx23gtdJWUZ7R7xzitGNquNhRQs fVeKvt0/pvRdc+TSKtj58kQ0tQ1BISUuOjr5bB4TeICooUMryRzQ98Qla7SkKwREX6YtySqZl+vj c+JuW0X95Ax0aHjYe13pD+zLHmbGTumwNfxbNi2/j1EeO/tIWml1saD/nMLovWWuChPd0w4Cy4Ex v3Y6Bsl0OEIehbTAw1Mb2kBAioP/6cd70DVgBqrLz8C+kWaIfLpobTwD8/wwrGs0ANtNFx3Dxz8x sfMRHkE140Fkmhf8ogO1M/hne2OzQJUVARLYa15yIDlp5rcRDIFRfjTRXDaETUq3dPHeApcCAwEA AaOCA18wggNbMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSUK0wr DI2kT+SUkmzvXtMaNBtUIzAbBgNVHREEFDASgRBiZW5AZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0g BIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdp Y2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBu AHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABE AGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkA bgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBp AHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIA YQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEF BQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcw AoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAG2NW/zRakbPATZt2m3+Xq7P/YdUzO1R8 6vcG49KkiuNGbExefzzMJnDK67LOzHpuqIyZmbe1ssg8swdenzRsRPoOt9hY7XFwwo8JJxiElddu NPWERMBQWeIPDnfpry3ZC4bMrEPsCsVa0ClPrG2RgGpq5JkPIdgiWngnHyl3ZajiqYca7faWU8eq SDjsyHj6KSF0M9gXhuTjZ20aMA3DZ0exTE2XAYYJUXLSg49szMy28LRW6i0rLfAfx1uNXjGfzdnf gYFRdkdSXqRgdXgCHtSmbAOi077oIvyVeBb2W7P9o+G29sZ/x8bLYoE/K2uliJ8fBAswrsdcirv3 Jqo+fDCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoX DTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sM NP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0Pd Aug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtP QLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9 BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggr BgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIB tQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBl ACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQA dQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBl AHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEA cgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBh AGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAA aABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8w fQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYI KwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVk SURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcN K2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEA hGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOK ZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYC gNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dG OHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qd lWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCA74wggO6AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UE AxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAHv9Jdb6GmlTp/jguOyky8MAkGBSsOAwIaBQCg ggIdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYwOTE2MjQy M1owIwYJKoZIhvcNAQkEMRYEFJxbbkePcn4sMTPhV6YAuc2vU8aSMIGFBgkrBgEEAYI3EAQxeDB2 MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44L jspMvDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3Vy ZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44LjspMvDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFl AwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIA gDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgB ZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQCoqcrdoAEY dDAYF2wcW+RoZiimKo6sgl+knNLNS3zqcTb5vsySpt5LW/9gLg7DjrpqvC6a2vL9QOQMRKTAvOK1 Wx5D1gsOZa1MAiBz4lmZtTjaniv/q+u5ATRneTrZ9yAOy9CUQijqZhsND4ZwJstjSmHMlhMN5Vu2 f63sv7dS9xhCbDTObXP/SjNW+6ivz8k2d5OTC9WLnIOBAYqJ+pEYsK2x164dbmy6CLGyuwJhtdTF FrjQ7RdG1ZvaG9MLK1v/S3GouojzMi39ezPGdEfyEu9D6cb5e9Nvbbp+fy29lASyDDjZmgn2Q5f6 qpAMow15442Ut7AEKG4W8BMx+xitAAAAAAAA ------=_NextPart_000_006F_01CF83CC.FB833200-- From nobody Tue Jun 10 03:24:24 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59E1A0035 for ; Tue, 10 Jun 2014 03:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fPUog_g0SHC for ; Tue, 10 Jun 2014 03:24:20 -0700 (PDT) Received: from ektmail1iron2.euskaltel.es (ektmail1iron2.euskaltel.es [212.142.144.27]) by ietfa.amsl.com (Postfix) with ESMTP id BB2E11A04D2 for ; Tue, 10 Jun 2014 03:24:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAJPcllPUNwh3/2dsb2JhbABZg1+9GoZrUQGBIXWEAwEBAQQBAQEtDAExBAcMBAIBCBEEAQEBCgYXAQYBJh8JCAIFEgiIPgEIyx4TBI47HRQHBoMlgRYBA5ohk0WDPg X-IPAS-Result: AqQEAJPcllPUNwh3/2dsb2JhbABZg1+9GoZrUQGBIXWEAwEBAQQBAQEtDAExBAcMBAIBCBEEAQEBCgYXAQYBJh8JCAIFEgiIPgEIyx4TBI47HRQHBoMlgRYBA5ohk0WDPg X-IronPort-AV: E=Sophos;i="4.98,1008,1392159600"; d="scan'208";a="174618524" Received: from ektmail2mta2.euskaltel.es (HELO correo.euskaltel.es) ([212.55.8.119]) by ektmail1iron2.euskaltel.es with ESMTP; 10 Jun 2014 12:07:59 +0200 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 <0N6Y003YJ7JK9TE0@ektmail2mta2.euskaltel.es> for wpkops@ietf.org; Tue, 10 Jun 2014 12:23:44 +0200 (MEST) Received: from afe01.ejsarea.net (afe01 [10.200.192.14]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id s5AANSAQ011228; Tue, 10 Jun 2014 12:23:44 +0200 Received: from AEX06.ejsarea.net ([10.200.198.17]) by afe01.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jun 2014 10:23:21 +0200 Date: Tue, 10 Jun 2014 10:23:20 +0200 From: i-barreira@izenpe.net In-reply-to: <007301cf83ff$4810e680$d832b380$@digicert.com> To: ben@digicert.com, bruce.morton@entrust.com Message-id: <763539E260C37C46A0D6B340B5434C3B09939C54@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] Preliminary Next Version of Browser Behavior Draft Thread-index: AQHAGq9YUAUY845vOYYDLXX689oZPAIbE3NYATl0SmABw3ilUgIjEPfBAtMvZiMCR6D4R5slGUwggAELenA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org> <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> <763539E260C37C46A0D6B340B5434C3B09939A2F@AEX06.ejsarea.net> <007301cf83ff$4810e680$d832b380$@digicert.com> X-OriginalArrivalTime: 10 Jun 2014 08:23:21.0324 (UTC) FILETIME=[3D6F12C0:01CF8485] Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/TUiDsHCl0s7zmlL-arAIh_s5iVw Cc: wpkops@ietf.org, gerv@mozilla.org, tim.moses@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 10:24:23 -0000 Hi Ben, I=B4ll wait for your proposal but still don=B4t see it as a part of the = trust model. The cryptolibraries are "something" the browsers use to = perform their activities regarding the web PKI but IMHO are not related = on how the browsers (or the OS) accept a CA in their root stores or how = a CA adopt different options. In any case, if this is important for the browser behavior document, as = said, will wait for the proposal and see where this can be added to the = trust model doc. 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: Ben Wilson [mailto:ben@digicert.com]=20 Enviado el: lunes, 09 de junio de 2014 18:24 Para: Barreira Iglesias, I=F1igo; bruce.morton@entrust.com CC: wpkops@ietf.org; gerv@mozilla.org; tim.moses@entrust.com Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft I=F1igo, Yes, the cryptolibraries are functional subcomponents of browsers, so = they ought to be mentioned. Providing the functional introduction will lay = the groundwork for technical background. I'll send you (or post to the IETF site) the next version of the working document on non-revocation = behavior. Cheers, Ben=20 -----Original Message----- From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of i-barreira@izenpe.net Sent: Monday, June 9, 2014 2:29 AM To: ben@digicert.com; bruce.morton@entrust.com Cc: wpkops@ietf.org; gerv@mozilla.org; tim.moses@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, The current text of the trust models document already identifies the way = a browser and a root store provider work together but not the relation = with the crypto libraries. I don=B4t understand your question exactly because = I don=B4t see why these libraries are of interest for a trust model. Do = you mean that a trust model can differ depending on which library is used? The trust model document is more on a "functional" view than a technical one. I need more clarification on what you think to be added 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: Ben Wilson [mailto:ben@digicert.com] Enviado el: viernes, 06 de = junio de 2014 20:48 Para: Barreira Iglesias, I=F1igo; bruce.morton@entrust.com CC: wpkops@ietf.org; 'Gervase Markham'; 'Tim Moses' Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft I=F1igo and Bruce, Perhaps we should revise the Trust Model document to describe how = browser, root store, and cryptolibrary are related? In addressing Gerv's = comments, I am thinking of starting with the following "This document reviews the current processing behaviors of cryptolibraries, and the browsers they support, with respect to SSL/TLS session establishment between a server = and a browser, ..." or something along those lines. Thoughts? Thanks, Ben >-----Original Message----- >From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Gervase=20 >Markham >Sent: Thursday, June 5, 2014 8:10 AM >To: Tim Moses; ben@digicert.com >Cc: wpkops@ietf.org >Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior=20 >Draft > >On 05/06/14 14:37, Tim Moses wrote: >> Hi Ben. We want to move this document to WG draft status. Do you=20 >> want to address Gerv's comments before we hold a ballot? I suggest=20 >> we do that. > >Again, apologies for lack of knowledge of the process, but: the doc is=20 >full of "to be expanded", > "we plan to..." etc. So there will be lots of further change. Is that=20 > what "Draft" means? > >My two examples were two of many; they were actually given to try and=20 >get clarity on the=20 >purpose and goals of the document. If that's written up somewhere, do=20 >point me to it. :-) > >Gerv > > _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From nobody Tue Jun 10 08:53:02 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E391A01A6 for ; Tue, 10 Jun 2014 08:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.953 X-Spam-Level: X-Spam-Status: No, score=-4.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAXFLW_QkJWa for ; Tue, 10 Jun 2014 08:52:59 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 625831A01B6 for ; Tue, 10 Jun 2014 08:52:59 -0700 (PDT) Received: from BWILSONL1 (unknown [67.137.52.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 90F927FA227; Tue, 10 Jun 2014 09:52:58 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1402415578; bh=O17mlYLIiq29ZR8tB3KUAU9d1GSxYGDiEVxtB/CxRC4=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=FXnoq+9oKtyCy3LQ6ffLcflCkagmSAWWUcwiDOWLiz1lMQe3JiMW1yUTkKCPwcVmV h3Ex5621tqBlnHw6pOmTytMVTmNY4Rx3IXs68/LcezXEnAPwIWdtQNcqeiFJHVbnhf Y4ZAtykq7x1qyVZCQwG6w5z1QGTXvcDxG3dY7hak= From: "Ben Wilson" To: , References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <538F795F.3020008@mozilla.org> <5B68A271B9C97046963CB6A5B8D6F62CE819DE1D@SOTTEXCH11.corp.ad.entrust.com> <53907A4C.7070307@mozilla.org> <003701cf81b7$d0cb5ae0$726210a0$@digicert.com> <763539E260C37C46A0D6B340B5434C3B09939A2F@AEX06.ejsarea.net> <007301cf83ff$4810e680$d832b380$@digicert.com> <763539E260C37C46A0D6B340B5434C3B09939C54@AEX06.ejsarea.net> In-Reply-To: <763539E260C37C46A0D6B340B5434C3B09939C54@AEX06.ejsarea.net> Date: Tue, 10 Jun 2014 09:52:53 -0600 Message-ID: <008101cf84c4$0aa1dc30$1fe59490$@digicert.com> X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHAGq9YUAUY845vOYYDLXX689oZPAIbE3NYATl0SmABw3ilUgIjEPfBAtMvZiMCR6D4RwJZZagJAoAuy+aa/9bKQA== Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_007D_01CF8491.BE408EE0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/mWj3d0b6gN3_0iLgWkJMDk-vMNY Cc: wpkops@ietf.org, gerv@mozilla.org, tim.moses@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:53:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007D_01CF8491.BE408EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's now posted here - https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01=20 -----Original Message----- From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of i-barreira@izenpe.net Sent: Tuesday, June 10, 2014 2:23 AM To: ben@digicert.com; bruce.morton@entrust.com Cc: wpkops@ietf.org; gerv@mozilla.org; tim.moses@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, I=B4ll wait for your proposal but still don=B4t see it as a part of the = trust model. The cryptolibraries are "something" the browsers use to perform = their activities regarding the web PKI but IMHO are not related on how the browsers (or the OS) accept a CA in their root stores or how a CA adopt different options. In any case, if this is important for the browser behavior document, as said, will wait for the proposal and see where this can be added to the trust model doc. 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: Ben Wilson [mailto:ben@digicert.com] Enviado el: lunes, 09 de junio = de 2014 18:24 Para: Barreira Iglesias, I=F1igo; bruce.morton@entrust.com CC: wpkops@ietf.org; gerv@mozilla.org; tim.moses@entrust.com Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft I=F1igo, Yes, the cryptolibraries are functional subcomponents of browsers, so = they ought to be mentioned. Providing the functional introduction will lay = the groundwork for technical background. I'll send you (or post to the IETF site) the next version of the working document on non-revocation = behavior. Cheers, Ben=20 -----Original Message----- From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of i-barreira@izenpe.net Sent: Monday, June 9, 2014 2:29 AM To: ben@digicert.com; bruce.morton@entrust.com Cc: wpkops@ietf.org; gerv@mozilla.org; tim.moses@entrust.com Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Hi Ben, The current text of the trust models document already identifies the way = a browser and a root store provider work together but not the relation = with the crypto libraries. I don=B4t understand your question exactly because = I don=B4t see why these libraries are of interest for a trust model. Do = you mean that a trust model can differ depending on which library is used? The trust model document is more on a "functional" view than a technical one. I need more clarification on what you think to be added 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: Ben Wilson [mailto:ben@digicert.com] Enviado el: viernes, 06 de = junio de 2014 20:48 Para: Barreira Iglesias, I=F1igo; bruce.morton@entrust.com CC: wpkops@ietf.org; 'Gervase Markham'; 'Tim Moses' Asunto: RE: [wpkops] Preliminary Next Version of Browser Behavior Draft I=F1igo and Bruce, Perhaps we should revise the Trust Model document to describe how = browser, root store, and cryptolibrary are related? In addressing Gerv's = comments, I am thinking of starting with the following "This document reviews the current processing behaviors of cryptolibraries, and the browsers they support, with respect to SSL/TLS session establishment between a server = and a browser, ..." or something along those lines. Thoughts? Thanks, Ben >-----Original Message----- >From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Gervase=20 >Markham >Sent: Thursday, June 5, 2014 8:10 AM >To: Tim Moses; ben@digicert.com >Cc: wpkops@ietf.org >Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior=20 >Draft > >On 05/06/14 14:37, Tim Moses wrote: >> Hi Ben. We want to move this document to WG draft status. Do you=20 >> want to address Gerv's comments before we hold a ballot? I suggest=20 >> we do that. > >Again, apologies for lack of knowledge of the process, but: the doc is=20 >full of "to be expanded", > "we plan to..." etc. So there will be lots of further change. Is that=20 > what "Draft" means? > >My two examples were two of many; they were actually given to try and=20 >get clarity on the=20 >purpose and goals of the document. If that's written up somewhere, do=20 >point me to it. :-) > >Gerv > > _______________________________________________ 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 ------=_NextPart_000_007D_01CF8491.BE408EE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRRjCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggbBMIIFqaADAgECAhAHv9Jd b6GmlTp/jguOyky8MA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMTAeFw0xMzA2MDMwMDAwMDBaFw0xNjA4MzExMjAwMDBaMHQxCzAJBgNVBAYT AlVTMQ0wCwYDVQQIEwRVdGFoMQ0wCwYDVQQHEwRMZWhpMREwDwYDVQQKEwhEaWdpQ2VydDETMBEG A1UEAxMKQmVuIFdpbHNvbjEfMB0GCSqGSIb3DQEJARMQYmVuQGRpZ2ljZXJ0LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8EX23kpIJWkjmY6Sx23gtdJWUZ7R7xzitGNquNhRQs fVeKvt0/pvRdc+TSKtj58kQ0tQ1BISUuOjr5bB4TeICooUMryRzQ98Qla7SkKwREX6YtySqZl+vj c+JuW0X95Ax0aHjYe13pD+zLHmbGTumwNfxbNi2/j1EeO/tIWml1saD/nMLovWWuChPd0w4Cy4Ex v3Y6Bsl0OEIehbTAw1Mb2kBAioP/6cd70DVgBqrLz8C+kWaIfLpobTwD8/wwrGs0ANtNFx3Dxz8x sfMRHkE140Fkmhf8ogO1M/hne2OzQJUVARLYa15yIDlp5rcRDIFRfjTRXDaETUq3dPHeApcCAwEA AaOCA18wggNbMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSUK0wr DI2kT+SUkmzvXtMaNBtUIzAbBgNVHREEFDASgRBiZW5AZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0g BIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdp Y2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBu AHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABE AGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkA bgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBp AHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIA YQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEF BQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcw AoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAG2NW/zRakbPATZt2m3+Xq7P/YdUzO1R8 6vcG49KkiuNGbExefzzMJnDK67LOzHpuqIyZmbe1ssg8swdenzRsRPoOt9hY7XFwwo8JJxiElddu NPWERMBQWeIPDnfpry3ZC4bMrEPsCsVa0ClPrG2RgGpq5JkPIdgiWngnHyl3ZajiqYca7faWU8eq SDjsyHj6KSF0M9gXhuTjZ20aMA3DZ0exTE2XAYYJUXLSg49szMy28LRW6i0rLfAfx1uNXjGfzdnf gYFRdkdSXqRgdXgCHtSmbAOi077oIvyVeBb2W7P9o+G29sZ/x8bLYoE/K2uliJ8fBAswrsdcirv3 Jqo+fDCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoX DTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sM NP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0Pd Aug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtP QLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9 BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggr BgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIB tQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBl ACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQA dQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBl AHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEA cgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBh AGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAA aABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8w fQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYI KwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVk SURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcN K2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEA hGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOK ZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYC gNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dG OHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qd lWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCA74wggO6AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UE AxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAHv9Jdb6GmlTp/jguOyky8MAkGBSsOAwIaBQCg ggIdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYxMDE1NTI1 MVowIwYJKoZIhvcNAQkEMRYEFDTRAj5YhR+CaHnYaDywixpsoeCYMIGFBgkrBgEEAYI3EAQxeDB2 MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44L jspMvDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3Vy ZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44LjspMvDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFl AwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIA gDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgB ZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQCY/SSm9qUd ryJzJbwkLWD+zOQ8SBWgOn1TR7daqjmT1EkZR+Ogww7jFoio1Q3LOrpwXrXIaJhlzr4AvSRN8mbd mE/hjwky464GgEyDxrhN5b3HzDGwRV/GOW0OTM0d8vKeUqPf9/DKg+qSOgAMJcl9+yxSr7/4QuOp vuQ6G7vwHs3BVooyywUQvLY2Y0mM1FitZfhQi2fvqdZuCReMaL/Vc8BLkT7pvjiHJuBRP9bkR7+v aaCRTSNX/DOFD2eFGKUPaJ+7KX+ui4pfMLSDTmFTW8+hcAwnoLrqtfml+gVr9XtigGQaLkZCFZB5 o/fTKoj5hoFEXW40jdI/blmc0AgEAAAAAAAA ------=_NextPart_000_007D_01CF8491.BE408EE0-- From nobody Tue Jun 10 17:04:05 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AC51A0263 for ; Tue, 10 Jun 2014 17:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.55 X-Spam-Level: X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sq9JM1rz_OQ for ; Tue, 10 Jun 2014 17:04:00 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273071A0311 for ; Tue, 10 Jun 2014 17:04:00 -0700 (PDT) X-AuditID: d80ac3f1-f799e6d0000063ae-a0-53979cef5e85 Received: from tus1smtintpin01.ges.symantec.com (tus1smtintpin01.ges.symantec.com [192.168.215.101]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 1C.C5.25518.FEC97935; Wed, 11 Jun 2014 01:03:59 +0100 (BST) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1WuW1H-0008PK-Ct; Wed, 11 Jun 2014 00:03:59 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Tue, 10 Jun 2014 17:03:59 -0700 From: Rick Andrews To: "ben@digicert.com" , "wpkops@ietf.org" Date: Tue, 10 Jun 2014 17:03:58 -0700 Thread-Topic: [wpkops] Preliminary Next Version of Browser Behavior Draft Thread-Index: AQHAGq9YUAUY845vOYYDLXX689oZPJtzqmBAgBYvSHA= Message-ID: <544B0DD62A64C1448B2DA253C011414607CC475E56@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> In-Reply-To: <059501cf79f0$69ba9060$3d2fb120$@digicert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607CC475E56TUS1XCHEVSPIN_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsVyYMX1VN33c6YHG/zolbXY+/oJq8XNU9tZ HZg89s99yeyxZMlPpgCmKC6blNSczLLUIn27BK6MTzdtC5q9K3433GBsYDzl2MXIySEhYCLx /8IjNghbTOLCvfVANheHkMBHRolFl5cyQjivGCWenTjGCFIlJLCKUWLa/2gQm01AT2LL4yvs ILaIgJ9E39wFYDUsAqoSqzf9YAWxhQU8JJ5M2sQMUeMpMffbYRYI20pi1rLJTCA2r0CUxLVX /6HmZ0t0btkOVsMpYC0x8+p1sOsYga77fmoNWD2zgLjErSfzmSCuFpBYsuc8M4QtKvHy8T9W iHpRiTvt6xkh6vMlvm9fxQqxS1Di5MwnLBMYRWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5m hrHPHHjMhCy+gJF9FaNMSWmxYXFuSX5pSUFqhYGhXnFlbiIw8pL1kvNzNzECo+8G1+GPOxiP 7nU8xCjAwajEw3t5+vRgIdbEMqDKQ4wSHMxKIrw2aUAh3pTEyqrUovz4otKc1OJDjNIcLEri vBk6bcFCAumJJanZqakFqUUwWSYOTqkGxkWih5xW7j789cdXrg8OxdMTP67Zk2ypMu31jJNS YcdlixLORtQfz/u/dK+zzRMHfYaqbp+MWRP3WR3UiQiZuTT3iO/Z/QcSZi1U/n1Ot6XYZp3f 7j/JkkY8F1NdLj7wcFn+tPnVp4MR+SF817UUzjrkcM6LkPbi+f165aRrP52dgq1f3X7wQVKJ pTgj0VCLuag4EQBKBn4vugIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/aLc5PLtfhboxSKBfPE337DalNmk Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 00:04:03 -0000 --_000_544B0DD62A64C1448B2DA253C011414607CC475E56TUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben, I reviewed what I think is the latest draft at https://tools.ietf.org/html/= draft-wilson-wpkops-browser-processing-01, not the Word doc attached to the= previous message. Section 2.1: Is it worth pointing out that root stores are not fixed? Not o= nly can they be extended via automatic download (as you pointed out), but e= nterprises can add and remove roots (as often happens in Windows environmen= ts) and browser users can manually add or remove roots or modify trust bits= . Document readers may not be aware of those other possibilities. Section 2.2: It might be helpful to readers to explain here why Firefox doe= s not do "AIA chasing". In other words, they don't see it as a missing feat= ure; they choose to fail on incomplete chains, and a case can be made as to= why this behavior is preferable to the behavior of other browsers. Or do w= e just want to point out differences among browsers without trying to expla= in why those differences exist (where we understand why)? Section 3.1 The introduction says "This document reviews the current proces= sing behaviors...", but this Section is full of "should"s. I suggest it nee= ds to be rewritten to factually describe current behavior. Section 3.4 seems speculative and not descriptive of current browser behavi= or. Section 3.5 Header is not in bold. Section 4.3 Shouldn't say "browsers should" ;^) -Rick From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson Sent: Tuesday, May 27, 2014 2:13 PM To: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Here is another draft with suggested changes from Santosh accepted, and the= addition of "Security Considerations" subsections, based on our discussion= s of May 13th. From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson Sent: Tuesday, May 13, 2014 9:44 AM To: wpkops@ietf.org Subject: [wpkops] Preliminary Next Version of Browser Behavior Draft Here is a first pass through the browser behavior document that I sent to R= obin and Santosh yesterday. --_000_544B0DD62A64C1448B2DA253C011414607CC475E56TUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ben,

 

= I reviewed what I think is the latest draft at https://tools.ietf.or= g/html/draft-wilson-wpkops-browser-processing-01, not the Word doc atta= ched to the previous message.

&n= bsp;

Section 2.1: Is it worth pointing out= that root stores are not fixed? Not only can they be extended via automati= c download (as you pointed out), but enterprises can add and remove roots (= as often happens in Windows environments) and browser users can manually ad= d or remove roots or modify trust bits. Document readers may not be aware o= f those other possibilities.

&nb= sp;

Section 2.2: It might be helpful to re= aders to explain here why Firefox does not do "AIA chasing". In o= ther words, they don't see it as a missing feature; they choose to fail on = incomplete chains, and a case can be made as to why this behavior is prefer= able to the behavior of other browsers. Or do we just want to point out dif= ferences among browsers without trying to explain why those differences exi= st (where we understand why)?

&n= bsp;

Section 3.1 The introduction says &qu= ot;This document reviews the current processing behaviors...", but thi= s Section is full of "should"s. I suggest it needs to be rewritte= n to factually describe current behavior.

 

Section 3.4 seems specula= tive and not descriptive of current browser behavior.

 

Section 3.5 H= eader is not in bold.

 

Section 4.3 Shouldn’t say “browse= rs should” ;^)

 

-Rick=

 

Fro= m: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilso= n
Sent: Tuesday, May 27, 2014 2:13 PM
To: wpkops@ietf.o= rg
Subject: Re: [wpkops] Preliminary Next Version of Browser Beha= vior Draft

 

Here is another draft with suggest= ed changes from Santosh accepted, and the addition of “Security Consi= derations” subsections, based on our discussions of May 13th.

<= span style=3D'color:#1F497D'> 

 

= From:= wpkops [mailto:wpkops-bounce= s@ietf.org] On Behalf Of Ben Wilson
Sent: Tuesday, May= 13, 2014 9:44 AM
To: wpkops@i= etf.org
Subject: [wpkops] Preliminary Next Version of Browser= Behavior Draft

 

Here is a first pass through the browser behavior document = that I sent to Robin and Santosh yesterday.

= --_000_544B0DD62A64C1448B2DA253C011414607CC475E56TUS1XCHEVSPIN_-- From nobody Tue Jun 10 19:42:03 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF701A0644 for ; Tue, 10 Jun 2014 19:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqpxO8zGpU_P for ; Tue, 10 Jun 2014 19:41:48 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD591A063A for ; Tue, 10 Jun 2014 19:41:48 -0700 (PDT) Received: from BWILSONL1 (c-98-202-216-177.hsd1.ut.comcast.net [98.202.216.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 7AE347FA3F6; Tue, 10 Jun 2014 20:41:47 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1402454507; bh=OhxilSo/OQckYwCBaoTP+6UzLYHuac9hjTq0D2mBNXQ=; h=From:To:References:In-Reply-To:Subject:Date; b=kkXdFeeS9jgATD3oj0YRuktDuIFIkUmYLYsy6p7zfbN6GPV53zcGZT4VhFKlio5Ff 4lpXdczAyTUycBzV3zsCx+ofs1e8Yp/y+bjs2nKq3vxqXTol7oimqjklXxj3ENgY4H qOdakt837rrUm2QIiS6BGvBLOjtIhKnD9Ttz2EeE= From: "Ben Wilson" To: "'Rick Andrews'" , References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <544B0DD62A64C1448B2DA253C011414607CC475E56@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CC475E56@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Tue, 10 Jun 2014 20:41:42 -0600 Message-ID: <00e901cf851e$ade87700$09b96500$@digicert.com> X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Thread-Index: AQHAGq9YUAUY845vOYYDLXX689oZPAIbE3NYAoEjYvibZSDHkA== Content-Language: en-us Content-Type: multipart/signed; boundary="----=_NextPart_000_00E1_01CF84EC.62BB15D0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/iSQvHhRPNJNY8DQTTlT857mPKs8 Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 02:41:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E1_01CF84EC.62BB15D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E2_01CF84EC.62BB15D0" ------=_NextPart_001_00E2_01CF84EC.62BB15D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks, Rick. I can add more about the dynamic nature of some root stores to Section 2.1. In 2.2, I wasn't sure what to say because I didn't think I should speak for Mozilla, even though it's been explained to me that those responsible for NSS/Firefox prefer a click through failure because it may tend to alert the server administrator that there is a problem and they need to install a chain properly. In order to say that, I think someone needs to point me to an official statement of that rationale so that I can reference it officially. In 3.1 and beyond, I'll make those replacements of "should" like I did above in Section 2. In Section 3.4, I can tone down the security concerns a bit, but the problem is that the statements are true in a generic sense. Basically, I am trying to take advice from the last telephone call we had and hit the security concerns, e.g., "why do we care?" or, in other words, what is significant about each particular category of behavior, and why did PKIX frame the security design as such? Are you saying that because I do not reveal a specific zero-day threat that I've observed, I'm therefore precluded from mentioning how that latent vulnerability might be exploited? I can make it more clear that we're addressing the generic issues and not the specifics, if that helps. Thanks again for your review and comments-they do help - significantly. Cheers, Ben From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Rick Andrews Sent: Tuesday, June 10, 2014 6:04 PM To: ben@digicert.com; wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Ben, I reviewed what I think is the latest draft at https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, not the Word doc attached to the previous message. Section 2.1: Is it worth pointing out that root stores are not fixed? Not only can they be extended via automatic download (as you pointed out), but enterprises can add and remove roots (as often happens in Windows environments) and browser users can manually add or remove roots or modify trust bits. Document readers may not be aware of those other possibilities. Section 2.2: It might be helpful to readers to explain here why Firefox does not do "AIA chasing". In other words, they don't see it as a missing feature; they choose to fail on incomplete chains, and a case can be made as to why this behavior is preferable to the behavior of other browsers. Or do we just want to point out differences among browsers without trying to explain why those differences exist (where we understand why)? Section 3.1 The introduction says "This document reviews the current processing behaviors...", but this Section is full of "should"s. I suggest it needs to be rewritten to factually describe current behavior. Section 3.4 seems speculative and not descriptive of current browser behavior. Section 3.5 Header is not in bold. Section 4.3 Shouldn't say "browsers should" ;^) -Rick From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson Sent: Tuesday, May 27, 2014 2:13 PM To: wpkops@ietf.org Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft Here is another draft with suggested changes from Santosh accepted, and the addition of "Security Considerations" subsections, based on our discussions of May 13th. From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson Sent: Tuesday, May 13, 2014 9:44 AM To: wpkops@ietf.org Subject: [wpkops] Preliminary Next Version of Browser Behavior Draft Here is a first pass through the browser behavior document that I sent to Robin and Santosh yesterday. ------=_NextPart_001_00E2_01CF84EC.62BB15D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Rick. 

I can add more about the = dynamic nature of some root stores to Section = 2.1.

In 2.2, I wasn’t sure what to say because = I didn’t think I should speak for Mozilla, even though it’s = been explained to me that those responsible for NSS/Firefox prefer a = click through failure because it may tend to alert the server = administrator that there is a problem and they need to install a chain = properly.  In order to say that, I think someone needs to point me = to an official statement of that rationale so that I can reference it = officially.

In 3.1 and beyond, I’ll make those = replacements of “should” like I did above in Section = 2.   

In Section 3.4, I can tone down the security = concerns a bit, but the problem is that the statements are true in a = generic sense.  Basically, I am trying to take advice from the last = telephone call we had and hit the security concerns, e.g., “why do = we care?” or, in other words, what is significant about each = particular category of behavior, and why did PKIX frame the security = design as such?  Are you saying that because I do not reveal a = specific zero-day threat that I’ve observed, I’m therefore = precluded from mentioning how that latent vulnerability might be = exploited?  I can make it more clear that we’re addressing = the generic issues and not the specifics, if that = helps.

Thanks again for your review and = comments—they do help - significantly.

Cheers,

Ben

 

From:= = wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Rick = Andrews
Sent: Tuesday, June 10, 2014 6:04 PM
To: = ben@digicert.com; wpkops@ietf.org
Subject: Re: [wpkops] = Preliminary Next Version of Browser Behavior = Draft

 

Ben,

 

I = reviewed what I think is the latest draft at https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-= 01, not the Word doc attached to the previous = message.

 

Section 2.1: Is it worth pointing out that root = stores are not fixed? Not only can they be extended via automatic = download (as you pointed out), but enterprises can add and remove roots = (as often happens in Windows environments) and browser users can = manually add or remove roots or modify trust bits. Document readers may = not be aware of those other possibilities.

 

Section 2.2: It might be helpful to readers to = explain here why Firefox does not do "AIA chasing". In other = words, they don't see it as a missing feature; they choose to fail on = incomplete chains, and a case can be made as to why this behavior is = preferable to the behavior of other browsers. Or do we just want to = point out differences among browsers without trying to explain why those = differences exist (where we understand why)?

 

Section 3.1 The introduction says "This = document reviews the current processing behaviors...", but this = Section is full of "should"s. I suggest it needs to be = rewritten to factually describe current behavior.

 

Section 3.4 seems speculative and not descriptive = of current browser behavior.

 

Section 3.5 Header is not in bold.

 

Section 4.3 Shouldn’t say “browsers = should” ;^)

 

-Rick

 

From:= = wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson
Sent: Tuesday, May 27, 2014 = 2:13 PM
To: wpkops@ietf.org
Subject: = Re: [wpkops] Preliminary Next Version of Browser Behavior = Draft

 

Here is another = draft with suggested changes from Santosh accepted, and the addition of = “Security Considerations” subsections, based on our = discussions of May 13th.

 

 

From:= = wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson
Sent: Tuesday, May 13, 2014 = 9:44 AM
To: wpkops@ietf.org
Subject: = [wpkops] Preliminary Next Version of Browser Behavior = Draft

 

Here is a first pass through the browser = behavior document that I sent to Robin and Santosh = yesterday.

------=_NextPart_001_00E2_01CF84EC.62BB15D0-- ------=_NextPart_000_00E1_01CF84EC.62BB15D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRRjCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggbBMIIFqaADAgECAhAHv9Jd b6GmlTp/jguOyky8MA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMTAeFw0xMzA2MDMwMDAwMDBaFw0xNjA4MzExMjAwMDBaMHQxCzAJBgNVBAYT AlVTMQ0wCwYDVQQIEwRVdGFoMQ0wCwYDVQQHEwRMZWhpMREwDwYDVQQKEwhEaWdpQ2VydDETMBEG A1UEAxMKQmVuIFdpbHNvbjEfMB0GCSqGSIb3DQEJARMQYmVuQGRpZ2ljZXJ0LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8EX23kpIJWkjmY6Sx23gtdJWUZ7R7xzitGNquNhRQs fVeKvt0/pvRdc+TSKtj58kQ0tQ1BISUuOjr5bB4TeICooUMryRzQ98Qla7SkKwREX6YtySqZl+vj c+JuW0X95Ax0aHjYe13pD+zLHmbGTumwNfxbNi2/j1EeO/tIWml1saD/nMLovWWuChPd0w4Cy4Ex v3Y6Bsl0OEIehbTAw1Mb2kBAioP/6cd70DVgBqrLz8C+kWaIfLpobTwD8/wwrGs0ANtNFx3Dxz8x sfMRHkE140Fkmhf8ogO1M/hne2OzQJUVARLYa15yIDlp5rcRDIFRfjTRXDaETUq3dPHeApcCAwEA AaOCA18wggNbMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSUK0wr DI2kT+SUkmzvXtMaNBtUIzAbBgNVHREEFDASgRBiZW5AZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQE AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwfQYDVR0fBHYwdDA4oDagNIYyaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0g BIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdp Y2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBu AHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABE AGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkA bgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBp AHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIA YQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEF BQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcw AoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAG2NW/zRakbPATZt2m3+Xq7P/YdUzO1R8 6vcG49KkiuNGbExefzzMJnDK67LOzHpuqIyZmbe1ssg8swdenzRsRPoOt9hY7XFwwo8JJxiElddu NPWERMBQWeIPDnfpry3ZC4bMrEPsCsVa0ClPrG2RgGpq5JkPIdgiWngnHyl3ZajiqYca7faWU8eq SDjsyHj6KSF0M9gXhuTjZ20aMA3DZ0exTE2XAYYJUXLSg49szMy28LRW6i0rLfAfx1uNXjGfzdnf gYFRdkdSXqRgdXgCHtSmbAOi077oIvyVeBb2W7P9o+G29sZ/x8bLYoE/K2uliJ8fBAswrsdcirv3 Jqo+fDCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkG A1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoX DTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sM NP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0Pd Aug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtP QLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9 BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggr BgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIB tQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBl ACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQA dQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBl AHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEA cgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBh AGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAA aABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8w fQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYI KwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVk SURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20v RGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcN K2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEA hGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOK ZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYC gNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dG OHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qd lWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCA74wggO6AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UE AxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAHv9Jdb6GmlTp/jguOyky8MAkGBSsOAwIaBQCg ggIdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDYxMTAyNDE0 MlowIwYJKoZIhvcNAQkEMRYEFAmNoMtDNU83rqTAekJAb/b8ViDQMIGFBgkrBgEEAYI3EAQxeDB2 MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44L jspMvDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3Vy ZWQgSUQgQ0EtMQIQB7/SXW+hppU6f44LjspMvDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFl AwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIA gDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgB ZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQCt5uvBTgCs 0H3EzvexCMCyPJQoQ+kaJb09TS0vEDkzRPPuS/2JHWVfpVBYv/KJBtHJHuKmeTHk0kiYIQsowbwN dvN6Zues2MY1mQzoEeyFUvJfjolE6qLxOUNf3jJ82dsDgpKXv7dpvx/QpfPTbTS4RdnXH1oI04J3 cdqhQn9PrsWjJZJIzrP2tkK+g/KWBAttgWt1OozjcJwzPr81RMbGwVGS9oV2bWcazE3fsz/CVV5W KN6G/my+o4s5cmV1FltPCXBdRu1RA8ldIIDXVs2VyMVi0qLADUNZtz3kOqjAQSitnn+1568m8v67 LA/gYOa7dwskKCf8bfHVHVO54jaRAAAAAAAA ------=_NextPart_000_00E1_01CF84EC.62BB15D0-- From nobody Wed Jun 11 07:27:23 2014 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA96B1A011E for ; Wed, 11 Jun 2014 07:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqeD1vcTi42G for ; Wed, 11 Jun 2014 07:27:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FB61A010D for ; Wed, 11 Jun 2014 07:27:20 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54986) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WujUp-0002by-9w for wpkops@ietf.org; Wed, 11 Jun 2014 10:27:30 -0400 Message-ID: <5398673F.30300@bbn.com> Date: Wed, 11 Jun 2014 10:27:11 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: wpkops@ietf.org References: <001901cf6ec2$376461b0$a62d2510$@digicert.com> <059501cf79f0$69ba9060$3d2fb120$@digicert.com> <544B0DD62A64C1448B2DA253C011414607CC475E56@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CC475E56@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Content-Type: multipart/alternative; boundary="------------050600080300020902010705" Archived-At: http://mailarchive.ietf.org/arch/msg/wpkops/yVl3g0UdfeRFSD-UYIIpnnLMzxA Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:27:22 -0000 This is a multi-part message in MIME format. --------------050600080300020902010705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 As some other have already said, the charter of the WG calls for documenting current Web PKI practices, not describing what one might wish were true. Steve > > Ben, > > I reviewed what I think is the latest draft at > https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, > not the Word doc attached to the previous message. > > Section 2.1: Is it worth pointing out that root stores are not fixed? > Not only can they be extended via automatic download (as you pointed > out), but enterprises can add and remove roots (as often happens in > Windows environments) and browser users can manually add or remove > roots or modify trust bits. Document readers may not be aware of those > other possibilities. > > Section 2.2: It might be helpful to readers to explain here why > Firefox does not do "AIA chasing". In other words, they don't see it > as a missing feature; they choose to fail on incomplete chains, and a > case can be made as to why this behavior is preferable to the behavior > of other browsers. Or do we just want to point out differences among > browsers without trying to explain why those differences exist (where > we understand why)? > > Section 3.1 The introduction says "This document reviews the current > processing behaviors...", but this Section is full of "should"s. I > suggest it needs to be rewritten to factually describe current behavior. > > Section 3.4 seems speculative and not descriptive of current browser > behavior. > > Section 3.5 Header is not in bold. > > Section 4.3 Shouldn't say "browsers should" ;^) > > -Rick > > *From:*wpkops [mailto:wpkops-bounces@ietf.org] *On Behalf Of *Ben Wilson > *Sent:* Tuesday, May 27, 2014 2:13 PM > *To:* wpkops@ietf.org > *Subject:* Re: [wpkops] Preliminary Next Version of Browser Behavior Draft > > Here is another draft with suggested changes from Santosh accepted, > and the addition of "Security Considerations" subsections, based on > our discussions of May 13^th . > > *From:*wpkops [mailto:wpkops-bounces@ietf.org] *On Behalf Of *Ben Wilson > *Sent:* Tuesday, May 13, 2014 9:44 AM > *To:* wpkops@ietf.org > *Subject:* [wpkops] Preliminary Next Version of Browser Behavior Draft > > Here is a first pass through the browser behavior document that I sent > to Robin and Santosh yesterday. > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops --------------050600080300020902010705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

As some other have already said, the charter of the WG calls for documenting current
Web PKI practices, not describing what one might wish were true.

Steve

Ben,

 

I reviewed what I think is the latest draft at https://tools.ietf.org/html/draft-wilson-wpkops-browser-processing-01, not the Word doc attached to the previous message.

 

Section 2.1: Is it worth pointing out that root stores are not fixed? Not only can they be extended via automatic download (as you pointed out), but enterprises can add and remove roots (as often happens in Windows environments) and browser users can manually add or remove roots or modify trust bits. Document readers may not be aware of those other possibilities.

 

Section 2.2: It might be helpful to readers to explain here why Firefox does not do "AIA chasing". In other words, they don't see it as a missing feature; they choose to fail on incomplete chains, and a case can be made as to why this behavior is preferable to the behavior of other browsers. Or do we just want to point out differences among browsers without trying to explain why those differences exist (where we understand why)?

 

Section 3.1 The introduction says "This document reviews the current processing behaviors...", but this Section is full of "should"s. I suggest it needs to be rewritten to factually describe current behavior.

 

Section 3.4 seems speculative and not descriptive of current browser behavior.

 

Section 3.5 Header is not in bold.

 

Section 4.3 Shouldn’t say “browsers should” ;^)

 

-Rick

 

From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson
Sent: Tuesday, May 27, 2014 2:13 PM
To: wpkops@ietf.org
Subject: Re: [wpkops] Preliminary Next Version of Browser Behavior Draft

 

Here is another draft with suggested changes from Santosh accepted, and the addition of “Security Considerations” subsections, based on our discussions of May 13th.

 

 

From: wpkops [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson
Sent: Tuesday, May 13, 2014 9:44 AM
To: wpkops@ietf.org
Subject: [wpkops] Preliminary Next Version of Browser Behavior Draft

 

Here is a first pass through the browser behavior document that I sent to Robin and Santosh yesterday.



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

--------------050600080300020902010705--