[Servercert-wg] Compromised keys

[Tim Hollebeek]

CAs generally do not have private keys, so their ability to misuse such a service is limited.  However if you have any misuse cases that you think are useful in the design of such a system, I’d love to hear them.  I’m not a big fan of bad actor CAs myself.  In fact, as you correctly point out, CAs can currently revoke certificates for a wide variety of reasons, some of which we have serious concerns with.  So even a bad actor CA who has access to private keys of subscriber certificates cannot do anything that they cannot already do today.  If they want to revoke a subscriber certificate, they can do so WITHOUT access to private keys or having to demonstrate compromise.  A reliable method for reporting key compromise and banning issuance for compromised keys would avoid having to rely on revocation to reduce risks from certificates that never should have been issued.  That said, revocation does have it’s place, and I’m encouraged that some browsers are making serious progress on that issue instead of continually complaining about its unreliability whenever it comes up.

 

Also, one of the things that’s least useful for discussion is calling other people’s contributions not as useful, and trying to steer the discussion elsewhere.  Discussions about nailing down the problem statement and scope are always useful, but there are lots of other useful and interesting topics to discuss on this topic since it is a bit more complicated than it first appears.  It’d be best to openly discuss all possible solutions, including their advantages and disadvantages for various participants, as that can provide useful input for focusing on problem statements where we can actually make some progress.  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.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, April 14, 2020 4:02 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Compromised keys

 

 

 

On Tue, Apr 14, 2020 at 3:31 PM Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

Slightly more tricky is some sort of coordinated blacklist of keys, which would be a good idea.  It doesn’t help the internet if clueless users can simply shop around until they find a CA that doesn’t know that their key has been compromised, because it hasn’t been reported to them yet.  

 

I think the question of whether this is a "good idea" depends on whether or not (other) CAs are part of your threat model. Naturally, as a Root Program, I'm most concerned about CAs that, intentionally or unintentionally, are bad actors. This is significantly more tricky, not slightly, because there's a question about whether or not the given key is compromised.

 

DigiCert is broadly familiar with this concern, as captured in this thread <https://groups.google.com/d/msg/mozilla.dev.security.policy/nU1bIZ9LgjU/8RxqN_zsAgAJ> , in that revocation is not necessarily trustworthy. Imagine such a CA using such a service to further prevent their customers from migrating. This is one of the concerns with any form of CA-initiated revocation.

 

One of the things that would make it easier to do this coordination would be if there were a few standardized forms of key compromise reports that CAs were required to accept.  

 

I think this puts the solution first, and that's not as useful for discussion.

 

I think it's more useful to discuss the problem statement first about the problem we're trying to solve. Discussions of this specific topic seem to lead towards different results, depending on how different participants view the problem to be solved. Are you optimizing for reporters? For holders of compromised keys? For CAs? Each of these leads to different directions, and so a good starting point is to reach consensus about the in-scope and out of scope problems.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200416/d596ab01/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200416/d596ab01/attachment.p7s>