[cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements

[Peter Bowen]

Ryan,

I can’t answer many of your questions, but there are a couple where I do have some insight.

> On Feb 24, 2017, at 2:29 PM, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> On Thu, Feb 16, 2017 at 11:08 AM, Ben Wilson via Public <public at cabforum.org> wrote:
> *       Insert a new definition for "Externally Operated Subordinate CA" as: "A third party Subordinate CA Operator, not the Root CA Operator or its Affiliate, that is in possession or control of the Private Key associated with the Subordinate CA Certificate." 
> *       Insert a new definition for "Internally Operated Subordinate CA" as: "A Subordinate CA Operator, operated by a Root CA Operator or its Affiliate, that is in possession or control of the Private Key associated with the Subordinate CA Certificate."
> 
> I think this is a potentially problematic definition, in that it relates to the scope of the operations of the audit, as well as matters below that I highlight. I'm hoping the proposers and drafters can clarify (or link to previous discussions) as to the reason in which "or its Affiliate" was introduced into these definitions, or to highlight where it was already a natural and existing part of these definitions.

This is a change that I think I asked for.  “Affiliate” in this context means a company with common ownership or a subsidiary.  Given that companies generally do not cross international boundaries, we need to include Affiliates in pretty much any place where we have an organization called out.  For example, Google Switzerland GmbH may operate the Zürich office and Google Inc may operate the Chapel Hill, NC office.  Most people would see this as one company but legally they are not.

> In Section 4.9.1.2 (Reasons for Revoking a Subordinate CA Certificate)
> 
> 
> Replace with:
> 
> The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:
> 
> 1.      The Externally Operated Subordinate CA requests revocation in writing;
> 2.      The Externally Operated Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;
> 
> Can you highlight/explain why this was limited to "Externally Operated"? I cannot see why these reasonings don't apply to Internally Operated Subordinate CAs as well, due to the above introduction of "or its Affiliate".
>  
> 5.      The Issuing CA is made aware that the Subordinate CA Certificate was not issued in accordance with, or that the Externally Operated Subordinate CA has not complied with these Requirements or the applicable Certificate Policy or Certification Practice Statement;
> 
> This change seems problematic in that it suggests that revocation is not required for Internally Operated Subordinate CAs to comply with the Requirements or the applicable Certificate Policy or Certification Practice Statement.

Given that “CA” means an organization, it makes no sense to have an organization notify itself.

> Put differently (since I understand this is subtle)
> 
> Imagine Private Key A is associated with Certificate 1 and Certificate 2. Certificate 1's associated Issuer Name is "Foo", Certificate 2's associated Issuer Name is "Bar". At present, I do not believe this is forbidden under the Baseline Requirements (or under this proposal).

You are correct.  Multiple DNs may be associated with a single key.

> Under this model, it seems that I potentially could issue a certificate whose issuer is Certificate 1 ("Foo"), but then create an OCSP response with responderID byName of "Bar", and then sign with Private Key A.
> 
> Under 6960, this meets the definition that "the information MUST correspond to the certificate that was used to sign the response" - since Certificate 2 was 'used' to sign the response, using Certificate 1's Private Key.
> 
> Have I missed somewhere in the intersection of this Ballot, the existing Baseline Requirements, and 6960 where this scenario (as insane as it is) is prohibited?

I think this was an attempt to address the concern that certificates are not used to sign things, rather private keys are used to sign things.  CA Certificates also do not issue certificates So you cannot say “Be signed by the CA Certificate that issued […]”

> In Section 5.4.1 (Types of events recorded)
> 
> 
> Replace subsections 1 and 2 in the second paragraph of so that they read:
> 
> The CA SHALL record at least the following events:
> 
> 1. Private Key lifecycle management events for the Root CA Certificate or Subordinate CA Certificate, including:
> 
> Does this mean items A and B are removed, or was it proposed to leave them in place? The language is ambiguous, given the text below.
> 

The redline makes this clear.  A and B are kept.

> 
> 2. Certificate lifecycle management events for the Root CA Certificate, Subordinate CA Certificate, and Subscriber Certificates, including:
> 
> a.      Certificate requests, renewal, and re-key requests, and revocation;
> b.      All verification activities stipulated in these Requirements and the CA's Certification Practice Statement;
> c.      Date, time, phone number used, persons spoken to, and end results of verification telephone calls;
> d.      Acceptance and rejection of certificate requests; Frequency of Processing Log
> 
> Was this a typo? Can you explain what "Frequency of processing log" is meant to be in this context?

Yes, a typo.  See the red line.

> Why does this not use the term Internally Operated Subordinate CA? It would seem that this would be semantically accurate and correspond to the (ii) above to completely cover the set of Sub CA Certificates.

Because there is no "Internally Operated Subordinate CA” term.

> Similarly, this creates the scenario where an Internally Operated Subordinate CA is operated with different infrastructure than the audit, at least based on my current understanding about the scope of the engagement not necessarily covering the "Affiliates" portion.
> 

The Affiliates portion was not intended to suggest that it was outside the audit scope.  The intent here was simply to solve the problem of multiple offices of the same company being legally different entities.  Maybe this needs to be rephrased into terms of the scope of the audit.

> In Section 7.1.5 (Name Constraints)
> 
> 
> Replace the last paragraph with:
> 
> If the Subordinate CA Operator is not allowed to issue certificates with dNSNames, then the Subordinate CA Certificate MUST include a zero-length dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate MUST include at least one dNSName in permittedSubtrees.
> 
> The preceding paragraph states "Subordinate CA Certificate is not allowed to issue certificates". This change introduces an asymmetry between the two. Was this intentional? Is it significant?

This is also confusing to me as certificates do not issue certificates.

Thanks,
Peter