在 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
