Re: [wpkops] Third draft charter proposal

[Stephen Farrell <[e-mail]>]

While I have comments on this version, I personally
think its almost-baked so should be fine for the BoF
approval call.

S

On 09/17/2012 04:48 PM, Ronald Bonica wrote:
> 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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Stephen Farrell
>> Sent: Saturday, September 15, 2012 1:35 PM
>> To: Tim Moses
>> Cc: [e-mail]
>> 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: [phone]
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wpkops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/wpkops
>>>
>> _______________________________________________
>> wpkops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/wpkops
> _______________________________________________
> wpkops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wpkops
> 
>