[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