<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Following up on this: I've posted to NetSec with some suggested
improvements to tighten the text of SC28 to make the data storage
purpose/usage and data storage retention period more explicit in
each case for 1.3.2 and 4.1.1. We'll follow up (soon) with the
results of that discussion to this list.</p>
<p>Regards,</p>
<p>Neil<br>
</p>
<div class="moz-cite-prefix">On 15/12/2020 16:42, Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvbPdJPZt=Z7VKT42qropdaT5qzxqRbHT8eYCbmLaF9SHA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">Servercert-wg@cabforum.org</a><br>
<a
href="https://lists.cabforum.org/mailman/listinfo/servercert-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>