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. On Tuesday, March 11, 2025 at 6:12:05 AM UTC+8 Matt Palmer wrote: > 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 > > -- 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/6727fb6a-1eb5-442d-a392-db6b87517a50n%40mozilla.org.