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 <[email protected]> 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 > [email protected] > > On Friday, January 5, 2024, 21:14, Deb Cooley <[email protected]> > 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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> > > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
