We are, in fact, evaluating those other claims, and testing them in our labs. We are also evaluating claims made by other researchers, both publicly and privately; and we hope to end up with both a better library out of this, as well as a better understanding of the hazards we do and don't provide safeties against.

Validating his first claim was sufficient to undermine our belief in key safety; the others are therefore only relevant for protection against future attacks. In that light, it was important to advise our customers and the community at large.

I think it is important to remember when validating flaws, that we show that attacks are possible not they are necessarily demonstrated. Just because one cannot construct an exploit doesn't mean that something is secure.

They also said

> In parallel, we are evaluating the other claims made by the researcher, to understand what actions we can take to improve our customer protection.

which seems to imply that they're at least looking into the other questions.

Why would their update need to address more than just (1)? That's the only part of the problem that they have to deal with. The OpenSSL team should be the one answering (2) and (3), since it's OpenSSL that copies the PK/parts after it's been read, or allocate temp vars for intermediates. If Akamai chooses to patch those two problems and then releases it to open source like their initial patch, then they can answer them, but otherwise, what's the point?

(2) & (3) are not bugs for OpenSSL because only Akamai is trying to segregate the key data.

In upstream OpenSSL the intermediates are stored in the same memory pool as the key data. Thus the intermediates do not expose privileged data anywhere it is not already present.

Without addressing issues 2 & 3 Akamai's patch is not a line of defense. It does not guard against dirty memory exploits like Heartbleed, it only increases the difficulty of exploitation.