[cabf_netsec] Minutes for NetSec Meeting 2020-03-19

[Neil Dunbar]

All,

Continuing the theme of 'things delayed by other activities', I'm 
attaching the minutes of the last meeting. I don't expect anyone to read 
through them in time for the next meeting in a couple of hours, so I'll 
delay the approval of minutes discussion for the meeting in 2 weeks 
after that.

Read, comment, correct, please!

Regards,

Neil

-------------- next part --------------
NetSec Meeting Minutes
2020-03-19 17:00:00 UTC

Attendees:

Neil Dunbar (TrustCor) [Chair]
Clint Wilson (Apple)
Bruce Morton (Entrust Datacard)
Joanna Fox (GoDaddy)
Tim Crawford (BDO)
Ben Wilson (IP)
David Kluge (Google)
Trevoli Ponds-White (Amazon)
Aaron Poulsen (DigiCert)
Tobias Josefowitz (Opera)

1. Review Agenda

The Agenda was Agreed.

2. Agree Last Meeting Minutes

The last minutes from 2020-03-05 were approved.

3. Pain Points Subgroup Update

[David arrived slightly late so this was performed after Document Structuring Report]

David summarised the last call with discussions on SC28, with reference to the
details of the categories of information. He also referred to the fact he has
looked at various definitions regarding the system account ballot which might help
clear up the issue identified at the last meeting, but said that there was probably
not enough time to discuss this at this meeting.

David continued on SC28. The Pain Points team split the categories into
CA key, CA/Subscriber Certificate, and Security Events because the retention periods differ for
each.

The restriction on a 7 year maximum was removed. David agreed that existing data which
had been deleted on the 7 year rule remained deleted, but this was a "going forward"
proposal.

Neil asked for a clarification to 5.4.3 to split the requirements on CA key and
certificate to different texts - one for keys, and one for certificates.

Trev wondered if a separate CA Certificate category would be better, since some
of the points don't really apply to CA Certificate. David didn't think that was a
problem since if the requirement doesn't apply, no events would be recorded.
[The example given was 'phone number used' for CA certificates.]

Trev continued, asking then why not to have specific requirements for each.

Neil asked if point 3 (records of phone calls) wasn't subsumed by point 2
(All verification activities). Trev said that she always wondered that too.
Ben did not think that point 3 needed to exist either. Tim wondered if the
reason it was there to state that you didn't need to retain audio transcripts.

Trev asked if we should have cleanup ballot to delete 5.4.3 (3). Neil said that
we should just continue with SC28. She asked whether verification of certificate
requests was needed for CA certificates. David said that external entities
could ask for Subordinate CAs.

Neil said that a failure in process could cause rejection of a request. Ben
also indicated that he couldn't see an auditor asking for evidence of rejection
of external SubCA requests.

The discussion focussed on point (4) referring to CSRs or requests in general.
Trev saw the request for a CA cert as being an internal activity. Neil and David
thought that it could indeed be communication between business entities, even
for groups within the same enterprise. David said that in his operation, there
was a formal review of requests for Subordinate CA certificates with approval
or not. Tim said that approval was the term used in the WebTrust requirements.

Neil said that the term acceptance or rejection could be replaced with approval
or disapproval.

Ben thought that point (5) Issuance could be included in point (1) - requests,
renewal, rekey and revocation.

Neil said that a final round of text approval was needed, but that time
meant that we needed to move on.

4. Threat Modelling SG Update

There was no meeting of the Threat Modelling Subgroup, owing to meeting conflicts.
Mariusz had previously sent his apologies, citing work pressures for his
unavailability to host the meeting.

5. Document Structuring SG Update

During reorganization, Ben felt like the definitions of "Secure Zone" needed
refining in order to move forward, hence his email to the list. He feels like the intent
of the existing text is directed towards physically secured zones, which is not
sufficient to encompass all of the controls which should be in place.

He suggested that NSR 1.d be altered to specifically note physical security, and
then go on to update the BRs with the reorganization ballots.

