Hi,
On 03/05/2020 06:36, Ryan Sleevi wrote:
On Sat, May 2, 2020 at 2:11 PM Ben Schwartz
<bemasc=40google....@dmarc.ietf.org
<mailto:40google....@dmarc.ietf.org>> wrote:
On Sat, May 2, 2020 at 8:35 AM Alexey Melnikov
<alexey.melni...@isode.com <mailto:alexey.melni...@isode.com>> wrote:
Hi Ben,
On 21/04/2020 01:12, Ben Schwartz wrote:
On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov
<alexey.melni...@isode.com
<mailto:alexey.melni...@isode.com>> 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? It
almost seems that ensuring human unfriendliness is a feature, not a
bug, towards the goal of automation.
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. The more structure, the
better, towards preventing accidental authorizations.
Let me try to elaborate on the current choice and talk about
alternatives. In general there are 3 ways how an ACME email challenge be
conveyed in email:
1) In the subject line. Some structure would be helpful for automated
software.
2) In a new header field.
3) In the body of the message, e.g. using "---BEGIN ACME CHALLENGE---"
line in text/plain or the like.
Unfortunately all of these have their downsides:
#1 is unfriendly to users and can possibly trigger antispam processing.
(Not sure how much of an issue the last part is)
#2 might not be accessible from libraries that don't support retrieval
of arbitrary email header fields. (I am not sure how big of a deal this
is, but I've heard some claims about that.) Also, non ACME aware clients
might not be able to show this header field, making them unusable for
manual processing.
#3 would either require use of text/plain (for simplicity of automated
processing) or it would require HTML parser with downconversion to
text/plain. I think the latter choice is a rather high barrier of entry
for implementations that are not fully capable email clients, which I
suspect would be too hight for some ACME servers.
So I am open to suggestions about the best choice. I think using some
structured subject line (choice #1) or possibly text/plain choice #3 are
the best. If there is a better structure for the subject header field, I
would be happy to change the document.
Best Regards,
Alexey
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
