<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 02/06/2020 16:53, Ryan Sleevi wrote:<br>
</p>
<blockquote type="cite"
cite="mid:CACvaWvbbWRtT-Ffqo3XDoGN68zV2uzRdtG-aqvJEhdExRi4kfw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<div class="gmail_quote">
<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>
</div>
</blockquote>
<p>And I thought my construction was awkward! :-) Still, I can get
my head around that without much hassle.<br>
</p>
<blockquote type="cite"
cite="mid:CACvaWvbbWRtT-Ffqo3XDoGN68zV2uzRdtG-aqvJEhdExRi4kfw@mail.gmail.com">
<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">
<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>
<br>
</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>
</div>
</blockquote>
A few things spring to mind:
<ol>
<li>These events (in 5.4.1 (3)) are not directly linked to any
particular CA Private Key/Certificate. Thus to take the most
conservative reading, while a single CA Private Key exists, all
security events shall be recorded and held in an indexable form.
That seems to be a very high burden to bear. Whatever log
recording/indexing technology is used would probably no longer
be supported by the time that records could be expunged from the
logs.<br>
</li>
<li>I find it hard to understand why a record of a core dump
(5.4.1 (3)(4)) really needs to be recorded into eternity; it
seems to me that its utility decreases rapidly with age.</li>
<li>Entries to and exits from the CA facility: those are often not
directly controlled by the CA themselves. While a CA could
retain a copy of the entry records, the ability to speak
authoritatively would reside with the data centre. Again, were
this to be retained for the lifetime of a (which)?</li>
</ol>
<p>In short, the security events don't - in themselves - seem to add
more value with lengthier retention than what's already in 5.4.1
(1) and (2). I really can't see how the log of Joe's fumble
fingering his password is really of use some five years down the
line.<br>
</p>
<blockquote type="cite"
cite="mid:CACvaWvbbWRtT-Ffqo3XDoGN68zV2uzRdtG-aqvJEhdExRi4kfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<p>But that would seem to be arguing that certificate profile
changes should be recorded and maintained in reportable form
indefinitely; just in case that data might one day be useful.
Isn't that a cost without bound, and seemingly of radically
diminishing value.</p>
<p>I'm not saying that such data could _never_ be useful - again,
the tradeoff is whether the likely utility to bodies (external to
the CA, including, by extension, the general public) warrants the
cost to the CA.</p>
<p>However, I'll raise this with the NetSec team specifically.<br>
</p>
<blockquote type="cite"
cite="mid:CACvaWvbbWRtT-Ffqo3XDoGN68zV2uzRdtG-aqvJEhdExRi4kfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<p>Oh, wow. While I'm also a fan of getting shorter
root/intermediate lifetimes, that's a whole can of worms I'd
rather not open with this ballot!</p>
<blockquote type="cite"
cite="mid:CACvaWvbbWRtT-Ffqo3XDoGN68zV2uzRdtG-aqvJEhdExRi4kfw@mail.gmail.com">
<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">
<div>
<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.</div>
</div>
</div>
</blockquote>
Really? I just can't see how a system description is worthy of the
name without knowledge of what is on the box and what function it
performs. I'd welcome some auditors weighing in on this: my
assumption that a system description includes a software manifest
could very well be wrong, in which case the NetSec folks might want
to revisit the categories (remembering that the categories are the
bare minimum of what to record, not an exhaustive list).<br>
<blockquote type="cite"
cite="mid:CACvaWvbbWRtT-Ffqo3XDoGN68zV2uzRdtG-aqvJEhdExRi4kfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> 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>
</div>
</blockquote>
<p>OK - but I think that's a slightly different aspect than not
having to log the software manifest. No-one was talking in that
case about not logging the changes or being able to note what
changes had occurred. Indeed, if I recall, Dimitris explicitly
said that recording the changes was definitely part of the system
logs. It was merely whether the pre-approved repository formed a
valid change control process.</p>
<p>I guess what I'm getting at is that I don't see that the shift to
the proposed wording makes the situation _worse_ in terms of what
should be logged. You may very well be justified in disagreeing;
alternatively you may be arguing that specifically recording
software manifest changes are explicitly security events, and as
such should be called out in 5.4.1 (3). Would appreciate your
thoughts.</p>
<p>Anyway - the feedback is still very much appreciated.<br>
</p>
</body>
</html>