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 "[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/d9bedc36-4631-4ce6-9a2b-feb351e69ccc%40mtasv.net.
