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. On Saturday, March 8, 2025 at 2:28:37 AM UTC+8 Rollin Yu wrote: > 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. > 在2025年2月16日星期日 UTC+8 08:57:41<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 >> >> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/e7ec7cca-3014-4ad0-92f4-681cc8f19917n%40mozilla.org.
