[cabfpub] Issuers in BR/EV/EVCS Guideline Scope

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Mon Apr 18 17:30:35 UTC 2016

Ryan, while I certainly remember various discussions from time to time about the proper scope of the Forum’s work, my recollection is that typically one or two people have strong opinions one way, one or two have opinions the other way, and most people are silent.  So we have never had a comprehensive discussion, and have never reached consensus on how to change the BRs or our Bylaws on the Forum’s scope.  Perhaps this is the right time.

In my view, the best way to reach consensus and move forward is to start with the known use cases where this has come up as an issue – such as code signing, or certs from non-trusted roots, etc.  All the past use cases (and some additional use cases that might come up in the future) could be listed with the pros and cons of including them within the scope of the Forum’s work listed for each.  We can then discuss to see if there is consensus for each.  Once we reach consensus, drafting the BR changes should be easy, and a ballot will sell itself.  If there is no consensus, there’s probably no reason to move forward with a ballot.

Dean has asked for Agenda items for the face to face meeting next month, and this seems like a perfect one.  Between now and then, we can work up a list of use cases for consideration, with pros and cons, and then have a useful discussion in Bilbao.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Sunday, April 17, 2016 3:43 AM
To: Kirk Hall (RD-US)
Cc: Peter Bowen; CABFPub
Subject: Re: [cabfpub] Issuers in BR/EV/EVCS Guideline Scope

On Fri, Apr 15, 2016 at 11:55 AM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
Peter - you have addresses a lot of issues at a very abstract level.  I'm curious -- is there a current problem or need you are addressing?  (If so, can you describe so we all have context?)  Or are you approaching this more from an intellectual perspective, simply trying to set limitations which might be useful in the future if we have a question about the scope of various guidelines?

Kirk, this topic has been discussed repeatedly for over a year, so there should be ample context. I'm a bit surprised you don't recognize it as such, given you've participated in these discussions.

The question is simple: What is the scope of the BRs? The current definition of "intended to be used" leaves great ambiguity: If something is technically capable of being used, is that an expression of intent? Is intent simply a matter of a CA saying "Oh, yeah, don't do that?" Can I issue a cert for google.com<http://google.com> and claim it's not intended to be used for TLS, but S/MIME? Even when it has the tls-serverAuth EKU?

This has been discussed in the context of root programs (see the debates with Jody on audit requirements). This has been discussed in the context of audits (what does WebTrust examine). This has been discussed in the context of program requirements (Mozilla's repeated clarifications). You've heard comments from the US Federal PKI with respect to EKU processing. We've had discussions in the IETF PKIX group before it was shuttered (and that really speaks to how long this conversation has been ongoing) about EKUs. And yet still we persist with the ambiguous language, in part, because the conversation gets stalled.

Also -- does this indirectly tie into the work of the new Governance Change Working Group - meaning, does the proper scope of any guidelines tie into the proper scope of the work and membership of the Forum?

Not necessarily.

I am wary of adopting new rules in the abstract without having a better understanding (including examples, if possible) of exactly what problem we are addressing.   Otherwise, we could adopt a limitation only to discover that we didn't like it when a particular situation arises (Gerv gave a good example)

Multiple examples have been provided over several years, considering that this is a conversation that has been ongoing for some time. Peter's questions attempt to rephrase the debate, given that it has in some ways reached a log-jam for some members.

Given the nature of members' PKI, and given the multiple statements from the auditors as to how they approach audits, root programs are understandably concerned. If a root program says "Everything technically capable must adhere to the BRs", but the BRs say they only cover certificates "intended to be used", how do we reconcile that conflict? The browsers clearly have a specific interpretation in mind (technically capable = intent), but formalizing that into the BRs is seemingly obstructed at every attempt, even with the browsers having that consistent expectation.

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160418/0f4025e7/attachment-0003.html>

More information about the Public mailing list