mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-03-03 14:40:00 +01:00
account 'id' #403
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kuehne-trustable-de on GitHub (Apr 1, 2019).
While testing my OS Java ACME server impl I came across the topic of expected 'id' element in the account response. As far as I can see there is nothing like this included in the spec.
My proposal would be to the URL from the location header. This avoids any assumptions regarding the implementation ...
Nevertheless:
You did a great Job!
Greetings,
Andreas
@lukas2511 commented on GitHub (Apr 1, 2019):
I'm not entirely sure what you mean... Dehydrated behaves (at least mostly) RFC8555-conform, so if you want to write a new server-software you should implement it following RFC8555, there are no assumptions in implementation on client- or server-side.
@kuehne-trustable-de commented on GitHub (Apr 1, 2019):
Hi Lukas,
if I understand your software correctly it takes advantage of an element
'id' in the account data structure
line 404:
ACCOUNT_ID="$(cat "${ACCOUNT_KEY_JSON}" | get_json_int_value id)"
But as far as I can see there is NO element 'id' defined in the spec
(Snippet from RFC8555):
{
"status": "valid",
"contact": [
"mailto:cert-admin@example.org",
"mailto:admin@example.org"
],
"termsOfServiceAgreed": true,
"orders": "https://example.com/acme/orders/rzGoeA"
}
Moreover I would consider it at least dangerous to make assumption about
the server's URL structure:
line 408:
ACCOUNT_URL="${CA_ACCOUNT}/${ACCOUNT_ID}"
This will be a valid in many implementations but it is NOT backed by the
spec!
BTW::
I'm testing my stuff with your client because colleagues recommended it
as 'great stuff' and want to be sure everything's woks out fine, not to
spot some minor spec deviations ;-)
Greetings,
Andreas
--
Andreas Kühne
Chair of OASIS DSS-X
phone: +49 177 293 24 97
mailto: kuehne@trustable.de
Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
Director Andreas Kühne
Company UK Company No: 5218868 Registered in England and Wales
@lukas2511 commented on GitHub (Apr 1, 2019):
I think you are correct, this seems to be something dehydrated doesn't do correctly. I'll fix this in the next few days.
@cpu commented on GitHub (Apr 1, 2019):
Thanks for opening this issue @kuehne-trustable-de.
I realized Pebble carried over this "Boulder-ism". I have a PR up to remove it: https://github.com/letsencrypt/pebble/pull/225 @lukas2511 Perhaps it will help you test your fix.
I'd like to remove the
IDfield from Boulder's "ACME v2" Account resource responses but it will be a little trickier to implement and will need to follow a full API announcement with enough fore-warning for developers/users. I'm tracking that in https://github.com/letsencrypt/boulder/issues/4136 but it will probably be some time before it can be prioritized.@lukas2511 commented on GitHub (Oct 4, 2019):
This has been fixed by now. Thanks for reporting.