From nobody Mon Aug 16 08:56:00 2021 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE413A0C25 for ; Mon, 16 Aug 2021 08:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2ECk-6lV19y for ; Mon, 16 Aug 2021 08:55:43 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 31A223A0C1A for ; Mon, 16 Aug 2021 08:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1629129340; d=isode.com; s=june2016; i=@isode.com; bh=0F2wIgi5FYtzp+PFFs/IjegFdIwPeVgVM8dRdd0Z3zM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RD3Ngg1iaun4KkPIblbG2Ax1RksQSoaXNTS7t1KNxGIVXTNdHCofZONLXqMhKeAQjBmyNL WnNzQ01TeQ5SBmDsqnN2jFeJIhoIFV4GKSoEwCrjUMRlE6797ajQsI6TzCOW4/HtqTp7qK 6P+NTH7mxj7TGNEkm+XwpakBUWo6kL4=; Received: from [192.168.1.222] (host31-49-142-56.range31-49.btcentralplus.com [31.49.142.56]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Aug 2021 16:55:40 +0100 To: Brian Sipos , "acme@ietf.org" References: From: Alexey Melnikov Message-ID: Date: Mon, 16 Aug 2021 16:55:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D3379D68CC2BE8343499143B" Content-Language: en-GB Archived-At: Subject: Re: [Acme] RFC 8823 email-reply-00: How to concatenate the tokens? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 15:55:58 -0000 --------------D3379D68CC2BE8343499143B Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Hi all, On 07/06/2021 03:39, Brian Sipos wrote: > Richard, > >From my interpretation, the fact that the two token parts are=20 > base64url strings is immaterial to the text-string concatenation into=20 > the ACME "token" value. The Key Authorization calculation of RFC 8555=20 > also does not care where the token text came from or whether it is a=20 > base64url encoded text string. > > Also be careful about your assumptions about the tokens themselves.=20 > While RFC 8555 makes requirements about base64url encoded token=20 > values, RFC 8823 does not make any requirements about the content of=20 > the "token-part2" text value. The fact that the example looks like=20 > base64url encoding implies that, but I don't see any requirement on=20 > the=A0token-part2 generation other than its minimum entropy. An RFC 8823= =20 > implementation could just as well use random ASCII, Latin-1, base16,=20 > or any other text; base64 just happens to produce more entropy-dense text. I can confirm that my intent was to suggest straight string=20 concatenation without any base64url-decode and re-encoding. Use of trailing "=3D" in the example token-part1=20 ("LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=3D") is unfortunate. I=20 should have used the same restriction on token-part1 as specified on=20 token in RFC 8555: no trailing "=3D". > >From my reading, the RFC 8823 requirement text is sufficient to=20 > explain this but having an example of the pre-digest Key Authorization=20 > value would be helpful to clarify this. The example currently includes=20 > only the Key Authorization digest but not the intermediate=20 > concatenated value. Best Regards, Alexey --------------D3379D68CC2BE8343499143B Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

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=A0RFC 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=A0token-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 "=3D" in the example token-part1 ("LgYemJLy3F1LDkiJrdIGbEzyFJyOyf6vBdyZ1TG3sME=3D") is unfortunate. I should have used the same restriction on token-part1 as specified on token in RFC 8555: no trailing "=3D".
>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

--------------D3379D68CC2BE8343499143B--