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

[Deb Cooley <[e-mail]>]

opinions?  Does entropy have to be measured as a base64 encoded value?

Deb

On Mon, May 2, 2022 at 4:31 AM RFC Errata System <[e-mail]>
wrote:

> 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 <[e-mail]>
>
> 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
>