<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 3:02 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> 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.<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> In Section 4.9.1.2 (Reasons for Revoking a Subordinate CA Certificate)<br>
><br>
><br>
> Replace with:<br>
><br>
> The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:<br>
><br>
> 1.      The Externally Operated Subordinate CA requests revocation in writing;<br>
> 2.      The Externally Operated Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;<br>
><br>
> 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".<br>
><br>
> 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;<br>
><br>
> 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.<br>
<br>
</span>Given that “CA” means an organization, it makes no sense to have an organization notify itself.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Does that make my "Why not just Subordinate CA for these" concern clearer?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> 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.<br>
><br>
> 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.<br>
><br>
> 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?<br>
<br>
</span>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 […]”<br></blockquote><div><br></div><div>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" ;)</div><div><br></div><div>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)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> ></span> 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:</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> > 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:<br>
></span><span class="gmail-"><br>
> 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.<br>
<br>
</span>Because there is no "Internally Operated Subordinate CA” term.<br></blockquote><div><br></div><div><div>Under this ballot, there is</div><div><br></div><div>" 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."</div><div><br></div><div>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?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>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.</div><div><br></div></div><br></div></div>