From tim.moses@entrust.com Thu Nov 1 13:58:46 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E72E21F8DDB for ; Thu, 1 Nov 2012 13:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSY5jJVISnxc for ; Thu, 1 Nov 2012 13:58:46 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6A21F8D76 for ; Thu, 1 Nov 2012 13:58:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,695,1344225600"; d="scan'208,217";a="6701123" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 01 Nov 2012 16:58:32 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Thu, 1 Nov 2012 16:58:31 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: BoF presentations Thread-Index: Ac24c6bo9+dqSLnhRg6JC4op+sMnTQ== Date: Thu, 1 Nov 2012 20:58:31 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A60849D@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62C3A60849DSOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] BoF presentations X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 20:58:46 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A60849DSOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues - The BoF presentations are available here. https://pub.ietf.org/proceedings/85/wpkops/ All the best. Tim. T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A60849DSOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues – The BoF presentations are availab= le here.

 

https://pub.ietf.org/proceedings/85/wpkops/

 

All the best.  Tim.

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A60849DSOTTEXCH10corpa_-- From shanna@juniper.net Thu Nov 1 14:28:14 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781E321F8B3E for ; Thu, 1 Nov 2012 14:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7-lApseb+20 for ; Thu, 1 Nov 2012 14:28:13 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5159C21F88FA for ; Thu, 1 Nov 2012 14:28:13 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUJLpbFS5i4o1ergbMoue65HMFyb0T3gZ@postini.com; Thu, 01 Nov 2012 14:28:13 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 1 Nov 2012 14:26:05 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 1 Nov 2012 14:26:05 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 1 Nov 2012 14:27:54 -0700 Received: from mail144-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 21:26:05 +0000 Received: from mail144-co1 (localhost [127.0.0.1]) by mail144-co1-R.bigfish.com (Postfix) with ESMTP id EC5B1CA04A6 for ; Thu, 1 Nov 2012 21:26:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic85fh4015Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received: from mail144-co1 (localhost.localdomain [127.0.0.1]) by mail144-co1 (MessageSwitch) id 1351805162773932_559; Thu, 1 Nov 2012 21:26:02 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.243]) by mail144-co1.bigfish.com (Postfix) with ESMTP id B9440C80048; Thu, 1 Nov 2012 21:26:02 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 21:26:01 +0000 Received: from BY2PRD0510MB366.namprd05.prod.outlook.com ([169.254.6.143]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0233.002; Thu, 1 Nov 2012 21:25:56 +0000 From: Stephen Hanna To: Tim Moses , "wpkops@ietf.org" Thread-Topic: BoF presentations Thread-Index: Ac24c6bo9+dqSLnhRg6JC4op+sMnTQAA732w Date: Thu, 1 Nov 2012 21:25:55 +0000 Message-ID: References: <5B68A271B9C97046963CB6A5B8D6F62C3A60849D@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A60849D@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_F1DFC16DCAA7D3468651A5A776D5796E01FF9C47BY2PRD0510MB366_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ENTRUST.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [wpkops] BoF presentations X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:28:14 -0000 --_000_F1DFC16DCAA7D3468651A5A776D5796E01FF9C47BY2PRD0510MB366_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That link didn't work for me. It seems to require a login that I don't have= . Try this URL instead: https://datatracker.ietf.org/meeting/85/materials.html#session.group-wpkops The presentations are there in PDF format. No login required. Thanks, Steve From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Tim Moses Sent: Thursday, November 01, 2012 4:59 PM To: wpkops@ietf.org Subject: [wpkops] BoF presentations Colleagues - The BoF presentations are available here. https://pub.ietf.org/proceedings/85/wpkops/ All the best. Tim. T: +1 613 270 3183 --_000_F1DFC16DCAA7D3468651A5A776D5796E01FF9C47BY2PRD0510MB366_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That link didn’t= work for me. It seems to require a login that I don’t have. Try this= URL instead:

 

https://d= atatracker.ietf.org/meeting/85/materials.html#session.group-wpkops=

 

The presentations are = there in PDF format. No login required.

 

Thanks,

 

Steve

 

From: wpkops-b= ounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses
Sent: Thursday, November 01, 2012 4:59 PM
To: wpkops@ietf.org
Subject: [wpkops] BoF presentations

 

Colleagues – The BoF presentations are availab= le here.

 

https://pub.ietf.org/proceedings/85/wpkops/

 

All the best.  Tim.

 

T: +1 613 270 3183

 

--_000_F1DFC16DCAA7D3468651A5A776D5796E01FF9C47BY2PRD0510MB366_-- From jeff.hodges@paypal-inc.com Thu Nov 1 14:30:44 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7683221F95FD for ; Thu, 1 Nov 2012 14:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3foscDfUw4Ag for ; Thu, 1 Nov 2012 14:30:43 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 9413621F93B0 for ; Thu, 1 Nov 2012 14:30:43 -0700 (PDT) DomainKey-Signature: s=paypalcorp; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=GniuIl1i3IqMR4jd0jB9cK2PRLCNwrFsisT+m5HQGlH4847eeq2E1qLI B9p1MhZICBrLcsjNwwbaMhDu3LPTUgGZwyQU3Q7N9YiFhkD6mTSNL76cN cPogmg/ljXj5USTgFBCsBz9UQrsMQ0cp/1WN4MD4oPgFWWdzmE8jLAP1l 8=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=jeff.hodges@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1351805443; x=1383341443; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6pnS3DCBEwe3R/Um86lJkjozszlxl8N66//4vnalv2Y=; b=I71w9yHbkRbreQLoype8N02IN3T5gqbT3Ee2SicI+m0P5HpNnOybMo2V 9xre9+YgO5FNU1RQV/90xMLNnn7P9gxbBAuuL6+ifPi9K48hPciW60cS9 sKxoLqbEGbFp/6nYSP3DKLaes9tC7Ws1wESaVZL08PhQUEwAw12wI9a0u w=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,695,1344236400"; d="scan'208";a="11112854" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 01 Nov 2012 14:30:43 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-001.corp.ebay.com ([fe80::345e:2420:7d3d:208d%13]) with mapi id 14.02.0318.004; Thu, 1 Nov 2012 15:30:42 -0600 From: "Hodges, Jeff" To: Tim Moses , "wpkops@ietf.org" Thread-Topic: BoF presentations Thread-Index: Ac24c6bo9+dqSLnhRg6JC4op+sMnTQAA33zA Date: Thu, 1 Nov 2012 21:30:42 +0000 Message-ID: References: <5B68A271B9C97046963CB6A5B8D6F62C3A60849D@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A60849D@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [wpkops] BoF presentations X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 21:30:44 -0000 > Colleagues - The BoF presentations are available here. >=20 > https://pub.ietf.org/proceedings/85/wpkops/ Hm, that link is perhaps just for managing the session materials, it says t= o me.. A username and password are being requested by https://pub.ietf.org.= =20 The site says: "IETF Secretariat Dashboard" But if you go here..=20 https://datatracker.ietf.org/meeting/85/materials.html ..and search for "wpkops", they appear to be there. HTH,=20 =3DJeffH From tim.moses@entrust.com Fri Nov 2 11:05:44 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301F51F0C5C for ; Fri, 2 Nov 2012 11:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af63sZFosguH for ; Fri, 2 Nov 2012 11:05:43 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16F21F93A0 for ; Fri, 2 Nov 2012 11:05:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,701,1344225600"; d="scan'208";a="2319162" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 02 Nov 2012 14:05:36 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Fri, 2 Nov 2012 14:05:36 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: Document editors Thread-Index: Ac25JKhCgxZdcdMPQNW8+UQ3C3y1lw== Date: Fri, 2 Nov 2012 18:05:35 +0000 Message-ID: <5CBEC170-4666-4EF4-AF6D-970D33D4BE69@bwdldb.pp.bnr.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <8ECA4F17D041CF4DA8644B0A938B4EA8@entrust.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [wpkops] Document editors X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:05:44 -0000 Q29sbGVhZ3VlcyAtIEhlcmUgaXMgdGhlIGN1cnJlbnQgbGlzdCBvZiB2b2x1bnRlZXJzIHRvIGVk aXQgV1BLT1BTIGRyYWZ0cy4NCg0KVHJ1c3QgbW9kZWwgLSBJw7FpZ28gQmFycmVpcmEsIEJydWNl IE1vcnRvbg0KQ2VydGlmaWNhdGUsIENSTCwgYW5kIE9DU1AgZmllbGQgYW5kIGV4dGVuc2lvbg0K ICAgICBwcm9jZXNzaW5nIC0gQmVuIFdpbHNvbiwgUm9iaW4gQWxkZW4NClJldm9jYXRpb24gLSBQ aGlsbGlwIEhhbGxlbS1CYWtlcg0KVExTIHN0YWNrIG9wZXJhdGlvbiAtIEFkYW0gTGFuZ2xleSA= From melinda.shore@gmail.com Mon Nov 5 09:21:11 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9391B21F87EE for ; Mon, 5 Nov 2012 09:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6VE2HrVpl43 for ; Mon, 5 Nov 2012 09:21:11 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1827121F880C for ; Mon, 5 Nov 2012 09:21:11 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so4063131pbb.31 for ; Mon, 05 Nov 2012 09:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=bzWAlzryxI1ysjR8xNHiKIb5TLA1dKmwJ187wCVhF8w=; b=Bw8fycg1tJohEhXXpOWaz6srggMFnyuZsEmrUn8JaLBEdE1RancSN2cnIvJAijsGzd yDwv4sT8x5ZNaOGRRQu2U1hmAZzMTj7Si5Juo9UyFPed3Gs1sCVf+WHX4lv0fnmMFCYA HfXfeMu58QwdFwFQRlCbvRrOdmKVUke938WbykbS3ys1cnTkEt0LutPs61urtih6AvFu +I3F0VOCtydKuNBKiIQofYb4i9nI8JJCAxVf2w8eCKdUz595mxsID8FQmb0QBX7E1rBZ mYKFk4qTHhgAAzTVTiwoWCmOYP80J3bQLx+p7eBWxerDoYcxFqLWbgbYLiWDAFtZpI3v JQQg== Received: by 10.68.236.8 with SMTP id uq8mr31834362pbc.156.1352136070877; Mon, 05 Nov 2012 09:21:10 -0800 (PST) Received: from ?IPv6:2001:df8:0:64:3cc3:7d59:19f:c380? ([2001:df8:0:64:3cc3:7d59:19f:c380]) by mx.google.com with ESMTPS id v9sm10933908paz.6.2012.11.05.09.21.09 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 09:21:10 -0800 (PST) Message-ID: <5097F585.7070301@gmail.com> Date: Mon, 05 Nov 2012 08:21:09 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: wpkops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [wpkops] Jabber scribe for bof? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:21:11 -0000 Unfortunately I've got a conflict and can't be at the BoF this afternoon. Would it be possible to make sure that there's a Jabber scribe? Thanks, Melinda From bhill@paypal-inc.com Mon Nov 5 09:36:51 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FC521F88C8 for ; Mon, 5 Nov 2012 09:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmGwCX8+W1xa for ; Mon, 5 Nov 2012 09:36:49 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8019621F867A for ; Mon, 5 Nov 2012 09:36:49 -0800 (PST) DomainKey-Signature: s=paypalcorp; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=Iv/j1huIafuqp3H0Y+u3E36s0mun1M1c9nwWQmvE/OsEpO0x5HGSQYAI GtF+xF6MJZQV7ZrzY6a5hJF/6SnWLgklOC/WayFGUrad39/BTk2VyniNT 0zbx6KjNUv6q9AdyxsCH1ko90rrViceUQT/upOusP31s2BndY5Ido6I+7 4=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1352137009; x=1383673009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vERJ8YdWrsTmkIKrTWjmmtwLM2aNVSNg//I/0pOQG7w=; b=OVSP3kv6hDS51jH//UQrqXRApLybrd5kmryZKu7+pTl8mSOvPqWlQltL xMRFY8x1QbG6GzwYliZToJgkZWgAjDbKx9RxHOdAHpb3jdmgtSgYhlRgc gZfXPWxRh4z2DPZ/taocv3qTIaxp9rNNiwrA/lhWJGtZIdT6/aKOgK5UM U=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,715,1344236400"; d="scan'208";a="10663202" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 05 Nov 2012 09:36:49 -0800 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-001.corp.ebay.com ([fe80::345e:2420:7d3d:208d%13]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 10:36:48 -0700 From: "Hill, Brad" To: Melinda Shore Thread-Topic: [wpkops] Jabber scribe for bof? Thread-Index: AQHNu3n+R5AVUQoDP0yV0EBvKGzP9ZfbgU/C Date: Mon, 5 Nov 2012 17:36:48 +0000 Message-ID: References: <5097F585.7070301@gmail.com> In-Reply-To: <5097F585.7070301@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Jabber scribe for bof? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:36:51 -0000 I will jabber scribe. Brad Hill On Nov 5, 2012, at 12:21 PM, "Melinda Shore" wrot= e: > Unfortunately I've got a conflict and can't be at the BoF > this afternoon. Would it be possible to make sure that there's > a Jabber scribe? >=20 > Thanks, >=20 > Melinda > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops From ynir@checkpoint.com Mon Nov 5 09:43:38 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54AE21F86DA for ; Mon, 5 Nov 2012 09:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh3yUdgmEf6U for ; Mon, 5 Nov 2012 09:43:37 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E2C2C21F8962 for ; Mon, 5 Nov 2012 09:43:36 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qA5HhYEa006988; Mon, 5 Nov 2012 19:43:34 +0200 X-CheckPoint: {5097F824-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 5 Nov 2012 19:43:33 +0200 From: Yoav Nir To: Melinda Shore Date: Mon, 5 Nov 2012 19:43:33 +0200 Thread-Topic: [wpkops] Jabber scribe for bof? Thread-Index: Ac27fRMwjQUwTsZFSSe7UWdXiqJfKg== Message-ID: <67FCDB9B-CE00-4126-BA35-4728577B7816@checkpoint.com> References: <5097F585.7070301@gmail.com> In-Reply-To: <5097F585.7070301@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Jabber scribe for bof? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:43:38 -0000 On Nov 5, 2012, at 12:21 PM, Melinda Shore wrote: > Unfortunately I've got a conflict and can't be at the BoF > this afternoon. Would it be possible to make sure that there's > a Jabber scribe? If a volunteer is needed, I'm willing. From melinda.shore@gmail.com Mon Nov 5 09:47:35 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A146721F842E for ; Mon, 5 Nov 2012 09:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsU65UVEm+jA for ; Mon, 5 Nov 2012 09:47:35 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2AA21F842D for ; Mon, 5 Nov 2012 09:47:35 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2773807dan.31 for ; Mon, 05 Nov 2012 09:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4sjk03MoMYu+sgJV8GsSC2lZlbx0HxHc08s1b3TsB8w=; b=WGaskUHEf+2AWU6uAEuSV+gKbUutFGjALjq1igEqwU3GBdoQPPvvJt2592vWyjGW7C lWlIOQ814GOC6XSai8IdwuRS8D748Pe0qgTTY+MU7FvWkSCoqtMix4I22PsLRxSzB1i3 NbDmfDezBoSDfjcaAbZOYHG7nlzmMU3+dLW4q1CNq+lioMAdtHxVM8hyzvb0Uh4KKnI8 1F4Df4As7W4Uw07yW3efJSdHsdQ3ilUH0XOr8DqjTtTEBXpOnClCky2yUWe35pm886Tm DjDin78MTbf4+MyLxQA/IT8L0w1nSzapaGCqDA0//oJI5wni3y+5PqSon5P2kpjmqUTz 80FA== Received: by 10.66.79.168 with SMTP id k8mr30504478pax.12.1352137655036; Mon, 05 Nov 2012 09:47:35 -0800 (PST) Received: from ?IPv6:2001:df8:0:64:3cc3:7d59:19f:c380? ([2001:df8:0:64:3cc3:7d59:19f:c380]) by mx.google.com with ESMTPS id o1sm10955030paz.34.2012.11.05.09.47.31 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2012 09:47:34 -0800 (PST) Message-ID: <5097FBB2.1000802@gmail.com> Date: Mon, 05 Nov 2012 08:47:30 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "wpkops@ietf.org" References: <5097F585.7070301@gmail.com> <67FCDB9B-CE00-4126-BA35-4728577B7816@checkpoint.com> In-Reply-To: <67FCDB9B-CE00-4126-BA35-4728577B7816@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [wpkops] Jabber scribe for bof? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:47:35 -0000 Many thanks! Melinda From tim.moses@entrust.com Fri Nov 9 07:21:44 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92D721F8715 for ; Fri, 9 Nov 2012 07:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZFTgdba8O0K for ; Fri, 9 Nov 2012 07:21:30 -0800 (PST) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id BE77421F868F for ; Fri, 9 Nov 2012 07:21:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,746,1344225600"; d="scan'208,217";a="6796309" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 09 Nov 2012 10:21:29 -0500 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Fri, 9 Nov 2012 10:21:28 -0500 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: Charter draft 5 Thread-Index: Ac2+jeTfcGgltfXvSwCC9TKEwIWVJg== Date: Fri, 9 Nov 2012 15:21:27 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A616FD0@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62C3A616FD0SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] Charter draft 5 X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:21:44 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A616FD0SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues - The WPKOPS charter was discussed during the BoF on Monday. Tw= o modifications were agreed. As a result, I made the following changes. Added: "... document current and historic browser and server behavior, iden= tifying, where appropriate, specific products and specific versions of thos= e products." Added: "The effectiveness of the Web PKI depends critically upon decisions = made by its users in response to information provided in the user interface= s of its various components. Therefore, such information should be accurat= e and complete, yet comprehensible. While recording the design details of = the user interfaces of specific products is not necessary, state changes th= at are visible to, and/or controlled by, the user should be captured." The revised charter appears below. Draft 5:- The Web PKI is the set of systems and procedures most commonly used, in con= junction with security protocols such as TLS, to protect the confidentialit= y, integrity and authenticity of communications between Web browsers and We= b content servers. More specifically, the Web PKI (as considered here) cons= ists of the actual contents of the certificates issued to Web application p= roviders by Certification Authorities (CAs), the certificate validation ser= vices provided by the Authorities to web browsers and their users, and the = TLS/SSL protocol stacks embedded in web servers and browsers. The Web PKI first appeared in 1993 or thereabouts and has developed continu= ously in a somewhat organic fashion since then. Across all the suppliers a= nd the point releases of their products, there are now hundreds of variatio= ns on the Web PKI in regular use. And this can be a source of problems for= end-users, certificate holders, and certificate issuers (CAs). For end-users, there is no clear view whether certificate "problems" remain= when they see indication of a "good" connection. For instance, in some br= owsers, a "good" indication may be displayed when a "revoked" response has = been received and "accepted" by the user, whereas other browsers may refuse= to display the contents under these circumstances. Certificate holders may have difficulty understanding whether some browser = versions will reject their certificate if certain content specifications ar= e not met, such as a subject public key that does not satisfy a minimum key= size, or a certificate policies extension that does not contain a particul= ar standard policy identifier. And for certificate issuers, it can be difficult to predict what proportion= of the user population will accept a certificate chain with certain charac= teristics. For instance, when a browser includes a nonce in an OCSP reques= t but the server supplies a response that does not include the nonce, it is= hard to know which browsers will accept and which will reject the response= . Starting from the premise that more consistency in Web security behavior is= desirable, a natural first step would be to document current and historic = browser and server behavior, identifying, where appropriate, specific produ= cts and specific versions of those products. But, such a project has to be= bounded. Therefore, only server-authentication behavior encountered in mo= re than 0.1 percent of connections made by desktop and mobile browsers shou= ld be considered. While it is not intended to apply the threshold with any= precision, it may be used to justify the inclusion or exclusion of a techn= ique. Future activities may attempt to prescribe how the Web PKI "should" work, a= nd the prescription may turn out to be a proper subset of the PKIX PKI. Ho= wever, that task is explicitly not a goal of the proposed working group. I= nstead, the group's goal is merely to describe how the Web PKI "actually" w= orks in the set of browsers and servers that are in common use today. Additionally, a number of applications (such as client authentication, docu= ment signing, code signing, and email) often use the same trust anchors and= certificate processing mechanisms as those used for server authentication = on the Web. This reuse creates problems in some situations [1]. While the= se applications are outside the scope of this working group, deliverables s= hould (wherever practical within the available expertise and time) identify= mechanisms that are reused by other applications and identify the implicat= ions of that reuse. The effectiveness of the Web PKI depends critically upon decisions made by = its users in response to information provided in the user interfaces of its= various components. Therefore, such information should be accurate and co= mplete, yet comprehensible. While recording the design details of the user= interfaces of specific products is not necessary, state changes that are v= isible to, and/or controlled by, the user should be captured. Also, the reliability of the Web PKI depends critically on the "practices" = of its certificate issuers; these practices comprise how certificate issuer= s perform their functions and implement controls, and are described in docu= ments known as "Certification Practice Statements" [2][3] and operational r= equirements documents [4][5]. However, the topic of certification practices= is outside the scope of the working group. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognised. And, that there is also some urgency in addressing = these shortcomings is also well recognised. But, it is felt that too much = haste can be counter-productive. The expectation is that the work of this = group will bring to light, in a systematic way, aspects of the Web PKI that= should be progressed in future working groups of the IETF's Security Area,= and that suppliers will be willing to participate in those working groups = and modify their products to comply with their standards. Given the urgency of the required developments and the scale of the task, i= t is agreed that adherence to the published schedule should take precedence= over completeness of the results, without sacrificing technical correctnes= s. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. First WG draft of "trust model" document (4 months). 2. First WG draft of "certificate, CRL, and OCSP field and extension processing" document (12 months). 3. First WG draft of "certificate revocation" document (8 months). 4. First WG draft of "TLS stack operation" document (8 months). 5. IESG submission of "trust model" document (16 months). 6. IESG submission of "certificate, CRL, and OCSP field and extension processing" document (24 months). 7. IESG submission of "certificate revocation" document (20 months). 8. IESG submission of "TLS stack operation" document (16 months). References: [1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html [2] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani et al, IETF RFC3647 https://tools.ietf.org/html/rfc3647 [3] Electronic Signatures and Infrastructures (ESI); Policy requirements fo= r certification authorities issuing public key certificates. ETSI TS 102 042 V2.2.1 (2011-12) http://www.etsi.org/deliver/etsi_ts/102000_102099/102042 /02.02.01_60/ts_102042v020201p.pdf [4] Network and certificate system security requirements, CA/Browser Forum, Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf [5] Baseline Requirements for the Issuance and Management of Publicly-Trust= ed Certificates Version 1.0, CA/Browser Forum, Nov 2011, https://www.cabforum.org/Baseline_Requirements_V1.pdf T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A616FD0SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues – The WPKOP= S charter was discussed during the BoF on Monday.  Two modifications w= ere agreed.  As a result, I made the following changes.

 

Added: “… docume= nt current and historic browser and server behavior, identifying, where app= ropriate, specific products and specific versions of those products.”=

 

 

Added: “The effectiven= ess of the Web PKI depends critically upon decisions made by its users in r= esponse to information provided in the user interfaces of its various components.  Therefore, such information should be acc= urate and complete, yet comprehensible.  While recording the design de= tails of the user interfaces of specific products is not necessary, state c= hanges that are visible to, and/or controlled by, the user should be captured.”

 

The revised charter appears = below.

 

Draft 5:-<= /p>

 

The Web PKI is the set of sy= stems and procedures most commonly used, in conjunction with security proto= cols such as TLS, to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web = content servers. More specifically, the Web PKI (as considered here) consis= ts of the actual contents of the certificates issued to Web application pro= viders by Certification Authorities (CAs), the certificate validation services provided by the Authorities to = web browsers and their users, and the TLS/SSL protocol stacks embedded in w= eb servers and browsers.

 

The Web PKI first appeared i= n 1993 or thereabouts and has developed continuously in a somewhat organic = fashion since then.  Across all the suppliers and the point releases of their products, there are now hundreds of variations= on the Web PKI in regular use.  And this can be a source of problems = for end-users, certificate holders, and certificate issuers (CAs).

 

For end-users, there is no c= lear view whether certificate "problems" remain when they see ind= ication of a "good" connection.  For instance, in some brows= ers, a "good" indication may be displayed when a "revoked" = response has been received and "accepted" by the user, whereas ot= her browsers may refuse to display the contents under these circumstances.<= o:p>

 

Certificate holders may have= difficulty understanding whether some browser versions will reject their c= ertificate if certain content specifications are not met, such as a subject public key that does not satisfy a minimum key = size, or a certificate policies extension that does not contain a particula= r standard policy identifier.

 

And for certificate issuers,= it can be difficult to predict what proportion of the user population will= accept a certificate chain with certain characteristics.  For instance, when a browser includes a nonce in an OCSP request but the s= erver supplies a response that does not include the nonce, it is hard to kn= ow which browsers will accept and which will reject the response.

 

Starting from the premise th= at more consistency in Web security behavior is desirable, a natural first = step would be to document current and historic browser and server behavior, identifying, where appropriate, specific products and= specific versions of those products.  But, such a project has to be b= ounded.  Therefore, only server-authentication behavior encountered in= more than 0.1 percent of connections made by desktop and mobile browsers should be considered.  While it is not= intended to apply the threshold with any precision, it may be used to just= ify the inclusion or exclusion of a technique.

 

Future activities may attemp= t to prescribe how the Web PKI "should" work, and the prescriptio= n may turn out to be a proper subset of the PKIX PKI.  However, that task is explicitly not a goal of the proposed working group.  In= stead, the group's goal is merely to describe how the Web PKI "actuall= y" works in the set of browsers and servers that are in common use tod= ay.

 

Additionally, a number of ap= plications (such as client authentication, document signing, code signing, = and email) often use the same trust anchors and certificate processing mechanisms as those used for server authentication = on the Web.  This reuse creates problems in some situations [1]. = While these applications are outside the scope of this working group, deli= verables should (wherever practical within the available expertise and time) identify mechanisms that are reused by o= ther applications and identify the implications of that reuse.

 

The effectiveness of the Web= PKI depends critically upon decisions made by its users in response to inf= ormation provided in the user interfaces of its various components.  Therefore, such information should be accurate a= nd complete, yet comprehensible.  While recording the design details o= f the user interfaces of specific products is not necessary, state changes = that are visible to, and/or controlled by, the user should be captured.

 

Also, the reliability of the= Web PKI depends critically on the "practices" of its certificate= issuers; these practices comprise how certificate issuers perform their functions and implement controls, and are described in docum= ents known as "Certification Practice Statements" [2][3] and oper= ational requirements documents [4][5]. However, the topic of certification = practices is outside the scope of the working group.

 

That there are technical sho= rtcomings with Web PKI, as it is practiced today, is well recognised. = And, that there is also some urgency in addressing these shortcomings is also well recognised.  But, it is felt that too much = haste can be counter-productive.  The expectation is that the work of = this group will bring to light, in a systematic way, aspects of the Web PKI= that should be progressed in future working groups of the IETF's Security Area, and that suppliers will be willing to = participate in those working groups and modify their products to comply wit= h their standards.

 

Given the urgency of the req= uired developments and the scale of the task, it is agreed that adherence t= o the published schedule should take precedence over completeness of the results, without sacrificing technical correctnes= s.

 

Milestones=

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

1.    First W= G draft of "trust model" document (4 months).

2.    First W= G draft of "certificate, CRL, and OCSP field and extension

processing" document (1= 2 months).

3.    First W= G draft of "certificate revocation" document (8 months).

4.    First W= G draft of "TLS stack operation" document (8 months).<= /span>

5.    IESG su= bmission of "trust model" document (16 months).=

6.    IESG su= bmission of "certificate, CRL, and OCSP field and extension

processing" document (2= 4 months).

7.    IESG su= bmission of "certificate revocation" document (20 months).

8.    IESG su= bmission of "TLS stack operation" document (16 months).

 

 

References:

 

[1] https://www.ietf.org/mai= l-archive/web/wpkops/current/msg00104.html

 

[2] Internet X.509 Public Ke= y Infrastructure Certificate Policy and

    &nbs= p; Certification Practices Framework. S. Chokhani et al, IETF RFC3647<= /o:p>

    &nbs= p; https://tools.ietf.org/html/rfc3647

 

[3] Electronic Signatures an= d Infrastructures (ESI); Policy requirements for

    &nbs= p; certification authorities issuing public key certificates.

    &nbs= p; ETSI TS 102 042 V2.2.1 (2011-12)

    &nbs= p; http://www.etsi.org/deliver/etsi_ts/102000_102099/102042

    &nbs= p; /02.02.01_60/ts_102042v020201p.pdf

 

[4] Network and certificate = system security requirements, CA/Browser Forum,

    &nbs= p; Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf=

 

[5] Baseline Requirements fo= r the Issuance and Management of Publicly-Trusted

    &nbs= p; Certificates Version 1.0, CA/Browser Forum, Nov 2011,<= /p>

    &nbs= p; https://www.cabforum.org/Baseline_Requirements_V1.pdf<= /p>

 

 

 

 

 

T: +1 613 270 3183<= /o:p>

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A616FD0SOTTEXCH10corpa_-- From tim.moses@entrust.com Fri Nov 9 12:05:01 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AE221F880D for ; Fri, 9 Nov 2012 12:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4VFexerOBMH for ; Fri, 9 Nov 2012 12:04:59 -0800 (PST) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id D315821F8807 for ; Fri, 9 Nov 2012 12:04:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,747,1344225600"; d="scan'208,217";a="6799945" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 09 Nov 2012 15:04:56 -0500 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Fri, 9 Nov 2012 15:04:56 -0500 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: Minutes IETF 85 BoF Thread-Index: Ac2+tXxo9f7uUMvkTB+nnomUFWKJLw== Date: Fri, 9 Nov 2012 20:04:55 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A617B07@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62C3A617B07SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] Minutes IETF 85 BoF X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 20:05:01 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A617B07SOTTEXCH10corpa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/85/minutes/minutes-85-wpkops Minutes BoF: WPKOPS IETF 85, Atlanta, US 5 Nov 2012 1. Tim Moses reminded the audience of the Note Well requirements. He then = reviewed the agenda: http://www.ietf.org/proceedings/85/agenda/agenda-85-wpkops He gave an introduction to WPKOPS: http://www.ietf.org/proceedings/85/slides/slides-85-wpkops-0.pdf He reviewed the history of the initiative, emphasizing that, were a working= group to be formed, it would not invent new protocols. He presented the problem statement: "Correct operation of the Web PKI depends upon coordination in the implemen= tation, configuration, and deployment of its components (servers, clients, = and certification authorities). These components are commonly developed an= d operated by unrelated organizations, yet important aspects of their funct= ionality are not publicly well specified. This frequently leads to problem= s for the Web PKI's participants (application owners, infrastructure provid= ers, and equipment vendors). Documenting these problems and their causes i= s required in order to have a basis for overcoming them." He said that the following people had volunteered to edit the documents ide= ntified in the charter: Trust model - I=F1igo Barreira, Bruce Morton Certificate, CRL, and OCSP field and extension processing - Ben Wilson, Rob= in Alden Revocation - Phillip Hallam-Baker, Gary Gapinski TLS stack operation - Adam Langley 2. The Web-app operator's perspective Jeff Hodges presented. http://www.ietf.org/proceedings/85/slides/slides-85-wpkops-3.pdf 3. The CA's perspective Ben Wilson presented. http://www.ietf.org/proceedings/85/slides/slides-85-wpkops-2.pdf The discussion went to whether or not aspects of UI should be considered in= -scope. It was decided that functional aspects of user interaction should = be in-scope. But aspects of style (such as colours and symbols) should not= . 4. Outstanding questions The following questions were posed to the audience: 1) Is the problem clear, well-scoped, solvable, and urgent? This was agreed. 2) Do we believe that product vendors will take notice? Generally, people felt that there is value in documenting the current situa= tion whether or not vendors take notice. 3) Is the proposed charter (Draft 4) suitable? There was some discussion on the charter. It was confirmed that the propos= ed working group (within the Operations and Management Area) would not atte= mpt to *specify* behavior. It would merely create a record of how the Web = PKI behaves today. Consensus emerged that the charter should permit discussion of functional a= spects of UI. It was suggested that (where the information is available and helpful) the = reasons for certain design decisions should be captured. This will avert f= uture design decisions that could have unexpected and unfortunate side-effe= cts. There was some discussion concerning whether or not the deliverables should= identify the behavior characteristics of particular products. It was agre= ed that they should. 4) Are there others willing to serve as editors? No one volunteered on the spot. 5) Who is willing to review documents and/or comment on the mailing list? Twenty people volunteered to review and comment on drafts produced by a wor= king group, if one were to be formed. 6) Who feels that a working group should not be formed? The views of the audience were tested by a hum. There was strong support f= or forming a working group. 7) Who feels that a working group should be formed? One unidentified participant dissented. 5. Ron Bonica indicated that he was satisfied with the outcome. T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A617B07SOTTEXCH10corpa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/85/minutes/minutes-85-= wpkops

 

Minutes
 
BoF: WPKOPS
 
IETF 85, Atlanta, US

 


5 Nov 2012


 


1. Tim Moses reminded the audience of the Note=
 Well requirements.  He then reviewed the agenda:

 


http://www.ietf.org/proceedings/85/agenda/agen=
da-85-wpkops


 


He gave an introduction to WPKOPS:<=
/span>


 


http://www.ietf.org/proceedings/85/slides/slid=
es-85-wpkops-0.pdf


 


He reviewed the history of the initiative, emp=
hasizing that, were a working group to be formed, it would not invent new p=
rotocols.


He presented the problem statement:=



 


“Correct operation of the Web PKI depend=
s upon coordination in the implementation, configuration, and deployment of=
 its components (servers, clients, and certification
 authorities).  These components are commonly developed and operated b=
y unrelated organizations, yet important aspects of their functionality are=
 not publicly well specified.  This frequently leads to problems for t=
he Web PKI's participants (application owners,
 infrastructure providers, and equipment vendors).  Documenting these =
