[cabfpub] Ballot 170 - Amend Section 5.1 of Baseline Requirements
ben.wilson at digicert.com
Wed Jun 15 16:15:54 UTC 2016
See responses inline below
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
>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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4954 bytes
Desc: not available
More information about the Public