On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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
>
Have you read through the archives? This was already discussed and decided
as part of handling Heartbleed. This was debated at length, in particular
as at least one (but possibly more) CAs charged for revocation, which
created challenges and potential conflicts with the contemporaneous BRs and
Policy.

I don’t see anything new being discussed, so I think the past decision
remains applicable.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to