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

Thu Jan 20 15:39:13 UTC 2022

> On Jan 19, 2022, at 12:49 PM, Aaron Gable <aaron at letsencrypt.org> wrote:
> 
> I fully support the intent of this ballot, but upon close reading I have some slight concern.
> 
> Although this ballot brings the definitions from the NCSSRs directly into the BRs, those definitions do not include a definition of the words "retain" or "archive". This causes me some confusion.
> 
> My reading of the structure of this ballot is essentially:
> 1) A CA must record events X, Y, Z to an audit log
> 2) A CA must retain those audit logs for 2 years after A, B, C
> 3) A CA must archive records X, Y, Z, W, V
> 4) A CA must retain archives for 2 years after A, B, C
> 
> With no functional definition of the word "archive", it is unclear what the purpose of having both of these sections at all is. With the exception of the additional numbered items 5.2.2.(4) and 5.2.2.(5), the two sections appear to be essentially identical. A CA which stores all required records on a single hard drive appears to be equally in compliance with both sections. So why have both sections at all?
I believe this to be a correct reading of the requirement. I think the primary reason there are 2 sections covering all this is simply that RFC3647 defines these as two separate sections with related, but separate, activities involved (“5.4 Audit Logging Procedures” and “5.5 Records Archival”). 
But further, perhaps reading too far into the question, why bother expanding the text in these sections so much instead of collapsing the already minimal 5.5.2 into 5.4.1 or similar? I think this came down to wanting to clarify the data processing sequence and even to highlight some of what you’re asking here, namely that audit logs are a precursor to the records archival step — one feeds into the next. The expansion of text (most of it identical) was to help make it clearer that there is an expected sequencing to these processes.
Another point that was brought up previously in discussion (and part of why text is duplicated between sections) is to preserve the notion that these sections’ requirements may diverge further in the future; while they’re very similar datasets now, that may not always be the case.

Are you thinking that it would be more clear to outline all the data (logged, collected, etc.) that needs to be present in the Records Archive and more or less leave it at that (i.e. consolidate everything into 5.5.1/5.5.2)?
> 
> Additionally, I find the phrasing of Section 5.5.1 to be unfortunate: it contains two sentences, both of which start "The CA and each Delegated Third Party SHALL archive records related to...". These should be combined into a single bulleted list, much as Section 5.5.2 does.
This was done in part to create direct comparability between 5.5.1 and 5.4.3, however if there’s little to no perceived value in that structure, the section could be combined, I think. I had made some prior attempts at this, which didn’t result in very readable text primarily due to the addition of documentation as input to the archive on top of the event records coming from audit logs. However, maybe something like this could work?

### 5.5.1 Types of records archived

The CA and each Delegated Third Party SHALL archive records relating to:

1. CA certificate and key lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (1));
2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2));
3. Security event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (3));
4. The security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and
5. Event records and documentation related to their verification, issuance, and revocation of certificate requests and Certificates
> 
> Aaron
> 
> On Thu, Jan 13, 2022 at 11:02 AM Clint Wilson via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
> This email begins the discussion period for Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements
> 
> BALLOT SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements
> 
> PURPOSE OF BALLOT
> 
> The purpose of this ballot is to consolidate and clarify aspects of audit log and records archival retention expectations and time-periods within 5.5.2.
> 
> Foremost, this ballot reduces retention periods for records archival to 2 years.
> Further, currently audit log events as outlined in section 5.4.1, and then referenced in 5.4.3 lead to confusion around the log retention that is defined and exclusive to each section, and how that retention feeds into records archival requirements. To further clarify the objectives of that interaction, an explicit requirement has been introduced in 5.5.1 stating that CAs must archive lifecycle event records.
> 
> As minor adjustments to related requirements, this ballot also clarifies what is expected by the term “OCSP Entries” as a logged lifecycle event; as OCSP Entry is an undefined term, this was replaced with OCSP Response such that it should be clear that a CA will be logging the event of signing an OCSP Response (including the elements stipulated in 5.4.1). Similarly, some certificate lifecycle events expected to be retained are currently separated into 5.5.2; these have been incorporated into 5.4.1 instead. This ballot also explicitly calls out the need for delegated third parties to abide by the established retention periods for audit logging and records archival procedures.
> This ballot also formalizes incorporation of terms defined in the NCSSRs as also applying to the BRs.
> 
> MOTION
> 
> The following motion has been proposed by Clint Wilson of Apple and endorsed by Trevoli Ponds-White of Amazon and Dustin Hollenback of Microsoft.
> 
> -----Motion Begins-----
> 
> This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as defined in the following redline, based on Version 1.8.0:
> 
> https://github.com/cabforum/servercert/compare/cda0f92ee70121fd5d692685b97ebb6669c74fb7...63dc6210e728349bb4602e4ede051efed593a91c <https://github.com/cabforum/servercert/compare/cda0f92ee70121fd5d692685b97ebb6669c74fb7...63dc6210e728349bb4602e4ede051efed593a91c>
> 
> -----Motion Ends-----
> 
> This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
> 
> Discussion (7+ days)
> 
> Start Time: January 13 2022 19:00 UTC
> End Time: January 20 2022 19:00 UTC
> 
> Vote for approval (7 days)
> 
> Start Time: TBD
> End Time: TBD
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://lists.cabforum.org/mailman/listinfo/servercert-wg>

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