[cabfpub] Ballot 170 - Amend Section 5.1 of Baseline Requirements
Ben Wilson
ben.wilson at digicert.com
Fri Jun 10 14:52:55 UTC 2016
Gerv,
Obviously it's not 2), as this Working Group has demonstrated with its prior
work, namely Ballot 160, in which we bypassed dozens of sections (4.2.3,
4.3.2, 4.4.1, 4.4.2, 4.4.3, 4.5.2, 4.6.1, 4.6.2, 4.6.3, 4.6.4, 4.6.5, 4.6.6,
4.6.7., 4.7.1, 4.7.2, 4.7.3, 4.7.4, 4.7.5, 4.7.6, 4.7.7, 4.8.1, 4.8.2, 4.8.3,
4.8.4, 4.8.5, 4.8.6, 4.8.7, 4.9.4, 4.9.6, 4.9.8, 4.9.14, 4.9.15, 4.9.16,
4.10.3, 4.11, 4.12.1, and 4.12.2).
Taking 1), and the sole purpose of this ballot, which is the physical security
of CAs, the premise is that physical security is an important aspect of CA
trustworthiness.
Why is physical security important? In a security assessment, it is the
first thing you evaluate (before assessing logical security and administrative
controls). What are the access paths to the equipment? Are those access
paths blocked by physical security controls? Are those physical security
controls adequate enough to provide reasonable degree of assurance that CA
equipment won't be tampered with? Beyond physical access there are the
environmental threats (fire, water, earthquake, etc.) that every CA should
address. These provisions are necessary because, while they are baseline and
should already be implemented by all CAs, they are absent in ETSI and
WebTrust. (Search for "fire" and you're only likely to find "firewall"). In
fact, these principles are so baseline that everyone already thinks they must
already be required somewhere--they are, just not in the security policies for
the Web PKI.
Cheers,
Ben
-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Friday, June 10, 2016 8:20 AM
To: Ben Wilson <ben.wilson at digicert.com>; Ryan Sleevi <sleevi at google.com>
Cc: CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] Ballot 170 - Amend Section 5.1 of Baseline Requirements
Hi Ben,
On 08/06/16 21:32, Ben Wilson wrote:
> Here are the sources of the language in this ballot. As you can see,
> this is not new language. The purpose of this language is to ensure
> that CAs protect themselves against reasonably foreseeable physical
> threats (environmental, human, supply system, etc.).
Could I zoom the motivation question out a little bit?
What is the larger goal of the Policy WG in this effort? Is it:
1) Make the BRs a comprehensive list of all the things a CA must do in order
to provide a secure and trustworthy service; or
2) Make it so the BRs stipulate _something_ for every heading from the
framework they are now fitting, and so it never says "no stipulation"; or
3) Something else?
If the answer is 1) or 2), could you explain more about why that is considered
to be a useful and appropriate goal?
Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160610/635caebb/attachment-0001.p7s>
More information about the Public
mailing list