[Acme] RFC 8823 email-reply-00: How to concatenate the tokens?

[Richard Körber <[e-mail]>]

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