Re: Does Heartbleed count for the purposes of BR point 11? ("proven or demonstrated method")

2019-05-27 Thread Han Yuwei via dev-security-policy
在 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

Re: Does Heartbleed count for the purposes of BR 4.9.11 point 11? ("proven or demonstrated method")

2019-05-27 Thread Ryan Sleevi via dev-security-policy
On Monday, May 27, 2019, Matt Palmer via dev-security-policy <> wrote:

> On Mon, May 27, 2019 at 06:06:42AM +0300, Ryan Sleevi wrote:
> > On Mon, May 27, 2019 at 4:34 AM Matt Palmer via dev-security-policy <
> >> wrote:
> > > 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:
> >
> > 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.
> Are you referring to the m.d.s.p archives, or somewhere else?  (Perhaps
> public@cabforum?) I have, in fact, gone through the m.d.s.p archives, and
> I
> can't see anything that addresses what I'm asking.  I can't even find a
> "lengthy" thread in
> security.policy/heartbleed%7Csort:date
> from around the time of Heartbleed that actually discusses revocation
> policy
> in any detail, just a couple of big ones that mention it in passing (like
> "DRAFT: May CA Communication").
> The thread that seems to come closest to touching on the issues is from
> 2017, and doesn't start off discussing Heartbleed, but rather just a mass
> of
> compromised keys:
> policy/71AXGTgcX9c/skHsKFdDBAAJ
> I assume that isn't the discussion you were referring to, because it is so
> far removed, temporally, from "handling Heartbleed".
> I would appreciate it if you could point me specifically to the relevant
> past discussions, so I can inform myself of the past decision.
> - Matt
The very first result for “revocation Heartbleed” returns
policy/ItSu2bebBKk/VrNXwL-MCZgJ , for example, which also links to

This also came up during the StartCom distrust decision, also linked from
that same query:
JpdMjH98GQAJ , which included related bugs.
dev-security-policy mailing list