Incompliant JWK Thumbprints with leading zeroes #145

New Issue

adam · 2025-12-29T00:25:50+01:00

adam commented

2025-12-29 00:25:50 +01:00

Originally created by @cpu on GitHub (Sep 14, 2016).

Hi there!

It seems that dehydrated is generating JWA JWK thumbprints that don't match the specification. This came to my attention as part of this Let's Encrypt community forum thread.

Section 2 of RFC 7518 defines Base64urlUInt as:

      The representation of a positive or zero integer value as the
      base64url encoding of the value's unsigned big-endian
      representation as an octet sequence.  The octet sequence MUST
      utilize the minimum number of octets needed to represent the
      value.  Zero is represented as BASE64URL(single zero-valued
      octet), which is "AA".

Further, Section 6.3 indicates that all of the RSA key parameters are expressed as Base64urlUInt.

It's not immediately obvious but the portion of the Base64urlUInt description that mandates that the sequence use the minimum number of octets means that leading zero's should be removed. You can see how Go-Jose implements this as one example of a complaint implementation.

It doesn't look to me that dehydrated strips leading zeroes presently to match the specification. I believe this might be the root cause of Issue #268 and is likely to cause further problems down the road for users that hit this corner case.

Unfortunately I don't work with bash or dehydrated enough to propose a patch, but hopefully it won't be difficult to address! Let me know if I can provide any other information.

Originally created by @cpu on GitHub (Sep 14, 2016). Hi there! It seems that `dehydrated` is generating JWA JWK thumbprints that don't match the specification. This came to my attention as part of this [Let's Encrypt community forum thread](https://community.letsencrypt.org/t/trouble-with-keyauthorization-for-dns-provided-key-authorization-was-incorrect-solved/19799). [Section 2 of RFC 7518](https://tools.ietf.org/html/rfc7518#section-2) defines `Base64urlUInt` as: ``` The representation of a positive or zero integer value as the base64url encoding of the value's unsigned big-endian representation as an octet sequence. The octet sequence MUST utilize the minimum number of octets needed to represent the value. Zero is represented as BASE64URL(single zero-valued octet), which is "AA". ``` Further, [Section 6.3](https://tools.ietf.org/html/rfc7518#section-6.3) indicates that all of the RSA key parameters are expressed as `Base64urlUInt`. It's not immediately obvious but the portion of the `Base64urlUInt` description that mandates that the sequence use the **minimum number of octets** means that leading zero's should be removed. You can see how [Go-Jose implements this](https://github.com/square/go-jose/blob/master/encoding.go#L144:L148) as one example of a complaint implementation. It [doesn't look to me](https://github.com/lukas2511/dehydrated/blob/master/dehydrated#L245) that dehydrated strips leading zeroes presently to match the specification. I believe this might be the root cause of Issue #268 and is likely to cause further problems down the road for users that hit this corner case. Unfortunately I don't work with bash or `dehydrated` enough to propose a patch, but hopefully it won't be difficult to address! Let me know if I can provide any other information.

adam closed this issue

2025-12-29 00:25:50 +01:00

adam commented

2025-12-29 00:25:52 +01:00

@lukas2511 commented on GitHub (Sep 17, 2016):

@cpu hey, can you check if that commit fixed the problem?

@lukas2511 commented on GitHub (Sep 17, 2016): @cpu hey, can you check if that commit fixed the problem?

adam commented

2025-12-29 00:25:52 +01:00

@cpu commented on GitHub (Sep 17, 2016):

@lukas2511 I'm afraid I'm not a user of dehydrated and don't have a reproduction case. Apologies.

@cpu commented on GitHub (Sep 17, 2016): @lukas2511 I'm afraid I'm not a user of dehydrated and don't have a reproduction case. Apologies.

adam commented

2025-12-29 00:25:53 +01:00

@lukas2511 commented on GitHub (Sep 21, 2016):

Commit was reverted in a316a094df because of problems with freebsd, reopening this ticket for now

@lukas2511 commented on GitHub (Sep 21, 2016): Commit was reverted in a316a094df8d3d4b25673cfbb1197f646781e48f because of problems with freebsd, reopening this ticket for now

adam commented

2025-12-29 00:25:53 +01:00

@lukas2511 commented on GitHub (Jan 30, 2017):

I wasn't ever able to reproduce any issues with this myself and it seems to be working fine... I'll close this issue until I have a reliable way of testing this. For the (seemingly very rare) case of people having this problem I'd suggest just trying to delete the key in question (or better: send it to me for testing! – of course only if there isn't anything validated with that yet) and let the script generate a new one.

@lukas2511 commented on GitHub (Jan 30, 2017): I wasn't ever able to reproduce any issues with this myself and it seems to be working fine... I'll close this issue until I have a reliable way of testing this. For the (seemingly very rare) case of people having this problem I'd suggest just trying to delete the key in question (or better: send it to me for testing! – of course only if there isn't anything validated with that yet) and let the script generate a new one.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#145