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

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Mar 2020 18:51:36 +0000

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$

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 12 Mar 2020 16:42:02 -0400

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?  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.  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-masked]> 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
>
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Mar 2020 13:39:38 +0000

Last chance for comments, slightly extended deadline because of the pandemic.

Please review.  You don’t want to be stuck with custom solutions or having to use PGP, right?

-rich.  No, the distancing isn’t getting to me, why do you ask? :)

From: Rich Salz <[email-masked]>
Date: Thursday, March 12, 2020 at 2:51 PM
To: "[email-masked]" <[email-masked]>
Subject: WG last call for draft-ietf-acme-email-smime-06

                /r$

---

From: "A. Schulze" <[email-masked]>
Date: Wed, 1 Apr 2020 00:24:16 +0200

> This mail begins a one-week working group last call on https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/?include_text=1
(hopefully not to late ...)

Hello @all,

I became aware of a privacy problem once an ACME instance will implement this draft: CT logs.
Usually the space of local parts for a domains email addresses is private. Enumeration is impossible and unwanted.
But CT logs change some assumptions people may have...

On the other side the problem isn't really new.
Similar applies to the hosts available inside a domain.
Similar applies to DNSSEC signed domains. But at least there is an option to make a zone-walk harder: NSEC3

Is this at least a point to be mentioned in the drafts security section?

Andreas

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 31 Mar 2020 18:35:53 -0400

> But CT logs change some assumptions people may have...

Aren’t those concerns founded on certain assumptions that may not be
entirely accurate?
- That an ACME server (CA) implementing this is using the same trust
hierarchy that they use for TLS?
  - This is forbidden by most major client software (to issue both from the
same hierarchy)
- That the CT logs intended for one protocol (e.g. TLS) accept certificates
for other protocols
  - This is a bug in the current TLS CT logs being fixed (to properly
exclude non-TLS certificates)

Either, or both, of these issues mitigate the concern. However, it doesn’t
seem this concern is related to the protocol, nor would this draft change
anything (and was discussed heavily in TRANS)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Apr 2020 00:04:51 +0000

“A” thank you for posting; Ryan thank you for responding.

The draft has already been sent to the IESG, and if you are concerned about this, I think the most effective thing will be to bring it up during the IETF last call or perhaps contact IESG.

I hope that Ryan’s response lessons your concerns, but if not, that’s probably the best way forward.