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

Fri Jan 21 19:57:25 UTC 2022

> On Jan 20, 2022, at 2:54 AM, Dimitris Zacharopoulos (HARICA) via Servercert-wg <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?

> 
> Based on 3647, sections 5.4 and 5.5 are complementary and symmetrical. With that said, it appears that 5.5.2 repeats what is already required in 5.4.3 (1.), (2.) and (3.). I'm fine with repeating important text but I'm concerned that this might cause some confusion. We should probably clarify these terms a little better.
> 
> I would also like to propose that a NOTE is added at the end of sections 5.4.3 and 5.5.2:
> 
> In 5.4.3:
> 
> "Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past audit log events."
> 
> In 5.5.2:
> 
> "Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past records archived."
> 
> I would even recommend changing the MAY into a SHOULD if others agree.
As mentioned in the SCWG discussion yesterday, I would love feedback on this proposal from the broader group.

> 
> Dimitris.
> 
> On 19/1/2022 10:50 μ.μ., Aaron Gable via Servercert-wg 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?
>> 
>> 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.
>> 
>> 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>
>> 
>> 
>> _______________________________________________
>> 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>
> 
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220121/ea671982/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/20220121/ea671982/attachment-0001.p7s>