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

Aaron Gable aaron at letsencrypt.org
Fri Jan 21 23:26:55 UTC 2022


I'll make one small edit to my own proposal: The first line of 5.5.2 should
be more like
"""
Archived audit logs (as set forth in [Section 5.5.1](...) SHALL be retained
for a period of...
"""
Just to be more consistent with the usage of the word "retained".

On Fri, Jan 21, 2022 at 12:12 PM Clint Wilson <clintw at apple.com> wrote:

>
>
> On Jan 20, 2022, at 8:27 AM, Aaron Gable <aaron at letsencrypt.org> wrote:
>
> On Thu, Jan 20, 2022 at 7:39 AM Clint Wilson <clintw at apple.com> wrote:
>
>>
>> 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”).
>>
>
> This makes some sense, and I believe that the RFC3647 distinction between
> audit logging and records archival can certainly be a valuable one. But in
> my mind all of that value comes from the difference in how these two things
> are protected, backed up, and accessed (e.g. presumably audit logs should
> be easily accessible so that they can be "processed"; while records
> archives should be more securely backed up and protected so that auditing
> can still occur in case of disaster). Since this ballot still leaves those
> subsections empty (i.e. no stipulation) it is not clear to me that
> repeating nearly-identical "types of records" and "period of retention"
> sections has value.
>
>>
>> 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
>>
>>
> Yep, this is exactly what I was thinking of when I sent my last email, but
> now I have a proposal I like even better. I think it would make the most
> sense to say something like:
>
> """
> ### 5.5.1: Types of records archived
>
> The CA and each Delegated Party SHALL archive all audit logs.
>
> Additionally, they SHALL archive:
> 1. Documentation related to the security of their Certificate Systems,
> Certificate Management Systems, Root CA Systems, and Delegated Third Party
> Systems; and
> 2. Documentation related to their verification, issuance, and revocation
> of certificate requests and Certificates.
> *(ed note: the phrase "event records" has been removed from the second
> bullet, as that is covered by the "audit logs" in the first sentence.)*
>
> ### 5.5.2: Retention period for archive
>
> Audit logs must be archived for a period of at least two (2) years from
> their record creation timestamp, or as long as they are required to be
> retained per Section 5.4.3, whichever is longer.
>
> Additionally, the CA and each delegated party SHALL retain, for at least
> two (2) years:
> 1. All archived documentation related to the security of Certificate
> Systems, Certificate Management Systems, Root CA Systems and Delegated
> Third Party Systems (as set forth in [Section
> 5.5.1](#551-types-of-records-archived)); and
> 2. All archived documentation relating to the verification, issuance, and
> revocation of certificate requests and Certificates (as set forth in
> [Section 5.5.1](#551-types-of-records-archived)) after the later occurrence
> of:
>    1. such records and documentation were last relied upon in the
> verification, issuance, or revocation of certificate requests and
> Certificates; or
>    2. the expiration of the Subscriber Certificates relying upon such
> records and documentation.
> *(ed. note: the first three bullets here have been removed as they are
> covered by the first sentence, and the phrase "records and" has been
> removed from the two remaining bullet points for the same reason)*
> """
>
> Basically, this structure makes it clear that the records archival
> requirements are of the form "archive audit logs *and* this additional
> non-event documentation". I personally find this approach to be much
> clearer than the current repetitive phrasing.
>
> What do you think?
>
> I like it. I might add “audit logs, as defined in section 5.4….” or
> something along those lines, but otherwise I think this conveys the same
> information and if the group generally feels that it does so in a clearer
> manner, then I’m all for it. If there is support and there are no
> objections, I’ll plan on incorporating this language in the branch.
>
>
> Aaron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220121/c42e14bd/attachment.html>


More information about the Servercert-wg mailing list