[cabf_netsec] Meeting minutes for NetSec 2021-04-27

[Neil Dunbar]

All,

These were actually sent out a while back, but for some reason didn't 
make it to the list - apparently I was a non-member... I think I've 
fixed list permissions, but hopefully this gets through now.

Meeting minutes are attached below  - all comments gratefully received.

Regards,

Neil

-------------- next part --------------
Network Security Subcommittee Minutes - 2021-04-27

Attendees

Neil Dunbar (TrustCor) [Chair]
Corey Bonnell (DigiCert)
David Kluge (Google)
Tobias Josefowitz (Opera)
Kati Davids (GoDaddy)
Ben Wilson (Mozilla)
Bruce Morton (Entrust)
Tim Hollebeek (DigiCert)
Maileen Del Rosario (GoDaddy)
Dustin Hollenback (Microsoft)
Tim Crawford (BDO)
Clint Wilson (Apple)
Brittany Randall (GoDaddy)
Trevoli Ponds-White (Amazon)

1. Review Agenda

The agenda was approved.

2. Approval of Minutes

Because of a delay in producing the minutes, it was agreed to wait until
next meeting to approve all outstanding minutes.

3. Cloud Service Team Update

David mentioned that the team had a good meeting on Monday to continue
the draft document; concentrating on the second section on CA specific
risks, as opposed to general risks and standards in the first section.

The team agreed on how to design the different tiers into how cloud
services might fall. Instead of a general process to assign tiers to
services, the team will be examining how the specific risks apply to
each service (e.g. whether the service processes PII, RTO and RPO considerations)
and based on that analysis, define the tiers.

David stressed that it is very much a work in progress, but good progress
is being made. David continues to invite all interested parties to Review
and contribute to the document as they wish.

Neil added that the tier definition process is to build on the standard
analyses over confidentiality, integrity and availability; and attempting
to assign services into tiers depending on the level of commitment and risk
from and to the CA. Ben mentioned that the starting diagram is done, but
we might end up shifting where those services belong. Neil agreed, and
said that the idea was to have a true calculus as to where services end up,
starting from the initial, more intuitive, position.

Neil also mentioned that there was discussion on whether the document should be in
RFC 3647 format, but that no decision had been reached. David mentioned
that for drafting purposes, we should keep the document as is, but once
formalised, it might be that either CA's could make disclosures in an appendix
to their CPS'es, or restructure the document into RFC 3647 so that CA's
could make appropriate statements into the CPS document proper.

4. Update to BR 4.1.1 Ballot

Clint mentioned that the ballot text is consolidating a bit, and that the
ballot is down to two minimal changes. The first section is still removing
the 4.1.1 text completely, and the second change is to no longer try to
introduce new text in 4.1.1, and the text for a process for identifying
and tracking of compromised keys should fit into 6.1.1.3 in a fairly
straightforward manner.

The ballot description still needs to be written up, but the pull request
was published.

Clint did ask whether "Trustworthy System or process" could be shortened
to "Trustworthy System". Neil thought that was appropriate given the
definition. Tim (Hollebeek) said that he would prefer only "Trustworthy
System" but wanted the text to reflect that the systems need not _only_
be doing weak key detection and tracking. Clint agreed to work that into
the text.

5. Update to BR 5.4/5.5 Ballot

Clint mentioned that the ballot updates the list of loggable categories
in 5.4.1, then move 5.4.3 into section 5.5.2. Clint asked if something should
be left in 5.4.3 to cross reference into 5.5.2.

Ben thought that for readers who don't understand English too well, it
might well be useful to add in a reference.

The major changes were pulling apart certificate requests and OCSP entries;
deriving from OCSP entries not being a defined term, and the text makes
it more explicit. Item 3 is the subscriber certificate lifecycle events
is new, but incorporates the events which were in 5.5.2 hitherto.

Ben asked if we mean to keep archive logs for a long time. Clint replied 
that the intention is to move all retention timelines into 5.5, so there
is only one timeline to track: the two year frame.

Neil added that it might be that the discussion feels that two years is
insufficiently long - but that it is simple to change that to reflect if the
ballot authors wish that.

Ben continued, saying that some consider that audit logs should exist until
they have been reviewed, at which point they can move to archive; but if
we wish to move forward with this, we'll see where we end up.

Neil said that the discussion from last time (SC38) resulted in some
participants saying that two years was insufficient to determine whether a
CA exhibited systemic issues. He added that the discussion document should
capture that these issues has been considered as part of the process of
forming the ballot, rather than being arbitrary figures dropped in without
due consideration.

Neil asked if Clint would draw up those discussion documents. Clint indicated
that he would.

Clint asked further if anyone believed that more than two years was needed.
Neil replied that since SC28 passed, the two year timeframe seems adequate
to him. 

Clint asked for reviewers and possible endorsers. Neil said that he would
review and possibly endorse. Ben said that he would review. Trev indicated
that she would review and possibly endorse.

6. Update to File Monitoring Ballot

No major updates have happened to the ballot - work is ongoing.

7. Update to Vulnerability Patching Ballot

No major updates have happened to the ballot - work is ongoing.

The discussion did turn to whether the vulnerability scanning should be 
made more frequent. Neil asked what a reasonably frequency would be.

Tim (C) did draw the distinction between patch scanning and vulnerability scan.
Neil agreed, saying that a scan of the system as a whole, versus knowing
that patches which address known CVEs.

Corey added that he didn't think that vulnerability scan was an appropriate
concept. Trev agreed - patching should be done regularly which is decoupled
from vulnerability scanning.

Tim (Hollebeek) commented that vulnerability scanning was more to ensure
that the patching management had been effective.

Neil said that the central issue remained in the ballot to ensure that a
patch had been applied in a reasonable term. Tim replied that a vulnerability
scan is a poor method of knowing which patches had been applied.

Neil committed to having a newer text which reflected a patch management
process, not vulnerablity scan.

Brittany asked if we were changing the definition of vulnerability scan; 
Neil replied that we were not - vulnerability scan would be left exactly
as is.

8. Any Other Business

There was no other business, except for GoDaddy's new members being welcomed
to the group.

9. Adjourn

The meeting was adjourned and will recommence on 2021-05-21