[cabfpub] Ballot 213 - Revocation Timeline Extension
Ryan Sleevi
sleevi at google.com
Wed Sep 13 20:01:26 UTC 2017
We may have lost sufficient context:
We are proposing extending the revocation timeline, because some CAs feel
they need additional time to respond to incidents.
We don't have a sense about what the situations are. We don't know whether
those situations are reasonable. We don't know whether there exist
alternatives that don't require that original time.
So it seems reasonable - and important - to bring transparency to that.
I would assert that without such a system - and a requirement - we will be
no closer to understanding those challenges tomorrow than we are today.
On Wed, Sep 13, 2017 at 3:57 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:
> I understand what you are saying, but revocation timelines seems like a
> different topic than challenges facing the space. There should be a
> mailing list for challenges, but I don’t think it should be tied to
> changing the revocation timelines already in the BRs.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Wednesday, September 13, 2017 1:18 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] Ballot 213 - Revocation Timeline Extension
>
>
>
>
>
>
>
> On Wed, Sep 13, 2017 at 3:10 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
> wrote:
>
> Sure, but I plan on uploading all these to the Mozilla dev list. Emailing
> the CAB Forum as well seems like duplicative effort, especially since the
> emails aren’t going to be readily collaborated. If the CABForum is going
> to collect the problem reports, some format other than email would be much
> better for data collection.
>
>
>
> I'm not sure I understand your point about collaborated, but I think you
> may be misunderstanding the goal.
>
>
>
> I appreciate the desire for transparency and engagement with the
> community, and I hope all CAs aspire to that level. However, I think the
> goal here is minimally to ensure public visibility, in a self-managed form
> (that is, I have difficulty imagining the CABF requiring an MDSP posting).
> I think going above and beyond is good, but i think we should set minimum
> reasonable requirements.
>
>
>
> As I noted, I'm not wedded to the idea of public@, but I think there
> should be a CABF-managed, publicly-visible list for discussion about the
> challenges here in this space :)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170913/7797dca4/attachment-0003.html>
More information about the Public
mailing list