Hi all,
On 07/06/2021 03:39, Brian Sipos wrote:
Richard,
>From my interpretation, the fact that the two token parts are
base64url strings is immaterial to the text-string concatenation into
the ACME "token" value. The Key Authorization calculation of RFC 8555
also does not care where the token text came from or whether it is a
base64url encoded text string.
Also be careful about your assumptions about the tokens themselves.
While RFC 8555 makes requirements about base64url encoded token
values, RFC 8823 does not make any requirements about the content of
the "token-part2" text value. The fact that the example looks like
base64url encoding implies that, but I don't see any requirement on
the token-part2 generation other than its minimum entropy. An RFC 8823
implementation could just as well use random ASCII, Latin-1, base16,
or any other text; base64 just happens to produce more entropy-dense text.
I can confirm that my intent was to suggest straight string
concatenation without any base64url-decode and re-encoding.
Use of trailing "=" in the example token-part1
("LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=") is unfortunate. I
should have used the same restriction on token-part1 as specified on
token in RFC 8555: no trailing "=".
>From my reading, the RFC 8823 requirement text is sufficient to
explain this but having an example of the pre-digest Key Authorization
value would be helpful to clarify this. The example currently includes
only the Key Authorization digest but not the intermediate
concatenated value.
Best Regards,
Alexey
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
