[Servercert-wg] Ballot SC28: Logging and Log Retention

[Neil Dunbar]

On 02/06/2020 16:53, Ryan Sleevi wrote:

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

And I thought my construction was awkward! :-) Still, I can get my head
around that without much hassle.

>>                 3. any security event records (as set forth in
>>         Section 5.4.1.3)
>>         after the event occured.
>>
>>
>>     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.
>
> I was actually arguing for the extreme: which is what, besides the
> firewall logs, should /not/ be retained for the lifetime of the CA
> certificate? Which of these are only of limited use?
A few things spring to mind:

 1. 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.
 2. 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.
 3. 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)?

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.

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

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.

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.

However, I'll raise this with the NetSec team specifically.

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

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!

>     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.
>
> I do not share your optimism on "definitely", and I think in some of
> the audit practices, it's not entirely the case.
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).
> 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 :)

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.

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.

Anyway - the feedback is still very much appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200602/b611f839/attachment.html>