[Servercert-wg] Compromised keys

Ryan Sleevi sleevi at google.com
Fri Apr 17 09:51:28 MST 2020


On Thu, Apr 16, 2020 at 4:09 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> CAs generally do not have private keys, so their ability to misuse such a
> service is limited.
>

I think you're presuming a design that was not stated in your past emails
or conversations on the topic. I can try to speculate what you might be
assuming, such as there being some shared proof-of-revocation-request, but
I think such designs themselves are flawed, and again based on ill-defined
problem statements.

This is not about adding stop energy, it's about how easy it is to suggest
solutions, but how harmful those approaches can be without a well-defined
problem statement. I would again encourage you to define the problem
statement well, about the set of problems and concerns and optimizations,
and we'd be happy to discuss the merits and weighting of concerns.

As a practical level, however, CA information sharing about revocation has
greater risk of systemic, lasting, real harm to end users, at least without
careful design that has not yet been captured or well-articulated, so we're
not supportive. There is further no reason to assume or expect that CAs
should be the arbiters of revocation, given the systemic issues at play and
given the abuses of revocation we see.

Such broad discussions are actually helpful in promoting broad
> participation in finding a solution, and then we can see where we can go
> from there.
>

Respectfully, we will continue to disagree here. If folks continue to
propose solutions, without articulating problems, they will continue to be
ill-considered, ill-specified, and ill-designed. This discussion itself
shows how that comes across - by dismissing legitimate concerns as
"continually complaining". I would hope that, as a collaborative body, we
could find more productive avenues for engagement, by setting out the
problems to be solved before trying to promote particular solutions. This
should be trivial to do, but helps ensure that we're aligned in goals and
mission, before delving deep into technical detail, and helps make for
productive collaborations rather than unnecessary dismissiveness and
hostility.

Given the significant potential risk of harm the solutions thus far
espoused have had, to both users and subscribers, it's not surprising that
we'd much like to understand the set of problems you're trying to solve, to
see if we can find less problematic solutions for those problems. Yet
without a clear statement, that's impossible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200417/fa5f2c12/attachment-0001.html>


More information about the Servercert-wg mailing list