IETF Logo Mail Archive

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

Sebastian <sebastian@sebbe.eu> Sat, 05 June 2021 14:20 UTC

Return-Path: <sebastian@sebbe.eu>
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 CB4743A24A7 for <acme@ietfa.amsl.com>; Sat, 5 Jun 2021 07:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=sebbe.eu
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 oiGHubxqOKT1 for <acme@ietfa.amsl.com>; Sat, 5 Jun 2021 07:20:02 -0700 (PDT)
Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467B73A24A5 for <acme@ietf.org>; Sat, 5 Jun 2021 07:20:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Date:To:From:cc; bh=Qgo0mZDndhKlT23boUrweg0E6943vrVj6jKZ/uJ+1+c=; b=xLJiPE+kjm8IffootEOnHYIF4ODd+mORN8FKF2Tm+wXqO3AuRiVXQa+rbekgMuF2nXYRr1Zjy9 7epXKPyeUoqS7Iha2ZGo1qyJBeBHUK1T8xTrLTutaz0ownaXYsJO1luhy/hBGnSaCAT8VSJSCcc4U d6/3c9s2TqfOma5qEU5s=;
Received: from localhost ([127.0.0.1] helo=sebastian-desktop) by sebbe.eu with esmtp (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1lpX9a-002n98-6C for acme@ietf.org; Sat, 05 Jun 2021 16:19:58 +0200
Received: from [192.168.4.100] (helo=DESKTOPH7H9A35) by sebbe.eu with esmtpa (Exim 4_94_RC0-31-83e8da8c0-XX) (envelope-from <sebastian@sebbe.eu>) id 1lpX9Z-002n95-Pq for acme@ietf.org; Sat, 05 Jun 2021 16:19:57 +0200
From: Sebastian <sebastian@sebbe.eu>
To: 'Mailing List' <acme@ietf.org>
Message-ID: <003801d75a15$dae60640$90b212c0$@sebbe.eu>
In-Reply-To: <a7b2cdea-53a0-2cd9-f07a-07f069d792a5@i7o.de>
References: <a7b2cdea-53a0-2cd9-f07a-07f069d792a5@i7o.de>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_2429_1495960860.1622902798154"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKL2dz94fevRMK5mqPwF1XtEFPpIamcd4xw
X-Encryption-Target: external
Date: Sat, 05 Jun 2021 16:19:58 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/RjdHo2VTJGWg8ZoXn_8jP_IvYsI>
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 <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Jun 2021 14:20:08 -0000

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: acme-bounces@ietf.org <acme-bounces@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 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
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

v2.23.0 | Report a Bug | By Email