Hi,
i can not see any reason for changing the text. At least 128 bit entropy
is clear defined.
For example
byte[16] buf;
fillrandom(buf)
token = base64encode(buf)
I would se more importance to define the upper Limit. Because missing
checks for upper limit of the string
can cause more harm via buffer overflow than few bits less entropy
because someone is not using the full alphabet.
You can also not control that not base64encode(ISO-Date-String) is done.
Gruß Thomas
On 05.01.2024 13:48, Deb Cooley wrote:
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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
