[Servercert-wg] Compromised keys

[Tim Hollebeek]

The discussion of weak keys is certainly interesting, but focusing on that
misses a much more pressing issue, which is keys that are actually known to
be completely compromised, because they have been demonstrated to be known
by a third party.  I'm glad recent m.d.s-p discussions have highlighted this
issue, and I think it would be productive to discuss whether progress can be
made here on that issue.

 

Certainly an easy place to start is to require CAs to reject keys that have
previously been reported to them as compromised.  That's relatively easy to
do and I would hope it is uncontroversial, if CAs are given the time to
implement it.  Which should be pretty straightforward.  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.  Requiring the internet
community to monitor CT logs and report these certificates for revocation is
not a great use of everybody's time, since they simply should not be issued
in the first place.

 

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.  This was discussed at IETF LAMPS a few years ago,
and unfortunately the discussion did not end constructively.  Note that this
would not prohibit users from demonstrating key compromise in any way they
wish, it would simply allow users to demonstrate the compromise once in one
or more standardized forms that all CAs would be required to accept, without
having to deal with the unique foibles of each individual CA.  You'd need
some additional language to require CAs to accept compromise reports for
keys they haven't issued certificates for yet, but that does not seem like
rocket science either.

 

A few notes for non-technical people: Could a malicious actor generate and
report a large number of compromised keys simply for the purpose of causing
the lists to blow up?  While it's possible to do so, it would be
prohibitively expensive.  Key generation is many orders of magnitude more
expensive than maintaining and checking lookup tables.

 

Another concern that doesn't exist is running out of key pairs.  When
generation is done correctly (e.g. non-ROCA), there are astronomically many
of them, so blacklisting existing known compromised keys has no practical
effect on anything.  The odds of generating one at random is vanishingly
small.

 

-Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200414/e931bb79/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/20200414/e931bb79/attachment.p7s>