[cabfpub] Issuance of certificates for keys reported as compromised

Ryan Sleevi sleevi at google.com
Tue Aug 21 19:58:27 UTC 2018


I don't think the concern should be misinterpreted as pessimism, but I do
think that if attempting to prevent this imposes unnecessary additional
cost with no concrete value, then there's a real problem supporting it, and
more harm will be done to the ecosystem than good. I'm sure you can
understand, we're extremely concerned about reasons to deny certificate
applications, as the ecosystem is best served with certificates widely and
easily available.

I appreciate your efforts to improve things, and I hope that any proposal
will demonstrate how it's taken these many concerns into consideration and
either addressed or meaningfully avoided them. Absent that, it's difficult
to see supporting a ballot, or to see how it's in the interest of the
Internet at large.

Sometimes an ounce of prevention can cause a ton of pain.

On Tue, Aug 21, 2018 at 3:51 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> We’re far less pessimistic about whether these problems can be solved.
> There are clearly some key pairs where is private key is either widely
> known, or someone other than the original owner has conclusively
> demonstrated possession of it.  You shouldn’t be able to get a certificate
> for those, but currently it’s very easy to do so.
>
>
>
> If other people want to work together with us on a concrete proposal for
> making sure previously compromised keys don’t get put in brand new Web PKI
> certificates, we’re willing to work with them on a proposal.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Tuesday, August 21, 2018 3:34 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CABFPub <
> public at cabforum.org>
> *Subject:* Re: [cabfpub] Issuance of certificates for keys reported as
> compromised
>
>
>
> I seem to recall we've discussed this before. There are a number of
> practical challenges with this, and that any reasonable proposal would need
> to provide interoperable guidance for. In short, it was substantial work,
> for questionable gain, and while it sounds sensible, the devil is in the
> details.
>
>
>
> We need to define what a compromised key is, how it was reported, and how
> it was determined. Without these basic things, you have the potential for
> malicious DoS. For example, we know of some CAs that revoke certificates as
> compromised even with faulty demonstration of proof, or insufficient proof.
> We've had substantial discussions about what counts as reasonable proof
> versus not - e.g. the signing of nonces or the like.
>
>
>
> You then have to have CAs consistently reporting (e.g. through CRLs and
> OCSP) the reason for revocation. All CAs would need to check all other CAs,
> or there would need to be some meta-service to aggregate. If there is an
> aggregated metaservice, you have to determine how to authenticate that
> metaservice and its information - it becomes a single point of attack for
> DoS.
>
>
>
> Once you've built a system that allows revoking an entire key off the
> Internet, you then have to deal with the policy ramifications of such a
> centralized risk, such as giving a single avenue for political or external
> attacks, such as revoking keys as 'compromised' if, for example, they are
> used to host 'objectionable' content.
>
>
>
> As you can see, these are just a few of the issues that present themselves.
>
>
>
> On Tue, Aug 21, 2018 at 2:42 PM Tim Hollebeek via Public <
> public at cabforum.org> wrote:
>
>
>
> Should we update the BRs to disallow issuance of certificates for key
> pairs that have been previously reported as compromised?
>
>
>
> I’m not aware of any CAs that currently do that check today, but it’s not
> that difficult to do.  It might be a sensible thing to add in the future.
> However it only works if all CAs do it, otherwise subscribers will just get
> their compromised key signed by a different CA.
>
>
>
> -Tim
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180821/2bd1d95f/attachment-0003.html>


More information about the Public mailing list