Re: [wpkops] Third draft charter proposal

Tim Moses <tim.moses@entrust.com> Mon, 17 September 2012 17:18 UTC

Return-Path: <tim.moses@entrust.com>
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 5DC2221F8526 for <wpkops@ietfa.amsl.com>; Mon, 17 Sep 2012 10:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.326
X-Spam-Level:
X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 cgPZmXYvrWDe for <wpkops@ietfa.amsl.com>; Mon, 17 Sep 2012 10:18:31 -0700 (PDT)
Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id E430A21F867C for <wpkops@ietf.org>; Mon, 17 Sep 2012 10:18:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,437,1344225600"; d="scan'208";a="1962983"
Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 17 Sep 2012 13:18: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; Mon, 17 Sep 2012 13:18:15 -0400
From: Tim Moses <tim.moses@entrust.com>
To: 'Ronald Bonica' <rbonica@juniper.net>
Thread-Topic: [wpkops] Third draft charter proposal
Thread-Index: Ac2TWy5Wt+5+AKCyQmSih2MU3O89AQALtceAAGDaMQAABUxZ4A==
Date: Mon, 17 Sep 2012 17:18:14 +0000
Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A58738B@SOTTEXCH10.corp.ad.entrust.com>
References: <5B68A271B9C97046963CB6A5B8D6F62C3A5862E7@SOTTEXCH10.corp.ad.entrust.com> <5054BC5F.5080107@cs.tcd.ie> <13205C286662DE4387D9AF3AC30EF456D7834D9FB4@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7834D9FB4@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "wpkops@ietf.org" <wpkops@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [wpkops] Third draft charter proposal
X-BeenThere: wpkops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <wpkops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpkops>, <mailto:wpkops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/wpkops>
List-Post: <mailto:wpkops@ietf.org>
List-Help: <mailto:wpkops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpkops>, <mailto:wpkops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Sep 2012 17:18:32 -0000

Hi Ron.  I have written up a BoF proposal/application and it is with Steve Hanna for his consideration.  I'll forward it to you as soon as I hear back from Steve.  All the best.  Tim.

-----Original Message-----
From: Ronald Bonica [mailto:rbonica@juniper.net] 
Sent: Monday, September 17, 2012 11:49 AM
To: Stephen Farrell; Tim Moses
Cc: wpkops@ietf.org
Subject: RE: [wpkops] Third draft charter proposal

Folks,

On September 26, the IAB and IESG will review BoF proposals. Would it be OK if I included this version of the charter proposal in the BoF proposal?

                                          Ron


