On Mon, May 18, 2020, 19:46 Ryan Sleevi <r...@sleevi.com> wrote:

> On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> > Regardless of that potential con, though, there is one very important
> thing
> > which Proof of Possession is good for, regardless of whether any credible
> > attacks are "enabled" by its lack: it enables identification of a
> situation
> > where multiple people independently generate and possess the same keypair
> > (such as what happened in the Debian weak-key fiasco). Regardless of how
> > often it might be seen in the wild, the fact is that on every key
> > generation there is a chance (small, but non-zero) that the same key will
> > be generated again, probably by someone different than the person who
> > originally generated it. (With bad implementations the chance gets much
> > larger.)
> This argument doesn't hold water. This is an argument not about proof
> of possession about private key, but about the public key itself.
> Multiple parties possessing the same key pair are revealed by the
> public key. Proof of possession provides zero value.

So... taking this argument to its logical end, Let's Encrypt should have
immediately revoked its public key when it was found to have been issued to
another entity by another member of CABF, which is supposed to operate
within the constraints of identification embedded in the Basic
Requirements.  (i.e., another entity was certified as being able to make
signatures which could be technically attributed to the Let's Encrypt CA,
which qualifies as "loss of control of the CA private key".  A private key
is not a device, or an authorized or unauthorized copy of a PKCS#8 or
PKCS#12 structure.  A private key is a sequence of bits which encodes a
value which, when operated upon in accordance with the rules of the
algorithm it was generated under, will generate a value which can be
verified (and possibly decrypted, in the case of RSA) with its
corresponding public key value.  Random generation means that the
independent generation of a keypair is always a potential risk.  The reason
we have a uniform and large key space and generation process is to minimize
the risk that this will happen, but a non-zero risk is not a zero risk.)

In this case, it becomes even more important for CAs to prove that the
private key is held by every person who claims it as being their public key
-- again, to change it from a theoretical/potential/too-expensive-to-act-on
threat to an actual key compromise scenario that mandates pushing the big
red button and holding a new key generation ceremony and regenerating the
PKI infrastructure and getting the new root key installed in browsers and
operating systems as soon as possible.

(or, if it's an intermediate, generating a new intermediate, contacting all
legitimate recipients and having them change their certificate chains, and
revoking the one that had its key independently discovered.)

Unfortunately, you can't have it both ways.  What's more important, correct
certificate issuance (the issuance is by the entity trusted to issue the
certificate), or lack of disruption?  The CA has always been expected to
err on the side of correct issuance (which is why, for example, the
Netherlands PKIOverheid intermediate was distrusted).

-Kyle H
dev-security-policy mailing list

Reply via email to