Here are the draft minutes of the meeting we had yesterday.
Minutes of NetSec Subcommittee Teleconference of 7-March-2019
Present: Corey Chapeski, Tim Crawford, Neil Dunbar, David Kluge, Robin
Alden, Tobias Josefowitz, Ben Wilson, Marcelo Silva, Trev Ponds-White, Corey
Rasmussen, Bruce Morton, and Daymion Reynolds
Ben read the Antitrust Statement
Subgroups: The meeting began by reviewing and adding membership to these
subgroups: Threat Modeling, Document Structure, Pain Points, and
Authentication and Access Control. It was noted that: each group needs to
focus on a deliverable, Pain Points and Authentication/Access Control are
similar in that both would have deliverables of new ballots to address pain
points, Pain Points will focus on addressing the points raised in the
WebTrust communication, the Pain Points subgroup already has a Doodle Poll
to gather people's availability for regular meetings, but some sub-groups
still need to get organized and schedule regular meetings.
CA Internal Certificate Requests: Daymion raised an issue he has
encountered when seeking to obtain certificates for use by his company.
Auditors and others have told him that they read that the Network Security
Requirements prohibit a CA from processing certificate requests internally
(i.e. for corporate accounts). Section 1.g. has been cited as a problematic
requirement - "g. Configure Issuing Systems, Certificate Management Systems,
Security Support Systems, and Front-End / Internal-Support Systems by
removing or disabling all accounts, applications, services, protocols, and
ports that are not used in the CA's or Delegated Third Party's operations
and allowing only those that are approved by the CA or Delegated Third
Party."
According to some interpretations, a strict reading of 1.g. means that the
CA cannot use an "account, application, service, protocol, or port" to
obtain a certificate for itself because it's not being "used in the CA's or
Delegated Third Party's operations."
There was concern by the group that these interpretations go too far in
restricting a CA's own ability to obtain a certificate. There are likely
various scenarios among CAs in which this problem could arise - e.g. the CA
has a technical team that needs to obtain a certificate and uses an account,
etc. Daymion said that his company uses an API similar that was identified
as fitting within the scope of 1.g. Daymion's approach would be to
restrict the scope of the Network Security Requirements (in the Scope
section at the beginning of the document). He is considering adding the
following:
The network security requirements apply to all system components included in
or connected to the publicly trusted certificate authority (CA) environment.
The CA environment is comprised of people, processes and technologies that
store, process, or transmit CA data. "System components" include network
devices, servers, hardware security modules(HSM), computing devices, and
applications residing within the CA environment. Examples of system
components include, but are not limited to the following:
a. Systems that provide security services (for example,
authentication servers), facilitate segmentation (for example, internal
firewalls), or may impact the security of (for example, name resolution or
web redirection servers).
b. Virtualization components such as virtual machines, virtual
switches/routers, virtual appliances, virtual applications/desktops, and
hypervisors.
c. Network components including but not limited to firewalls,
switches, routers, network appliances, HSM and other security appliances.
d. Server types including but not limited to web, application,
database, authentication, mail, proxy, Network Time Protocol (NTP), and
Domain Name System (DNS).
e. Applications including all purchased and custom applications.
f. Any other component or device located within the CA
environment.
To be considered out of scope for CA environment, a system component must be
properly isolated (segmented) from the CA environment, such that even if the
out-of-scope system component was compromised it could not impact the
security of the CA environment.
His proposal would also add definitions for "Certificate Authority
Environment" ("The area where certificates are generated, and stored for
later transmission to the requester") and "Connected To" ("Components within
the certificate authority environment which exchange data").
The group discussed parts of the proposed language. The phrase "connected
to" received the most criticism because it seemed to be too broad - anything
could be considered "connected" whether it is operating, transmitting, or
exchanging data. Similarly, "exchange data" was discussed.
Daymion offered to create a redline/pull request using GitHub, but he noted
that the version on GitHub was not in sync with the version on the CA/B
Forum website. Ben said he'd look into it and get it fixed. He also noted
that if 1.g. is the problem, then maybe we should focus on fixing that.
Tobias suggested that it would help for us to understand the underlying
reasoning on why certain individuals have interpreted 1.g the way they have,
and he also asked for an explanation of how Daymion's proposal would fix the
problematic interpretation.
It was agreed that we do need to fix this and that we appreciated that
Daymion brought this issue forward. Given that we were running out of
meeting time, we decided to continue discussion of this issue in a
subsequent meeting and/or as part of the work of a subgroup.
Next two meetings will be Tuesday, March 12, and then on Thursday, March 21.
Meeting adjourned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20190308/1b46ad16/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4934 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/netsec/attachments/20190308/1b46ad16/attachment.p7s>