在 2019年5月27日星期一 UTC+8上午10:05:25，Matt Palmer写道： > 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
1. Yes, it doesn't fit ( for what I thought) 2. I missed some words. please add "without proven fact that the certificate is not secure" I thought what Matt says is not about charge, it is about potential policy to further mass private key compromising. I don't think this have anything to do with StartCom. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