problems and their causes is required in order to have a basis for overcomi=
ng them.”


 


He said that the following people had voluntee=
red to edit the documents identified in the charter:


 


Trust model - I=F1igo Barreira, Bruce Morton



Certificate, CRL, and OCSP field and extension=
 processing - Ben Wilson, Robin Alden



Revocation - Phillip Hallam-Baker, Gary Gapins=
ki



TLS stack operation - Adam Langley<=
/span>


 


2. The Web-app operator’s perspective


 


Jeff Hodges presented.


 


http://www.ietf.org/proceedings/85/slides/slid=
es-85-wpkops-3.pdf


 


3. The CA’s perspective


 


Ben Wilson presented.


 


http://www.ietf.org/proceedings/85/slides/slid=
es-85-wpkops-2.pdf


 


The discussion went to whether or not aspects =
of UI should be considered in-scope.  It was decided that functional a=
spects of user interaction should be in-scope.  But
 aspects of style (such as colours and symbols) should not.


 


4. Outstanding questions


 


The following questions were posed to the audi=
ence:


 


1) Is the problem clear, well-scoped, solvable=
, and urgent?


 


This was agreed.


 


2) Do we believe that product vendors will tak=
e notice?


 


Generally, people felt that there is value in =
documenting the current situation whether or not vendors take notice.<=
/o:p>


 


