[cabfpub] Policy Review Working Group Discussion on Terminology

[Peter Bowen]

> On Feb 25, 2016, at 3:12 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Thu, Feb 25, 2016 at 3:00 PM, Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com>> wrote:
> 1.       Where the intent of the guidelines is to discuss the end entity subscriber, as opposed to an intermediate CA subscriber, replace the word “subscriber” with the phrase “end entity”.  During this process, we may need to consider how we use the term “Applicant” and “Subject.”  For example, when a certificate is issued, what does the “Applicant” become if not a Subscriber? 
> 
> Is there a reference to the issues you see here? As the F2F minutes are not public, nor are your meeting minutes, the best I could do is look through the past two months of the Policy WG to attempt to understand the issue, but I was unable to find any summary or discussion. Apologies if I missed it, but a recap would be greatly appreciated

I’m not sure about the Applicant/Subscriber bit, but the primary concern was the term “Subscriber Certificate”.  This is not defined anywhere.  Given that a Subscriber could be getting a certificate with CA:True in the basic constraints (e.g. the Subscriber is a subordinate CA), we wanted to change “Subscriber Certificate” to “End-entity Certificate” in most locations and create a definition for “End-entity Certificate”.

> 2.       Where the intent of the guidelines is to discuss the entity that operates a certification authority, replace the word CA with the phrase “certification service provider”, CSP, or similar.  How do people feel about that? The working group felt that the term “CA” should be reserved to refer to the system that can issue certificates because the basic constraints extension of its certificate contains “CA equals true”.
> 
> Apologies for making you expand on arguments that were no doubt discussed on the call, but since you asked for thoughts... what's the logic here?
> 
> Is the group feeling that CA refers to the underlying technology? Because that's seemingly wildly at odds with the specs of which the Web PKI builds on (X.509 and 5280, as the most obvious case). It does seem to add any benefit, and would serve to introduce great confusion if we use the commonly accepted term in some new way. It would be helpful to understand the arguments here, which I readily admit, I'm not familiar with.

A single Certification Service Provider (CSP) may run multiple Certification Authorities (CAs).  It is entirely possible that a single entity (the CSP) may operate both a Root CA and one or more CAs that are subordinate to Root CAs.  

This would clarify and align terminology with the Browser half of the forum; Application Software Suppliers and Certification Service Providers are legal entities and Browsers and CA are things which are personal property.
> 3.       We also hope to standardize on usages of the terms “Intermediate CA” vs. “Subordinate CA” (and possibly address other similar or related concepts in the same ballot).
> 
> Similar in response, what problem are you trying to solve here? At least checking through the BRs again, I don't see any mention of "Intermediate CA", so it would be useful to know what standardized usage is envisioned, and why Subordinate CA (or simply CA) does not encompass this.

I think the intent here is to ensure we not using “Subordinate CA” alone, but only as an adjective, for example “Subordinate CA Certificate”.

> Is there any further discussion of the issue beyond https://cabforum.org/pipermail/policyreview/2016-February/000231.html <https://cabforum.org/pipermail/policyreview/2016-February/000231.html> ? Is that what you're trying to call attention to? If so, I believe I agree with Peter Bowen's remarks (which I take to be "No change needed”)

I’m actually one of the proponents of most of these changes.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160225/dfb8e7dc/attachment-0003.html>