Subject: Re: [wpkops] Second draft charter proposal

From: Carl Wallace <[email-masked]>
Date: Tue, 04 Sep 2012 14:11:28 -0400

That sounds fair enough.  My request was that if client auth was not in
scope that it be explicitly called out as out of scope.  I'm more
interested in seeing documentation of the overlap/reuse of Web PKI
components for enterprise and non-browser purposes being included as in
scope since this is often a source of pain.

On 9/4/12 12:28 PM, "Phillip Hallam-Baker" <[email-masked]> wrote:

>I would like to see us 'do' something 'about' client authentication.
>
>But I don't see much of a client PKI out there to be operated, I think
>we are going to have to 'build stuff' to fix it. So I don't think its
>a PKI operations issue.
>
>I would prefer to see a separate, security area WG to look into the
>client ops side. In particular I don't want to spend time trying to
>work out how to automate the 'certificate lifecycle' premised on the
>idea that client certs expire on an annual basis in a group where we
>can't ask why the cert has to expire.
>
>On Thu, Aug 30, 2012 at 12:31 PM, Carl Wallace
><[email-masked]> wrote:
>> On 8/30/12 12:28 PM, "Jon Callas" <[email-masked]> 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.
>>
>>
>> _______________________________________________
>> wpkops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/wpkops
>
>
>
>-- 
>Website: http://hallambaker.com/
>

---

From: =JeffH <[email-masked]>
Date: Wed, 05 Sep 2012 13:35:53 -0700

Tim replied..
 >
 > I'd said..
 >>
 >> 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.
 >
 > I was thinking that "both" aspects of practices should be outside the scope
 > of an IETF activity.

Maybe so, at least for now.

Although, the term "practices" in the draft charter should be defined, and refs 
to the relevant (technical) CA/Browser Forum (CABF) documents included, which 
are it seems..

https://www.cabforum.org/Network_Security_Controls_V1.pdf

https://www.cabforum.org/Baseline_Requirements_V1.pdf

https://www.cabforum.org/Guidelines_v1_4.pdf

https://www.cabforum.org/Guidelines_for_the_processing_of_EV_certificates%20v1_0.pdf

(note that some IETF working group charters do contain refs to various docs for 
context-setting purposes)

 > The CA/Browser Forum is working on these with the
 > co-operation of the root-program operators and the relevant audit experts
 > (ETSI and WebTrust). I think that best value is obtained from the IETF
 > community by focusing on technical protocols.  No?

Just to note, the IETF Ops Area has explicitly specified infrastructural 
operational "practices" in at least two cases, see for example..

DNSSEC Operational Practices
https://datatracker.ietf.org/doc/rfc4641/

Current Operational Security Practices in Internet Service Provider Environments
https://datatracker.ietf.org/doc/rfc4778/

HTH,

=JeffH