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

[Ryan Sleevi]

On Tue, Jun 2, 2020 at 5:42 AM Neil Dunbar via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> (Snipped all the other changes, that sound good)
>


> 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.
> https://github.com/cabforum/documents/issues/187 ), but it seems
> appropriate to try and tackle this.
>
> 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:
>
> [...] 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
>
> Does this allow wiggle room which we would rather not allow? Is there
> something more succinct that we can use (highly probable)?
>
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.

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:

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

        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.
>
> 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)?
>
> [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]
>
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?

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.

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.

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.

(Snipping the questions I responded to above)

> 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.
>
> 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. 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200602/9273242c/attachment-0001.html>