[Servercert-wg] Updated agenda for F2F 49 meeting

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Thu Feb 13 23:27:43 MST 2020


I'd encourage people to also review more recent related discussions in 
m.d.s.p.

  * https://groups.google.com/d/msg/mozilla.dev.security.policy/hbo2SCH8c_M/yFGozJHBAgAJ
  * and the earlier thread
    https://groups.google.com/d/msg/mozilla.dev.security.policy/HaLmrDILtcA/W-0LDgywAgAJ


Dimitris.


On 2020-02-13 10:36 μ.μ., Wayne Thayer wrote:
> 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
>
>
> On Thu, Feb 13, 2020 at 11:34 AM Ryan Sleevi via Servercert-wg 
> <servercert-wg at cabforum.org <mailto: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 <mailto: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/20200214/def4258f/attachment.html>


More information about the Servercert-wg mailing list