Hi,
On 04/05/2020 18:48, Ben Schwartz wrote:
On Sun, May 3, 2020 at 1:36 AM Ryan Sleevi <[email protected]
<mailto:[email protected]>> wrote:
On Sat, May 2, 2020 at 2:11 PM Ben Schwartz
<[email protected]
<mailto:[email protected]>> wrote:
On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov
<[email protected] <mailto:[email protected]>>
wrote:
Hi Ben,
On 21/04/2020 01:12, Ben Schwartz wrote:
On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov
<[email protected]
<mailto:[email protected]>> wrote:
Hi Ben,
My apologies for missing your email in March:
And mine for this delayed response.
On 12/03/2020 20:42, Ben Schwartz wrote:
Section 3 says token-part1 "contains at least 64 bit
of entropy", but Section 3.1 says token-part1 "MUST
be at least 64 octet long after decoding". Is this
difference deliberate?
No, I obviously made a typo when saying octets. I
will fix.
Fixed.
Also 64 octets of entropy is a _lot_. RFC 8555 says
"the token is required to contain at least 128 bits
of entropy".
The draft seems to be oriented entirely toward use
with e-mail clients that have a built-in ACME-S/MIME
client. I'm a bit disappointed that the draft
doesn't accommodate users with "naive" email clients
very well, e.g. by allowing customized subject lines.
Actually, I was trying to accommodate naive email
clients, but it was a fine balance trying to specify
minimal requirements.
Can you suggest some specific text to change and then
we can discuss whether or not it should be done? My
thinking about the Subject header field was that I
wanted to have a unique subject (so that ACME email
messages are easily findable). I also wanted to allow
the token in the subject for APIs that can easily
access Subject and not other header fields.
In that case, I would suggest "... subject ending with
"(ACME: <token-part1>)", where ...". That would allow the
first part of the subject (most likely to be seen by a
human) to be human-readable.
After thinking a bit more about this:
As ACME servers are generating ACME challenge emails, the
requirement on them is stricter (they create the first
message in an email thread). I am tempted to leave this as
is. Can you think of a case where ACME servers would be
unable to comply with this restriction?
My concern is that users will not know what to do if they
receive an email whose subject line is "ACME:
awlkNSdpijawrfz...". Users are used to seeing emails whose
subject line is "Please verify your email address" or "Confirm
your email". (My inbox is full of them.) I see no reason to
disallow that here.
Mandating that the subject line be non-human-readable seems
like an unnecessary barrier to adoption.
Are you expecting humans to be the primary interaction point?
Ideally, ACME-aware mail clients will handle these messages in some
beautiful, mostly-invisible way, but mail clients don't update as fast
as browsers. Even many years after most users have ACME-aware
clients, I think a sizable fraction will have non-aware clients.
Right.
It almost seems that ensuring human unfriendliness is a feature,
not a bug, towards the goal of automation.
That was my expectation after reading draft-06, but Alexey explained
that human-friendliness was in-scope, hence my suggestions.
Obviously human-friendliness for non ACME aware email clients and ease
of implementation in ACME aware email clients are in conflict. I would
be happy to use some compromise if a good balance can be found.
This structure seems especially important if it has a chance to be
adopted by publicly trusted CAs. One of the big concerns with
existing validation approaches is bodies that are rich-text with
links used for approval, and for which anti-spam or scanning
engines inspect (“click”) and cause improper authorizations.
According to this draft, authorization requires sending a specially
formed reply email, so I think the risk of a scanning engine
accidentally authorizing is low.
The more structure, the better, towards preventing accidental
authorizations.
Best Regards,
Alexey
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
