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. >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.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