Trev indicated that she liked the proposed direction. She commented that terms
like "Secure Zone" are not helpful when such terms are not common, but have commonly
understood terms. She asked if anyone felt strongly attached to the terms
Secure Zone and Highly Secured Zone. Neil said that he did not.

Ben replied that he thought the term came from RFC 3647. Trev said that the RFC
didn't really use those as defined terms.

Ben wondered if using the NSRs to define a Secured Environment might be a better
approach, which covers the physical/environmental controls around equipment.

Trev asked if the differences between Highly Secured Zone and Secured Zone was important.

David said that he wasn't attached to either term. He noted that there was no
clear definition as to what makes a zone "secure".

Trev said that the definitions just don't match up to reality. There would
be different layers of physical security for various spaces within an enterprise;
but that doesn't neatly partition things into "non-secure" versus "secure".

David then asked what the standard would be to judge whether private keys were
adequately protected? He presumed that an auditor would judge this - Trev agreed,
but pointed out that the standards of expected security were what was missing from
the NSR document.

Neil commented that, in his view, the level of security required scaled with the
sensitivity of the data being protected in each "zone". He said further that the
NSRs usually conflate Secure Zone and Highly Secure Zone in terms of requirements,
so what does differentiating the terms buy us?

David agreed. Trev replied that the BRs, Section 6.1.1 makes reference to a
physically secured environment for CA key pair generation, implying that this
is the only place where a security description would be required. She suggested
that perhaps the NSRs could require that the CP and CPS define the physical security
around sensitive equipment, rather than attempting to define the controls in the
NSRs themselves. David thought that the BRs currently don't make stipulations
on physical security.

Neil couldn't see an issue with having the BRs demand a physical security description
in the CP/CPS, and even have the NSRs just refer to that section.

Trev said that given the extended discussion periods, perhaps we could have
CAs discuss their CP/CPS descriptions of physical security and discuss whether those
conditions were sufficient.

Ben concluded by asking if we could then just replace Secure Zone and High Security
Zone with Physically Secured Environment, which was a defined term.

Trev asked if we couldn't just delete 4.7. Tim said that he considered the mixing
of physical and logical security controls just muddy the waters, and different
controls for different definitions would be preferable.

Trev asked Ben if he could either replace with Physically Secured Enviroment, or
just undefine the defined terms. She also considered that we could just eliminate
the terms in easy to eliminate areas, but after a pass through, it would be easier
to decide.

When discussing logical security zones, Trev said that she normally sees discussion
more about the traffic between boundaries. 

Neil said that owing to time pressures, we would be better taking the discussion
offline, although it is important work.

David finished up by saying that modern security architectures generally don't refer
to secure zones, and that further discussion embedding threat modelling would be
a good next step.

6. Ballot SC29 Voting Period

Neil said that if needed, he would heartbeat the ballot to keep it alive. He was not
fully clear that the need was sensible, but that the coronavirus pressures on CAs
meant that full discussion on the ballot might still be difficult.

Trev asked for a summary for those unfamiliar. Neil said that SC20 failed because
of a lack of vote. SC29 was a resurrection of the ballot. Dimitris asked for a
delay of a week. Then there was a request for indefinite suspension because of
COVID-19.

David also said that he didn't understand the delay either. The matter had been
discussed to death.

Trev agreed with the heartbeating decision. Tim asked if the reason given was that
CAs don't have the time to decide. Trev added that by adding some text in the
discussion, perhaps it could offset worries. Neil said that he could do so, but
that he was not sure if there was any real point.

Aaron asked if we were in a voting period. Neil said that it was supposed to be in
voting, but requests for delays had occurred. He worried that once the moratorium
on ballots happened, there would be overload and conflicts between ballots then;
so this hold on voting was only storing up a worse problem later as we are not
getting throughput.

7. Balloc SC28 Preparation

See above.

8. Other Ballot Discussion

The was no other discussion.

9. Any Other Business

There was no other business.

10. Adjourn

The meeting was adjourned until 2020-04-02