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 tok
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.
Yes, I was misguided by the example. This is a strong argument
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 en
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.
RFC 8555 Section 8.1 says:
A key authorization is a string that
concatenates the token for the challenge with a key fingerprint,
separ
the result (as a byte array) to do the key-authorization calculation.
-Ursprungligt meddelande-
Från: acme-boun...@ietf.org För Richard Körber
Skickat: den 5 juni 2021 16:16
Till: acme@ietf.org
Ämne: [Acme] RFC 8823 email-reply-00: How to concatenate the tokens?
Hi!
I have a question reg
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
