[cabfcert_policy] Latest Version of CA vs. CA Certificate

[Dimitris Zacharopoulos]

> On 22/9/2016 7:01 μμ, Ben Wilson wrote:
> Here is the  latest version the marked-up version of the Baseline Requirements where we compare uses of the word CA.
> 
> 
> _______________________________________________
> Policyreview mailing list
> Policyreview at cabforum.org
> https://cabforum.org/mailman/listinfo/policyreview

I have attached a new revision, after our discussion on the last WG call. I believe this revision is consistent with the current BR definitions for "Root CA", "Root Certificate" and others, as described in section 1.6.1. 

Peter has expressed some concerns that there are several spots in the BRs say where it says that "Certificates" sign or issue other Certificates. While this language is technically incorrect, we could include this correction on this "CA" term clarification effort. or have a second attempt after we clear out a consistent use of the term "CA".

IMO, private keys sign public keys thus producing certificates. We could try to replace this whenever possible. You will see the language "signed by the private key associated with a Root Certificate or a Subordinate CA Certificate". Are there any better suggestions?

Here are some more of Peter's comments and answers. I replaced real examples with fake ones. 

>  
> In 4.9.1.2, you appear to be discounting the case of a Subordinate CA Certificate held by an entity that is neither a Root CA nor an Externally Operated Subordinate CA.  This gap would happen if an affiliate of the Root CA holds the Subordinate CA Certificate; for example Company A and Example CA are affiliates (common owner).  If Example CA issues a CA certificate to Company A, then Company A is neither a Root CA nor an Externally Operated Subordinate CA.

My rationale here is that "Affiliated" companies are part of the "Root CA" as a whole. That is, the "Root CA" is responsible for its internally operated Subordinate CAs. I did not spot specific controls for internally operated subordinate CA Certificates in the current BRs. They could be treated as any other subCA under the control of the Root CA. What the BRs are after (thus adding extra controls), IMO, are to increase attention on the externally operated subCAs.

In Peter's example, Company A would control yet another subordinate CA Certificate issued by Example CA, a Certificate very much like a Subordinate CA Certificate that Example CA has for issuing general purpose SSL Certificates. The same should apply for "branded" subCA Certificates. Example CA must make sure that it's own CP/CPS and the one from Company A are followed and properly audited. Additionally, if Company A's subCA Certificate is technically constrained per 7.1.5, it only requires an internal audit as described in 8.7.

To make my point more clear, it is Example CA's responsibility and risk acceptance to allow Company A, as an Affiliate, to run it's own Subordinate CA and no additional contracts are mandatory to be in place. In the case of an externally operated subCA, a contract is most definitely needed to be signed by the two entities.

> In 4.9.10, it needs to cover all CA Certificates, not just Subordinate CA Certificates.  Specifically, status of self-signed certificates needs to be supported in addition the status of Subordinate CA certificates.

I am not aware of a case where you are able to verify the status of a Root Certificate. Root Certificates are trust anchors and are trusted by definition. If there is such a case, of course we can replace the "Subordinate CA Certificate" with "Root Certificate or Subordinate CA Certificate" as need.

>  
> In 8.7, I think there is a gap when the technically constrained CA is operated by the Root operator.

The rationale is similar. A Root operator is already responsible to audit the proper usage of its "internal" subordinate CA Certificates, including the technically constrained ones. If you take the same example with Company A and Example CA, I would assume that Example CA's qualified auditor will audit (under the same assignment) all of Example CA's internal subCAs and its Affiliates, including Company A.     They would probably include Company A's assessment in a single audit report with all of Example CA's internal subCAs. If Company A is technically constrained, Example CA's auditor would be ok by reviewing the internal audit from     Example CA and maybe do some additional checks. In the case of an Externally operated subCA, Example CA may receive an audit report from a completely different qualified auditor (for that particular subCA) and Example CA's auditor will have to evaluate the audit report from that other auditor. There would definitely be two separate audit reports.

I hope my point of view is understandable and reasonable. If it's not, we might have to add another definition of an "Internally operated Subordinate CA" which will refer to an "Affiliate" of the Root CA, because we agreed that we want the "CA" term to be identified as an "organization". It would be inconsistent if it were to refer to the Subordinate CA Certificates that are directly operated by the Root CA.

Perhaps this rationale should be addressed somewhere in an appropriate section of the BRs.

> That is what I found so far.

If any of you would like to propose a way forward so we can have something ready for the F2F, I'd be happy to hear. If we can address Peter's concerns, maybe we could remove most of the comments and circulate the doc in the public list for final comments. 


All the best,
Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/policyreview/attachments/20161017/1ac04007/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BR 1.3.7-with-comments-regarding-CA-subCA-intermediateCA v4.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 122895 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/policyreview/attachments/20161017/1ac04007/attachment-0001.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/policyreview/attachments/20161017/1ac04007/attachment-0003.html>