[Servercert-wg] Ballot SC38 - Alignment of Record Archival
Neil Dunbar
ndunbar at trustcorsystems.com
Wed Dec 16 12:31:09 UTC 2020
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.
Regards,
Neil
On 15/12/2020 16:42, Ryan Sleevi wrote:
> 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 <mailto: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
> <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 <mailto:Servercert-wg at cabforum.org>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://lists.cabforum.org/mailman/listinfo/servercert-wg>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20201216/0deeeefd/attachment.html>
More information about the Servercert-wg
mailing list