Re: [Acme] WG last call for draft-ietf-acme-email-smime-06

[Ben Schwartz <[e-mail]>]

On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov <[e-mail]>
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.
>
> 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.

Similarly, for Section 3.2. Point 6, I would relax the requirement to state
that this block must appear somewhere in the body.  That way, if the user
sees the response message, it can provide some explanation of what is going
on.

For Section 3.1 Point 5, I don't understand why the body is restricted to
text/plain.  In particular, I think hyperlinks to explanations and
instructions are likely to be helpful.  I also wonder whether support for
multipart/multilingual could be useful.  The body is irrelevant to
ACME-aware clients, so it seems like there could be a lot of freedom in how
this is constructed.

Most email clients automatically convert HTTPS URLs to hyperlinks, which
should make the silly schemes I'm imagining possible, but not very
attractive, for ordinary users.

> Best Regards,
>
> Alexey
>
> I assume this is deliberate, perhaps because of a desire to use short-TTL
> S/MIME certificates that would be impractical to provision manually, but
> the draft doesn't mention a rationale.
>
> On Thu, Mar 12, 2020 at 2:52 PM Salz, Rich <rsalz=
> [e-mail] <40akamai.com@dmarc..ietf.org>> wrote:
>
>> This mail begins a one-week working group last call on
>> https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1
>>
>>
>>
>> If you have comments or issues, please post here.
>>
>>
>>
>> If anyone wants to be a document shepherd, please contact the chairs.
>>
>>
>>
>>                 /r$
>>
>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
> _______________________________________________
> Acme mailing [e-mail]://www.ietf.org/mailman/listinfo/acme
>
>