Rejecting incorrectly padded EC JWKs

In November of 2018 we were made aware that Boulder would accept EC JWKs that used invalid X/Y padding produced by some clients. While this had no security impact it did cause issues with some clients as Boulder would re-encode the JWKs using the proper padding. This caused some clients to think that Boulder was returning a different key when it was returned to the user (for example when using the /acme/new-acct endpoint).

After fixing this issue we decided to monitor how prevalent it was before enabling the fix. We found an extremely small number of users that exhibited the issue, but unfortunately the clients these users were using do not send the User-Agent header so we were unable to identify them and file bugs. Given that the number of users that will be impacted is quite small we’ve decided to enable the fix in staging starting next week (the week of the 28th of June). Once this fix is deployed if a JWK using the incorrect padding is provided we will return an error indicating EC public key has incorrect padding. Accounts initially created using incorrectly padded JWK will still be able to use their accounts, but the JWK their client sends will need to be encoded using the correct padding.


This is now live in staging and will be moved into production next week.