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 -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/59159d25-fbfd-4c0b-aa39-137c0174c987%40mtasv.net.
