On Sun, May 26, 2019 at 06:57:08PM -0700, Han Yuwei via dev-security-policy wrote: > If malloc() is correctly implemented, private keys are secure from > Heartbleed. So > I think it doesn't meet the criteria.
Just to make sure I'm understanding you correctly, you're saying that being vulnerable to Heartbleed doesn't *necessarily* expose private keys, it requires an additional criteria (malloc being "incorrectly implemented"), thus it doesn't fit the definition of a "proven method that exposes the Subscriber's Private Key to compromise"? > CAs can't revoke a certificate without noticing subscriber in advance. Can you point me to where that requirement comes from? Some CAs don't necessarily have *any* notification method for their subscribers (Let's Encrypt immediately comes to mind); does that mean they're immune from revocation requirements? Is there any requirement around how quickly CAs are required to notify subscribers, and does that time come out of the 24 hour / 5 day budget, or is it some additional time period? > But if any bugs found in future which can retrieve private keys from TLS > endpoints, > you can just use automated tools to scan them and get private keys to request > a > revoke. I thought this is the best practice to this BR. OK, so that's one vote for "just scan the Internet and drop private keys on CAs for revocation within 24 hours". - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
