Discussions on mechanism to enhance the Use of Digital Certificate Private Keys Similar to PwnedKeys

[Arabella Barks]

Should Mozilla provide a service similar to Pwnedkeys to verify whether the digest of an asymmetric private key matches the weak keys library and all key libraries where the keys have been revoked by CAs and marked as keyCompromised?

[Matt Palmer]

Out of curiosity, what benefits do you think Mozilla would get from
running such a service? Unsurprisingly, I can think of a few
possibilities, but I'm keen to see what you (and others) think.

- Matt
(posting in my capacity as Pwnedkeys' God-King, CEO, and assistant bottle-washer)

[Arabella Barks]

In my opinion, currently each Certificate Authority (CA) can only identify and reject the public keys revoked due to key compromise within its own PKI, but not those from other CAs. However, I believe that CAs have the obligation to submit the public keys of compromised keys to PwnedKeys, a centralized service. They are also obliged to conduct verification via PwnedKeys when receiving CSR to prevent the use of leaked or insecure keys.

It is appropriate for this centralized service to be operated by entities like Mozilla or Google, which have their own independent root inclusion policies or programs.

Moreover, we need a neutral yet mandatory service to address the issue of sharing information about compromised keys.

[Matt Palmer]

On Thu, Feb 06, 2025 at 10:48:28PM -0800, Arabella Barks wrote:
> In my opinion, currently each Certificate Authority (CA) can only identify
> and reject the public keys revoked due to key compromise within its own
> PKI, but not those from other CAs. However, I believe that CAs have the
> obligation to submit the public keys of compromised keys to PwnedKeys, a
> centralized service. They are also obliged to conduct verification via
> PwnedKeys when receiving CSR to prevent the use of leaked or insecure keys.

Overall, I agree with your sentiment -- I believe that the WebPKI would
be strengthened if CAs were obliged to perform more due diligence around
known problems with private keys before issuing certificates, if for no
other reason than post-issuance revocation is a very lacklustre control,
given the poor support for revocation in the WebPKI. This does not
appear to be a widely shared sentiment, however I applaud your desires
to increase awareness of the problem.

There are a couple of practical problems with the idea of CAs sharing
public keys reported to them as compromised, however, mostly around the
lack of verifiability, and opportunities for attacks. I looked into
this some time ago, after a private discussion on this topic with
someone from a prominent actor in the WebPKI. The conclusion I came to
was that, at present, any scheme involving having CAs report keys as
compromised due to revoking the associated certificate with the
"keyCompromise" reason is a very dangerous proposition.

The issue is that there is no requirement for a CA to robustly verify
proof-of-possession of the private key for which they issue a
certificate. This means that, in a world where reporting a certificate
as needing to be revoked due to key compromise causes that key to be
placed on a global naughty list, would almost invariably lead to the
following attack:

1. Good Guy Greg gets a certificate issued for
gooeguygreg.example.net, using a key they control, whose public key
is P.

2. Naughty Nell gets a certificate issued for naughtynell.example.com,
which includes the same public key P in the certificate. Nell can do
this because they choose to use a WebPKI CA and issuance method that
does not provide proof-of-possession of the private key for P.

3. Naughty Nell now goes to their CA and reports the certificate for
naughtynell.example.com as needing to be revoked due to key compromise.
Note that at this point the CA can't require proof-of-possession,
because there are entirely valid key compromise scenarios where the
legitimate subscriber would lose access to the private key (think
ransomware, for example).

4. Upon revoking the certificate for key compromise, the CA then reports
public key P as having been compromised, as the rules require them to
do.

5. Good Guy Greg's entirely legitimate certificate gets revoked because
its key has been reported to the "Central Key Compromise Clearinghouse",
even though the key was never actually compromised. While we know that
subscribers are _supposed_ to be able to replace compromised
certificates quickly, there are puh-lenty of examples where certificates
can't be replaced within *five days*, let alone the 24 hours required
for key-compromised certificates. Thus, Good Guy Greg's site could very
well be denied service until a new certificate can be issued and
installed.

Now, I know there are a variety of mitigations that could solve for this
attack -- for example, requiring robust proof-of-possession before
issuing a certificate. However, those mitigations are not in place yet,
and would take considerable time to standardise and roll out to all
WebPKI CAs. Thus, "CAs should report all key-compromised certificates
to a central clearing house", while a great idea, is not something that
can happen any time soon, and is a much larger undertaking than it might
appear at first glance.

That's only one viable attack scenario that I've thought of. I've got
several more, most of which are even harder to mitigate, such as key
flooding.

> It is appropriate for this centralized service to be operated by entities
> like Mozilla or Google, which have their own independent root inclusion
> policies or programs.

Mmmm, I think any proposal of this kind would receive _heavy_ push-back
from CAs. Having to do real-time checks of any kind during certificate
issuance is never something that CAs like, as it slows down the issuance
process -- consider how CAs have not been leaping with joy at the
existence of linting tools, and how much over-engineering had to be put
into CT in order to accomodate CAs' desire not to block the pipe.

If each trust store mandated a check against their own list of
compromised keys, that would be mandating *multiple* real-time
pre-issuance checks, and I would expect CAs to absolutely lose their
minds at the idea.

> Moreover, we need a neutral yet mandatory service to address the issue of
> sharing information about compromised keys.

If there were one service, run by one of the trust stores, that the
various trust stores all required, that would ease the proliferation
concerns, but the next question that would inevitably arise would be:
who would run it? To get any one of the trust stores to spin up
something from scratch and commit to operating it basically forever
would be a politically and financially non-trivial undertaking, and
would, I expect, only happen if there were someone within that
organisation who had an absolutely burning desire to see it happen.

Now personally, I'd be fine with trust stores mandating that all CAs had
to use Pwnedkeys, but I expect that there would be, to put it mildly, a
certain degree of understandable concern expressed, from many different
contituencies, around single-points-of-failure, monopoly, and similar
such things.

Mandating that CAs use _a_ third-party source of compromised key
information, without specifying anything about which one to use, would
ease the single-point-of-failure concern, but then you've got the
quality problem to address. After all, CAs are _already_ required to
maintain and consult some sort of list of keys for which they will not
issue, but we still see problem reports now and then where a certificate
is issued for a key that should _absolutely_ not be used, and the root
cause is invariably found to be "oh, that key wasn't on our list, but
we've definitely got the full list now, yep absolutely, you can totally
trust us".

I have absolutely no doubt that, were a requirement to use a third-party
source of compromised key data instituted, many CAs, either through
ignorance or apathy, would use whatever was easiest for them, rather
than what would be best for the WebPKI, and certificates would still be
issued to keys that other sources of compromised key data already knew
all about. Putting in meaningful requirements for data quality
would basically amount to mandating the use of one service (or at most a
couple), as it isn't exactly a large and vibrant market with a wide
variety of players whose data is broad and up-to-date.

- Matt

[Rollin Yu]

We analyzed certificate revocation data using the All Certificate Information provided by CCADB:
• Extracted CRL URLs from AllCertificateRecords: 8,577
• Successfully retrieved valid CRLs: 7,744
• Parsed revoked certificate serial numbers from these CRLs: 7,760,804
• Among them, certificates revoked due to CRLReason #1 (key compromise): 254,690
• Using these serial numbers (and AKID), we identified certificate data in our CT monitor database: 31,967

Although these public key data cannot serve as a basis for other CAs to revoke certificates, they can at least function as a public key blocklist  to prevent issuing certificates to these risky public keys.

Since CRL URLs and the revocation lists within CRLs are dynamic, and our CT monitor data may have gaps and delays, the above data is for reference only.

We seek the community’s input: Is maintaining a continuously growing public key blocklist in this manner feasible to prevent issuing certificates to potentially risky public keys? As the blocklist grows, constructing a Bloom filter might enhance the efficiency of public key checks.

[Arabella Barks]

Rollin Yu,

Thank you for your outstanding efforts - you've precisely demonstrated the enhanced key functionality for PwnedKeys + CAs.
My personal opinion is that this move will do nothing but good to improve the security of WebPKI.
I believe, decision regarding the standardization append into the BR will be thoughtfully determined by the WebPKI and MDSP communities.

Your company - TrustAsia must be a excellent contributor to the industry.

Arabella Barks.

[Peter Gutmann]

Rollin Yu <roll...@trustasia.com> writes:

>Among them, certificates revoked due to CRLReason #1 (key compromise):
>254,690

How reliable are those figures though? Unless an attacker thoughtfully
notifies you that they've stolen your key, how would anyone know it's been
compromised? What if it's just the default setting in software for
revocations, since keyCompromise is the very first CRL reason entry? What if
it's deliberately selected because keyCompromise gets given a higher priority
(urgent) than any other reason (oh, just FYI...).

What are the figures for other crlReasons? If superseded (due to forced cert
turnover) has a much lower count than keyCompromise then we can be pretty sure
the keyCompromise figures aren't realistic.

Peter.

[Jeremy Rowley]

7.2.2 requires CAs to make the default option be "Unspecified".

Under the Mozilla policy (6.1.1), CAs must only use the keyCompromise reason code for situations listed in the TLS BRs as associated with the reason code. keyCompromises requires evidence of a compromise or that the key can be easily computed.  A CA offering this reasoncode as the default probably violates the BR requirement. 

However, the Mozilla guidance is somewhat at odds with this requirement as it offers more reasons to choose keyCompromise than the BRs:

• the certificate subscriber requests that the CA operator revoke the certificate for this reason, with the scope of revocation being described below.

The potential conflict in language is mitigated by 7.2.2 which says that the subscriber should be able to choose keyCompromise. 

To implement something like this, I would make it a SHOULD to block compromised keys on the list and a MUST to at least check the list. That way the CA needs to block unless there is a good reason not to. Once we figure out and address any good reasons not to block the key that the CAs provide, you could move the requirement to block compromised keys on the list a MUST. 

IMO, the biggest issue with a global key compromise list is that you would not want a requirement tied to a specific list operated by one entity. You'd want CAs to choose any public list of available blocked keys. Tying issuing to a single provider wrecks havoc on issuance times and creates a single point of failure.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ME0P300MB0713ECDBD50465977986D726EED42%40ME0P300MB0713.AUSP300.PROD.OUTLOOK.COM.

[Rollin Yu]

As Jeremy highlighted, according to TLS BR 7.2.2, the default revocation reason shall be “unspecified (0)”, ensuring that “keyCompromise (1)” is not set as the default. TLS BR 4.9.1.1 specifies that the “keyCompromise (1)” reason code may be used in two scenarios: when the CA has obtained evidence of the subscriber’s private key compromise, or when the CA can easily compute the subscriber’s private key using known methods. In terms of urgency, both “unspecified (0)” and “keyCompromise (1)” require CAs to revoke the certificate within 24 hours upon the subscriber’s request.

Mozilla Root Store Policy section 6.1.1 and the Mozilla wiki on Revocation Reasons provide detailed guidance, allowing subscribers to request revocation with the “keyCompromise (1)” reason without providing explicit evidence. Therefore, if CAs operate in compliance with these standards, the “keyCompromise (1)” reason code in CRLs should be relatively reliable.
Based on my previous analysis, certificates revoked due to keyCompromise (1) account for approximately 3% of all revocation data.  

However, since Certificate Transparency (CT) logs primarily contain data on TLS certificates, the proportion of public keys associated with keyCompromise (1) revocations found in CT logs represents only about 0.4% of all revocation data.

Regarding the maintenance of a global key compromise list, community collaboration, especially from CT monitor data providers, would enhance its effectiveness.

[Suchan Seo]

form reading those I don't think it actually said to not use keyCompromise revocation reason when subscriber can't prove key leak, just ask CA to not apply revoke cert from different subscriber because of that: it'd be nightmare to manage but wording of documents allow set reason 1 for CRL just because subscriber explicitly say so.

2025년 3월 10일 월요일 오후 9시 51분 24초 UTC+9에 Rollin Yu님이 작성:

[Matt Palmer]

On Sun, Mar 09, 2025 at 10:55:36AM -0600, Jeremy Rowley wrote:
> To implement something like this, I would make it a SHOULD to block
> compromised keys on the list and a MUST to at least check the list. That
> way the CA needs to block unless there is a good reason not to. Once we
> figure out and address any good reasons not to block the key that the CAs
> provide, you could move the requirement to block compromised keys on the
> list a MUST.

Another thing to consider when implementing such a process is that CAs
_absolutely_ do not put the correct reason code in CRLs sometimes --
whether that's because the subscriber out-and-out lies to them, or for
some other reason. Only listing keys in certs revoked with a
keyCompromise reason won't get you everything.

> IMO, the biggest issue with a global key compromise list is that you would
> not want a requirement tied to a specific list operated by one entity.
> You'd want CAs to choose any public list of available blocked keys. Tying
> issuing to a single provider wrecks havoc on issuance times and creates a
> single point of failure.

Which is a problem in-and-of itself, because there aren't many reliable
lists out there. The Debian weak keys situation is the perfect case
study here -- more than a decade after the fact, and CAs were still
issuing certificates to weak keys, with the excuse that "we weren't
using a list of weak keys that included that one". So the BRs had to be
updated to provide a single, specific list that was the bare acceptable
minimum. The same thing will happen with any other "you must use a
list" requirement that doesn't specify either the precise source of the
list, or the precise content of the list -- CAs will choose the easy
option that feels like it obeys the requirement, not necessarily an
option that _actually_ obeys the requirement.

- Matt

[Arabella Barks]

Suchan Seo,

Regarding your concern about being included in the GlobalKeyCompromisedList without proof, I have a technical proposal: Since the CA definitely holds 100% of the CSR (Certificate Signing Request) submitted by the applicant when applying for a certificate, and the CSR contains the signature stamp of the private key on the application message, if the CA submits the CSR together when docking with the GlobalKeyCompromisedList, is it sufficient to prove that the applicant owns the private key?

I'm not sure if this is enough to ease your concerns. If there are any errors on my part, I’m pleased and welcome to see your corrections.

[Suchan Seo]

I personally don't care, but Current moziila revocation reason policy explictly not allow CSR as proof of key possesion:

 The scope of revocation depends on whether the certificate subscriber has proven possession of the private key of the certificate. A CSR alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation.

• If anyone requesting revocation for keyCompromise has previously demonstrated or can currently demonstrate possession of the private key of the certificate, then the CA operator MUST revoke all instances of that key across all subscribers.
• If the certificate subscriber requests that the CA operator revoke the certificate for keyCompromise, and has not previously demonstrated and cannot currently demonstrate possession of the associated private key of that certificate, the CA operator MAY revoke all certificates associated with that subscriber that contain that public key. The CA operator MUST NOT assume that it has evidence of private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key.

2025년 3월 25일 화요일 오후 3시 56분 10초 UTC+9에 Arabella Barks님이 작성:

[Aaron Gable]

Possession of a CSR is not proof of compromise. For a quick demonstration, here are 45k CSRs which I could submit to a revocation API, but for which I certainly do not control -- nor know anything about the compromise status of -- the corresponding private key.

Aaron

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/2c5ae5d4-e876-4a28-a18a-36bd2c2cc485n%40mozilla.org.