From stephen.farrell@cs.tcd.ie Mon Aug 20 09:38: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 2CA2021F8613 for ; Mon, 20 Aug 2012 09:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuE0TyRa1shH for ; Mon, 20 Aug 2012 09:38:13 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E19721F8608 for ; Mon, 20 Aug 2012 09:38:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 27DA417147A for ; Mon, 20 Aug 2012 17:38:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1345480686; bh=JHXdKD49mzeihN4Rc6Cuw1By gkdBRQi4b8zRyrCtsRk=; b=VqSQq/ei6wtQH/Kw6sbkcaVoSjBL9YqqbDsfzHWi HD1evmAiupUaJ0xJq8rXwr2ISlkTC43WFzdqg0xyvoFK+iIwHqSYSO+mrT4UnRqu /Q+87i+F7WjA/vN1jNJq1ayroLflaWPGrZYduOwolJn3M3zaJc+6XLpwn8l0rQHC uzrlwB/ET87UwvIJlQuhuMxB+tccUADhbA302E/GCQGjNQ2+tg2PtJrG0QTefl3T bv0g4YmBkK5Y7Vd79l9/73/g+1KruoSprlcf0ri5YvYSEFQUhM8FcL/CE7dIDezh fHGD/DhLFdJhNSHYe8mnr4m0Asf/We+wvHKq4VhW5QHXBg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id T4jkPN1M0VrR for ; Mon, 20 Aug 2012 17:38:06 +0100 (IST) Received: from [10.87.48.6] (unknown [86.42.30.175]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CAF40171475 for ; Mon, 20 Aug 2012 17:38:06 +0100 (IST) Message-ID: <503267EE.2070600@cs.tcd.ie> Date: Mon, 20 Aug 2012 17:38:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: wpkops@ietf.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [wpkops] test 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, 20 Aug 2012 16:38:14 -0000 Noting in archive yet, so this is a test. S. From ietf-secretariat@ietf.org Mon Aug 20 10:12: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 C2BC321F8527; Mon, 20 Aug 2012 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 6ulMJPNlMzvh; Mon, 20 Aug 2012 10:12:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED0221F859F; Mon, 20 Aug 2012 10:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120820171244.8440.34946.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 10:12:44 -0700 Cc: rbonica@juniper.net, wpkops@ietf.org Subject: [wpkops] New Non-WG Mailing List: wpkops 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, 20 Aug 2012 17:12:44 -0000 A new IETF non-working group email list has been created. List address: wpkops@ietf.og Archive: http://www.ietf.org/mail-archive/web/wpkops/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/wpkops Purpose: This mailing list is for the discussion of the following topics: - How the Web PKI currently works - Shortcomings and failure modes of the current Web PKI - Future evolution of Web PKI - Advice to those developing Web PKI clients As this is an IETF mailing list, the IETF Intellectual Property Rights (IPR= ) Policy applies. See http://www.ietf.org/ipr/policy.html for details. For additional information, please contact the list administrators. From tim.moses@entrust.com Wed Aug 22 05:44:58 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 8A65C21F84DD for ; Wed, 22 Aug 2012 05:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.434, 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 Z2FSyPF0ABOZ for ; Wed, 22 Aug 2012 05:44:55 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id BD42521F84C2 for ; Wed, 22 Aug 2012 05:44:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,808,1336363200"; d="scan'208,217";a="5978624" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 22 Aug 2012 08:44:54 -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.001; Wed, 22 Aug 2012 08:44:53 -0400 From: Tim Moses To: "'wpkops@ietf.org'" Thread-Topic: First draft charter proposal Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQ== Date: Wed, 22 Aug 2012 12:44:53 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@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_5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 12:44:58 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues - Here is a first draft of a charter proposal. Please give it s= ome thought and share the results of your deliberations. Thanks a lot. Al= l the best. Tim. The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems both for end-users and certificate issuers. 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 refu= se to display the contents under these circumstances. And for 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 se= rver supplies a response that does not include the nonce, it is hard to kno= w 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. 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 (other than the Web) may use the sam= e trust anchors as the ones used by the Web. These applications include: d= ocument signing; code signing; and email. They may use PKI in a way that d= iffers from the way in which the Web uses it. Therefore, these application= s are explicitly out of scope for the working group. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers. However, the topic of practices is outside the s= cope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. 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. The working group should focus its init= ial attention on the browser and server versions that make up the largest p= art of the desktop and mobile Web today. The output documents will all be BCP-style RFCs. 1. Agree the working group charter (1 month). 2. Catalog the products and versions to be analyzed (1 month). 3. First WG draft of "trust model" document (4 months). 4. First WG draft of "public-key submission and certificate installation= " document (4 months). 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 mo= nths). 6. First WG draft of "certificate, CRL, and OCSP processing" document (1= 2 months). 7. First WG draft of "certificate re-issuance" document (4 months). 8. First WG draft of "certificate renewal" document (4 months). 9. First WG draft of "certificate revocation" document (8 months). 10. IESG submission of "trust model" document (16 months). 11. IESG submission of "public-key submission and certificate installation"= document (16 months). 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 mo= nths). 13. IESG submission of "certificate, CRL, and OCSP processing" document (24= months). 14. IESG submission of "certificate re-issuance" document (16 months). 15. IESG submission of "certificate renewal" document (16 months). 16. IESG submission of "certificate revocation" document (20 months) The schedule is predicated upon the group's ability to recruit a sufficient= number of editors and engage either the relevant product experts or other = experts willing to test the selected product configurations. T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues – Here is a first draft of a charte= r proposal.  Please give it some thought and share the results of your= deliberations.  Thanks a lot.  All the best.  Tim.

 

The Web PKI is the set of systems and procedures most co= mmonly used to protect the confidentiality, integrity and authenticity of c= ommunications between Web browsers and Web content servers.  It first = appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then.  Acr= oss all the suppliers and the point releases of their products, there are n= ow hundreds of variations on the Web PKI in regular use.  And this can= be a source of problems both for end-users and certificate issuers.

 

For end-users, there is no clear view whether certificat= e "problems" remain when they see indication of a "good"= ; connection.  For instance, in some browsers, a "good" indi= cation may be displayed when a "revoked" response has been receiv= ed and "accepted" by the user.  Whereas, other browsers may refuse= to display the contents under these circumstances.

 

And for issuers, it can be difficult to predict what pro= portion 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 server supplies a response that does not include the nonce, it is hard to know which browser= s will accept and which will reject the response.

 

Starting from the premise that more consistency in Web s= ecurity behavior is desirable, a natural first step would be to document cu= rrent and historic browser and server behavior.

 

Future activities may attempt to prescribe how the Web P= KI "should" work, and the prescription may turn out to be a prope= r 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 t= he set of browsers and servers that are in common use today.

 

Additionally, a number of applications (other than the W= eb) may use the same trust anchors as the ones used by the Web.  These= applications include: document signing; code signing; and email.  The= y may use PKI in a way that differs from the way in which the Web uses it.  Therefore, these applications are expl= icitly out of scope for the working group.

 

Also, the reliability of the Web PKI depends critically = on the practices of its certificate issuers.  However, the topic of pr= actices is outside the scope of the IETF.  Therefore, this will be lef= t to other competent bodies.

 

That there are technical shortcomings with Web PKI, as i= t is practiced today, is well recognized.  And, that there is also som= e urgency in addressing these shortcomings is also well recognized.  B= ut, 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 s= ystematic way, aspects of the Web PKI that should be progressed in future w= orking groups of the IETF's Security Area, and that suppliers will be willi= ng to participate in those working groups and modify their products to comply with their standards.

 

Given the urgency of the required developments and the s= cale of the task, it is agreed that adherence to the published schedule sho= uld take precedence over completeness of the results.  The working gro= up should focus its initial attention on the browser and server versions that make up the largest part of the deskt= op and mobile Web today.

 

The output documents will all be BCP-style RFCs.

 

1.    Agree the working group charter (1 month).

2.    Catalog the products and versions to be analyzed (1= month).

3.    First WG draft of "trust model" document = (4 months).

4.    First WG draft of "public-key submission and c= ertificate installation" document (4 months).

5.    First WG draft of "certificate, CRL, and OCSP = profile" document (8 months).

6.    First WG draft of "certificate, CRL, and OCSP = processing" document (12 months).

7.    First WG draft of "certificate re-issuance&quo= t; document (4 months).

8.    First WG draft of "certificate renewal" d= ocument (4 months).

9.    First WG draft of "certificate revocation"= ; document (8 months).

10. IESG submission of "trust model" document= (16 months).

11. IESG submission of "public-key submission and = certificate installation" document (16 months).

12. IESG submission of "certificate, CRL, and OCSP= profile" document (20 months).

13. IESG submission of "certificate, CRL, and OCSP= processing" document (24 months).

14. IESG submission of "certificate re-issuance&qu= ot; document (16 months).

15. IESG submission of "certificate renewal" = document (16 months).

16. IESG submission of "certificate revocation&quo= t; document (20 months)

 

The schedule is predicated upon the group's ability to r= ecruit a sufficient number of editors and engage either the relevant produc= t experts or other experts willing to test the selected product configurati= ons.  

 

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5SOTTEXCH10corpa_-- From rbonica@juniper.net Wed Aug 22 07:29:33 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 BE94821F8510 for ; Wed, 22 Aug 2012 07:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Umn+CZ9bJIES for ; Wed, 22 Aug 2012 07:29:30 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DB40A21F8460 for ; Wed, 22 Aug 2012 07:29:29 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUDTsyGlV078XB02hOWKmvg9B/WnGgf+8@postini.com; Wed, 22 Aug 2012 07:29:29 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Aug 2012 07:29:05 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 22 Aug 2012 07:29:03 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 22 Aug 2012 10:29:02 -0400 From: Ronald Bonica To: Tim Moses , "'wpkops@ietf.org'" Date: Wed, 22 Aug 2012 10:29:00 -0400 Thread-Topic: First draft charter proposal Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQADeIIQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D781D92FFB@EMBX01-WF.jnpr.net> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D781D92FFBEMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:29:33 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D781D92FFBEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tim, This is an excellent first attempt. Comments in line..... From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Tim Moses Sent: Wednesday, August 22, 2012 8:45 AM To: 'wpkops@ietf.org' Subject: [wpkops] First draft charter proposal Colleagues - Here is a first draft of a charter proposal. Please give it s= ome thought and share the results of your deliberations. Thanks a lot. Al= l the best. Tim. The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems both for end-users and certificate issuers. 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 refu= se to display the contents under these circumstances. And for 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 se= rver supplies a response that does not include the nonce, it is hard to kno= w 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. 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 (other than the Web) may use the sam= e trust anchors as the ones used by the Web. These applications include: d= ocument signing; code signing; and email. They may use PKI in a way that d= iffers from the way in which the Web uses it. Therefore, these application= s are explicitly out of scope for the working group. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers. However, the topic of practices is outside the s= cope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. 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. The working group should focus its init= ial attention on the browser and server versions that make up the largest p= art of the desktop and mobile Web today. So far, this is exceptionally strong! The output documents will all be BCP-style RFCs. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Agree the working group charter (1 month). Typically, this is done before the WG is formed. No need for an RFC 2. Catalog the products and versions to be analyzed (1 month). When you say "Products", do you mean "Explorer, Chrome and Safari". If so, = that might be a problem. In the IETF, we can't talk about peoples products.= We have to talk about protocols. 3. First WG draft of "trust model" document (4 months). 4. First WG draft of "public-key submission and certificate installation" = document (4 months). 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 mont= hs). 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 = months). 7. First WG draft of "certificate re-issuance" document (4 months). 8. First WG draft of "certificate renewal" document (4 months). 9. First WG draft of "certificate revocation" document (8 months). 10. IESG submission of "trust model" document (16 months). 11. IESG submission of "public-key submission and certificate installation"= document (16 months). 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 mo= nths). 13. IESG submission of "certificate, CRL, and OCSP processing" document (24= months). 14. IESG submission of "certificate re-issuance" document (16 months). 15. IESG submission of "certificate renewal" document (16 months). 16. IESG submission of "certificate revocation" document (20 months) The schedule is predicated upon the group's ability to recruit a sufficient= number of editors and engage either the relevant product experts or other = experts willing to test the selected product configurations. This is true for all WGs. There is no need to say it. T: +1 613 270 3183 --_000_13205C286662DE4387D9AF3AC30EF456D781D92FFBEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,

 

This is an excellent first attempt. Comments in line= 230;..

 

<= b>From:<= /span> wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Tim Moses
Sent: Wednesday, August 22, 2012 8:45 AM
To:= 'wpkops@ietf.org'
Subject: [wpkops] First draft charter prop= osal

 

Colleagues – Here is a first draft of a cha= rter proposal.  Please give it some thought and share the results of y= our deliberations.  Thanks a lot.  All the best.  Tim.<= /o:p>

 

The Web= PKI is the set of systems and procedures most commonly used to protect the= confidentiality, integrity and authenticity of communications between Web = browsers and Web content servers.  It first appeared in 1993 or therea= bouts and has developed continuously in a somewhat organic fashion since th= en.  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 both for end-users and certificate is= suers.

 

For end-users, there is no clear view whether certificate "problems&q= uot; remain when they see indication of a "good" connection. = ; For instance, in some browsers, a "good" indication may be disp= layed when a "revoked" response has been received and "accep= ted" by the user.  Whereas, other browsers may refuse to display = the contents under these circumstances.

 

And for issuers, it can be difficult to p= redict what proportion of the user population will accept a certificate cha= in with certain characteristics.  For instance, when a browser include= s a nonce in an OCSP request but the server supplies a response that does n= ot include the nonce, it is hard to know which browsers will accept and whi= ch will reject the response.

 

Starting from the premise that more consistency in W= eb security behavior is desirable, a natural first step would be to documen= t current and historic browser and server behavior.

 

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 t= ask 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.

 

Additiona= lly, a number of applications (other than the Web) may use the same trust a= nchors as the ones used by the Web.  These applications include: docum= ent signing; code signing; and email.  They may use PKI in a way that = differs from the way in which the Web uses it.  Therefore, these appli= cations are explicitly out of scope for the working group.

 

Also, the reliability = of the Web PKI depends critically on the practices of its certificate issue= rs.  However, the topic of practices is outside the scope of the IETF.=   Therefore, this will be left to other competent bodies.

 

That there are tec= hnical shortcomings with Web PKI, as it is practiced today, is well recogni= zed.  And, that there is also some urgency in addressing these shortco= mings is also well recognized.  But, it is felt that too much haste ca= n be counter-productive.  The expectation is that the work of this gro= up will bring to light, in a systematic way, aspects of the Web PKI that sh= ould be progressed in future working groups of the IETF's Security Area, an= d 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 r= equired developments and the scale of the task, it is agreed that adherence= to the published schedule should take precedence over completeness of the = results.  The working group should focus its initial attention on the = browser and server versions that make up the largest part of the desktop an= d mobile Web today.

 =

 

So far, this is exceptionally strong!

 

The output documents wil= l all be BCP-style RFCs.

 <= /o:p>

 

Milestones

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

&nbs= p;

1.  Agree the working group charter (1 month).

 

Typically, = this is done before the WG is formed. No need for an RFC<= /p>

 

2.  Catalog the products and v= ersions to be analyzed (1 month).

 

When you say “Produc= ts”, do you mean “Explorer, Chrome and Safari”. If so, th= at might be a problem. In the IETF, we can’t talk about peoples produ= cts. We have to talk about protocols.

 

3.&= nbsp; First WG draft of "trust model" doc= ument (4 months).

4. = ; First WG draft of "public-key submission and= certificate installation" document (4 months).

5.  First WG draft= of "certificate, CRL, and OCSP profile" document (8 months).

6.  First WG draft of "certificate, CRL, and OCSP processing" do= cument (12 months).

7.&nb= sp; First WG draft of "certificate re-issuance= " document (4 months).

8.  First WG draft of "certificate ren= ewal" document (4 months).

9.  First WG draft of "certificate= revocation" document (8 months).

10. IESG submission of "trust mo= del" document (16 months).

11. IESG submission of "public-key subm= ission and certificate installation" document (16 months).<= /p>

12. IESG sub= mission of "certificate, CRL, and OCSP profile" document (20 mont= hs).

13. IESG submission of "certificate, CRL, and OCSP processing"= ; document (24 months).

14.15. IESG submission of "certificate renewa= l" document (16 months).

16. IESG submission of "certificate revoc= ation" document (20 months)

 =

The schedule is predicated upon the group's abil= ity to recruit a sufficient number of editors and engage either the relevan= t product experts or other experts willing to test the selected product con= figurations.  

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>This is true for all WGs. There is no need to say it.

 

&= nbsp;

T: +1 613 270 3183

 

= --_000_13205C286662DE4387D9AF3AC30EF456D781D92FFBEMBX01WFjnprn_-- From tim.moses@entrust.com Wed Aug 22 12:00:15 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 7FE5C21F86B4 for ; Wed, 22 Aug 2012 12:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.369, 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 IgNF2WIyQW74 for ; Wed, 22 Aug 2012 12:00:11 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2793721F8680 for ; Wed, 22 Aug 2012 12:00:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,809,1344225600"; d="scan'208,217";a="5984518" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 22 Aug 2012 15:00:07 -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.001; Wed, 22 Aug 2012 15:00:06 -0400 From: Tim Moses To: 'Ronald Bonica' Thread-Topic: First draft charter proposal Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQADeIIQAAdsMzA= Date: Wed, 22 Aug 2012 19:00:06 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A5704A6@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <13205C286662DE4387D9AF3AC30EF456D781D92FFB@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D781D92FFB@EMBX01-WF.jnpr.net> 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_5B68A271B9C97046963CB6A5B8D6F62C3A5704A6SOTTEXCH10corpa_" MIME-Version: 1.0 Cc: "'wpkops@ietf.org'" Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:00:16 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A5704A6SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Ron. Very helpful. On the topic of "products", I'm afraid I did mean specific company's produc= ts. The thinking was that we need to limit the scale of the job, so that o= ur efforts only go towards useful deliverables. We don't need to waste tim= e documenting how IE3 implemented the Web PKI. But, we do need to document= versions other than the most recent ones, because those still form a signi= ficant part of today's Web PKI. Maybe, we should speak in terms of "the pr= oduct implementations that make up today's Web PKI", and rely on the partic= ipants' judgment to decide which products and versions fall into that categ= ory, while (at no time) being explicit about which products those are. All the best. Tim. From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: Wednesday, August 22, 2012 10:29 AM To: Tim Moses; 'wpkops@ietf.org' Subject: RE: First draft charter proposal Tim, This is an excellent first attempt. Comments in line..... From: wpkops-bounces@ietf.org [mailto:wpkop= s-bounces@ietf.org] On Behalf Of Tim Moses Sent: Wednesday, August 22, 2012 8:45 AM To: 'wpkops@ietf.org' Subject: [wpkops] First draft charter proposal Colleagues - Here is a first draft of a charter proposal. Please give it s= ome thought and share the results of your deliberations. Thanks a lot. Al= l the best. Tim. The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems both for end-users and certificate issuers. 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 refu= se to display the contents under these circumstances. And for 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 se= rver supplies a response that does not include the nonce, it is hard to kno= w 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. 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 (other than the Web) may use the sam= e trust anchors as the ones used by the Web. These applications include: d= ocument signing; code signing; and email. They may use PKI in a way that d= iffers from the way in which the Web uses it. Therefore, these application= s are explicitly out of scope for the working group. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers. However, the topic of practices is outside the s= cope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. 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. The working group should focus its init= ial attention on the browser and server versions that make up the largest p= art of the desktop and mobile Web today. So far, this is exceptionally strong! The output documents will all be BCP-style RFCs. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Agree the working group charter (1 month). Typically, this is done before the WG is formed. No need for an RFC 2. Catalog the products and versions to be analyzed (1 month). When you say "Products", do you mean "Explorer, Chrome and Safari". If so, = that might be a problem. In the IETF, we can't talk about peoples products.= We have to talk about protocols. 3. First WG draft of "trust model" document (4 months). 4. First WG draft of "public-key submission and certificate installation" = document (4 months). 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 mont= hs). 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 = months). 7. First WG draft of "certificate re-issuance" document (4 months). 8. First WG draft of "certificate renewal" document (4 months). 9. First WG draft of "certificate revocation" document (8 months). 10. IESG submission of "trust model" document (16 months). 11. IESG submission of "public-key submission and certificate installation"= document (16 months). 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 mo= nths). 13. IESG submission of "certificate, CRL, and OCSP processing" document (24= months). 14. IESG submission of "certificate re-issuance" document (16 months). 15. IESG submission of "certificate renewal" document (16 months). 16. IESG submission of "certificate revocation" document (20 months) The schedule is predicated upon the group's ability to recruit a sufficient= number of editors and engage either the relevant product experts or other = experts willing to test the selected product configurations. This is true for all WGs. There is no need to say it. T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A5704A6SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Ron.  Very= helpful.

 

On the topic of “= ;products”, I’m afraid I did mean specific company’s prod= ucts.  The thinking was that we need to limit the scale of the job, so= that our efforts only go towards useful deliverables.  We don’t need to waste time documenting how IE3 implemented the Web PKI.  But,= we do need to document versions other than the most recent ones, because t= hose still form a significant part of today’s Web PKI.  Maybe, w= e should speak in terms of “the product implementations that make up today’s Web PKI”, and rely on the participants= 217; judgment to decide which products and versions fall into that category= , while (at no time) being explicit about which products those are.

 

All the best.  Ti= m.

 

From: Ronald B= onica [mailto:rbonica@juniper.net]
Sent: Wednesday, August 22, 2012 10:29 AM
To: Tim Moses; 'wpkops@ietf.org'
Subject: RE: First draft charter proposal

 

Tim,=

 

This is an excellent f= irst attempt. Comments in line…..

 

From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 8:45 AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First draft charter proposal

 

Colleagues – Here is a first draft of a charte= r proposal.  Please give it some thought and share the results of your= deliberations.  Thanks a lot.  All the best.  Tim.

 

The Web PKI is the set of systems and procedures most co= mmonly used to protect the confidentiality, integrity and authenticity of c= ommunications between Web browsers and Web content servers.  It first = appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then.  Acr= oss all the suppliers and the point releases of their products, there are n= ow hundreds of variations on the Web PKI in regular use.  And this can= be a source of problems both for end-users and certificate issuers.

 

For end-users, there is no clear view whether certificat= e "problems" remain when they see indication of a "good"= ; connection.  For instance, in some browsers, a "good" indi= cation may be displayed when a "revoked" response has been receiv= ed and "accepted" by the user.  Whereas, other browsers may refuse= to display the contents under these circumstances.

 

And for issuers, it can be difficult to predict what pro= portion 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 server supplies a response that does not include the nonce, it is hard to know which browser= s will accept and which will reject the response.

 

Starting from the premise that more consistency in Web s= ecurity behavior is desirable, a natural first step would be to document cu= rrent and historic browser and server behavior.

 

Future activities may attempt to prescribe how the Web P= KI "should" work, and the prescription may turn out to be a prope= r 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 t= he set of browsers and servers that are in common use today.

 

Additionally, a number of applications (other than the W= eb) may use the same trust anchors as the ones used by the Web.  These= applications include: document signing; code signing; and email.  The= y may use PKI in a way that differs from the way in which the Web uses it.  Therefore, these applications are expl= icitly out of scope for the working group.

 

Also, the reliability of the Web PKI depends critically = on the practices of its certificate issuers.  However, the topic of pr= actices is outside the scope of the IETF.  Therefore, this will be lef= t to other competent bodies.

 

That there are technical shortcomings with Web PKI, as i= t is practiced today, is well recognized.  And, that there is also som= e urgency in addressing these shortcomings is also well recognized.  B= ut, 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 s= ystematic way, aspects of the Web PKI that should be progressed in future w= orking groups of the IETF's Security Area, and that suppliers will be willi= ng to participate in those working groups and modify their products to comply with their standards.

 

Given the urgency of the required developments and the s= cale of the task, it is agreed that adherence to the published schedule sho= uld take precedence over completeness of the results.  The working gro= up should focus its initial attention on the browser and server versions that make up the largest part of the deskt= op and mobile Web today.

 

 

So far, this is exceptionally= strong!

 

The output documents will all be BCP-style RFCs.

 

 

Milestones<= /p>

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

 

1.  Agree the working group charter (1 month).

 

Typically, this is done befor= e the WG is formed. No need for an RFC

 

2.  Catalog the products and versions to be analyzed (1= month).

 

When you say “Products&= #8221;, do you mean “Explorer, Chrome and Safari”. If so, that = might be a problem. In the IETF, we can’t talk about peoples products= . We have to talk about protocols.

 

3.  First WG draft of "trust model" document = (4 months).

4.  First WG draft of "public-key submission and c= ertificate installation" document (4 months).

5.  First WG draft of "certificate, CRL, and OCSP = profile" document (8 months).

6.  First WG draft of "certificate, CRL, and OCSP = processing" document (12 months).

7.  First WG draft of "certificate re-issuance&quo= t; document (4 months).

8.  First WG draft of "certificate renewal" d= ocument (4 months).

9.  First WG draft of "certificate revocation"= ; document (8 months).

10. IESG submission of "trust model" document= (16 months).

11. IESG submission of "public-key submission and = certificate installation" document (16 months).

12. IESG submission of "certificate, CRL, and OCSP= profile" document (20 months).

13. IESG submission of "certificate, CRL, and OCSP= processing" document (24 months).

14. IESG submission of "certificate re-issuance&qu= ot; document (16 months).

15. IESG submission of "certificate renewal" = document (16 months).

16. IESG submission of "certificate revocation&quo= t; document (20 months)

 

The schedule is predicated upon the group's ability to r= ecruit a sufficient number of editors and engage either the relevant produc= t experts or other experts willing to test the selected product configurati= ons.  

 

This is true for all WGs. The= re is no need to say it.

 

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A5704A6SOTTEXCH10corpa_-- From tim.moses@entrust.com Wed Aug 22 12:09:06 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 769EF21F8665 for ; Wed, 22 Aug 2012 12:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.323, 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 qydRMy+3Zpjv for ; Wed, 22 Aug 2012 12:09:05 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4025621F85EA for ; Wed, 22 Aug 2012 12:09:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,809,1344225600"; d="scan'208,217";a="5984654" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 22 Aug 2012 15:09:04 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Wed, 22 Aug 2012 15:09:04 -0400 From: Tim Moses To: "'wpkops@ietf.org'" Thread-Topic: IETF Process Thread-Index: Ac2AmZd6SddTWFH4S0iaQe0oqOM0Tw== Date: Wed, 22 Aug 2012 19:09:02 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A5706D0@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_5B68A271B9C97046963CB6A5B8D6F62C3A5706D0SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] IETF Process X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:09:06 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A5706D0SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For those unfamiliar with IETF process, here is some background reading. A= ll the best. Tim. - http://www.rfc-editor.org/rfc/rfc2026.txt describes the IETF Standards Pr= ocess - http://www.ietf.org/tao.html provides a general overview of how the IETF = works - http://tools.ietf.org/html/rfc5434 provides guidelines for a successful B= oF T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A5706D0SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For those unfamiliar with IETF process, here is some= background reading.  All the best.  Tim.

 

- http://www.rfc-editor.org/rfc/rfc2026.txt describes the IETF Sta= ndards Process

- http:/= /www.ietf.org/tao.html provides a general overview of how the IETF work= s

- = http://tools.ietf.org/html/rfc5434 provides guidelines for a successful= BoF

 

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A5706D0SOTTEXCH10corpa_-- From tim.moses@entrust.com Wed Aug 22 12:23:37 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 F2F8E21F85F4 for ; Wed, 22 Aug 2012 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.287, 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 mzThP1YXF5T9 for ; Wed, 22 Aug 2012 12:23:34 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3189421F850C for ; Wed, 22 Aug 2012 12:23:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,809,1344225600"; d="scan'208,217";a="1678481" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 22 Aug 2012 15:23:31 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Wed, 22 Aug 2012 15:23:31 -0400 From: Tim Moses To: "'wpkops@ietf.org'" Thread-Topic: What's the strategy? Thread-Index: Ac2Am5x5d2gMV5uJT8mO4FUNt5AZnw== Date: Wed, 22 Aug 2012 19:23:30 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A570712@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_5B68A271B9C97046963CB6A5B8D6F62C3A570712SOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] What's the strategy? X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 19:23:37 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A570712SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues - This is by way of explaining some of the background to this ma= il list. As you may be aware, the IETF's PKIX working group will be wound up some ti= me in the next few months. The members of PKIX have worked hard over the l= ast 16 years to define how PKI should be practiced in large and extended en= terprises. That work is now nearing completion. Those whose interest is PKI as practiced in the Web, working together in th= e CA/Browser Forum, have also accomplished much in the seven years of its e= xistence. But, the Forum has consistently stated its intention not to prod= uce and maintain technical standards. So, its members have often turned to= PKIX for their standard protocol needs. Now, that facility is about to di= sappear, even though the Forum's work is far from complete. In order to illustrate the point, here are some examples of ongoing technic= al discussions: the best way to accomplish revocation; how to augment the t= rust model to improve observability; and whether and how to implement short= -lived certificates. These, and similar outstanding questions, have to be = addressed in a coordinated fashion across all components of the eco-system,= including: browser/OS, Web server, load balancer, and certification author= ity, and both with those who supply the products and those who operate them= . The IETF's Security Area directors have identified a need for a new forum i= n which issues such as these can be discussed and advanced. And, to that e= nd, this mail list has been established and a BoF at the IETF's Atlanta mee= ting in November of this year is under consideration. Initial indications are that there is enthusiastic support for the idea. B= ut, success will depend upon having the right experts actively involved. T= heir willingness remains to be confirmed. The IETF will decide whether to = set aside time for a BoF on 24 Sep or thereabouts. So, there is some urgen= cy to progressing the matter. We have to answer some fundamental questions, such as: 1. How broad is the recognition of the need? 2. Are all the essential constituents willing to participate? 3. What objective should the nascent working group set itself? Armed with the answers to these questions, the IETF planners will be in a p= osition to consider a request for a BoF and how best to accommodate the nee= ds of the Web PKI community. There is one idea that I would like you to consider: set up a working group= within the Operations and Management Area of the IETF to document how the = Web PKI actually works today. This would comprise a set of descriptive dra= fts covering the various certificate lifecycle phases: trust model, certifi= cate application and installation, certificate issuance, certificate renewa= l, certificate reissuance, certificate revocation, and certificate validati= on. There are many variants in use, and the idea would be to record as man= y of the important variants as possible. This might be accomplished within= one to two years, and the benefit would be two-fold: it would make it clea= rer which options are preferable; and it would allow time for the group to = cohere. My fear is that launching directly into writing prescriptive stand= ards will foster mutual suspicion and hold back progress. Once deliverables start to flow from this initial project, we may consider = forming other groups to advance standards or standard profiles for specific= aspects of the system. I hope that helps. All the best. Tim. T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A570712SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues – This is by way of explaining some= of the background to this mail list.

 

As you may be aware, the IETF’s PKIX working g= roup will be wound up some time in the next few months.  The members o= f PKIX have worked hard over the last 16 years to define how PKI should be = practiced in large and extended enterprises.  That work is now nearing completion.

 

Those whose interest is PKI as practiced in the Web,= working together in the CA/Browser Forum, have also accomplished much in t= he seven years of its existence.  But, the Forum has consistently stat= ed its intention not to produce and maintain technical standards.  So, its members have often turned to PKIX for t= heir standard protocol needs.  Now, that facility is about to disappea= r, even though the Forum’s work is far from complete.

 

In order to illustrate the point, here are some exam= ples of ongoing technical discussions: the best way to accomplish revocatio= n; how to augment the trust model to improve observability; and whether and= how to implement short-lived certificates.  These, and similar outstanding questions, have to be addressed in a coordi= nated fashion across all components of the eco-system, including: browser/O= S, Web server, load balancer, and certification authority, and both with th= ose who supply the products and those who operate them.

 

The IETF’s Security Area directors have identi= fied a need for a new forum in which issues such as these can be discussed = and advanced.  And, to that end, this mail list has been established a= nd a BoF at the IETF’s Atlanta meeting in November of this year is under consideration. 

 

Initial indications are that there is enthusiastic s= upport for the idea.  But, success will depend upon having the right e= xperts actively involved.  Their willingness remains to be confirmed.&= nbsp; The IETF will decide whether to set aside time for a BoF on 24 Sep or thereabouts.  So, there is some urgency to pro= gressing the matter.

 

We have to answer some fundamental questions, such a= s:

 

1.     &= nbsp; How broad is the recognition of the need?

2.     &= nbsp; Are all the essential constituents willing to parti= cipate?

3.     &= nbsp; What objective should the nascent working group set= itself?

Armed with the answers to these questions, the IETF = planners will be in a position to consider a request for a BoF and how best= to accommodate the needs of the Web PKI community.

 

There is one idea that I would like you to consider:= set up a working group within the Operations and Management Area of the IE= TF to document how the Web PKI actually works today.  This would compr= ise a set of descriptive drafts covering the various certificate lifecycle phases: trust model, certificate applica= tion and installation, certificate issuance, certificate renewal, certifica= te reissuance, certificate revocation, and certificate validation.  Th= ere are many variants in use, and the idea would be to record as many of the important variants as possible.&nbs= p; This might be accomplished within one to two years, and the benefit woul= d be two-fold: it would make it clearer which options are preferable; and i= t would allow time for the group to cohere.  My fear is that launching directly into writing prescriptive standards wil= l foster mutual suspicion and hold back progress. 

 

Once deliverables start to flow from this initial pr= oject, we may consider forming other groups to advance standards or standar= d profiles for specific aspects of the system.

 

I hope that helps.  All the best.  Tim.

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A570712SOTTEXCH10corpa_-- From stephen.farrell@cs.tcd.ie Wed Aug 22 13:15:15 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 1383021F8691 for ; Wed, 22 Aug 2012 13:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74qBvpyxIEUG for ; Wed, 22 Aug 2012 13:15:11 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD6621F867E for ; Wed, 22 Aug 2012 13:15:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D0DA3171491; Wed, 22 Aug 2012 21:15:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1345666507; bh=nInHXXhXxZFO3K +ZbcxmHemcmohprJ2Y6sJ//5lX23Y=; b=4W5aNOfLDGYod0u+WdP58GLHu5iMEY Gp25VeoX6Wyy3nPgYIrmn3sbvqWltjaBDb1JRUITp7k9VqZQLkd+YvcFQKlrPKuI 2xVuQqRTz+EeDX/WmDynkZBBMXK7JiLNDlCywv5VRLajw3MPBy7dgDGQxRbwjY7p ByCjv+Pe+uQLXXjXKB3ffVmMWa+8cDp903UNXiuyKEVtMW9Pxq3mPmNycFhKg0+0 SkNujQ0GzXeS9UsEReXTmjOiNkJFQQLylCddvFvJASrNW3Lcg6RDa2D+mNmdxQo4 HKK/GmsbHPSSxps8uTV1W2BW0RkOCFHCHnoDBtiVUzY0SKBKkg6vO2qg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id qSjiwyeNufg0; Wed, 22 Aug 2012 21:15:07 +0100 (IST) Received: from [10.87.48.7] (unknown [86.44.66.66]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D3BFC171474; Wed, 22 Aug 2012 21:15:05 +0100 (IST) Message-ID: <50353DC9.7010905@cs.tcd.ie> Date: Wed, 22 Aug 2012 21:15:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A5706D0@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A5706D0@SOTTEXCH10.corp.ad.entrust.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'wpkops@ietf.org'" Subject: Re: [wpkops] IETF Process X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:15:15 -0000 Thanks Tim, Just to be clear and for the archive: For this activity we're hoping we'll have a BoF at the Atlanta IETF meeting [1] in November with the goal of forming a working group along the lines of Tim's other mail. The decision as to whether the BoF will be approved will be made around September 23rd. If approved, the actual date won't be known until about 2 weeks before the meeting. So far, interest levels in this seem good, but postings to this list to the effect that this is a good/bad idea for IETF work (saying why) before then are very useful, as are thoughts on the early charter text that Tim posted. Cheers, S. PS: If anyone has process questions they'd like answered just mail the list and ask. If you're shy, then feel free to mail me or Ron offlist. [1] http://www.ietf.org/meeting/85/index.html On 08/22/2012 08:09 PM, Tim Moses wrote: > For those unfamiliar with IETF process, here is some background reading. All the best. Tim. > > > - http://www.rfc-editor.org/rfc/rfc2026.txt describes the IETF Standards Process > > - http://www.ietf.org/tao.html provides a general overview of how the IETF works > > - http://tools.ietf.org/html/rfc5434 provides guidelines for a successful BoF > > > T: +1 613 270 3183 > > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From stephen.farrell@cs.tcd.ie Wed Aug 22 13:33:25 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 242EA21F85EA for ; Wed, 22 Aug 2012 13:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU4mraUaDa5g for ; Wed, 22 Aug 2012 13:33:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 911C721F85A7 for ; Wed, 22 Aug 2012 13:33:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 57138171491; Wed, 22 Aug 2012 21:33:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1345667593; bh=nbLBTnjqHwc6HQ DzEaEqUx9FN3luPQ0E1ycZCO/lSl0=; b=2VBJ6qaqDm54dbLqsuxwM49gtiz4Pq ocHIMSYor2TKWZcsfyJJyb4dyIOweP0sMwLN4fP33b7LjBfdDjzI+bYh0JBR5ePf t5/pA2SlGYeqP4rF0BZYTWw72ce/nkjSm7qzNyZnd7eTwoR94NOIEyVp4gVN4rIm ArNl9lr0+pnpJw0arvLmMOTsngON8oyMsara9loV864rC++BZaTtUZ41aNefyPwx gx4ccc4BnQsRESZnw5jCovxvdmnKuzcoOsImDxcSMpQOg+LwSCdDoF1qRQ5j5kdO iA5u+mSsRAWPv1DJEfk2H0lUeWgb04kW1d7i1uqVKc2VDBzEpt7WjG6w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cwfrg0FPavtM; Wed, 22 Aug 2012 21:33:13 +0100 (IST) Received: from [10.87.48.7] (unknown [86.44.66.66]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E942A171474; Wed, 22 Aug 2012 21:33:12 +0100 (IST) Message-ID: <50354208.3070902@cs.tcd.ie> Date: Wed, 22 Aug 2012 21:33:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'wpkops@ietf.org'" Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:33:25 -0000 Thanks Tim for that. I agree with Ron - that's a really good start, but does need work. My initial thoughts on that: - I think the milestone list you presented is too detailed for a charter, especially at this point. But I'd say that can be left for now though until the overall scope is clearer. So fix that later and let's try focus on the scope for now. - I'm not sure that omitting code signing is a good plan, since the same libraries and trust anchors are used and code-signing has been a recent attack vector of note. Omitting document signing and email seems ok to me though as those are much more enterprisey things, but HTTPS and code-signing are both common on the public Internet. So I'd like to understand that better. - I think the putative OPS WG ought document deployed stuff as you say, but beyond that its scope ought be explicitly limited to developing (at most) use-cases and/or requirements for any new protocol. So I'm not at all sure how to interpret some of the deliverables you envisage. For example, what's the "certificate, CRL, and OCSP profile" document? If that means "invent a new profile" then I have a problem with that. If it means "document deployed deviations from 5280/2560" then that'd be fine I think but then it ought have a different name. - As Ron said, the IETF doesn't do product evaluations but I think that's an easy one, just include in scope documenting the behaviour of "recent" browsers, web servers and (I guess) relevant middleboxen, so long as they have non-trivial deployment. Cheers, S. On 08/22/2012 01:44 PM, Tim Moses wrote: > Colleagues - Here is a first draft of a charter proposal. Please give it some thought and share the results of your deliberations. Thanks a lot. All the best. Tim. > > > The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. It 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 hundreds of variations on the Web PKI in regular use. And this can be a source of problems both for end-users and certificate issuers. > > > > For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, 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. > > > > And for 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 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. > > > > 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 (other than the Web) may use the same trust anchors as the ones used by the Web. These applications include: document signing; code signing; and email. They may use PKI in a way that differs from the way in which the Web uses it. Therefore, these applications are explicitly out of scope for the working group. > > > > Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers. However, the topic of practices is outside the scope of the IETF. Therefore, this will be left to other competent bodies. > > > > That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. 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, it is agreed that adherence to the published schedule should take precedence over completeness of the results. The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today. > > > > The output documents will all be BCP-style RFCs. > > > > 1. Agree the working group charter (1 month). > > 2. Catalog the products and versions to be analyzed (1 month). > > 3. First WG draft of "trust model" document (4 months). > > 4. First WG draft of "public-key submission and certificate installation" document (4 months). > > 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 months). > > 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 months). > > 7. First WG draft of "certificate re-issuance" document (4 months). > > 8. First WG draft of "certificate renewal" document (4 months). > > 9. First WG draft of "certificate revocation" document (8 months). > > 10. IESG submission of "trust model" document (16 months). > > 11. IESG submission of "public-key submission and certificate installation" document (16 months). > > 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months). > > 13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months). > > 14. IESG submission of "certificate re-issuance" document (16 months). > > 15. IESG submission of "certificate renewal" document (16 months). > > 16. IESG submission of "certificate revocation" document (20 months) > > > > The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations. > > > T: +1 613 270 3183 > > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From tim.moses@entrust.com Wed Aug 22 13:56:42 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 6684A21F86B6 for ; Wed, 22 Aug 2012 13:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 RzBPFqgh0jYd for ; Wed, 22 Aug 2012 13:56:40 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 32CDF21F85B1 for ; Wed, 22 Aug 2012 13:56:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,296,1344225600"; d="scan'208";a="1681295" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 22 Aug 2012 16:56:37 -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.001; Wed, 22 Aug 2012 16:56:36 -0400 From: Tim Moses To: 'Stephen Farrell' Thread-Topic: [wpkops] First draft charter proposal Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQAYvGQAAAfp/gA= Date: Wed, 22 Aug 2012 20:56:36 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A571AAD@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <50354208.3070902@cs.tcd.ie> In-Reply-To: <50354208.3070902@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'wpkops@ietf.org'" Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:56:42 -0000 Thanks Stephen. To explain ... when I suggested a profiling activity, I ha= d in mind to describe the subset of PKIX that is actually used in the Web P= KI (as well as non-conformant variations). For instance, I don't believe a= ny publicly-trusted CAs issue delta CRLs or that any browsers use OCSP nonc= es. If this is true, then it isn't recorded in any one place. I had in mi= nd to record those facts. And, there are - no doubt - many other features = of RFC 5280 that are not exercised in the Web PKI. Do that seem appropriat= e to you? All the best. Tim. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Wednesday, August 22, 2012 4:33 PM To: Tim Moses Cc: 'wpkops@ietf.org' Subject: Re: [wpkops] First draft charter proposal Thanks Tim for that. I agree with Ron - that's a really good start, but does need work. My initial thoughts on that: - I think the milestone list you presented is too detailed for a charter, e= specially at this point. But I'd say that can be left for now though until = the overall scope is clearer. So fix that later and let's try focus on the = scope for now. - I'm not sure that omitting code signing is a good plan, since the same li= braries and trust anchors are used and code-signing has been a recent attac= k vector of note. Omitting document signing and email seems ok to me though= as those are much more enterprisey things, but HTTPS and code-signing are = both common on the public Internet. So I'd like to understand that better. - I think the putative OPS WG ought document deployed stuff as you say, but= beyond that its scope ought be explicitly limited to developing (at most) = use-cases and/or requirements for any new protocol. So I'm not at all sure = how to interpret some of the deliverables you envisage. For example, what's= the "certificate, CRL, and OCSP profile" document? If that means "invent a= new profile" then I have a problem with that. If it means "document deploy= ed deviations from 5280/2560" then that'd be fine I think but then it ought= have a different name. - As Ron said, the IETF doesn't do product evaluations but I think that's a= n easy one, just include in scope documenting the behaviour of "recent" bro= wsers, web servers and (I guess) relevant middleboxen, so long as they have= non-trivial deployment. Cheers, S. On 08/22/2012 01:44 PM, Tim Moses wrote: > Colleagues - Here is a first draft of a charter proposal. Please give it= some thought and share the results of your deliberations. Thanks a lot. = All the best. Tim. >=20 >=20 > The Web PKI is the set of systems and procedures most commonly used to pr= otect the confidentiality, integrity and authenticity of communications bet= ween Web browsers and Web content servers. It first appeared in 1993 or th= ereabouts and has developed continuously in a somewhat organic fashion sinc= e 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 t= his can be a source of problems both for end-users and certificate issuers. >=20 >=20 >=20 > For end-users, there is no clear view whether certificate "problems" rema= in when they see indication of a "good" connection. For instance, in some = browsers, a "good" indication may be displayed when a "revoked" response ha= s been received and "accepted" by the user. Whereas, other browsers may re= fuse to display the contents under these circumstances. >=20 >=20 >=20 > And for issuers, it can be difficult to predict what proportion of the us= er population will accept a certificate chain with 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 k= now which browsers will accept and which will reject the response. >=20 >=20 >=20 > Starting from the premise that more consistency in Web security behavior = is desirable, a natural first step would be to document current and histori= c browser and server behavior. >=20 >=20 >=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 >=20 >=20 > Additionally, a number of applications (other than the Web) may use the s= ame trust anchors as the ones used by the Web. These applications include:= document signing; code signing; and email. They may use PKI in a way that= differs from the way in which the Web uses it. Therefore, these applicati= ons are explicitly out of scope for the working group. >=20 >=20 >=20 > Also, the reliability of the Web PKI depends critically on the practices = of its certificate issuers. However, the topic of practices is outside the= scope of the IETF. Therefore, this will be left to other competent bodies= . >=20 >=20 >=20 > That there are technical shortcomings with Web PKI, as it is practiced to= day, is well recognized. And, that there is also some urgency in addressin= g these shortcomings is also well recognized. But, it is felt that too muc= h haste can be counter-productive. The expectation is that the work of thi= s group will bring to light, in a systematic way, aspects of the Web PKI th= at should be progressed in future working groups of the IETF's Security Are= a, and that suppliers will be willing to participate in those working group= s and modify their products to comply with their standards. >=20 >=20 >=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 preceden= ce over completeness of the results. The working group should focus its in= itial attention on the browser and server versions that make up the largest= part of the desktop and mobile Web today. >=20 >=20 >=20 > The output documents will all be BCP-style RFCs. >=20 >=20 >=20 > 1. Agree the working group charter (1 month). >=20 > 2. Catalog the products and versions to be analyzed (1 month). >=20 > 3. First WG draft of "trust model" document (4 months). >=20 > 4. First WG draft of "public-key submission and certificate installati= on" document (4 months). >=20 > 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 = months). >=20 > 6. First WG draft of "certificate, CRL, and OCSP processing" document = (12 months). >=20 > 7. First WG draft of "certificate re-issuance" document (4 months). >=20 > 8. First WG draft of "certificate renewal" document (4 months). >=20 > 9. First WG draft of "certificate revocation" document (8 months). >=20 > 10. IESG submission of "trust model" document (16 months). >=20 > 11. IESG submission of "public-key submission and certificate installatio= n" document (16 months). >=20 > 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 = months). >=20 > 13. IESG submission of "certificate, CRL, and OCSP processing" document (= 24 months). >=20 > 14. IESG submission of "certificate re-issuance" document (16 months). >=20 > 15. IESG submission of "certificate renewal" document (16 months). >=20 > 16. IESG submission of "certificate revocation" document (20 months) >=20 >=20 >=20 > The schedule is predicated upon the group's ability to recruit a sufficie= nt number of editors and engage either the relevant product experts or othe= r experts willing to test the selected product configurations. >=20 >=20 > T: +1 613 270 3183 >=20 >=20 >=20 >=20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 From rturner@amalfisystems.com Wed Aug 22 14:17:49 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 E8AA021F84A7 for ; Wed, 22 Aug 2012 14:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 9PmkW3IUYHRO for ; Wed, 22 Aug 2012 14:17:49 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id C353D21F84A6 for ; Wed, 22 Aug 2012 14:17:48 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7MLHeuA001177 for ; Wed, 22 Aug 2012 17:17:46 -0400 X-Authenticated-IP: 98.151.18.90 Received: from [98.151.18.90] ([98.151.18.90:63594] helo=[192.168.1.106]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id A6/CD-04944-D6C45305; Wed, 22 Aug 2012 17:17:34 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Randy Turner In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A571AAD@SOTTEXCH10.corp.ad.entrust.com> Date: Wed, 22 Aug 2012 14:17:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <50354208.3070902@cs.tcd.ie> <5B68A271B9C97046963CB6A5B8D6F62C3A571AAD@SOTTEXCH10.corp.ad.entrust.com> To: wpkops@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:17:50 -0000 Hi Tim, I think the problem space you are defining does definitely need some = discipline applied to the mostly organic evolution of PKI, as = experienced by end users, typically through browsers. Based on the knowledge gained (acquired) from the participants and their = experiences + any landscape analysis of currently shipping behaviors, I = think there should be enough "meat" there to justify a WG. I am expecting (read "hoping") that what will come out of this work = however, will not strictly apply to browsers and content servers. I would think most of the issues/problems and subsequent requirements = would probably form a BCP for any user-facing application that utilizes = PKI - not just browsers and servers. No doubt, there will be some use-cases that are browser/server-centric, = but I think it might be a "short walk" to factor out the = browser/content-server specifics to realize a benefit for PKI apps in = general. I know Stephen may think that email and document signing is more = "enterprise-y", but if you're going to bring the subject of "signing" of = content into the problem space, any user-facing application that = performs signatures should be able to benefit.=20 Randy On Aug 22, 2012, at 1:56 PM, Tim Moses wrote: > Thanks Stephen. To explain ... when I suggested a profiling activity, = I had in mind to describe the subset of PKIX that is actually used in = the Web PKI (as well as non-conformant variations). For instance, I = don't believe any publicly-trusted CAs issue delta CRLs or that any = browsers use OCSP nonces. If this is true, then it isn't recorded in = any one place. I had in mind to record those facts. And, there are - = no doubt - many other features of RFC 5280 that are not exercised in the = Web PKI. Do that seem appropriate to you? >=20 > All the best. Tim. >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 > Sent: Wednesday, August 22, 2012 4:33 PM > To: Tim Moses > Cc: 'wpkops@ietf.org' > Subject: Re: [wpkops] First draft charter proposal >=20 >=20 > Thanks Tim for that. >=20 > I agree with Ron - that's a really good start, but does need work. >=20 > My initial thoughts on that: >=20 > - I think the milestone list you presented is too detailed for a = charter, especially at this point. But I'd say that can be left for now = though until the overall scope is clearer. So fix that later and let's = try focus on the scope for now. >=20 > - I'm not sure that omitting code signing is a good plan, since the = same libraries and trust anchors are used and code-signing has been a = recent attack vector of note. Omitting document signing and email seems = ok to me though as those are much more enterprisey things, but HTTPS and = code-signing are both common on the public Internet. So I'd like to = understand that better. >=20 > - I think the putative OPS WG ought document deployed stuff as you = say, but beyond that its scope ought be explicitly limited to developing = (at most) use-cases and/or requirements for any new protocol. So I'm not = at all sure how to interpret some of the deliverables you envisage. For = example, what's the "certificate, CRL, and OCSP profile" document? If = that means "invent a new profile" then I have a problem with that. If it = means "document deployed deviations from 5280/2560" then that'd be fine = I think but then it ought have a different name. >=20 > - As Ron said, the IETF doesn't do product evaluations but I think = that's an easy one, just include in scope documenting the behaviour of = "recent" browsers, web servers and (I guess) relevant middleboxen, so = long as they have non-trivial deployment. >=20 > Cheers, > S. >=20 > On 08/22/2012 01:44 PM, Tim Moses wrote: >> Colleagues - Here is a first draft of a charter proposal. Please = give it some thought and share the results of your deliberations. = Thanks a lot. All the best. Tim. >>=20 >>=20 >> The Web PKI is the set of systems and procedures most commonly used = to protect the confidentiality, integrity and authenticity of = communications between Web browsers and Web content servers. It 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 hundreds of variations = on the Web PKI in regular use. And this can be a source of problems = both for end-users and certificate issuers. >>=20 >>=20 >>=20 >> For end-users, there is no clear view whether certificate "problems" = remain when they see indication of a "good" connection. For instance, = in some browsers, 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. >>=20 >>=20 >>=20 >> And for 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 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 >>=20 >>=20 >> 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. >>=20 >>=20 >>=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 >>=20 >>=20 >> Additionally, a number of applications (other than the Web) may use = the same trust anchors as the ones used by the Web. These applications = include: document signing; code signing; and email. They may use PKI in = a way that differs from the way in which the Web uses it. Therefore, = these applications are explicitly out of scope for the working group. >>=20 >>=20 >>=20 >> Also, the reliability of the Web PKI depends critically on the = practices of its certificate issuers. However, the topic of practices = is outside the scope of the IETF. Therefore, this will be left to other = competent bodies. >>=20 >>=20 >>=20 >> That there are technical shortcomings with Web PKI, as it is = practiced today, is well recognized. And, that there is also some = urgency in addressing these shortcomings is also well recognized. 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. >>=20 >>=20 >>=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. The working group should = focus its initial attention on the browser and server versions that make = up the largest part of the desktop and mobile Web today. >>=20 >>=20 >>=20 >> The output documents will all be BCP-style RFCs. >>=20 >>=20 >>=20 >> 1. Agree the working group charter (1 month). >>=20 >> 2. Catalog the products and versions to be analyzed (1 month). >>=20 >> 3. First WG draft of "trust model" document (4 months). >>=20 >> 4. First WG draft of "public-key submission and certificate = installation" document (4 months). >>=20 >> 5. First WG draft of "certificate, CRL, and OCSP profile" document = (8 months). >>=20 >> 6. First WG draft of "certificate, CRL, and OCSP processing" = document (12 months). >>=20 >> 7. First WG draft of "certificate re-issuance" document (4 = months). >>=20 >> 8. First WG draft of "certificate renewal" document (4 months). >>=20 >> 9. First WG draft of "certificate revocation" document (8 months). >>=20 >> 10. IESG submission of "trust model" document (16 months). >>=20 >> 11. IESG submission of "public-key submission and certificate = installation" document (16 months). >>=20 >> 12. IESG submission of "certificate, CRL, and OCSP profile" document = (20 months). >>=20 >> 13. IESG submission of "certificate, CRL, and OCSP processing" = document (24 months). >>=20 >> 14. IESG submission of "certificate re-issuance" document (16 = months). >>=20 >> 15. IESG submission of "certificate renewal" document (16 months). >>=20 >> 16. IESG submission of "certificate revocation" document (20 months) >>=20 >>=20 >>=20 >> The schedule is predicated upon the group's ability to recruit a = sufficient number of editors and engage either the relevant product = experts or other experts willing to test the selected product = configurations. >>=20 >>=20 >> T: +1 613 270 3183 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >>=20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 From md@ssc.lt Wed Aug 22 14:22:50 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 8F80C21F8545 for ; Wed, 22 Aug 2012 14:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, 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 Kx9vNaegXmoQ for ; Wed, 22 Aug 2012 14:22:49 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1833521F8495 for ; Wed, 22 Aug 2012 14:22:49 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.101]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1T4INy-0007jD-5D; Thu, 23 Aug 2012 00:22:46 +0300 Message-ID: <50354DA8.4080501@ssc.lt> Date: Thu, 23 Aug 2012 00:22:48 +0300 From: "Moudrick M. Dadashov" Organization: Skaitmeninio sertifikavimo centras User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Turner References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <50354208.3070902@cs.tcd.ie> <5B68A271B9C97046963CB6A5B8D6F62C3A571AAD@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: wpkops@ietf.org Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:22:50 -0000 +1 Thanks, M.D. On 8/23/2012 12:17 AM, Randy Turner wrote: > Hi Tim, > > I think the problem space you are defining does definitely need some discipline applied to the mostly organic evolution of PKI, as experienced by end users, typically through browsers. > > Based on the knowledge gained (acquired) from the participants and their experiences + any landscape analysis of currently shipping behaviors, I think there should be enough "meat" there to justify a WG. > > I am expecting (read "hoping") that what will come out of this work however, will not strictly apply to browsers and content servers. > > I would think most of the issues/problems and subsequent requirements would probably form a BCP for any user-facing application that utilizes PKI - not just browsers and servers. > > No doubt, there will be some use-cases that are browser/server-centric, but I think it might be a "short walk" to factor out the browser/content-server specifics to realize a benefit for PKI apps in general. > > I know Stephen may think that email and document signing is more "enterprise-y", but if you're going to bring the subject of "signing" of content into the problem space, any user-facing application that performs signatures should be able to benefit. > > Randy > > > On Aug 22, 2012, at 1:56 PM, Tim Moses wrote: > >> Thanks Stephen. To explain ... when I suggested a profiling activity, I had in mind to describe the subset of PKIX that is actually used in the Web PKI (as well as non-conformant variations). For instance, I don't believe any publicly-trusted CAs issue delta CRLs or that any browsers use OCSP nonces. If this is true, then it isn't recorded in any one place. I had in mind to record those facts. And, there are - no doubt - many other features of RFC 5280 that are not exercised in the Web PKI. Do that seem appropriate to you? >> >> All the best. Tim. >> >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Wednesday, August 22, 2012 4:33 PM >> To: Tim Moses >> Cc: 'wpkops@ietf.org' >> Subject: Re: [wpkops] First draft charter proposal >> >> >> Thanks Tim for that. >> >> I agree with Ron - that's a really good start, but does need work. >> >> My initial thoughts on that: >> >> - I think the milestone list you presented is too detailed for a charter, especially at this point. But I'd say that can be left for now though until the overall scope is clearer. So fix that later and let's try focus on the scope for now. >> >> - I'm not sure that omitting code signing is a good plan, since the same libraries and trust anchors are used and code-signing has been a recent attack vector of note. Omitting document signing and email seems ok to me though as those are much more enterprisey things, but HTTPS and code-signing are both common on the public Internet. So I'd like to understand that better. >> >> - I think the putative OPS WG ought document deployed stuff as you say, but beyond that its scope ought be explicitly limited to developing (at most) use-cases and/or requirements for any new protocol. So I'm not at all sure how to interpret some of the deliverables you envisage. For example, what's the "certificate, CRL, and OCSP profile" document? If that means "invent a new profile" then I have a problem with that. If it means "document deployed deviations from 5280/2560" then that'd be fine I think but then it ought have a different name. >> >> - As Ron said, the IETF doesn't do product evaluations but I think that's an easy one, just include in scope documenting the behaviour of "recent" browsers, web servers and (I guess) relevant middleboxen, so long as they have non-trivial deployment. >> >> Cheers, >> S. >> >> On 08/22/2012 01:44 PM, Tim Moses wrote: >>> Colleagues - Here is a first draft of a charter proposal. Please give it some thought and share the results of your deliberations. Thanks a lot. All the best. Tim. >>> >>> >>> The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. It 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 hundreds of variations on the Web PKI in regular use. And this can be a source of problems both for end-users and certificate issuers. >>> >>> >>> >>> For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, 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. >>> >>> >>> >>> And for 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 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. >>> >>> >>> >>> 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 (other than the Web) may use the same trust anchors as the ones used by the Web. These applications include: document signing; code signing; and email. They may use PKI in a way that differs from the way in which the Web uses it. Therefore, these applications are explicitly out of scope for the working group. >>> >>> >>> >>> Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers. However, the topic of practices is outside the scope of the IETF. Therefore, this will be left to other competent bodies. >>> >>> >>> >>> That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. 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, it is agreed that adherence to the published schedule should take precedence over completeness of the results. The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today. >>> >>> >>> >>> The output documents will all be BCP-style RFCs. >>> >>> >>> >>> 1. Agree the working group charter (1 month). >>> >>> 2. Catalog the products and versions to be analyzed (1 month). >>> >>> 3. First WG draft of "trust model" document (4 months). >>> >>> 4. First WG draft of "public-key submission and certificate installation" document (4 months). >>> >>> 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 months). >>> >>> 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 months). >>> >>> 7. First WG draft of "certificate re-issuance" document (4 months). >>> >>> 8. First WG draft of "certificate renewal" document (4 months). >>> >>> 9. First WG draft of "certificate revocation" document (8 months). >>> >>> 10. IESG submission of "trust model" document (16 months). >>> >>> 11. IESG submission of "public-key submission and certificate installation" document (16 months). >>> >>> 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months). >>> >>> 13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months). >>> >>> 14. IESG submission of "certificate re-issuance" document (16 months). >>> >>> 15. IESG submission of "certificate renewal" document (16 months). >>> >>> 16. IESG submission of "certificate revocation" document (20 months) >>> >>> >>> >>> The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations. >>> >>> >>> T: +1 613 270 3183 >>> >>> >>> >>> >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >>> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops From bhill@paypal-inc.com Wed Aug 22 14:27:48 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 5C2F921F8471 for ; Wed, 22 Aug 2012 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.037 X-Spam-Level: X-Spam-Status: No, score=-9.037 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, 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 WjotGJwkMDM2 for ; Wed, 22 Aug 2012 14:27:44 -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 1BB6321F843F for ; Wed, 22 Aug 2012 14:27:44 -0700 (PDT) DomainKey-Signature: s=ppinc; 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: x-ems-proccessed:x-ems-stamp:Content-Type:MIME-Version: X-CFilter; b=iesZbedPFaOYzaqRaO3bUNOww6lCxhwcnD412VNH2vnA2zE7kBYMCXvU ZYI72jWWoe0mxqKF80KH2ceINvCW4Y3q5J4TQb6gHs2y9PpuKoGlE41gL CuztaRVrcjF101e; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1345670864; x=1377206864; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NTmJ4SGKWbEk8jLwJhwtXOBPcNy26ccELsyLVeVnkSs=; b=VU/K47WxVANOmKrIeHXkuISSBR5FT+09DwBtl4IZH0sTug9l/TORcT/C ugGQO6JphCuhRz4z29wcUMKauygDEmvMx0bsyf3syhJSW4F4NODCXtl2K 4sakpJ6VjXDbIH9; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,296,1344236400"; d="scan'208,217";a="9799596" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-005.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 22 Aug 2012 14:27:44 -0700 Received: from DEN-EXDDA-S11.corp.ebay.com ([fe80::74c6:c884:c352:716]) by DEN-EXMHT-005.corp.ebay.com ([fe80::8109:2a37:17ad:e57e%18]) with mapi id 14.02.0298.004; Wed, 22 Aug 2012 15:27:41 -0600 From: "Hill, Brad" To: Tim Moses , "'wpkops@ietf.org'" Thread-Topic: First draft charter proposal Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQASI2Wg Date: Wed, 22 Aug 2012 21:27:40 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@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.245.27.243] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: wPOHkl5jap8+Vgq5qfP3Qw== Content-Type: multipart/alternative; boundary="_000_370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6DENEXDDAS11corpeb_" MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:27:48 -0000 --_000_370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6DENEXDDAS11corpeb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Tim that we should start with a narrow scope focused on the We= b PKI rather than documents, etc., I also think there are cases that are o= n the edge - like the programmatic HTTP clients used by mobile aps, embedde= d browsing contexts with different PKI error handling logic than standalone= ones, and, towards the more complex end, web services that use HTTP and th= e web PKI explicitly but might also use other transports and trust models. = Not clear from the draft charter where to draw the line among these, but t= here is plenty of work to do and that needs doing urgently. Brad Hill From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Tim Moses Sent: Wednesday, August 22, 2012 5:45 AM To: 'wpkops@ietf.org' Subject: [wpkops] First draft charter proposal Colleagues - Here is a first draft of a charter proposal. Please give it s= ome thought and share the results of your deliberations. Thanks a lot. Al= l the best. Tim. The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems both for end-users and certificate issuers. 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 refu= se to display the contents under these circumstances. And for 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 se= rver supplies a response that does not include the nonce, it is hard to kno= w 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. 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 (other than the Web) may use the sam= e trust anchors as the ones used by the Web. These applications include: d= ocument signing; code signing; and email. They may use PKI in a way that d= iffers from the way in which the Web uses it. Therefore, these application= s are explicitly out of scope for the working group. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers. However, the topic of practices is outside the s= cope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. 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. The working group should focus its init= ial attention on the browser and server versions that make up the largest p= art of the desktop and mobile Web today. The output documents will all be BCP-style RFCs. 1. Agree the working group charter (1 month). 2. Catalog the products and versions to be analyzed (1 month). 3. First WG draft of "trust model" document (4 months). 4. First WG draft of "public-key submission and certificate installation" = document (4 months). 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 mont= hs). 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 = months). 7. First WG draft of "certificate re-issuance" document (4 months). 8. First WG draft of "certificate renewal" document (4 months). 9. First WG draft of "certificate revocation" document (8 months). 10. IESG submission of "trust model" document (16 months). 11. IESG submission of "public-key submission and certificate installation"= document (16 months). 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 mo= nths). 13. IESG submission of "certificate, CRL, and OCSP processing" document (24= months). 14. IESG submission of "certificate re-issuance" document (16 months). 15. IESG submission of "certificate renewal" document (16 months). 16. IESG submission of "certificate revocation" document (20 months) The schedule is predicated upon the group's ability to recruit a sufficient= number of editors and engage either the relevant product experts or other = experts willing to test the selected product configurations. T: +1 613 270 3183 --_000_370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6DENEXDDAS11corpeb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Tim that = we should start with a narrow scope focused on the Web PKI rather than docu= ments, etc.,  I also think there are cases that are on the edge –= ; like the programmatic HTTP clients used by mobile aps, embedded browsing contexts with different PKI error handling logic th= an standalone ones, and, towards the more complex end, web services that us= e HTTP and the web PKI explicitly but might also use other transports and t= rust models.  Not clear from the draft charter where to draw the line among these, but there is plenty of w= ork to do and that needs doing urgently.

 

Brad Hill

 

From: wpkops-b= ounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 5:45 AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First draft charter proposal

 

Colleagues – Here is a first draft of a charte= r proposal.  Please give it some thought and share the results of your= deliberations.  Thanks a lot.  All the best.  Tim.

 

The Web PKI is the set of systems and procedures most co= mmonly used to protect the confidentiality, integrity and authenticity of c= ommunications between Web browsers and Web content servers.  It first = appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then.  Acr= oss all the suppliers and the point releases of their products, there are n= ow hundreds of variations on the Web PKI in regular use.  And this can= be a source of problems both for end-users and certificate issuers.

 

For end-users, there is no clear view whether certificat= e "problems" remain when they see indication of a "good"= ; connection.  For instance, in some browsers, a "good" indi= cation may be displayed when a "revoked" response has been receiv= ed and "accepted" by the user.  Whereas, other browsers may refuse= to display the contents under these circumstances.

 

And for issuers, it can be difficult to predict what pro= portion 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 server supplies a response that does not include the nonce, it is hard to know which browser= s will accept and which will reject the response.

 

Starting from the premise that more consistency in Web s= ecurity behavior is desirable, a natural first step would be to document cu= rrent and historic browser and server behavior.

 

Future activities may attempt to prescribe how the Web P= KI "should" work, and the prescription may turn out to be a prope= r 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 t= he set of browsers and servers that are in common use today.

 

Additionally, a number of applications (other than the W= eb) may use the same trust anchors as the ones used by the Web.  These= applications include: document signing; code signing; and email.  The= y may use PKI in a way that differs from the way in which the Web uses it.  Therefore, these applications are expl= icitly out of scope for the working group.

 

Also, the reliability of the Web PKI depends critically = on the practices of its certificate issuers.  However, the topic of pr= actices is outside the scope of the IETF.  Therefore, this will be lef= t to other competent bodies.

 

That there are technical shortcomings with Web PKI, as i= t is practiced today, is well recognized.  And, that there is also som= e urgency in addressing these shortcomings is also well recognized.  B= ut, 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 s= ystematic way, aspects of the Web PKI that should be progressed in future w= orking groups of the IETF's Security Area, and that suppliers will be willi= ng to participate in those working groups and modify their products to comply with their standards.

 

Given the urgency of the required developments and the s= cale of the task, it is agreed that adherence to the published schedule sho= uld take precedence over completeness of the results.  The working gro= up should focus its initial attention on the browser and server versions that make up the largest part of the deskt= op and mobile Web today.

 

The output documents will all be BCP-style RFCs.

 

1.  Agree the working group charter (1 month).

2.  Catalog the products and versions to be analyzed (1= month).

3.  First WG draft of "trust model" document = (4 months).

4.  First WG draft of "public-key submission and c= ertificate installation" document (4 months).

5.  First WG draft of "certificate, CRL, and OCSP = profile" document (8 months).

6.  First WG draft of "certificate, CRL, and OCSP = processing" document (12 months).

7.  First WG draft of "certificate re-issuance&quo= t; document (4 months).

8.  First WG draft of "certificate renewal" d= ocument (4 months).

9.  First WG draft of "certificate revocation"= ; document (8 months).

10. IESG submission of "trust model" document= (16 months).

11. IESG submission of "public-key submission and = certificate installation" document (16 months).

12. IESG submission of "certificate, CRL, and OCSP= profile" document (20 months).

13. IESG submission of "certificate, CRL, and OCSP= processing" document (24 months).

14. IESG submission of "certificate re-issuance&qu= ot; document (16 months).

15. IESG submission of "certificate renewal" = document (16 months).

16. IESG submission of "certificate revocation&quo= t; document (20 months)

 

The schedule is predicated upon the group's ability to r= ecruit a sufficient number of editors and engage either the relevant produc= t experts or other experts willing to test the selected product configurati= ons.  

 

 

T: +1 613 270 3183

 

--_000_370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6DENEXDDAS11corpeb_-- From stephen.farrell@cs.tcd.ie Wed Aug 22 14:37:48 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 74FE921F8513 for ; Wed, 22 Aug 2012 14:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBNPDyPpez3Y for ; Wed, 22 Aug 2012 14:37:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 32C5B21F84FE for ; Wed, 22 Aug 2012 14:37:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5C69D17149C; Wed, 22 Aug 2012 22:37:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1345671463; bh=PyPL+ivhNEux2s Vx4I0+zDbdYksAwrb/zc9uC3KxYl4=; b=IIKyeZ2Zi805aqFDCDHGhyaOazB4DW 00VWLnr4rkrojeJl33q77OMKKSZjGlRoyOfUQgGzSR/6bdbdvRS2CJzpTMk42Um1 NqlIVln18WTWpa6938SzkboUMuxEmexabPKso39HjIHFNEkZgtDFdeofy5LIMtvL jCyV8TRSV7SsTTyLXGd2341rI9gl8FDbG/49mRBYah7H8mPq1TCgSSQProb33/dj J1TH4CJbyqoHp75f/ZnY24A6EVjOtK75qT/6tEU8rbS7+ds0Io+7qVE+isxmFG76 SSP5w3tXoIeQ59OPog2SXyC4S82W9Jde4Mk3M1SIvgPEfM+/X+ODGTNQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id nR9QSCT444Qm; Wed, 22 Aug 2012 22:37:43 +0100 (IST) Received: from [10.87.48.7] (unknown [86.44.72.248]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5881B171491; Wed, 22 Aug 2012 22:37:42 +0100 (IST) Message-ID: <50355125.7080004@cs.tcd.ie> Date: Wed, 22 Aug 2012 22:37:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <50354208.3070902@cs.tcd.ie> <5B68A271B9C97046963CB6A5B8D6F62C3A571AAD@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A571AAD@SOTTEXCH10.corp.ad.entrust.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'wpkops@ietf.org'" Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:37:48 -0000 Hi Tim, On 08/22/2012 09:56 PM, Tim Moses wrote: > Thanks Stephen. To explain ... when I suggested a profiling activity, I had in mind to describe the subset of PKIX that is actually used in the Web PKI (as well as non-conformant variations). For instance, I don't believe any publicly-trusted CAs issue delta CRLs or that any browsers use OCSP nonces. If this is true, then it isn't recorded in any one place. I had in mind to record those facts. And, there are - no doubt - many other features of RFC 5280 that are not exercised in the Web PKI. Do that seem appropriate to you? It does, yes. I think though that it'll be important for this to always be seen in context so avoiding the (mis-)perception that the goal is to re-visit PKIX will continue to be important. Perhaps avoiding the term "profiling" will help - PKIX after all was setup to profile X.509, which is not what you're after here. While doing that profiling PKIX had to invent lots of detailed rules that weren't specified in the CCITT docs but that were (thought to be) needed for interop, and its that kind of invention that we want to avoid here I think. Maybe focus on saying "document deployed PKI" as much as possible just to be clear? S > > All the best. Tim. > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, August 22, 2012 4:33 PM > To: Tim Moses > Cc: 'wpkops@ietf.org' > Subject: Re: [wpkops] First draft charter proposal > > > Thanks Tim for that. > > I agree with Ron - that's a really good start, but does need work. > > My initial thoughts on that: > > - I think the milestone list you presented is too detailed for a charter, especially at this point. But I'd say that can be left for now though until the overall scope is clearer. So fix that later and let's try focus on the scope for now. > > - I'm not sure that omitting code signing is a good plan, since the same libraries and trust anchors are used and code-signing has been a recent attack vector of note. Omitting document signing and email seems ok to me though as those are much more enterprisey things, but HTTPS and code-signing are both common on the public Internet. So I'd like to understand that better. > > - I think the putative OPS WG ought document deployed stuff as you say, but beyond that its scope ought be explicitly limited to developing (at most) use-cases and/or requirements for any new protocol. So I'm not at all sure how to interpret some of the deliverables you envisage. For example, what's the "certificate, CRL, and OCSP profile" document? If that means "invent a new profile" then I have a problem with that. If it means "document deployed deviations from 5280/2560" then that'd be fine I think but then it ought have a different name. > > - As Ron said, the IETF doesn't do product evaluations but I think that's an easy one, just include in scope documenting the behaviour of "recent" browsers, web servers and (I guess) relevant middleboxen, so long as they have non-trivial deployment. > > Cheers, > S. > > On 08/22/2012 01:44 PM, Tim Moses wrote: >> Colleagues - Here is a first draft of a charter proposal. Please give it some thought and share the results of your deliberations. Thanks a lot. All the best. Tim. >> >> >> The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. It 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 hundreds of variations on the Web PKI in regular use. And this can be a source of problems both for end-users and certificate issuers. >> >> >> >> For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, 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. >> >> >> >> And for 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 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. >> >> >> >> 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 (other than the Web) may use the same trust anchors as the ones used by the Web. These applications include: document signing; code signing; and email. They may use PKI in a way that differs from the way in which the Web uses it. Therefore, these applications are explicitly out of scope for the working group. >> >> >> >> Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers. However, the topic of practices is outside the scope of the IETF. Therefore, this will be left to other competent bodies. >> >> >> >> That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. 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, it is agreed that adherence to the published schedule should take precedence over completeness of the results. The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today. >> >> >> >> The output documents will all be BCP-style RFCs. >> >> >> >> 1. Agree the working group charter (1 month). >> >> 2. Catalog the products and versions to be analyzed (1 month). >> >> 3. First WG draft of "trust model" document (4 months). >> >> 4. First WG draft of "public-key submission and certificate installation" document (4 months). >> >> 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 months). >> >> 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 months). >> >> 7. First WG draft of "certificate re-issuance" document (4 months). >> >> 8. First WG draft of "certificate renewal" document (4 months). >> >> 9. First WG draft of "certificate revocation" document (8 months). >> >> 10. IESG submission of "trust model" document (16 months). >> >> 11. IESG submission of "public-key submission and certificate installation" document (16 months). >> >> 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months). >> >> 13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months). >> >> 14. IESG submission of "certificate re-issuance" document (16 months). >> >> 15. IESG submission of "certificate renewal" document (16 months). >> >> 16. IESG submission of "certificate revocation" document (20 months) >> >> >> >> The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations. >> >> >> T: +1 613 270 3183 >> >> >> >> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> > From md@ssc.lt Wed Aug 22 14:42:24 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 139B621F86D3 for ; Wed, 22 Aug 2012 14:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.554, 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 Ku2D6RkXiHxK for ; Wed, 22 Aug 2012 14:42:20 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2321F86C6 for ; Wed, 22 Aug 2012 14:42:19 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.101]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1T4Igl-0007zC-7c; Thu, 23 Aug 2012 00:42:11 +0300 Message-ID: <50355235.5030003@ssc.lt> Date: Thu, 23 Aug 2012 00:42:13 +0300 From: "Moudrick M. Dadashov" Organization: Skaitmeninio sertifikavimo centras User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Hill, Brad" References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> Content-Type: multipart/alternative; boundary="------------080907070009000307040500" Cc: "'wpkops@ietf.org'" , Tim Moses Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:42:24 -0000 This is a multi-part message in MIME format. --------------080907070009000307040500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Right, but obviously seeking to narrow the scope we need a wider vision, right? Exclusion of "documents etc." has its historical reasons, not technological. Why not to form a generic vision and based on that try to figure out the scope of interest. Thanks, M.D. On 8/23/2012 12:27 AM, Hill, Brad wrote: > > I agree with Tim that we should start with a narrow scope focused on > the Web PKI rather than documents, etc., I also think there are cases > that are on the edge -- like the programmatic HTTP clients used by > mobile aps, embedded browsing contexts with different PKI error > handling logic than standalone ones, and, towards the more complex > end, web services that use HTTP and the web PKI explicitly but might > also use other transports and trust models. Not clear from the draft > charter where to draw the line among these, but there is plenty of > work to do and that needs doing urgently. > > Brad Hill > > *From:*wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] *On > Behalf Of *Tim Moses > *Sent:* Wednesday, August 22, 2012 5:45 AM > *To:* 'wpkops@ietf.org' > *Subject:* [wpkops] First draft charter proposal > > Colleagues -- Here is a first draft of a charter proposal. Please > give it some thought and share the results of your deliberations. > Thanks a lot. All the best. Tim. > > The Web PKI is the set of systems and procedures most commonly used to > protect the confidentiality, integrity and authenticity of > communications between Web browsers and Web content servers. It 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 hundreds of variations > on the Web PKI in regular use. And this can be a source of problems > both for end-users and certificate issuers. > > For end-users, there is no clear view whether certificate "problems" > remain when they see indication of a "good" connection. For instance, > in some browsers, 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. > > And for 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 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. > > 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 (other than the Web) may use > the same trust anchors as the ones used by the Web. These > applications include: document signing; code signing; and email. They > may use PKI in a way that differs from the way in which the Web uses > it. Therefore, these applications are explicitly out of scope for the > working group. > > Also, the reliability of the Web PKI depends critically on the > practices of its certificate issuers. However, the topic of practices > is outside the scope of the IETF. Therefore, this will be left to > other competent bodies. > > That there are technical shortcomings with Web PKI, as it is practiced > today, is well recognized. And, that there is also some urgency in > addressing these shortcomings is also well recognized. 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, it is agreed that adherence to the published schedule should > take precedence over completeness of the results. The working group > should focus its initial attention on the browser and server versions > that make up the largest part of the desktop and mobile Web today. > > The output documents will all be BCP-style RFCs. > > 1.Agree the working group charter (1 month). > > 2.Catalog the products and versions to be analyzed (1 month). > > 3.First WG draft of "trust model" document (4 months). > > 4.First WG draft of "public-key submission and certificate > installation" document (4 months). > > 5.First WG draft of "certificate, CRL, and OCSP profile" document (8 > months). > > 6.First WG draft of "certificate, CRL, and OCSP processing" document > (12 months). > > 7.First WG draft of "certificate re-issuance" document (4 months). > > 8.First WG draft of "certificate renewal" document (4 months). > > 9.First WG draft of "certificate revocation" document (8 months). > > 10.IESG submission of "trust model" document (16 months). > > 11.IESG submission of "public-key submission and certificate > installation" document (16 months). > > 12.IESG submission of "certificate, CRL, and OCSP profile" document > (20 months). > > 13.IESG submission of "certificate, CRL, and OCSP processing" document > (24 months). > > 14.IESG submission of "certificate re-issuance" document (16 months). > > 15.IESG submission of "certificate renewal" document (16 months). > > 16.IESG submission of "certificate revocation" document (20 months) > > The schedule is predicated upon the group's ability to recruit a > sufficient number of editors and engage either the relevant product > experts or other experts willing to test the selected product > configurations. > > T: +1 613 270 3183 > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops --------------080907070009000307040500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Right, but obviously seeking to narrow the scope we need a wider vision, right? Exclusion of "documents etc." has its historical reasons, not technological. Why not to form a generic vision and based on that try to figure out the scope of interest.

Thanks,
M.D.

On 8/23/2012 12:27 AM, Hill, Brad wrote:

I agree with Tim that we should start with a narrow scope focused on the Web PKI rather than documents, etc.,  I also think there are cases that are on the edge – like the programmatic HTTP clients used by mobile aps, embedded browsing contexts with different PKI error handling logic than standalone ones, and, towards the more complex end, web services that use HTTP and the web PKI explicitly but might also use other transports and trust models.  Not clear from the draft charter where to draw the line among these, but there is plenty of work to do and that needs doing urgently.

 

Brad Hill

 

From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 5:45 AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First draft charter proposal

 

Colleagues – Here is a first draft of a charter proposal.  Please give it some thought and share the results of your deliberations.  Thanks a lot.  All the best.  Tim.

 

The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers.  It 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 hundreds of variations on the Web PKI in regular use.  And this can be a source of problems both for end-users and certificate issuers.

 

For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection.  For instance, in some browsers, 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.

 

And for 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 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.

 

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 (other than the Web) may use the same trust anchors as the ones used by the Web.  These applications include: document signing; code signing; and email.  They may use PKI in a way that differs from the way in which the Web uses it.  Therefore, these applications are explicitly out of scope for the working group.

 

Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers.  However, the topic of practices is outside the scope of the IETF.  Therefore, this will be left to other competent bodies.

 

That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized.  And, that there is also some urgency in addressing these shortcomings is also well recognized.  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, it is agreed that adherence to the published schedule should take precedence over completeness of the results.  The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today.

 

The output documents will all be BCP-style RFCs.

 

1.  Agree the working group charter (1 month).

2.  Catalog the products and versions to be analyzed (1 month).

3.  First WG draft of "trust model" document (4 months).

4.  First WG draft of "public-key submission and certificate installation" document (4 months).

5.  First WG draft of "certificate, CRL, and OCSP profile" document (8 months).

6.  First WG draft of "certificate, CRL, and OCSP processing" document (12 months).

7.  First WG draft of "certificate re-issuance" document (4 months).

8.  First WG draft of "certificate renewal" document (4 months).

9.  First WG draft of "certificate revocation" document (8 months).

10. IESG submission of "trust model" document (16 months).

11. IESG submission of "public-key submission and certificate installation" document (16 months).

12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months).

13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months).

14. IESG submission of "certificate re-issuance" document (16 months).

15. IESG submission of "certificate renewal" document (16 months).

16. IESG submission of "certificate revocation" document (20 months)

 

The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations.  

 

 

T: +1 613 270 3183

 



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

--------------080907070009000307040500-- From stephen.farrell@cs.tcd.ie Wed Aug 22 14:44:19 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 2084821F8508 for ; Wed, 22 Aug 2012 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh3ZY8yt9uZp for ; Wed, 22 Aug 2012 14:44:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id BED4321F8456 for ; Wed, 22 Aug 2012 14:44:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1C59117149C; Wed, 22 Aug 2012 22:44:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1345671856; bh=RT0xbvgYa/UFnM trvXa2FbAAxE911vhoBmibo2ZluF8=; b=B4AUfnboDRucd+3h/iJ0aVdABTJsg5 FGdawfjya2bsZ0X3aHjbyqi6+GCjKomCZb0J2Ct4pzwtA9SpilE3+vRy7K4WElbO 49vmkaj62ZBRASbmYYOTGRTYbnxFOwZhqRQ2grTqmXD1beD5U0Kqzs3K20EK3Pzq VvbCOX2q3s6jI0yWHuP393NT3vnrsLPb2ej1PM73UQBvxF8Wl2kXNkcpZZj4sSF8 /VdCuaNSf2bo+jOGkty5WQmZ5WZrayI7vwsEMOvFCMUGYm6iGzumfrTYBbWt4LBr 9pQN+2OytSExGSIAxJI2sLyIOfyLOpzPj+uSyAwPyrtl7Gh33ki1kxWA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id yOue1M7vptHZ; Wed, 22 Aug 2012 22:44:16 +0100 (IST) Received: from [10.87.48.7] (unknown [86.44.72.248]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C304B171491; Wed, 22 Aug 2012 22:44:14 +0100 (IST) Message-ID: <503552AE.1090308@cs.tcd.ie> Date: Wed, 22 Aug 2012 22:44:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Hill, Brad" References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'wpkops@ietf.org'" , Tim Moses Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:44:19 -0000 I've no very strong opinion myself about what's right for this aspect of the scope of the proposed work. But I do think the scope in terms of applications needs to be clear and whatever scope is chosen needs a good justification. (When I say "applications," I mean the set of applications that are dependent on the in-scope aspects of PKI, not that this WG would be saying how HTTPS or S/MIME should work.) Tim's initial text is clear, but I don't get the justification for that choice, should it be the one that ends up being made. In particular, I don't get why code-signing is called out of scope. S On 08/22/2012 10:27 PM, Hill, Brad wrote: > I agree with Tim that we should start with a narrow scope focused on the Web PKI rather than documents, etc., I also think there are cases that are on the edge - like the programmatic HTTP clients used by mobile aps, embedded browsing contexts with different PKI error handling logic than standalone ones, and, towards the more complex end, web services that use HTTP and the web PKI explicitly but might also use other transports and trust models. Not clear from the draft charter where to draw the line among these, but there is plenty of work to do and that needs doing urgently. > > Brad Hill > > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses > Sent: Wednesday, August 22, 2012 5:45 AM > To: 'wpkops@ietf.org' > Subject: [wpkops] First draft charter proposal > > Colleagues - Here is a first draft of a charter proposal. Please give it some thought and share the results of your deliberations. Thanks a lot. All the best. Tim. > > > The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. It 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 hundreds of variations on the Web PKI in regular use. And this can be a source of problems both for end-users and certificate issuers. > > > > For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, 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. > > > > And for 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 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. > > > > 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 (other than the Web) may use the same trust anchors as the ones used by the Web. These applications include: document signing; code signing; and email. They may use PKI in a way that differs from the way in which the Web uses it. Therefore, these applications are explicitly out of scope for the working group. > > > > Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers. However, the topic of practices is outside the scope of the IETF. Therefore, this will be left to other competent bodies. > > > > That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. 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, it is agreed that adherence to the published schedule should take precedence over completeness of the results. The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today. > > > > The output documents will all be BCP-style RFCs. > > > > 1. Agree the working group charter (1 month). > > 2. Catalog the products and versions to be analyzed (1 month). > > 3. First WG draft of "trust model" document (4 months). > > 4. First WG draft of "public-key submission and certificate installation" document (4 months). > > 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 months). > > 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 months). > > 7. First WG draft of "certificate re-issuance" document (4 months). > > 8. First WG draft of "certificate renewal" document (4 months). > > 9. First WG draft of "certificate revocation" document (8 months). > > 10. IESG submission of "trust model" document (16 months). > > 11. IESG submission of "public-key submission and certificate installation" document (16 months). > > 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months). > > 13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months). > > 14. IESG submission of "certificate re-issuance" document (16 months). > > 15. IESG submission of "certificate renewal" document (16 months). > > 16. IESG submission of "certificate revocation" document (20 months) > > > > The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations. > > > T: +1 613 270 3183 > > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From ben@digicert.com Wed Aug 22 14:52:07 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 C487621F862B for ; Wed, 22 Aug 2012 14:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfSI9jPIZsza for ; Wed, 22 Aug 2012 14:52:04 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB221F8625 for ; Wed, 22 Aug 2012 14:52:04 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id A45131AE01B; Wed, 22 Aug 2012 15:52:03 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1345672323; bh=ZTGNv/P4Ipioeqq/1zTaIMAaifW8f1ceT3FWZrxBhfk=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=YSvnYr+h6sZhkaaoGBJ7k2k/ERue30YGVOEOJfRGsPp4ViI1eXhSAociKWHMdA98S lhkUhUTNEWKisgIpLb1fojzBcoRPV7gLVCSKpyn3kpYnP8EiaZCVOe5imXfJ4WPeVK MqBMvR41SmiGmEUTLOvDx84uO2V53k88mk4kTB8k= From: "Ben Wilson" To: "'Tim Moses'" , References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> Date: Wed, 22 Aug 2012 15:52:01 -0600 Organization: DigiCert Message-ID: <01ee01cd80b0$5cb4e1d0$161ea570$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EF_01CD807E.121BD160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK1B/3g8RTiiDvaXrCEOsWt+qR9t5WXTsiA Content-Language: en-us Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 21:52:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01EF_01CD807E.121BD160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim, How do you envision that any previous or future work product of members of the CAB Forum on profile-type documents be integrated into the work of this group? Namely, in Section 9 of the Baseline Requirements there was some language about Issuer and Subject Identifiers, and then Appendices A and B discussed key lengths, algorithms, and certificate extensions. I am thinking that because there will be an overlap of participation from many of the same players it will not be a problem, but will one group end up deferring to the other on certain types of issues, or are they completely separate? Thanks, Ben From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses Sent: Wednesday, August 22, 2012 6:45 AM To: 'wpkops@ietf.org' Subject: [wpkops] First draft charter proposal Colleagues - Here is a first draft of a charter proposal. Please give it some thought and share the results of your deliberations. Thanks a lot. All the best. Tim. The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. It 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 hundreds of variations on the Web PKI in regular use. And this can be a source of problems both for end-users and certificate issuers. For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, 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. And for 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 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. 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 (other than the Web) may use the same trust anchors as the ones used by the Web. These applications include: document signing; code signing; and email. They may use PKI in a way that differs from the way in which the Web uses it. Therefore, these applications are explicitly out of scope for the working group. Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers. However, the topic of practices is outside the scope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. 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, it is agreed that adherence to the published schedule should take precedence over completeness of the results. The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today. The output documents will all be BCP-style RFCs. 1. Agree the working group charter (1 month). 2. Catalog the products and versions to be analyzed (1 month). 3. First WG draft of "trust model" document (4 months). 4. First WG draft of "public-key submission and certificate installation" document (4 months). 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 months). 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 months). 7. First WG draft of "certificate re-issuance" document (4 months). 8. First WG draft of "certificate renewal" document (4 months). 9. First WG draft of "certificate revocation" document (8 months). 10. IESG submission of "trust model" document (16 months). 11. IESG submission of "public-key submission and certificate installation" document (16 months). 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months). 13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months). 14. IESG submission of "certificate re-issuance" document (16 months). 15. IESG submission of "certificate renewal" document (16 months). 16. IESG submission of "certificate revocation" document (20 months) The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations. T: +1 613 270 3183 ------=_NextPart_000_01EF_01CD807E.121BD160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,

How do you envision that = any previous or future work product of members of the CAB Forum on = profile-type documents be integrated into the work of this = group?

Namely, in Section 9 of the Baseline = Requirements there was some language about Issuer and Subject = Identifiers, and then Appendices A and B discussed key lengths, = algorithms, and certificate extensions.

I am thinking that = because there will be an overlap of participation from many of the same = players it will not be a problem, but will one group end up deferring to = the other on certain types of issues, or are they completely = separate?

Thanks,

Ben

 

From:= = wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of = Tim Moses
Sent: Wednesday, August 22, 2012 6:45 = AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First = draft charter proposal

 

Colleagues = – Here is a first draft of a charter proposal.  Please give = it some thought and share the results of your deliberations.  = Thanks a lot.  All the best.  Tim.

 

The Web PKI is = the set of systems and procedures most commonly used to protect the = confidentiality, integrity and authenticity of communications between = Web browsers and Web content servers.  It 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 hundreds of variations on the Web PKI in = regular use.  And this can be a source of problems both for = end-users and certificate issuers.

 

For end-users, there = is no clear view whether certificate "problems" remain when = they see indication of a "good" connection.  For = instance, in some browsers, 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.

 

And for 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 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.

 

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 (other than the = Web) may use the same trust anchors as the ones used by the Web.  = These applications include: document signing; code signing; and = email.  They may use PKI in a way that differs from the way in = which the Web uses it.  Therefore, these applications are = explicitly out of scope for the working group.

 

Also, the = reliability of the Web PKI depends critically on the practices of its = certificate issuers.  However, the topic of practices is outside = the scope of the IETF.  Therefore, this will be left to other = competent bodies.

 

That there are technical shortcomings with Web PKI, as it = is practiced today, is well recognized.  And, that there is also = some urgency in addressing these shortcomings is also well = recognized.  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, it is agreed that adherence to the published schedule = should take precedence over completeness of the results.  The = working group should focus its initial attention on the browser and = server versions that make up the largest part of the desktop and mobile = Web today.

 

The output documents will all be BCP-style = RFCs.

 

1.    Agree the working = group charter (1 month).

2.    = Catalog the products and versions to be analyzed = (1 month).

3.    = First WG draft of "trust model" = document (4 months).

4.    = First WG draft of "public-key submission = and certificate installation" document (4 months).

5.    First WG draft of = "certificate, CRL, and OCSP profile" document (8 = months).

6.    = First WG draft of "certificate, CRL, and = OCSP processing" document (12 months).

7.    First WG draft of = "certificate re-issuance" document (4 = months).

8.    = First WG draft of "certificate = renewal" document (4 months).

9.    = First WG draft of "certificate = revocation" document (8 months).

10. IESG = submission of "trust model" document (16 = months).

11. IESG = submission of "public-key submission and certificate = installation" document (16 months).

12. IESG = submission of "certificate, CRL, and OCSP profile" document = (20 months).

13. IESG = submission of "certificate, CRL, and OCSP processing" document = (24 months).

14. IESG = submission of "certificate re-issuance" document (16 = months).

15. IESG = submission of "certificate renewal" document (16 = months).

16. IESG = submission of "certificate revocation" document (20 = months)

 

The schedule is predicated upon the group's ability to = recruit a sufficient number of editors and engage either the relevant = product experts or other experts willing to test the selected product = configurations.  

 

 

T: +1 613 = 270 3183

 

------=_NextPart_000_01EF_01CD807E.121BD160-- From bhill@paypal-inc.com Wed Aug 22 15:29:43 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 B7AF221F8665 for ; Wed, 22 Aug 2012 15:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.042 X-Spam-Level: X-Spam-Status: No, score=-9.042 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, 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 Hmsn5mWStSGn for ; Wed, 22 Aug 2012 15:29:38 -0700 (PDT) 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 728CD21F862B for ; Wed, 22 Aug 2012 15:29:38 -0700 (PDT) DomainKey-Signature: s=ppinc; 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:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type:MIME-Version: X-CFilter; b=xPENzT94/KVVWGzeDKVm4cSxy2L5jNyc+lMBfk0vOwfoJjvvf9nvQtJV x4P4eDbI7D0Rc8LjbO3KPHZXajtDGgRcdY9d9Ft7jyj5LlHNF1Kx1rqOq FQTAnSTRxKtK2gq; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1345674579; x=1377210579; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Oor5AtGGQNjB1aiJV0lA2rdy5I93MQLBKoT1hzetz6E=; b=uyPqApjzk3PfhCZF+IENUqpgvXDkpd7ybfsaGiNycsqzQCD/WHPruVuZ 5eAngUxf1dGQ9PROjSUjCLIXCM+ajC9HxWWOaHxhHxgDiK8nQo479M9qt aBzEh+YsAFJGSqw; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,296,1344236400"; d="scan'208,217";a="9315260" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-006.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 22 Aug 2012 15:29:38 -0700 Received: from DEN-EXDDA-S11.corp.ebay.com ([fe80::74c6:c884:c352:716]) by DEN-EXMHT-006.corp.ebay.com ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.02.0298.004; Wed, 22 Aug 2012 16:29:35 -0600 From: "Hill, Brad" To: "Moudrick M. Dadashov" Thread-Topic: [wpkops] First draft charter proposal Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQASI2WgAA0y8IAAC5VH0A== Date: Wed, 22 Aug 2012 22:29:34 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> In-Reply-To: <50355235.5030003@ssc.lt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.243] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: 6In7KH9fy3ovqi9QN8AKTw== Content-Type: multipart/alternative; boundary="_000_370C9BEB4DD6154FA963E2F79ADC6F2E1F233DDENEXDDAS11corpeb_" MIME-Version: 1.0 X-CFilter: Scanned Cc: "'wpkops@ietf.org'" , Tim Moses Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 22:29:43 -0000 --_000_370C9BEB4DD6154FA963E2F79ADC6F2E1F233DDENEXDDAS11corpeb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Moudrick Dadashov wrote: >Right, but obviously seeking to narrow the scope we need a wider vision, r= ight? >Exclusion of "documents etc." has its historical reasons, not technologica= l. I think it does have technological reasons: Document and code signing has = to: * Deal with problems of long-lived artifacts - including signed objects tha= t may outlive the certificates used to sign them * Work by default without a direct connection to the entity in control of t= he certificate * Support entirely offline verification This has also led to different practices about revocation and blacklisti= ng, use of third party time stamping authorities, etc. The differences are= substantial. Code signing in particular is also HIGHLY vendor-specific. I may be mistak= en, but my impression is that it's not meaningful at all to talk about a si= ngle set of practices around code signing that is common across multiple pl= atforms - Java, Apple App Store, Android Apps, Microsoft Authenticode, Str= ong Named Assemblies in .NET, etc. Java and Authenticode may have interoperable certificate formats, but how t= hey are used still differs greatly. Individual vendors remain in the best = position to provide authoritative guidance on their own implementations. Document signing is a bit more interoperable, though still more fragmented = than the Web by regulatory requirements and jurisdictional boundaries, and = often additionally by document formats. (PDF vs. Word vs. XML) I think "the Web" / HTTPS is the only PKI (other than the work PKIX does/di= d) with enough actually interoperating implementations that a body like the= IETF is best-positioned to document current and historical practices. -Brad From: Moudrick M. Dadashov [mailto:md@ssc.lt] Sent: Wednesday, August 22, 2012 2:42 PM To: Hill, Brad Cc: Tim Moses; 'wpkops@ietf.org' Subject: Re: [wpkops] First draft charter proposal Right, but obviously seeking to narrow the scope we need a wider vision, ri= ght? Exclusion of "documents etc." has its historical reasons, not technolo= gical. Why not to form a generic vision and based on that try to figure out= the scope of interest. Thanks, M.D. On 8/23/2012 12:27 AM, Hill, Brad wrote: I agree with Tim that we should start with a narrow scope focused on the We= b PKI rather than documents, etc., I also think there are cases that are o= n the edge - like the programmatic HTTP clients used by mobile aps, embedde= d browsing contexts with different PKI error handling logic than standalone= ones, and, towards the more complex end, web services that use HTTP and th= e web PKI explicitly but might also use other transports and trust models. = Not clear from the draft charter where to draw the line among these, but t= here is plenty of work to do and that needs doing urgently. Brad Hill From: wpkops-bounces@ietf.org [mailto:wpkop= s-bounces@ietf.org] On Behalf Of Tim Moses Sent: Wednesday, August 22, 2012 5:45 AM To: 'wpkops@ietf.org' Subject: [wpkops] First draft charter proposal Colleagues - Here is a first draft of a charter proposal. Please give it s= ome thought and share the results of your deliberations. Thanks a lot. Al= l the best. Tim. The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems both for end-users and certificate issuers. 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 refu= se to display the contents under these circumstances. And for 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 se= rver supplies a response that does not include the nonce, it is hard to kno= w 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. 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 (other than the Web) may use the sam= e trust anchors as the ones used by the Web. These applications include: d= ocument signing; code signing; and email. They may use PKI in a way that d= iffers from the way in which the Web uses it. Therefore, these application= s are explicitly out of scope for the working group. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers. However, the topic of practices is outside the s= cope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. 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. The working group should focus its init= ial attention on the browser and server versions that make up the largest p= art of the desktop and mobile Web today. The output documents will all be BCP-style RFCs. 1. Agree the working group charter (1 month). 2. Catalog the products and versions to be analyzed (1 month). 3. First WG draft of "trust model" document (4 months). 4. First WG draft of "public-key submission and certificate installation= " document (4 months). 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 mo= nths). 6. First WG draft of "certificate, CRL, and OCSP processing" document (1= 2 months). 7. First WG draft of "certificate re-issuance" document (4 months). 8. First WG draft of "certificate renewal" document (4 months). 9. First WG draft of "certificate revocation" document (8 months). 10. IESG submission of "trust model" document (16 months). 11. IESG submission of "public-key submission and certificate installation"= document (16 months). 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 mo= nths). 13. IESG submission of "certificate, CRL, and OCSP processing" document (24= months). 14. IESG submission of "certificate re-issuance" document (16 months). 15. IESG submission of "certificate renewal" document (16 months). 16. IESG submission of "certificate revocation" document (20 months) The schedule is predicated upon the group's ability to recruit a sufficient= number of editors and engage either the relevant product experts or other = experts willing to test the selected product configurations. T: +1 613 270 3183 _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops --_000_370C9BEB4DD6154FA963E2F79ADC6F2E1F233DDENEXDDAS11corpeb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Moudrick Dadashov wrote:

 

>Right, but obviously seeking to narrow the scope= we need a wider vision, right?

>Exclusion of "documents etc." has its = historical reasons, not technological.

 

I think it does have t= echnological reasons:  Document and code signing has to:

 

* Deal with problems o= f long-lived artifacts – including signed objects that may outlive th= e certificates used to sign them

* Work by default with= out a direct connection to the entity in control of the certificate

* Support entirely off= line verification

 

   This has = also led to different practices about revocation and blacklisting, use of t= hird party time stamping authorities, etc.  The differences are substa= ntial.

 

Code signing in partic= ular is also HIGHLY vendor-specific.  I may be mistaken, but my impres= sion is that it’s not meaningful at all to talk about a single set of= practices around code signing that is common across multiple platforms – Java, Apple App Store, Android Apps,  Micr= osoft Authenticode, Strong Named Assemblies in .NET, etc. 

 

Java and Authenticode = may have interoperable certificate formats, but how they are used still dif= fers greatly.  Individual vendors remain in the best position to provi= de authoritative guidance on their own implementations. 

 

Document signing is a = bit more interoperable, though still more fragmented than the Web by regula= tory requirements and jurisdictional boundaries, and often additionally by = document formats. (PDF vs. Word vs. XML)

 

I think “the Web= ” / HTTPS is the only PKI (other than the work PKIX does/did) with en= ough actually interoperating implementations that a body like the IETF is b= est-positioned to document current and historical practices.

 

-Brad

 

From: Moudrick M. Dadashov [mailto:md@ssc.lt]
Sent: Wednesday, August 22, 2012 2:42 PM
To: Hill, Brad
Cc: Tim Moses; 'wpkops@ietf.org'
Subject: Re: [wpkops] First draft charter proposal=

 

Right, but obviously seeking to narrow the scope we = need a wider vision, right? Exclusion of "documents etc." has its= historical reasons, not technological. Why not to form a generic vision an= d based on that try to figure out the scope of interest.

Thanks,
M.D.

On 8/23/2012 12:27 AM, Hill, Brad wrote:

I agree with Tim that = we should start with a narrow scope focused on the Web PKI rather than docu= ments, etc.,  I also think there are cases that are on the edge –= ; like the programmatic HTTP clients used by mobile aps, embedded browsing contexts with different PKI error handling logic th= an standalone ones, and, towards the more complex end, web services that us= e HTTP and the web PKI explicitly but might also use other transports and t= rust models.  Not clear from the draft charter where to draw the line among these, but there is plenty of w= ork to do and that needs doing urgently.

 

Brad Hill<= /o:p>

 

From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 5:45 AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First draft charter proposal

 

Colleagues – Here is a first draft of a charte= r proposal.  Please give it some thought and share the results of your= deliberations.  Thanks a lot.  All the best.  Tim.

 

The Web PKI is the set of systems and procedures most co= mmonly used to protect the confidentiality, integrity and authenticity of c= ommunications between Web browsers and Web content servers.  It first = appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then.  Acr= oss all the suppliers and the point releases of their products, there are n= ow hundreds of variations on the Web PKI in regular use.  And this can= be a source of problems both for end-users and certificate issuers.

 

For end-users, there is no clear view whether certificat= e "problems" remain when they see indication of a "good"= ; connection.  For instance, in some browsers, a "good" indi= cation may be displayed when a "revoked" response has been receiv= ed and "accepted" by the user.  Whereas, other browsers may refuse= to display the contents under these circumstances.

 

And for issuers, it can be difficult to predict what pro= portion 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 server supplies a response that does not include the nonce, it is hard to know which browser= s will accept and which will reject the response.

 

Starting from the premise that more consistency in Web s= ecurity behavior is desirable, a natural first step would be to document cu= rrent and historic browser and server behavior.

 

Future activities may attempt to prescribe how the Web P= KI "should" work, and the prescription may turn out to be a prope= r 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 t= he set of browsers and servers that are in common use today.

 

Additionally, a number of applications (other than the W= eb) may use the same trust anchors as the ones used by the Web.  These= applications include: document signing; code signing; and email.  The= y may use PKI in a way that differs from the way in which the Web uses it.  Therefore, these applications are expl= icitly out of scope for the working group.

 

Also, the reliability of the Web PKI depends critically = on the practices of its certificate issuers.  However, the topic of pr= actices is outside the scope of the IETF.  Therefore, this will be lef= t to other competent bodies.

 

That there are technical shortcomings with Web PKI, as i= t is practiced today, is well recognized.  And, that there is also som= e urgency in addressing these shortcomings is also well recognized.  B= ut, 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 s= ystematic way, aspects of the Web PKI that should be progressed in future w= orking groups of the IETF's Security Area, and that suppliers will be willi= ng to participate in those working groups and modify their products to comply with their standards.

 

Given the urgency of the required developments and the s= cale of the task, it is agreed that adherence to the published schedule sho= uld take precedence over completeness of the results.  The working gro= up should focus its initial attention on the browser and server versions that make up the largest part of the deskt= op and mobile Web today.

 

The output documents will all be BCP-style RFCs.

 

1.    Agree the working group charter (1 month).

2.    Catalog the products and versions to be analyzed (1= month).

3.    First WG draft of "trust model" document = (4 months).

4.    First WG draft of "public-key submission and c= ertificate installation" document (4 months).

5.    First WG draft of "certificate, CRL, and OCSP = profile" document (8 months).

6.    First WG draft of "certificate, CRL, and OCSP = processing" document (12 months).

7.    First WG draft of "certificate re-issuance&quo= t; document (4 months).

8.    First WG draft of "certificate renewal" d= ocument (4 months).

9.    First WG draft of "certificate revocation"= ; document (8 months).

10. IESG submission of "trust model" document= (16 months).

11. IESG submission of "public-key submission and = certificate installation" document (16 months).

12. IESG submission of "certificate, CRL, and OCSP= profile" document (20 months).

13. IESG submission of "certificate, CRL, and OCSP= processing" document (24 months).

14. IESG submission of "certificate re-issuance&qu= ot; document (16 months).

15. IESG submission of "certificate renewal" = document (16 months).

16. IESG submission of "certificate revocation&quo= t; document (20 months)

 

The schedule is predicated upon the group's ability to r= ecruit a sufficient number of editors and engage either the relevant produc= t experts or other experts willing to test the selected product configurati= ons.  

 

 

T: +1 613 270 3183

 




_______________________________________________
wpkops mailing list
wpkops@ietf.org

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

 

--_000_370C9BEB4DD6154FA963E2F79ADC6F2E1F233DDENEXDDAS11corpeb_-- From rturner@amalfisystems.com Wed Aug 22 15:38: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 6CC6A21F8518 for ; Wed, 22 Aug 2012 15:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grwCMqhUnjKA for ; Wed, 22 Aug 2012 15:38:09 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5069B21F84FC for ; Wed, 22 Aug 2012 15:38:09 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7MMc8N9004256 for ; Wed, 22 Aug 2012 18:38:08 -0400 X-Authenticated-IP: 98.151.18.90 Received: from [98.151.18.90] ([98.151.18.90:65403] helo=[192.168.1.106]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 5E/B5-31423-F4F55305; Wed, 22 Aug 2012 18:38:08 -0400 From: Randy Turner Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_17F7B408-71E7-461F-9449-A4880DD79449" Date: Wed, 22 Aug 2012 15:38:07 -0700 In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> To: wpkops@ietf.org References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> Message-Id: <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> X-Mailer: Apple Mail (2.1278) Subject: Re: [wpkops] First draft charter proposal X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 22:38:11 -0000 --Apple-Mail=_17F7B408-71E7-461F-9449-A4880DD79449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would agree with the scope that "signing" brings into the potential = work of a WG, but I think there might be a fair amount of interoperable = S/MIME experience as well that could be discussed. Code signing is a bit fragmented, although there have been discussions = on using CMS for generating signed code containers, but vendors largely = do what they want (as you mentioned) The LTANS working group looked at document archival awhile back, and did = some work on timestamping, but I'm not aware of any shipping = implementations that standardized their long-term archival strategies = regarding signatures or timestamping (not that there aren't any, I just = don't keep up with this) R. On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote: > Moudrick Dadashov wrote: > =20 > >Right, but obviously seeking to narrow the scope we need a wider = vision, right? > >Exclusion of "documents etc." has its historical reasons, not = technological. > =20 > I think it does have technological reasons: Document and code signing = has to: > =20 > * Deal with problems of long-lived artifacts =96 including signed = objects that may outlive the certificates used to sign them > * Work by default without a direct connection to the entity in control = of the certificate > * Support entirely offline verification > =20 > This has also led to different practices about revocation and = blacklisting, use of third party time stamping authorities, etc. The = differences are substantial. > =20 > Code signing in particular is also HIGHLY vendor-specific. I may be = mistaken, but my impression is that it=92s not meaningful at all to talk = about a single set of practices around code signing that is common = across multiple platforms =96 Java, Apple App Store, Android Apps, = Microsoft Authenticode, Strong Named Assemblies in .NET, etc.=20 > =20 > Java and Authenticode may have interoperable certificate formats, but = how they are used still differs greatly. Individual vendors remain in = the best position to provide authoritative guidance on their own = implementations.=20 > =20 > Document signing is a bit more interoperable, though still more = fragmented than the Web by regulatory requirements and jurisdictional = boundaries, and often additionally by document formats. (PDF vs. Word = vs. XML) > =20 > I think =93the Web=94 / HTTPS is the only PKI (other than the work = PKIX does/did) with enough actually interoperating implementations that = a body like the IETF is best-positioned to document current and = historical practices. > =20 > -Brad > =20 > From: Moudrick M. Dadashov [mailto:md@ssc.lt]=20 > Sent: Wednesday, August 22, 2012 2:42 PM > To: Hill, Brad > Cc: Tim Moses; 'wpkops@ietf.org' > Subject: Re: [wpkops] First draft charter proposal > =20 > Right, but obviously seeking to narrow the scope we need a wider = vision, right? Exclusion of "documents etc." has its historical reasons, = not technological. Why not to form a generic vision and based on that = try to figure out the scope of interest. >=20 > Thanks, > M.D. >=20 > On 8/23/2012 12:27 AM, Hill, Brad wrote: > I agree with Tim that we should start with a narrow scope focused on = the Web PKI rather than documents, etc., I also think there are cases = that are on the edge =96 like the programmatic HTTP clients used by = mobile aps, embedded browsing contexts with different PKI error handling = logic than standalone ones, and, towards the more complex end, web = services that use HTTP and the web PKI explicitly but might also use = other transports and trust models. Not clear from the draft charter = where to draw the line among these, but there is plenty of work to do = and that needs doing urgently. > =20 > Brad Hill > =20 > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On = Behalf Of Tim Moses > Sent: Wednesday, August 22, 2012 5:45 AM > To: 'wpkops@ietf.org' > Subject: [wpkops] First draft charter proposal > =20 > Colleagues =96 Here is a first draft of a charter proposal. Please = give it some thought and share the results of your deliberations. = Thanks a lot. All the best. Tim. > =20 > The Web PKI is the set of systems and procedures most commonly used to = protect the confidentiality, integrity and authenticity of = communications between Web browsers and Web content servers. It 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 hundreds of variations = on the Web PKI in regular use. And this can be a source of problems = both for end-users and certificate issuers. > =20 > For end-users, there is no clear view whether certificate "problems" = remain when they see indication of a "good" connection. For instance, = in some browsers, 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. > =20 > And for 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 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 > 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. > =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 (other than the Web) may use = the same trust anchors as the ones used by the Web. These applications = include: document signing; code signing; and email. They may use PKI in = a way that differs from the way in which the Web uses it. Therefore, = these applications are explicitly out of scope for the working group. > =20 > Also, the reliability of the Web PKI depends critically on the = practices of its certificate issuers. However, the topic of practices = is outside the scope of the IETF. Therefore, this will be left to other = competent bodies. > =20 > That there are technical shortcomings with Web PKI, as it is practiced = today, is well recognized. And, that there is also some urgency in = addressing these shortcomings is also well recognized. 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. > =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. The working group should = focus its initial attention on the browser and server versions that make = up the largest part of the desktop and mobile Web today. > =20 > The output documents will all be BCP-style RFCs. > =20 > 1. Agree the working group charter (1 month). > 2. Catalog the products and versions to be analyzed (1 month). > 3. First WG draft of "trust model" document (4 months). > 4. First WG draft of "public-key submission and certificate = installation" document (4 months). > 5. First WG draft of "certificate, CRL, and OCSP profile" document = (8 months). > 6. First WG draft of "certificate, CRL, and OCSP processing" = document (12 months). > 7. First WG draft of "certificate re-issuance" document (4 months). > 8. First WG draft of "certificate renewal" document (4 months). > 9. First WG draft of "certificate revocation" document (8 months). > 10. IESG submission of "trust model" document (16 months). > 11. IESG submission of "public-key submission and certificate = installation" document (16 months). > 12. IESG submission of "certificate, CRL, and OCSP profile" document = (20 months). > 13. IESG submission of "certificate, CRL, and OCSP processing" = document (24 months). > 14. IESG submission of "certificate re-issuance" document (16 months). > 15. IESG submission of "certificate renewal" document (16 months). > 16. IESG submission of "certificate revocation" document (20 months) > =20 > The schedule is predicated upon the group's ability to recruit a = sufficient number of editors and engage either the relevant product = experts or other experts willing to test the selected product = configurations. =20 > =20 > =20 > T: +1 613 270 3183 > =20 >=20 >=20 >=20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > =20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops --Apple-Mail=_17F7B408-71E7-461F-9449-A4880DD79449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

I would agree with the scope that = "signing" brings into the potential work of a WG, but I think there = might be a fair amount of interoperable S/MIME experience as well that = could be discussed.

Code signing is a bit fragmented, = although there have been discussions on using CMS for generating signed = code containers, but vendors largely do what they want (as you = mentioned)

The LTANS working group looked at = document archival awhile back, and did some work on timestamping, but = I'm not aware of any shipping implementations that standardized their = long-term archival strategies regarding signatures or timestamping (not = that there aren't any, I just don't keep up with = this)

R.


O= n Aug 22, 2012, at 3:29 PM, Hill, Brad wrote:

Moudrick Dadashov = wrote:
 
>Right, but obviously seeking to narrow = the scope we need a wider vision, right?
>Exclusion of "documents etc." has its = historical reasons, not technological.
I think it does have technological = reasons:  Document and code signing has = to:
 
* = Deal with problems of long-lived artifacts =96 including signed objects = that may outlive the certificates used to sign = them
* Work by default without a direct connection to the = entity in control of the certificate
* = Support entirely offline verification
   This has also led to = different practices about revocation and blacklisting, use of third = party time stamping authorities, etc.  The differences are = substantial.
 
 
 
 
I = think =93the Web=94 / HTTPS is the only PKI (other than the work PKIX = does/did) with enough actually interoperating implementations that a = body like the IETF is best-positioned to document current and historical = practices.
 
 
 Moudrick M. Dadashov = [mailto:md@ssc.lt] 
Sent: Wednesday, August 22, 2012 = 2:42 PM
To: Hill, = Brad
Cc: Tim = Moses; ' Re: [wpkops] First draft = charter proposal
From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim = Moses
Sent: Wednesday, August 22, 2012 = 5:45 AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First draft = charter proposal
 
Colleagues =96 Here is a first draft of a = charter proposal.  Please give it some thought and share the = results of your deliberations.  Thanks a lot.  All the = best.  Tim.
The Web PKI is the = set of systems and procedures most commonly used to protect the = confidentiality, integrity and authenticity of communications between = Web browsers and Web content servers.  It 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 hundreds of variations on the Web PKI in = regular use.  And this can be a source of problems both for = end-users and certificate issuers.
 
For end-users, there is no clear view = whether certificate "problems" remain when they see indication of a = "good" connection.  For instance, in some browsers, 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.
 
And for 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 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.
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 (other than the Web) may use the same trust = anchors as the ones used by the Web.  These applications include: = document signing; code signing; and email.  They may use PKI in a = way that differs from the way in which the Web uses it.  Therefore, = these applications are explicitly out of scope for the working = group.
 
Also, the reliability of the Web PKI depends = critically on the practices of its certificate issuers.  However, = the topic of practices is outside the scope of the IETF.  = Therefore, this will be left to other competent = bodies.
That there are = technical shortcomings with Web PKI, as it is practiced today, is well = recognized.  And, that there is also some urgency in addressing = these shortcomings is also well recognized.  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, it is agreed that = adherence to the published schedule should take precedence over = completeness of the results.  The working group should focus its = initial attention on the browser and server versions that make up the = largest part of the desktop and mobile Web today.
 
The output documents will all be BCP-style = RFCs.
 
1. Agree the = working group charter (1 month).
2.    Catalog the = products and versions to be analyzed (1 month).
3. First WG = draft of "trust model" document (4 months).
4. First WG = draft of "public-key submission and certificate installation" document = (4 months).
    First WG = draft of "certificate, CRL, and OCSP profile" document (8 = months).
    First WG = draft of "certificate, CRL, and OCSP processing" document (12 = months).
    First WG = draft of "certificate re-issuance" document (4 = months).
    First WG = draft of "certificate renewal" document (4 months).
9. First WG = draft of "certificate revocation" document (8 = months).
 IESG = submission of "trust model" document (16 months).
11. IESG = submission of "public-key submission and certificate installation" = document (16 months).
12. IESG = submission of "certificate, CRL, and OCSP profile" document (20 = months).
 IESG = submission of "certificate, CRL, and OCSP processing" document (24 = months).
 IESG = submission of "certificate re-issuance" document (16 = months).
 IESG = submission of "certificate renewal" document (16 = months).
 IESG = submission of "certificate revocation" document (20 = months)
The schedule is = predicated upon the group's ability to recruit a sufficient number of = editors and engage either the relevant product experts or other experts = willing to test the selected product = configurations.  
T: +1 613 270 = 3183
 



wpkops mailing list
wpkops@ietf.org
wpkops@ietf.org

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkemgqfGKRj/ReNQlpfW0h5K+h5ihFXyZ3/B/2yWv72sYfFWCdzot+gAJW26PFfTEkccra0XVk30BSWIVUTaBUL1K+A3qW18A3IAvLgF1X1gvr5vBRTNJuwvwHCTN58KNpPWsUqkit6xeol+VctZe/8gEI2/MnfV2x+IW4gjGZgdr0fPAYBP0jKAjKFKxtwWO9QbCiF
Cc: "Moudrick M. Dadashov" , "wpkops@ietf.org" , Tim Moses 
Subject: Re: [wpkops] First draft charter proposal
X-BeenThere: wpkops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Aug 2012 23:25:38 -0000

On Wed, Aug 22, 2012 at 3:29 PM, Hill, Brad  wrote:

> I think =E2=80=9Cthe Web=E2=80=9D / HTTPS is the only PKI (other than the=
 work PKIX
> does/did) with enough actually interoperating implementations that a body
> like the IETF is best-positioned to document current and historical
> practices.

Exactly.

The problem of documenting current, real-world behavior for just the
HTTPS PKI is plenty hard enough; I see no reason to increase the scope
to even hairier problems right now. One impossible task at a time,
please.

From stpeter@stpeter.im  Wed Aug 22 18:04:53 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 D7AFD21F84F8 for ; Wed, 22 Aug 2012 18:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level: 
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 YQBOmGdRsMLL for ; Wed, 22 Aug 2012 18:04:53 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3621F84F5 for ; Wed, 22 Aug 2012 18:04:53 -0700 (PDT)
Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4C075404EB; Wed, 22 Aug 2012 19:05:42 -0600 (MDT)
Message-ID: <503581B4.9070702@stpeter.im>
Date: Wed, 22 Aug 2012 19:04:52 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Hill, Brad" 
References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com>
In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: "Moudrick M. Dadashov" , "'wpkops@ietf.org'" , Tim Moses 
Subject: Re: [wpkops] First draft charter proposal
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, 23 Aug 2012 01:04:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/22/12 4:29 PM, Hill, Brad wrote:

> I think “the Web†/ HTTPS is the only PKI (other than the work
> PKIX does/did) with enough actually interoperating
> implementations...

Brad, do you include the use of PKIX certificates in application
technologies like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog, and
XMPP as part of or derivative from "the Web PKI"? The proposed charter
seems tightly focused on browsers and HTTPS, but (as documented in RFC
6125) there's plenty of implementation and deployment of PKIX
certificates outside that space.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA1gbQACgkQNL8k5A2w/vyTrACg0UuaY0WHCWqXn6ZfnIapFG2K
h6UAoPldt4Pp01duTrgJv9h/c+xsEFZv
=iDW8
-----END PGP SIGNATURE-----

From rturner@amalfisystems.com  Wed Aug 22 21:22: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 82FBE11E809B for ; Wed, 22 Aug 2012 21:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRzyfPoPcz3t for ; Wed, 22 Aug 2012 21:22:07 -0700 (PDT)
Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACBB11E808A for ; Wed, 22 Aug 2012 21:22:06 -0700 (PDT)
Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7N4M5xr006819 for ; Thu, 23 Aug 2012 00:22:05 -0400
X-Authenticated-IP: 98.151.18.90
Received: from [98.151.18.90] ([98.151.18.90:59948] helo=[192.168.1.106]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id E5/DE-11452-DEFA5305; Thu, 23 Aug 2012 00:22:05 -0400
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1278)
From: Randy Turner 
In-Reply-To: <503581B4.9070702@stpeter.im>
Date: Wed, 22 Aug 2012 21:22:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <054110FE-25B7-4847-9930-8BB0B184E210@amalfisystems.com>
References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <503581B4.9070702@stpeter.im>
To: wpkops@ietf.org
X-Mailer: Apple Mail (2.1278)
Subject: Re: [wpkops] First draft charter proposal
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, 23 Aug 2012 04:22:16 -0000

This was part of what I was alluding to earlier, the value of this work =
being applied to protocols/applications like the ones described below
(for my own selfish interests, I was thinking about SIP and XMPP :)

Randy

On Aug 22, 2012, at 6:04 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 8/22/12 4:29 PM, Hill, Brad wrote:
>=20
>> I think =93the Web=94 / HTTPS is the only PKI (other than the work
>> PKIX does/did) with enough actually interoperating
>> implementations...
>=20
> Brad, do you include the use of PKIX certificates in application
> technologies like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog, and
> XMPP as part of or derivative from "the Web PKI"? The proposed charter
> seems tightly focused on browsers and HTTPS, but (as documented in RFC
> 6125) there's plenty of implementation and deployment of PKIX
> certificates outside that space.
>=20
> Peter
>=20
> - --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iEYEARECAAYFAlA1gbQACgkQNL8k5A2w/vyTrACg0UuaY0WHCWqXn6ZfnIapFG2K
> h6UAoPldt4Pp01duTrgJv9h/c+xsEFZv
> =3DiDW8
> -----END PGP SIGNATURE-----
> _______________________________________________
> wpkops mailing list
> wpkops@ietf.org
> https://www.ietf.org/mailman/listinfo/wpkops


From bhill@paypal-inc.com  Wed Aug 22 21:23:20 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 2C8CA11E809C for ; Wed, 22 Aug 2012 21:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.047
X-Spam-Level: 
X-Spam-Status: No, score=-9.047 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 YUnQNsib9u2b for ; Wed, 22 Aug 2012 21:23:19 -0700 (PDT)
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 6DBB711E8097 for ; Wed, 22 Aug 2012 21:23:19 -0700 (PDT)
DomainKey-Signature: s=ppinc; 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:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=U0Auxi92fqIuVHmIjgm5rq8rK37qWkMsZVx0CGT3ZsuyBS9mP5F7n4iz Q/2lJO//+94xjE+mrUe606pYDAlTmHLtXlCLMQZ9RYC+pLhInSuDkRaV7 BFxAjAbsYIoYvIl;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1345695800; x=1377231800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l1wDAJp7PDdqSHs2FBW4x4AyS/m+KmkCAYjM5zTtDS0=; b=r5YF2CVs/fKLmw3Lkx/q3L3iLVNS7qAc2Q16iPinwMqm/Vy4+T+Kw7NH KGfYLJXl59dy3wcfHx7WR07LIX4JFz4FwNjscWr4Zb7YG2Z6wnFihTtxJ HE5bCnnh0aPLaEd;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.80,298,1344236400";  d="scan'208";a="9319442"
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; 22 Aug 2012 21:23:19 -0700
Received: from DEN-EXDDA-S11.corp.ebay.com ([fe80::74c6:c884:c352:716]) by DEN-EXMHT-001.corp.ebay.com ([fe80::345e:2420:7d3d:208d%13]) with mapi id 14.02.0298.004; Wed, 22 Aug 2012 22:23:16 -0600
From: "Hill, Brad" 
To: Peter Saint-Andre 
Thread-Topic: [wpkops] First draft charter proposal
Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQASI2WgAA0y8IAAC5VH0P//2/QAgAAvbsA=
Date: Thu, 23 Aug 2012 04:23:15 +0000
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1F3630@DEN-EXDDA-S11.corp.ebay.com>
References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <503581B4.9070702@stpeter.im>
In-Reply-To: <503581B4.9070702@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.245.27.243]
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: bpCqGUwrilFM5v2Kzz6i6Q==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "Moudrick M. Dadashov" , "'wpkops@ietf.org'" , Tim Moses 
Subject: Re: [wpkops] First draft charter proposal
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, 23 Aug 2012 04:23:20 -0000

PiBCcmFkLCBkbyB5b3UgaW5jbHVkZSB0aGUgdXNlIG9mIFBLSVggY2VydGlmaWNhdGVzIGluIGFw
cGxpY2F0aW9uIHRlY2hub2xvZ2llcw0KPiBsaWtlIElNQVAsIExEQVAsIE5FVENPTkYsIFNJUCwg
U01UUCwgU05NUCwgU3lzbG9nLCBhbmQgWE1QUCBhcyBwYXJ0IG9mIG9yDQo+IGRlcml2YXRpdmUg
ZnJvbSAidGhlIFdlYiBQS0kiPyBUaGUgcHJvcG9zZWQgY2hhcnRlciBzZWVtcyB0aWdodGx5IGZv
Y3VzZWQNCj4gb24gYnJvd3NlcnMgYW5kIEhUVFBTLCBidXQgKGFzIGRvY3VtZW50ZWQgaW4gUkZD
DQo+IDYxMjUpIHRoZXJlJ3MgcGxlbnR5IG9mIGltcGxlbWVudGF0aW9uIGFuZCBkZXBsb3ltZW50
IG9mIFBLSVggY2VydGlmaWNhdGVzDQo+IG91dHNpZGUgdGhhdCBzcGFjZS4NCg0KR29vZCBxdWVz
dGlvbnMuICBUaGV5IGFyZSBjbG9zZXIgY291c2lucyB0aGFuIHRoZSBvZmZsaW5lIHVzZSBjYXNl
cy4gIE15IGZvbGxvdyB1cCBxdWVzdGlvbnMgd291bGQgYmU6DQoNCmEpIElzIHRoZXJlIHRoZSBz
YW1lIHBlcmNlaXZlZCBuZWVkIHRvIGRvY3VtZW50IHRoZSAic3RhdGUgb2YgaW50ZXJvcCIgZm9y
IHRoZXNlIHVzZXMgb2YgUEtJWCBhcyB0aGVyZSBpcyBmb3IgSFRUUFM/DQpiKSBBcmUgdGhlIHJp
Z2h0IGV4cGVydHMgYW5kIHN0YWtlaG9sZGVycyBoZXJlIGFuZCBpbnRlcmVzdGVkIGluIHRhY2ts
aW5nIGFueS9zb21lL2FsbCBvZiB0aGVzZSBhcyBwYXJ0IG9mIHRoaXMgcHJvcG9zZWQgV0c/DQpj
KSBXaWxsIHRob3NlIHBlb3BsZSBjb21taXQgdG8gZWRpdCBhbmQgY29udHJpYnV0ZSB0byB0aGUg
cmVsZXZhbnQgZGVsaXZlcmFibGVzPw0KZCkgRG9lcyB0aGF0IHdvcmsgZGVwZW5kIG9uIG9yIGJ1
aWxkIGRpcmVjdGx5IGZyb20gdGhlIEhUVFBTIHdvcmssIG9yIGFyZSB0aGVyZSBvdGhlciBXR3Mg
d2hlcmUgaXQgY2FuIGJlIHVuZGVydGFrZW4gb24gaXRzIG93biB0aW1lbGluZSBhbmQgd2hlcmUg
dGhlICJyaWdodCBwZW9wbGUiIGFyZSBhbHJlYWR5IGFzc2VtYmxlZD8NCg0KLUJyYWQNCg0KPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZXRlciBTYWludC1BbmRyZSBbbWFp
bHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0NCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjIsIDIw
MTIgNjowNSBQTQ0KPiBUbzogSGlsbCwgQnJhZA0KPiBDYzogTW91ZHJpY2sgTS4gRGFkYXNob3Y7
ICd3cGtvcHNAaWV0Zi5vcmcnOyBUaW0gTW9zZXMNCj4gU3ViamVjdDogUmU6IFt3cGtvcHNdIEZp
cnN0IGRyYWZ0IGNoYXJ0ZXIgcHJvcG9zYWwNCj4gDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBN
RVNTQUdFLS0tLS0NCj4gSGFzaDogU0hBMQ0KPiANCj4gT24gOC8yMi8xMiA0OjI5IFBNLCBIaWxs
LCBCcmFkIHdyb3RlOg0KPiANCj4gPiBJIHRoaW5rIOKAnHRoZSBXZWLigJ0gLyBIVFRQUyBpcyB0
aGUgb25seSBQS0kgKG90aGVyIHRoYW4gdGhlIHdvcmsgUEtJWA0KPiA+IGRvZXMvZGlkKSB3aXRo
IGVub3VnaCBhY3R1YWxseSBpbnRlcm9wZXJhdGluZyBpbXBsZW1lbnRhdGlvbnMuLi4NCj4gDQo+
IEJyYWQsIGRvIHlvdSBpbmNsdWRlIHRoZSB1c2Ugb2YgUEtJWCBjZXJ0aWZpY2F0ZXMgaW4gYXBw
bGljYXRpb24gdGVjaG5vbG9naWVzDQo+IGxpa2UgSU1BUCwgTERBUCwgTkVUQ09ORiwgU0lQLCBT
TVRQLCBTTk1QLCBTeXNsb2csIGFuZCBYTVBQIGFzIHBhcnQgb2Ygb3INCj4gZGVyaXZhdGl2ZSBm
cm9tICJ0aGUgV2ViIFBLSSI/IFRoZSBwcm9wb3NlZCBjaGFydGVyIHNlZW1zIHRpZ2h0bHkgZm9j
dXNlZA0KPiBvbiBicm93c2VycyBhbmQgSFRUUFMsIGJ1dCAoYXMgZG9jdW1lbnRlZCBpbiBSRkMN
Cj4gNjEyNSkgdGhlcmUncyBwbGVudHkgb2YgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQg
b2YgUEtJWCBjZXJ0aWZpY2F0ZXMNCj4gb3V0c2lkZSB0aGF0IHNwYWNlLg0KPiANCj4gUGV0ZXIN
Cj4gDQo+IC0gLS0NCj4gUGV0ZXIgU2FpbnQtQW5kcmUNCj4gaHR0cHM6Ly9zdHBldGVyLmltLw0K
PiANCj4gDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IFZlcnNpb246IEdudVBH
L01hY0dQRzIgdjIuMC4xOCAoRGFyd2luKQ0KPiBDb21tZW50OiBVc2luZyBHbnVQRyB3aXRoIE1v
emlsbGEgLSBodHRwOi8vZW5pZ21haWwubW96ZGV2Lm9yZy8NCj4gDQo+IGlFWUVBUkVDQUFZRkFs
QTFnYlFBQ2drUU5MOGs1QTJ3L3Z5VHJBQ2cwVXVhWTBXSENXcVhuNlpmbklhcEZHDQo+IDJLDQo+
IGg2VUFvUGxkdDRQcDAxZHVUcmdKdjloL2MreHNFRlp2DQo+ID1pRFc4DQo+IC0tLS0tRU5EIFBH
UCBTSUdOQVRVUkUtLS0tLQ0K

From rturner@amalfisystems.com  Wed Aug 22 21:23: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 05FDA11E80D3 for ; Wed, 22 Aug 2012 21:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZaQTcKpSEqY for ; Wed, 22 Aug 2012 21:23:33 -0700 (PDT)
Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id B6E5B11E80D1 for ; Wed, 22 Aug 2012 21:23:32 -0700 (PDT)
Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7N4NVEo011983 for ; Thu, 23 Aug 2012 00:23:31 -0400
X-Authenticated-IP: 98.151.18.90
Received: from [98.151.18.90] ([98.151.18.90:59981] helo=[192.168.1.106]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id C9/87-26049-240B5305; Thu, 23 Aug 2012 00:23:31 -0400
From: Randy Turner 
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_76CB05D3-EC23-4456-AD73-2800BAEAA320"
Date: Wed, 22 Aug 2012 21:23:30 -0700
In-Reply-To: 
To: wpkops@ietf.org
References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> 
Message-Id: <27E55FD0-C7F2-4C8B-9E1F-48AB2057D2C4@amalfisystems.com>
X-Mailer: Apple Mail (2.1278)
Subject: Re: [wpkops] First draft charter proposal
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, 23 Aug 2012 04:23:35 -0000

--Apple-Mail=_76CB05D3-EC23-4456-AD73-2800BAEAA320
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


Yes, I was specifically referring to signing timestamps and/or content =
as a part of the LTANS work=85I just wasn't sure if there were products =
in the marketplace that could be called "LTANS-compliant"=20

R.

On Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote:

> I do not know what you mean by =93shipping=94 here, but LTANS did work =
on long term non repudiation and time stamp resulting Evidence Record =
Structure RFC.
> =20
> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On =
Behalf Of Randy Turner
> Sent: Wednesday, August 22, 2012 6:38 PM
> To: wpkops@ietf.org
> Subject: Re: [wpkops] First draft charter proposal
> =20
> =20
> I would agree with the scope that "signing" brings into the potential =
work of a WG, but I think there might be a fair amount of interoperable =
S/MIME experience as well that could be discussed.
> =20
> Code signing is a bit fragmented, although there have been discussions =
on using CMS for generating signed code containers, but vendors largely =
do what they want (as you mentioned)
> =20
> The LTANS working group looked at document archival awhile back, and =
did some work on timestamping, but I'm not aware of any shipping =
implementations that standardized their long-term archival strategies =
regarding signatures or timestamping (not that there aren't any, I just =
don't keep up with this)
> =20
> R.
> =20
> =20
> On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote:
>=20
>=20
> Moudrick Dadashov wrote:
> =20
> >Right, but obviously seeking to narrow the scope we need a wider =
vision, right?
> >Exclusion of "documents etc." has its historical reasons, not =
technological.
> =20
> I think it does have technological reasons:  Document and code signing =
has to:
> =20
> * Deal with problems of long-lived artifacts =96 including signed =
objects that may outlive the certificates used to sign them
> * Work by default without a direct connection to the entity in control =
of the certificate
> * Support entirely offline verification
> =20
>    This has also led to different practices about revocation and =
blacklisting, use of third party time stamping authorities, etc.  The =
differences are substantial.
> =20
> Code signing in particular is also HIGHLY vendor-specific.  I may be =
mistaken, but my impression is that it=92s not meaningful at all to talk =
about a single set of practices around code signing that is common =
across multiple platforms =96 Java, Apple App Store, Android Apps,  =
Microsoft Authenticode, Strong Named Assemblies in .NET, etc.=20
> =20
> Java and Authenticode may have interoperable certificate formats, but =
how they are used still differs greatly.  Individual vendors remain in =
the best position to provide authoritative guidance on their own =
implementations.=20
> =20
> Document signing is a bit more interoperable, though still more =
fragmented than the Web by regulatory requirements and jurisdictional =
boundaries, and often additionally by document formats. (PDF vs. Word =
vs. XML)
> =20
> I think =93the Web=94 / HTTPS is the only PKI (other than the work =
PKIX does/did) with enough actually interoperating implementations that =
a body like the IETF is best-positioned to document current and =
historical practices.
> =20
> -Brad
> =20
> From: Moudrick M. Dadashov [mailto:md@ssc.lt]=20
> Sent: Wednesday, August 22, 2012 2:42 PM
> To: Hill, Brad
> Cc: Tim Moses; 'wpkops@ietf.org'
> Subject: Re: [wpkops] First draft charter proposal
> =20
> Right, but obviously seeking to narrow the scope we need a wider =
vision, right? Exclusion of "documents etc." has its historical reasons, =
not technological. Why not to form a generic vision and based on that =
try to figure out the scope of interest.
>=20
> Thanks,
> M.D.
>=20
> On 8/23/2012 12:27 AM, Hill, Brad wrote:
> I agree with Tim that we should start with a narrow scope focused on =
the Web PKI rather than documents, etc.,  I also think there are cases =
that are on the edge =96 like the programmatic HTTP clients used by =
mobile aps, embedded browsing contexts with different PKI error handling =
logic than standalone ones, and, towards the more complex end, web =
services that use HTTP and the web PKI explicitly but might also use =
other transports and trust models.  Not clear from the draft charter =
where to draw the line among these, but there is plenty of work to do =
and that needs doing urgently.
> =20
> Brad Hill
> =20
> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On =
Behalf Of Tim Moses
> Sent: Wednesday, August 22, 2012 5:45 AM
> To: 'wpkops@ietf.org'
> Subject: [wpkops] First draft charter proposal
> =20
> Colleagues =96 Here is a first draft of a charter proposal.  Please =
give it some thought and share the results of your deliberations.  =
Thanks a lot.  All the best.  Tim.
> =20
> The Web PKI is the set of systems and procedures most commonly used to =
protect the confidentiality, integrity and authenticity of =
communications between Web browsers and Web content servers.  It 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 hundreds of variations =
on the Web PKI in regular use.  And this can be a source of problems =
both for end-users and certificate issuers.
> =20
> For end-users, there is no clear view whether certificate "problems" =
remain when they see indication of a "good" connection.  For instance, =
in some browsers, 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.
> =20
> And for 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 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
> 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.
> =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 (other than the Web) may use =
the same trust anchors as the ones used by the Web.  These applications =
include: document signing; code signing; and email.  They may use PKI in =
a way that differs from the way in which the Web uses it.  Therefore, =
these applications are explicitly out of scope for the working group.
> =20
> Also, the reliability of the Web PKI depends critically on the =
practices of its certificate issuers.  However, the topic of practices =
is outside the scope of the IETF.  Therefore, this will be left to other =
competent bodies.
> =20
> That there are technical shortcomings with Web PKI, as it is practiced =
today, is well recognized.  And, that there is also some urgency in =
addressing these shortcomings is also well recognized.  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.
> =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.  The working group should =
focus its initial attention on the browser and server versions that make =
up the largest part of the desktop and mobile Web today.
> =20
> The output documents will all be BCP-style RFCs.
> =20
> 1.    Agree the working group charter (1 month).
> 2.    Catalog the products and versions to be analyzed (1 month).
> 3.    First WG draft of "trust model" document (4 months).
> 4.    First WG draft of "public-key submission and certificate =
installation" document (4 months).
> 5.    First WG draft of "certificate, CRL, and OCSP profile" document =
(8 months).
> 6.    First WG draft of "certificate, CRL, and OCSP processing" =
document (12 months).
> 7.    First WG draft of "certificate re-issuance" document (4 months).
> 8.    First WG draft of "certificate renewal" document (4 months).
> 9.    First WG draft of "certificate revocation" document (8 months).
> 10. IESG submission of "trust model" document (16 months).
> 11. IESG submission of "public-key submission and certificate =
installation" document (16 months).
> 12. IESG submission of "certificate, CRL, and OCSP profile" document =
(20 months).
> 13. IESG submission of "certificate, CRL, and OCSP processing" =
document (24 months).
> 14. IESG submission of "certificate re-issuance" document (16 months).
> 15. IESG submission of "certificate renewal" document (16 months).
> 16. IESG submission of "certificate revocation" document (20 months)
> =20
> The schedule is predicated upon the group's ability to recruit a =
sufficient number of editors and engage either the relevant product =
experts or other experts willing to test the selected product =
configurations. =20
> =20
> =20
> T: +1 613 270 3183
> =20
>=20
>=20
>=20
>=20
> _______________________________________________
> wpkops mailing list
> wpkops@ietf.org
> https://www.ietf.org/mailman/listinfo/wpkops
> =20
> _______________________________________________
> wpkops mailing list
> wpkops@ietf.org
> https://www.ietf.org/mailman/listinfo/wpkops
> =20


--Apple-Mail=_76CB05D3-EC23-4456-AD73-2800BAEAA320
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



Yes, I was specifically referring to =
signing timestamps and/or content as a part of the LTANS work=85I just =
wasn't sure if there were products in the marketplace that could be =
called =
"LTANS-compliant" 

R.

On =
Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote:

I do not =
know what you mean by =93shipping=94 here, but LTANS did work on long =
term non repudiation and time stamp resulting Evidence Record Structure =
RFC.
From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.o=
rg] On Behalf =
Of Randy =
Turner
Sent: Wednesday, August 22, 2012 =
6:38 PM
To: wpkops@ietf.org
Subject: Re: [wpkops] First draft =
charter proposal
 
I would agree with the =
scope that "signing" brings into the potential work of a WG, but I think =
there might be a fair amount of interoperable S/MIME experience as well =
that could be discussed.
Code signing is a bit =
fragmented, although there have been discussions on using CMS for =
generating signed code containers, but vendors largely do what they want =
(as you mentioned)
The LTANS working group =
looked at document archival awhile back, and did some work on =
timestamping, but I'm not aware of any shipping implementations that =
standardized their long-term archival strategies regarding signatures or =
timestamping (not that there aren't any, I just don't keep up with =
this)
On Aug 22, 2012, at 3:29 =
PM, Hill, Brad wrote:
Moudrick =
Dadashov wrote:
>Right, but obviously seeking to narrow the scope we need a =
wider vision, right?
>Exclusion of "documents etc." has its =
historical reasons, not =
technological.
 I =
think it does have technological reasons:  Document and code =
signing has to:
* Deal with problems of =
long-lived artifacts =96 including signed objects that may outlive the =
certificates used to sign them* =
Work by default without a direct connection to the entity in control of =
the certificate* =
Support entirely offline verification
   This has also led to =
different practices about revocation and blacklisting, use of third =
party time stamping authorities, etc.  The differences are =
substantial.
 
Code signing in particular is also HIGHLY =
vendor-specific.  I may be mistaken, but my impression is that it=92s=
 not meaningful at all to talk about a single set of practices around =
code signing that is common across multiple platforms =96 Java, Apple =
App Store, Android Apps,  Microsoft Authenticode, Strong Named =
Assemblies in .NET, etc. 
Java and Authenticode may have =
interoperable certificate formats, but how they are used still differs =
greatly.  Individual vendors remain in the best position to provide =
authoritative guidance on their own implementations. 
 
 
I think =93the Web=94 / HTTPS is the only PKI (other =
than the work PKIX does/did) with enough actually interoperating =
implementations that a body like the IETF is best-positioned to document =
current and historical practices.
-Brad
 
Moudrick M. Dadashov [mailto:md@ssc.lt] 
Sent: Wednesday, August 22, 2012 =
2:42 PM
To: Hill, =
Brad
Cc: Tim =
Moses; ' Re: [wpkops] First draft =
charter proposal 
From:wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim =
Moses
Sent: Wednesday, August 22, 2012 =
5:45 AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First draft =
charter proposal 
Colleagues =96 Here is a first draft of a =
charter proposal.  Please give it some thought and share the =
results of your deliberations.  Thanks a lot.  All the =
best.  Tim.
The Web PKI =
is the set of systems and procedures most commonly used to protect the =
confidentiality, integrity and authenticity of communications between =
Web browsers and Web content servers.  It 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 hundreds of variations on the Web PKI in =
regular use.  And this can be a source of problems both for =
end-users and certificate =
issuers.
For =
end-users, there is no clear view whether certificate "problems" remain =
when they see indication of a "good" connection.  For instance, in =
some browsers, 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.
And for =
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 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.
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 (other than the =
Web) may use the same trust anchors as the ones used by the Web.  =
These applications include: document signing; code signing; and =
email.  They may use PKI in a way that differs from the way in =
which the Web uses it.  Therefore, these applications are =
explicitly out of scope for the working =
group.
Also, the =
reliability of the Web PKI depends critically on the practices of its =
certificate issuers.  However, the topic of practices is outside =
the scope of the IETF.  Therefore, this will be left to other =
competent bodies.
 
That there are technical shortcomings with Web PKI, as =
it is practiced today, is well recognized.  And, that there is also =
some urgency in addressing these shortcomings is also well =
recognized.  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, it is =
agreed that adherence to the published schedule should take precedence =
over completeness of the results.  The working group should focus =
its initial attention on the browser and server versions that make up =
the largest part of the desktop and mobile Web =
today.
The output =
documents will all be BCP-style =
RFCs.
1.    Agree the =
working group charter (1 month).
 Catalog the =
products and versions to be analyzed (1 =
month).
3.    First WG =
draft of "trust model" document (4 =
months).
4.    First WG =
draft of "public-key submission and certificate installation" document =
(4 months).
5.    First WG =
draft of "certificate, CRL, and OCSP profile" document (8 =
months).
6.    First WG =
draft of "certificate, CRL, and OCSP processing" document (12 =
months).
7.    First WG =
draft of "certificate re-issuance" document (4 =
months).
8.    First WG =
draft of "certificate renewal" document (4 =
months).
9.    First WG =
draft of "certificate revocation" document (8 =
months).
10. IESG submission of "trust model" document =
(16 months).
11. IESG submission of "public-key submission =
and certificate installation" document (16 =
months).
12. IESG submission of "certificate, CRL, and =
OCSP profile" document (20 months).
 IESG =
submission of "certificate, CRL, and OCSP processing" document (24 =
months).
14. IESG submission of "certificate re-issuance" =
document (16 months).
 IESG =
submission of "certificate renewal" document (16 =
months).
16. IESG submission of "certificate revocation" =
document (20 months)
 
The schedule is predicated upon the group's ability to =
recruit a sufficient number of editors and engage either the relevant =
product experts or other experts willing to test the selected product =
configurations.  
 
T: +1 613 270 =
3183




wpkops mailing =
list
wpkops@ietf.org
wpkops@ietf.org
To: Randy Turner , "wpkops@ietf.org" Date: Wed, 22 Aug 2012 22:05:05 -0400 Thread-Topic: [wpkops] First draft charter proposal Thread-Index: Ac2Atts8rbAj6XQFT7uECSgEMoUqiAAHKpCQ Message-ID: References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> In-Reply-To: <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF36299DAEscygexch7cygnac_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 23 Aug 2012 02:39:40 -0700 Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 02:05:17 -0000 --_000_B83745DA469B7847811819C5005244AF36299DAEscygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not know what you mean by "shipping" here, but LTANS did work on long = term non repudiation and time stamp resulting Evidence Record Structure RFC= . From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Randy Turner Sent: Wednesday, August 22, 2012 6:38 PM To: wpkops@ietf.org Subject: Re: [wpkops] First draft charter proposal I would agree with the scope that "signing" brings into the potential work = of a WG, but I think there might be a fair amount of interoperable S/MIME e= xperience as well that could be discussed. Code signing is a bit fragmented, although there have been discussions on u= sing CMS for generating signed code containers, but vendors largely do what= they want (as you mentioned) The LTANS working group looked at document archival awhile back, and did so= me work on timestamping, but I'm not aware of any shipping implementations = that standardized their long-term archival strategies regarding signatures = or timestamping (not that there aren't any, I just don't keep up with this) R. On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote: Moudrick Dadashov wrote: >Right, but obviously seeking to narrow the scope we need a wider vision, r= ight? >Exclusion of "documents etc." has its historical reasons, not technologica= l. I think it does have technological reasons: Document and code signing has = to: * Deal with problems of long-lived artifacts - including signed objects tha= t may outlive the certificates used to sign them * Work by default without a direct connection to the entity in control of t= he certificate * Support entirely offline verification This has also led to different practices about revocation and blacklisti= ng, use of third party time stamping authorities, etc. The differences are= substantial. Code signing in particular is also HIGHLY vendor-specific. I may be mistak= en, but my impression is that it's not meaningful at all to talk about a si= ngle set of practices around code signing that is common across multiple pl= atforms - Java, Apple App Store, Android Apps, Microsoft Authenticode, Str= ong Named Assemblies in .NET, etc. Java and Authenticode may have interoperable certificate formats, but how t= hey are used still differs greatly. Individual vendors remain in the best = position to provide authoritative guidance on their own implementations. Document signing is a bit more interoperable, though still more fragmented = than the Web by regulatory requirements and jurisdictional boundaries, and = often additionally by document formats. (PDF vs. Word vs. XML) I think "the Web" / HTTPS is the only PKI (other than the work PKIX does/di= d) with enough actually interoperating implementations that a body like the= IETF is best-positioned to document current and historical practices. -Brad From: Moudrick M. Dadashov [mailto:md@ssc.lt] Sent: Wednesday, August 22, 2012 2:42 PM To: Hill, Brad Cc: Tim Moses; 'wpkops@ietf.org' Subject: Re: [wpkops] First draft charter proposal Right, but obviously seeking to narrow the scope we need a wider vision, ri= ght? Exclusion of "documents etc." has its historical reasons, not technolo= gical. Why not to form a generic vision and based on that try to figure out= the scope of interest. Thanks, M.D. On 8/23/2012 12:27 AM, Hill, Brad wrote: I agree with Tim that we should start with a narrow scope focused on the We= b PKI rather than documents, etc., I also think there are cases that are o= n the edge - like the programmatic HTTP clients used by mobile aps, embedde= d browsing contexts with different PKI error handling logic than standalone= ones, and, towards the more complex end, web services that use HTTP and th= e web PKI explicitly but might also use other transports and trust models. = Not clear from the draft charter where to draw the line among these, but t= here is plenty of work to do and that needs doing urgently. Brad Hill From: wpkops-bounces@ietf.org [mailto:wpkop= s-bounces@ietf.org] On Behalf Of Tim Moses Sent: Wednesday, August 22, 2012 5:45 AM To: 'wpkops@ietf.org' Subject: [wpkops] First draft charter proposal Colleagues - Here is a first draft of a charter proposal. Please give it s= ome thought and share the results of your deliberations. Thanks a lot. Al= l the best. Tim. The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems both for end-users and certificate issuers. 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 refu= se to display the contents under these circumstances. And for 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 se= rver supplies a response that does not include the nonce, it is hard to kno= w 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. 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 (other than the Web) may use the sam= e trust anchors as the ones used by the Web. These applications include: d= ocument signing; code signing; and email. They may use PKI in a way that d= iffers from the way in which the Web uses it. Therefore, these application= s are explicitly out of scope for the working group. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers. However, the topic of practices is outside the s= cope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. 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. The working group should focus its init= ial attention on the browser and server versions that make up the largest p= art of the desktop and mobile Web today. The output documents will all be BCP-style RFCs. 1. Agree the working group charter (1 month). 2. Catalog the products and versions to be analyzed (1 month). 3. First WG draft of "trust model" document (4 months). 4. First WG draft of "public-key submission and certificate installation= " document (4 months). 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 mo= nths). 6. First WG draft of "certificate, CRL, and OCSP processing" document (1= 2 months). 7. First WG draft of "certificate re-issuance" document (4 months). 8. First WG draft of "certificate renewal" document (4 months). 9. First WG draft of "certificate revocation" document (8 months). 10. IESG submission of "trust model" document (16 months). 11. IESG submission of "public-key submission and certificate installation"= document (16 months). 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 mo= nths). 13. IESG submission of "certificate, CRL, and OCSP processing" document (24= months). 14. IESG submission of "certificate re-issuance" document (16 months). 15. IESG submission of "certificate renewal" document (16 months). 16. IESG submission of "certificate revocation" document (20 months) The schedule is predicated upon the group's ability to recruit a sufficient= number of editors and engage either the relevant product experts or other = experts willing to test the selected product configurations. T: +1 613 270 3183 _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops --_000_B83745DA469B7847811819C5005244AF36299DAEscygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not kno= w what you mean by “shipping” here, but LTANS did work on long = term non repudiation and time stamp resulting Evidence Record Structure RFC= .

 

From: wpkops-bounces@ietf.org [mailto:wpk= ops-bounces@ietf.org] On Behalf Of Randy Turner
Sent: Wedn= esday, August 22, 2012 6:38 PM
To: wpkops@ietf.org
Subject:= Re: [wpkops] First draft charter proposal

<= /div>

 

 

I would agree with the scope = that "signing" brings into the potential work of a WG, but I thin= k there might be a fair amount of interoperable S/MIME experience as well t= hat could be discussed.

 =

Code signing is a bit fragmented,= although there have been discussions on using CMS for generating signed co= de containers, but vendors largely do what they want (as you mentioned)

 

=

The LTANS working group looked at document archival aw= hile back, and did some work on timestamping, but I'm not aware of any ship= ping implementations that standardized their long-term archival strategies = regarding signatures or timestamping (not that there aren't any, I just don= 't keep up with this)

&n= bsp;

R.

<= p class=3DMsoNormal> 

 

On Aug 22, 2012, at 3:29 = PM, Hill, Brad wrote:



Moudrick Dadashov wrote:

 

>Right, but obviously seeki= ng to narrow the scope we need a wider vision, right?

=

>Exclusion of "documents etc.&= quot; has its historical reasons, not technological.

<= /div>

 <= /p>

I think it does have technologica= l reasons:  Document and code signing has to:

 

* Deal with problems of= long-lived artifacts – including signed objects that may outlive the= certificates used to sign them

* Work by default without a direct connection = to the entity in control of the certificate

* Support entirely offline verific= ation

 

=    This has also led to different practices about revocati= on and blacklisting, use of third party time stamping authorities, etc.&nbs= p; The differences are substantial.

=

 

Code signing in particular is also HIG= HLY vendor-specific.  I may be mistaken, but my impression is that it&= #8217;s not meaningful at all to talk about a single set of practices aroun= d code signing that is common across multiple platforms – Java, Apple= App Store, Android Apps,  Microsoft Authenticode, Strong Named Assemb= lies in .NET, etc. 

 

Java and Authenticode may have interoperable cert= ificate formats, but how they are used still differs greatly.  Individ= ual vendors remain in the best position to provide authoritative guidance o= n their own implementations. 

<= div>

 

Document signing is a bit more interope= rable, though still more fragmented than the Web by regulatory requirements= and jurisdictional boundaries, and often additionally by document formats.= (PDF vs. Word vs. XML)

 

I think “the Web” / HTTPS is the only = PKI (other than the work PKIX does/did) with enough actually interoperating= implementations that a body like the IETF is best-positioned to document c= urrent and historical practices.

 

-Brad

 

 

Right, but obvi= ously seeking to narrow the scope we need a wider vision, right? Exclusion = of "documents etc." has its historical reasons, not technological= . Why not to form a generic vision and based on that try to figure out the = scope of interest.

Thanks,
M.D.

On 8/23/2012 12:27 AM, Hil= l, Brad wrote:

I agree wi= th Tim that we should start with a narrow scope focused on the Web PKI rath= er than documents, etc.,  I also think there are cases that are on the= edge – like the programmatic HTTP clients used by mobile aps, embedd= ed browsing contexts with different PKI error handling logic than standalon= e ones, and, towards the more complex end, web services that use HTTP and t= he web PKI explicitly but might also use other transports and trust models.=   Not clear from the draft charter where to draw the line among these,= but there is plenty of work to do and that needs doing urgently.

 

Brad Hil= l

&= nbsp;

=

From: wpkops-bounces@ietf.org = [mailto:wpkops-bounces@ie= tf.org] On Behalf Of=  Tim Moses
Sent:<= /b> Wednesday, August 22, 2= 012 5:45 AM
To: '= wpkops@ietf.org'
Subject:<= span class=3Dapple-converted-space> [wpkops] First draft charte= r proposal

 

Colleagues – Here is a first draft of a charter proposal.&nbs= p; Please give it some thought and share the results of your deliberations.=   Thanks a lot.  All the best.  Tim.

 

<= p class=3DMsoNormal>The Web PKI is the set of systems and procedures most commonly us= ed to protect the confidentiality, integrity and authenticity of communicat= ions between Web browsers and Web content servers.  It 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 hundreds of variations on the Web PKI in r= egular use.  And this can be a source of problems both for end-users a= nd certificate issuers.

 

For end-users, there is no clear = view whether certificate "problems" remain when they see indicati= on of a "good" connection.  For instance, in some browsers, = a "good" indication may be displayed when a "revoked" r= esponse has been received and "accepted" by the user.  Where= as, other browsers may refuse to display the contents under these circumsta= nces.

 

And for issuers, it can be difficult to predict wha= t proportion of the user population will accept a certificate chain with ce= rtain 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 re= ject the response.

 

Starting from the premise that more co= nsistency in Web security behavior is desirable, a natural first step would= be to document current and historic browser and server behavior.

 

Future activities may attempt to prescribe how the Web PKI "s= hould" work, and the prescription may turn out to be a proper subset o= f the PKIX PKI.  However, that task is explicitly not a goal of the pr= oposed working group.  Instead, the group's goal is merely to describe= how the Web PKI "actually" works in the set of browsers and serv= ers that are in common use today.

 

Additionally, a numbe= r of applications (other than the Web) may use the same trust anchors as th= e ones used by the Web.  These applications include: document signing;= code signing; and email.  They may use PKI in a way that differs from= the way in which the Web uses it.  Therefore, these applications are = explicitly out of scope for the working group.

<= div>

 

= Also, the = reliability of the Web PKI depends critically on the practices of its certi= ficate issuers.  However, the topic of practices is outside the scope = of the IETF.  Therefore, this will be left to other competent bodies.<= o:p>

 

That there are technical shortcomings with Web PKI, as it= is practiced today, is well recognized.  And, that there is also some= urgency in addressing these shortcomings is also well recognized.  Bu= t, it is felt that too much haste can be counter-productive.  The expe= ctation 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 gr= oups of the IETF's Security Area, and that suppliers will be willing to par= ticipate in those working groups and modify their products to comply with t= heir standards.

 

Given the urgency of the required develop= ments and the scale of the task, it is agreed that adherence to the publish= ed schedule should take precedence over completeness of the results.  = The working group should focus its initial attention on the browser and ser= ver versions that make up the largest part of the desktop and mobile Web to= day.

 

The output documents will all be BCP-style RFCs.

 

<= div style=3D'margin-left:.25in'>

1.<= /span>    Agree the working group charter (1 m= onth).

2.    C= atalog the products and versions to be analyzed (1 month).

3.  &= nbsp; First WG draft of "= trust model" document (4 months).

<= span style=3D'font-family:"Helvetica","sans-serif";color:black'>4.    First WG draft of "public-key submissio= n and certificate installation" document (4 months).=

5.  &n= bsp; First WG draft of "c= ertificate, CRL, and OCSP profile" document (8 months).

6.  = ;  First WG draft of &qu= ot;certificate, CRL, and OCSP processing" document (12 months).

7.&nb= sp;   First WG draft= of "certificate re-issuance" document (4 months).

8.  = ;  First WG draft of &qu= ot;certificate renewal" document (4 months).

= 9.    First WG draft of "certifica= te revocation" document (8 months).

10. IESG submission of "trust model" document (16 mon= ths).

11. IESG submission of= "public-key submission and certificate installation" document (1= 6 months).

12. IESG submissio= n of "certificate, CRL, and OCSP profile" document (20 months).

13. IESG submission of "c= ertificate, CRL, and OCSP processing" document (24 months).=

14. IESG submission of "certificat= e re-issuance" document (16 months).

15. IESG submission of "certificate renewal" documen= t (16 months).

=

16. = IESG submi= ssion of "certificate revocation" document (20 months)=

 

The schedule is predicated upon the group's ability to recruit a su= fficient number of editors and engage either the relevant product experts o= r other experts willing to test the selected product configurations. &= nbsp;

 =

 

T: +1 613 270 3183

 

<= /div>




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

 

_________________________________________= ______
wpkops mailing list
wpkops@= ietf.org
ht= tps://www.ietf.org/mailman/listinfo/wpkops

<= /div>

 

= --_000_B83745DA469B7847811819C5005244AF36299DAEscygexch7cygnac_-- From stephen.farrell@cs.tcd.ie Thu Aug 23 02:44:26 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 1EAAB21F85C6 for ; Thu, 23 Aug 2012 02:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nITgFrlPmpG for ; Thu, 23 Aug 2012 02:44:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8067F21F843F for ; Thu, 23 Aug 2012 02:44:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6CB791714FE; Thu, 23 Aug 2012 10:44:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1345715060; bh=+FBuSfWd24wTu6 7arTSJpRN5xep5gRs7YDwkWrg3XNg=; b=sQs7aZm3pSkrL31tS81+p5L8suYLGB Y13+fTMsIzE/N7laz1v8wX1uF5W02IUh0mG5TwlWwb0ugGQHFDZRY0T1FZ3GxcNe t94sKVO8vSuP8QQB3jNJCvdrF11qEmWQllTpiV9ukT+DlBjIwQHD+roCsf/Dyg5h z0z/WJRMsQyon/EVPLevVYZjXsWda4DNk2/QimrZeLTYD2lNI1KczuWjuJRnMNuk ap8F7CNhBuUNC4hvzDkKrbxwfHhm3zkMd9s1chssvVa+sw8OUZzwvl7lqDEeopmO 4at2uTDBKjRJPG0KI4crIqpR4TVXhjAuLXugCMFtXZzxJWdMbDLC1upA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 4a2aF1t3yC3F; Thu, 23 Aug 2012 10:44:20 +0100 (IST) Received: from [10.87.48.7] (unknown [86.44.72.248]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 591A0171485; Thu, 23 Aug 2012 10:44:18 +0100 (IST) Message-ID: <5035FB71.6040707@cs.tcd.ie> Date: Thu, 23 Aug 2012 10:44:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Turner References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> <27E55FD0-C7F2-4C8B-9E1F-48AB2057D2C4@amalfisystems.com> In-Reply-To: <27E55FD0-C7F2-4C8B-9E1F-48AB2057D2C4@amalfisystems.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: wpkops@ietf.org Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 09:44:26 -0000 FWIW, I'd be *highly* skeptical that an OPS area WG is needed to address anything whatsoever about LTANS. While it might be fine work, its just not sufficiently deployed for that to be useful. S. On 08/23/2012 05:23 AM, Randy Turner wrote: > > Yes, I was specifically referring to signing timestamps and/or content as a part of the LTANS work…I just wasn't sure if there were products in the marketplace that could be called "LTANS-compliant" > > R. > > On Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote: > >> I do not know what you mean by “shipping” here, but LTANS did work on long term non repudiation and time stamp resulting Evidence Record Structure RFC. >> >> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Randy Turner >> Sent: Wednesday, August 22, 2012 6:38 PM >> To: wpkops@ietf.org >> Subject: Re: [wpkops] First draft charter proposal >> >> >> I would agree with the scope that "signing" brings into the potential work of a WG, but I think there might be a fair amount of interoperable S/MIME experience as well that could be discussed. >> >> Code signing is a bit fragmented, although there have been discussions on using CMS for generating signed code containers, but vendors largely do what they want (as you mentioned) >> >> The LTANS working group looked at document archival awhile back, and did some work on timestamping, but I'm not aware of any shipping implementations that standardized their long-term archival strategies regarding signatures or timestamping (not that there aren't any, I just don't keep up with this) >> >> R. >> >> >> On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote: >> >> >> Moudrick Dadashov wrote: >> >>> Right, but obviously seeking to narrow the scope we need a wider vision, right? >>> Exclusion of "documents etc." has its historical reasons, not technological. >> >> I think it does have technological reasons: Document and code signing has to: >> >> * Deal with problems of long-lived artifacts – including signed objects that may outlive the certificates used to sign them >> * Work by default without a direct connection to the entity in control of the certificate >> * Support entirely offline verification >> >> This has also led to different practices about revocation and blacklisting, use of third party time stamping authorities, etc. The differences are substantial. >> >> Code signing in particular is also HIGHLY vendor-specific. I may be mistaken, but my impression is that it’s not meaningful at all to talk about a single set of practices around code signing that is common across multiple platforms – Java, Apple App Store, Android Apps, Microsoft Authenticode, Strong Named Assemblies in .NET, etc. >> >> Java and Authenticode may have interoperable certificate formats, but how they are used still differs greatly. Individual vendors remain in the best position to provide authoritative guidance on their own implementations. >> >> Document signing is a bit more interoperable, though still more fragmented than the Web by regulatory requirements and jurisdictional boundaries, and often additionally by document formats. (PDF vs. Word vs. XML) >> >> I think “the Web” / HTTPS is the only PKI (other than the work PKIX does/did) with enough actually interoperating implementations that a body like the IETF is best-positioned to document current and historical practices. >> >> -Brad >> >> From: Moudrick M. Dadashov [mailto:md@ssc.lt] >> Sent: Wednesday, August 22, 2012 2:42 PM >> To: Hill, Brad >> Cc: Tim Moses; 'wpkops@ietf.org' >> Subject: Re: [wpkops] First draft charter proposal >> >> Right, but obviously seeking to narrow the scope we need a wider vision, right? Exclusion of "documents etc." has its historical reasons, not technological. Why not to form a generic vision and based on that try to figure out the scope of interest. >> >> Thanks, >> M.D. >> >> On 8/23/2012 12:27 AM, Hill, Brad wrote: >> I agree with Tim that we should start with a narrow scope focused on the Web PKI rather than documents, etc., I also think there are cases that are on the edge – like the programmatic HTTP clients used by mobile aps, embedded browsing contexts with different PKI error handling logic than standalone ones, and, towards the more complex end, web services that use HTTP and the web PKI explicitly but might also use other transports and trust models. Not clear from the draft charter where to draw the line among these, but there is plenty of work to do and that needs doing urgently. >> >> Brad Hill >> >> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses >> Sent: Wednesday, August 22, 2012 5:45 AM >> To: 'wpkops@ietf.org' >> Subject: [wpkops] First draft charter proposal >> >> Colleagues – Here is a first draft of a charter proposal. Please give it some thought and share the results of your deliberations. Thanks a lot. All the best. Tim. >> >> The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers. It 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 hundreds of variations on the Web PKI in regular use. And this can be a source of problems both for end-users and certificate issuers. >> >> For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection. For instance, in some browsers, 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. >> >> And for 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 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. >> >> 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 (other than the Web) may use the same trust anchors as the ones used by the Web. These applications include: document signing; code signing; and email. They may use PKI in a way that differs from the way in which the Web uses it. Therefore, these applications are explicitly out of scope for the working group. >> >> Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers. However, the topic of practices is outside the scope of the IETF. Therefore, this will be left to other competent bodies. >> >> That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized. And, that there is also some urgency in addressing these shortcomings is also well recognized. 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, it is agreed that adherence to the published schedule should take precedence over completeness of the results. The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today. >> >> The output documents will all be BCP-style RFCs. >> >> 1. Agree the working group charter (1 month). >> 2. Catalog the products and versions to be analyzed (1 month). >> 3. First WG draft of "trust model" document (4 months). >> 4. First WG draft of "public-key submission and certificate installation" document (4 months). >> 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 months). >> 6. First WG draft of "certificate, CRL, and OCSP processing" document (12 months). >> 7. First WG draft of "certificate re-issuance" document (4 months). >> 8. First WG draft of "certificate renewal" document (4 months). >> 9. First WG draft of "certificate revocation" document (8 months). >> 10. IESG submission of "trust model" document (16 months). >> 11. IESG submission of "public-key submission and certificate installation" document (16 months). >> 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months). >> 13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months). >> 14. IESG submission of "certificate re-issuance" document (16 months). >> 15. IESG submission of "certificate renewal" document (16 months). >> 16. IESG submission of "certificate revocation" document (20 months) >> >> The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations. >> >> >> T: +1 613 270 3183 >> >> >> >> >> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> > > > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From md@ssc.lt Thu Aug 23 03:03:18 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 6109B21F861D for ; Thu, 23 Aug 2012 03:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.369, 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 8UNUEv0bn4+o for ; Thu, 23 Aug 2012 03:03:14 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7D21F85F7 for ; Thu, 23 Aug 2012 03:03:12 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.101]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1T4UFi-0006au-43; Thu, 23 Aug 2012 13:03:02 +0300 Message-ID: <5035FFD8.9000702@ssc.lt> Date: Thu, 23 Aug 2012 13:03:04 +0300 From: "Moudrick M. Dadashov" Organization: Skaitmeninio sertifikavimo centras User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Hill, Brad" References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> Content-Type: multipart/alternative; boundary="------------020909040403040505080402" Cc: "'wpkops@ietf.org'" , Tim Moses Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 10:03:18 -0000 This is a multi-part message in MIME format. --------------020909040403040505080402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/23/2012 1:29 AM, Hill, Brad wrote: > > Moudrick Dadashov wrote: > > >Right, but obviously seeking to narrow the scope we need a wider > vision, right? > > >Exclusion of "documents etc." has its historical reasons, not > technological. > > I think it does have technological reasons: Document and code signing > has to: > > * Deal with problems of long-lived artifacts -- including signed > objects that may outlive the certificates used to sign them > > * Work by default without a direct connection to the entity in control > of the certificate > > * Support entirely offline verification > or just to identify those generic building blocks that are common to many similar use scenarios. If web client authentication fits into the "narrowed scope" why web signing doesn't? > > This has also led to different practices about revocation and > blacklisting, use of third party time stamping authorities, etc. The > differences are substantial. > Sure, service/application specific specialties are obviously out of scope. > > Code signing in particular is also HIGHLY vendor-specific. I may be > mistaken, but my impression is that it's not meaningful at all to talk > about a single set of practices around code signing that is common > across multiple platforms -- Java, Apple App Store, Android Apps, > Microsoft Authenticode, Strong Named Assemblies in .NET, etc. > > Java and Authenticode may have interoperable certificate formats, but > how they are used still differs greatly. Individual vendors remain in > the best position to provide authoritative guidance on their own > implementations. > > Document signing is a bit more interoperable, though still more > fragmented than the Web by regulatory requirements and jurisdictional > boundaries, and often additionally by document formats. (PDF vs. Word > vs. XML) > whatever the difference is, the underlying lower level operations (building blocks) are almost the same or very close, all we need at this stage is to identify them. > > I think "the Web" / HTTPS is the only PKI (other than the work PKIX > does/did) with enough actually interoperating implementations that a > body like the IETF is best-positioned to document current and > historical practices. > No doubt. Web client authentication, web content signing are second to that IMO. Thanks, M.D. > > -Brad > > *From:*Moudrick M. Dadashov [mailto:md@ssc.lt] > *Sent:* Wednesday, August 22, 2012 2:42 PM > *To:* Hill, Brad > *Cc:* Tim Moses; 'wpkops@ietf.org' > *Subject:* Re: [wpkops] First draft charter proposal > > Right, but obviously seeking to narrow the scope we need a wider > vision, right? Exclusion of "documents etc." has its historical > reasons, not technological. Why not to form a generic vision and based > on that try to figure out the scope of interest. > > Thanks, > M.D. > > On 8/23/2012 12:27 AM, Hill, Brad wrote: > > I agree with Tim that we should start with a narrow scope focused > on the Web PKI rather than documents, etc., I also think there > are cases that are on the edge -- like the programmatic HTTP > clients used by mobile aps, embedded browsing contexts with > different PKI error handling logic than standalone ones, and, > towards the more complex end, web services that use HTTP and the > web PKI explicitly but might also use other transports and trust > models. Not clear from the draft charter where to draw the line > among these, but there is plenty of work to do and that needs > doing urgently. > > Brad Hill > > *From:*wpkops-bounces@ietf.org > [mailto:wpkops-bounces@ietf.org] *On Behalf Of *Tim Moses > *Sent:* Wednesday, August 22, 2012 5:45 AM > *To:* 'wpkops@ietf.org ' > *Subject:* [wpkops] First draft charter proposal > > Colleagues -- Here is a first draft of a charter proposal. Please > give it some thought and share the results of your deliberations. > Thanks a lot. All the best. Tim. > > The Web PKI is the set of systems and procedures most commonly > used to protect the confidentiality, integrity and authenticity of > communications between Web browsers and Web content servers. It > 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 hundreds of variations on the Web PKI in regular use. And > this can be a source of problems both for end-users and > certificate issuers. > > For end-users, there is no clear view whether certificate > "problems" remain when they see indication of a "good" > connection. For instance, in some browsers, 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. > > And for 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 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. > > 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 (other than the Web) may > use the same trust anchors as the ones used by the Web. These > applications include: document signing; code signing; and email. > They may use PKI in a way that differs from the way in which the > Web uses it. Therefore, these applications are explicitly out of > scope for the working group. > > Also, the reliability of the Web PKI depends critically on the > practices of its certificate issuers. However, the topic of > practices is outside the scope of the IETF. Therefore, this will > be left to other competent bodies. > > That there are technical shortcomings with Web PKI, as it is > practiced today, is well recognized. And, that there is also some > urgency in addressing these shortcomings is also well recognized. > 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, it is agreed that adherence to the published schedule > should take precedence over completeness of the results. The > working group should focus its initial attention on the browser > and server versions that make up the largest part of the desktop > and mobile Web today. > > The output documents will all be BCP-style RFCs. > > 1.Agree the working group charter (1 month). > > 2.Catalog the products and versions to be analyzed (1 month). > > 3.First WG draft of "trust model" document (4 months). > > 4.First WG draft of "public-key submission and certificate > installation" document (4 months). > > 5.First WG draft of "certificate, CRL, and OCSP profile" document > (8 months). > > 6.First WG draft of "certificate, CRL, and OCSP processing" > document (12 months). > > 7.First WG draft of "certificate re-issuance" document (4 months). > > 8.First WG draft of "certificate renewal" document (4 months). > > 9.First WG draft of "certificate revocation" document (8 months). > > 10.IESG submission of "trust model" document (16 months). > > 11.IESG submission of "public-key submission and certificate > installation" document (16 months). > > 12.IESG submission of "certificate, CRL, and OCSP profile" > document (20 months). > > 13.IESG submission of "certificate, CRL, and OCSP processing" > document (24 months). > > 14.IESG submission of "certificate re-issuance" document (16 months). > > 15.IESG submission of "certificate renewal" document (16 months). > > 16.IESG submission of "certificate revocation" document (20 months) > > The schedule is predicated upon the group's ability to recruit a > sufficient number of editors and engage either the relevant > product experts or other experts willing to test the selected > product configurations. > > T: +1 613 270 3183 > > > > > _______________________________________________ > > wpkops mailing list > > wpkops@ietf.org > > https://www.ietf.org/mailman/listinfo/wpkops > --------------020909040403040505080402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/23/2012 1:29 AM, Hill, Brad wrote:

Moudrick Dadashov wrote:

 

>Right, but obviously seeking to narrow the scope we need a wider vision, right?

>Exclusion of "documents etc." has its historical reasons, not technological.

 

I think it does have technological reasons:  Document and code signing has to:

 

* Deal with problems of long-lived artifacts – including signed objects that may outlive the certificates used to sign them

* Work by default without a direct connection to the entity in control of the certificate

* Support entirely offline verification


or just to identify those generic building blocks that are common to many similar use scenarios. If web client authentication fits into the "narrowed scope" why web signing doesn't?

 

   This has also led to different practices about revocation and blacklisting, use of third party time stamping authorities, etc.  The differences are substantial.


Sure, service/application specific specialties are obviously out of scope.

 

Code signing in particular is also HIGHLY vendor-specific.  I may be mistaken, but my impression is that it’s not meaningful at all to talk about a single set of practices around code signing that is common across multiple platforms – Java, Apple App Store, Android Apps,  Microsoft Authenticode, Strong Named Assemblies in .NET, etc. 

 

Java and Authenticode may have interoperable certificate formats, but how they are used still differs greatly.  Individual vendors remain in the best position to provide authoritative guidance on their own implementations. 

 

Document signing is a bit more interoperable, though still more fragmented than the Web by regulatory requirements and jurisdictional boundaries, and often additionally by document formats. (PDF vs. Word vs. XML)

whatever the difference is, the underlying lower level operations (building blocks) are almost the same or very close, all we need at this stage is to identify them.

 

I think “the Web” / HTTPS is the only PKI (other than the work PKIX does/did) with enough actually interoperating implementations that a body like the IETF is best-positioned to document current and historical practices.

 

No doubt. Web client authentication, web content signing are second to that IMO.

Thanks,
M.D. 

-Brad

 

From: Moudrick M. Dadashov [mailto:md@ssc.lt]
Sent: Wednesday, August 22, 2012 2:42 PM
To: Hill, Brad
Cc: Tim Moses; 'wpkops@ietf.org'
Subject: Re: [wpkops] First draft charter proposal

 

Right, but obviously seeking to narrow the scope we need a wider vision, right? Exclusion of "documents etc." has its historical reasons, not technological. Why not to form a generic vision and based on that try to figure out the scope of interest.

Thanks,
M.D.

On 8/23/2012 12:27 AM, Hill, Brad wrote:

I agree with Tim that we should start with a narrow scope focused on the Web PKI rather than documents, etc.,  I also think there are cases that are on the edge – like the programmatic HTTP clients used by mobile aps, embedded browsing contexts with different PKI error handling logic than standalone ones, and, towards the more complex end, web services that use HTTP and the web PKI explicitly but might also use other transports and trust models.  Not clear from the draft charter where to draw the line among these, but there is plenty of work to do and that needs doing urgently.

 

Brad Hill

 

From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 5:45 AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First draft charter proposal

 

Colleagues – Here is a first draft of a charter proposal.  Please give it some thought and share the results of your deliberations.  Thanks a lot.  All the best.  Tim.

 

The Web PKI is the set of systems and procedures most commonly used to protect the confidentiality, integrity and authenticity of communications between Web browsers and Web content servers.  It 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 hundreds of variations on the Web PKI in regular use.  And this can be a source of problems both for end-users and certificate issuers.

 

For end-users, there is no clear view whether certificate "problems" remain when they see indication of a "good" connection.  For instance, in some browsers, 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.

 

And for 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 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.

 

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 (other than the Web) may use the same trust anchors as the ones used by the Web.  These applications include: document signing; code signing; and email.  They may use PKI in a way that differs from the way in which the Web uses it.  Therefore, these applications are explicitly out of scope for the working group.

 

Also, the reliability of the Web PKI depends critically on the practices of its certificate issuers.  However, the topic of practices is outside the scope of the IETF.  Therefore, this will be left to other competent bodies.

 

That there are technical shortcomings with Web PKI, as it is practiced today, is well recognized.  And, that there is also some urgency in addressing these shortcomings is also well recognized.  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, it is agreed that adherence to the published schedule should take precedence over completeness of the results.  The working group should focus its initial attention on the browser and server versions that make up the largest part of the desktop and mobile Web today.

 

The output documents will all be BCP-style RFCs.

 

1.    Agree the working group charter (1 month).

2.    Catalog the products and versions to be analyzed (1 month).

3.    First WG draft of "trust model" document (4 months).

4.    First WG draft of "public-key submission and certificate installation" document (4 months).

5.    First WG draft of "certificate, CRL, and OCSP profile" document (8 months).

6.    First WG draft of "certificate, CRL, and OCSP processing" document (12 months).

7.    First WG draft of "certificate re-issuance" document (4 months).

8.    First WG draft of "certificate renewal" document (4 months).

9.    First WG draft of "certificate revocation" document (8 months).

10. IESG submission of "trust model" document (16 months).

11. IESG submission of "public-key submission and certificate installation" document (16 months).

12. IESG submission of "certificate, CRL, and OCSP profile" document (20 months).

13. IESG submission of "certificate, CRL, and OCSP processing" document (24 months).

14. IESG submission of "certificate re-issuance" document (16 months).

15. IESG submission of "certificate renewal" document (16 months).

16. IESG submission of "certificate revocation" document (20 months)

 

The schedule is predicated upon the group's ability to recruit a sufficient number of editors and engage either the relevant product experts or other experts willing to test the selected product configurations.  

 

 

T: +1 613 270 3183

 




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

 


--------------020909040403040505080402-- From tim.moses@entrust.com Thu Aug 23 06:43:19 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 18D1A21F8525 for ; Thu, 23 Aug 2012 06:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.235, 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 wTvzai3Mbunu for ; Thu, 23 Aug 2012 06:43:14 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id E0F8121F8577 for ; Thu, 23 Aug 2012 06:43:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,300,1344225600"; d="scan'208,217";a="1707735" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 23 Aug 2012 09:43:11 -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.001; Thu, 23 Aug 2012 09:43:10 -0400 From: Tim Moses To: "'ben@digicert.com'" Thread-Topic: [wpkops] First draft charter proposal Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQAbfRGAABfcpmA= Date: Thu, 23 Aug 2012 13:43:10 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A571FC2@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <01ee01cd80b0$5cb4e1d0$161ea570$@digicert.com> In-Reply-To: <01ee01cd80b0$5cb4e1d0$161ea570$@digicert.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_5B68A271B9C97046963CB6A5B8D6F62C3A571FC2SOTTEXCH10corpa_" MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 13:43:19 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A571FC2SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben. I don't see a conflict. I think the CA/Browser Forum develops rec= ommendations (both technical and procedural) for modifications to the relev= ant audit standards (ETSI and WebTrust). If accepted, these recommendation= s get enforced "going forward". The proposal for WPKOPS is that it documen= t existing technical functionality. The CA/B Forum work is "prescriptive".= The WKPOPS work is "descriptive", but it would describe those CA/B Forum = recommendations that have already been enacted. Now, looking beyond WPKOPS, if this activity were to be successful (and by = "successful" I mean that it attracts experts who actually know how the Web = PKI works and have the ability to change it) then it could spawn other work= ing groups with a mandate to define how the future Web PKI will work. But,= now I'm getting ahead of myself. All the best. Tim. From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Ben Wilson Sent: Wednesday, August 22, 2012 5:52 PM To: Tim Moses; wpkops@ietf.org Subject: Re: [wpkops] First draft charter proposal Tim, How do you envision that any previous or future work product of members of = the CAB Forum on profile-type documents be integrated into the work of this= group? Namely, in Section 9 of the Baseline Requirements there was some language a= bout Issuer and Subject Identifiers, and then Appendices A and B discussed = key lengths, algorithms, and certificate extensions. I am thinking that because there will be an overlap of participation from m= any of the same players it will not be a problem, but will one group end up= deferring to the other on certain types of issues, or are they completely = separate? Thanks, Ben From: wpkops-bounces@ietf.org [mailto:wpkop= s-bounces@ietf.org] On Behalf Of Tim Moses Sent: Wednesday, August 22, 2012 6:45 AM To: 'wpkops@ietf.org' Subject: [wpkops] First draft charter proposal Colleagues - Here is a first draft of a charter proposal. Please give it s= ome thought and share the results of your deliberations. Thanks a lot. Al= l the best. Tim. The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems both for end-users and certificate issuers. 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 refu= se to display the contents under these circumstances. And for 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 se= rver supplies a response that does not include the nonce, it is hard to kno= w 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. 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 (other than the Web) may use the sam= e trust anchors as the ones used by the Web. These applications include: d= ocument signing; code signing; and email. They may use PKI in a way that d= iffers from the way in which the Web uses it. Therefore, these application= s are explicitly out of scope for the working group. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers. However, the topic of practices is outside the s= cope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. 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. The working group should focus its init= ial attention on the browser and server versions that make up the largest p= art of the desktop and mobile Web today. The output documents will all be BCP-style RFCs. 1. Agree the working group charter (1 month). 2. Catalog the products and versions to be analyzed (1 month). 3. First WG draft of "trust model" document (4 months). 4. First WG draft of "public-key submission and certificate installation= " document (4 months). 5. First WG draft of "certificate, CRL, and OCSP profile" document (8 mo= nths). 6. First WG draft of "certificate, CRL, and OCSP processing" document (1= 2 months). 7. First WG draft of "certificate re-issuance" document (4 months). 8. First WG draft of "certificate renewal" document (4 months). 9. First WG draft of "certificate revocation" document (8 months). 10. IESG submission of "trust model" document (16 months). 11. IESG submission of "public-key submission and certificate installation"= document (16 months). 12. IESG submission of "certificate, CRL, and OCSP profile" document (20 mo= nths). 13. IESG submission of "certificate, CRL, and OCSP processing" document (24= months). 14. IESG submission of "certificate re-issuance" document (16 months). 15. IESG submission of "certificate renewal" document (16 months). 16. IESG submission of "certificate revocation" document (20 months) The schedule is predicated upon the group's ability to recruit a sufficient= number of editors and engage either the relevant product experts or other = experts willing to test the selected product configurations. T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A571FC2SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ben.  I don= 217;t see a conflict.  I think the CA/Browser Forum develops recommend= ations (both technical and procedural) for modifications to the relevant au= dit standards (ETSI and WebTrust).  If accepted, these recommendations get enforced “going forward”.  The propos= al for WPKOPS is that it document existing technical functionality.  T= he CA/B Forum work is “prescriptive”.  The WKPOPS work is = “descriptive”, but it would describe those CA/B Forum recommend= ations that have already been enacted.

 

Now, looking beyond WP= KOPS, if this activity were to be successful (and by “successful̶= 1; I mean that it attracts experts who actually know how the Web PKI works = and have the ability to change it) then it could spawn other working groups with a mandate to define how the future Web PKI= will work.  But, now I’m getting ahead of myself.

 

All the best.  Ti= m.

 

From: wpkops-b= ounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Ben Wilson
Sent: Wednesday, August 22, 2012 5:52 PM
To: Tim Moses; wpkops@ietf.org
Subject: Re: [wpkops] First draft charter proposal=

 

Tim,=

How do you envision th= at any previous or future work product of members of the CAB Forum on profi= le-type documents be integrated into the work of this group?

Namely, in Section 9 o= f the Baseline Requirements there was some language about Issuer and Subjec= t Identifiers, and then Appendices A and B discussed key lengths, algorithm= s, and certificate extensions.

I am thinking that bec= ause there will be an overlap of participation from many of the same player= s it will not be a problem, but will one group end up deferring to the othe= r on certain types of issues, or are they completely separate?

Thanks,

Ben<= /p>

 

From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Tim Moses
Sent: Wednesday, August 22, 2012 6:45 AM
To: 'wpkops@ietf.org'
Subject: [wpkops] First draft charter proposal

 

Colleagues – Here is a first draft of a charte= r proposal.  Please give it some thought and share the results of your= deliberations.  Thanks a lot.  All the best.  Tim.

 

The Web PKI is the set of systems and procedures most co= mmonly used to protect the confidentiality, integrity and authenticity of c= ommunications between Web browsers and Web content servers.  It first = appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then.  Acr= oss all the suppliers and the point releases of their products, there are n= ow hundreds of variations on the Web PKI in regular use.  And this can= be a source of problems both for end-users and certificate issuers.

 

For end-users, there is no clear view whether certificat= e "problems" remain when they see indication of a "good"= ; connection.  For instance, in some browsers, a "good" indi= cation may be displayed when a "revoked" response has been receiv= ed and "accepted" by the user.  Whereas, other browsers may refuse= to display the contents under these circumstances.

 

And for issuers, it can be difficult to predict what pro= portion 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 server supplies a response that does not include the nonce, it is hard to know which browser= s will accept and which will reject the response.

 

Starting from the premise that more consistency in Web s= ecurity behavior is desirable, a natural first step would be to document cu= rrent and historic browser and server behavior.

 

Future activities may attempt to prescribe how the Web P= KI "should" work, and the prescription may turn out to be a prope= r 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 t= he set of browsers and servers that are in common use today.

 

Additionally, a number of applications (other than the W= eb) may use the same trust anchors as the ones used by the Web.  These= applications include: document signing; code signing; and email.  The= y may use PKI in a way that differs from the way in which the Web uses it.  Therefore, these applications are expl= icitly out of scope for the working group.

 

Also, the reliability of the Web PKI depends critically = on the practices of its certificate issuers.  However, the topic of pr= actices is outside the scope of the IETF.  Therefore, this will be lef= t to other competent bodies.

 

That there are technical shortcomings with Web PKI, as i= t is practiced today, is well recognized.  And, that there is also som= e urgency in addressing these shortcomings is also well recognized.  B= ut, 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 s= ystematic way, aspects of the Web PKI that should be progressed in future w= orking groups of the IETF's Security Area, and that suppliers will be willi= ng to participate in those working groups and modify their products to comply with their standards.

 

Given the urgency of the required developments and the s= cale of the task, it is agreed that adherence to the published schedule sho= uld take precedence over completeness of the results.  The working gro= up should focus its initial attention on the browser and server versions that make up the largest part of the deskt= op and mobile Web today.

 

The output documents will all be BCP-style RFCs.

 

1.    Agree the working group charter (1 month).

2.    Catalog the products and versions to be analyzed (1= month).

3.    First WG draft of "trust model" document = (4 months).

4.    First WG draft of "public-key submission and c= ertificate installation" document (4 months).

5.    First WG draft of "certificate, CRL, and OCSP = profile" document (8 months).

6.    First WG draft of "certificate, CRL, and OCSP = processing" document (12 months).

7.    First WG draft of "certificate re-issuance&quo= t; document (4 months).

8.    First WG draft of "certificate renewal" d= ocument (4 months).

9.    First WG draft of "certificate revocation"= ; document (8 months).

10. IESG submission of "trust model" document= (16 months).

11. IESG submission of "public-key submission and = certificate installation" document (16 months).

12. IESG submission of "certificate, CRL, and OCSP= profile" document (20 months).

13. IESG submission of "certificate, CRL, and OCSP= processing" document (24 months).

14. IESG submission of "certificate re-issuance&qu= ot; document (16 months).

15. IESG submission of "certificate renewal" = document (16 months).

16. IESG submission of "certificate revocation&quo= t; document (20 months)

 

The schedule is predicated upon the group's ability to r= ecruit a sufficient number of editors and engage either the relevant produc= t experts or other experts willing to test the selected product configurati= ons.  

 

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A571FC2SOTTEXCH10corpa_-- From rturner@amalfisystems.com Thu Aug 23 06:55:13 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 1966621F85A8 for ; Thu, 23 Aug 2012 06:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpNg5n-H6vcR for ; Thu, 23 Aug 2012 06:55:12 -0700 (PDT) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id AA46221F858A for ; Thu, 23 Aug 2012 06:55:11 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7NDtAK2011722 for ; Thu, 23 Aug 2012 09:55:10 -0400 X-Authenticated-IP: 98.151.18.90 Received: from [98.151.18.90] ([98.151.18.90:55783] helo=[192.168.1.104]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPS (cipher=AES128-SHA) id D4/DF-15542-E3636305; Thu, 23 Aug 2012 09:55:10 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Randy Turner In-Reply-To: <5035FB71.6040707@cs.tcd.ie> Date: Thu, 23 Aug 2012 06:55:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B1B8AB7-9732-433D-9008-95519DEC1B1C@amalfisystems.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> <27E55FD0-C7F2-4C8B-9E1F-48AB2057D2C4@amalfisystems.com> <5035FB71.6040707@cs.tcd.ie> To: wpkops@ietf.org X-Mailer: Apple Mail (2.1485) Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 13:55:13 -0000 Yes, that was my question=85.they were doing signature-like things, but = I wasn't sure about the size of any deployment=85.(i.e, "shipping = products") R. On Aug 23, 2012, at 2:44 AM, Stephen Farrell = wrote: >=20 > FWIW, I'd be *highly* skeptical that an OPS area WG is needed to > address anything whatsoever about LTANS. While it might be fine > work, its just not sufficiently deployed for that to be useful. >=20 > S. >=20 > On 08/23/2012 05:23 AM, Randy Turner wrote: >>=20 >> Yes, I was specifically referring to signing timestamps and/or = content as a part of the LTANS work=85I just wasn't sure if there were = products in the marketplace that could be called "LTANS-compliant"=20 >>=20 >> R. >>=20 >> On Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote: >>=20 >>> I do not know what you mean by =93shipping=94 here, but LTANS did = work on long term non repudiation and time stamp resulting Evidence = Record Structure RFC. >>>=20 >>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On = Behalf Of Randy Turner >>> Sent: Wednesday, August 22, 2012 6:38 PM >>> To: wpkops@ietf.org >>> Subject: Re: [wpkops] First draft charter proposal >>>=20 >>>=20 >>> I would agree with the scope that "signing" brings into the = potential work of a WG, but I think there might be a fair amount of = interoperable S/MIME experience as well that could be discussed. >>>=20 >>> Code signing is a bit fragmented, although there have been = discussions on using CMS for generating signed code containers, but = vendors largely do what they want (as you mentioned) >>>=20 >>> The LTANS working group looked at document archival awhile back, and = did some work on timestamping, but I'm not aware of any shipping = implementations that standardized their long-term archival strategies = regarding signatures or timestamping (not that there aren't any, I just = don't keep up with this) >>>=20 >>> R. >>>=20 >>>=20 >>> On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote: >>>=20 >>>=20 >>> Moudrick Dadashov wrote: >>>=20 >>>> Right, but obviously seeking to narrow the scope we need a wider = vision, right? >>>> Exclusion of "documents etc." has its historical reasons, not = technological. >>>=20 >>> I think it does have technological reasons: Document and code = signing has to: >>>=20 >>> * Deal with problems of long-lived artifacts =96 including signed = objects that may outlive the certificates used to sign them >>> * Work by default without a direct connection to the entity in = control of the certificate >>> * Support entirely offline verification >>>=20 >>> This has also led to different practices about revocation and = blacklisting, use of third party time stamping authorities, etc. The = differences are substantial. >>>=20 >>> Code signing in particular is also HIGHLY vendor-specific. I may be = mistaken, but my impression is that it=92s not meaningful at all to talk = about a single set of practices around code signing that is common = across multiple platforms =96 Java, Apple App Store, Android Apps, = Microsoft Authenticode, Strong Named Assemblies in .NET, etc.=20 >>>=20 >>> Java and Authenticode may have interoperable certificate formats, = but how they are used still differs greatly. Individual vendors remain = in the best position to provide authoritative guidance on their own = implementations.=20 >>>=20 >>> Document signing is a bit more interoperable, though still more = fragmented than the Web by regulatory requirements and jurisdictional = boundaries, and often additionally by document formats. (PDF vs. Word = vs. XML) >>>=20 >>> I think =93the Web=94 / HTTPS is the only PKI (other than the work = PKIX does/did) with enough actually interoperating implementations that = a body like the IETF is best-positioned to document current and = historical practices. >>>=20 >>> -Brad >>>=20 >>> From: Moudrick M. Dadashov [mailto:md@ssc.lt]=20 >>> Sent: Wednesday, August 22, 2012 2:42 PM >>> To: Hill, Brad >>> Cc: Tim Moses; 'wpkops@ietf.org' >>> Subject: Re: [wpkops] First draft charter proposal >>>=20 >>> Right, but obviously seeking to narrow the scope we need a wider = vision, right? Exclusion of "documents etc." has its historical reasons, = not technological. Why not to form a generic vision and based on that = try to figure out the scope of interest. >>>=20 >>> Thanks, >>> M.D. >>>=20 >>> On 8/23/2012 12:27 AM, Hill, Brad wrote: >>> I agree with Tim that we should start with a narrow scope focused on = the Web PKI rather than documents, etc., I also think there are cases = that are on the edge =96 like the programmatic HTTP clients used by = mobile aps, embedded browsing contexts with different PKI error handling = logic than standalone ones, and, towards the more complex end, web = services that use HTTP and the web PKI explicitly but might also use = other transports and trust models. Not clear from the draft charter = where to draw the line among these, but there is plenty of work to do = and that needs doing urgently. >>>=20 >>> Brad Hill >>>=20 >>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On = Behalf Of Tim Moses >>> Sent: Wednesday, August 22, 2012 5:45 AM >>> To: 'wpkops@ietf.org' >>> Subject: [wpkops] First draft charter proposal >>>=20 >>> Colleagues =96 Here is a first draft of a charter proposal. Please = give it some thought and share the results of your deliberations. = Thanks a lot. All the best. Tim. >>>=20 >>> The Web PKI is the set of systems and procedures most commonly used = to protect the confidentiality, integrity and authenticity of = communications between Web browsers and Web content servers. It 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 hundreds of variations = on the Web PKI in regular use. And this can be a source of problems = both for end-users and certificate issuers. >>>=20 >>> For end-users, there is no clear view whether certificate "problems" = remain when they see indication of a "good" connection. For instance, = in some browsers, 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. >>>=20 >>> And for 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 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 >>> 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. >>>=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 (other than the Web) may use = the same trust anchors as the ones used by the Web. These applications = include: document signing; code signing; and email. They may use PKI in = a way that differs from the way in which the Web uses it. Therefore, = these applications are explicitly out of scope for the working group. >>>=20 >>> Also, the reliability of the Web PKI depends critically on the = practices of its certificate issuers. However, the topic of practices = is outside the scope of the IETF. Therefore, this will be left to other = competent bodies. >>>=20 >>> That there are technical shortcomings with Web PKI, as it is = practiced today, is well recognized. And, that there is also some = urgency in addressing these shortcomings is also well recognized. 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. >>>=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. The working group should = focus its initial attention on the browser and server versions that make = up the largest part of the desktop and mobile Web today. >>>=20 >>> The output documents will all be BCP-style RFCs. >>>=20 >>> 1. Agree the working group charter (1 month). >>> 2. Catalog the products and versions to be analyzed (1 month). >>> 3. First WG draft of "trust model" document (4 months). >>> 4. First WG draft of "public-key submission and certificate = installation" document (4 months). >>> 5. First WG draft of "certificate, CRL, and OCSP profile" = document (8 months). >>> 6. First WG draft of "certificate, CRL, and OCSP processing" = document (12 months). >>> 7. First WG draft of "certificate re-issuance" document (4 = months). >>> 8. First WG draft of "certificate renewal" document (4 months). >>> 9. First WG draft of "certificate revocation" document (8 = months). >>> 10. IESG submission of "trust model" document (16 months). >>> 11. IESG submission of "public-key submission and certificate = installation" document (16 months). >>> 12. IESG submission of "certificate, CRL, and OCSP profile" document = (20 months). >>> 13. IESG submission of "certificate, CRL, and OCSP processing" = document (24 months). >>> 14. IESG submission of "certificate re-issuance" document (16 = months). >>> 15. IESG submission of "certificate renewal" document (16 months). >>> 16. IESG submission of "certificate revocation" document (20 months) >>>=20 >>> The schedule is predicated upon the group's ability to recruit a = sufficient number of editors and engage either the relevant product = experts or other experts willing to test the selected product = configurations. =20 >>>=20 >>>=20 >>> T: +1 613 270 3183 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >>>=20 >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >>=20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 From tim.moses@entrust.com Thu Aug 23 07:22: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 7894F21F849C for ; Thu, 23 Aug 2012 07:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 ovbVc7wrNftc for ; Thu, 23 Aug 2012 07:22:50 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id AA40C21F849B for ; Thu, 23 Aug 2012 07:22:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,300,1344225600"; d="scan'208";a="5993447" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 23 Aug 2012 10:22:48 -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.001; Thu, 23 Aug 2012 10:22:48 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: [wpkops] First draft charter proposal Thread-Index: AQHNgOcMhcHsamCRREOXQyLd0a8eMZdnaPmAgABGF4D//8LgsA== Date: Thu, 23 Aug 2012 14:22:48 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A572172@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> <27E55FD0-C7F2-4C8B-9E1F-48AB2057D2C4@amalfisystems.com> <5035FB71.6040707@cs.tcd.ie> <0B1B8AB7-9732-433D-9008-95519DEC1B1C@amalfisystems.com> In-Reply-To: <0B1B8AB7-9732-433D-9008-95519DEC1B1C@amalfisystems.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Randy Turner' Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 14:22:51 -0000 I agree with Brad and Stephen. We need to be addressing pressing practical= problems. And (in my mind) site-authentication qualifies. I understand S= tephen's concern about code-signing. But, it seems like significant extra = work. I wonder if it should be left out of the initial charter. Once we h= ave a better grasp of the type and quantity of resources that we can draw o= n, we could consider a re-chartering exercise to include it. All the best.= Tim. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Randy Turner Sent: Thursday, August 23, 2012 9:55 AM To: wpkops@ietf.org Subject: Re: [wpkops] First draft charter proposal Yes, that was my question....they were doing signature-like things, but I w= asn't sure about the size of any deployment....(i.e, "shipping products") R. On Aug 23, 2012, at 2:44 AM, Stephen Farrell wr= ote: >=20 > FWIW, I'd be *highly* skeptical that an OPS area WG is needed to=20 > address anything whatsoever about LTANS. While it might be fine work,=20 > its just not sufficiently deployed for that to be useful. >=20 > S. >=20 > On 08/23/2012 05:23 AM, Randy Turner wrote: >>=20 >> Yes, I was specifically referring to signing timestamps and/or content a= s a part of the LTANS work...I just wasn't sure if there were products in t= he marketplace that could be called "LTANS-compliant"=20 >>=20 >> R. >>=20 >> On Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote: >>=20 >>> I do not know what you mean by "shipping" here, but LTANS did work on l= ong term non repudiation and time stamp resulting Evidence Record Structure= RFC. >>>=20 >>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 >>> Behalf Of Randy Turner >>> Sent: Wednesday, August 22, 2012 6:38 PM >>> To: wpkops@ietf.org >>> Subject: Re: [wpkops] First draft charter proposal >>>=20 >>>=20 >>> I would agree with the scope that "signing" brings into the potential w= ork of a WG, but I think there might be a fair amount of interoperable S/MI= ME experience as well that could be discussed. >>>=20 >>> Code signing is a bit fragmented, although there have been=20 >>> discussions on using CMS for generating signed code containers, but=20 >>> vendors largely do what they want (as you mentioned) >>>=20 >>> The LTANS working group looked at document archival awhile back, and=20 >>> did some work on timestamping, but I'm not aware of any shipping=20 >>> implementations that standardized their long-term archival=20 >>> strategies regarding signatures or timestamping (not that there=20 >>> aren't any, I just don't keep up with this) >>>=20 >>> R. >>>=20 >>>=20 >>> On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote: >>>=20 >>>=20 >>> Moudrick Dadashov wrote: >>>=20 >>>> Right, but obviously seeking to narrow the scope we need a wider visio= n, right? >>>> Exclusion of "documents etc." has its historical reasons, not technolo= gical. >>>=20 >>> I think it does have technological reasons: Document and code signing = has to: >>>=20 >>> * Deal with problems of long-lived artifacts - including signed=20 >>> objects that may outlive the certificates used to sign them >>> * Work by default without a direct connection to the entity in=20 >>> control of the certificate >>> * Support entirely offline verification >>>=20 >>> This has also led to different practices about revocation and blackli= sting, use of third party time stamping authorities, etc. The differences = are substantial. >>>=20 >>> Code signing in particular is also HIGHLY vendor-specific. I may be mi= staken, but my impression is that it's not meaningful at all to talk about = a single set of practices around code signing that is common across multipl= e platforms - Java, Apple App Store, Android Apps, Microsoft Authenticode,= Strong Named Assemblies in .NET, etc.=20 >>>=20 >>> Java and Authenticode may have interoperable certificate formats, but h= ow they are used still differs greatly. Individual vendors remain in the b= est position to provide authoritative guidance on their own implementations= .=20 >>>=20 >>> Document signing is a bit more interoperable, though still more=20 >>> fragmented than the Web by regulatory requirements and=20 >>> jurisdictional boundaries, and often additionally by document=20 >>> formats. (PDF vs. Word vs. XML) >>>=20 >>> I think "the Web" / HTTPS is the only PKI (other than the work PKIX doe= s/did) with enough actually interoperating implementations that a body like= the IETF is best-positioned to document current and historical practices. >>>=20 >>> -Brad >>>=20 >>> From: Moudrick M. Dadashov [mailto:md@ssc.lt] >>> Sent: Wednesday, August 22, 2012 2:42 PM >>> To: Hill, Brad >>> Cc: Tim Moses; 'wpkops@ietf.org' >>> Subject: Re: [wpkops] First draft charter proposal >>>=20 >>> Right, but obviously seeking to narrow the scope we need a wider vision= , right? Exclusion of "documents etc." has its historical reasons, not tech= nological. Why not to form a generic vision and based on that try to figure= out the scope of interest. >>>=20 >>> Thanks, >>> M.D. >>>=20 >>> On 8/23/2012 12:27 AM, Hill, Brad wrote: >>> I agree with Tim that we should start with a narrow scope focused on th= e Web PKI rather than documents, etc., I also think there are cases that a= re on the edge - like the programmatic HTTP clients used by mobile aps, emb= edded browsing contexts with different PKI error handling logic than standa= lone ones, and, towards the more complex end, web services that use HTTP an= d the web PKI explicitly but might also use other transports and trust mode= ls. Not clear from the draft charter where to draw the line among these, b= ut there is plenty of work to do and that needs doing urgently. >>>=20 >>> Brad Hill >>>=20 >>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 >>> Behalf Of Tim Moses >>> Sent: Wednesday, August 22, 2012 5:45 AM >>> To: 'wpkops@ietf.org' >>> Subject: [wpkops] First draft charter proposal >>>=20 >>> Colleagues - Here is a first draft of a charter proposal. Please give = it some thought and share the results of your deliberations. Thanks a lot.= All the best. Tim. >>>=20 >>> The Web PKI is the set of systems and procedures most commonly used to = protect the confidentiality, integrity and authenticity of communications b= etween Web browsers and Web content servers. It first appeared in 1993 or = thereabouts and has developed continuously in a somewhat organic fashion si= nce then. Across all the suppliers and the point releases of their product= s, there are now hundreds of variations on the Web PKI in regular use. And= this can be a source of problems both for end-users and certificate issuer= s. >>>=20 >>> For end-users, there is no clear view whether certificate "problems" re= main when they see indication of a "good" connection. For instance, in som= e browsers, 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. >>>=20 >>> And for issuers, it can be difficult to predict what proportion of the = user population will accept a certificate chain with certain characteristic= s. For instance, when a browser includes a nonce in an OCSP request but th= e 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 >>> Starting from the premise that more consistency in Web security behavio= r is desirable, a natural first step would be to document current and histo= ric browser and server behavior. >>>=20 >>> Future activities may attempt to prescribe how the Web PKI "should" wor= k, 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 "actuall= y" works in the set of browsers and servers that are in common use today. >>>=20 >>> Additionally, a number of applications (other than the Web) may use the= same trust anchors as the ones used by the Web. These applications includ= e: document signing; code signing; and email. They may use PKI in a way th= at differs from the way in which the Web uses it. Therefore, these applica= tions are explicitly out of scope for the working group. >>>=20 >>> Also, the reliability of the Web PKI depends critically on the practice= s of its certificate issuers. However, the topic of practices is outside t= he scope of the IETF. Therefore, this will be left to other competent bodi= es. >>>=20 >>> That there are technical shortcomings with Web PKI, as it is practiced = today, is well recognized. And, that there is also some urgency in address= ing these shortcomings is also well recognized. But, it is felt that too m= uch haste can be counter-productive. The expectation is that the work of t= his 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 A= rea, and that suppliers will be willing to participate in those working gro= ups and modify their products to comply with their standards. >>>=20 >>> Given the urgency of the required developments and the scale of the tas= k, it is agreed that adherence to the published schedule should take preced= ence over completeness of the results. The working group should focus its = initial attention on the browser and server versions that make up the large= st part of the desktop and mobile Web today. >>>=20 >>> The output documents will all be BCP-style RFCs. >>>=20 >>> 1. Agree the working group charter (1 month). >>> 2. Catalog the products and versions to be analyzed (1 month). >>> 3. First WG draft of "trust model" document (4 months). >>> 4. First WG draft of "public-key submission and certificate installa= tion" document (4 months). >>> 5. First WG draft of "certificate, CRL, and OCSP profile" document (= 8 months). >>> 6. First WG draft of "certificate, CRL, and OCSP processing" documen= t (12 months). >>> 7. First WG draft of "certificate re-issuance" document (4 months). >>> 8. First WG draft of "certificate renewal" document (4 months). >>> 9. First WG draft of "certificate revocation" document (8 months). >>> 10. IESG submission of "trust model" document (16 months). >>> 11. IESG submission of "public-key submission and certificate installat= ion" document (16 months). >>> 12. IESG submission of "certificate, CRL, and OCSP profile" document (2= 0 months). >>> 13. IESG submission of "certificate, CRL, and OCSP processing" document= (24 months). >>> 14. IESG submission of "certificate re-issuance" document (16 months). >>> 15. IESG submission of "certificate renewal" document (16 months). >>> 16. IESG submission of "certificate revocation" document (20 months) >>>=20 >>> The schedule is predicated upon the group's ability to recruit a suffic= ient number of editors and engage either the relevant product experts or ot= her experts willing to test the selected product configurations. =20 >>>=20 >>>=20 >>> T: +1 613 270 3183 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >>>=20 >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >>=20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From rturner@amalfisystems.com Thu Aug 23 07:37:21 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 2DBCD21F8557 for ; Thu, 23 Aug 2012 07:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 F5KDcpuFZkCo for ; Thu, 23 Aug 2012 07:37:20 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id AAB5621F8530 for ; Thu, 23 Aug 2012 07:37:19 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7NEbIqj030331 for ; Thu, 23 Aug 2012 10:37:18 -0400 X-Authenticated-IP: 98.151.18.90 Received: from [98.151.18.90] ([98.151.18.90:57379] helo=[192.168.1.104]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPS (cipher=AES128-SHA) id 9E/DC-26650-E1046305; Thu, 23 Aug 2012 10:37:18 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Randy Turner In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A572172@SOTTEXCH10.corp.ad.entrust.com> Date: Thu, 23 Aug 2012 07:37:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <90569382-F2E0-44F4-9112-D10126F7DAEB@amalfisystems.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> <27E55FD0-C7F2-4C8B-9E1F-48AB2057D2C4@amalfisystems.com> <5035FB71.6040707@cs.tcd.ie> <0B1B8AB7-9732-433D-9008-95519DEC1B1C@amalfisystems.com> <5B68A271B9C97046963CB6A5B8D6F62C3A572172@SOTTEXCH10.corp.ad.entrust.com> To: "wpkops@ietf.org" X-Mailer: Apple Mail (2.1485) Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 14:37:21 -0000 I think Stephen's reminder about the "OPS" designation in the proposed = WG, is a good one. If that's the case, then, by definition, it's probably existing pressing = issues with deployed standards that's the target (or so it would seem). By eliminating signing we're saying one of the following: 1. Signatures are not deployed significantly to end-users, so it's not = an OPS problem 2. Signatures "are" deployed significantly, but there are no perceived = issues in the current deployment 3. The scope of web browser/server use of PKI (site authentication, = etc.) by itself is enough for the WG I think it's #3=20 I'm ok with the go-forward "Once we have a better grasp=85" strategy = included in the Tim's note below. R. On Aug 23, 2012, at 7:22 AM, Tim Moses wrote: > I agree with Brad and Stephen. We need to be addressing pressing = practical problems. And (in my mind) site-authentication qualifies. I = understand Stephen's concern about code-signing. But, it seems like = significant extra work. I wonder if it should be left out of the = initial charter. Once we have a better grasp of the type and quantity = of resources that we can draw on, we could consider a re-chartering = exercise to include it. All the best. Tim. >=20 > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On = Behalf Of Randy Turner > Sent: Thursday, August 23, 2012 9:55 AM > To: wpkops@ietf.org > Subject: Re: [wpkops] First draft charter proposal >=20 >=20 > Yes, that was my question....they were doing signature-like things, = but I wasn't sure about the size of any deployment....(i.e, "shipping = products") >=20 > R. >=20 >=20 > On Aug 23, 2012, at 2:44 AM, Stephen Farrell = wrote: >=20 >>=20 >> FWIW, I'd be *highly* skeptical that an OPS area WG is needed to=20 >> address anything whatsoever about LTANS. While it might be fine work,=20= >> its just not sufficiently deployed for that to be useful. >>=20 >> S. >>=20 >> On 08/23/2012 05:23 AM, Randy Turner wrote: >>>=20 >>> Yes, I was specifically referring to signing timestamps and/or = content as a part of the LTANS work...I just wasn't sure if there were = products in the marketplace that could be called "LTANS-compliant"=20 >>>=20 >>> R. >>>=20 >>> On Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote: >>>=20 >>>> I do not know what you mean by "shipping" here, but LTANS did work = on long term non repudiation and time stamp resulting Evidence Record = Structure RFC. >>>>=20 >>>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20= >>>> Behalf Of Randy Turner >>>> Sent: Wednesday, August 22, 2012 6:38 PM >>>> To: wpkops@ietf.org >>>> Subject: Re: [wpkops] First draft charter proposal >>>>=20 >>>>=20 >>>> I would agree with the scope that "signing" brings into the = potential work of a WG, but I think there might be a fair amount of = interoperable S/MIME experience as well that could be discussed. >>>>=20 >>>> Code signing is a bit fragmented, although there have been=20 >>>> discussions on using CMS for generating signed code containers, but=20= >>>> vendors largely do what they want (as you mentioned) >>>>=20 >>>> The LTANS working group looked at document archival awhile back, = and=20 >>>> did some work on timestamping, but I'm not aware of any shipping=20 >>>> implementations that standardized their long-term archival=20 >>>> strategies regarding signatures or timestamping (not that there=20 >>>> aren't any, I just don't keep up with this) >>>>=20 >>>> R. >>>>=20 >>>>=20 >>>> On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote: >>>>=20 >>>>=20 >>>> Moudrick Dadashov wrote: >>>>=20 >>>>> Right, but obviously seeking to narrow the scope we need a wider = vision, right? >>>>> Exclusion of "documents etc." has its historical reasons, not = technological. >>>>=20 >>>> I think it does have technological reasons: Document and code = signing has to: >>>>=20 >>>> * Deal with problems of long-lived artifacts - including signed=20 >>>> objects that may outlive the certificates used to sign them >>>> * Work by default without a direct connection to the entity in=20 >>>> control of the certificate >>>> * Support entirely offline verification >>>>=20 >>>> This has also led to different practices about revocation and = blacklisting, use of third party time stamping authorities, etc. The = differences are substantial. >>>>=20 >>>> Code signing in particular is also HIGHLY vendor-specific. I may = be mistaken, but my impression is that it's not meaningful at all to = talk about a single set of practices around code signing that is common = across multiple platforms - Java, Apple App Store, Android Apps, = Microsoft Authenticode, Strong Named Assemblies in .NET, etc.=20 >>>>=20 >>>> Java and Authenticode may have interoperable certificate formats, = but how they are used still differs greatly. Individual vendors remain = in the best position to provide authoritative guidance on their own = implementations.=20 >>>>=20 >>>> Document signing is a bit more interoperable, though still more=20 >>>> fragmented than the Web by regulatory requirements and=20 >>>> jurisdictional boundaries, and often additionally by document=20 >>>> formats. (PDF vs. Word vs. XML) >>>>=20 >>>> I think "the Web" / HTTPS is the only PKI (other than the work PKIX = does/did) with enough actually interoperating implementations that a = body like the IETF is best-positioned to document current and historical = practices. >>>>=20 >>>> -Brad >>>>=20 >>>> From: Moudrick M. Dadashov [mailto:md@ssc.lt] >>>> Sent: Wednesday, August 22, 2012 2:42 PM >>>> To: Hill, Brad >>>> Cc: Tim Moses; 'wpkops@ietf.org' >>>> Subject: Re: [wpkops] First draft charter proposal >>>>=20 >>>> Right, but obviously seeking to narrow the scope we need a wider = vision, right? Exclusion of "documents etc." has its historical reasons, = not technological. Why not to form a generic vision and based on that = try to figure out the scope of interest. >>>>=20 >>>> Thanks, >>>> M.D. >>>>=20 >>>> On 8/23/2012 12:27 AM, Hill, Brad wrote: >>>> I agree with Tim that we should start with a narrow scope focused = on the Web PKI rather than documents, etc., I also think there are = cases that are on the edge - like the programmatic HTTP clients used by = mobile aps, embedded browsing contexts with different PKI error handling = logic than standalone ones, and, towards the more complex end, web = services that use HTTP and the web PKI explicitly but might also use = other transports and trust models. Not clear from the draft charter = where to draw the line among these, but there is plenty of work to do = and that needs doing urgently. >>>>=20 >>>> Brad Hill >>>>=20 >>>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20= >>>> Behalf Of Tim Moses >>>> Sent: Wednesday, August 22, 2012 5:45 AM >>>> To: 'wpkops@ietf.org' >>>> Subject: [wpkops] First draft charter proposal >>>>=20 >>>> Colleagues - Here is a first draft of a charter proposal. Please = give it some thought and share the results of your deliberations. = Thanks a lot. All the best. Tim. >>>>=20 >>>> The Web PKI is the set of systems and procedures most commonly used = to protect the confidentiality, integrity and authenticity of = communications between Web browsers and Web content servers. It 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 hundreds of variations = on the Web PKI in regular use. And this can be a source of problems = both for end-users and certificate issuers. >>>>=20 >>>> For end-users, there is no clear view whether certificate = "problems" remain when they see indication of a "good" connection. For = instance, in some browsers, 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. >>>>=20 >>>> And for 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 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 >>>> 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. >>>>=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 (other than the Web) may use = the same trust anchors as the ones used by the Web. These applications = include: document signing; code signing; and email. They may use PKI in = a way that differs from the way in which the Web uses it. Therefore, = these applications are explicitly out of scope for the working group. >>>>=20 >>>> Also, the reliability of the Web PKI depends critically on the = practices of its certificate issuers. However, the topic of practices = is outside the scope of the IETF. Therefore, this will be left to other = competent bodies. >>>>=20 >>>> That there are technical shortcomings with Web PKI, as it is = practiced today, is well recognized. And, that there is also some = urgency in addressing these shortcomings is also well recognized. 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. >>>>=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. The working group should = focus its initial attention on the browser and server versions that make = up the largest part of the desktop and mobile Web today. >>>>=20 >>>> The output documents will all be BCP-style RFCs. >>>>=20 >>>> 1. Agree the working group charter (1 month). >>>> 2. Catalog the products and versions to be analyzed (1 month). >>>> 3. First WG draft of "trust model" document (4 months). >>>> 4. First WG draft of "public-key submission and certificate = installation" document (4 months). >>>> 5. First WG draft of "certificate, CRL, and OCSP profile" = document (8 months). >>>> 6. First WG draft of "certificate, CRL, and OCSP processing" = document (12 months). >>>> 7. First WG draft of "certificate re-issuance" document (4 = months). >>>> 8. First WG draft of "certificate renewal" document (4 months). >>>> 9. First WG draft of "certificate revocation" document (8 = months). >>>> 10. IESG submission of "trust model" document (16 months). >>>> 11. IESG submission of "public-key submission and certificate = installation" document (16 months). >>>> 12. IESG submission of "certificate, CRL, and OCSP profile" = document (20 months). >>>> 13. IESG submission of "certificate, CRL, and OCSP processing" = document (24 months). >>>> 14. IESG submission of "certificate re-issuance" document (16 = months). >>>> 15. IESG submission of "certificate renewal" document (16 months). >>>> 16. IESG submission of "certificate revocation" document (20 = months) >>>>=20 >>>> The schedule is predicated upon the group's ability to recruit a = sufficient number of editors and engage either the relevant product = experts or other experts willing to test the selected product = configurations. =20 >>>>=20 >>>>=20 >>>> T: +1 613 270 3183 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> wpkops mailing list >>>> wpkops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/wpkops >>>>=20 >>>> _______________________________________________ >>>> wpkops mailing list >>>> wpkops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/wpkops >>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >>>=20 >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >>=20 >=20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 From carl@redhoundsoftware.com Thu Aug 23 07:38:21 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 CFD7C21F846F for ; Thu, 23 Aug 2012 07:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qytlymTFesf for ; Thu, 23 Aug 2012 07:38:20 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E73221F8474 for ; Thu, 23 Aug 2012 07:38:20 -0700 (PDT) Received: by qcac10 with SMTP id c10so591567qca.31 for ; Thu, 23 Aug 2012 07:38:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=DEk4XIJclXtUrFPe/e89I5Qr2vvLEjdlZfBiTuIbDFs=; b=S+YdoyWFS35augptIWOqrT+gvbdbSvrSLg6WZwGDlBuLzfIJJETML8KvVbpaNt/5My VKV0mNMY+nL/uDB5KelnvKjVOwbXk2Y010mYlpBBGCIF07BRz3oZVtvkgYQ1ZNg5pVy4 np/fjMlVdy45mu4gB20BTi0sPqfM9fpersFEaC1z/1Cbt7OqplH7d172NDxfisXVpsbX NUkPxSTw8OiQh6SzhnoHKWgGpZan08GcKj0SEaplUEDV4C62ZZF1WQPMxOTGi4Lc0axz haCY1i1cwOfnx5khvewb6EbZZcIl5WC+5ckm5lqclMljiKv3rKlK/9QFhOqCeUfk+rzT +Yag== Received: by 10.224.26.210 with SMTP id f18mr3071721qac.80.1345732699574; Thu, 23 Aug 2012 07:38:19 -0700 (PDT) Received: from [192.168.1.5] (pool-71-191-137-227.washdc.fios.verizon.net. [71.191.137.227]) by mx.google.com with ESMTPS id l3sm5359895qan.19.2012.08.23.07.38.16 (version=SSLv3 cipher=OTHER); Thu, 23 Aug 2012 07:38:18 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 23 Aug 2012 10:38:11 -0400 From: Carl Wallace To: Tim Moses , "wpkops@ietf.org" Message-ID: Thread-Topic: [wpkops] First draft charter proposal In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A572172@SOTTEXCH10.corp.ad.entrust.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmfV2ZaAXAuP8jU8rVsZryf2YDu+cSR9+QKlVN+vGH4fw1a+ZOmtFUacZLYDTGncyCb7U8L Cc: 'Randy Turner' Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 14:38:21 -0000 One problem with a narrow scope is the mechanisms that support the "Web PKI" also support a lot of the stuff being categorized as out of scope. It's not clear that focusing on site authentication in isolation is correct where the documented mechanisms have a (negative) impact on things like email, mutually authenticated TLS, chat, code signing, etc. It may be fine to limit the primary focus in the charter but take care during the documentation effort to note where mechanisms are reused for purposes beyond site authentication (even if the reuse is not explored to great depth). On 8/23/12 10:22 AM, "Tim Moses" wrote: >I agree with Brad and Stephen. We need to be addressing pressing >practical problems. And (in my mind) site-authentication qualifies. I >understand Stephen's concern about code-signing. But, it seems like >significant extra work. I wonder if it should be left out of the initial >charter. Once we have a better grasp of the type and quantity of >resources that we can draw on, we could consider a re-chartering exercise >to include it. All the best. Tim. > >-----Original Message----- >From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf >Of Randy Turner >Sent: Thursday, August 23, 2012 9:55 AM >To: wpkops@ietf.org >Subject: Re: [wpkops] First draft charter proposal > > >Yes, that was my question....they were doing signature-like things, but I >wasn't sure about the size of any deployment....(i.e, "shipping products") > >R. > > >On Aug 23, 2012, at 2:44 AM, Stephen Farrell >wrote: > >> >> FWIW, I'd be *highly* skeptical that an OPS area WG is needed to >> address anything whatsoever about LTANS. While it might be fine work, >> its just not sufficiently deployed for that to be useful. >> >> S. >> >> On 08/23/2012 05:23 AM, Randy Turner wrote: >>> >>> Yes, I was specifically referring to signing timestamps and/or content >>>as a part of the LTANS work...I just wasn't sure if there were products >>>in the marketplace that could be called "LTANS-compliant" >>> >>> R. >>> >>> On Aug 22, 2012, at 7:05 PM, Santosh Chokhani wrote: >>> >>>> I do not know what you mean by "shipping" here, but LTANS did work on >>>>long term non repudiation and time stamp resulting Evidence Record >>>>Structure RFC. >>>> >>>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On >>>> Behalf Of Randy Turner >>>> Sent: Wednesday, August 22, 2012 6:38 PM >>>> To: wpkops@ietf.org >>>> Subject: Re: [wpkops] First draft charter proposal >>>> >>>> >>>> I would agree with the scope that "signing" brings into the potential >>>>work of a WG, but I think there might be a fair amount of >>>>interoperable S/MIME experience as well that could be discussed. >>>> >>>> Code signing is a bit fragmented, although there have been >>>> discussions on using CMS for generating signed code containers, but >>>> vendors largely do what they want (as you mentioned) >>>> >>>> The LTANS working group looked at document archival awhile back, and >>>> did some work on timestamping, but I'm not aware of any shipping >>>> implementations that standardized their long-term archival >>>> strategies regarding signatures or timestamping (not that there >>>> aren't any, I just don't keep up with this) >>>> >>>> R. >>>> >>>> >>>> On Aug 22, 2012, at 3:29 PM, Hill, Brad wrote: >>>> >>>> >>>> Moudrick Dadashov wrote: >>>> >>>>> Right, but obviously seeking to narrow the scope we need a wider >>>>>vision, right? >>>>> Exclusion of "documents etc." has its historical reasons, not >>>>>technological. >>>> >>>> I think it does have technological reasons: Document and code >>>>signing has to: >>>> >>>> * Deal with problems of long-lived artifacts - including signed >>>> objects that may outlive the certificates used to sign them >>>> * Work by default without a direct connection to the entity in >>>> control of the certificate >>>> * Support entirely offline verification >>>> >>>> This has also led to different practices about revocation and >>>>blacklisting, use of third party time stamping authorities, etc. The >>>>differences are substantial. >>>> >>>> Code signing in particular is also HIGHLY vendor-specific. I may be >>>>mistaken, but my impression is that it's not meaningful at all to talk >>>>about a single set of practices around code signing that is common >>>>across multiple platforms - Java, Apple App Store, Android Apps, >>>>Microsoft Authenticode, Strong Named Assemblies in .NET, etc. >>>> >>>> Java and Authenticode may have interoperable certificate formats, but >>>>how they are used still differs greatly. Individual vendors remain in >>>>the best position to provide authoritative guidance on their own >>>>implementations. >>>> >>>> Document signing is a bit more interoperable, though still more >>>> fragmented than the Web by regulatory requirements and >>>> jurisdictional boundaries, and often additionally by document >>>> formats. (PDF vs. Word vs. XML) >>>> >>>> I think "the Web" / HTTPS is the only PKI (other than the work PKIX >>>>does/did) with enough actually interoperating implementations that a >>>>body like the IETF is best-positioned to document current and >>>>historical practices. >>>> >>>> -Brad >>>> >>>> From: Moudrick M. Dadashov [mailto:md@ssc.lt] >>>> Sent: Wednesday, August 22, 2012 2:42 PM >>>> To: Hill, Brad >>>> Cc: Tim Moses; 'wpkops@ietf.org' >>>> Subject: Re: [wpkops] First draft charter proposal >>>> >>>> Right, but obviously seeking to narrow the scope we need a wider >>>>vision, right? Exclusion of "documents etc." has its historical >>>>reasons, not technological. Why not to form a generic vision and based >>>>on that try to figure out the scope of interest. >>>> >>>> Thanks, >>>> M.D. >>>> >>>> On 8/23/2012 12:27 AM, Hill, Brad wrote: >>>> I agree with Tim that we should start with a narrow scope focused on >>>>the Web PKI rather than documents, etc., I also think there are cases >>>>that are on the edge - like the programmatic HTTP clients used by >>>>mobile aps, embedded browsing contexts with different PKI error >>>>handling logic than standalone ones, and, towards the more complex >>>>end, web services that use HTTP and the web PKI explicitly but might >>>>also use other transports and trust models. Not clear from the draft >>>>charter where to draw the line among these, but there is plenty of >>>>work to do and that needs doing urgently. >>>> >>>> Brad Hill >>>> >>>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On >>>> Behalf Of Tim Moses >>>> Sent: Wednesday, August 22, 2012 5:45 AM >>>> To: 'wpkops@ietf.org' >>>> Subject: [wpkops] First draft charter proposal >>>> >>>> Colleagues - Here is a first draft of a charter proposal. Please >>>>give it some thought and share the results of your deliberations. >>>>Thanks a lot. All the best. Tim. >>>> >>>> The Web PKI is the set of systems and procedures most commonly used >>>>to protect the confidentiality, integrity and authenticity of >>>>communications between Web browsers and Web content servers. It 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 hundreds of variations >>>>on the Web PKI in regular use. And this can be a source of problems >>>>both for end-users and certificate issuers. >>>> >>>> For end-users, there is no clear view whether certificate "problems" >>>>remain when they see indication of a "good" connection. For instance, >>>>in some browsers, 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. >>>> >>>> And for 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 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. >>>> >>>> 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 (other than the Web) may use >>>>the same trust anchors as the ones used by the Web. These >>>>applications include: document signing; code signing; and email. They >>>>may use PKI in a way that differs from the way in which the Web uses >>>>it. Therefore, these applications are explicitly out of scope for the >>>>working group. >>>> >>>> Also, the reliability of the Web PKI depends critically on the >>>>practices of its certificate issuers. However, the topic of practices >>>>is outside the scope of the IETF. Therefore, this will be left to >>>>other competent bodies. >>>> >>>> That there are technical shortcomings with Web PKI, as it is >>>>practiced today, is well recognized. And, that there is also some >>>>urgency in addressing these shortcomings is also well recognized. >>>>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, it is agreed that adherence to the published schedule should >>>>take precedence over completeness of the results. The working group >>>>should focus its initial attention on the browser and server versions >>>>that make up the largest part of the desktop and mobile Web today. >>>> >>>> The output documents will all be BCP-style RFCs. >>>> >>>> 1. Agree the working group charter (1 month). >>>> 2. Catalog the products and versions to be analyzed (1 month). >>>> 3. First WG draft of "trust model" document (4 months). >>>> 4. First WG draft of "public-key submission and certificate >>>>installation" document (4 months). >>>> 5. First WG draft of "certificate, CRL, and OCSP profile" document >>>>(8 months). >>>> 6. First WG draft of "certificate, CRL, and OCSP processing" >>>>document (12 months). >>>> 7. First WG draft of "certificate re-issuance" document (4 months). >>>> 8. First WG draft of "certificate renewal" document (4 months). >>>> 9. First WG draft of "certificate revocation" document (8 months). >>>> 10. IESG submission of "trust model" document (16 months). >>>> 11. IESG submission of "public-key submission and certificate >>>>installation" document (16 months). >>>> 12. IESG submission of "certificate, CRL, and OCSP profile" document >>>>(20 months). >>>> 13. IESG submission of "certificate, CRL, and OCSP processing" >>>>document (24 months). >>>> 14. IESG submission of "certificate re-issuance" document (16 months). >>>> 15. IESG submission of "certificate renewal" document (16 months). >>>> 16. IESG submission of "certificate revocation" document (20 months) >>>> >>>> The schedule is predicated upon the group's ability to recruit a >>>>sufficient number of editors and engage either the relevant product >>>>experts or other experts willing to test the selected product >>>>configurations. >>>> >>>> >>>> T: +1 613 270 3183 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> wpkops mailing list >>>> wpkops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/wpkops >>>> >>>> _______________________________________________ >>>> wpkops mailing list >>>> wpkops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/wpkops >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >>> >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> > >_______________________________________________ >wpkops mailing list >wpkops@ietf.org >https://www.ietf.org/mailman/listinfo/wpkops >_______________________________________________ >wpkops mailing list >wpkops@ietf.org >https://www.ietf.org/mailman/listinfo/wpkops From hallam@gmail.com Thu Aug 23 07:52:05 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 39B0F21F8608 for ; Thu, 23 Aug 2012 07:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[AWL=-1.908, 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 EJtIybZPf0qW for ; Thu, 23 Aug 2012 07:52:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 539D521F84F3 for ; Thu, 23 Aug 2012 07:52:04 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2084199obb.31 for ; Thu, 23 Aug 2012 07:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8oO8jbRCTfKvUyXrUvu53dFjONtIqe5lVYz+wNjvYDA=; b=u2vm7EZtNbGzxUFiqknXQItr363B7ChDyaZI3xhXAdFHnwHJeHTnLIMRJ/PiX+V7qO GXZc6BNsDg9jogRMaWjMh2jGYsobStscuxkxbrK2gZj6fxYBxsdxlxbDb5pf9tipe90y f/x0QThLln9OsQzi2g0pMFonpAFl4aMr7y0xRDXdRvHfvH4nu5W+s7TIV35TTEV2Vpux KMkgBlob6kQc3ShtC8/e1/fW5oxlnNwKkXSxjEbaZjARf0+6gTt5SYqqKjhF5vHWmNQ+ PeCh+puRcrqWhPRHszO4jSmgTEVQAVUZp8FLv0rA3rpFBgLb+RcnhTzazupUsPfcnZCX cxUw== MIME-Version: 1.0 Received: by 10.182.117.71 with SMTP id kc7mr1257778obb.62.1345733523926; Thu, 23 Aug 2012 07:52:03 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Thu, 23 Aug 2012 07:52:03 -0700 (PDT) In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A572172@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <820E52D9-E695-4779-BE1E-A8EC8C841ACB@amalfisystems.com> <27E55FD0-C7F2-4C8B-9E1F-48AB2057D2C4@amalfisystems.com> <5035FB71.6040707@cs.tcd.ie> <0B1B8AB7-9732-433D-9008-95519DEC1B1C@amalfisystems.com> <5B68A271B9C97046963CB6A5B8D6F62C3A572172@SOTTEXCH10.corp.ad.entrust.com> Date: Thu, 23 Aug 2012 10:52:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Tim Moses Content-Type: text/plain; charset=ISO-8859-1 Cc: Randy Turner , "wpkops@ietf.org" Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 14:52:05 -0000 I think that what is needed most of all in Web PKI space right now is to arrive at a statement of what applications and servers should expect so they can be designed to work with the PKI that exists rather than the infinite set of possibilities that are consistent with PKIX but not deployed. At the moment we have a system that depends a great deal on 'lore' which is only understood by a handful of people and is mostly arrived at by trial and error: * Server Lore: The PKI/SSL features that the servers actually support * Client Lore: The PKI/SSL features that the clients actually implement * CA Lore: How certs rollover, PKI topology A lot of the lore results from different people trying to 'do the right thing' in different ways. Some of it results from one side trying to do the right thing but not being supported by another. Quite a bit of the lore results from the common misconception that the primary purpose of the Web PKI is to encrypt stuff rather than to assure people that they are talking to the right party and that that party is accountable in some fashion. Standards that rely on Lore are not really standards in my view. On the code signing thing, I agree that running the right code is probably the most important security concern right now. There is nothing Chrome can do to improve security if the Chrome executable has been compromised. Anti-Virus vendors such as Comodo have been moving away from traditional AV approaches of looking for badness to a default-deny approach. We only run the code we know is trustworthy rather than only nerfing the code known to be bad. Code signing could be an important part of that approach but it is actually pretty difficult right now as every code signing scheme is different and while most are open, some are closed (e.g. iOS). Most of the schemes out there depend on some form of X.509 PKI and some form of digital signature. Some only authenticate the installation package, others have signatures on the running .exe and .obj files, some have manifests. It would be nice if there was some form of registry that actually catalogued all this variation and that might lead to some future project to come up with a single scheme that could be applied to all code. There is really no good reason for the Java code signing scheme to be completely different from the .Net scheme and require a completely different validation strategy. From stpeter@stpeter.im Thu Aug 23 08:33: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 DE21021F8577 for ; Thu, 23 Aug 2012 08:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 cSKxVvU3dWo0 for ; Thu, 23 Aug 2012 08:33:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABB621F855E for ; Thu, 23 Aug 2012 08:33:38 -0700 (PDT) Received: from [64.101.72.60] (unknown [64.101.72.60]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 667CB405EF; Thu, 23 Aug 2012 09:34:30 -0600 (MDT) Message-ID: <50364542.3070306@stpeter.im> Date: Thu, 23 Aug 2012 08:59:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Hill, Brad" References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1F21A6@DEN-EXDDA-S11.corp.ebay.com> <50355235.5030003@ssc.lt> <370C9BEB4DD6154FA963E2F79ADC6F2E1F233D@DEN-EXDDA-S11.corp.ebay.com> <503581B4.9070702@stpeter.im> <370C9BEB4DD6154FA963E2F79ADC6F2E1F3630@DEN-EXDDA-S11.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E1F3630@DEN-EXDDA-S11.corp.ebay.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Moudrick M. Dadashov" , "'wpkops@ietf.org'" , Tim Moses Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 15:33:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/22/12 10:23 PM, Hill, Brad wrote: >> Brad, do you include the use of PKIX certificates in application >> technologies like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog, >> and XMPP as part of or derivative from "the Web PKI"? The >> proposed charter seems tightly focused on browsers and HTTPS, but >> (as documented in RFC 6125) there's plenty of implementation and >> deployment of PKIX certificates outside that space. > > Good questions. They are closer cousins than the offline use > cases. My follow up questions would be: > > a) Is there the same perceived need to document the "state of > interop" for these uses of PKIX as there is for HTTPS? I think there is for some of those technologies. In any case, admins who are requesting certificates for email or IM servers interact with the very same CAs as admins who are requesting certificates for web servers. I'd hate to see misalignment creep in because we're deliberately excluded everything but the web. > b) Are the right experts and stakeholders here Well, "here" was just created, and created with "web" in the name. Turning it around, have the folks who are initiating this effort reached out to any other application communities? > and interested in tackling any/some/all of these as part of this > proposed WG? I'm here (heavily involved in XMPP) and given that I co-authored RFC 6125 I'm pretty interested in the general topic. > c) Will those people commit to edit and contribute to the relevant > deliverables? No idea, since they're not here yet. > d) Does that work depend on or build directly from the HTTPS work, > or are there other WGs where it can be undertaken on its own > timeline and where the "right people" are already assembled? I think some of the work for other application technologies is parallel to the HTTPS work, and some of it is downstream. We'll need to get down to cases and see exactly what work applies more generally and what work is specific to particular technologies. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA2RUIACgkQNL8k5A2w/vx2KQCg460hWsvw/hkVx2hGD/SrfnVU ebcAn0rrbwErOIBkmaYoTOKHqOSnXMrP =U+iW -----END PGP SIGNATURE----- From agl@google.com Thu Aug 23 09:23: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 BB2E521F8487 for ; Thu, 23 Aug 2012 09:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.868 X-Spam-Level: X-Spam-Status: No, score=-101.868 tagged_above=-999 required=5 tests=[AWL=1.109, 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 pn9SZA29fa3W for ; Thu, 23 Aug 2012 09:23:01 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12F6521F847C for ; Thu, 23 Aug 2012 09:23:00 -0700 (PDT) Received: by iabz21 with SMTP id z21so1760407iab.31 for ; Thu, 23 Aug 2012 09:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record; bh=7MwjaeL7HokxnR7jxzQ7UwECOjpAiGFkul+86d4pWvI=; b=dWWX9CpI+sJoi1bmcRhiSrLGXqp1c0iSFEA1vC+gfyfIPIZq5hgDn3U61ajmrgWisJ kyV0qaxPHzTTCV+S7fbreEtyrmzQRNeHyiIBFcd69u/8QUcwKxgUED6+TS+tQG2rDUEN /lwNMZs28iCVnV37O+emkYM089dYFfVtytlSkGiwSgscEQF+iaHvvWs5WY4o4YtCZY27 Sy2PUeLy424v8Oe35o2f1ds1fvO+CD2ccpcEoDjTFbtN4Cy0OcC7zyCZ7pgT8Uhb3IK6 S5IEB5cJ6xeRU5DCxGhjGn4x2ARtwlRgsZpgyKUVCGvVVC/qlLKpMUcwT5BtY6KoWGHQ oNkQ== 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 :content-transfer-encoding:x-system-of-record:x-gm-message-state; bh=7MwjaeL7HokxnR7jxzQ7UwECOjpAiGFkul+86d4pWvI=; b=oyBo+tW6QDAF4hSqLhDv1vJ2qRqZofQxQPlLtDAucsQ/K9KKKuy7xxZxfMTzai0T7L xLkuOLI6p+6xVAvJEFH5/AGynpoR85m9HX3IPb2wUoExi2jkNUEXjFabrc6cND+N0mi2 GshH/TVKsINXv3L3aubr6hw9DBI1Ssk2QDI31HBqw7m9bY4DUPtoQAEjNr4Xx9C1PuJu DOh6nxNUDJNzpbkAjoBrnhTfpR/0+9xWZmcDzrW4+4nNYD7XcA0AGjxZ4cK2EZgFEJSW BVSysV7q9yKutUuG1ctmEmOv82o3xgJh7iwYf/l2bfMz13EwQrPKGXnvHcnW+OBquL3m VZFQ== Received: by 10.50.219.138 with SMTP id po10mr2205944igc.52.1345738980616; Thu, 23 Aug 2012 09:23:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.219.138 with SMTP id po10mr2205934igc.52.1345738980443; Thu, 23 Aug 2012 09:23:00 -0700 (PDT) Sender: agl@google.com Received: by 10.231.224.84 with HTTP; Thu, 23 Aug 2012 09:23:00 -0700 (PDT) In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> Date: Thu, 23 Aug 2012 12:23:00 -0400 X-Google-Sender-Auth: hIQlV3XD8W8yg2Um4OcllUo5PNE Message-ID: From: Adam Langley To: Tim Moses Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnHYzx9Yx9+idoCOmgSvLgepbdbcHUvEp8cqw+ORZWSuGElzgzX/lwYrychaDY2Ql9H0XIqGsSvk5DBSzLdUs2395v/dVfhwrVy/GhpDbqve2eucYwIXiZAq6vYQDQUqMTXoM11XcMa3okKKkM+O8IBxdwfynOKpk4PZ4UZPskpM2QixzkxQSbHPOOfvttD2LJEA4Wh Cc: "wpkops@ietf.org" Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 16:23:01 -0000 On Wed, Aug 22, 2012 at 8:44 AM, Tim Moses wrote: > Colleagues =E2=80=93 Here is a first draft of a charter proposal. Please= give it > some thought and share the results of your deliberations. Thanks a lot. > All the best. Tim. Do you envision that the WG focuses solely on certificates? I would be keen, at some point, in documenting the arcane knowledge needed to write a browser TLS stack (i.e. something like http://www.ietf.org/mail-archive/web/tls/current/msg07281.html). I'd be happy to do it in the scope of this WG if that scope includes it. Cheers AGL From tim.moses@entrust.com Thu Aug 23 10:34:55 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 F302321F8619 for ; Thu, 23 Aug 2012 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 jE8bbU9A1ITz for ; Thu, 23 Aug 2012 10:34:54 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9B221F8609 for ; Thu, 23 Aug 2012 10:34:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,301,1344225600"; d="scan'208";a="5996015" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 23 Aug 2012 13:34:53 -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.001; Thu, 23 Aug 2012 13:34:53 -0400 From: Tim Moses To: 'Adam Langley' Thread-Topic: [wpkops] First draft charter proposal Thread-Index: AQHNgUuPhcHsamCRREOXQyLd0a8eMZdnpz7g Date: Thu, 23 Aug 2012 17:34:52 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A57294F@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 17:34:55 -0000 SGkgQWRhbS4gIFBlcnNvbmFsbHksIEkgd291bGQgbGlrZSB0byBzZWUgdGhpcyBzb3J0IG9mIG1h dGVyaWFsIGluY2x1ZGVkLiAgSXQgaXMgYWxsIGVpdGhlciBkaXJlY3RseSBvciBjbG9zZWx5IHJl bGF0ZWQgdG8gdGhlIHdvcmtpbmdzIG9mIHRoZSBQS0kuICBBbmQsIGFzIGxvbmcgYXMgd2UgaGF2 ZSBhIHZvbHVudGVlciwgd2h5IHdvdWxkIHdlIHJlZnVzZSB0aGUgb2ZmZXI/ICBBbGwgdGhlIGJl c3QuICBUaW0uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhZ2xAZ29vZ2xl LmNvbSBbbWFpbHRvOmFnbEBnb29nbGUuY29tXSBPbiBCZWhhbGYgT2YgQWRhbSBMYW5nbGV5DQpT ZW50OiBUaHVyc2RheSwgQXVndXN0IDIzLCAyMDEyIDEyOjIzIFBNDQpUbzogVGltIE1vc2VzDQpD Yzogd3Brb3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3dwa29wc10gRmlyc3QgZHJhZnQgY2hh cnRlciBwcm9wb3NhbA0KDQpPbiBXZWQsIEF1ZyAyMiwgMjAxMiBhdCA4OjQ0IEFNLCBUaW0gTW9z ZXMgPHRpbS5tb3Nlc0BlbnRydXN0LmNvbT4gd3JvdGU6DQo+IENvbGxlYWd1ZXMg4oCTIEhlcmUg aXMgYSBmaXJzdCBkcmFmdCBvZiBhIGNoYXJ0ZXIgcHJvcG9zYWwuICBQbGVhc2UgZ2l2ZSANCj4g aXQgc29tZSB0aG91Z2h0IGFuZCBzaGFyZSB0aGUgcmVzdWx0cyBvZiB5b3VyIGRlbGliZXJhdGlv bnMuICBUaGFua3MgYSBsb3QuDQo+IEFsbCB0aGUgYmVzdC4gIFRpbS4NCg0KRG8geW91IGVudmlz aW9uIHRoYXQgdGhlIFdHIGZvY3VzZXMgc29sZWx5IG9uIGNlcnRpZmljYXRlcz8gSSB3b3VsZCBi ZSBrZWVuLCBhdCBzb21lIHBvaW50LCBpbiBkb2N1bWVudGluZyB0aGUgYXJjYW5lIGtub3dsZWRn ZSBuZWVkZWQgdG8gd3JpdGUgYSBicm93c2VyIFRMUyBzdGFjayAoaS5lLiBzb21ldGhpbmcgbGlr ZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdGxzL2N1cnJlbnQvbXNnMDcy ODEuaHRtbCkuDQoNCkknZCBiZSBoYXBweSB0byBkbyBpdCBpbiB0aGUgc2NvcGUgb2YgdGhpcyBX RyBpZiB0aGF0IHNjb3BlIGluY2x1ZGVzIGl0Lg0KDQoNCkNoZWVycw0KDQpBR0wNCg== From hallam@gmail.com Thu Aug 23 11:04: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 9729721F863C for ; Thu, 23 Aug 2012 11:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.495 X-Spam-Level: X-Spam-Status: No, score=-5.495 tagged_above=-999 required=5 tests=[AWL=-1.896, 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 KDezA0xPOMIU for ; Thu, 23 Aug 2012 11:04:45 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81CF321F861F for ; Thu, 23 Aug 2012 11:04:45 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2729619obb.31 for ; Thu, 23 Aug 2012 11:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v0xSCiCKKo6lHLTfvWXJD2ge4Zb92JcADIFQ9Qs/r2s=; b=apk2aso+hr+qsF10qhz1qU4WhwctvJJjSoRy+2oHQR4vurkCJAcSpnOHTf2RwH/V9a yY6EGfjx5tybbcgKXEGt5KsKsRvJfI9+S9r6XWwUDEfOjDqgUWVwOnGF7JM/9hdQQ9ud XSRvMBlW2Au9wObOM805fQSgkDBOvk8IyoO4b3TVg1b8fywfm/VAgpUPkfXcLDTcDoqj CiY9Lq/5oQgeUgbfvpn61+ZSef2e8CcBI2GeLNjgATSwlFnWg8EAqHNZLrws398QPmZ+ Vvdd68n9lw9usk3OhV6yZUo0Wm39vocUxr2cDb4rwunwJkWditjoLo5P+g29WQwc+hIA vWbQ== MIME-Version: 1.0 Received: by 10.182.75.33 with SMTP id z1mr1852511obv.9.1345745085122; Thu, 23 Aug 2012 11:04:45 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Thu, 23 Aug 2012 11:04:45 -0700 (PDT) In-Reply-To: References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> Date: Thu, 23 Aug 2012 14:04:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Adam Langley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "wpkops@ietf.org" , Tim Moses Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 18:04:46 -0000 It occurs to me that rather than looking for participation from the server providers, what we really need is the maintainer of the SSL library they all use. On Thu, Aug 23, 2012 at 12:23 PM, Adam Langley wrote: > On Wed, Aug 22, 2012 at 8:44 AM, Tim Moses wrote: >> Colleagues =96 Here is a first draft of a charter proposal. Please give= it >> some thought and share the results of your deliberations. Thanks a lot. >> All the best. Tim. > > Do you envision that the WG focuses solely on certificates? I would be > keen, at some point, in documenting the arcane knowledge needed to > write a browser TLS stack (i.e. something like > http://www.ietf.org/mail-archive/web/tls/current/msg07281.html). > > I'd be happy to do it in the scope of this WG if that scope includes it. > > > Cheers > > AGL > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops --=20 Website: http://hallambaker.com/ From jeff.hodges@paypal-inc.com Thu Aug 23 12:28: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 E2CD621F8643 for ; Thu, 23 Aug 2012 12:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 j0NxzkG4kxvP for ; Thu, 23 Aug 2012 12:28:35 -0700 (PDT) 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 CF87821F8665 for ; Thu, 23 Aug 2012 12:28:34 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:was:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:x-ems-proccessed: x-ems-stamp:Content-Type:Content-Transfer-Encoding: MIME-Version:X-CFilter; b=jH49Pz7jUBS+aeDBpudVi8VGaYWXI68L4naFRE39h1QiOddURo3YPQL3 aHkjHlAjMRFyA7bcVe2LjLAMul5IDYcLdlpb8M9z/RnEXr2MprZs9SaoW zGCykiIiAqqsH6B; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=jeff.hodges@paypal-inc.com; q=dns/txt; s=ppinc; t=1345750115; x=1377286115; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=39cQMlIBvsH+fSneru2m1X8fcirM2B4MJsVUuiqhFSc=; b=r+VfBDC9FWCc0bOwfUp2rAkZDK7yugBunqolGhdXMkC61f94DjgNbwRY EpW+xZ4cWmSahZ+OCvVJhrhENgPTAATb3tYT3aVI06QhDyMxC2xmkmWxZ i4jLF6h5TXc0eWc; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,301,1344236400"; d="scan'208";a="9332765" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-006.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 23 Aug 2012 12:28:34 -0700 Received: from DEN-EXDDA-S11.corp.ebay.com ([fe80::74c6:c884:c352:716]) by DEN-EXMHT-006.corp.ebay.com ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 13:28:32 -0600 From: "Hodges, Jeff" To: Peter Saint-Andre , "Hill, Brad" Thread-Topic: [wpkops] scope of addressed app technologies (was: First draft charter proposal) Thread-Index: AQHNgV7giHsL8JwI3UeljqjwF4/Xng== Date: Thu, 23 Aug 2012 19:28:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.243] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: 0mw9dpFTdGKMq0Qt2r7g4Q== 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] scope of addressed app technologies (was: First draft charter proposal) 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, 23 Aug 2012 19:28:36 -0000 Peter SA replied: > On 8/22/12 10:23 PM, Hill, Brad wrote: >>> Brad, do you include the use of PKIX certificates in application=20 >>> technologies like IMAP, LDAP, NETCONF, SIP, SMTP, SNMP, Syslog, >>> and XMPP as part of or derivative from "the Web PKI"? The >>> proposed charter seems tightly focused on browsers and HTTPS, but >>> (as documented in RFC 6125) there's plenty of implementation and=20 >>> deployment of PKIX certificates outside that space. >>=20 >> Good questions. They are closer cousins than the offline use >> cases. My follow up questions would be: >>=20 >> a) Is there the same perceived need to document the "state of=20 >> interop" for these uses of PKIX as there is for HTTPS? >=20 > I think there is for some of those technologies. In any case, admins > who are requesting certificates for email or IM servers interact with > the very same CAs as admins who are requesting certificates for web > servers. I'd hate to see misalignment creep in because we're > deliberately excluded everything but the web. This begs the question of what we mean by "the web" in this discussion, and= I've been=20 supposing that it essentially means "https".=20 I think Peter has a good point here, speaking as the other co-author on RFC= 6125,=20 wherein we were compelled to address matching of presented identifiers (in = certs)=20 on behalf of various protocols (basically the list of protocols he mentions= above). However, RFC6125 is also an example of both a data-gathering descriptive do= cument,=20 as well as a subsequent prescriptive one. This turned out to be do-able (b= ut=20 still a ton of work) because IMV we were concentrating on just one narrow p= iece=20 of the PKI puzzle.=20 =20 Given that the present proposal is to be first descriptive, and then to see= whether prescriptive work is warranted, I don't think there's much risk of misalign= ment in the nearer term. =20 >> >> d) Does that work depend on or build directly from the HTTPS work, >> or are there other WGs where it can be undertaken on its own >> timeline and where the "right people" are already assembled? >=20 > I think some of the work for other application technologies is > parallel to the HTTPS work, and some of it is downstream. We'll need > to get down to cases and see exactly what work applies more generally > and what work is specific to particular technologies. Given that just doing this work for HTTPS will be tough, I'm for keeping th= e charter=20 narrowly focused on HTTPS PKI for now, coming up with some initial drafts, = and then=20 as they firm up, shopping them around to the other app technology communiti= es (aka=20 working groups) to see if they have interest in doing the same for their ar= eas of interest,=20 and then consider re-chartering.=20 Another way to approach this if i understand correctly is to write somethin= g like the=20 above paragraph into the charter and charter schedule in order to avoid the= re-chartering step.=20 HTH,=20 =3DJeffH From jeff.hodges@paypal-inc.com Thu Aug 23 12:34: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 34EAB21F86C1 for ; Thu, 23 Aug 2012 12:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 Q81-l7sMqJBm for ; Thu, 23 Aug 2012 12:34:00 -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 52B3721F8683 for ; Thu, 23 Aug 2012 12:34:00 -0700 (PDT) DomainKey-Signature: s=ppinc; 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:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=qK5tOmSPeB4g4YShOp3H5RBtEvC+eK1afGnT2J5kiAUNBRtxmtyR2Bt6 KAsxI7a1Vda8FZN0GZKKLqFHNyvZYPWx+RL3raLfWZEj7oX7UPg7zUpTI Nu1I2y1zDhnB/H1; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=jeff.hodges@paypal-inc.com; q=dns/txt; s=ppinc; t=1345750440; x=1377286440; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TSPbJo32voQs+adhcvmUeHvuOj1+HtJnFQLrZZjeA68=; b=aLSwtgRqFpeZNRR7jkYWFbqtUPTj31q6uU2G7iBQJXtrnvKkF73+t/Sa 4mh1Xz6B7UWreWo/kSGCr6b4+7JI+qcLLNoecwXwVRulj69w2sjWNt2g3 M4a/Lo08ih10T9T; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,301,1344236400"; d="scan'208";a="9818544" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-005.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 23 Aug 2012 12:33:59 -0700 Received: from DEN-EXDDA-S11.corp.ebay.com ([fe80::74c6:c884:c352:716]) by DEN-EXMHT-005.corp.ebay.com ([fe80::8109:2a37:17ad:e57e%18]) with mapi id 14.02.0298.004; Thu, 23 Aug 2012 13:33:58 -0600 From: "Hodges, Jeff" To: Tim Moses , 'Adam Langley' Thread-Topic: [wpkops] First draft charter proposal Thread-Index: Ac2AY+7RhcHsamCRREOXQyLd0a8eMQBGeuoAAAKCigD//7wDfQ== Date: Thu, 23 Aug 2012 19:33:57 +0000 Message-ID: References: <5B68A271B9C97046963CB6A5B8D6F62C3A56FDE5@SOTTEXCH10.corp.ad.entrust.com> , <5B68A271B9C97046963CB6A5B8D6F62C3A57294F@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A57294F@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] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: OXDRkhjJ3nozlm7Qk0opuw== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "wpkops@ietf.org" Subject: Re: [wpkops] First draft charter proposal 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, 23 Aug 2012 19:34:01 -0000 +1 you going to publish draft-agl-tls-oppractices-00 in the I-D repository? =20 ________________________________________ From: wpkops-bounces@ietf.org [wpkops-bounces@ietf.org] on behalf of Tim Mo= ses [tim.moses@entrust.com] Sent: Thursday, August 23, 2012 10:34 AM To: 'Adam Langley' Cc: wpkops@ietf.org Subject: Re: [wpkops] First draft charter proposal Hi Adam. Personally, I would like to see this sort of material included. = It is all either directly or closely related to the workings of the PKI. A= nd, as long as we have a volunteer, why would we refuse the offer? All the= best. Tim. -----Original Message----- From: agl@google.com [mailto:agl@google.com] On Behalf Of Adam Langley Sent: Thursday, August 23, 2012 12:23 PM To: Tim Moses Cc: wpkops@ietf.org Subject: Re: [wpkops] First draft charter proposal On Wed, Aug 22, 2012 at 8:44 AM, Tim Moses wrote: > Colleagues =96 Here is a first draft of a charter proposal. Please give > it some thought and share the results of your deliberations. Thanks a lo= t. > All the best. Tim. Do you envision that the WG focuses solely on certificates? I would be keen= , at some point, in documenting the arcane knowledge needed to write a brow= ser TLS stack (i.e. something like http://www.ietf.org/mail-archive/web/tls= /current/msg07281.html). I'd be happy to do it in the scope of this WG if that scope includes it. Cheers AGL _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops= From stpeter@stpeter.im Thu Aug 23 12:59:21 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 D9F1921F8634 for ; Thu, 23 Aug 2012 12:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 gJgctbUhjYnX for ; Thu, 23 Aug 2012 12:59:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 017B421F8619 for ; Thu, 23 Aug 2012 12:59:18 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 03DEE404EA; Thu, 23 Aug 2012 14:00:11 -0600 (MDT) Message-ID: <50368B95.1090209@stpeter.im> Date: Thu, 23 Aug 2012 13:59:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Hodges, Jeff" References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "'wpkops@ietf.org'" , "Hill, Brad" Subject: Re: [wpkops] scope of addressed app technologies (was: First draft charter proposal) 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, 23 Aug 2012 19:59:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/23/12 1:28 PM, Hodges, Jeff wrote: > Peter SA replied: >> On 8/22/12 10:23 PM, Hill, Brad wrote: >>>> Brad, do you include the use of PKIX certificates in >>>> application technologies like IMAP, LDAP, NETCONF, SIP, SMTP, >>>> SNMP, Syslog, and XMPP as part of or derivative from "the Web >>>> PKI"? The proposed charter seems tightly focused on browsers >>>> and HTTPS, but (as documented in RFC 6125) there's plenty of >>>> implementation and deployment of PKIX certificates outside >>>> that space. >>> >>> Good questions. They are closer cousins than the offline use >>> cases. My follow up questions would be: >>> >>> a) Is there the same perceived need to document the "state of >>> interop" for these uses of PKIX as there is for HTTPS? >> >> I think there is for some of those technologies. In any case, >> admins who are requesting certificates for email or IM servers >> interact with the very same CAs as admins who are requesting >> certificates for web servers. I'd hate to see misalignment creep >> in because we're deliberately excluded everything but the web. > > This begs the question of what we mean by "the web" in this > discussion, and I've been supposing that it essentially means > "https". > > I think Peter has a good point here, speaking as the other > co-author on RFC6125, wherein we were compelled to address matching > of presented identifiers (in certs) on behalf of various protocols > (basically the list of protocols he mentions above). > > However, RFC6125 is also an example of both a data-gathering > descriptive document, as well as a subsequent prescriptive one. > This turned out to be do-able (but still a ton of work) because IMV > we were concentrating on just one narrow piece of the PKI puzzle. > > Given that the present proposal is to be first descriptive, and > then to see whether prescriptive work is warranted, I don't think > there's much risk of misalignment in the nearer term. Jeff, I think that makes sense. > >>> >>> d) Does that work depend on or build directly from the HTTPS >>> work, or are there other WGs where it can be undertaken on its >>> own timeline and where the "right people" are already >>> assembled? >> >> I think some of the work for other application technologies is >> parallel to the HTTPS work, and some of it is downstream. We'll >> need to get down to cases and see exactly what work applies more >> generally and what work is specific to particular technologies. > > Given that just doing this work for HTTPS will be tough, True. You saw how long it took us to produce RFC 6125... > I'm for keeping the charter narrowly focused on HTTPS PKI for now, > coming up with some initial drafts, and then as they firm up, > shopping them around to the other app technology communities (aka > working groups) to see if they have interest in doing the same for > their areas of interest, and then consider re-chartering. Perchance. I somewhat doubt that every community will have the energy to work on dedicated documents of a descriptive nature (and some of those communities no longer have WGs at the IETF), but I do think that if someone writes a more general descriptive (or, eventually, prescriptive) document or set of documents then we would be able to get feedback from those different communities (much as we did while working on RFC 6125). So for now I will mostly go along with what you've just proposed, with the proviso that I'll keep an eye on the work here (and encourage folks from other technology communities to do the same) so we can see where input from outside of HTTPS would be important. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA2i5UACgkQNL8k5A2w/vwt5gCgtPPTJYdYRXA7Vte1DJXlXstP La0An3sCMSbYg9dnlhrraMWAdzlqcVDb =llow -----END PGP SIGNATURE----- From Jeff.Hodges@KingsMountain.com Fri Aug 24 10:28:32 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 41F3721F86B1 for ; Fri, 24 Aug 2012 10:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.67 X-Spam-Level: X-Spam-Status: No, score=-100.67 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 kbj27ETTbe5i for ; Fri, 24 Aug 2012 10:28:31 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 9AA9D21F8646 for ; Fri, 24 Aug 2012 10:28:31 -0700 (PDT) Received: (qmail 14653 invoked by uid 0); 24 Aug 2012 17:28:31 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 24 Aug 2012 17:28:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=I5fWHQhvZmQipuDzj4i+0bPGe2Q1bAIZ6h4B265KlAE=; b=1APKGe1gqww6/i1v+8ob+IgY0yj1VYnUG5IgLp9uExWLsX3c27LgU7C8fYOGF4nSQt4UoASroJO7IOHuuH24Dhsq28ZT9MN3TC89OI2YLRIQbOPwwWMPLQJxgaQloqHB; Received: from [24.4.122.173] (port=60904 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T4xgM-000131-NC; Fri, 24 Aug 2012 11:28:30 -0600 Message-ID: <5037B9BD.7050601@KingsMountain.com> Date: Fri, 24 Aug 2012 10:28:29 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: wpkops@ietf.org, Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [wpkops] scope of addressed app technologies (was: First draft charter proposal) 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, 24 Aug 2012 17:28:32 -0000 Peter SA replied: > On 8/23/12 1:28 PM, Hodges, Jeff wrote: >> Peter SA replied: >>> On 8/22/12 10:23 PM, Hill, Brad wrote: >>>> >>>> d) Does that work depend on or build directly from the HTTPS >>>> work, or are there other WGs where it can be undertaken on its >>>> own timeline and where the "right people" are already >>>> assembled? >>> >>> I think some of the work for other application technologies is >>> parallel to the HTTPS work, and some of it is downstream. We'll >>> need to get down to cases and see exactly what work applies more >>> generally and what work is specific to particular technologies. >> >> Given that just doing this work for HTTPS will be tough, > > True. You saw how long it took us to produce RFC 6125... Indeed. >> I'm for keeping the charter narrowly focused on HTTPS PKI for now, >> coming up with some initial drafts, and then as they firm up, >> shopping them around to the other app technology communities (aka >> working groups) to see if they have interest in doing the same for >> their areas of interest, and then consider re-chartering. > > Perchance. I somewhat doubt that every community will have the energy > to work on dedicated documents of a descriptive nature (and some of > those communities no longer have WGs at the IETF), but I do think that > if someone writes a more general descriptive (or, eventually, > prescriptive) document or set of documents then we would be able to > get feedback from those different communities (much as we did while > working on RFC 6125). agreed. > So for now I will mostly go along with what > you've just proposed, with the proviso that I'll keep an eye on the > work here (and encourage folks from other technology communities to do > the same) so we can see where input from outside of HTTPS would be > important. sounds good. thanks, =JeffH From tim.moses@entrust.com Tue Aug 28 07:58:29 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 D7AB621F84CE for ; Tue, 28 Aug 2012 07:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 Sk2GfiNo-2hA for ; Tue, 28 Aug 2012 07:58:29 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDB821F84EA for ; Tue, 28 Aug 2012 07:58:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,327,1344225600"; d="scan'208";a="1804500" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 28 Aug 2012 10:58:16 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Tue, 28 Aug 2012 10:58:16 -0400 From: Tim Moses To: "'wpkops@ietf.org'" Thread-Topic: Scope Thread-Index: Ac2FLQOf067PJtcuTxW2JRJChd6B0QAADibA Date: Tue, 28 Aug 2012 14:58:15 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [wpkops] Scope 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, 28 Aug 2012 14:58:30 -0000 Colleagues - As discussed, the idea is to document the Web PKI as it is pra= cticed today. Generally, that means considering product versions other tha= n the most recent one from each significant supplier. But, in order to kee= p the workload at a manageable level, we will have to eliminate product ver= sions that are seldom encountered today. Without making reference to speci= fic products and versions, it's tough to come up with an objective criterio= n for identifying the versions that deserve to be documented. Therefore, I= believe we have to rely on experts' judgments. As a guide, we might agree that, in order to warrant consideration, a techn= ique must be involved in more than one percent of connections that use the = Web PKI. While we would not attempt to apply this threshold with any preci= sion, contributors may appeal to it in order to justify their exclusion of = a particular technique. Then the disputant would be called upon to demonstr= ate that the technique was more prevalent. What do others think? All the best. Tim. From agl@google.com Tue Aug 28 08:09:15 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 CEAB511E80E7 for ; Tue, 28 Aug 2012 08:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.555, 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 6hBhZxfAg3I6 for ; Tue, 28 Aug 2012 08:09:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4608411E8099 for ; Tue, 28 Aug 2012 08:09:15 -0700 (PDT) Received: by iabz21 with SMTP id z21so12222134iab.31 for ; Tue, 28 Aug 2012 08:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record; bh=Tnism/18HZqq6YGuQt2jkiLiOVGMaXNPeCVhslkwSf8=; b=C5MfHQJuhlc4sbkJ8g40P/vEcWQLlA7n+7ue9u7nVX8TIqUhJughI4shvst1BiIA1w ae+uwMWeRn/wdyVKgTZ8/4QAissVbvmjvFofCDEB2vkkF87ofPGFL6BRZlRugk3N8KIm 4DO0kLDti3B8miYB2YwKWg85Q/IGRAe6L4V1MhRVRZosJxTd2XUcwsNkHVi5pFFuQU6D DDjkLq8YVJa+vPqeX2D307DdEMw5rLEDvuPzyVVGhYDhFPwZneaqBFvN+h2/ivt5MkYZ d5FqHOfRz3TZVmoRiGhxp7FFlXcJ1CVfOvFcgXAwUMBpggXv5YZTZ5yehB7qNy2XWEQq nn1Q== 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 :content-transfer-encoding:x-system-of-record:x-gm-message-state; bh=Tnism/18HZqq6YGuQt2jkiLiOVGMaXNPeCVhslkwSf8=; b=e/8ydMCulHpySNdHtOZZJJYxCsrCzVpMEWtyeA+zXskugwT7YY56VT0EToYXSOUVPI y49wz0EoyjUnGTZRUn3NVXnrvFS8ksRO3/BmfRI8R9apu6RhEiO6xuh0BkuiPqK6Ir8+ DQSVxYFXvLn7uvYOCjOykmNAygm8zpb3GxJd1jn8ruLoUIPF0ZsGVKNfhkg+yhj1WvJ3 36T4ttIuIRzFM3CW7NPhQ+HJUtnRU/N2VSBSRxaauhhrhstSgcZj3duqYWG+GJabd7Hx Hi6iY5kUyN89ayz0YpJ/wQ9w32REpH9vrVX3s67hGnPv2XL6xW3GIdYkE5bcplaZL1ef 6MFQ== Received: by 10.50.173.41 with SMTP id bh9mr8484203igc.52.1346166554305; Tue, 28 Aug 2012 08:09:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.173.41 with SMTP id bh9mr8484178igc.52.1346166554035; Tue, 28 Aug 2012 08:09:14 -0700 (PDT) Sender: agl@google.com Received: by 10.231.224.84 with HTTP; Tue, 28 Aug 2012 08:09:13 -0700 (PDT) In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> Date: Tue, 28 Aug 2012 11:09:13 -0400 X-Google-Sender-Auth: ZMgH61KzLfQhmlmJoF32ZecCGr4 Message-ID: From: Adam Langley To: Tim Moses Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlFYECxOrNsSaxq4KvpvqnSUcwQjxYxvC88InMwm3Q/I2JstAC642aCka+tCOA2WAG7bEkyeF93Tca9rpLr2Oju+fjCLQxNCf+2bWaTom/LxYsKvpv2Kqc0n//Y5F9mXggLwexmyXeOT8O2dExuOzwEyFBG+y1wtGR9IqjohMG8y2ilLGhi+EmJpd0RL0IuxCBIWlYd Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Scope 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, 28 Aug 2012 15:09:15 -0000 On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses wrote: > Colleagues - As discussed, the idea is to document the Web PKI as it is p= racticed today. Generally, that means considering product versions other t= han the most recent one from each significant supplier. But, in order to k= eep the workload at a manageable level, we will have to eliminate product v= ersions that are seldom encountered today. Without making reference to spe= cific products and versions, it's tough to come up with an objective criter= ion for identifying the versions that deserve to be documented. Therefore,= I believe we have to rely on experts' judgments. > > As a guide, we might agree that, in order to warrant consideration, a tec= hnique must be involved in more than one percent of connections that use th= e Web PKI. While we would not attempt to apply this threshold with any pre= cision, contributors may appeal to it in order to justify their exclusion o= f a particular technique. Then the disputant would be called upon to demons= trate that the technique was more prevalent. > > What do others think? 1% seems reasonable although, if anything, a little high. There are workarounds that apply to less than 1% but are, none the less, important. But any number 0.1%..1% seems sane. Cheers AGL From Rick_Andrews@symantec.com Tue Aug 28 09:56:06 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 1325421F85C0 for ; Tue, 28 Aug 2012 09:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz3xpIta2BXy for ; Tue, 28 Aug 2012 09:56:04 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9586E21F8596 for ; Tue, 28 Aug 2012 09:56:04 -0700 (PDT) X-AuditID: d80ac3f1-b7feb6d000005c5d-3a-503cf823a3e3 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 5B.21.23645.328FC305; Tue, 28 Aug 2012 16:56:03 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1T6P59-0000Dt-E2; Tue, 28 Aug 2012 16:56:03 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Tue, 28 Aug 2012 09:56:03 -0700 From: Rick Andrews To: Adam Langley , Tim Moses Date: Tue, 28 Aug 2012 09:56:02 -0700 Thread-Topic: [wpkops] Scope Thread-Index: Ac2FLxj0y8sD1lPQQRSJmD/j6qmYXQADpBeA Message-ID: <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsVyYMU1bV3lHzYBBr275C1u9L5jtVh0cAOr xc1T21kdmD1mN1xk8Xj5eTejx5IlP5kCmKO4bFJSczLLUov07RK4Mj7NXMlSsEygYtn9ftYG xn7eLkZODgkBE4lT23vZIWwxiQv31rN1MXJxCAl8YJSYt/ArC4TzilFi1dOPUJlVjBKLtyxn BWlhE9CT2PL4Cli7iICbxK2LD1hAbGYBdYmpDS1gNSwCqhIrjp5m7GLk4BAWkJY49TcWxBQR kJGYdkgFotNI4vvHb2BTeAWiJA48WcwMsWoOo8S3HVPBxnAKBEq8/3uVDcRmBLr0+6k1TBCr xCVuPZnPBPGBgMSSPeeZIWxRiZeP/7FC1ItK3GlfzwhRryOxYPcnNghbW2LZwtfMEIsFJU7O fMIygVF8FpKxs5C0zELSMgtJywJGllWMMiWlxYbFuSX5pSUFqRUGhnrFlbmJwLhL1kvOz93E CIy9G1yHP+5gvL5U8RCjAAejEg9v31qbACHWxDKgykOMEhzMSiK8564BhXhTEiurUovy44tK c1KLDzFKc7AoifO+373VX0ggPbEkNTs1tSC1CCbLxMEp1cC4zXffHH+T964rYpfO4v9w1n/l qeyVE4wYHyqd3zVvts+3bq6Uj0XbqpSm/dhRk8TaEbPbas5k+57FGTemPfH8ffnHSoX0Ke3/ Nx2d/EW5hlup2iBqc4f7M8cb9bIN4g+i/G76a33bfn/FRB6pzJdS70IMfvP6iU5t/ueRYSXS e/q7RG1L2vfLSizFGYmGWsxFxYkAWKanxrkCAAA= Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Scope 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, 28 Aug 2012 16:56:06 -0000 Tim, I think the 1% fuzzy threshold is fine. But I really hope that the sum= total of connections that use Web PKI includes mobile browsers and apps. I= 've heard anecdotally that mobile represents a large and ever-growing share= of web use, and I think it's essential to include it. -Rick > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf = Of > Adam Langley > Sent: Tuesday, August 28, 2012 8:09 AM > To: Tim Moses > Cc: wpkops@ietf.org > Subject: Re: [wpkops] Scope >=20 > On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses wrote= : > > Colleagues - As discussed, the idea is to document the Web PKI as it is > practiced today. Generally, that means considering product versions othe= r > than the most recent one from each significant supplier. But, in order t= o > keep the workload at a manageable level, we will have to eliminate produc= t > versions that are seldom encountered today. Without making reference to > specific products and versions, it's tough to come up with an objective > criterion for identifying the versions that deserve to be documented. > Therefore, I believe we have to rely on experts' judgments. > > > > As a guide, we might agree that, in order to warrant consideration, a > technique must be involved in more than one percent of connections that u= se > the Web PKI. While we would not attempt to apply this threshold with any > precision, contributors may appeal to it in order to justify their exclus= ion > of a particular technique. Then the disputant would be called upon to > demonstrate that the technique was more prevalent. > > > > What do others think? >=20 > 1% seems reasonable although, if anything, a little high. There are > workarounds that apply to less than 1% but are, none the less, > important. But any number 0.1%..1% seems sane. >=20 >=20 > Cheers >=20 > AGL > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops From tim.moses@entrust.com Tue Aug 28 09:59:37 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 9370421F855A for ; Tue, 28 Aug 2012 09:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 Iy2yh6ULp3Eb for ; Tue, 28 Aug 2012 09:59:37 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id D938021F8514 for ; Tue, 28 Aug 2012 09:59:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,327,1344225600"; d="scan'208";a="6040051" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 28 Aug 2012 12:59: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.001; Tue, 28 Aug 2012 12:59:36 -0400 From: Tim Moses To: 'Rick Andrews' Thread-Topic: [wpkops] Scope Thread-Index: AQHNhS8Wk6F4vhDnQku8ZZoRSxLk2JdvtLIA//+9hNA= Date: Tue, 28 Aug 2012 16:59:35 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Scope 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, 28 Aug 2012 16:59:37 -0000 Hi Rick. I completely agree. It's covered in the last paragraph of the dr= aft charter. In the near future I'll distribute an updated charter proposa= l. All the best. Tim. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Rick Andrews Sent: Tuesday, August 28, 2012 12:56 PM To: Adam Langley; Tim Moses Cc: wpkops@ietf.org Subject: Re: [wpkops] Scope Tim, I think the 1% fuzzy threshold is fine. But I really hope that the sum= total of connections that use Web PKI includes mobile browsers and apps. I= 've heard anecdotally that mobile represents a large and ever-growing share= of web use, and I think it's essential to include it. -Rick > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 > Behalf Of Adam Langley > Sent: Tuesday, August 28, 2012 8:09 AM > To: Tim Moses > Cc: wpkops@ietf.org > Subject: Re: [wpkops] Scope >=20 > On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses wrote= : > > Colleagues - As discussed, the idea is to document the Web PKI as it=20 > > is > practiced today. Generally, that means considering product versions=20 > other than the most recent one from each significant supplier. But,=20 > in order to keep the workload at a manageable level, we will have to=20 > eliminate product versions that are seldom encountered today. Without=20 > making reference to specific products and versions, it's tough to come=20 > up with an objective criterion for identifying the versions that deserve = to be documented. > Therefore, I believe we have to rely on experts' judgments. > > > > As a guide, we might agree that, in order to warrant consideration,=20 > > a > technique must be involved in more than one percent of connections=20 > that use the Web PKI. While we would not attempt to apply this=20 > threshold with any precision, contributors may appeal to it in order=20 > to justify their exclusion of a particular technique. Then the=20 > disputant would be called upon to demonstrate that the technique was more= prevalent. > > > > What do others think? >=20 > 1% seems reasonable although, if anything, a little high. There are=20 > workarounds that apply to less than 1% but are, none the less,=20 > important. But any number 0.1%..1% seems sane. >=20 >=20 > Cheers >=20 > AGL > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From rturner@amalfisystems.com Tue Aug 28 12:26:06 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 DC6AA11E80F7 for ; Tue, 28 Aug 2012 12:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK88kwDgfpWg for ; Tue, 28 Aug 2012 12:26:06 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4C11E80D9 for ; Tue, 28 Aug 2012 12:26:06 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7SJQ4xM027479 for ; Tue, 28 Aug 2012 15:26:04 -0400 X-Authenticated-IP: 98.151.18.90 Received: from [98.151.18.90] ([98.151.18.90:56640] helo=[192.168.1.106]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 3B/55-08981-B4B1D305; Tue, 28 Aug 2012 15:26:04 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Randy Turner In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> Date: Tue, 28 Aug 2012 12:26:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> To: wpkops@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [wpkops] Scope 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, 28 Aug 2012 19:26:07 -0000 Hi Tim, So, in a nutshell (because this is an OPS effort), we're doing to: 1. Document existing practice, given the most prevalent products, and 2. Given existing practice, analyze this existing practice for a set of = BCPs Is this correct? Thanks! Randy On Aug 28, 2012, at 9:59 AM, Tim Moses wrote: > Hi Rick. I completely agree. It's covered in the last paragraph of = the draft charter. In the near future I'll distribute an updated = charter proposal. All the best. Tim. >=20 > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On = Behalf Of Rick Andrews > Sent: Tuesday, August 28, 2012 12:56 PM > To: Adam Langley; Tim Moses > Cc: wpkops@ietf.org > Subject: Re: [wpkops] Scope >=20 > Tim, I think the 1% fuzzy threshold is fine. But I really hope that = the sum total of connections that use Web PKI includes mobile browsers = and apps. I've heard anecdotally that mobile represents a large and = ever-growing share of web use, and I think it's essential to include it. >=20 > -Rick >=20 >> -----Original Message----- >> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 >> Behalf Of Adam Langley >> Sent: Tuesday, August 28, 2012 8:09 AM >> To: Tim Moses >> Cc: wpkops@ietf.org >> Subject: Re: [wpkops] Scope >>=20 >> On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses = wrote: >>> Colleagues - As discussed, the idea is to document the Web PKI as it=20= >>> is >> practiced today. Generally, that means considering product versions=20= >> other than the most recent one from each significant supplier. But,=20= >> in order to keep the workload at a manageable level, we will have to=20= >> eliminate product versions that are seldom encountered today. = Without=20 >> making reference to specific products and versions, it's tough to = come=20 >> up with an objective criterion for identifying the versions that = deserve to be documented. >> Therefore, I believe we have to rely on experts' judgments. >>>=20 >>> As a guide, we might agree that, in order to warrant consideration,=20= >>> a >> technique must be involved in more than one percent of connections=20 >> that use the Web PKI. While we would not attempt to apply this=20 >> threshold with any precision, contributors may appeal to it in order=20= >> to justify their exclusion of a particular technique. Then the=20 >> disputant would be called upon to demonstrate that the technique was = more prevalent. >>>=20 >>> What do others think? >>=20 >> 1% seems reasonable although, if anything, a little high. There are=20= >> workarounds that apply to less than 1% but are, none the less,=20 >> important. But any number 0.1%..1% seems sane. >>=20 >>=20 >> Cheers >>=20 >> AGL >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 From tim.moses@entrust.com Tue Aug 28 12:29:59 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 06C9511E810B for ; Tue, 28 Aug 2012 12:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 yaYJBmyZFy9B for ; Tue, 28 Aug 2012 12:29:58 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03411E8107 for ; Tue, 28 Aug 2012 12:29:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,328,1344225600"; d="scan'208";a="6041944" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 28 Aug 2012 15:29:57 -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.001; Tue, 28 Aug 2012 15:29:57 -0400 From: Tim Moses To: 'Randy Turner' Thread-Topic: [wpkops] Scope Thread-Index: AQHNhS8Wk6F4vhDnQku8ZZoRSxLk2JdvtLIA//+9hNCAAGxmgP//vUpQ Date: Tue, 28 Aug 2012 19:29:56 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Scope 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, 28 Aug 2012 19:29:59 -0000 Hi Randy. That's right. Hopefully, this will be a precursor to fixing som= e of the issues with the Web PKI. But, step one is to "catalog" what we ha= ve. So, we'll start by producing a set of BCPs that document major aspects= of the Web PKI as it is generally practiced today. All the best. Tim. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Randy Turner Sent: Tuesday, August 28, 2012 3:26 PM To: wpkops@ietf.org Subject: Re: [wpkops] Scope Hi Tim, So, in a nutshell (because this is an OPS effort), we're doing to: 1. Document existing practice, given the most prevalent products, and 2. Gi= ven existing practice, analyze this existing practice for a set of BCPs Is this correct? Thanks! Randy On Aug 28, 2012, at 9:59 AM, Tim Moses wrote: > Hi Rick. I completely agree. It's covered in the last paragraph of the = draft charter. In the near future I'll distribute an updated charter propo= sal. All the best. Tim. >=20 > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 > Behalf Of Rick Andrews > Sent: Tuesday, August 28, 2012 12:56 PM > To: Adam Langley; Tim Moses > Cc: wpkops@ietf.org > Subject: Re: [wpkops] Scope >=20 > Tim, I think the 1% fuzzy threshold is fine. But I really hope that the s= um total of connections that use Web PKI includes mobile browsers and apps.= I've heard anecdotally that mobile represents a large and ever-growing sha= re of web use, and I think it's essential to include it. >=20 > -Rick >=20 >> -----Original Message----- >> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 >> Behalf Of Adam Langley >> Sent: Tuesday, August 28, 2012 8:09 AM >> To: Tim Moses >> Cc: wpkops@ietf.org >> Subject: Re: [wpkops] Scope >>=20 >> On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses wrot= e: >>> Colleagues - As discussed, the idea is to document the Web PKI as it=20 >>> is >> practiced today. Generally, that means considering product versions=20 >> other than the most recent one from each significant supplier. But,=20 >> in order to keep the workload at a manageable level, we will have to=20 >> eliminate product versions that are seldom encountered today. =20 >> Without making reference to specific products and versions, it's=20 >> tough to come up with an objective criterion for identifying the version= s that deserve to be documented. >> Therefore, I believe we have to rely on experts' judgments. >>>=20 >>> As a guide, we might agree that, in order to warrant consideration,=20 >>> a >> technique must be involved in more than one percent of connections=20 >> that use the Web PKI. While we would not attempt to apply this=20 >> threshold with any precision, contributors may appeal to it in order=20 >> to justify their exclusion of a particular technique. Then the=20 >> disputant would be called upon to demonstrate that the technique was mor= e prevalent. >>>=20 >>> What do others think? >>=20 >> 1% seems reasonable although, if anything, a little high. There are=20 >> workarounds that apply to less than 1% but are, none the less,=20 >> important. But any number 0.1%..1% seems sane. >>=20 >>=20 >> Cheers >>=20 >> AGL >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From stpeter@stpeter.im Tue Aug 28 12:37:05 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 6F7FC21F845F for ; Tue, 28 Aug 2012 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 XFZiW6j8wv3n for ; Tue, 28 Aug 2012 12:37:02 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7710411E8099 for ; Tue, 28 Aug 2012 12:37:02 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4D828404EB; Tue, 28 Aug 2012 13:38:11 -0600 (MDT) Message-ID: <503D1DDC.8020504@stpeter.im> Date: Tue, 28 Aug 2012 13:37:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Randy Turner' , "wpkops@ietf.org" Subject: Re: [wpkops] Scope 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, 28 Aug 2012 19:37:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/28/12 1:29 PM, Tim Moses wrote: > Hi Randy. That's right. Hopefully, this will be a precursor to > fixing some of the issues with the Web PKI. But, step one is to > "catalog" what we have. So, we'll start by producing a set of > BCPs that document major aspects of the Web PKI as it is generally > practiced today. I'm not sure if those would really be BCPs or Informational, but we'll burn that bridge when we come to it. ;-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9HdwACgkQNL8k5A2w/vxrWgCgy9lcyDBsPVSyREEgx+RsVuqr PbgAoORHojR+zz9PxdsC+ySrSKR6zLUP =oz+u -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Tue Aug 28 13:57:22 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 D2C8411E80F8 for ; Tue, 28 Aug 2012 13:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 AcnBcGOrIhqX for ; Tue, 28 Aug 2012 13:57:16 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6452611E8099 for ; Tue, 28 Aug 2012 13:57:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 011B5171481; Tue, 28 Aug 2012 21:57:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346187434; bh=3NVsHs7SMNjX9p 1KqXFwsub5p1c7GtgEoFVks0Kcv/0=; b=yzNwcKmdObYU8FARUNhAQ6HVMxXnVi KA51VXnpblFlxkq0WMV8fPn+S/tbwzePuWGvTaypUxH0gdGnIEkXKb5izqjrX0lm Jl0NmeDKRvdEiXeyK7cvWAwGrEhE1Bua+WeF/XPK1GyYgpUiPIHNP3AxNEAnLiRg GjR5lzOFqLIodqxIgiLCyeJqGSuSj95c1Ng68ESA8qRnejF7JV17/0PAeUET+yQ0 1Wl2QKqIgffRRg65x/OzdkDSajuc8xbdSsCE6lcMBlq+kZG0+UpvoSJeZEtHRtGP IO7Bfl/4gGZmfgObOmza7BV5peqoOVBX8GeSkeS+EJSajrlpYZW4me9w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id YqNrFkNGdY56; Tue, 28 Aug 2012 21:57:14 +0100 (IST) Received: from [10.87.48.7] (unknown [86.42.18.88]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2A4C1171474; Tue, 28 Aug 2012 21:57:10 +0100 (IST) Message-ID: <503D30A6.2000704@cs.tcd.ie> Date: Tue, 28 Aug 2012 21:57:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> <503D1DDC.8020504@stpeter.im> In-Reply-To: <503D1DDC.8020504@stpeter.im> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Randy Turner' , "wpkops@ietf.org" , Tim Moses Subject: Re: [wpkops] Scope 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, 28 Aug 2012 20:57:23 -0000 On 08/28/2012 08:37 PM, Peter Saint-Andre wrote: > I'm not sure if those would really be BCPs or Informational, but we'll > burn that bridge when we come to it. ;-) Right. While there can be debates about how to label RFCs (and even better, the outcome of those debates varies over time;-) that's something that can be decided on a case by case basis e.g. as you add milestones or later. In this case, I guess you can think of it as follows: - If a document just says what's out there but isn't trying to encourage anyone to do thing in that precise way (or to not do that) then its informational. - If a document is recommending to do stuff "this" way, then its more of a BCP. - There're grey bits in between. If you want the official word on that, you can read the bit of rfc 2026 that describes BCPs [1] but note what I said above - we have folks involved in the IETF who can debate this stuff endlessly. Better to decide what you wanna do though and not get hung up on status. S. [1] http://tools.ietf.org/html/rfc2026#section-5 From stephen.farrell@cs.tcd.ie Tue Aug 28 14:04:32 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 A90D521F85A1 for ; Tue, 28 Aug 2012 14:04:32 -0700 (PDT) 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.200, 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 oN6NY3XXrJ36 for ; Tue, 28 Aug 2012 14:04:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C16021F859F for ; Tue, 28 Aug 2012 14:04:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7C771171481; Tue, 28 Aug 2012 22:04:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346187869; bh=obo7VUEuCHFsKy R4+0Dtitet9NXQ+B/raxR81qdTcoU=; b=WdgCjY6SocbuhIm6hq+Ltm3hkwPNZU LQKTaWlzWHGFQvvlFQfWJxsv0N3NqM3AXV07biOLP58sVb481YVvLRb63ZKxpWNI /EoVyEEQYtxOOF8ywk14xjPPBsJM1o6HYWzmM9PhRd7P9gqtpcQ846V7Cb4cbZIm tAw64ecCZFyZbKCXAgv9owh65i76rtRUm/IQs09o3s+AM75KulmBvKi310pPbTCt QG/bhXMBoOmERcw0iWHWP6Mj2iKvA6llVAvFXtGwrU9tJMCO6/vwhzCDwUNOB814 LXCscWR9AsqvzwP8tGFZ/qOxTIolguQsSEWWc1EEj8YcumBjVkFd/ZpQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id duc6XOvhllBK; Tue, 28 Aug 2012 22:04:29 +0100 (IST) Received: from [10.87.48.7] (unknown [86.42.18.88]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BC483171474; Tue, 28 Aug 2012 22:04:28 +0100 (IST) Message-ID: <503D325C.80305@cs.tcd.ie> Date: Tue, 28 Aug 2012 22:04:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Randy Turner' , "wpkops@ietf.org" Subject: Re: [wpkops] Scope 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, 28 Aug 2012 21:04:32 -0000 So in addition, I was hoping this group would document use-cases and requirements for new protocols or changes to current protocols if the wg figure some are needed so that we could spin-up short-lived SEC or other WGs as needed. I'm not gonna stamp my feet if folks don't want to do that but I'd hope to get that kind of output so's we can concentrate on new protocol work in this space that'll be more likely to get adopted. (I would stamp my feet if folks wanted to specify new protocols in this group.) Cheers, S. On 08/28/2012 08:29 PM, Tim Moses wrote: > Hi Randy. That's right. Hopefully, this will be a precursor to fixing some of the issues with the Web PKI. But, step one is to "catalog" what we have. So, we'll start by producing a set of BCPs that document major aspects of the Web PKI as it is generally practiced today. > > All the best. Tim. > > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of Randy Turner > Sent: Tuesday, August 28, 2012 3:26 PM > To: wpkops@ietf.org > Subject: Re: [wpkops] Scope > > > Hi Tim, > > So, in a nutshell (because this is an OPS effort), we're doing to: > > 1. Document existing practice, given the most prevalent products, and 2. Given existing practice, analyze this existing practice for a set of BCPs > > Is this correct? > > Thanks! > Randy > > On Aug 28, 2012, at 9:59 AM, Tim Moses wrote: > >> Hi Rick. I completely agree. It's covered in the last paragraph of the draft charter. In the near future I'll distribute an updated charter proposal. All the best. Tim. >> >> -----Original Message----- >> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On >> Behalf Of Rick Andrews >> Sent: Tuesday, August 28, 2012 12:56 PM >> To: Adam Langley; Tim Moses >> Cc: wpkops@ietf.org >> Subject: Re: [wpkops] Scope >> >> Tim, I think the 1% fuzzy threshold is fine. But I really hope that the sum total of connections that use Web PKI includes mobile browsers and apps. I've heard anecdotally that mobile represents a large and ever-growing share of web use, and I think it's essential to include it. >> >> -Rick >> >>> -----Original Message----- >>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On >>> Behalf Of Adam Langley >>> Sent: Tuesday, August 28, 2012 8:09 AM >>> To: Tim Moses >>> Cc: wpkops@ietf.org >>> Subject: Re: [wpkops] Scope >>> >>> On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses wrote: >>>> Colleagues - As discussed, the idea is to document the Web PKI as it >>>> is >>> practiced today. Generally, that means considering product versions >>> other than the most recent one from each significant supplier. But, >>> in order to keep the workload at a manageable level, we will have to >>> eliminate product versions that are seldom encountered today. >>> Without making reference to specific products and versions, it's >>> tough to come up with an objective criterion for identifying the versions that deserve to be documented. >>> Therefore, I believe we have to rely on experts' judgments. >>>> >>>> As a guide, we might agree that, in order to warrant consideration, >>>> a >>> technique must be involved in more than one percent of connections >>> that use the Web PKI. While we would not attempt to apply this >>> threshold with any precision, contributors may appeal to it in order >>> to justify their exclusion of a particular technique. Then the >>> disputant would be called upon to demonstrate that the technique was more prevalent. >>>> >>>> What do others think? >>> >>> 1% seems reasonable although, if anything, a little high. There are >>> workarounds that apply to less than 1% but are, none the less, >>> important. But any number 0.1%..1% seems sane. >>> >>> >>> Cheers >>> >>> AGL >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From asteingruebl@paypal-inc.com Tue Aug 28 14:12:23 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 D66B311E80E7 for ; Tue, 28 Aug 2012 14:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 jdTzTqOJF7OT for ; Tue, 28 Aug 2012 14:12:23 -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 ED55711E8099 for ; Tue, 28 Aug 2012 14:12:22 -0700 (PDT) DomainKey-Signature: s=ppinc; 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:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=D1ZiA4/4tx595eBsLozAypoV0mwj5Mo+irfS4jmDUJSNm/KS+SrNrp/g NLd6tT7if5ruZ8CbKrr5wLU33H5mzGoIyWQSmIOOY/nu+0e2rPLukP5U4 2kF19j7UvQDrNsA; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1346188343; x=1377724343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+qmw7gm1O8Nw7IK4kuUsGEJlhSfsHjR6AJvEBvUJk24=; b=I4AxNFC660d/lf29K37B4Bw+Uyy98ziDdhfiLYtASX5tVSkxO+WxJbTZ 3JTY7Aqf98u4lE6Q6eG1mNpCCsOIZ0kMf+7lCSL5QXL3o4471AeckYnkZ kGDF+bfwf92u46V; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,328,1344236400"; d="scan'208";a="9902371" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 28 Aug 2012 14:12:22 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-002.corp.ebay.com ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 15:12:17 -0600 From: "Steingruebl, Andy" To: Stephen Farrell , Tim Moses Thread-Topic: [wpkops] Scope Thread-Index: Ac2FLQOf067PJtcuTxW2JRJChd6B0QAADibAAA0I6IAAA7sEAAAAH72AAAUdhIAAACK4AAADTTIAAAxeOlA= Date: Tue, 28 Aug 2012 21:12:17 +0000 Message-ID: <1DFCCAFE421024488073B74EEA0173E1293C6B@DEN-EXDDA-S12.corp.ebay.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> <503D325C.80305@cs.tcd.ie> In-Reply-To: <503D325C.80305@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.243] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: tVIIzKNMSI43yd0ZwDKNAQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: 'Randy Turner' , "wpkops@ietf.org" Subject: Re: [wpkops] Scope 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, 28 Aug 2012 21:12:23 -0000 > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On > Behalf Of Stephen Farrell >=20 > So in addition, I was hoping this group would document use-cases and > requirements for new protocols or changes to current protocols if the wg > figure some are needed so that we could spin-up short-lived SEC or other > WGs as needed. I view this sort of like I view Zalewski's browser security handbook (http= ://code.google.com/p/browsersec/wiki/Main). Anywhere we document a behavior using a chart or some such and the behavior= differs, or we can't point to an underlying spec that allows for the varia= nce, we should seriously consider spinning up some standards work, and hope= that we can get everyone to adopt. I don't think this is a misplaced hope/plan at all :) - Andy From joncallas@me.com Tue Aug 28 14:32:49 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 D3EF221F8471 for ; Tue, 28 Aug 2012 14:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sFVprIE0hKl for ; Tue, 28 Aug 2012 14:32:49 -0700 (PDT) Received: from st11p01mm-asmtp001.mac.com (st11p01mm-asmtpout001.mac.com [17.172.204.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6432E21F8468 for ; Tue, 28 Aug 2012 14:32:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.4.25.151] (client36.entrust.com [216.191.251.36]) by st11p01mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0M9H00HP2IEY5930@st11p01mm-asmtp001.mac.com> for wpkops@ietf.org; Tue, 28 Aug 2012 21:32:35 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-08-28_07:2012-08-28, 2012-08-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208280248 From: Jon Callas In-reply-to: <503D325C.80305@cs.tcd.ie> Date: Tue, 28 Aug 2012 14:21:05 -0700 Message-id: References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> <503D325C.80305@cs.tcd.ie> To: wpkops@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [wpkops] Scope 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, 28 Aug 2012 21:32:49 -0000 On Aug 28, 2012, at 2:04 PM, Stephen Farrell wrote: > > So in addition, I was hoping this group would document > use-cases and requirements for new protocols or changes > to current protocols if the wg figure some are needed > so that we could spin-up short-lived SEC or other WGs > as needed. I think that is *precisely* one of the things this group should be doing. As we've noted Web PKI isn't precisely what -- umm, what's the correct back-formation? -- orthodox PKI? -- is. Those deltas cam out of real-world use cases that had real-world requirements. It's best to discuss them along with the use cases because the use cases are the whys. Jon From rturner@amalfisystems.com Tue Aug 28 14:37: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 2411611E80D9 for ; Tue, 28 Aug 2012 14:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 AkIRzwZO8x-x for ; Tue, 28 Aug 2012 14:37:37 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8547221F8471 for ; Tue, 28 Aug 2012 14:37:37 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q7SLbaJP027070 for ; Tue, 28 Aug 2012 17:37:36 -0400 X-Authenticated-IP: 98.151.18.90 Received: from [98.151.18.90] ([98.151.18.90:63282] helo=[192.168.1.106]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 2D/DD-31423-02A3D305; Tue, 28 Aug 2012 17:37:36 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Randy Turner In-Reply-To: Date: Tue, 28 Aug 2012 14:37:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> <503D325C.80305@cs.tcd.ie> To: wpkops@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [wpkops] Scope 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, 28 Aug 2012 21:37:38 -0000 to emphasize Tim's desire for reduced scope, I am thinking that during = the generation of a set of BCPs, if we find glaring holes in what's = going on, then the group could be re-chartered to address and document = use-cases and new requirements. Randy On Aug 28, 2012, at 2:21 PM, Jon Callas wrote: >=20 > On Aug 28, 2012, at 2:04 PM, Stephen Farrell wrote: >=20 >>=20 >> So in addition, I was hoping this group would document >> use-cases and requirements for new protocols or changes >> to current protocols if the wg figure some are needed >> so that we could spin-up short-lived SEC or other WGs >> as needed. >=20 > I think that is *precisely* one of the things this group should be = doing. >=20 > As we've noted Web PKI isn't precisely what -- umm, what's the correct = back-formation? -- orthodox PKI? -- is. Those deltas cam out of = real-world use cases that had real-world requirements. It's best to = discuss them along with the use cases because the use cases are the = whys. >=20 > Jon >=20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 From Jeff.Hodges@KingsMountain.com Tue Aug 28 15:26:19 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 28C3811E8107 for ; Tue, 28 Aug 2012 15:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.536 X-Spam-Level: X-Spam-Status: No, score=-100.536 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 jvAK+9f0HscP for ; Tue, 28 Aug 2012 15:26:18 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 7C09511E8104 for ; Tue, 28 Aug 2012 15:26:18 -0700 (PDT) Received: (qmail 27232 invoked by uid 0); 28 Aug 2012 22:26:17 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 28 Aug 2012 22:26:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=EvhjiXsDHOeYKgKPrW49Fm8tzJ7aVybeceipSijtybA=; b=6EBKovoLN3+5bqFVFsYUhLe7pJW6YZguW94YnuIB0Rn5xW/DgZkLmIFNMiquHNXM0lFKt5uL8hTlU1XYJeKnCXE4yeeAtc1nqYIJVuNSkRydCx7pG82Fbkp59+Q5qNUY; Received: from [216.113.168.128] (port=46270 helo=[10.244.136.52]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T6UEj-0002q6-Iv for wpkops@ietf.org; Tue, 28 Aug 2012 16:26:17 -0600 Message-ID: <503D458A.6030102@KingsMountain.com> Date: Tue, 28 Aug 2012 15:26:18 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: wpkops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [wpkops] Scope 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, 28 Aug 2012 22:26:19 -0000 Andy noted.. > > From: Stephen Farrell >> >> So in addition, I was hoping this group would document use-cases and >> requirements for new protocols or changes to current protocols if the wg >> figure some are needed so that we could spin-up short-lived SEC or other >> WGs as needed. > > I view this sort of like I view Zalewski's browser security handbook > (http://code.google.com/p/browsersec/wiki/Main). > > Anywhere we document a behavior using a chart or some such and the behavior > differs, or we can't point to an underlying spec that allows for the > variance, we should seriously consider spinning up some standards work, and > hope that we can get everyone to adopt. > > I don't think this is a misplaced hope/plan at all :) +1 Additionally, I was about to point to the browser security handbook (BSH) as perhaps an example of what sort of document(s) wpkops will craft for web pki -- one(s) featuring tables with rows denoting features/behavior and columns denoting implementations. Different tables address different topics. https://code.google.com/p/browsersec/wiki/Part2 =JeffH From turners@ieca.com Tue Aug 28 15:27:07 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 2394511E8107 for ; Tue, 28 Aug 2012 15:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 HFK43PQYxrQ8 for ; Tue, 28 Aug 2012 15:27:01 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.125.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3272C11E8104 for ; Tue, 28 Aug 2012 15:27:01 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id AE534854F038; Tue, 28 Aug 2012 17:27:00 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id A162E854F018 for ; Tue, 28 Aug 2012 17:27:00 -0500 (CDT) Received: from [198.228.199.102] (port=42743 helo=[10.171.185.237]) by gator1743.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1T6UFQ-0002qP-52; Tue, 28 Aug 2012 17:27:00 -0500 References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> <503D325C.80305@cs.tcd.ie> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-021A5EE2-770C-4DA3-AAA0-59598D76979F; protocol="application/pkcs7-signature" Message-Id: <9DC0C5F7-756F-46B2-9BF0-C6D128DC43D0@ieca.com> X-Mailer: iPhone Mail (9B206) From: Sean Turner Date: Tue, 28 Aug 2012 18:26:52 -0400 To: Jon Callas 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: ([10.171.185.237]) [198.228.199.102]:42743 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Scope 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, 28 Aug 2012 22:27:07 -0000 --Apple-Mail-021A5EE2-770C-4DA3-AAA0-59598D76979F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 28, 2012, at 5:21 PM, Jon Callas wrote: >=20 > On Aug 28, 2012, at 2:04 PM, Stephen Farrell wrote: >=20 >>=20 >> So in addition, I was hoping this group would document >> use-cases and requirements for new protocols or changes >> to current protocols if the wg figure some are needed >> so that we could spin-up short-lived SEC or other WGs >> as needed. >=20 > I think that is *precisely* one of the things this group should be doing. >=20 > As we've noted Web PKI isn't precisely what -- umm, what's the correct bac= k-formation? -- orthodox PKI? -- is. Those deltas cam out of real-world use c= ases that had real-world requirements. It's best to discuss them along with t= he use cases because the use cases are the whys. >=20 > Jo For what it's worth this was one of my primary wants out of this effort. Spt > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops --Apple-Mail-021A5EE2-770C-4DA3-AAA0-59598D76979F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUdDANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMjA0MTExNDQ3MjdaFw0xMzA0MTExNDQ3MjdaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANFniuhe1PHTHJz3PO+s3x0UXMwsH8t2er3qAYid2pRDzq6g RAnK49/RpeAoqdtl8Yb1k8yQ0srhvE6461ramVXu8uQEny8/C+tOUeZMPuL2StELpyq0yJ6us0cF AvaEFuEVQOGfVg0hfjh7PqUwyccTqPyY7n/tTFf7ZdekCIYJ4eoOfWAyjcnNbQKLskDrIhlXw2eR 0O2pKLFyFbeGbfeTh+EhvjLeyG2Ue+Am1NsF1XccSQdI6u+mflL93aYvhHct6gMB8mLyz4eAQlrv REYbyrd9rIzVEAeg3l/ct4d+EwYXZ+e7Zx/ksJPbSdg8UC3eezg6ELX7DaXMM8UNw28CAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQdHVybmVyc0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQA6SUSIybM+JcdlBcHzW2vEkDrMWbIVVNUU97NuXTOZNhmLoFe6gU2R4kL9sYTAuQfQ JEMtdtzUzQvuD77qZb4oHVlJiH3Y+8qOP5qAtkbD1351ksLWVhDf2qncxRWcTb5jKTYpJWQSlAWO LtbRrtrItgJJTNGKL2aRLu823EPI/gFOa9/8bVAiAwi8iAh5a2jZL7du1CmxGZFfN5x9Q0mzKKhG 7mVQRr0im8cZb/dh7WWu/YHExecQ110025GD2oibQUNgEVfexPptVyKVC3Lu12oB3zJ8GLcvKlVB RdIuYfL/mogoRLI2rUfNPzibx3lHq36OR7tqDckcXRsXYDyFqTA6YUFEKYdp1IJPghczwvKCfUSa 423plba+JSsg6djnAsFOy3GIR/nKq/W7JOUIOve9FTbLkqu9IWu5hpyRmW6asvwgIbh039VNWTfd xMRCcCdNpawbAeFTA6XrWs8Q2O4r/2GH6hkDGE1dh5sNCq2FsmQEwYCcOgzGzRtQgas/KJAiKvZg d9BRjL3VtApYewt91KJImHNGraETVd5jzOf5PssE3gG5k3QEOcCvo1er4tY9xUF0JUbJz97crnf5 OBrtxNaUfS2oFOmhZMQu3qDe/uyuIin3WwXo65hw3bmf8A0BPNSfNv82F8MB5yjD63pUbxNGksBi IhWRHMhhFDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUdDAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMDgyODIyMjY1OFowIwYJKoZIhvcNAQkEMRYEFArfGmCAmd5vl4RXps8GrD6T aeMHMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUdDBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUdDANBgkqhkiG9w0BAQEFAASCAQCgJCPNrL32p4+un415gg+l2tNi Zs8rFvJbkyKGFaLIHd89wNrgnTx2nK2QVhWLQF/v+gtfqCZi7KoTFG/jV9eYCj+KOx3/x8zlrdTo SrhPHg6njC6mc1zfL4dmU0WQjC7if5BpTDy9JQJKgTwkS6mgeipH/JHUbUEzhPu48GmQcbxt54iC 6jprqOVdWXIKHNsV3yL4Dh3n2dGhl5ecB0w4hq4V9mjq7yDBIQR3+4/HdmWizqqZBs3gt24KE8Gj tzAB52TaM6xeXFiqVB8jYzgWoCKY4nmv2tV1eFcotCDVGysO/NF9MtqiZ44YnsgqyIk1McYCeslk jmQV61rdjztXAAAAAAAA --Apple-Mail-021A5EE2-770C-4DA3-AAA0-59598D76979F-- From tom@ritter.vg Tue Aug 28 15:35:58 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 0018711E8107 for ; Tue, 28 Aug 2012 15:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 9vUneYPOpTAY for ; Tue, 28 Aug 2012 15:35:57 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1F711E8104 for ; Tue, 28 Aug 2012 15:35:56 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7379846vcb.31 for ; Tue, 28 Aug 2012 15:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3rdyknc04ApQ+z4+D6FqQXU42OKZBa2rR1ngadIAIqk=; b=O7U+d87ym86YoHk1Loba0SqoggDdD26jHgQ0ewplSr50g54gifAsmk0uS/jkLw6KWN w9j7MFbVkaBO8h8VJRrnsa9w1JOTUTNHVjhHa0EEeP9JHUY9IWozufy45/uOh7ORGBvC 6Ak1GN0mzpuNbuCBT12nQpTk+jPlVjBNDjKmo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=3rdyknc04ApQ+z4+D6FqQXU42OKZBa2rR1ngadIAIqk=; b=JbSmVz9sqM6sedOV7IARR2RpuONrpJ5TOBFW7a6LPbnUldkPtAt3ymYeHuqFtwQyMH cbH8G8UaWa6YrWN1ByAwEninX4pKbRW0+/Kdr6q/12jf27x5tOH8Xc4cu90Et+ls0cb/ PlxY/EUCea3neeLvkLpwEueoOJk0mrMuRMyiRrLRnzDbGLV/nwRDQIF9PeKDCVmUhwSm n/9PySbF2UfJO09Pzxl5CV0GtwewqYZO/IsOaSaYioAUU6c/SHVVM0P7RoUNAt5C2zCq MDHzfp/q/vjTdQINJ3mJtujgQzGeXkjGufdXH3uUwf+jItEYWJ7BpseM4go8ZMnMpP9A t3ZA== Received: by 10.52.29.70 with SMTP id i6mr7281655vdh.36.1346193356031; Tue, 28 Aug 2012 15:35:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.239.200 with HTTP; Tue, 28 Aug 2012 15:35:35 -0700 (PDT) In-Reply-To: <9DC0C5F7-756F-46B2-9BF0-C6D128DC43D0@ieca.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> <503D325C.80305@cs.tcd.ie> <9DC0C5F7-756F-46B2-9BF0-C6D128DC43D0@ieca.com> From: Tom Ritter Date: Tue, 28 Aug 2012 18:35:35 -0400 Message-ID: To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmAg3Y37bFCwsqBp2M5BxnFR0DfstDSneiXmkD6r7GL5G13XYikykDpfmdrhEIB9EmKHIYV Cc: "wpkops@ietf.org" , Jon Callas Subject: Re: [wpkops] Scope 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, 28 Aug 2012 22:35:58 -0000 On 28 August 2012 17:12, Steingruebl, Andy wrote: > I view this sort of like I view Zalewski's browser security handbook (http://code.google.com/p/browsersec/wiki/Main). On 28 August 2012 18:26, =JeffH wrote: > Additionally, I was about to point to the browser security handbook (BSH) as > perhaps an example of what sort of document(s) wpkops will craft for web pki > -- one(s) featuring tables with rows denoting features/behavior and columns > denoting implementations. Different tables address different topics. > > https://code.google.com/p/browsersec/wiki/Part2 On 28 August 2012 18:26, Sean Turner wrote: > For what it's worth this was one of my primary wants out of this effort. The Browser Security Handbook lists implementations and the observations about those implementations. But this group intends to list observations about implementations, along with hand-waving percentages... with no information about what implementation we're talking about? (I don't have any problem with hand-waving percentages for the record.) We're not scared talking about Browser Security features. And we're not talking about _vulnerabilities_ in hardware devices that would be difficult to patch and leave people vulnerable... It's just everyone seems to clam up when it comes time to say who actually can't support compression or whatever. I know no one is actually trying to perpetuate some sort of coverup - but at the same time *believing* that there's no nefarious purpose and still not seeing any info is pretty frustrating. -tom From stephen.farrell@cs.tcd.ie Tue Aug 28 15:45:55 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 00C3621F8525 for ; Tue, 28 Aug 2012 15:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 kbSS3SyBuHbG for ; Tue, 28 Aug 2012 15:45:54 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 516E521F8523 for ; Tue, 28 Aug 2012 15:45:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B9245171481; Tue, 28 Aug 2012 23:45:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346193953; bh=RN56iqarFyIBH8 bvhWPDTUN8lAFSbjZGWaF9TNv60K0=; b=naZnsP79YNESJ/MZ4KRsCgGANwIaR0 CHHgOVtK0+mJhr0xRTqLX/qd4TZ2kqeOcqODtc68FD5q1ex27MGogymUnGHx98lm bzjlh0pehoR4zNDgh7shXhmpI34UherYRo7FMxs2ip4j8wfpYs5AVdynzwCaNFfF wCekukA8qdBMxpgEVmuuZxz1tphXz56pVaJlFmLFWOrfbDWjBeTAF8baja9BBH5d VVU05w6LEZwL9NZBeyRm6kCKfrjh0dhxIv3epK9p1YuXBIqIVovu/JNyTi2WiLVq MtAHCt0Ty7Tb23EjnUG6HKuUv9gU5eX1ZXn5MVmmgZ1EorunuLrY8wpw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id YSAsYYQ4hbSP; Tue, 28 Aug 2012 23:45:53 +0100 (IST) Received: from [10.87.48.7] (unknown [86.45.56.143]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6C016171474; Tue, 28 Aug 2012 23:45:51 +0100 (IST) Message-ID: <503D4A1F.5040908@cs.tcd.ie> Date: Tue, 28 Aug 2012 23:45:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Tom Ritter References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> <503D325C.80305@cs.tcd.ie> <9DC0C5F7-756F-46B2-9BF0-C6D128DC43D0@ieca.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sean Turner , "wpkops@ietf.org" , Jon Callas Subject: Re: [wpkops] Scope 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, 28 Aug 2012 22:45:55 -0000 On 08/28/2012 11:35 PM, Tom Ritter wrote: > We're not scared talking about Browser Security features. And we're > not talking about _vulnerabilities_ in hardware devices that would be > difficult to patch and leave people vulnerable... It's just everyone > seems to clam up when it comes time to say who actually can't support > compression or whatever. I know no one is actually trying to > perpetuate some sort of coverup - but at the same time *believing* > that there's no nefarious purpose and still not seeing any info is > pretty frustrating. I'm sure there're ways to handle this. And since we're talking about an OPS area WG, other WGs will have figured out ways and means. I've asked a couple of folks, since I don't know myself. Cheers, S. > > -tom > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > > From Jeff.Hodges@KingsMountain.com Tue Aug 28 16:16: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 D1BA011E80E7 for ; Tue, 28 Aug 2012 16:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.534 X-Spam-Level: X-Spam-Status: No, score=-100.534 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 SLppR8zaDXaa for ; Tue, 28 Aug 2012 16:16:51 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 2E61721F84F9 for ; Tue, 28 Aug 2012 16:16:51 -0700 (PDT) Received: (qmail 14075 invoked by uid 0); 28 Aug 2012 23:16:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 28 Aug 2012 23:16:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=zrXPqAOpGK2Ig9AtSMn2Bc3Jf7T0dke6/9eYO8tg5uc=; b=Vg302dPTkZOa85bCfFqOdHUQQFqjsw88+6ivCZ7UMDrvHMQ3T2ioL9ik5qHwXWMWbeRjqm1DRXKaIoa5FPvqWj6zv12CKoOoYEipGPHPkC+2mOugm2B7ttJhF4826Qli; Received: from [216.113.168.128] (port=9029 helo=[10.244.136.52]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T6V1e-0002y8-Bd; Tue, 28 Aug 2012 17:16:50 -0600 Message-ID: <503D5163.4040600@KingsMountain.com> Date: Tue, 28 Aug 2012 16:16:51 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: wpkops@ietf.org, Tom Ritter Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [wpkops] Scope 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, 28 Aug 2012 23:16:52 -0000 > But this group intends to > list observations about implementations, along with hand-waving > percentages... with no information about what implementation we're > talking about? I don't think that that is what Tim was proposing. As AdamL noted, there's various "workarounds" (aka "techniques" as Tim termed them) embedded in various places (user agents and/or servers and/or CA systems and/or certs). Tim, IIUC, is proposing that to spend time documenting a workaround/technique it should be used in at least some baseline number of overall web connections (as a way to attempt to trim the "long tail" of workarounds/techniques and software versions to document). (whose data is used, and the availability thereof, are of course good questions) =JeffH From tim.moses@entrust.com Wed Aug 29 11:48:13 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 380B321F86C4 for ; Wed, 29 Aug 2012 11:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 XlgPThiUTY0K for ; Wed, 29 Aug 2012 11:48:12 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8EA21F86C8 for ; Wed, 29 Aug 2012 11:48:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,335,1344225600"; d="scan'208";a="1816828" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 29 Aug 2012 14:48:11 -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.001; Wed, 29 Aug 2012 14:48:10 -0400 From: Tim Moses To: 'Stephen Farrell' Thread-Topic: [wpkops] Scope Thread-Index: AQHNhS8Wk6F4vhDnQku8ZZoRSxLk2JdvtLIA//+9hNCAAGxmgP//vUpQgABeNQCAAR8GUA== Date: Wed, 29 Aug 2012 18:48:09 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A579115@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A576BC4@SOTTEXCH10.corp.ad.entrust.com> <544B0DD62A64C1448B2DA253C01141460697253A63@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5B68A271B9C97046963CB6A5B8D6F62C3A576DF9@SOTTEXCH10.corp.ad.entrust.com> <5B68A271B9C97046963CB6A5B8D6F62C3A57744A@SOTTEXCH10.corp.ad.entrust.com> <503D325C.80305@cs.tcd.ie> In-Reply-To: <503D325C.80305@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Scope X-BeenThere: wpkops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:48:13 -0000 All - Here's what I had in mind. Tell me if you think it won't work. (Wha= t am I saying? Of course you're going to tell me.) I saw the purpose of this project as "identifying issues" with the way that= the Web PKI works, based on a complete and common understanding. We may h= ave different opinions on which of those issues needs to be addressed and w= ith what priority. But, there will be less room for dispute over whether o= r not the issue exists, or the extent to which it exists. I didn't want to commit to writing requirements unless and until we have th= e enthusiastic participation of the browser and Web server suppliers. With= out their involvement, there is no reason to believe that they would accept= such requirements, or that significant considerations had been omitted or = misunderstood when writing them. Documenting how things "actually" work (I hope) will foster a well-informed= discussion about what works well and what could work better. The discussi= on may occasionally stray into potential solutions. And, while such discus= sions would be out-of-scope, and therefore have to be cut short, it should = be easier to agree what further actions are required. So, in a sense, there are two types of deliverable: the BCP or info RFCs, a= nd the mail-list discussion about what to do next. And, if we are successf= ul, the latter will be the more valuable. All the best. Tim. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Tuesday, August 28, 2012 5:04 PM To: Tim Moses Cc: 'Randy Turner'; wpkops@ietf.org Subject: Re: [wpkops] Scope So in addition, I was hoping this group would document use-cases and requir= ements for new protocols or changes to current protocols if the wg figure s= ome are needed so that we could spin-up short-lived SEC or other WGs as nee= ded. I'm not gonna stamp my feet if folks don't want to do that but I'd hope to = get that kind of output so's we can concentrate on new protocol work in thi= s space that'll be more likely to get adopted. (I would stamp my feet if folks wanted to specify new protocols in this gro= up.) Cheers, S. On 08/28/2012 08:29 PM, Tim Moses wrote: > Hi Randy. That's right. Hopefully, this will be a precursor to fixing s= ome of the issues with the Web PKI. But, step one is to "catalog" what we = have. So, we'll start by producing a set of BCPs that document major aspec= ts of the Web PKI as it is generally practiced today. >=20 > All the best. Tim. >=20 > -----Original Message----- > From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 > Behalf Of Randy Turner > Sent: Tuesday, August 28, 2012 3:26 PM > To: wpkops@ietf.org > Subject: Re: [wpkops] Scope >=20 >=20 > Hi Tim, >=20 > So, in a nutshell (because this is an OPS effort), we're doing to: >=20 > 1. Document existing practice, given the most prevalent products, and=20 > 2. Given existing practice, analyze this existing practice for a set=20 > of BCPs >=20 > Is this correct? >=20 > Thanks! > Randy >=20 > On Aug 28, 2012, at 9:59 AM, Tim Moses wrote: >=20 >> Hi Rick. I completely agree. It's covered in the last paragraph of the= draft charter. In the near future I'll distribute an updated charter prop= osal. All the best. Tim. >> >> -----Original Message----- >> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 >> Behalf Of Rick Andrews >> Sent: Tuesday, August 28, 2012 12:56 PM >> To: Adam Langley; Tim Moses >> Cc: wpkops@ietf.org >> Subject: Re: [wpkops] Scope >> >> Tim, I think the 1% fuzzy threshold is fine. But I really hope that the = sum total of connections that use Web PKI includes mobile browsers and apps= . I've heard anecdotally that mobile represents a large and ever-growing sh= are of web use, and I think it's essential to include it. >> >> -Rick >> >>> -----Original Message----- >>> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On=20 >>> Behalf Of Adam Langley >>> Sent: Tuesday, August 28, 2012 8:09 AM >>> To: Tim Moses >>> Cc: wpkops@ietf.org >>> Subject: Re: [wpkops] Scope >>> >>> On Tue, Aug 28, 2012 at 10:58 AM, Tim Moses wro= te: >>>> Colleagues - As discussed, the idea is to document the Web PKI as=20 >>>> it is >>> practiced today. Generally, that means considering product versions=20 >>> other than the most recent one from each significant supplier. But,=20 >>> in order to keep the workload at a manageable level, we will have to=20 >>> eliminate product versions that are seldom encountered today. >>> Without making reference to specific products and versions, it's=20 >>> tough to come up with an objective criterion for identifying the versio= ns that deserve to be documented. >>> Therefore, I believe we have to rely on experts' judgments. >>>> >>>> As a guide, we might agree that, in order to warrant consideration,=20 >>>> a >>> technique must be involved in more than one percent of connections=20 >>> that use the Web PKI. While we would not attempt to apply this=20 >>> threshold with any precision, contributors may appeal to it in order=20 >>> to justify their exclusion of a particular technique. Then the=20 >>> disputant would be called upon to demonstrate that the technique was mo= re prevalent. >>>> >>>> What do others think? >>> >>> 1% seems reasonable although, if anything, a little high. There are=20 >>> workarounds that apply to less than 1% but are, none the less,=20 >>> important. But any number 0.1%..1% seems sane. >>> >>> >>> Cheers >>> >>> AGL >>> _______________________________________________ >>> wpkops mailing list >>> wpkops@ietf.org >>> https://www.ietf.org/mailman/listinfo/wpkops >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> _______________________________________________ >> wpkops mailing list >> wpkops@ietf.org >> https://www.ietf.org/mailman/listinfo/wpkops >> >=20 > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 From tim.moses@entrust.com Thu Aug 30 08:42:04 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 7867F21F8532 for ; Thu, 30 Aug 2012 08:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.216, 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 MaoPZYqc4PI4 for ; Thu, 30 Aug 2012 08:42:01 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 269A021F8595 for ; Thu, 30 Aug 2012 08:42:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,341,1344225600"; d="scan'208,217";a="6064377" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 30 Aug 2012 11:41:55 -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.001; Thu, 30 Aug 2012 11:41:55 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: Second draft charter proposal Thread-Index: Ac2Gxfw8PmJfmJJLTxGAagHtE7TNSw== Date: Thu, 30 Aug 2012 15:41:54 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A579C1B@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_5B68A271B9C97046963CB6A5B8D6F62C3A579C1BSOTTEXCH10corpa_" MIME-Version: 1.0 Subject: [wpkops] Second draft charter proposal 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, 30 Aug 2012 15:42:04 -0000 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A579C1BSOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colleagues - I have updated the proposed charter to reflect the discussion = (see below). All the best. Tim. The Web PKI is the set of systems and procedures most commonly used to prot= ect the confidentiality, integrity and authenticity of communications betwe= en Web browsers and Web content servers. It first appeared in 1993 or ther= eabouts and has developed continuously in a somewhat organic fashion since = then. Across all the suppliers and the point releases of their products, t= here are now hundreds of variations on the Web PKI in regular use. And thi= s can be a source of problems both for end-users and certificate issuers. 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 refu= se to display the contents under these circumstances. And for 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 se= rver supplies a response that does not include the nonce, it is hard to kno= w 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. But, such a project has to be bounded. There= fore, only behavior encountered in more than 0.1 percent of connections mad= e by desktop and mobile browsers should be considered. While it is not int= ended to apply the threshold with any precision, it may be used to justify = the inclusion or exclusion of a technique. 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 document signing, code sign= ing, and email) may use the same trust anchors and certificate-handling lib= raries as the ones used by the Web. Nevertheless, they may use the results= in a way that is visibly different from the way in which the Web uses them= . Therefore, these applications are explicitly out of scope for the workin= g group. Also, the reliability of the Web PKI depends critically on the practices of= its certificate issuers. However, the topic of practices is outside the s= cope of the IETF. Therefore, this will be left to other competent bodies. That there are technical shortcomings with Web PKI, as it is practiced toda= y, is well recognized. And, that there is also some urgency in addressing = these shortcomings is also well recognized. 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. Milestones =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 pro= cessing" document (12 months). 3. First WG draft of "Web-server / CA communications" document (4 months= ). 4. First WG draft of "certificate revocation" document (8 months). 5. First WG draft of "TLS stack operation" document (8 months). 6. IESG submission of "trust model" document (16 months). 7. IESG submission of "certificate, CRL, and OCSP field and extension pr= ocessing" document (24 months). 8. IESG submission of "Web-server / CA communications" document (16 mont= hs). 9. IESG submission of "certificate revocation" document (20 months). 10. IESG submission of "TLS stack operation" document (16 months). T: +1 613 270 3183 --_000_5B68A271B9C97046963CB6A5B8D6F62C3A579C1BSOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Colleagues – I have updated the proposed charter to reflect the discussio= n (see below).  All the best.  Tim.

 

The Web PKI is the set of systems and procedures most co= mmonly used to protect the confidentiality, integrity and authenticity of c= ommunications between Web browsers and Web content servers.  It first = appeared in 1993 or thereabouts and has developed continuously in a somewhat organic fashion since then.  Acr= oss all the suppliers and the point releases of their products, there are n= ow hundreds of variations on the Web PKI in regular use.  And this can= be a source of problems both for end-users and certificate issuers.

 

For end-users, there is no clear view whether certificat= e "problems" remain when they see indication of a "good"= ; connection.  For instance, in some browsers, a "good" indi= cation may be displayed when a "revoked" response has been receiv= ed and "accepted" by the user.  Whereas, other browsers may refuse= to display the contents under these circumstances.

 

And for issuers, it can be difficult to predict what pro= portion 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 server supplies a response that does not include the nonce, it is hard to know which browser= s will accept and which will reject the response.

 

Starting from the premise that more consistency in Web s= ecurity behavior is desirable, a natural first step would be to document cu= rrent and historic browser and server behavior.  But, such a project h= as to be bounded.  Therefore, only behavior encountered in more than 0.1 percent of connections made by desktop and mo= bile browsers should 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 technique.

 

Future activities may attempt to prescribe how the Web P= KI "should" work, and the prescription may turn out to be a prope= r 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 t= he set of browsers and servers that are in common use today.

 

Additionally, a number of applications (such as document= signing, code signing, and email) may use the same trust anchors and certi= ficate-handling libraries as the ones used by the Web.  Nevertheless, = they may use the results in a way that is visibly different from the way in which the Web uses them.  Theref= ore, these applications are explicitly out of scope for the working group.<= o:p>

 

Also, the reliability of the Web PKI depends critically = on the practices of its certificate issuers.  However, the topic of pr= actices is outside the scope of the IETF.  Therefore, this will be lef= t to other competent bodies.

 

That there are technical shortcomings with Web PKI, as i= t is practiced today, is well recognized.  And, that there is also som= e urgency in addressing these shortcomings is also well recognized.  B= ut, 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 s= ystematic way, aspects of the Web PKI that should be progressed in future w= orking groups of the IETF's Security Area, and that suppliers will be willi= ng to participate in those working groups and modify their products to comply with their standards.

 

Given the urgency of the required developments and the s= cale of the task, it is agreed that adherence to the published schedule sho= uld take precedence over completeness of the results.

 

Milestones

=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 "Web-server / CA communicati= ons" document (4 months).

4.    First WG draft of "certificate revocation"= ; document (8 months).

5.    First WG draft of "TLS stack operation" d= ocument (8 months).

6.    IESG submission of "trust model" document= (16 months).

7.    IESG submission of "certificate, CRL, and OCSP= field and extension processing" document (24 months).

8.    IESG submission of "Web-server / CA communicat= ions" document (16 months).

9.    IESG submission of "certificate revocation&quo= t; document (20 months).

10. IESG submission of "TLS stack operation" = document (16 months).

 

 

 

T: +1 613 270 3183

 

--_000_5B68A271B9C97046963CB6A5B8D6F62C3A579C1BSOTTEXCH10corpa_-- From carl@redhoundsoftware.com Thu Aug 30 09:18:18 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 C8E0721F853D for ; Thu, 30 Aug 2012 09:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2C6F8k8dovH for ; Thu, 30 Aug 2012 09:18:18 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C739921F84C4 for ; Thu, 30 Aug 2012 09:18:17 -0700 (PDT) Received: by qcac10 with SMTP id c10so1615232qca.31 for ; Thu, 30 Aug 2012 09:18:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=s7redu2/8QIDapD1yk6IQy9tFEvlL1IdOpR7woLHcy4=; b=CU86aBNk7F7uvGDcQVDuxeMfr53WObqhNpNtl23KYJwVet/AJObPeWxBG7r4OeSucd R7uwDA3c778ynnM8hYFwZnqBzDmoaNKs9WaieQcJQlH6mLnDBlp3Au9Lj7IzbvdCyUrR 7UxtN46s11H5OaER3xqIhCP541vFrgyL+6reCYyI+PjblsNrPtr5J9xuRanRUoHddWoH oiJLhOFLhfc0ZtDlyadxMX28d0Sk5TGQ+mcKz0FFrgNhdN+RHCQW2yI0CIX0ICPITcyZ M+7uohGA+bttZXXEwiMm8N6wWkEFCBWqh1G6WPuMESzmxGjGQHnY6gBGLusRKPa76BTK ObNg== Received: by 10.224.174.134 with SMTP id t6mr12141428qaz.90.1346343497197; Thu, 30 Aug 2012 09:18:17 -0700 (PDT) Received: from [192.168.1.5] (pool-71-191-137-227.washdc.fios.verizon.net. [71.191.137.227]) by mx.google.com with ESMTPS id gt4sm2923324qab.21.2012.08.30.09.18.14 (version=SSLv3 cipher=OTHER); Thu, 30 Aug 2012 09:18:15 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 30 Aug 2012 12:18:12 -0400 From: Carl Wallace To: Tim Moses , "wpkops@ietf.org" Message-ID: Thread-Topic: [wpkops] Second draft charter proposal In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A579C1B@SOTTEXCH10.corp.ad.entrust.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Gm-Message-State: ALoCoQnkA4rxDkL8RaIWEWA3hqEKphGTNGnoTYwgxMu7zAPaxfOl5cBuHlsrHWRd5yaft2dg2q5Z Subject: Re: [wpkops] Second draft charter proposal 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, 30 Aug 2012 16:18:18 -0000 Inline=8A From: Tim Moses Date: Thursday, August 30, 2012 11:41 AM To: "wpkops@ietf.org" Subject: [wpkops] Second draft charter proposal >Colleagues=20 >=AD I have updated the proposed charter to reflect the discussion (see >below). All the best. Tim. >=20 >The Web PKI is the set of systems and procedures most commonly used to >protect the confidentiality, integrity and authenticity of communications >between Web browsers and Web content servers. It 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 >hundreds of variations on the Web PKI in regular use. And this can be a >source of problems both for end-users > and certificate issuers. >=20 >For end-users, there is no clear view whether certificate "problems" >remain when they see indication of a "good" connection. For instance, in >some browsers, 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. > > > >=20 >And for 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 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. > > > Is client authentication processing performed by web servers in scope? If not, explicitly push that out of scope. > >=20 >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. But, such a project has to be >bounded. Therefore, only 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 justify the inclusion >or exclusion of a technique. >=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. > > > Why are so many words quoted here and in the second paragraph? > >=20 >Additionally, a number of applications (such as document signing, code >signing, and email) may use the same trust anchors and >certificate-handling libraries as the ones used by the Web. >Nevertheless, they may use the results in a way that > is visibly different from the way in which the Web uses them. >Therefore, these applications are explicitly out of scope for the working >group. > > > I'd like to see the charter include identification of overlap between the Web PKI and other applications as in scope. As written, it's not clear this information will be captured. Any BCP resulting from this effort can't ignore impact on other applications (even if those applications are not in scope for this effort). > >=20 >Also, the reliability of the Web PKI depends critically on the practices >of its certificate issuers. However, the topic of practices is outside >the scope of the IETF. Therefore, this will be left to other competent >bodies. >=20 >That there are technical shortcomings with Web PKI, as it is practiced >today, is well recognized. And, that there is also some urgency in >addressing these shortcomings is also well recognized. 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. >=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. >=20 >Milestones >=3D=3D=3D=3D=3D=3D=3D=3D >=20 >1. =20 >First WG draft of "trust model" document (4 months). >2. =20 >First WG draft of "certificate, CRL, and OCSP field and extension >processing" document (12 months). >3. =20 >First WG draft of "Web-server / CA communications" document (4 months). >4. =20 >First WG draft of "certificate revocation" document (8 months). >5. =20 >First WG draft of "TLS stack operation" document (8 months). >6. =20 >IESG submission of "trust model" document (16 months). >7. =20 >IESG submission of "certificate, CRL, and OCSP field and extension >processing" document (24 months). >8. =20 >IESG submission of "Web-server / CA communications" document (16 months). >9. =20 >IESG submission of "certificate revocation" document (20 months). >10.IESG submission of "TLS stack operation" document (16 months). >=20 >=20 >=20 >T: +1 613 270 3183 >=20 > > > >_______________________________________________ >wpkops mailing list >wpkops@ietf.orghttps://www.ietf.org/mailman/listinfo/wpkops From joncallas@me.com Thu Aug 30 09:28:54 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 990FF21F84DA for ; Thu, 30 Aug 2012 09:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6ecDFscGj8p for ; Thu, 30 Aug 2012 09:28:54 -0700 (PDT) Received: from st11p01mm-asmtp001.mac.com (st11p01mm-asmtp001.mac.com [17.172.204.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55521F8518 for ; Thu, 30 Aug 2012 09:28:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [172.16.1.217] (23-24-110-141-static.hfc.comcastbusiness.net [23.24.110.141]) by st11p01mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0M9K003W3TROU200@st11p01mm-asmtp001.mac.com> for wpkops@ietf.org; Thu, 30 Aug 2012 16:28:40 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-08-30_04:2012-08-30, 2012-08-30, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208300140 From: Jon Callas In-reply-to: Date: Thu, 30 Aug 2012 09:28:36 -0700 Message-id: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> References: To: wpkops@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [wpkops] Second draft charter proposal 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, 30 Aug 2012 16:28:54 -0000 On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: >> And for 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 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. >> >> >> > > Is client authentication processing performed by web servers in scope? If > not, explicitly push that out of scope. It would be nice if it were in scope. Client authorization is a vastly under-used feature. I wouldn't want to endanger everything else over it, but if we keep sweeping it under the rug, it will continue to languish. Jon From dkg@fifthhorseman.net Thu Aug 30 09:28:56 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 8ED5421F8574 for ; Thu, 30 Aug 2012 09:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 9fnJFI1yEgyt for ; Thu, 30 Aug 2012 09:28:55 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 80EF721F84DA for ; Thu, 30 Aug 2012 09:28:55 -0700 (PDT) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 37B9CF970; Thu, 30 Aug 2012 12:28:52 -0400 (EDT) Message-ID: <503F94BB.4030203@fifthhorseman.net> Date: Thu, 30 Aug 2012 12:28:43 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: Tim Moses References: <5B68A271B9C97046963CB6A5B8D6F62C3A579C1B@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A579C1B@SOTTEXCH10.corp.ad.entrust.com> X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigD95751E7A192770473086A19" Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Second draft charter proposal 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, 30 Aug 2012 16:28:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD95751E7A192770473086A19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/30/2012 11:41 AM, Tim Moses wrote: > And for issuers, it can be difficult to predict what proportion of the = user population will accept a certificate chain with certain characterist= ics. For instance, when a browser includes a nonce in an OCSP request bu= t the server supplies a response that does not include the nonce, it is h= ard to know which browsers will accept and which will reject the response= =2E This is stated as a concern primarily for issuers, but it is arguably more of a concer for certificate holders than for issuers, if i'm reading it correctly. There are 4 parties involved in web pki fwict: * web clients (mostly the users of web browsers, as far as i can make out in this proposaL) * certificate issuers * software developers and vendors * certificate holders The charter proposal here speaks directly to the first three categories, but doesn't seem to explicitly address the last category. Is it worth mentioning them explicitly? Also, i wonder about the scoping of web clients specifically to the users of browsers. While this is convenient for discussion, web protocols are used heavily as transport backends and automated contexts as well. For example, HTTPS is required for CALDAV; it's used by many RSS feedreaders; and it's used as a backend transport for federated messaging systems. Currently, i think the clarification about "other applications are explicitly out of scope" a bit ambiguous, because it's not clear where to draw the line between, say, S/MIME e-mail certificates (clearly out of scope) and a human in front of a web browser (clearly in-scope). should that line be more clearly drawn? Regards, --dkg --------------enigD95751E7A192770473086A19 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJQP5S7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpAmAP/RwnviPTCEfwD0Y1XJni3wc4 svQkw1lK7kprsFeVv7Ie25Rnks4F87Sn04uMUpv+qDoVoqr3cKWxsn743cPKiXnA Jaqr7ti8TZQEcdMYOr1yhfjrIoAlPfJVSVm3QnHZ8gS9p2Nr4nxzObVE+OWadBIi P0QDwFKMBgYSvu1R/rFYYMAY0rvYNP//ZWqbQoS/DRDa5UwgigVF+IuosYBqfN1n R4QNdloCyz+ZBEv2nEp5tkdr1LnYFJYyZ9pTBVI9D1Un0d0traFIS2c+25G4EQuE 3xiuXypFdPpdvcLsfbRzDedj7Er0UqABhji62jwtc9x1ZP3UWVBura0/wRtlBI64 tm9JllxfT/8qxEBPs2LpndO03gc+0guDGlWWFViiFlO2OW99Gl0nueTRlE6Ez+ra AHkMVJsJR3UdcajT6EHKP1aldT4GoOOQmkBkPFujlilr94p9GTmWRX7x4ZmgPWcQ Azd81n60AXd2pCMJc4IZKze6x5Is5eNal3MPcFAzyzv+pCeNxhazPWxxmRAnmFz8 te2BiQLypfebqPn0raP6V9hrJHua0qb8MhP6x3Ss4oBraOORba0HiQUZ3Ur8Nj5c fBsMkecfu800NCzKMrND307jnehvnJln5iev/iyeEyoH0z6HNegkV0CjQpkxvima WYGjQnR5V5J/9M+B4YZK =oLEv -----END PGP SIGNATURE----- --------------enigD95751E7A192770473086A19-- From carl@redhoundsoftware.com Thu Aug 30 09:31: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 075F621F85B4 for ; Thu, 30 Aug 2012 09:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aETmiHDXv2Ww for ; Thu, 30 Aug 2012 09:31:13 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6951F21F8574 for ; Thu, 30 Aug 2012 09:31:13 -0700 (PDT) Received: by qan41 with SMTP id 41so340953qan.10 for ; Thu, 30 Aug 2012 09:31:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=5C1L2QPRaFLKQW6RcwjxCkzQr2chqXBHPPdRGUMNxPs=; b=LBs1U4Gh6ts2nJd3Oxe9AtUA86S6u7UL0RE0GbtOrT+yoZ6vexnZHyJfOURq5sq6sM XBMESTvpx8WKeIz2FU5v/Ls68JtmoQsNEgUyiKbYltdfBtX9FsUH3z78KDmqtQMID9U9 c991Rc8udEosdcEXPWiVNSS9sykHvonvug03fo3lpNUA0opyQ/T6LEYoMKGsLOVNnEKW ruRq/2D9UQemXPsvxP+d1IQcapnFM7ZLUbTeVWpjMJ01LEg8ntDqtndaQlUD0hGNTHJP aJKYVgkirdiprvRg5byZ5lZstfxtB/4Vm5kst97SeNPNDO1Q2xpxTKhQh2Czj85TOpAq cO/g== Received: by 10.224.174.145 with SMTP id t17mr12385389qaz.0.1346344272144; Thu, 30 Aug 2012 09:31:12 -0700 (PDT) Received: from [192.168.1.5] (pool-71-191-137-227.washdc.fios.verizon.net. [71.191.137.227]) by mx.google.com with ESMTPS id ca8sm2948089qab.20.2012.08.30.09.31.09 (version=SSLv3 cipher=OTHER); Thu, 30 Aug 2012 09:31:11 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 30 Aug 2012 12:31:07 -0400 From: Carl Wallace To: Jon Callas , Message-ID: Thread-Topic: [wpkops] Second draft charter proposal In-Reply-To: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnKRTBWczyuRFq32JHHLH1S/061u2jTQiJxH798mJGJ+H6lanUVDkjg4mnPx7Sn74tuUsLH Subject: Re: [wpkops] Second draft charter proposal 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, 30 Aug 2012 16:31:14 -0000 On 8/30/12 12:28 PM, "Jon Callas" wrote: >On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: > >>> And for 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 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. >>> >>> >>> >> >> Is client authentication processing performed by web servers in scope? >>If >> not, explicitly push that out of scope. > >It would be nice if it were in scope. Client authorization is a vastly >under-used feature. > >I wouldn't want to endanger everything else over it, but if we keep >sweeping it under the rug, it will continue to languish. I agree and would like to see it stay in scope as well. From anders.rundgren@telia.com Thu Aug 30 09:50: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 D661821F852C for ; Thu, 30 Aug 2012 09:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om77XfPDf+si for ; Thu, 30 Aug 2012 09:50:11 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id EC52521F852B for ; Thu, 30 Aug 2012 09:50:10 -0700 (PDT) Received: from [192.168.0.203] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 503A691C001C12B3; Thu, 30 Aug 2012 18:50:06 +0200 Message-ID: <503F99BA.2060503@telia.com> Date: Thu, 30 Aug 2012 18:50:02 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Carl Wallace References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: wpkops@ietf.org, Jon Callas Subject: [wpkops] Client-auth. Was: Second draft charter proposal 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, 30 Aug 2012 16:50:12 -0000 On 2012-08-30 18:31, Carl Wallace wrote: > On 8/30/12 12:28 PM, "Jon Callas" wrote: > >> On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: >> >>>> And for 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 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. >>>> >>>> >>>> >>> >>> Is client authentication processing performed by web servers in scope? >>> If >>> not, explicitly push that out of scope. >> >> It would be nice if it were in scope. Client authorization is a vastly >> under-used feature. >> >> I wouldn't want to endanger everything else over it, but if we keep >> sweeping it under the rug, it will continue to languish. > > I agree and would like to see it stay in scope as well. I'm not sure what client authorization and WebPKI has in common. Are you rather to for for example TLS client-certificate-authentication? Anders > > > _______________________________________________ > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops > From Jeff.Hodges@KingsMountain.com Thu Aug 30 16:27:49 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 798BD21F8455 for ; Thu, 30 Aug 2012 16:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.532 X-Spam-Level: X-Spam-Status: No, score=-100.532 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 BFxrUJXDnP4f for ; Thu, 30 Aug 2012 16:27:49 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id D852021F8449 for ; Thu, 30 Aug 2012 16:27:48 -0700 (PDT) Received: (qmail 22716 invoked by uid 0); 30 Aug 2012 23:27:47 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy11.bluehost.com with SMTP; 30 Aug 2012 23:27:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=sElVYgyogXAuVTszgQHIYqBUOy9aUHwMgIaoNxFHYDs=; b=5Y6xUB2xuQAv+90obaJSVtv7u56TbcqSSVcMQA/rZaYpFq71pr1A55YJpV76Nfm2tWHzz6I6KbcBqsW4g/fZEi7toOKEbk897u+XbU1Lm4TeE2rMHvGFzlmhcZbj+NG9; Received: from [216.113.168.128] (port=44097 helo=[10.244.137.246]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T7E9L-0002zS-Ow for wpkops@ietf.org; Thu, 30 Aug 2012 17:27:47 -0600 Message-ID: <503FF7BC.2070705@KingsMountain.com> Date: Thu, 30 Aug 2012 16:31:08 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: wpkops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [wpkops] Second draft charter proposal 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, 30 Aug 2012 23:27:49 -0000 a detail-level comment: > Also, the reliability of the Web PKI depends critically on the practices of > its certificate issuers. However, the topic of practices is outside the > scope of the IETF. Therefore, this will be left to other competent bodies. "practices of ... certificate issuers" needs to be clearly defined in order to disambiguate between, e.g., verification of certificate issuance requester and CA infrastructure operational practices. My understanding is that this scope declaration is intended to exclude the former and not necessarily the latter, but this isn't clear. HTH, =JeffH From tim.moses@entrust.com Fri Aug 31 08:26:00 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 4111821F8648 for ; Fri, 31 Aug 2012 08:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 wJHcOIFa4Je9 for ; Fri, 31 Aug 2012 08:25:56 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53621F8658 for ; Fri, 31 Aug 2012 08:25:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,347,1344225600"; d="scan'208";a="6076339" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 31 Aug 2012 11:25:52 -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.001; Fri, 31 Aug 2012 11:25:52 -0400 From: Tim Moses To: '=JeffH' Thread-Topic: [wpkops] Second draft charter proposal Thread-Index: AQHNhweIPmJfmJJLTxGAagHtE7TNS5d0ByQg Date: Fri, 31 Aug 2012 15:25:51 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A57B2DE@SOTTEXCH10.corp.ad.entrust.com> References: <503FF7BC.2070705@KingsMountain.com> In-Reply-To: <503FF7BC.2070705@KingsMountain.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wpkops@ietf.org" Subject: Re: [wpkops] Second draft charter proposal 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, 31 Aug 2012 15:26:00 -0000 Hi Jeff. I was thinking that "both" aspects of practices should be outside= the scope of an IETF activity. The CA/Browser Forum is working on these w= ith the co-operation of the root-program operators and the relevant audit e= xperts (ETSI and WebTrust). I think that best value is obtained from the I= ETF community by focusing on technical protocols. No? All the best. Tim. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= =3DJeffH Sent: Thursday, August 30, 2012 7:31 PM To: wpkops@ietf.org Subject: Re: [wpkops] Second draft charter proposal a detail-level comment: > Also, the reliability of the Web PKI depends critically on the practices= of > its certificate issuers. However, the topic of practices is outside= the > scope of the IETF. Therefore, this will be left to other competent= bodies. "practices of ... certificate issuers" needs to be clearly defined in order= to disambiguate between, e.g., verification of certificate issuance reques= ter and CA infrastructure operational practices. My understanding is that this scope declaration is intended to exclude the = former and not necessarily the latter, but this isn't clear. HTH, =3DJeffH _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops From tim.moses@entrust.com Fri Aug 31 08:52:20 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 24F2221F86B9 for ; Fri, 31 Aug 2012 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 lz5x9hfWDUEw for ; Fri, 31 Aug 2012 08:52:19 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7044321F86B8 for ; Fri, 31 Aug 2012 08:52:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,347,1344225600"; d="scan'208";a="1833963" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 31 Aug 2012 11:52:18 -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.001; Fri, 31 Aug 2012 11:52:18 -0400 From: Tim Moses To: "wpkops@ietf.org" Thread-Topic: [wpkops] Second draft charter proposal Thread-Index: Ac2Gxfw8PmJfmJJLTxGAagHtE7TNSwAJpfwAAABc+wAAABaBgAAoCViw Date: Fri, 31 Aug 2012 15:52:17 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A57B344@SOTTEXCH10.corp.ad.entrust.com> References: <37FAC45A-304E-48A8-B294-A0C3F465FDAA@me.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [wpkops] Second draft charter proposal 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, 31 Aug 2012 15:52:20 -0000 All - I have no fundamental objection to expanding the scope in the ways su= ggested. It's true that the original idea was to limit the scope to server-auth to W= eb browsers. That's because vulnerabilities have been demonstrated and the= impact can clearly be severe. Do those conditions exist for client-auth a= nd CalDAV? If not, I might assign them lower priority. On the other hand, if they impact the workload by no more than (say) 10%, w= hy wouldn't we include them? I think it's important to remember that increased workload must be borne no= t just by the editors but also by the reviewers (every subscriber to the ma= il-list). All the best. Tim. -----Original Message----- From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On Behalf Of= Carl Wallace Sent: Thursday, August 30, 2012 12:31 PM To: Jon Callas; wpkops@ietf.org Subject: Re: [wpkops] Second draft charter proposal On 8/30/12 12:28 PM, "Jon Callas" wrote: >On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote: > >>> And for issuers, it can be difficult to predict what proportion of=20 >>> the user population will accept a certificate chain with certain=20 >>> characteristics. For instance, when a browser includes a nonce in=20 >>> an OCSP request but the server supplies a response that does not=20 >>> include the nonce, it is hard to know which browsers will accept and=20 >>> which will reject the response. >>>=20 >>>=20 >>>=20 >>=20 >> Is client authentication processing performed by web servers in scope? >>If >> not, explicitly push that out of scope. > >It would be nice if it were in scope. Client authorization is a vastly=20 >under-used feature. > >I wouldn't want to endanger everything else over it, but if we keep=20 >sweeping it under the rug, it will continue to languish. I agree and would like to see it stay in scope as well. =20 _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops