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
