[cabfcert_policy] CA vs. CAO

Tue Nov 22 13:43:05 MST 2016

A couple of follow-up comments to my edits below:

1 – Under E., the definition could be revised to read, “A third party CA (not the Root CA Operator or its Affiliate) that is in possession or control of the Private Key associated with a Subordinate CA Certificate.”

2 – Under F., we could keep “Issuing CA” (and not replace it with “Issuer”).  That would reduce the number of edits in the document.  F would read, “Replace the definition of ‘Issuing CA’ with: ‘In relation to a particular Certificate, the Root Certificate or the Subordinate CA Certificate that issued the particular Certificate.’”

From: Policyreview [mailto:policyreview-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Tuesday, November 22, 2016 12:49 PM
To: Peter Bowen <pzb at amzn.com>; Dimitris Zacharopoulos <jimmy at it.auth.gr>
Cc: policyreview at cabforum.org
Subject: Re: [cabfcert_policy] CA vs. CAO

Here is a first attempt at creating a ballot based on Dimitris’ v.6, with edits I’ve made as I’ve reworked the definitions.

Delete the last sentence of section 1.1, which reads, “These Requirements are applicable to all Certification Authorities within a chain of trust. They are to be flowed down from the Root Certification Authority through successive Subordinate Certification Authorities.”

Insert as the last sentence of section 1.1 the following:  “These requirements are applicable to all CAs that can issue a certificate that appears in a particular certificate chain from a Root Certificate that is publicly trusted.  They are to be flowed down from a Root Certificate through successive Subordinate CA Certificates.”

In Section 1.6.1 (Definitions):

A.    Insert a new definition for “CA Certificate” as: “A Certificate in which the basicConstraints field has the cA attribute set to TRUE.”

B.    Replace the definition of “Certificate Revocation List” with: “A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the Issuer’s Private Key.” 

C.    Replace the definition of “Certification Authority” with: “An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CA Operators and Externally Operated Subordinate CAs.”

D.    Replace the definition of “Cross Certificate” with: “A CA Certificate that is used to establish a trust relationship between two Root CA Certificates.”

E.     Insert a new definition for “Externally Operated Subordinate CA” as: “Any organization or legal entity, other than the Root CA Operator or its Affiliate, that is in possession or control of a CA Certificate (and its associated Private Key).”

F.     Replace the defined term “Issuing CA” with “Issuer” and replace the definition with: “In relation to a particular Certificate, the Root Certificate or the Subordinate CA Certificate that issued the particular Certificate.”

G.    Replace the definition of “Key Generation Script” with:  “A documented plan of procedures for the generation of the Key Pair to be associated with a CA Certificate.”

H.    Replace the definition of “OCSP Responder” with:  “A system that provides Online Certificate Status Protocol responses.”

I.       Replace the definition of “Root CA” with “A system comprised of a Root CA Certificate and its associated Private Key and Public Key.” 

J.      Insert a new definition for “Root CA Operator” as:  “The top level Certification Authority (i.e. an organization) whose CA Certificate (or associated Public Key) is distributed by Application Software Suppliers as a trust anchor.”

K.    Replace the defined term “Root Certificate” with “Root CA Certificate” and replace the definition with:  “A CA Certificate in which the Public Key has been digitally signed by its corresponding Private Key.” 

L.     Replace the definition of “Subordinate CA” with “A Certification Authority in possession or control of the Private Key associated with a Subordinate CA Certificate.”

M.   Insert a new definition for “Subordinate CA Certificate” as: “A CA Certificate that has been signed by the Private Key associated with a Root CA Certificate or a different Subordinate CA Certificate.”

Comments, suggestions, and improvements welcome.

Ben

From: Peter Bowen [mailto:pzb at amzn.com] 
Sent: Tuesday, November 22, 2016 12:09 PM
To: Dimitris Zacharopoulos <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr> >
Cc: Ben Wilson <ben.wilson at digicert.com <mailto:ben.wilson at digicert.com> >; policyreview at cabforum.org <mailto:policyreview at cabforum.org> 
Subject: Re: [cabfcert_policy] CA vs. CAO

I agree that nobody wants to go over every document and replace “CA” with “CAO” and I don’t think that is necessary.  Ben ran into a challenge on the last call which he can discuss, but I have run into a somewhat larger challenge when it comes to defining “CA” as the legal entity.

Many entities that control CA private keys control different keys that are part of different PKIs.  For example they may have one set of CA keys that are for BR compliant CA, one set that are for CAs that follow the Four Bridges Forum standards, and another set that are for private Enterprise PKIs that each follow standards for a specific enterprise case.  If we define “CA” to mean the operator, then things get very confusing because the the operator may be following different requirements for issuing very similar certificates depending on the PKI.

I suggest that we define a Certification Authority to be a distinct entity that itself has agency and is owned or operated by a CAO.  A CA is best thought of as logically equivalent to a department or division within an organization.  So if you can say “the IT department must ensure that all computers have asset tags” you can say “the CA must ensure that all domain names end in a public top-level domain”.  This preserves that status quo that each CA is a distinct asset that can be bought and sold and a CAO/TSP may sell a some CAs while retaining others.  

By giving the CA agency, most the CA references in the BRs do not need changing and things like “Root CA” may make sense without any changes at all.    For example, see the sentence fragment in section 6.1.1.1:

"For Root CA Key Pairs created after the Effective Date that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL”

This can be changed to:

"Fort CA Key Pairs created after the Effective Date that are either (i) used as Root CA Key Pairs or (ii) for a subordinate CA that is not operated by CAO of the Issuing CA or an Affiliate thereof, the CA SHALL”

I think there are probably few places where we only mean the operator of the CA.

Thanks,

Peter

On Nov 21, 2016, at 1:11 PM, Dimitris Zacharopoulos <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr> > wrote:

First of all, sorry I missed the last call. This topic was discussed in previous F2F meetings and on several occasions. I believe that nobody wants to go over changing every document that has the term "CA" and change it to "CAO". If we are to do such a big change, I would vote to use the term "Trust Service Provider - TSP" in order to align with the European model.

The majority of the CAs and auditors have linked the term "CA" with an "organization". That's why it was agreed (on past meetings) that we will not try to change the meaning of the term "CA" to mean anything else but that of an organization. Instead, we would try to use this term consistently (to refer to an organization) and introduce changes to the other instances to mean something else. That would introduce fewer changes in the BRs and EV guidelines.

Dimitris.

On 21/11/2016 10:47 μμ, Ben Wilson wrote:

On our most recent call, Peter Bowen and I again discussed use of “CA” vs. something else.  (Back on May 5th I sent out a proposed “straw poll” to this group, but I don’t think I ever sent it to the public list.)  Peter and I like the term “CA Operator” or abbreviated, “CAO”.  The only downside, which is a big one – I’ll admit, is that  the term “CA” seems to  be used pervasively within the Forum and elsewhere to refer to  the entity that  operates a CA.  

Following our last call, I started to do a replacement of CA with CAO to see how it would look/work, but I stopped because there would be many instances to replace and I wanted to get more of a consensus from  this group and potentially the public list.

Thoughts?

Ben

_______________________________________________
Policyreview mailing list
 <mailto:Policyreview at cabforum.org> Policyreview at cabforum.org
 <https://cabforum.org/mailman/listinfo/policyreview> https://cabforum.org/mailman/listinfo/policyreview

_______________________________________________
Policyreview mailing list
 <mailto:Policyreview at cabforum.org> Policyreview at cabforum.org
 <https://cabforum.org/mailman/listinfo/policyreview> https://cabforum.org/mailman/listinfo/policyreview

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/policyreview/attachments/20161122/b80d62a6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/policyreview/attachments/20161122/b80d62a6/attachment-0001.bin>