Digicert issued certificate with let's encrypts public key

[Kurt Roeckx]

Hi,

Browsing crt.sh, I found this:
https://crt.sh/?id=1902422627

It's a certificate for api.pillowz.kz with the public key of Let's
Encrypt Authority X1 and X3 CAs.

It's revoked since 2020-01-31, but I couldn't find any incident
report related to it.


Kurt

[Andrew Ayer]

On Sat, 16 May 2020 14:02:42 +0200
Kurt Roeckx via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> https://crt.sh/?id=1902422627
>
> It's a certificate for api.pillowz.kz with the public key of Let's
> Encrypt Authority X1 and X3 CAs.
>
> It's revoked since 2020-01-31, but I couldn't find any incident
> report related to it.

Hi Kurt,

It's not obvious what's non-compliant about this certificate - could you
explain? Note that there is no requirement or security need for CAs to
validate proof of possession of a private key. Therefore, it's
entirely acceptable for a subscriber to request a certificate for
someone else's public key, although the certificate would be useless to
them.

Regards,
Andrew

[Kurt Roeckx]

On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via dev-security-policy wrote:
> On Sat, 16 May 2020 14:02:42 +0200
> Kurt Roeckx via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > https://crt.sh/?id=1902422627
> >
> > It's a certificate for api.pillowz.kz with the public key of Let's
> > Encrypt Authority X1 and X3 CAs.
> >
> > It's revoked since 2020-01-31, but I couldn't find any incident
> > report related to it.
>
> Hi Kurt,
>
> It's not obvious what's non-compliant about this certificate - could you
> explain? Note that there is no requirement or security need for CAs to
> validate proof of possession of a private key.

I was under the impression that there was. But looking at the BRs,
3.2.1 is just empty.


Kurt

[Ryan Sleevi]

On Sat, May 16, 2020 at 10:11 AM Kurt Roeckx via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> On Sat, May 16, 2020 at 10:04:24AM -0400, Andrew Ayer via
> dev-security-policy wrote:
> > On Sat, 16 May 2020 14:02:42 +0200
> > Kurt Roeckx via dev-security-policy
> > <dev-secur...@lists.mozilla.org> wrote:
> >
> > > https://crt.sh/?id=1902422627
> > >
> > > It's a certificate for api.pillowz.kz with the public key of Let's
> > > Encrypt Authority X1 and X3 CAs.
> > >
> > > It's revoked since 2020-01-31, but I couldn't find any incident
> > > report related to it.
> >
> > Hi Kurt,
> >
> > It's not obvious what's non-compliant about this certificate - could you
> > explain? Note that there is no requirement or security need for CAs to
> > validate proof of possession of a private key.
>
> I was under the impression that there was. But looking at the BRs,
> 3.2.1 is just empty.

Yeah, that’s intentional, at least with regards to server certificates, as
it is not necessary for such certificates.

As Andrew mentioned, there are no requirements here and it’s not a
violation of any expectation, in the Baseline Requirements or in any Root
Programs’ policies.

>

[Peter Gutmann]

Kurt Roeckx via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>Browsing crt.sh, I found this: https://crt.sh/?id=1902422627

>
>It's a certificate for api.pillowz.kz with the public key of Let's Encrypt
>Authority X1 and X3 CAs.

