Since it says the "calculated key-authorization", which assumes you have to use the decoded tokens, I think you should neither concatenate the tokens as-is, nor re-encode the tokens after concatenation.
Rather, you should decode both token-parts, then concatenate the result, and use the result (as a byte array) to do the key-authorization calculation. -----Ursprungligt meddelande----- Från: [email protected] <[email protected]> För Richard Körber Skickat: den 5 juni 2021 16:16 Till: [email protected] Ämne: [Acme] RFC 8823 email-reply-00: How to concatenate the tokens? 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
