<div dir="ltr"><div>Hey Neil,</div><div><br></div><div>I just wanted to make sure to capture on the list what we discussed on the call.</div><div><br></div><div>Unlike Section 5.4.3, 5.5.2 has two cross-references: Section 1.3.2 (Registration Authorities) and Section 4.1.1 (Who can submit a certificate application), and thus, this change could be interpreted as impacting both. As I believe both you and Trev captured, I do agree that it's likely that, in practice, CAs think of both of these functions (1.3.2 / 4.1.1) as separate purposes than 5.4.3, however, that's not presently explicitly stated.</div><div><br></div><div>It seems both of these sections benefit from the current duration, and would potentially lose out from the shorter duration.</div><div><br></div><div>For 4.1.1, it requires the CA to maintain a database of revoked Certificates and requests rejected because the CA believes they are suspicious, in order to identify future requests. As I believe Tim mentioned, in practice, this means much like the "High Risk Request" requirement, which is to say that it doesn't afford any normalized practices (e.g. the requirement is merely to /identify/ such requests, not /reject/ them, nor take any other action other than mere identification). As such, the information storage here is, at minimum, a single bit-per-certificate/request, indicating "revoked/rejected", and so the arguments for reducing the lifetime used for 5.4.3 aren't really as applicable. However, what is useful is the ability to examine this information in light of incidents (e.g. forensic purposes).</div><div><br></div><div>For 1.3.2, this relates to the use of Registration Authorities / Delegated Third Parties. As discussed on the call, with the exception of Section 3.2.2.4 / 3.2.2.5, RAs/DTPs are effectively performing as the CA. While this makes it tempting to lump it in with the past changes to 5.5.2, saying "Whatever was good for the CA is good for the RA", a significant difference here is that an RA lacks both the transparency that the ecosystem benefits from for CAs (e.g. via Certificate Transparency), and because a given RA may be used by multiple different CAs (which was, in part, one of the goals for RAs as a concept). When it comes to evaluating an RA, whether for a new business relationship (e.g. new CA) or as part of the regular review of existing relationships, the timescales involved in consideration are necessarily longer than that for CAs, precisely because the lack of other visibility into their practices. A CA <b>should</b> examine more than two/three years of issuance from an RA before entering into/continuing a relationship with an RA, carefully examining the documents provided to/by the RA to their decision/recommendation to the CA to issue (effectively, an audit). I realize this might sound like an argument for RA audits (which WebTrust provides, while ETSI... doesn't), but hopefully we've learned from the CA ecosystem that audits alone are not enough to make effective or meaningful decisions.</div><div><br></div><div>It sounded like next steps were for the NetSec WG to revisit this, examining the interplay between these sections, and working to provide a recommendation for browsers and CAs in the broader SCWG to consider before considering this ballot.</div><div> </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 5:37 AM Neil Dunbar via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This begins the discussion period for Ballot SC38: Alignment of Record <br>
Archival (which I circulated a little while ago).<br>
<br>
The following ballot is proposed by Neil Dunbar of TrustCor Systems and <br>
endorsed by David Kluge of Google Trust Services and Ben Wilson of Mozilla.<br>
<br>
Purpose of Ballot:<br>
<br>
After the updated language included in SC28 Sections 5.4.3 and 5.5.2 (of <br>
the BRs) could be in conflict. Section 5.5.2 requires all documentation <br>
relating to certificate requests and the verification thereof, and all <br>
Certificates and revocation thereof be retained for seven years after <br>
certificates cease to to be valid. Section 5.4.3 requires all audit logs <br>
of Subscriber Certificate lifecycle management event records be <br>
maintained for two years after the revocation or expiration of the <br>
Subscriber Certificate. These sections intersect at the retention <br>
requirements for audit logs and archived records, as they relate to <br>
subscriber certificate lifecycle events. The retention periods are in <br>
conflict as to the length of retention.<br>
<br>
The proposed changes seek to bring these two sections of the “Baseline <br>
Requirements” into agreement and avoid confusion and potential issues of <br>
noncompliance as they relate to retention periods.<br>
<br>
The NetSec discussion document for this ballot is attached as a PDF to <br>
this email.<br>
<br>
-- MOTION BEGINS --<br>
<br>
Delete the following Section 5.5.2 Retention period for archive from the <br>
“Baseline Requirements for the Issuance and Management of <br>
Publicly-Trusted Certificates”, which currently reads as follows:<br>
<br>
The CA SHALL retain all documentation relating to certificate requests <br>
and the verification thereof, and all Certificates and revocation <br>
thereof, for at least seven years after any Certificate based on that <br>
documentation ceases to be valid.<br>
Insert, as Section 5.5.2. Retention period for archive of the “Baseline <br>
Requirements for the Issuance and Management of Publicly-Trusted <br>
Certificates”, the following:<br>
<br>
The CA SHALL retain all documentation relating to certificate requests <br>
and the verification thereof, and all Certificates and revocation <br>
thereof, for at least two years after any Certificate based on that <br>
documentation ceases to be valid.<br>
<br>
-- MOTION ENDS --<br>
<br>
* WARNING *: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT THE OFFICIAL <br>
VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):<br>
<br>
A comparison of the changes can be found at: <br>
<a href="https://github.com/cabforum/documents/compare/8f63128...neildunbar:180341b" rel="noreferrer" target="_blank">https://github.com/cabforum/documents/compare/8f63128...neildunbar:180341b</a><br>
<br>
This ballot proposes one Final Maintenance Guideline.<br>
<br>
The procedure for approval of this ballot is as follows:<br>
<br>
Discussion: (7+ days)<br>
Start Time: 2020-12-09 17:00 UTC<br>
End Time: not before 2020-12-16 17:00 UTC<br>
<br>
Vote for approval: (7 days)<br>
Start Time: TBD<br>
End Time: TBD<br>
<br>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div></div>