<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
I read the minutes of the netsec subcommittee and have some
questions/comments regarding sections 5.4 and 5.5 of the BRs.<br>
<br>
First of all, I believe it would be useful for members to refresh
their recollection of RFC 3647 because it might resolve some of the
confusion on this topic.<br>
<br>
In RFC 3647, sections 5.4 and 5.5 are pretty much structured the
same way. Here's the relevant structure:<br>
<br>
5.4 Audit Logging Procedures<br>
------------------------------------------------------<br>
5.4.1 <b>T</b><b>ypes of Events Recorded</b><br>
------------------------------------------------------<br>
5.4.2 Frequency of Processing Log<br>
------------------------------------------------------<br>
5.4.3 <b>Retention Period for Audit Log</b><br>
------------------------------------------------------<br>
5.4.4 <b>Protection of Audit Log</b><br>
------------------------------------------------------<br>
5.4.5 <b>Audit Log Backup Procedures</b><br>
------------------------------------------------------<br>
5.4.6 Audit Collection System (Internal vs. External)<br>
------------------------------------------------------<br>
5.4.7 Notification to Event-Causing Subject<br>
------------------------------------------------------<br>
5.4.8 Vulnerability Assessments<br>
------------------------------------------------------<br>
5.5 Records Archival<br>
------------------------------------------------------<br>
5.5.1 <b>Types of Records Archived</b><br>
------------------------------------------------------<br>
5.5.2 <b>Retention Period for Archive</b><br>
------------------------------------------------------<br>
5.5.3 <b>Protection of Archive</b><br>
------------------------------------------------------<br>
5.5.4 <b>Archive Backup Procedures</b><br>
------------------------------------------------------<br>
5.5.5 Requirements for Time-Stamping of Records<br>
------------------------------------------------------<br>
5.5.6 Archive Collection System (Internal or External)<br>
------------------------------------------------------<br>
5.5.7 Procedures to Obtain and Verify Archive Information<br>
<br>
In my understanding, section 5.4 focuses on "events", and guidance
is provided in section <a moz-do-not-send="true"
href="https://datatracker.ietf.org/doc/html/rfc3647#section-4.5.4">4.5.4</a>
of the RFC. This includes events recorded that are related to
certificate lifecycle operations. However, this is just for
"events", which are actions captured/performed by systems and humans
and are captured in databases, log files and other transactions.<br>
<br>
It is clear to me that the intent of the authors of RFC 3647 is for
a CA to include <b>policy </b>to set the <b>retention period</b>
of these "Audit Logs" (documented in 5.4.3 of the CA's CP/CPS), <b>protection
control</b><b>s</b> for these "Audit Logs" (so they cannot be
tampered with and/or deleted), and <b>backup </b>controls so they
cannot be recovered.<br>
<br>
Section 5.5 focuses on "Records", and guidance is provided in
section <a
href="https://datatracker.ietf.org/doc/html/rfc3647#section-4.5.5"
moz-do-not-send="true">4.5.5</a> of the RFC. That could be
documentation supporting certificate applications,
identity/organization evidence, ceremony scripts, audit reports, in
general any supporting evidence that "is not an event"!<br>
<br>
Similarly with the "events", a CA should set policy for the <b>retention
period</b> of these "records" (documented in 5.5.2 of the CA's
CP/CPS),<b> protection controls</b>, <b>backup </b>of these
records, and so on.<br>
<br>
As an example, think of a CA having a new subCA ceremony. This task
includes both "events" being captured (key generation, issuance of
the subCA certificate), and "records" being recorded (a ceremony
script, paper logs where trusted role members sign-off, possibly
configuration files).<br>
<br>
I believe the "events" fall under section 5.4 and "records" fall
under section 5.5. From a policy perspective, we have the
flexibility to set different retention and protection for these two
types but the safest approach would be to keep them aligned. <br>
<br>
I would be in favor of the NetSec subcommittee:<br>
<ol>
<li>clarifying this interpretation of "what is an event" and "what
is a record", <br>
</li>
<li>populate 5.5.1 with the "categories" described in 5.4.1, and
then <br>
</li>
<li>carefully check which particular "tasks" make sense for 5.4.1
and 5.5.1</li>
<li>update 5.4.3 and 5.5.2 to include language to describe either
BOTH retention periods (some <b>events/records</b> may need to
be retained for 2 years and some for 7) OR agree on a 2
year-make-sense-for-all policy.<br>
</li>
</ol>
Finally, we should update the title of 5.4.2 to match RFC 3647.<br>
<br>
Thoughts?<br>
Dimitris.<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/5/2021 6:28 μ.μ., Neil Dunbar via
Netsec wrote:<br>
</div>
<blockquote type="cite"
cite="mid:010001795c0b5013-dc0f621c-a42f-4f57-8068-217d0e879c26-000000@email.amazonses.com">All,
<br>
<br>
These were actually sent out a while back, but for some reason
didn't make it to the list - apparently I was a non-member... I
think I've fixed list permissions, but hopefully this gets through
now.
<br>
<br>
Meeting minutes are attached below - all comments gratefully
received.
<br>
<br>
Regards,
<br>
<br>
Neil
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Netsec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Netsec@cabforum.org">Netsec@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/netsec">https://lists.cabforum.org/mailman/listinfo/netsec</a>
</pre>
</blockquote>
<br>
</body>
</html>