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

[Ryan Sleevi]

On Fri, Feb 24, 2017 at 3:02 PM, Peter Bowen <pzb at amzn.com> wrote:

> > 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.
>

Right, and I can see where this makes things "Common Sense" in some
respects, but seems to introduce confusion/scope issues in some of the
sections below. I think this is probably less of a concern then the
application/usage below, so thanks for highlighting and explaining the
intent and practice here.


>
> > 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.
>

So given a case of Alphabet, in which Waymo might acquire a certificate
from Google Inc, is the idea that if Waymo wants the certificate revoked,
it has to use unspecified internal channels?

Given their legally distinct nature, as you highlighted, I would think that
at least 1 and 2 would be no worse than the status quo. I'm specifically
questioning the relationship as to what recourse/options/handling exists
for if a CA Operator does one thing, but an Affiliate does something. How
does that Affiliate (a distinct legal entity) handle various scenarios.

Similarly, if an Affiliate runs an ("Internally Operated Subordinate CA"),
under a separate legal aegis and potentially separate auditing
infrastructure as a consequence of that, what obligation does the Issuing
CA have to take action?

Does that make my "Why not just Subordinate CA for these" concern clearer?


> > 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 […]”
>

And yet RFC 6960 disagrees, which is where the problem comes from.
"Therefore, the information MUST correspond to the certificate that was
used to sign the response" ;)

Now, had 6960 said the information must correspond to the certificate that
was used to issue the response, 6960 would be clearer. But the current BRs
align with 6960 (referring to 'certificate signing'), which thus gives a
clearer picture that both the RFC and the BRs are referring to the same
concept. This asymmetry potentially introduces confusion, and I suspect the
best we can do, given voting has started, is to figure out how likely the
confusion is (low, hopefully) and how a follow-up ballot can clarify (...
and whether we can get that clarification prior to voting ending here)


> > > For a Key Pair generated to be associated with either (i) a Root CA
> Certificate or (ii) a Subordinate CA Certificate to be operated by an
> Externally Operated Subordinate CA, the CA SHALL:

> > For a Key Pair generated to be associated with a Subordinate CA
> Certificate to be operated by the Root CA Operator or its Affiliates, the
> CA SHOULD:
> >
> > 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.
>

Under this ballot, there is

" 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."

That is, the only distinction that seems between these two is "in
possession or control of the Private Key associated with the Subordinate CA
Certificate", and this being describing how such a Private Key is
generated... but does that make it clearer?


> 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.
>

I think that really is the core of the concerns related to scope. I totally
appreciate the legal vs conceptual separation, but I'm concerned about the
ambiguity it introduces to the scope of the audit, CP, and CPS. This was
the topic discussed at the Redmond F2F with respect to organizations that
have many legal entities, those legal entities potentially possessing many
CP and CPSes, those entities potentially possessing many audits (of
different scopes) for a single set of CP and CPSes, and the binding of the
key, name, and issuance practice through those multiple layers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170224/80201bda/attachment-0003.html>