[Servercert-wg] Ballot SC31 - Browser Alignment

[Dimitris Zacharopoulos (HARICA)]

On 2020-06-27 7:48 μ.μ., Clint Wilson via Servercert-wg wrote:
> Hello all,
>
> Broadly speaking, I agree and support the messages sent by Google and 
> Mozilla. I think SC31 should proceed as written and I hope that it can 
> find strong support and backing from CAs.
> However, based on the feedback from CAs in this thread, I do have 
> questions that I’m hoping will help me better understand the thoughts 
> and opinions of CAs.
> I think we have come to agreement on a few things, but I want to 
> restate them here to ensure I’m not overly assuming :)
>
> 1.
>
>     The WebPKI is not perfect statically nor dynamically,
>     necessitating changes to how it operates at times.
>
> 2.
>     Changes to the WebPKI should be discussed openly, weighing input
>     from the varied stakeholders (both directly and indirectly)
>     affected by such changes.
> 3.
>     The CA/B Forum is a very good place for such discussions to occur
>     and achieving consensus through the ballot process of the CA/B
>     Forum is a valuable way to implement changes to the WebPKI.
> 4.
>
>     In situations where a change is identified as profoundly important
>     by a certificate consumer, but where initial consensus in the CA/B
>     Forum is not achieved, it may be necessary for the certificate
>     consumer to independently enforce that change through their root
>     program.
>
> A few of the things said here raise additional questions, to which I 
> don’t have a clear understanding of the position of CAs. FWIW, I do 
> have my own position, but at this point I’m more interested in where 
> CAs stand.
>
> 1.
>
>     If a change is requested within the CA/B Forum, but fails to pass
>     during the ballot process, in what way(s) should that change be
>     brought up in future CA/B Forum discussions or ballots? What, if
>     any, are appropriate ways of revisiting changes represented in
>     failed ballots?
>
> 2.
>
>     In situations like described in #4 above, except instead of a
>     single certificate consumer enforcing the identified change, it’s
>     a majority or unanimous show of support reflected in independent
>     changes to multiple root programs, what role does the CA/B Forum
>     play in ensuring those root programs can rely upon participating
>     CAs to adhere to their individual root program policies?
>
> Thank you!
> -Clint
>

Wearing my "HARICA hat" on, and after carefully reading the messages 
from Google, Mozilla and Apple about Ballot SC31 and their desire to 
proceed with SC31 "as written" and the maximum certificate validity 
period for 398 days, I must admit that no new substantial 
security-related information has been brought forward that would warrant 
a new discussion and revise the opinion of the Members that voted "No" 
on ballot SC22. It's true that most CA members (if not all) have already 
declared their will to meet this requirement in practice, as indicated 
in the recent Mozilla communications survey. However, this doesn't mean 
that there is "industry consensus" or that this is a change that meets 
the spirit of this Forum where all decisions must be consensus-driven.

IMHO, we've had "big ballots" before, like SC31, that try to deal with 
many issues at once and in such cases there is always a risk of finding 
a single controversial issue that may cause the entire ballot to fail. 
It seems that the 398-days issue creates such a risk and it's up to the 
proposer and endorsers to weight in this risk. In most cases I can 
remember, proposers that faced such a challenge, separated the 
controversial issue into a separate ballot so that the Forum/WG can make 
forward progress with the majority of the "big ballot". In fact, this 
was one of the first things I learned in the Forum when I started 
actively participating and contributing to ballots. This advice came 
from Ryan Sleevi and it made perfect sense to me.

I'd also like to take this opportunity to comment on specific quotes 
from the emails received.

[Ben Wilson wrote]: "In summary, we agree with Ryan’s message that the 
BRs represent the collective minimum requirements of Root Programs and 
that Root Programs set their own policies. We think that it is now 
reasonable to consider the change to reduce the TLS certificate validity 
period to a maximum of 398 days as part of aligning the BRs with root 
store policies, so we think that this change should remain in the 
Browser Alignment Ballot (SC31). We would like to see the Browser 
Alignment ballot adopted, but are ready to add all of the changes in the 
ballot directly to Mozilla’s Root Store Policy as needed."

[Clint Wilson wrote]: "If a change is requested within the CA/B Forum, 
but fails to pass during the ballot process, in what way(s) should that 
change be brought up in future CA/B Forum discussions or ballots? What, 
if any, are appropriate ways of revisiting changes represented in failed 
ballots?"

As explained previously, I believe that no new security-related 
information was presented that would trigger a re-evaluation of the 
previous ballot decision. As with other controversial topics, which are 
the most "painful" to tackle, IMHO the bare minimum to re-introduce a 
previously failed ballot would be to bring in new arguments or 
information that was possibly overlooked. There is always a possibility 
for a Member that voted "No" to change their mind. If the proposer feels 
there is a good chance for members to have a change of mind, I would 
suggest using tools like straw polls to get a reading of the intent 
before re-introducing the same ballot without any additional 
security-related information.


Dimitris.

>> On Jun 22, 2020, at 7:57 AM, Doug Beattie via Servercert-wg 
>> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
>>
>> Hi Chris,
>> Yes, I agree.  There are some things that CAs and Browsers don’t 
>> always agree on.  CAs can document these in their CPS and the root 
>> programs can define them in their root policies. This is one that 
>> should remain in the root policies for those programs that endorse 
>> this change.
>> I like all of the other changes in this ballot and don’t want to see 
>> them held up unnecessarily.
>> Doug
>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200630/5bbc0e5d/attachment.html>