RFC 8555 incompatible account ID handling #417

New Issue

2025-12-29T01:24:41+01:00

adam commented

2025-12-29 01:24:41 +01:00

Originally created by @cpu on GitHub (Jun 21, 2019).

Hi @lukas2511,

Recently in the Let's Encrypt staging environment we stopped sending the id field in account objects returned from the newAccount endpoint. The reason is that this field is not specified in RFC 8555. Instead Section 7.3 says:

The server returns this account object in a 201 (Created) response, with the account URL in a Location header field. The account URL is used as the "kid" value in the JWS authenticating subsequent requests by this account (see Section 6.2).

It looks like Dehydrated depended on that unspecified id field in some circumstances, and does not process the Location header. E.g. here:
https://github.com/lukas2511/dehydrated/blob/74a536c16178312845503caa5322c19de34b2dca/dehydrated#L402-L404

There was more discussion about this in https://github.com/lukas2511/dehydrated/issues/636

This has started causing issues for users with the staging environment:

As mentioned in our API Announcement this change is moving to production the week of July 3rd and will likely begin to cause more significant issues for dehydrated users.

Originally created by @cpu on GitHub (Jun 21, 2019). Hi @lukas2511, Recently in the Let's Encrypt staging environment we [stopped sending the `id` field in account objects returned from the `newAccount` endpoint](https://community.letsencrypt.org/t/acme-v2-scheduled-removal-of-id-from-account-objects/94744). The reason is that this field is **not** specified in [RFC 8555](https://tools.ietf.org/html/rfc8555). Instead [Section 7.3](https://tools.ietf.org/html/rfc8555#section-7.3) says: > The server returns this account object in a 201 (Created) response, with the account URL in a Location header field. The account URL is used as the "kid" value in the JWS authenticating subsequent requests by this account (see Section 6.2). It looks like Dehydrated depended on that unspecified `id` field in some circumstances, and does not process the `Location` header. E.g. here: https://github.com/lukas2511/dehydrated/blob/74a536c16178312845503caa5322c19de34b2dca/dehydrated#L402-L404 There was more discussion about this in https://github.com/lukas2511/dehydrated/issues/636 This has started causing issues for users with the staging environment: * https://github.com/lukas2511/dehydrated/issues/647 * https://github.com/lukas2511/dehydrated/issues/650 As mentioned in our API Announcement this change is moving to production the week of July 3rd and will likely begin to cause more significant issues for `dehydrated` users.

adam closed this issue

2025-12-29 01:24:41 +01:00

adam commented

2025-12-29 01:24:43 +01:00

@lukas2511 commented on GitHub (Jun 25, 2019):

@cpu just to clarify: the id field will remain in the account information that can be retrieved afterwards, it's just removed from the initial registration, correct?

@lukas2511 commented on GitHub (Jun 25, 2019): @cpu just to clarify: the id field will remain in the account information that can be retrieved afterwards, it's just removed from the initial registration, correct?

adam commented

2025-12-29 01:24:43 +01:00

@cpu commented on GitHub (Jun 25, 2019):

Thanks for fixing this 👍

@cpu just to clarify: the id field will remain in the account information that can be retrieved afterwards, it's just removed from the initial registration, correct?

That's the way it's implemented presently but I think that was an oversight. It should have been removed throughout. The id field isn't specified anywhere in RFC 8555 and it shouldn't be relied on. If you're retrieving an account's information in the standard way you're POSTing its URL and so already know the ID, there isn't any value in having that non-standard field in the response since its already known.

@cpu commented on GitHub (Jun 25, 2019): Thanks for fixing this :+1: > @cpu just to clarify: the id field will remain in the account information that can be retrieved afterwards, it's just removed from the initial registration, correct? That's the way it's implemented presently but I think that was an oversight. It should have been removed throughout. The `id` field isn't specified anywhere in RFC 8555 and it shouldn't be relied on. If you're retrieving an account's information in the standard way you're POSTing its URL and so already know the ID, there isn't any value in having that non-standard field in the response since its already known.

adam commented

2025-12-29 01:24:44 +01:00

@lukas2511 commented on GitHub (Jun 25, 2019):

@cpu mh well okay, i guess then it needs a second "fix" to actually store the information from the location header. kinda dislike to do that, but well, if it's in the rfc it's in the rfc.

@lukas2511 commented on GitHub (Jun 25, 2019): @cpu mh well okay, i guess then it needs a second "fix" to actually store the information from the location header. kinda dislike to do that, but well, if it's in the rfc it's in the rfc.

adam commented

2025-12-29 01:24:44 +01:00

@cpu commented on GitHub (Jun 25, 2019):

That's the way it's implemented presently but I think that was an oversight. It should have been removed throughout.

Fixed in https://github.com/letsencrypt/boulder/commit/7f01d1274ec0f1ff71310e0960c351b506f1bd3f

kinda dislike to do that, but well, if it's in the rfc it's in the rfc.

@lukas2511 I have my own gripes with parts of the RFC but that's the cost of inter-operability :-) This change will definitely help dehydrated be usable with more CAs. Thanks for making the additional fix.

@cpu commented on GitHub (Jun 25, 2019): > That's the way it's implemented presently but I think that was an oversight. It should have been removed throughout. Fixed in https://github.com/letsencrypt/boulder/commit/7f01d1274ec0f1ff71310e0960c351b506f1bd3f > kinda dislike to do that, but well, if it's in the rfc it's in the rfc. @lukas2511 I have my own gripes with parts of the RFC but that's the cost of inter-operability :-) This change will definitely help dehydrated be usable with more CAs. Thanks for making the additional fix.

adam commented

2025-12-29 01:24:45 +01:00