<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 21/1/2022 9:57 μ.μ., Clint Wilson
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1B77C6AD-6C70-47DF-BE64-5887BD0332B1@apple.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <br class="">
      <div><br class="">
        <blockquote type="cite" class="">
          <div class="">On Jan 20, 2022, at 2:54 AM, Dimitris
            Zacharopoulos (HARICA) via Servercert-wg <<a
              href="mailto:servercert-wg@cabforum.org"
              class="moz-txt-link-freetext" moz-do-not-send="true">servercert-wg@cabforum.org</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <meta http-equiv="Content-Type" content="text/html;
              charset=UTF-8" class="">
            <div class=""> Similarly with Aaron, I support the intent of
              this ballot but have similar concerns about the terms used
              in the ballot.<br class="">
              <br class="">
              Back in May 2021, I sent <a moz-do-not-send="true"
                href="https://lists.cabforum.org/pipermail/netsec/2021-May/000449.html"
                class="">this message</a> 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.<br class="">
            </div>
          </div>
        </blockquote>
        <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"
          class="">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 <i class="">how</i><span style="font-style:
            normal;" class=""> we outline that end result, however.</span></div>
        <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"
          class=""><br class="">
        </div>
        <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"
          class="">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.</div>
        <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"
          class=""><br class="">
        </div>
        <blockquote type="cite" class="">
          <div class="">
            <div class=""> <br class="">
              I understand that RFC3647 has a different meaning in the
              term "archival" (used in the phrase "records archival")
              compared to this ballot.<br class="">
            </div>
          </div>
        </blockquote>
        <font class="" color="#000000"><span style="caret-color: rgb(0,
            0, 0);" class="">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?</span></font></div>
    </blockquote>
    <br>
    The notion of retention is also included in 4.5.4 in the phrase
    "Period for which audit logs are kept" but I see your point.<br>
    <br>
    I believe the interpretation that audit logs (described in section
    5.4 of the BRs) are a subset of records archival (described in
    section 5.5) is fair and reasonable, and unless there are any
    objections, we should adopt it as such in the BRs by providing the
    necessary additional language. This will clarify the intent and
    expectations from CAs and auditors evaluating these requirements.<br>
    <br>
    Dimitris.<br>
  </body>
</html>