How could that have been issued? Since a (PKCS #10) request has to be self-
signed, does this mean Digicert aren't validating signatures on requests?

Peter.

[Peter Bowen]

On Sat, May 16, 2020 at 8:18 PM Peter Gutmann via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Kurt Roeckx via dev-security-policy <dev-secur...@lists.mozilla.org>
> writes:
>
> >Browsing crt.sh, I found this: https://crt.sh/?id=1902422627
> >
> >It's a certificate for api.pillowz.kz with the public key of Let's
> Encrypt
> >Authority X1 and X3 CAs.
>
> How could that have been issued? Since a (PKCS #10) request has to be
> self-
> signed

There is no requirement to submit a PKCS#10 CSR.

>

[Peter Gutmann]

Peter Bowen <pzb...@gmail.com> writes:

>There is no requirement to submit a PKCS#10 CSR. 

Hmm, so what sort of issue process allows you to obtain a certificate for a key you don't control?

Peter.

[Corey Bonnell]

> Hmm, so what sort of issue process allows you to obtain a certificate for a key you don't control?

Certificate renewal that uses the existing certificate as input, rather than a CSR. The (presumably expiring) certificate supplies the domains, organization info, and the public key for the renewal certificate request. In this case there is no proof of key possession absent some out-of-band process (TLS handshake with the web server, etc).

Thanks,
Corey

[Peter Gutmann]

Corey Bonnell <cbon...@outlook.com> writes:

>Certificate renewal that uses the existing certificate as input, rather than
>a CSR. The (presumably expiring) certificate supplies the domains,
>organization info, and the public key for the renewal certificate request. In
>this case there is no proof of key possession absent some out-of-band process
>(TLS handshake with the web server, etc).

But if it's a renewal based on an existing cert, meaning that someone already
had a cert for a key they don't control, that means that at some point in the
past the CA turned a CSR for a key the requester doesn't control into a cert.

In particular, there must have been some authorisation carried out at some
point, or perhaps that wasn't carried out, that indicates who requested the
cert. What I'm trying to discover is where the gap was, and what's required
to fix it in the future.

Peter.

[Matthew Hardeman]

> In particular, there must have been some authorisation carried out at some
> point, or perhaps that wasn't carried out, that indicates who requested the
> cert. What I'm trying to discover is where the gap was, and what's
> required
> to fix it in the future.
>

What gap, exactly? There’s not a risk here.

I don’t think it’s been codified that private key possession or control has
to be demonstrated.

I think it would be plausible for a CA to allow submission of a public key
in lieu of a CSR and that nothing would be wrong about it.

[Peter Gutmann]

Matthew Hardeman <mhar...@gmail.com> writes:

>What gap, exactly?  There’s not a risk here.

There are attacks possible, but this stuff was covered more than twenty years
ago by PKIX and I can't remember the specifics. It was around various ways of
fooling a victim that you'd signed something that you hadn't based on the two
different certs.

>I don’t think it’s been codified that private key possession or control has
>to be demonstrated.

All the PKIX cert-enrolment protocols (CMP, CMC, and plain PKCS #10) as well
as the non-PKIX SCEP require proof-of-possession in order to deal with these
problems. Unfortunately in the PKIX tradition the spec just says "In order to
prevent certain attacks" without ever saying what they are.

I assume this is ACME that allows a key to be certified without any proof that
the entity requesting the certificate controls it? I don't know that any of
the PKIX protocols allow it.

Peter.

[Carl Mehner]

On Sun, May 17, 2020 at 10:47 PM Peter Gutmann via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I assume this is ACME that allows a key to be certified without any proof that
> the entity requesting the certificate controls it? I don't know that any of
> the PKIX protocols allow it.

I do not see anywhere in ACME that specifies how an ACME server or the
CA are to treat the CSR's signature field. Based on that, there is
nothing specific in ACME allowing this behavior.
(The only place I see talking about the private key associated with
the cert's public key is to sign messages for revocation.)

-carl mehner

[Matt Palmer]

On Mon, May 18, 2020 at 03:46:46AM +0000, Peter Gutmann via dev-security-policy wrote:
> I assume this is ACME that allows a key to be certified without any proof that
> the entity requesting the certificate controls it?

ACME requires a CSR to be submitted in order to get the certificate issued.
A quick scan doesn't show anything like "the signature on the CSR MUST be
validated against the key", but it does talk about policy considerations
around weak signatures on CSRs and such, suggesting that it was at least the
general intention of ACME to require signatures on CSRs to be validated.

In any event, given that the certs involved were issued by Digicert, not
Let's Encrypt, and Digicert's ACME issuance pipeline is somewhat of a niche
thing at present, I think it's more likely the problem lies elsewhere.

- Matt

[Jeremy Rowley]

I thought I posted on this a while ago, but I can't seem to find the post. It may have been CAB Forum (where the archives are nearly useless). The conclusion from that is the CSR isn't required as part of the issuance process because there isn't a risk without having actual control over the private key. The worst someone can do is....demonstrate the existence of a cert with a bad public key?

For those interested, the short of what happened is that we had an old service where you could replace existing certificates by having DigiCert connect to a site and replace the certificate with a key taken from the site after a TLS connection. No requirement for a CSR since we obtained proof of key control through a TLS connection with the website. Turned out the handshake didn't actually take the key, but allowed the customer to submit a different public key without a CSR. We took down the service a while ago - back in November I think. I plan to put it back up when we work out the kink with it not forcing the key to match the key used in the handshake.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Peter Gutmann]

Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>For those interested, the short of what happened is that we had an old
>service where you could replace existing certificates by having DigiCert
>connect to a site and replace the certificate with a key taken from the site
>after a TLS connection. No requirement for a CSR since we obtained proof of
>key control through a TLS connection with the website. Turned out the
>handshake didn't actually take the key, but allowed the customer to submit a
>different public key without a CSR. We took down the service a while ago -
>back in November I think. I plan to put it back up when we work out the kink
>with it not forcing the key to match the key used in the handshake.

Thanks, that was the info I was after: was this a general problem that we need
to check other systems for as well, or a situation-specific issue that
affected just one site/system but no others. Looks like other systems are
unaffected.

Peter.

[Jeremy Rowley]

It was just the one system and situation-specific.

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Peter Gutmann via dev-security-policy
Sent: Monday, May 18, 2020 6:31 AM
To: Matt Palmer <mpa...@hezmatt.org>; Mozilla <mozilla-dev-s...@lists.mozilla.org>; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: Digicert issued certificate with let's encrypts public key

[Matthew Hardeman]

I certainly recall descriptions of other issuing systems in history in
which it was (at least based on the description) possible to get a
certificate issued without proof of control of the private key.

A scary example, I know, but StartCom's original system was once described
as taking the public key data (and they emphasized _only_ the public key
data) from the CSR. Everything else was populated out-of-band of any PKI
protocols via the website.

Frankly, I don't see how anyone permitting signature over a third party
public key without proof of control of the matching private key creates a
risk. I think if there are relying-party systems where this creates a
problem, the error is in those relying-party systems and their respective
validation logic.

[Ryan Sleevi]

On Mon, May 18, 2020 at 11:40 AM Matthew Hardeman via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> A scary example, I know, but StartCom's original system was once described
> as taking the public key data (and they emphasized _only_ the public key
> data) from the CSR. Everything else was populated out-of-band of any PKI
> protocols via the website.
>
> Frankly, I don't see how anyone permitting signature over a third party
> public key without proof of control of the matching private key creates a
> risk. I think if there are relying-party systems where this creates a
> problem, the error is in those relying-party systems and their respective
> validation logic.

Why would StartCom's system be "A scary example" when you acknowledge
that you don't see how it creates a risk? The scenario you ascribe to
StartCom is exactly what is recommended, of CAs, in numerous CA
incident bugs where the failure to apply that restrictive model has
lead to misissuance.

[Matthew Hardeman]

I did not state the point well. "Scary example" as I used it above was
merely because it was a reference to StartCom at all (given the history,
etc.) -- not particularly in the context of this practice.

I concur that I see no risk in leaf certificates issued with signatures
over public keys for which neither ownership or control of the
corresponding private key have been established.

I merely wished to add an example case to the discussion in which it was
presumably possible to have leaf certificates issued over a public key for
which the control of private key had not been proven.

[Matthew Hardeman]

On Mon, May 18, 2020 at 12:44 PM Ryan Sleevi <ry...@sleevi.com> wrote:

> The scenario you ascribe to
> StartCom is exactly what is recommended, of CAs, in numerous CA
> incident bugs where the failure to apply that restrictive model has
> lead to misissuance.
>

Separate to the matter in discussion in this thread, my understanding of
CSR processing best practice mirrored what you say here -- take the minimum
that you require from the structure and discard the rest. I was surprised
in reading the ACME specs that various factors for issuance rely upon data
in the rather flexible but (relatively) complex data structure that is the
CSR, like requested DNS names, whether or not OCSP must-staple is desired,
etc.

I am curious what the authors' intent was there. Was it possibly a desire
to adhere to the original functional intent of the CSR as elsewhere
specified, irrespective of the known risks which had been previously
demonstrated in bad CA implementations?

[Kyle Hamilton]

CABForum's current Basic Requirements, section 3.2.1, is titled "Method to
prove possession of private key".

It is currently blank.

A potential attack without Proof of Possession which PKIX glosses over
could involve someone believing that a signature on a document combined
with the non-possession-proved certificate constitutes proof of possession,
and combined with external action which corroborates the contents of the
document could heuristically evidence the authority to issue the document.
(Yes, this would be a con job. But it would be prevented if CAs actually
had the applicant prove possession of the private key.)

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.)

With proof of possession, these situations can be detected and raised as
being not-just-theoretical, and the CAs (or whoever wants to search the CT
logs) can notify the entities involved that they probably want to change
their keys. In the case of CA keys potentially being duplicated, this is an
incredibly important capacity. In the case of EV certificate keys being
duplicated, it can be a reportable event for the certified entities (such
as banks) if copies of their private key are found to be in the possession
of anyone else.

Non-zero probability of duplication is not zero probability of duplication,
and relying on it being "close enough to zero" is eventually going to bite
us all. It's up to those who work for CAs to put in mitigations for when
that day ultimately arrives, or else risk the viability of not only their
businesses but every other CA business they compete with.

So, I request and encourage that CABForum members consider populating
clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be
mandated.

-Kyle H

On Sun, May 17, 2020, 22:23 Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > In particular, there must have been some authorisation carried out at
> some
> > point, or perhaps that wasn't carried out, that indicates who requested
> the
> > cert. What I'm trying to discover is where the gap was, and what's
> > required
> > to fix it in the future.
> >
>

> What gap, exactly? There’s not a risk here.
>

> I don’t think it’s been codified that private key possession or control has
> to be demonstrated.
>

> I think it would be plausible for a CA to allow submission of a public key
> in lieu of a CSR and that nothing would be wrong about it.

[Ryan Sleevi]

On Mon, May 18, 2020 at 7:55 PM Kyle Hamilton via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> A potential attack without Proof of Possession which PKIX glosses over
> could involve someone believing that a signature on a document combined
> with the non-possession-proved certificate constitutes proof of possession,
> and combined with external action which corroborates the contents of the
> document could heuristically evidence the authority to issue the document.
> (Yes, this would be a con job. But it would be prevented if CAs actually
> had the applicant prove possession of the private key.)

The problem with this attack is that it has no relevance to TLS and
server certificates. Which is important to understand, especially why
the omission is, as I stated, intentional.

I appreciate the appeal to theoretical purity of consistency among
PKIs, but comparing the needs of one PKI with the needs of another is
not a reasonable comparison to make. That same logical leap would have
all keys in HSMs in safes, or forbid keys from being in safes, both of
which we know are appropriate or inappropriate - depending on the use
case.

> 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.

[Peter Gutmann]

A bit of philosophical question here: Certificates are pretty much universally
described in PKI texts and the like as a cryptographic binding between an
identity and a key, in other words an assertion by the CA that the key in the
cert is associated with the identity in the cert.

If there's no requirement to verify that this is the case by CAs issuing
certificates, doesn't this make what they're producing a non-certificate?

This isn't snark, it's a genuine question: If the CA isn't checking that the
entity they're certifying controls the key they're certifying, aren't they
then not acting as CAs any more?

Peter.

[Kyle Hamilton]

That is my reading of the situation, that they're not doing an actual
certification of an enrollment without verifying the actual key-identity
binding.

In addition, I'm wondering if the concept of "third-party attestation" (of
identity) is even a thing anymore, given that most CAs issue certificates
for their own websites.

-Kyle H

[Kyle Hamilton]

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

[Paul Wouters]

On May 18, 2020, at 23:58, Peter Gutmann via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>
>
> This isn't snark, it's a genuine question: If the CA isn't checking that the
> entity they're certifying controls the key they're certifying, aren't they
> then not acting as CAs any more?

They are really only certifying that the requester can control the dns for the domain name mentioned in the certificate anyway. The same function DNSSEC provides without middle men :)

Paul

[Ryan Sleevi]

This is a strawman argument based on fundamental misunderstanding, not the
logical end. You’ve directly conflated public and private key, and confused
the ability to create a signature with attribution.

In short: this is utter nonsense.

I’m disappointed to even need to point out how unsound the statement of
“another entity was certified as being able to make signatures which could
be technically attributed to the Let's Encrypt CA” is.

This doesn’t hold water at all. The Issuing CA is not certifying a proof of
possession of a private key, so naturally you can’t (and shouldn’t)
conclude it is a proof of possession of a private key. This is basic.

> 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.
>

This is, continuing, nonsense. This is entirely unnecessarily precisely
because it *isn’t* a proof of possession of private key.

> (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).
>

Again, you’re trying to call it both ways. You’re right to point out the
logical absurdity of having your cake and eating it to, but you’re missing
that you’re the one making that claim.

The concerns you raise are there only if you believe it is a PoP. As I’ve
said, repeatedly, it is not, nor should it be. These concerns entirely
disappear.

A TLS Certificate is an expression of authorization, by the domain holder,
to allow a public key to be used for their domain. The domain holder is
permitted to express whatever public key(s) they want, with all the
attendant risk, and the certificate is an expression that the CA has
verified that assertion and expression by the domain holder.

Similarly, in the case of OV/EV, it’s similarly an expression that the
given identity has authorized the key.

You’re arguing in favor a property - non-repudiation - that by very
protocol does not exist for TLS, nor does it need to. The potential use
cases for such a property can be addressed by other protocols/formats, with
their own corresponding certificates (e.g. document signing certificates
for signing documents that cannot be repudiated).

>

[Matthew Hardeman]

On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton <kya...@kyanha.net> wrote:

> A potential attack without Proof of Possession which PKIX glosses over
> could involve someone believing that a signature on a document combined
> with the non-possession-proved certificate constitutes proof of possession,
> and combined with external action which corroborates the contents of the
> document could heuristically evidence the authority to issue the document.
> (Yes, this would be a con job. But it would be prevented if CAs actually
> had the applicant prove possession of the private key.)
>

Could you explain how this is different from other stretches of fitness for
purpose? For example, I can use Lipton's tea leaves as guidance dictates -
for making a beverage purportedly fit for human consumption. I can also
try to diving events of the future by finding meaning in the patterns of
the tiny dregs of tea leaf left in the bottom of my mug. But I should
expect to get laughed at by Lipton customer service if I ask for assistance
with this or appear to be taking these predictions seriously.

On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton <kya...@kyanha.net> wrote:

> CABForum's current Basic Requirements, section 3.2.1, is titled "Method to
> prove possession of private key".
>
> It is currently blank.
>

> A potential attack without Proof of Possession which PKIX glosses over
> could involve someone believing that a signature on a document combined
> with the non-possession-proved certificate constitutes proof of possession,
> and combined with external action which corroborates the contents of the
> document could heuristically evidence the authority to issue the document.
> (Yes, this would be a con job. But it would be prevented if CAs actually
> had the applicant prove possession of the private key.)
>

> 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.)
>