> -----Original Message-----
> From: wpkops-bounces@ietf.org [mailto:wpkops-bounces@ietf.org] On 
> Behalf Of Stephen Farrell
> Sent: Saturday, September 15, 2012 1:35 PM
> To: Tim Moses
> Cc: wpkops@ietf.org
> Subject: Re: [wpkops] Third draft charter proposal
> 
> 
> Hi Tim,
> 
> That looks pretty good to me. Some comments below.
> 
> On 09/15/2012 05:00 PM, Tim Moses wrote:
> > Colleagues - Here is a third draft of the WPKOPS charter proposal.
> It attempts to accommodate comments received on the second draft.
> >
> > The other major change is that I have deleted the proposal for a
> draft on communications between the certificate-holder and the 
> certificate issuer.  This was included originally to ensure that we 
> didn't lose sight of the role of the Web server in the "stapling"
> process.  But, I think this can be dealt with in the "certificate 
> revocation" document.
> >
> > Equally to the point, I have received commitments from individuals 
> > to
> act as the primary editors for the remaining documents.  Rick Andrews 
> from Symantec with Scott Rea and Ben Wilson from DigiCert have offered 
> to tackle certificate revocation, Ben Wilson and colleagues from 
> DigiCert have offered to tackle the behavior of the certificate using 
> product, and Adam Langley of Google has volunteered to edit the draft 
> on TLS stack operation.
> >
> > I am looking for others to volunteer to assist in an editing role.
> Please let me know as soon as you possibly can and I'll put you in 
> touch with the editors that have already been identified.
> >
> > 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 
> for end-users, certificate holders, 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.
> >
> > Certificate holders may have difficulty understanding whether some
> browser versions will reject their certificate if certain content 
> specifications are not met, such as a subject public key that does not 
> satisfy a minimum key size, or a certificate policies extension that 
> does not contain a particular standard policy identifier.
> >
> > 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.  But, such a project 
> has to be bounded.  Therefore, only server-authentication behavior 
> encountered in more than 0.1 percent of connections made by desktop 
> and mobile browsers should be considered.  While it is not 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 PKI "should"
> work, and the prescription may turn out to be a proper subset of the 
> PKIX PKI.  However, that task is explicitly not a goal of the proposed 
> working group.  Instead, the group's goal is merely to describe how 
> the Web PKI "actually" works in the set of browsers and servers that 
> are in common use today.
> >
> > Additionally, a number of applications (such as client
> authentication, document signing, code signing, and email) may use the 
> same trust anchors and certificate-handling libraries as the ones used 
> for server authentication on the Web.  Nevertheless, they may use the 
> results in a way that is visibly different from the way in which they 
> are used for server authentication.  While these applications are 
> considered outside the scope of this working group, deliverables 
> should (wherever practical within the available expertise and time) 
> identify other applications that exhibit identical behavior and 
> identify the implications of that behavior where they differ from 
> those for server authentication.
> >
> > Also, the reliability of the Web PKI depends critically on the
> practices of its certificate issuers; practices such as: how the 
> contents of certificate applications are verified and how access (both 
> direct and indirect) to the CA's private key is controlled.  However, 
> the topic of practices is considered outside the scope of the working 
> group.
> 
> I think that last sentence is problematically ambiguous. I suspect 
> that the term "practice" has evolved into something well defined for 
> CAB forum members but I don't think its well understood in the IETF. 
> If you don't make this more precise, in terms understood in the IETF 
> context, I suspect the WG might have recurring friction about what is 
> or is not in scope.
> 
> Some examples of what's in/out of scope might help the discussion here 
> I reckon.
> 
> > This topic will be left to other competent bodies, such as the
> CA/Browser Forum [1][2].
> 
> I think that sentence wouldn't be needed if the previous one were well 
> enough defined. I also think that since CAB forum's constitution is in 
> flux it'd be better to just not mention it in the charter.
> 
> >
> > 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.
> 
> I sympathise with that, but it needs to be understood (e.g. by folks 
> new to the IETF) that the usual IETF processes do apply and the WG 
> doesn't get to override those. That means that technically correct and 
> relevant comments can be a showstopper at any point for example. I 
> don't know if that needs different text, but it needs to be understood.
> 
> > Milestones
> > ==========
> 
> I think these deliverables need to be better characterised in the text 
> above, e.g. its not clear that the "trust model" document is meant 
> only to document the existing trust model(s) that are in use in 
> non-trivial deployments.
> 
> I'm also not sure if this is the right structure for the set of 
> documents you want to produce, e.g. whether or not its better to 
> separate trust models from the processing of e.g. issuer, subject and 
> SPKI fields, nor whether it makes sense to discuss OCSP in one 
> document but revocation in another.
> 
> So I think a bit more discussion on that is needed.
> 
> Cheers,
> S.
> 
> >
> > 1.    First WG draft of "trust model" document (4 months).
> > 2.    First WG draft of "certificate, CRL, and OCSP field and
> extension processing" document (12 months).
> > 3.    First WG draft of "certificate revocation" document (8 months).
> > 4.    First WG draft of "TLS stack operation" document (8 months).
> > 5.    IESG submission of "trust model" document (16 months).
> > 6.    IESG submission of "certificate, CRL, and OCSP field and
> extension processing" document (24 months).
> > 7.    IESG submission of "certificate revocation" document (20
> months).
> > 8.    IESG submission of "TLS stack operation" document (16 months).
> >
> >
> > References:
> >
> > [1]   Network and certificate system security requirements,
> CA/Browser Forum, Aug 2012,
> https://www.cabforum.org/Network_Security_Controls_V1.pdf
> >
> > [2]   Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Certificates Version 1.0, CA/Browser Forum, Nov 2011, 
> https://www.cabforum.org/Baseline_Requirements_V1.pdf
> >
> >
> >
> >
> > T: +1 613 270 3183
> >
> >
> >
> >
> > _______________________________________________
> > wpkops mailing list
> > wpkops@ietf.org
> > https://www.ietf.org/mailman/listinfo/wpkops
> >
> _______________________________________________
> wpkops mailing list
> wpkops@ietf.org
> https://www.ietf.org/mailman/listinfo/wpkops