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

Ryan Sleevi sleevi at google.com
Sun Apr 17 10:43:20 UTC 2016


On Fri, Apr 15, 2016 at 11:55 AM, kirk_hall at trendmicro.com <
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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160417/e8763612/attachment-0003.html>


More information about the Public mailing list