[Acme] [Technical Errata Reported] RFC8555 (6950)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 02 May 2022 08:31 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
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 BDA97C159490 for <acme@ietfa.amsl.com>; Mon, 2 May 2022 01:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VyWxB4eyip5 for <acme@ietfa.amsl.com>; Mon, 2 May 2022 01:31:35 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2399C15948C for <acme@ietf.org>; Mon, 2 May 2022 01:31:34 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id BDA48E5311; Mon, 2 May 2022 01:31:34 -0700 (PDT)
To: rlb@ipv.sx, jsha@eff.org, cpu@letsencrypt.org, jdkasten@umich.edu, rdd@cert.org, kaduk@mit.edu, decoole@nsa.gov, debcooley1@gmail.com, ynir.ietf@gmail.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: lloyd.wood@yahoo.co.uk, acme@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220502083134.BDA48E5311@rfcpa.amsl.com>
Date: Mon, 02 May 2022 01:31:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/2ZNQ89QiQ5sVqyx2pkYdW5LD1Jk>
X-Mailman-Approved-At: Mon, 02 May 2022 06:39:15 -0700
Subject: [Acme] [Technical Errata Reported] RFC8555 (6950)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.34
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: Mon, 02 May 2022 08:31:38 -0000

The following errata report has been submitted for RFC8555,
"Automatic Certificate Management Environment (ACME)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6950

--------------------------------------
Type: Technical
Reported by: Lloyd Wood <lloyd.wood@yahoo.co.uk>

Section: GLOBAL

Original Text
-------------
token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy.

Corrected Text
--------------
token (required, string):  A random value that uniquely identifies
      the challenge.  This value MUST have at least 128 bits of entropy, which in the 
      base64url alphabet means a minimum string length of 22 characters if the full
      scope of the base64url alphabet is in use in the token, by:
                        log2(64^22) = 132 bits of entropy



Notes
-----
This standards-track document doesn't specify the string ramifications for entropy; I'd expect it to be called out to implementers, just the once, and then referred to later at other tokens.

If entropy is log2 the number of possible characters (64 if full base64url set of chars is in use) then 
log2 (64^21) = 126
log2 (64^22) = 132

so a minimum of 22 characters are needed to get a minimum of 128 bits of entropy in the token.

But, if the random value is specified using a subset of the base64url, say because the implementer doesn't like or use CAPITALS or (most likely) the punctuation symbols, then the token must necessarily be longer to meet the local implementer entropy requirement (though just losing only the punctuation marks means you're still good and meet the requirement with 22 characters). Not sure that matters so much on the wire.

I also have editing nits about base64url being defined clearly in ABNF just for Replay-Nonce:, but then both 'base64 alphabet' and 'base64url alphabet' are in use in the document, and base64url references are to RFC4648 via RFC7515, but those are to Base64url, not to base64url... it all seems a bit inconsistent editingwise. So all the references to 'base64 alphabet' should be to 'base64url alphabet' as defined in the doc, but it should really be 'Base64url alphabet' to be consistent with references?

(I really think that it should have been called 'Base-64_url alphabet' way back when to enphasise the punctuation use, but that ship has sailed.)

To me, 'base64 alphabet' is the a-zA-Z subset of base64... I think the document could be much clearer in this regard, and I hope any doc revisions taking into account all the other errata raised consider this too.

My thanks to Lee Maguire for pointing much of this out.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8555 (draft-ietf-acme-acme-18)
--------------------------------------
Title               : Automatic Certificate Management Environment (ACME)
Publication Date    : March 2019
Author(s)           : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
Category            : PROPOSED STANDARD
Source              : Automated Certificate Management Environment
Area                : Security
Stream              : IETF
Verifying Party     : IESG