Hi everyone,

In pondering ways of getting yet more keys for pwnedkeys.com, my mind turned
to everyone's favourite bug, Heartbleed.  Whilst hitting all the vulnerable
servers and pulling their keys is eminently possible (see, as just one
example, https://github.com/robertdavidgraham/heartleech), I recalled that
CAs are responsible for revoking certificates within 5 days (with a "SHOULD"
of 24 hours) when:

> The CA is made aware of a demonstrated or proven method that exposes the
> Subscriber's Private Key to compromise, methods have been developed that
> can easily calculate it based on the Public Key (such as a Debian weak
> key, see http://wiki.debian.org/SSLkeys), or if there is clear evidence
> that the specific method used to generate the Private Key was flawed

(Taken from BRs v1.6.3, because that's what I happened to have handy)

That sounds an *awful* lot like Heartbleed: "a [...] proven method that
exposes the Subscriber's Private Key to compromise".

Several questions arise from this, which I'd like to get the opinion of the
members of this illustrious debating society:

1. Do others agree that Heartbleed appears to meet the criteria of this
   paragraph in the BRs?

2. Assuming "yes" to the above question, is it (still) reasonable to require
   CAs to revoke certificates within 5 days if notified that a certificate
   they issued is being served from an endpoint vulnerable to Heartbleed?

3. Assuming "yes" to the above questions, should I stand up a tool to watch
   certificates coming out of CT logs, identify endpoints serving those
   certificates, test them for Heartbleed, and report these facts to CAs for
   appropriate handling?

Of course, if it's deemed that Heartbleed *isn't* "a proven method etc etc",
the keys could just be pulled directly, which I'm led to believe typically
takes a lot less than four days (and which would trigger the
24-hour-required revocation), but it seems to me "politer" to everyone to
use the less intrusive option.

Additional comments surrounding this issue, not pertaining specifically to
the above three questions, would also be gladly received.

- Matt

dev-security-policy mailing list

Reply via email to