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

[Alexey Melnikov <[e-mail]>]

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