[Servercert-wg] Updated agenda for F2F 49 meeting

[Wayne Thayer]

I'd also like to point out that ballot SC6 [1] just relaxed revocation
requirements about 18 months ago. That ballot was based on the 2017
proposal for ballot 213 [2] and earlier discussions [3][4][5], and it took
a lot of time and effort to achieve consensus. I encourage everyone to
review the past discussions if we're going to reopen this topic.

- Wayne

[1]
https://cabforum.org/2018/09/14/ballot-sc6-revocation-timeline-extension/
[2] https://cabforum.org/pipermail/public/2017-July/011587.html
[3] https://cabforum.org/pipermail/public/2017-May/010892.html
[4] https://cabforum.org/pipermail/public/2017-September/011998.html
[5] https://cabforum.org/pipermail/public/2017-August/011996.html
<https://cabforum.org/pipermail/public/2017-May/010892.html>


On Thu, Feb 13, 2020 at 11:34 AM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> In order to ensure a productive conversation, it might be useful for the
> discussion leader to share in advance, as this does seem like something
> that can and should have been discussed on the list beforehand.
>
> That said, we're extremely receptive to analyzing the many violations of
> the Baseline Requirements in 2019, and look at meaningful changes we can to
> to reduce or eliminate that risk. That said, it does seem to be quite
> short-sighted to assume that changing revocation requirements is the
> answer, so perhaps we can make this session a bit broader, in order to be a
> productive discussion.
>
> For example, we could more thoroughly analyze and discuss the CA incidents
> of 2019, and look at their root causes and mitigations, to understand
> opportunities to improve. If that seems too large, perhaps we can focus on
> just the incidents of a particular CA, so that we can use that as a case
> study to understand challenges and trends.
>
> By careful analysis, we might realize that the trends being flagged in
> this proposed discussion topic are due to certain certificate fields or
> profiles. An alternative to relaxing requirements, allowing users to be
> mislead and CAs to not have to behave in a trustworthy and consistent
> fashion might be to prohibit those fields from being included in
> certificates. This would address the root cause, rather than the symptom,
> and in a far easier and more reliable fashion.
>
> That said, any discussion predicated on an assumption that a CA can or
> should be permitted to have degrees of compliance with their CP/CPS, and
> perhaps only comply with their CP/CPS when it's convenient, seems deeply
> problematic, and a sign of a deep disconnect on the expectations for what
> it means to be trusted. As a browser, we've been closely involved in every
> CA incident that's been reported, and we see no data to support the
> conclusion being presented here. If there's something we've overlooked, it
> seems essential to share sooner, but it also seems we should be approaching
> this solution with an open mind, and not overindexing on relaxed revocation
> being a solution, especially since that's not something we have any plans
> to change at this time.
>
> In any event, looking forward to reading more on the list, to see if there
> are new CA incidents that were not reported, or to see the proposed
> approach to discuss the CA incidents and non-compliance in detail.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200213/1ff3e658/attachment.html>