[cabfpub] Ballot 170 - Amend Section 5.1 of Baseline Requirements

[Ben Wilson]

See responses inline below
>
>-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Wednesday, June 15, 2016 9:41 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
>
>On 10/06/16 15:52, Ben Wilson wrote:
>> 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).
>
>Well, just because you left them blank in one ballot doesn't mean the 
>ultimate plan is not to fill them in. But thank you for confirming this is 
>not the goal.
>

There is no ultimate plan.

>> 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.
>
>Yes, it is. However, I think it's worth having a discussion about the goal of 
>the BRs because my statement 1):
>
>"1) Make the BRs a comprehensive list of all the things a CA must do in order 
>to provide a secure and trustworthy service"
>
>is, I think, _not_ the right goal for the BRs.
>
>There are a million and one things a CA must do in order to provide a secure 
>and trustworthy service - hiring trustworthy people, physical security, 
>electronic security, backups and disaster recovery, etc. etc.
>etc. I'm not sure it's either possible or wise to list them all. The full 
>title of the BRs is:
>
>"Baseline Requirements Certificate Policy for the Issuance and Management of 
>Publicly-Trusted Certificates"
>
>The further we get from stipulations about the issuance and management of 
>certificates, the further we get from the core areas of expertise of the 
>people who are involved in this forum, and the greater the likelihood that we 
>will stipulate things which are either wrong now, or are wrong in two years 
>and we don't notice.
>
>So I'd say that just because a CA should do _something_ doesn't mean it 
>should be mandated that they do it in the BRs. Perhaps others in the group 
>disagree, so I would welcome a debate on this. It would be good to have 
>because otherwise the more maximalists among us are going to spend time 
>preparing ballots that the more minimalists among us might vote against, 
>which will lead to frustration all round. It would be good if we could get on 
>the same page here.
>
>Gerv
>
I don't think it is maximalist to provide some baseline requirements around 
physical security, but that, I guess, is a matter of opinion.  Talking of 
frustration, I do get frustrated that  browsers prefer an extreme minimalist 
approach to  the  extent that  they would rather see "survival of the 
fittest".  In other words, it is only a matter of time until another CA with 
lax operational practices goes the way of DigiNotar.  Browsers should be 
partners with CAs in looking  out for the best interests of the ecosystem.  On 
the one hand, I can partially agree with you  because, hey, why should the 
well-operated CAs care -- they will survive because they are doing things 
right.  However, on the other hand, those who are ignorant of past lessons are 
doomed to repeat them, and I don't think that is a model that  we should 
necessarily embrace.
-------------- 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/20160615/cb0478bf/attachment-0001.p7s>