3) Is the proposed charter (Draft 4) suitable?=



 


There was some discussion on the charter. =
; It was confirmed that the proposed working group (within the Operations a=
nd Management Area) would not attempt to *specify*
 behavior.  It would merely create a record of how the Web PKI behaves=
 today.


Consensus emerged that the charter should perm=
it discussion of functional aspects of UI.


 


It was suggested that (where the information i=
s available and helpful) the reasons for certain design decisions should be=
 captured.  This will avert future design decisions
 that could have unexpected and unfortunate side-effects.=



 


There was some discussion concerning whether o=
r not the deliverables should identify the behavior characteristics of part=
icular products.  It was agreed that they should.

 


4) Are there others willing to serve as editor=
s?


 


No one volunteered on the spot.


 


5) Who is willing to review documents and/or c=
omment on the mailing list?


 


Twenty people volunteered to review and commen=
t on drafts produced by a working group, if one were to be formed.


 


6) Who feels that a working group should not b=
e formed?


 


The views of the audience were tested by a hum=
.  There was strong support for forming a working group.


 


7) Who feels that a working group should be fo=
rmed?


 


One unidentified participant dissented.


 


5. Ron Bonica indicated that he was satisfied =
with the outcome.


 


 


T: +1 613 270 3183


 
--_000_5B68A271B9C97046963CB6A5B8D6F62C3A617B07SOTTEXCH10corpa_-- From agl@google.com Mon Nov 12 10:19:17 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819F21F86C1 for ; Mon, 12 Nov 2012 10:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+AEh9kU9Xdk for ; Mon, 12 Nov 2012 10:19:17 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9D321F868B for ; Mon, 12 Nov 2012 10:19:14 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so10515248iec.31 for ; Mon, 12 Nov 2012 10:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PrO2EUmpEYOLHA81ah7gRdlid9t8ydOmC3ptVL4ZKOg=; b=HWzkq0XHZrCw0vdRxk9hLs1l57ywGMHHaSTbBTlMxeSXQ43bPIvftzUkK0rG6GVxfx pL8q5y4JDfTxlDyi3R6yhrRt55FSRe6F+vwaIEtuorJHpPXjHnqUNEga66NjDKse1Ivw awgt+9zB8MEWlKu8IcFFokxYOj8big47kQA3xeDdB3V3ncJTeAcOfZ2wtyvAWdiFrnrK YO1w4q+vHcOxsm46WI0fUXo0nTT5NhIpzeuYzRb9zFIVIJFAQZJ0F9MAmlRbJzs3BXOP IXS2bWORVe9BRi9mJCQvyf++pOKOGTXScQwH7zVdfISc/YJtpG6gEyADoUd8jOF/8bP9 XmSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=PrO2EUmpEYOLHA81ah7gRdlid9t8ydOmC3ptVL4ZKOg=; b=Bk41BnjPTWtpfxdTnCotSl+Saa3ApcjDI6fQZavoGQ/t6YdZKu5piGXO5DJb9r3Kvx VIFLhe8ssQKNsUGc524Uk4QTaTC3k/O3vu+xiL1ZqJ86kiOLy2Mlc+JMzohY4/b90A0R NWUJHd/9WYKw0Kouf4N0wy5vf9tJrFnF7YLXXXEP9KcO3SuxagzfTle0xx6dVj300lId 5RJGC4B6fpBexgcC2B37SDYHbxMp0O1C+109wiJnoIzmhPr4NsS11QLfQI0Zw1/lIuSx G83K7+J2xzxR2K6tEOu9oJFRmT42Gq2th9U40G7N4fNM8NaGL3h3MCB8R7LEZ3O4g9kS SVVQ== MIME-Version: 1.0 Received: by 10.50.91.195 with SMTP id cg3mr8721476igb.57.1352744353741; Mon, 12 Nov 2012 10:19:13 -0800 (PST) Sender: agl@google.com Received: by 10.231.85.9 with HTTP; Mon, 12 Nov 2012 10:19:13 -0800 (PST) In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A617B07@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A617B07@SOTTEXCH10.corp.ad.entrust.com> Date: Mon, 12 Nov 2012 13:19:13 -0500 X-Google-Sender-Auth: X3eXyi_bU9bhWRsjqYU0VrF9_Eo Message-ID: From: Adam Langley To: Tim Moses Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkMvMR09rKXhaULmx9gcIzpAz2JkiVbX9St6KOGto02XiyRDpCJgYvYY4FGnsoz4f44Om8oShHH/0Nv4po5WKRsEaVFKv4pTt/XkQOFotIDyJTMCpmB86wPyI3Q3I+gtXEbJlJh5YEKXMXrDxAq+UDNF5/R8ZU6Gz0ciX1y5fRaJKZS79FpwN0APdnJxb/XqzRlYtyJ Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Minutes IETF 85 BoF X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:19:17 -0000 On Fri, Nov 9, 2012 at 3:04 PM, Tim Moses wrote: > 6) Who feels that a working group should not be formed? > > The views of the audience were tested by a hum. There was strong support > for forming a working group. > > 7) Who feels that a working group should be formed? > > One unidentified participant dissented. For the record, I believe that (6) and (7) are the wrong way round. There was strong consensus that the working group *should* be formed. The small dissent believed that it should *not* be formed. Cheers AGL From rbonica@juniper.net Mon Nov 12 17:47:14 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72F21F880A for ; Mon, 12 Nov 2012 17:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgMNIXdQO9x1 for ; Mon, 12 Nov 2012 17:47:14 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id CA47321F8808 for ; Mon, 12 Nov 2012 17:47:13 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUKGmoZz9iqj77abvRhY4CDEpbVIArTME@postini.com; Mon, 12 Nov 2012 17:47:13 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Nov 2012 17:43:45 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 12 Nov 2012 17:43:45 -0800 Received: from CO9EHSOBE015.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Nov 2012 17:46:07 -0800 Received: from mail74-co9-R.bigfish.com (10.236.132.238) by CO9EHSOBE015.bigfish.com (10.236.130.78) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Nov 2012 01:43:44 +0000 Received: from mail74-co9 (localhost [127.0.0.1]) by mail74-co9-R.bigfish.com (Postfix) with ESMTP id 80D852601F2 for ; Tue, 13 Nov 2012 01:43:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 4 X-BigFish: PS4(zzc85fhzz1de0h1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0l1155h) Received: from mail74-co9 (localhost.localdomain [127.0.0.1]) by mail74-co9 (MessageSwitch) id 1352771022268863_29145; Tue, 13 Nov 2012 01:43:42 +0000 (UTC) Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.231]) by mail74-co9.bigfish.com (Postfix) with ESMTP id 3FC574E0056; Tue, 13 Nov 2012 01:43:42 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Nov 2012 01:43:39 +0000 Received: from CH1PRD0511MB418.namprd05.prod.outlook.com ([169.254.1.25]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0233.004; Tue, 13 Nov 2012 01:43:38 +0000 From: Ronald Bonica To: Tim Moses , "wpkops@ietf.org" Thread-Topic: Next Steps: (was: Minutes IETF 85 BoF) Thread-Index: AQHNwUBNgZPGutJTfEuZi+o9kxeQ+Q== Date: Tue, 13 Nov 2012 01:43:38 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE250670DF@CH1PRD0511MB418.namprd05.prod.outlook.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A617B07@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A617B07@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_2CF4CB03E2AA464BA0982EC92A02CE250670DFCH1PRD0511MB418na_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ENTRUST.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [wpkops] Next Steps: (was: Minutes IETF 85 BoF) X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:47:14 -0000 --_000_2CF4CB03E2AA464BA0982EC92A02CE250670DFCH1PRD0511MB418na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, IMHO, the BoF went as well as any that I have seen. The following are next = steps: - The BoF chairs will post a final version of the draft charter to= this mailing list - The BoF chairs will initiate a two week last call for comments o= n the draft charter - If there are no objections, I will put the draft charter on an I= ESG telechat and propose WG creation Ron 5. Ron Bonica indicated that he was satisfied with the outcome. --_000_2CF4CB03E2AA464BA0982EC92A02CE250670DFCH1PRD0511MB418na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

IMHO, the BoF went as = well as any that I have seen. The following are next steps:

 

-&nb= sp;         The BoF chairs= will post a final version of the draft charter to this mailing list

-&nb= sp;         The BoF chairs= will initiate a two week last call for comments on the draft charter

-&nb= sp;         If there are n= o objections, I will put the draft charter on an IESG telechat and propose = WG creation

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       Ron

 

 

 

 

5. Ron Bonica indicated that he was satisfied = with the outcome.

 

 

 

--_000_2CF4CB03E2AA464BA0982EC92A02CE250670DFCH1PRD0511MB418na_-- From tim.moses@entrust.com Mon Nov 19 08:56:39 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795FB21F8635 for ; Mon, 19 Nov 2012 08:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JBnWm61rM5Q for ; Mon, 19 Nov 2012 08:56:35 -0800 (PST) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 53BAA21F865B for ; Mon, 19 Nov 2012 08:56:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,280,1352091600"; d="scan'208,217";a="2467059" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 19 Nov 2012 11:56:32 -0500 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Mon, 19 Nov 2012 11:56:32 -0500 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: Draft charter last call Thread-Index: Ac3GdtLvpkwyeEdNQly45OF/hPPUPQ== Date: Mon, 19 Nov 2012 16:56:31 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A65F8D2@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: multipart/alternative; boundary="_000_5B68A271B9C97046963CB6A5B8D6F62C3A65F8D2SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] Draft charter last call X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 16:56:39 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A65F8D2SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues - In accordance with Ron's instructions, this is a last call for= comments on the WPKOPS draft charter (v05), which you will find below. Th= e last call closes on 3 Dec 2012. Thanks a lot. All the best. Tim. The Web PKI is the set of systems and procedures most commonly used, in con= junction with security protocols such as TLS, to protect the confidentialit= y, integrity and authenticity of communications between Web browsers and We= b content servers. More specifically, the Web PKI (as considered here) cons= ists of the actual contents of the certificates issued to Web application p= roviders by Certification Authorities (CAs), the certificate validation ser= vices provided by the Authorities to web browsers and their users, and the = TLS/SSL protocol stacks embedded in web servers and browsers. The Web PKI first appeared in 1993 or thereabouts and has developed continu= ously in a somewhat organic fashion since then. Across all the suppliers a= nd the point releases of their products, there are now hundreds of variatio= ns on the Web PKI in regular use. And this can be a source of problems for= end-users, certificate holders, and certificate issuers (CAs). For end-users, there is no clear view whether certificate "problems" remain= when they see indication of a "good" connection. For instance, in some br= owsers, a "good" indication may be displayed when a "revoked" response has = been received and "accepted" by the user, whereas other browsers may refuse= to display the contents under these circumstances. Certificate holders may have difficulty understanding whether some browser = versions will reject their certificate if certain content specifications ar= e not met, such as a subject public key that does not satisfy a minimum key= size, or a certificate policies extension that does not contain a particul= ar standard policy identifier. And for certificate issuers, it can be difficult to predict what proportion= of the user population will accept a certificate chain with certain charac= teristics. For instance, when a browser includes a nonce in an OCSP reques= t but the server supplies a response that does not include the nonce, it is= hard to know which browsers will accept and which will reject the response= . Starting from the premise that more consistency in Web security behavior is= desirable, a natural first step would be to document current and historic = browser and server behavior, identifying, where appropriate, specific produ= cts and specific versions of those products. But, such a project has to be= bounded. Therefore, only server-authentication behavior encountered in mo= re than 0.1 percent of connections made by desktop and mobile browsers shou= ld be considered. While it is not intended to apply the threshold with any= precision, it may be used to justify the inclusion or exclusion of a techn= ique. Future activities may attempt to prescribe how the Web PKI "should" work, a= nd the prescription may turn out to be a proper subset of the PKIX PKI. Ho= wever, that task is explicitly not a goal of the proposed working group. I= nstead, the group's goal is merely to describe how the Web PKI "actually" w= orks in the set of browsers and servers that are in common use today. Additionally, a number of applications (such as client authentication, docu= ment signing, code signing, and email) often use the same trust anchors and= certificate processing mechanisms as those used for server authentication = on the Web. This reuse creates problems in some situations [1]. While the= se applications are outside the scope of this working group, deliverables s= hould (wherever practical within the available expertise and time) identify= mechanisms that are reused by other applications and identify the implicat= ions of that reuse. The effectiveness of the Web PKI depends critically upon decisions made by = its users in response to information provided in the user interfaces of its= various components. Therefore, such information should be accurate and co= mplete, yet comprehensible. While recording the design details of the user= interfaces of specific products is not necessary, state changes that are v= isible to, and/or controlled by, the user should be captured. Also, the reliability of the Web PKI depends critically on the "practices" = of its certificate issuers; these practices comprise how certificate issuer= s perform their functions and implement controls, and are described in docu= ments known as "Certification Practice Statements" [2][3] and operational r= equirements documents [4][5]. However, the topic of certification practices= is outside the scope of the working group. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognised. And, that there is also some urgency in addressing = these shortcomings is also well recognised. But, it is felt that too much = haste can be counter-productive. The expectation is that the work of this = group will bring to light, in a systematic way, aspects of the Web PKI that= should be progressed in future working groups of the IETF's Security Area,= and that suppliers will be willing to participate in those working groups = and modify their products to comply with their standards. Given the urgency of the required developments and the scale of the task, i= t is agreed that adherence to the published schedule should take precedence= over completeness of the results, without sacrificing technical correctnes= s. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. First WG draft of "trust model" document (4 months). 2. First WG draft of "certificate, CRL, and OCSP field and extension processing" document (12 months). 3. First WG draft of "certificate revocation" document (8 months). 4. First WG draft of "TLS stack operation" document (8 months). 5. IESG submission of "trust model" document (16 months). 6. IESG submission of "certificate, CRL, and OCSP field and extension processing" document (24 months). 7. IESG submission of "certificate revocation" document (20 months). 8. IESG submission of "TLS stack operation" document (16 months). References: [1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html [2] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani et al, IETF RFC3647 https://tools.ietf.org/html/rfc3647 [3] Electronic Signatures and Infrastructures (ESI); Policy requirements fo= r certification authorities issuing public key certificates. ETSI TS 102 042 V2.2.1 (2011-12) http://www.etsi.org/deliver/etsi_ts/102000_102099/102042 /02.02.01_60/ts_102042v020201p.pdf [4] Network and certificate system security requirements, CA/Browser Forum, Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf [5] Baseline Requirements for the Issuance and Management of Publicly-Trust= ed Certificates Version 1.0, CA/Browser Forum, Nov 2011, https://www.cabforum.org/Baseline_Requirements_V1.pdf T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A65F8D2SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues – In accordance with Ron’s in= structions, this is a last call for comments on the WPKOPS draft charter (v= 05), which you will find below.  The last call closes on 3 Dec 2012.&n= bsp; Thanks a lot.  All the best.  Tim.

 

The Web PKI is the set of sy= stems and procedures most commonly used, in conjunction with security proto= cols such as TLS, to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web = content servers. More specifically, the Web PKI (as considered here) consis= ts of the actual contents of the certificates issued to Web application pro= viders by Certification Authorities (CAs), the certificate validation services provided by the Authorities to = web browsers and their users, and the TLS/SSL protocol stacks embedded in w= eb servers and browsers.

 

The Web PKI first appeared i= n 1993 or thereabouts and has developed continuously in a somewhat organic = fashion since then.  Across all the suppliers and the point releases of their products, there are now hundreds of variations= on the Web PKI in regular use.  And this can be a source of problems = for end-users, certificate holders, and certificate issuers (CAs).

 

For end-users, there is no c= lear view whether certificate "problems" remain when they see ind= ication of a "good" connection.  For instance, in some brows= ers, a "good" indication may be displayed when a "revoked" = response has been received and "accepted" by the user, whereas ot= her browsers may refuse to display the contents under these circumstances.<= o:p>

 

Certificate holders may have= difficulty understanding whether some browser versions will reject their c= ertificate if certain content specifications are not met, such as a subject public key that does not satisfy a minimum key = size, or a certificate policies extension that does not contain a particula= r standard policy identifier.

 

And for certificate issuers,= it can be difficult to predict what proportion of the user population will= accept a certificate chain with certain characteristics.  For instance, when a browser includes a nonce in an OCSP request but the s= erver supplies a response that does not include the nonce, it is hard to kn= ow which browsers will accept and which will reject the response.

 

Starting from the premise th= at more consistency in Web security behavior is desirable, a natural first = step would be to document current and historic browser and server behavior, identifying, where appropriate, specific products and= specific versions of those products.  But, such a project has to be b= ounded.  Therefore, only server-authentication behavior encountered in= more than 0.1 percent of connections made by desktop and mobile browsers should be considered.  While it is not= intended to apply the threshold with any precision, it may be used to just= ify the inclusion or exclusion of a technique.

 

Future activities may attemp= t to prescribe how the Web PKI "should" work, and the prescriptio= n may turn out to be a proper subset of the PKIX PKI.  However, that task is explicitly not a goal of the proposed working group.  In= stead, the group's goal is merely to describe how the Web PKI "actuall= y" works in the set of browsers and servers that are in common use tod= ay.

 

Additionally, a number of ap= plications (such as client authentication, document signing, code signing, = and email) often use the same trust anchors and certificate processing mechanisms as those used for server authentication = on the Web.  This reuse creates problems in some situations [1]. = While these applications are outside the scope of this working group, deli= verables should (wherever practical within the available expertise and time) identify mechanisms that are reused by o= ther applications and identify the implications of that reuse.

 

The effectiveness of the Web= PKI depends critically upon decisions made by its users in response to inf= ormation provided in the user interfaces of its various components.  Therefore, such information should be accurate a= nd complete, yet comprehensible.  While recording the design details o= f the user interfaces of specific products is not necessary, state changes = that are visible to, and/or controlled by, the user should be captured.

 

Also, the reliability of the= Web PKI depends critically on the "practices" of its certificate= issuers; these practices comprise how certificate issuers perform their functions and implement controls, and are described in docum= ents known as "Certification Practice Statements" [2][3] and oper= ational requirements documents [4][5]. However, the topic of certification = practices is outside the scope of the working group.

 

That there are technical sho= rtcomings with Web PKI, as it is practiced today, is well recognised. = And, that there is also some urgency in addressing these shortcomings is also well recognised.  But, it is felt that too much = haste can be counter-productive.  The expectation is that the work of = this group will bring to light, in a systematic way, aspects of the Web PKI= that should be progressed in future working groups of the IETF's Security Area, and that suppliers will be willing to = participate in those working groups and modify their products to comply wit= h their standards.

 

Given the urgency of the req= uired developments and the scale of the task, it is agreed that adherence t= o the published schedule should take precedence over completeness of the results, without sacrificing technical correctnes= s.

 

Milestones=

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

1.    First W= G draft of "trust model" document (4 months).

2.    First W= G draft of "certificate, CRL, and OCSP field and extension

processing" document (1= 2 months).

3.    First W= G draft of "certificate revocation" document (8 months).

4.    First W= G draft of "TLS stack operation" document (8 months).<= /span>

5.    IESG su= bmission of "trust model" document (16 months).=

6.    IESG su= bmission of "certificate, CRL, and OCSP field and extension

processing" document (2= 4 months).

7.    IESG su= bmission of "certificate revocation" document (20 months).

8.    IESG su= bmission of "TLS stack operation" document (16 months).

 

 

References:

 

[1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html<= o:p>

 

[2] Internet X.509 Public Ke= y Infrastructure Certificate Policy and

    &nbs= p; Certification Practices Framework. S. Chokhani et al, IETF RFC3647<= /o:p>

    &nbs= p; https://tools.ietf.org/html= /rfc3647

 

[3] Electronic Signatures an= d Infrastructures (ESI); Policy requirements for

    &nbs= p; certification authorities issuing public key certificates.

    &nbs= p; ETSI TS 102 042 V2.2.1 (2011-12)

    &nbs= p; http:/= /www.etsi.org/deliver/etsi_ts/102000_102099/102042

    &nbs= p; /02.02.01_60/ts_102042v020201p.pdf

 

[4] Network and certificate = system security requirements, CA/Browser Forum,

    &nbs= p; Aug 2012, https= ://www.cabforum.org/Network_Security_Controls_V1.pdf<= /p>

 

[5] Baseline Requirements fo= r the Issuance and Management of Publicly-Trusted

    &nbs= p; Certificates Version 1.0, CA/Browser Forum, Nov 2011,<= /p>

    &nbs= p; https://w= ww.cabforum.org/Baseline_Requirements_V1.pdf

 

 

 

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A65F8D2SOTTEXCH10corpa_-- From turners@ieca.com Tue Nov 20 08:15:01 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8005621F8758 for ; Tue, 20 Nov 2012 08:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgNIOjhdzQYM for ; Tue, 20 Nov 2012 08:15:00 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.38.21]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF821F8753 for ; Tue, 20 Nov 2012 08:15:00 -0800 (PST) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 2D39D7FBEE507; Tue, 20 Nov 2012 10:15:01 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 1B3997FBEE49E for ; Tue, 20 Nov 2012 10:15:01 -0600 (CST) Received: from [108.45.19.185] (port=56649 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TaqTT-0004SQ-Bv; Tue, 20 Nov 2012 10:14:59 -0600 Message-ID: <50ABAC82.1040101@ieca.com> Date: Tue, 20 Nov 2012 11:14:58 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A65F8D2@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A65F8D2@SOTTEXCH10.corp.ad.entrust.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:56649 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 0 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Draft charter last call X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 16:15:01 -0000 Tim, Hi. Couple of comments and some editorial nits. spt On 11/19/12 11:56 AM, Tim Moses wrote: > Colleagues – In accordance with Ron’s instructions, this is a last call > for comments on the WPKOPS draft charter (v05), which you will find > below. The last call closes on 3 Dec 2012. Thanks a lot. All the > best. Tim. > > The Web PKI is the set of systems and procedures most commonly used, in Not sure about this one, but maybe we should add policies? to systems and procedures - systems, policies, and procedures. > conjunction with security protocols such as TLS, to protect the r/such as TLS/(e.g., TLS/SSL, OCSP) > confidentiality, integrity and authenticity of communications between > Web browsers and Web content servers. More specifically, the Web PKI (as > considered here) consists of the actual contents of the certificates r/of the actual contents of the certificates/consists of fields included in certificates > issued to Web application providers by Certification Authorities (CAs), Is it just application providers or is it also content providers or are they the same thing? > the certificate validation services provided by the Authorities to web Do you mean certificate status services instead of certificate validation services? I think you're talking about OCSP servers here so maybe status is better and validation is usually about the whole path. > browsers and their users, and the TLS/SSL protocol stacks embedded in > web servers and browsers. > > The Web PKI first appeared in 1993 or thereabouts and has developed > continuously in a somewhat organic fashion since then. Across all the > suppliers and the point releases of their products, there are now r/suppliers/Web browsers (for consistency with the 1st para) > hundreds of variations on the Web PKI in regular use. And this can be a r/can be/is > source of problems for end-users, certificate holders, and certificate > issuers (CAs). > > For end-users, there is no clear view whether certificate "problems" Add in here that end-users are the relying parties? r/end-users/end-users (i.e., the relying parties) > remain when they see indication of a "good" connection. For instance, > in some browsers, a "good" indication may be displayed when a "revoked" r/may be/is This does actually happen right ;) > response has been received and "accepted" by the user, whereas other > browsers may refuse to display the contents under these circumstances. r/may refuse/refuse > > Certificate holders may have difficulty understanding whether some I think this is true and it sounds a little more assertive :) r/Certificate holders may have difficulty understanding whether some/Many certificate holders are unsure which > browser versions will reject their certificate if certain content > specifications are not met, such as a subject public key that does not I think we should just be blunt about this bit, which is where I think you're trying to say some people don't follow the profiles. /content specifications/certificate profiles > satisfy a minimum key size, or a certificate policies extension that > does not contain a particular standard policy identifier. > > And for certificate issuers, it can be difficult to predict what > proportion of the user population will accept a certificate chain with When you say user population are do you mean end-users or browsers? Maybe we should avoid it - suggestions below. > certain characteristics. For instance, when a browser includes a nonce > in an OCSP request but the server supplies a response that does not > include the nonce, it is hard to know which browsers will accept and > which will reject the response. I'd like to make sure the point isn't lost that rejecting the OCSP response affects the validation of the path so maybe: And for certificate issuers, it is difficult to predict whether a certificate chain with certain characteristics will be accepted. For instance, some browsers includes a nonce in their OCSP requests and expect one in responses, not all servers include a nonce in replies, and his means some certificate chains will validate while others won't. > Starting from the premise that more consistency in Web security behavior > is desirable, a natural first step would be to document current and r/would be/is > historic browser and server behavior, identifying, where appropriate, > specific products and specific versions of those products. But, such a > project has to be bounded. Therefore, only server-authentication > behavior encountered in more than 0.1 percent of connections made by > desktop and mobile browsers should be considered. While it is not r/should be/is to be > intended to apply the threshold with any precision, it may be used to r/may be/will be > justify the inclusion or exclusion of a technique. Does the above imply that any client authentication discussions are also out of scope? Opps never mind it's discussed later. > Future activities may attempt to prescribe how the Web PKI "should" > work, and the prescription may turn out to be a proper subset of the > PKIX PKI. However, that task is explicitly not a goal of the proposed > working group. Instead, the group's goal is merely to describe how the > Web PKI "actually" works in the set of browsers and servers that are in > common use today. > > Additionally, a number of applications (such as client authentication, > document signing, code signing, and email) often use the same trust > anchors and certificate processing mechanisms as those used for server > authentication on the Web. This reuse creates problems in some r/server authentication on the Web/Web server authentication > situations [1]. While these applications are outside the scope of this > working group, deliverables should (wherever practical within the > available expertise and time) identify mechanisms that are reused by > other applications and identify the implications of that reuse. > > The effectiveness of the Web PKI depends critically upon decisions made > by its users in response to information provided in the user interfaces > of its various components. Therefore, such information should be > accurate and complete, yet comprehensible. While recording the design > details of the user interfaces of specific products is not necessary, > state changes that are visible to, and/or controlled by, the user should > be captured. > > Also, the reliability of the Web PKI depends critically on the > "practices" of its certificate issuers; these practices comprise how > certificate issuers perform their functions and implement controls, and > are described in documents known as "Certification Practice Statements" > [2][3] and operational requirements documents [4][5]. However, the topic > of certification practices is outside the scope of the working group. > > That there are technical shortcomings with Web PKI, as it is practiced > today, is well recognised. And, that there is also some urgency in > addressing these shortcomings is also well recognised. But, it is felt > that too much haste can be counter-productive. The expectation is that > the work of this group will bring to light, in a systematic way, aspects > of the Web PKI that should be progressed in future working groups of the > IETF's Security Area, and that suppliers will be willing to participate r/suppliers/Web browsers and CAs > in those working groups and modify their products to comply with their > standards. > > Given the urgency of the required developments and the scale of the > task, it is agreed that adherence to the published schedule should take > precedence over completeness of the results, without sacrificing > technical correctness. > > Milestones > > ========== > > 1. First WG draft of "trust model" document (4 months). > > 2. First WG draft of "certificate, CRL, and OCSP field and extension > > processing" document (12 months). > > 3. First WG draft of "certificate revocation" document (8 months). > > 4. First WG draft of "TLS stack operation" document (8 months). > > 5. IESG submission of "trust model" document (16 months). > > 6. IESG submission of "certificate, CRL, and OCSP field and extension > > processing" document (24 months). > > 7. IESG submission of "certificate revocation" document (20 months). > > 8. IESG submission of "TLS stack operation" document (16 months). > > References: > > [1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html > > [2] Internet X.509 Public Key Infrastructure Certificate Policy and > > Certification Practices Framework. S. Chokhani et al, IETF RFC3647 > > https://tools.ietf.org/html/rfc3647 > > [3] Electronic Signatures and Infrastructures (ESI); Policy requirements for > > certification authorities issuing public key certificates. > > ETSI TS 102 042 V2.2.1 (2011-12) > > http://www.etsi.org/deliver/etsi_ts/102000_102099/102042 > > /02.02.01_60/ts_102042v020201p.pdf > > [4] Network and certificate system security requirements, CA/Browser Forum, > > Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pdf > > [5] Baseline Requirements for the Issuance and Management of > Publicly-Trusted > > Certificates Version 1.0, CA/Browser Forum, Nov 2011, > > https://www.cabforum.org/Baseline_Requirements_V1.pdf > > T: +1 613 270 3183 > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From tim.moses@entrust.com Tue Nov 20 12:40:16 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5A921F847D for ; Tue, 20 Nov 2012 12:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnZEIdbcMCD8 for ; Tue, 20 Nov 2012 12:40:15 -0800 (PST) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 033C921F8475 for ; Tue, 20 Nov 2012 12:40:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.83,287,1352091600"; d="scan'208";a="2479864" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 20 Nov 2012 15:40:14 -0500 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.004; Tue, 20 Nov 2012 15:40:14 -0500 From: Tim Moses To: Sean Turner Thread-Topic: [wpkops] Draft charter last call Thread-Index: Ac3GdtLvpkwyeEdNQly45OF/hPPUPQA7UU8A///2Soc= Date: Tue, 20 Nov 2012 20:40:12 +0000 Message-ID: <75D5D3EF-AD55-4C40-88B3-966B706B7F83@bwdldb.pp.bnr.ca> References: <5B68A271B9C97046963CB6A5B8D6F62C3A65F8D2@SOTTEXCH10.corp.ad.entrust.com>, <50ABAC82.1040101@ieca.com> In-Reply-To: <50ABAC82.1040101@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" , Tim Moses Subject: Re: [wpkops] Draft charter last call X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 20:40:16 -0000 Thanks Sean. I'll incorporate these into the next version. All the best. = Tim. On 2012-11-20, at 11:15 AM, "Sean Turner" wrote: > Tim, >=20 > Hi. Couple of comments and some editorial nits. >=20 > spt >=20 > On 11/19/12 11:56 AM, Tim Moses wrote: >> Colleagues =96 In accordance with Ron=92s instructions, this is a last c= all >> for comments on the WPKOPS draft charter (v05), which you will find >> below. The last call closes on 3 Dec 2012. Thanks a lot. All the >> best. Tim. >>=20 >> The Web PKI is the set of systems and procedures most commonly used, in >=20 > Not sure about this one, but maybe we should add policies? to systems and= procedures - systems, policies, and procedures. >=20 >> conjunction with security protocols such as TLS, to protect the >=20 > r/such as TLS/(e.g., TLS/SSL, OCSP) >=20 >> confidentiality, integrity and authenticity of communications between >> Web browsers and Web content servers. More specifically, the Web PKI (as >> considered here) consists of the actual contents of the certificates >=20 > r/of the actual contents of the certificates/consists of fields included = in certificates >=20 >> issued to Web application providers by Certification Authorities (CAs), >=20 > Is it just application providers or is it also content providers or are t= hey the same thing? >=20 >> the certificate validation services provided by the Authorities to web >=20 > Do you mean certificate status services instead of certificate validation= services? I think you're talking about OCSP servers here so maybe status i= s better and validation is usually about the whole path. >=20 >> browsers and their users, and the TLS/SSL protocol stacks embedded in >> web servers and browsers. >>=20 >> The Web PKI first appeared in 1993 or thereabouts and has developed >> continuously in a somewhat organic fashion since then. Across all the >> suppliers and the point releases of their products, there are now >=20 > r/suppliers/Web browsers (for consistency with the 1st para) >=20 >> hundreds of variations on the Web PKI in regular use. And this can be a >=20 > r/can be/is >=20 >> source of problems for end-users, certificate holders, and certificate >> issuers (CAs). >>=20 >> For end-users, there is no clear view whether certificate "problems" >=20 > Add in here that end-users are the relying parties? > r/end-users/end-users (i.e., the relying parties) >=20 >> remain when they see indication of a "good" connection. For instance, >> in some browsers, a "good" indication may be displayed when a "revoked" >=20 > r/may be/is This does actually happen right ;) >=20 >> response has been received and "accepted" by the user, whereas other >> browsers may refuse to display the contents under these circumstances. >=20 > r/may refuse/refuse >=20 >>=20 >> Certificate holders may have difficulty understanding whether some >=20 > I think this is true and it sounds a little more assertive :) >=20 > r/Certificate holders may have difficulty understanding whether some/Many= certificate holders are unsure which >=20 >> browser versions will reject their certificate if certain content >> specifications are not met, such as a subject public key that does not >=20 > I think we should just be blunt about this bit, which is where I think yo= u're trying to say some people don't follow the profiles. >=20 > /content specifications/certificate profiles >=20 >> satisfy a minimum key size, or a certificate policies extension that >> does not contain a particular standard policy identifier. >>=20 >> And for certificate issuers, it can be difficult to predict what >> proportion of the user population will accept a certificate chain with >=20 > When you say user population are do you mean end-users or browsers? Maybe= we should avoid it - suggestions below. >=20 >> certain characteristics. For instance, when a browser includes a nonce >> in an OCSP request but the server supplies a response that does not >> include the nonce, it is hard to know which browsers will accept and >> which will reject the response. >=20 > I'd like to make sure the point isn't lost that rejecting the OCSP respon= se affects the validation of the path so maybe: >=20 > And for certificate issuers, it is difficult to predict whether a certifi= cate chain with certain characteristics will be accepted. For instance, so= me browsers includes a nonce in their OCSP requests and expect one in respo= nses, not all servers include a nonce in replies, and his means some certif= icate chains will validate while others won't. >=20 >> Starting from the premise that more consistency in Web security behavior >> is desirable, a natural first step would be to document current and >=20 > r/would be/is >=20 >> historic browser and server behavior, identifying, where appropriate, >> specific products and specific versions of those products. But, such a >> project has to be bounded. Therefore, only server-authentication >> behavior encountered in more than 0.1 percent of connections made by >> desktop and mobile browsers should be considered. While it is not >=20 > r/should be/is to be >=20 >> intended to apply the threshold with any precision, it may be used to >=20 > r/may be/will be >=20 >> justify the inclusion or exclusion of a technique. >=20 > Does the above imply that any client authentication discussions are also = out of scope? Opps never mind it's discussed later. >=20 >> Future activities may attempt to prescribe how the Web PKI "should" >> work, and the prescription may turn out to be a proper subset of the >> PKIX PKI. However, that task is explicitly not a goal of the proposed >> working group. Instead, the group's goal is merely to describe how the >> Web PKI "actually" works in the set of browsers and servers that are in >> common use today. >>=20 >> Additionally, a number of applications (such as client authentication, >> document signing, code signing, and email) often use the same trust >> anchors and certificate processing mechanisms as those used for server >> authentication on the Web. This reuse creates problems in some >=20 > r/server authentication on the Web/Web server authentication >=20 >> situations [1]. While these applications are outside the scope of this >> working group, deliverables should (wherever practical within the >> available expertise and time) identify mechanisms that are reused by >> other applications and identify the implications of that reuse. >>=20 >> The effectiveness of the Web PKI depends critically upon decisions made >> by its users in response to information provided in the user interfaces >> of its various components. Therefore, such information should be >> accurate and complete, yet comprehensible. While recording the design >> details of the user interfaces of specific products is not necessary, >> state changes that are visible to, and/or controlled by, the user should >> be captured. >>=20 >> Also, the reliability of the Web PKI depends critically on the >> "practices" of its certificate issuers; these practices comprise how >> certificate issuers perform their functions and implement controls, and >> are described in documents known as "Certification Practice Statements" >> [2][3] and operational requirements documents [4][5]. However, the topic >> of certification practices is outside the scope of the working group. >>=20 >> That there are technical shortcomings with Web PKI, as it is practiced >> today, is well recognised. And, that there is also some urgency in >> addressing these shortcomings is also well recognised. But, it is felt >> that too much haste can be counter-productive. The expectation is that >> the work of this group will bring to light, in a systematic way, aspects >> of the Web PKI that should be progressed in future working groups of the >> IETF's Security Area, and that suppliers will be willing to participate >=20 > r/suppliers/Web browsers and CAs >=20 >> in those working groups and modify their products to comply with their >> standards. >>=20 >> Given the urgency of the required developments and the scale of the >> task, it is agreed that adherence to the published schedule should take >> precedence over completeness of the results, without sacrificing >> technical correctness. >>=20 >> Milestones >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> 1. First WG draft of "trust model" document (4 months). >>=20 >> 2. First WG draft of "certificate, CRL, and OCSP field and extension >>=20 >> processing" document (12 months). >>=20 >> 3. First WG draft of "certificate revocation" document (8 months). >>=20 >> 4. First WG draft of "TLS stack operation" document (8 months). >>=20 >> 5. IESG submission of "trust model" document (16 months). >>=20 >> 6. IESG submission of "certificate, CRL, and OCSP field and extension >>=20 >> processing" document (24 months). >>=20 >> 7. IESG submission of "certificate revocation" document (20 months). >>=20 >> 8. IESG submission of "TLS stack operation" document (16 months). >>=20 >> References: >>=20 >> [1] https://www.ietf.org/mail-archive/web/wpkops/current/msg00104.html >>=20 >> [2] Internet X.509 Public Key Infrastructure Certificate Policy and >>=20 >> Certification Practices Framework. S. Chokhani et al, IETF RFC3647 >>=20 >> https://tools.ietf.org/html/rfc3647 >>=20 >> [3] Electronic Signatures and Infrastructures (ESI); Policy requirements= for >>=20 >> certification authorities issuing public key certificates. >>=20 >> ETSI TS 102 042 V2.2.1 (2011-12) >>=20 >> http://www.etsi.org/deliver/etsi_ts/102000_102099/102042 >>=20 >> /02.02.01_60/ts_102042v020201p.pdf >>=20 >> [4] Network and certificate system security requirements, CA/Browser For= um, >>=20 >> Aug 2012, https://www.cabforum.org/Network_Security_Controls_V1.pd= f >>=20 >> [5] Baseline Requirements for the Issuance and Management of >> Publicly-Trusted >>=20 >> Certificates Version 1.0, CA/Browser Forum, Nov 2011, >>=20 >> https://www.cabforum.org/Baseline_Requirements_V1.pdf >>=20 >> T: +1 613 270 3183 >>=20 >>=20 >>=20 >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >>=20 From paul.hoffman@vpnc.org Tue Nov 27 12:54:38 2012 Return-Path: X-Original-To: wpkops@ietfa.amsl.com Delivered-To: wpkops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD18F1F0C59 for ; Tue, 27 Nov 2012 12:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmyNFe6czBzO for ; Tue, 27 Nov 2012 12:54:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAB821F87A0 for ; Tue, 27 Nov 2012 12:54:38 -0800 (PST) Received: from [165.227.249.210] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qARKsagW001070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 27 Nov 2012 13:54:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7223F3C9-808B-4E47-94A7-4A1E41B95700@vpnc.org> Date: Tue, 27 Nov 2012 12:54:35 -0800 To: wpkops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [wpkops] Draft charter last call X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 20:54:38 -0000 In addition to agreeing with Sean's comments, I have a two more. First, = references are normally not used in IETF WG charters. The references = here could easily be removed without making the charter any worse. Mor significantly: Is there a document missing? "The effectiveness of = the Web PKI depends critically upon decisions made by its users in = response to information provided in the user interfaces of its various = components. Therefore, such information should be accurate and = complete, yet comprehensible. While recording the design details of the = user interfaces of specific products is not necessary, state changes = that are visible to, and/or controlled by, the user should be captured." = Capturing state changes that are visible to the user doesn't seem to be = part of "trust model", "certificate, CRL, and OCSP field and extension = processing", "certificate revocation", or "TLS stack operation". Possibly the last document could be expanded to "TLS stack operation and = interaction with the browser". Alternately, a document about visible = state changes in web browsers could be added to the list of documents. A = third option is to drop the paragraph if the group believes that adding = this would be to difficult to do cleanly. --Paul Hoffman=