[cabfcert_policy] CA vs. CAO
Dimitris Zacharopoulos
jimmy at it.auth.gr
Wed Nov 23 02:51:07 MST 2016
On 23/11/2016 1:46 πμ, Ben Wilson wrote:
>
> Here are some edits that I’d favor.
>
I am also in favor of most of these changes. Attached are some comments
on specific changes.
Perhaps we should reconsider the proposed change from "Issuing CA" to
"Issuer". Keeping the "Issuing CA" term and updating the relevant
sections to mean something consistent, is probably the best solution.
Best regards,
Dimitris.
> *From:*Ben Wilson
> *Sent:* Tuesday, November 22, 2016 1:43 PM
> *To:* Ben Wilson <ben.wilson at digicert.com>; 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
>
> 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 <mailto:pzb at amzn.com>>; Dimitris
> Zacharopoulos <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>>
> *Cc:* policyreview at cabforum.org <mailto: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 5^th 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
>
> Policyreview at cabforum.org <mailto:Policyreview at cabforum.org>
>
> https://cabforum.org/mailman/listinfo/policyreview
>
>
> _______________________________________________
> Policyreview mailing list
> Policyreview at cabforum.org <mailto:Policyreview at cabforum.org>
> https://cabforum.org/mailman/listinfo/policyreview
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/policyreview/attachments/20161123/b63151cb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Policy-Review-Ballot-DZ.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 31518 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/policyreview/attachments/20161123/b63151cb/attachment-0001.bin>
More information about the Policyreview
mailing list