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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
