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

[Deb Cooley <[e-mail]>]

 My question to you would be:  which RFC will make the most impact?  Seems
like your comments weren't really targeted at ACME per se, but at how to
measure entropy using Base64 encoding?  I have not read RFC 4086 closely,
but an RFC like that would impact all of them.

Just my thoughts...
Deb Cooley

On Fri, Jan 5, 2024 at 7:43 AM <[e-mail]> wrote:

> Thanks for that.
>
> Well, I stand by my detailed comments of (checks dates) two years ago.
> Which I had forgotten I ever even made!
>
> I know, covid and all, but lately in the past few years I’ve
> been sensing a vibe of why-even-bother-submitting errata anyway. (and
> sitting in a Tokyo airport transit lounge, heavily jetlagged, is really not
> the place for me to do any detailed analysis.)
>
> Perhaps reframing it as some security concern, since entropy, might prompt
> wider review? security types are quite keen on this stuff, and do tend to
> like rigour in specifications to close off implementation misunderstandings
> loopholes.
>
> best
>
> Lloyd Wood
> [e-mail]
>
> On Friday, January 5, 2024, 21:14, Deb Cooley <[e-mail]>
> wrote:
>
> I did some reading, some consulting, and some pondering.  I want to reject
> this errata.
>
> 1.  The original paragraph:
>
> token (required, string):  A random value that uniquely identifies
>       the challenge.  This value MUST have at least 128 bits of entropy.
>       It MUST NOT contain any characters outside the base64url alphabet
>       and MUST NOT include base64 padding characters ("=").  See
>       [RFC4086] for additional information on randomness requirements.
>
> In my opinion this is sufficient.  It specifies how much entropy (w/ a ref), and specifies what cannot be included (padding, non-base54 characters).
>
> Let me know if you have other thoughts.
>
> Deb
>
>
> On Thu, Jan 4, 2024 at 7:41 AM Deb Cooley <[e-mail]> wrote:
>
> 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
>
>