On Wed, Apr 1, 2020 at 5:40 AM Alexey Melnikov <[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. > > 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= > [email protected] <[email protected]>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > > _______________________________________________ > Acme mailing [email protected]https://www.ietf.org/mailman/listinfo/acme > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
