> On 1 Nov 2024, at 7:28 AM, Roman Fischer <[email protected]> wrote: > > Key-generation isn't that cheap and the larger the keys get, the more > expensive it gets. > Also, the CA's would probably need to feed and query one central database of > "used" keys to prevent the re-use.
Private Key Compromise Transparency (PKCT), as mentioned in https://mailarchive.ietf.org/arch/msg/trans/tB8YhAapz_6RN9MJVMKlRCR9HK0/, might help to make this information available to all CAs. > > -Roman > > From: Mike Shaver <[email protected] <mailto:[email protected]>> > Sent: Freitag, 1. November 2024 13:16 > To: Roman Fischer <[email protected] > <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > Subject: Re: Assuming keyCompromise for unspecified-reason revocations > > I guess I’m curious about the opposite question: why is it important that a > key be permitted to be reused ever? I understand that there are some > operational shortcuts that can be taken to avoid deploying a new key along > with a new certificate, but I’m not sure if there are other reasons to not > just require a new private key for every certificate. They are cheap to > generate! > > I feel a nagging at the back of my brain as I ask this question, so I > anticipate that someone will provide a tremendously obvious answer. > > Mike > > On Fri, Nov 1, 2024 at 6:00 AM Roman Fischer <[email protected] > <mailto:[email protected]>> wrote: > Dear Jamie, > > I don't see what's the final goal here. Is it to prohibit anybody from > re-using any key that was ever involved in a certificate that was revoked > (any reason could be "false" or "mistaken")? Or also keys of certificates > that expired (not everybody who has a key compromise reports it or revokes > the certificate, they might just create a new key and let the cert expire)? I was only suggesting to prohibit reuse of keys for certificates revoked without reason (“unspecified” reasonCode) as there is a chance they are compromised. Though, preventing overall reuse of any key seems like the safer approach but I don’t really know what type of negative implications it might bring. -- 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/F61FC7BF-E7BA-40DA-877C-3C6AE6605BFF%40gmail.com.
