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

[Ryan Sleevi]

On Wed, May 27, 2020 at 10:39 AM Neil Dunbar via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Section 5.4.1
>
> The CA and each Delegated Third Party SHALL record details of the
> actions taken to process a certificate request and to issue a
> Certificate, including all information generated and documentation
> received in connection with the certificate request; the time and date;
> and the personnel involved. The CA SHALL make these records available to
> its Qualified Auditor as proof of the CA’s compliance with these
> Requirements.
>
> The CA SHALL record at least the following events:
>

Just a note: In the GitHub redline, this is repeated twice :) I realize
it's not official, but it stood out ;)


> Insert, as Section 5.4.3. Retention Period for Audit Logs of the
> “Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Certificates”, the following:
>
>     The CA SHALL retain, for at least two years:
>

My first glance when reading this is that it reads a little weird, and I
can easily see it leading to misinterpretation. "For at least two years"
reads as a period since the event happened, but that's not actually the
case - it's for at least two years *following* a different event (namely,
destruction/revocation/expiration).

I don't have a great concrete solution here, but if it helps settle any
debates, it does seem confusing :P I'm loath to introduce a term like "log
retention period", but that might help? e.g. "The log retention period for
CA certificate and key lifecycle management event records shall be from the
moment of the event until at least two years after the ..."?


>
>         1. CA certificate and key lifecycle management event records (as

set forth in Section 5.4.1.1)


1) This is a little confusing on terminology. 5.4.1 stipulates the CA SHALL
record, but then later in the same section, states "Log entries". Are "log
entries" "log records"? Should we align the two terms.
  Suggestion: Pick a term (i don't care which) and let's use it
consistently, either as "log entries" or "log records", or highlight why
they're distinct/different

2) There is no Section titled 5.4.1.1; there's a Section 5.4.1 with a
bulleted list that has a 1. We don't really have an established notation
here, but I don't think we've treated all numbered lists as inherently
subsections (notoriously, 4.9.1.1's requirements are hard to cite).
  Suggestion: Tease 5.4.1 into sub-sections, and move the requirements that
follow the list into the top-level 5.4.1 as applying to all of those
subsections?


> after either: the destruction of the CA
>

CA _Private_ Key


> key, or the revocation or expiration of the CA certificate, whichever
>

s/certificate/Certificate/ (we consistently case-match Certificate in the
BRs)


> occurs later.
>

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.


>
>         2. Subscriber Certificate lifecycle management event records (as
> set forth in Section 5.4.1.2) after the revocation or expiration of the
> Subscriber Certificate


This seems fine


>         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 may not be
fully appreciating the scope of the challenge, and I know it'll be
laughable coming from a Googler, but "terabytes of data" does not sound
'that' hard, especially given the vital role of CAs.

It seems like the focus on this ballot is "If there's something to catch,
we would have caught it sooner", but I'm moreso interested in the "If
something goes wrong, we can really understand how, where, and why it went
wrong". I can appreciate the argument that no one would be patient enough
to wait two years before doing shenanigans, but some of these things (like
Certificate Profiles) are totally things that have gone years before
shenanigans/issues caught.


>
> Delete from “Network and Certificate Systems Security Requirements”,
> Version 1.3, Section 3.b
>
>     b.  Identify those Certificate Systems under the control of CA or
> Delegated Third Party Trusted Roles capable of monitoring and logging
> system activity and enable those systems to continuously monitor and log
> system activity;
>
> Insert new “Network and Certificate Systems Security Requirements”,
> Version 1.3, Section 3.b with the following text:
>
>     b.  Identify those Certificate Systems under the control of CA or
> Delegated Third Party Trusted Roles capable of monitoring and logging
> system activity, and enable those systems to log and continuously
> monitor the events specified in Section 5.4.1.3 of the Baseline
> Requirements for the Issuance and Management of Publicly-Trusted
> Certificates;
>

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.

I definitely appreciate the effort to bring more of the NCSSRs in harmony
with the BRs, potentially permitting their eventual integration of the
useful bits, but some of the places of broad applicability are useful (for
Root Programs), even if burdensome (for CAs).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200527/7d4f6fa4/attachment-0001.html>