<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 20, 2022, at 8:27 AM, Aaron Gable <<a href="mailto:aaron@letsencrypt.org" class="">aaron@letsencrypt.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">On Thu, Jan 20, 2022 at 7:39 AM Clint Wilson <<a href="mailto:clintw@apple.com" class="">clintw@apple.com</a>> wrote:<br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><div class=""><br class=""><div style="" class="">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”). </div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div style="" class=""><div class="">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?</div><div class=""><br class=""></div></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div class="">### 5.5.1 Types of records archived</div><div class=""><br class=""></div><div class="">The CA and each Delegated Third Party SHALL archive records relating to:</div><div class=""><br class=""></div><div class="">1. CA certificate and key lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (1));</div><div class="">2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2));</div><div class="">3. Security event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (3));</div><div class="">4. The security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and</div><div class="">5. Event records and documentation related to their verification, issuance, and revocation of certificate requests and Certificates</div></blockquote></div></div></blockquote><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">"""</div><div class="">### 5.5.1: Types of records archived</div><div class=""><br class=""></div><div class="">The CA and each Delegated Party SHALL archive all audit logs.</div><div class=""><br class=""></div><div class="">Additionally, they SHALL archive:</div><div class="">1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and</div><div class="">2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates.</div><div class=""><i class="">(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.)</i></div><div class=""><br class=""></div><div class="">### 5.5.2: Retention period for archive</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Additionally, the CA and each delegated party SHALL retain, for at least two (2) years:</div><div class="">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<br class="">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:</div><div class=""> 1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or<br class=""> 2. the expiration of the Subscriber Certificates relying upon such records and documentation.</div><div class=""><i class="">(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)</i></div><div class="">"""</div><div class=""><br class=""></div><div class="">Basically, this structure makes it clear that the records archival requirements are of the form "archive audit logs <i class="">and</i> this additional non-event documentation". I personally find this approach to be much clearer than the current repetitive phrasing.</div><div class=""><br class=""></div><div class="">What do you think?</div></div></div></div></blockquote>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.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Aaron</div></div></div>
</div></blockquote></div><br class=""></body></html>