> What I do in badkeys is that I don't blocklist keys, but values. > Modulus for RSA, x coordinate for EC.
I agree that this approach makes sense. > The debian bug is a good example why this is a good idea: You can > create RSA keys with e=3 with that old openssl version, the default is > e=65537. If you block whole keys and you would want to consider that > you'd need to double the number of keys to block. But if you block the > modulus you already have that case covered. That's only true for a key-based blocklist system that doesn't "normalize" the keys, whereas I'm suggesting modifying the blocked keys and the candidate keys as follows... - always set the RSA modulus to 65337 - always use the uncompressed ECC key format - always re-encode the key to ensure canonical DER encoding ...before adding them to the blocklist or checking if they're already blocked. I think that both your approach and my approach are valid. If starting from scratch, I'd choose your approach. My approach is a bit more complex and probably will require more care when implementing, but it might be a better fit for any CA that already has a key-based blocklist system. ________________________________ From: Hanno Böck <ha...@hboeck.de> Sent: 09 September 2022 10:54 To: 'Rob Stradling' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> Cc: Rob Stradling <r...@sectigo.com> Subject: Re: Debian Weak Keys and ECDSA CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, 8 Sep 2022 13:44:42 +0000 "'Rob Stradling' via dev-security-policy@mozilla.org" <dev-security-policy@mozilla.org> wrote: > I think the best approach is for CAs to use some sort of normalized > form when performing key checks. For example: always set the public > exponent to 65537 before adding an RSA public key to a blocklist (or > before checking if it's already blocked); and always convert the EC > point to the uncompressed form before adding an EC public key to a > blocklist (or before checking if it's already blocked). What I do in badkeys is that I don't blocklist keys, but values. Modulus for RSA, x coordinate for EC. For EC this makes me not worry about any encoding issues, and the x coordinate is enough to uniquely identify a key. For RSA there's a simple mathematical reason: If you have two keys with the same N and different e, and one key is broken, then the other is automatically broken as well (because if you know d you can factor N and this calculate any other key with the same N and a different e). The debian bug is a good example why this is a good idea: You can create RSA keys with e=3 with that old openssl version, the default is e=65537. If you block whole keys and you would want to consider that you'd need to double the number of keys to block. But if you block the modulus you already have that case covered. -- Hanno Böck https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhboeck.de%2F&data=05%7C01%7Crob%40sectigo.com%7C4d43f347f71349be633f08da92494d60%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637983140782112990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1%2FJSZWKBXbfcEmOLqtn4KmCFLfeexknrcmtU767SFFg%3D&reserved=0 -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/MW4PR17MB472958CD8A0074999535E980AA479%40MW4PR17MB4729.namprd17.prod.outlook.com.
