<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 10:52 AM, Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</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">
<div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote>
<div><br>
</div>
<div>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>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Peter already provided some clarity for this. The "Affiliate"
language was not introduced by this ballot. It was already mentioned
in several sections of the BRs (6.1.1.1 "CA Key Pair Generation",
6.1.2 "Private Key Delivery to Subscriber", 6.2.6 "Private Key
Transfer into or from a Cryptographic Module", 7.1.2.2 "Subordinate
CA Certificate" and 7.1.6.3 "Subordinate CA Certificates").<br></div></blockquote><div><br></div><div>Unfortunately, I think the concern still remains that this is a subtle introduction that goes from being scoped to specific sections (as you've noted) to now being a foundational concept, which unfortunately 'weakens' the BRs, I believe.</div><div><br></div><div>I totally understand and appreciate the intent to align here, especially for the cases Peter noted, but I want to especially make sure to highlight the issue that "or the Affiliate" can be problematic from a set of scope of audits.</div><div><br></div><div>Basically, what's being asked for on this ballot is a trade-off from being logically bugged (and I agree, this is an issue we should fix) to something that is procedurally weaker, and I'm trying to figure out what the plan is to align. From both you and Peter's response, it sounds like you don't believe further changes are needed, and this is concerning.</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"><div bgcolor="#FFFFFF">
Peter's answer should cover this. Your follow-up questions challenge
the fact that the current BRs treat Root Operator's "Affiliates" in
a different way than the non-Affiliates but this is a policy matter
and should be discussed separately. In any case, I don't think it
changes the fact that all Subordinate CAs (whether internally or
externally operated) need to be audited. In the case of Internally
Operated Subordinate CAs, the audit might be covered in the Root
Operator audit, and this information should be included in the audit
scope.<br></div></blockquote><div><br></div><div>That's the intent - but my question is, where is it specified? I may have missed that, and that was the point of raising these concerns: if I'm misreading, and it's already addressed, fantastic. But I don't believe it is, hence the concern :)</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"><div bgcolor="#FFFFFF">
After several discussions within the WG, it was agreed that the most
accurate technical language is that "Private Keys sign
Certificates". Certificates, don't sign Certificates. </div></blockquote><div><br></div><div>I understand the "why". I'm more specifically asking three questions:</div><div>1) Is my interpretation correct?</div><div>2) Is this desired?</div><div>3) Is there a plan to fix it?</div><div><br></div><div>From the rest of this section, I can interpret your response as "1) Yes 2) No, not necessarily 3) Not really, but we could come up with one". I'm not sure if that really provides the level of assurance when considering whether to vote on this ballot, even though I agree and understand the why, and am relieved it isn't intended.</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"><div bgcolor="#FFFFFF">So, according to your example, if the ResponderID was the hash of
the Subordinate CA Certificate's public key, it would not be
prohibited even though that key would be included in two or more
Subordinate CA Certificates. Perhaps the multiple CA Certificates
with the same key-pair scenario is not entirely addressed. We could
update the BRs to specifically include language for the ResponderID
information, if you think people would be puzzled about what
information should be included in that field.<br></div></blockquote><div><br></div><div>Whether we address this by specifying language fro the ResponderID (which seems overly specific) or by addressing the general concern, I'd like to see a concrete proposal to address this, ideally before voting concludes.</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"><div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In Section 4.9.10 (On-line revocation checking
requirements)<br><br></blockquote>
<div><br>
</div>
<div>Was this intentional?</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
This specific change was addressed during the discussion phase
(<a class="gmail-m_-4091516754384310756moz-txt-link-freetext" href="https://www.mail-archive.com/public@cabforum.org/msg02652.html" target="_blank">https://www.mail-archive.com/<wbr>public@cabforum.org/msg02652.<wbr>html</a>).<br></div></blockquote><div><br></div><div>Did you link to the right thread? I cannot find a clear answer, but perhaps I'm just missing it. As it stands, I think this alone is potentially grounds that we may need to vote against it, because it's a clear reduction in assurance.<br></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"><div bgcolor="#FFFFFF">
A typo indeed. It is clear in the red-lined version.<br></div></blockquote><div><br></div><div>For future reference, we should try to figure out what version is being voted on, when the e-mailed ballot and Red Line disagree :) This is a minor issue, but I can easily see more significant issues creeping in, least of all, because I have not looked at all at the Red Lined version, because that's not the balloted text :)</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"><div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In Section 8.7 (Self-Audits)<br>
<br>
<br>
Replace the last paragraph with:<br>
<br>
During the period in which a Technically Constrained
Externally Operated Subordinate CA issues Certificates,
the Issuing CA SHALL monitor adherence to the Issuing
CA's Certificate Policy and/or Certification Practice
Statement and the Externally Operated Subordinate CA's
Certificate Policy and/or Certification Practice
Statement. On at least a quarterly basis, against a
randomly selected sample of the greater of one
certificate or at least three percent of the
Certificates issued by the Externally Operated
Subordinate CA, during the period commencing immediately
after the previous audit sample was taken, the CA SHALL
ensure adherence to all applicable Certificate Policies
and/or Certification Practice Statements.<br>
</blockquote>
<div><br>
</div>
<div>Much like several other changes mentioned above, this
limits the scope of the existing text from "internal or
external" to simply "external". Thus it reduces the
scope of examination for internally operated subordinate
CA certificates, which may be operated by an Afilliate
under a distinct CP/CPS. Is that fair to say?</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
The rest of the section remains the same. It doesn't remove the
obligation for the CA (this covers ALL CA organizations, including
affiliates) to perform quarterly self-audits.<br>
<br>
The reasoning for changing the last paragraph to only "Externally
Operated Subordinate CAs", was that the language dictates that the
"Issuing CA SHALL monitor adherence...". We thought that it doesn't
make sense to have one organization monitor adherence to it's own
organization. It is already required for the Root CA Operator to
adhere to its own CP and/or CPS (that must cover all Internally
Operated Subordinate CAs), check against a randomly selected sample,
etc, as specified in the first paragraph of section 8.7.<br></div></blockquote><div><br></div><div>So I think the point you're making is important, and I'm not cleared where it's technically spelled out or required, and do hope you can highlight this.</div><div><br></div><div>You're asserting that all Internally Operated Subordinate CAs are operated by the Root Operator AND, if I'm understanding correctly, audited to the same CP/CPS as the Root CA Certificate - is this correct?</div><div><br></div><div>I haven't found text to normatively require either statement, and that's the concern: even if it's the same organization as the Root Operator, the possibility for distinct CP/CPSes to exist between the Root CA Certificate's policies and the Internally Operated Subordinate CA's policies (and/or independent audits) exists, and as much as possible, I want to ensure the same consistent duty of care with respect to policies and practices. I fear this introduces a loophole for Affiliates to 'skip' audits and key protection, even if unintended, so I'm curious if we can find a resolution for this within the voting period.</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"><div bgcolor="#FFFFFF"><br>
Here are the two definitions introduced:<br>
<br>
<b><span lang="EN-US">Root
CA Operator:</span></b><span lang="EN-US"><span> </span></span><span lang="EN-US">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<br>
</span><br>
<b><span lang="EN-US">Internally Operated
Subordinate CA:</span></b><span lang="EN-US"> <span> </span>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</span>
<br>
<br>
The Root CA Operator is already -by definition- responsible for all
actions related to its Internally Operated Subordinate CAs and
Affiliates.</div></blockquote><div><br></div><div>I disagree, and that's the point of concern. If the Root CA Operator included the definition of Affiliates - ergo bringing consistency to the scope of audits and operation - then perhaps this issue would be resolved (of course, it may introduce new bugs). But as it stands, an Internally Operated Sub CA having the "or its Affiliate" creates a loophole in which all the policies which apply to a Root CA Operator _don't_ apply to the Affiliate, because IOSCAs clearly distinguish Affiliate as "something other than the Root CA Operator"</div><div><br></div><div>Does this make sense?</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"><div bgcolor="#FFFFFF">
Voting ends on Thursday March 2 at 22:00 UTC but the remaining
issues will be tracked and addressed in a future ballot.<br></div></blockquote><div><br></div><div>My hope is something a bit more concrete than future ballot before then, because I think some of these concerns are enough to prevent our support </div></div></div></div>