[Servercert-wg] Ballot SC38 - Alignment of Record Archival

[Ryan Sleevi]

Hey Neil,

I just wanted to make sure to capture on the list what we discussed on the
call.

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.

It seems both of these sections benefit from the current duration, and
would potentially lose out from the shorter duration.

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).

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 *should* 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.

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.


On Wed, Dec 9, 2020 at 5:37 AM Neil Dunbar via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> This begins the discussion period for Ballot SC38: Alignment of Record
> Archival (which I circulated a little while ago).
>
> The following ballot is proposed by Neil Dunbar of TrustCor Systems and
> endorsed by David Kluge of Google Trust Services and Ben Wilson of Mozilla.
>
> Purpose of Ballot:
>
> After the updated language included in SC28 Sections 5.4.3 and 5.5.2 (of
> the BRs) could be in conflict. Section 5.5.2 requires all documentation
> relating to certificate requests and the verification thereof, and all
> Certificates and revocation thereof be retained for seven years after
> certificates cease to to be valid. Section 5.4.3 requires all audit logs
> of Subscriber Certificate lifecycle management event records be
> maintained for two years after the revocation or expiration of the
> Subscriber Certificate. These sections intersect at the retention
> requirements for audit logs and archived records, as they relate to
> subscriber certificate lifecycle events. The retention periods are in
> conflict as to the length of retention.
>
> The proposed changes seek to bring these two sections of the “Baseline
> Requirements” into agreement and avoid confusion and potential issues of
> noncompliance as they relate to retention periods.
>
> The NetSec discussion document for this ballot is attached as a PDF to
> this email.
>
> -- MOTION BEGINS --
>
> Delete the following Section 5.5.2 Retention period for archive from the
> “Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Certificates”, which currently reads as follows:
>
> The CA SHALL retain all documentation relating to certificate requests
> and the verification thereof, and all Certificates and revocation
> thereof, for at least seven years after any Certificate based on that
> documentation ceases to be valid.
> Insert, as Section 5.5.2. Retention period for archive of the “Baseline
> Requirements for the Issuance and Management of Publicly-Trusted
> Certificates”, the following:
>
> The CA SHALL retain all documentation relating to certificate requests
> and the verification thereof, and all Certificates and revocation
> thereof, for at least two years after any Certificate based on that
> documentation ceases to be valid.
>
> -- MOTION ENDS --
>
> * WARNING *: USE AT YOUR OWN RISK. THE REDLINE BELOW IS NOT THE OFFICIAL
> VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
>
> A comparison of the changes can be found at:
> https://github.com/cabforum/documents/compare/8f63128...neildunbar:180341b
>
> This ballot proposes one Final Maintenance Guideline.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion: (7+ days)
> Start Time: 2020-12-09 17:00 UTC
> End Time: not before 2020-12-16 17:00 UTC
>
> Vote for approval: (7 days)
> Start Time: TBD
> End Time: TBD
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20201215/ce1bb1e6/attachment.html>