You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The MAC key SHOULD be provided in base64url-encoded form, to maximize compatibility between non-ACME provisioning systems and ACME clients.
Right now from_base64_secret does base64-standard decoding. Is this common for other protocols that use HMAC keys?
I think a url-safe base64 method would be useful, since ACME users will have url-safe base64 strings from ACME providers and they'd be able to bridge that to this library without needing an extra direct dependency just to hand the key over. Url-safe base64 also aligns with a lot of the rest of the JOSE specs so I'd expect that to be common.
Sorry, this is a pretty trivial issue, but what about something like from_urlsafe_base64_secret or from_base64_hmac?
The text was updated successfully, but these errors were encountered:
In the ACME RFC (https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.4) it says
Right now
from_base64_secret
does base64-standard decoding. Is this common for other protocols that use HMAC keys?I think a url-safe base64 method would be useful, since ACME users will have url-safe base64 strings from ACME providers and they'd be able to bridge that to this library without needing an extra direct dependency just to hand the key over. Url-safe base64 also aligns with a lot of the rest of the JOSE specs so I'd expect that to be common.
Sorry, this is a pretty trivial issue, but what about something like
from_urlsafe_base64_secret
orfrom_base64_hmac
?The text was updated successfully, but these errors were encountered: