<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 5:42 AM Neil Dunbar via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>(Snipped all the other changes, that sound good)</p></div></blockquote><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>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">There's an ambiguity here, which is
when there are multiple certificates associated with a given
key (e.g. a Root Certificate and a Subordinate CA that is a
Cross-Certificate). The wording of this requirement implies a
singular requirement ("the CA key"), which would seem to
permit a CA arguing that they no longer have to retain the
events after /one/ certificate expires, rather than after
/all/ certificates expire. This isn't the only section to face
that challenge (e.g. <a href="https://github.com/cabforum/documents/issues/187" target="_blank">https://github.com/cabforum/documents/issues/187</a> ),
but it seems appropriate to try and tackle this.</div>
</div>
</blockquote>
<p>So, my first attempt at a fix - and I grant you it's clunkier
than an Austin Allegro (substitute culture specific example of a
bad car here) - is to use this terminology:</p>
<blockquote>
<p><span style="color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:16px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">[...] or the revocation or expiration of the
final CA Certificate in that set of Certificates sharing a
common Public Key which corresponds to the CA Private Key</span><br>
</p>
</blockquote>
<p> Does this allow wiggle room which we would rather not allow? Is
there something more succinct that we can use (highly probable)?<br></p></div></blockquote><div>We can probably use the language of 6.2.6, which the new browser alignment ballot also borrows (for 7.1.4.1), which is a variant of "all certificates" to make it clear that all in the set must share that property.</div><div><br></div><div>The worry I have with "CA Certificates" is we've seen at least one CA get confused about "Cross-Certificates" and how they are "Subordinate CA Certificates", and we've also seen more than one CA get confused about Section 8.1's language ("capable of being used to issue new certificates") because they like to ignore the sentence that immediately follows and defines what that capability is, so I do think we might need to get a little clunkier:</div><div><br></div><div>"or until all Certificates that have an X.509v3 basicConstraints extension with the cA field set to true and that contain a Public Key corresponding to the CA Private Key have expired or been revoked".</div><div><br></div><div>The choice of "a" vs "the" is just to make sure someone doesn't try to argue an encoding difference (which the browser alignment will hopefully fix on a go-forward basis) as a basis for ignoring this. It's clunky, but hopefully that language is clear enough for CAs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite">
<div dir="ltr">
<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">
3. any security event records (as set forth in
Section 5.4.1.3)<br>
after the event occured.<br>
</blockquote>
<div><br>
</div>
<div>I am most uneasy about this. I think it's understandable
with respect to firewall/router logs the challenges faced by
CAs, but I'm deeply concerned about things like CA
entry/exit. The problem is the system event logs are
relevant to the overall trust in the CA, and you really want
to make sure you have the lifecycle history... for the CA
certificate.</div>
</div>
</div>
</blockquote>
<p>Would having the entry/exit records from many years ago really
help demonstrate trust in the CA, though? Given that the CA
certificate can last 15-20 years, I'd be interested to hear what
forensic value a 10 year old CA facility entry/exit record would
have. I'm *not* saying that there is *no* value in retaining
records indefinitely - the question is what forensic value they
have versus the cost of their maintenance? Do you think that some
of the system records need to be extended to cover the lifetime of
all CA Certificates? In this case, move the facility entry/exit
records into 5.4.1 (1)?<br>
</p>
<p>[Note: this is not meant to be pejorative or ad absurdum
reasoning - it's a genuine query to get other viewpoints on what
information, in quality and quantity, is useful to those wishing
to evaluate the trustworthiness of a CA]<br></p></div></blockquote><div>I was actually arguing for the extreme: which is what, besides the firewall logs, should <i>not</i> be retained for the lifetime of the CA certificate? Which of these are only of limited use?</div><div><br></div><div>As long known, I'm not a fan of "only audits" for assurance, although they do play a valuable role. Any CA who has had to deal with me on a CA incident knows my persistence in trying to understand the systemic and root causes, and ensuring that more of these forensic details are actually shared.</div><div><br></div><div>Certificate profiles are, for an example, something that might be initially configured when a CA is starting, but they're not actually issuing certificates against those profiles. At some point, potentially years later, they decide they will start issuing, and something goes wrong. Do we have sufficient detail to understand what went wrong? On the surface level, it's easy to respond "Well, they should have checked those profiles were still current/acceptable according to the latest standards", and yes, that's true. But also understanding what the policies and practices were in place when those were originally configured, and how those policies/practices have been changed, is relevant.</div><div><br></div><div>Incidentally, and related to this, you can see there's a question about whether or not 15-20 year roots are good. I think the cost assumptions here assume the status quo, but I'm not discounting the possibility, and in fact supportive of, that the way to reduce the cost of that logging is to yield to shorter aggregate lifetimes, which has a host of other security benefits. It is, I readily admit, a set of tradeoffs here, but I mention this to acknowledge that the result may be shorter lifetimes, and I'm supportive of that.</div><div><br></div><div>(Snipping the questions I responded to above)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>So one obvious implication to this is that CAs no longer
have to log what software is installed on their system. As
long as it's not "security" software, the CA would argue
that under 5.4.1 (3)(2), installing software on the CA is
not itself the PKI system (e.g. EJBCA) or the security
system (e.g. the firewall/audit logging), ergo doesn't need
to be logged.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<p>Ah - I'm not sure that this is the case though. Any audit begins
with a system description, and the entire software manifest of a
host is definitely part of that description.</p></div></blockquote><div>I do not share your optimism on "definitely", and I think in some of the audit practices, it's not entirely the case. As shown by the shock and disapproval of the use of unreviewed, externally-provided automatic updates by some CAs. In theory, this is where the detailed control reporting, which would include the system description, would provide a more consistent understanding about whether that's the case. However, in the absence of that, the assumption has to be that it's not the case. We have to assume the worst, whether through malice or ignorance, because we constantly keep seeing new ways CAs surprise us :)</div><div><br></div></div></div>