[cabf_netsec] Minutes from the Network Security Subcomittee meeting 2021-05-11

[Neil Dunbar]

All,

Attached for review are the minutes of the previous NetSec meeting. Any 
corrections or observations, please send to me.

Reminder that I won't be at the next meeting, and Ben Wilson has kindly 
agreed to step into the breach in my stead.

Best regards,

Neil

-------------- next part --------------
Network Security Subcommittee Minutes - 2021-05-11

Attendees

Neil Dunbar [TrustCor] (Chair)
Maileen Del Rosario [GoDaddy]
Corey Bonnell [DigiCert]
Corey Rasmussen [OATI]
Ben Wilson [Mozilla]
Trevoli Ponds-White [Amazon]
Tim Crawford [BDO]
David Kluge [Google]
Ali Gholami [Telia]
Tobia Josefowitz [Opera]
Janet Hines [SecureTrust]
Tim Hollebeek [DigiCert]
Brittany Randall [GoDaddy]
Kati Davids [GoDaddy]
Wendy Brown [FPKI]
Clint Wilson [Apple]

1. Review Agenda

Neil apologised regarding the late arrival of the agenda, which
was caused by permission errors in the mailing list system, since
corrected.

The agenda was agreed.

2. Agree Minutes

The minutes of previous meetings were agreed.

3. Cloud Services Team Update

David presented the updates from the Monday (2021-05-10) meeting of
the Cloud Services Team.

The team have continued to meet and work on the security requirements
document, on section 2 - the definition of the (currently) 3 tiers.
The definitions will then more accurately reflect what will services
will then occupy which tiers. The challenge is still to find good
criteria. The first tier is approaching complete definition, and this
will be the process for the next few calls.

Neil asked if the process remained the same - to define the tiers in
formal terms (for example, RTO and RPO) and then to move the services
from their intuitively positioned tiers into ones more appropriate
to their status, depending on the matching of the relevant criteria.

David replied that this was still the plan - to take the risks identified
and spell them out in the tiers. What makes the task non-trivial is that
it is not easy to spell out in formal criterion terms even well understood
terms like Confidentiality, Integrity and Availability, since the thresholds
are difficult to define as they pertain to different services.

4. Update to BR 4.1.1 Discussion Document

Clint introduced the newly uploaded document to the shared Google drive.

Clint wished to introduce a change which is not to remove Section 4.1.1,
but rather to blank it out, since it is part of the RFC. Tim (Hollebeek)
asked for the text to say "No stipulation" rather than making it completely
blank, that would be preferable.

Clint asked if this was a BR practice or rather a root policy one. Tim
replied that the Mozilla policy had been adjusted to cope with the
blank text issue, but that there was a working group agreement that
a blank entry indicated a section that the working group had not yet
reached to consider text. Tim considered that there is no good reason
to have blank sections in the BRs today, and that "No stipulation" is
much preferred.

Clint had no problem with changing to "No stipulation". Trev pointed out
that if it does not get added, all the CAs will have to manually add it.

Clint asked for reviews and edits to the document, so that endorsers could
be sought. Neil said that he would be happy to endorse the 4.1.1 ballot,
but would need discussion to endorse the 5.4 ballot.

5. Update to BR 5.4/5.4 Discussion Document

Clint introduced the uploaded document to the Google Drive.

No changes to the ballot have been made, but Clint wishes to change
section 5.4.1 and how the events defined interplay with 5.4.3.

Clint pointed out that the current 5.4.3(2) states that Subscriber
Certificate lifecycle management records need not be kept for 2 years
after the revocation or expiration of the certificate. Clint wishes
to remove the "revocation" clause and simply rely on expiration as
being the cutoff trigger. This stems from the fact that the generation
of OCSP Entries and CRLs must needs be retained for 2 years after
a certificate expires (per 5.4.1), but that this could mean, in the event that
a certificate was revoked early after its issuance that a gap could
emerge in the logging requirements around that certificate, which
is not a desirable outcome. Since log retention times and certificate
lifetimes have now shortened considerably, it seems like this would
not be a burdensome requirement, since a certificate could only be in
a revoked state for at most 389 days under the current BRs.

Tim liked the proposal, saying that it made the log cutoff far more
deterministic. Neil agreed. Tim added that if one needs to consult
revocation records to determine whether to archive log entries, it
makes the endeavor more complicated.

Trev also agreed. Tim asked the question if it doesn't make more sense
to stipulate that retention should be X years after the _issuance_
of the certificate, since lifetimes have such a low bound now.

Trev thought this was a good idea. Ben asked why this was a good thing,
and Tim added his observation that in his analysis, the logging requirements
end up as 3 years anyway, since its the lifetime of a 1 year certificate
plus 2 years, so why not 3 years from issuance.

Neil said this was a good point, since both lifetimes and retention
periods have shortened.

Trev said that perhaps the only reason for retaining expiration was
to maintain parity with Intermediate Subordinate CA certificates.

Neil then asked if it was worth splitting the 5.4.1 section into two
with one element requiring three years from issuance for Subscriber
Certificates, and 2 years after expiration for CA certificates and
security events. Tim thought that splitting makes sense. 

Neil pointed out that the CA certificate expiration would need to
continue to be the cutoff trigger, since CA certificate lifetimes are
not set by the BRs but are considerably longer than Subscriber Certificates,
which are constrained by the BRs. Neil added that if that change were
made then a note in the Considerations section would need to be made
to capture the essence of the discussion above.

Clint also wanted to emphasize that the expectations from the root
programs (at least Apple) is that the incident response requirements
do not change as a result of this ballot. Apple still expects all CAs
to provide a root cause analysis for all incidents, and a reduction
in retention time does not allow CAs to fail to provide an RCA owing
to the records having been expired.

Trev observed that the lack of records could be a second incident.
Neil thought this was indeed the case, but that it might be worth
stating this in the document. Tim said that the BRs and NSRs have no
root cause analysis so introducing this as a textual requirement would
be a new cause. Neil said that the text would go in the discussion
document, not the ballot itself.

There followed discussion which emphasized that the retention periods
are minima, and that CAs are allowed to retain for longer periods.

Clint said that he would like to emphasize the minimal nature of the
retention.

As before, Clint would like people to review and edits to the document.

6. Any Other Business

Neil will be absent for the next meeting, but Ben Wilson has agreed
to chair the meeting.

7. Adjourn

The meeting was adjourned and will reconvene on 2021-05-25.