[Matthew Hardeman]

On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton <kya...@kyanha.net> wrote:

> With proof of possession, these situations can be detected and raised as
> being not-just-theoretical, and the CAs (or whoever wants to search the CT
> logs) can notify the entities involved that they probably want to change
> their keys. In the case of CA keys potentially being duplicated, this is an
> incredibly important capacity. In the case of EV certificate keys being
> duplicated, it can be a reportable event for the certified entities (such
> as banks) if copies of their private key are found to be in the possession
> of anyone else.
>

How, precisely? Today, the vast majority of certificates lack any
end-entity identifying factors other than some number of SAN dnsName
entries. In modern CDNs (example: CloudFlare), a single certificate might
represent a plurality of entirely unrelated websites run by entirely
unrelated entities who happen to share a service provider in common. In as
far as that these sites are already sharing a TLS concentrator -- while it
is not the practice of anyone I know of -- such a service provider could
have quite a number of TLS concentrator elements sharing (access to) a
public/private key pair and might choose to provision quite a number of
unrelated certificates with the same key.

Two certificates issued at two different times containing the same public
key is not proof one way or the other. It does not prove two entities are
definitely related. It does not prove that they are not. But the fact
that proof of possession isn't required increases the plausibility that it
does not prove a relationship. I wonder if the attendant ambiguity has
saved anyone's head from rolling.

