Hi!
I have a question regarding RFC 8823 and the calculation of the ACME
response. The RFC says:
"[...] followed by [...] the key authorization, calculated from
concatenated token-part1 (received over email) and token-part2 (received
over HTTPS) [...]"
The RFC also gives two example tokens:
token-part1 = "LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME="
token-part2 = "DGyRejmCefe7v4NfDGDKfA"
There are now two ways to concatenate them.
The simple way would be a plain string concatenation, giving:
LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=DGyRejmCefe7v4NfDGDKfA
As token-part1 has a trailing padding character '=', the concatenation
has a padding character within the string. This is not a valid base64url
encoded value according to RFC 4648, but since the token does not need
to be decoded for the key authorization computation, it would be
technically possible to use it like that.
The clean way would be to base64url-decode both parts first, concatenate
the decoded byte arrays, and then base64url-encode the concatenated
array. This would give an entirely different result though:
LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sMEMbJF6OYJ597u_g18MYMp8
Since both ways are giving different results, only one of them can be
the correct one. :)
Question 1: Which concatenation is meant to be used in RFC 8823?
Question 2: Should the RFC 8823 explicitly specify how the concatenation
should be done?
Thank you for your help!
Best,
Richard Körber
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
