[Servercert-wg] Discussion Period Begins on Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements

Fri Feb 11 19:03:58 UTC 2022

That would be best, yes.

-Tim

From: Clint Wilson <clintw at apple.com> 
Sent: Friday, February 11, 2022 1:56 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: ServerCert CA/BF <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Discussion Period Begins on Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements

Thanks Tim (and others that helped correct me here)! I think I also can/should update to basing it off of v1.8.1 of the BRs now as well?

On Feb 11, 2022, at 10:13 AM, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

Did you make changes to the version posted when the discussion period started?  If so, then we need to post a new version of the ballot and restart the discussion period.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Clint Wilson via Servercert-wg
Sent: Thursday, February 10, 2022 6:19 PM
To: ServerCert CA/BF <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Subject: Re: [Servercert-wg] Discussion Period Begins on Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements

I’ve incorporated the feedback received thus far into https://github.com/cabforum/servercert/compare/cda0f92ee70121fd5d692685b97ebb6669c74fb7...8398fb32ab21829b55ab4ca4f0cf9060ec44741a and plan to start the voting period for this ballot tomorrow. Please let me know if there are issues with this, or if there’s a preference for restarting a discussion period instead, and thanks to all for the input so far!

Cheers,

-Clint

On Jan 24, 2022, at 2:40 AM, Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr <mailto:dzacharo at harica.gr> > wrote:

On 21/1/2022 9:57 μ.μ., Clint Wilson wrote:

On Jan 20, 2022, at 2:54 AM, Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

Similarly with Aaron, I support the intent of this ballot but have similar concerns about the terms used in the ballot.

Back in May 2021, I sent this message <https://lists.cabforum.org/pipermail/netsec/2021-May/000449.html>  to the NetSec Subcommittee referring to RFC 3647 for guidance on the use of the terms "audit log" and "records archival". In my understanding the authors of RFC 3647 were trying to capture two different sets of "evidence". Each set would need to define the "types of events recorded/types of records archived", the "retention period", the "protection" controls, and the "backup" controls.

I agree that the authors of RFC 3647 intended for more detail to be included in a CPS around each of these sections than is currently in the BRs or added via the proposed changes in this ballot, however I don’t believe that RFC 3647 intends for 5.4 and 5.5 to represent two entirely different sets of “evidence”. For example, in section 4.5.4 (“Audit Logging Procedures”) it indicates that coverage should include “Frequency with which audit logs are processed or archived”. Similarly, in 4.5.5 (“Records Archival”) the RFC indicates that coverage should include “Types of records that are archived, for example all audit data….”. These references to archive and audits lead me to the interpretation that the authors of RFC 3647 intended for the records archival process to be an overarching collection and retention of audit data (i.e. everything logged in section 5.4) along with other data which may not be processed by event logging or audit systems (such as documentation supporting certificate applications). That is, as a Venn diagram, this is one circle inside another. This ballot attempts to clearly outline the end result of this relationship by delineating (and repeating, where relevant) the categories of data accounted for in both sections 5.4 and 5.5. Given Aaron’s feedback, I definitely think there’s room for improving how we outline that end result, however.

Of course, one could also imagine, in CA-specific scenarios and modernized validation/issuance processes, that all data processed by the CA goes through event logging systems, and therefore there would be no additional data beyond audit data present in the records archive. I don’t believe this ballot negatively impacts such a CA, but I would love to hear if there are perceived unintended implications from the proposed text which can be corrected.

I understand that RFC3647 has a different meaning in the term "archival" (used in the phrase "records archival") compared to this ballot.

Are there differences that would be helpful to share here? FWIW, my understanding is that archival is, as noted in 4.5.5 of RFC 3647, “records retention” — that is, the continued possession and control of a collection of records, typically (but not necessarily) on a less frequently used storage medium. Perhaps this would be worth including as a newly defined term, if there’s general agreement that this represents what an archive is meant to be in the context of 5.5?

The notion of retention is also included in 4.5.4 in the phrase "Period for which audit logs are kept" but I see your point.

I believe the interpretation that audit logs (described in section 5.4 of the BRs) are a subset of records archival (described in section 5.5) is fair and reasonable, and unless there are any objections, we should adopt it as such in the BRs by providing the necessary additional language. This will clarify the intent and expectations from CAs and auditors evaluating these requirements.

Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220211/ae1a86ae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5120 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220211/ae1a86ae/attachment-0001.p7s>