[Matthew Hardeman]

On Mon, May 18, 2020 at 6:55 PM Kyle Hamilton <kya...@kyanha.net> wrote:

> So, I request and encourage that CABForum members consider populating
> clause 3.2.1 of the Basic Requirements, so that Proof-of-Possession be
> mandated.
>

I don't mean to beat a dead horse, and without addressing the merits of
trying to consider a leaf certificate issued over a particular public key
as proof-of-possession/control of the corresponding private key, I add one
further practical problem:

The standard use of the most common way of communicating the public key and
the purported proof-of-possession of the private key to the CA, the CSR,
does not provide replay protection and yet is frequently NOT treated as a
security impacting element should it be disclosed post-issuance. As such,
one must question if an arbitrary CSR which contains a valid signature
produced using the private key which corresponds to the subject public key
in same said CSR is really qualified to be considered proof-of-possession
(or proof of control) of said private key. I submit that it is not.

[Peter Gutmann]

Matthew Hardeman via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>The standard use of the most common way of communicating the public key and
>the purported proof-of-possession of the private key to the CA, the CSR, does
>not provide replay protection and yet is frequently NOT treated as a security
>impacting element should it be disclosed post-issuance. As such, one must
>question if an arbitrary CSR which contains a valid signature produced using
>the private key which corresponds to the subject public key in same said CSR
>is really qualified to be considered proof-of-possession (or proof of control)
>of said private key. I submit that it is not.

All of the cert management protocols I referenced earlier, CMP, CMC, and SCEP
but not ACME which I haven't implemented so I'm not sure about, have liveness
constraints. In other words you can't replay an old CSR to get a new cert.

Even if there is a bare-CSR way to get a cert, the only thing you could do
with it is get the same cert issued with a more recent expiry date. Since
everyone clicks past expired certs anyway and when they're used for things
like code signing they're countersigned by a TSA to give them an indefinite
lifetime, I'm not sure that it gets an attacker much.

Having said that, it's another one of the many PKI things that just get done a
certain way without anyone ever presenting a threat model that justifies it,
so it could be a threat in some manner.

Peter.

[Corey Bonnell]

While I realize the current topic is concerning TLS, I find it rather surprising that Mozilla Policy does not mandate PoP for S/MIME certificate issuance. Lack of checking for S/MIME would present more concrete security concerns, so perhaps this should be addressed in a future update to the Policy.

Thanks,
Corey

[Ben Wilson]

Thanks, Corey.
I've added this as a matter to consider in a future version of the Root
Store Policy. https://github.com/mozilla/pkipolicy/issues/215