Re: [lamps] [EXTERNAL] Re: CAA processing for email addresses

I support adoption of this draft.

The use of DNS for email is broken as far as serving individuals goes and
that isn't something S/MIME can fix. If your email address is
alice@example.com and you don't own example.com, you don't have control of
that email unless you control example.com.

This is not what we want for the case where example.com is a mail service
provider offering public mail service. But that is the architecture of SMTP
which was built on the assumption that institutions connected to the
Internet, not individuals. Trying to change that architecture post facto is
not going to work.

So the best approach for S/MIME is to make it work for institutions. Which
means the owner of example.com can decide whether to issue S/MIME certs or
not. That will mean that a public service mail provider can prevent
customers getting S/MIME certs but that really isn't their biggest problem
as the service provider can shut them down completely.

Email users of such a service provider can still make use of other PKIs to
validate their keys. I might have issues trying to use CAA records with
OpenPGP for that reason.

The only thing I would add is that I think the current approach to S/MIME
cert issue is broken as a business model and if people want S/MIME to
really succeed, the way to make it work is make it align with the WebPKI
model where organizations buy one cert rather than one cert per email user.

So I would like to see any CAA mechanism for S/MIME to distinguish between
delegating the ability to issue end entity certs and cert signing certs.

On Thu, Dec 1, 2022 at 10:25 AM Mike Ounsworth <Mike.Ounsworth=
40entrust.com@dmarc.ietf.org> wrote:

> Thanks for the explanations Corey.
>
>
>
> I support adoption of this draft.
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Corey Bonnell <Corey.Bonnell=40digicert.com@dmarc.ietf.org>
> *Sent:* December 1, 2022 8:26 AM
> *To:* Mike Ounsworth <Mike.Ounsworth@entrust.com>; Stephen Farrell <
> stephen.farrell@cs.tcd.ie>; Corey Bonnell <Corey.Bonnell@digicert.com>;
> spasm@ietf.org
> *Subject:* RE: [lamps] [EXTERNAL] Re: CAA processing for email addresses
>
>
>
> Hi Stephen and Mike,
>
> Thank you for your feedback thus far. I’ll address a few questions that
> were raised inline.
>
>
>
>    - > The gmails and yahoos don't do S/MIME right?, so are probably out
>    of
>    - > scope here.
>    -
>    - Well, no. Not if this proposes restricting what they can
>    subsequently do I'd say. Same for alumni and vanity mail providers too and
>    probably others of the many and varied email corner cases perhaps.
>
>
>
> I think Mike already addressed this, but if there are no “issuemail”
> properties in the Relevant RRSet, then there are no restrictions on which
> CA can issue certificates for the domain. Mail providers will not see any
> impact of CAs processing the “issuemail” tag unless they have explicitly
> added those records to the zone.
>
>
>
>
>
>    - @Corey Bonnell can you expand on why CA/B wants a CAA `issuemail`
>    separate from the CAA `issue`?
>
>
>
> I don’t speak for all of CA/B, but previous discussion in the SMIME WG and
> MDSP threads that I originally referenced showed that there was rough
> consensus that the existing “issue” and “issuewild” property tags are
> relevant solely to the issuance of server authentication certs and do not
> apply to S/MIME or other certificate types. There are two reasons for this:
>
>
>
>    1. Assuming that “issue” and “issuewild” restrict both serverauth and
>    S/MIME issuance, there is no way for a domain administrator to express
>    different restrictions for these two certificate types. In the mailbox
>    provider case that Stephen raised, that means it would not be possible for
>    a mailbox provider to restrict issuance of TLS certs for the domain while
>    allowing mailbox users to obtain SMIME certs from any CA. Having separate
>    property tags allows administrators to express the restrictions at a
>    granular level that more closely mirrors their arrangements with various
>    CAs for the issuance of various certificate types for that domain.
>    2. Existing deployments in the wild assume that “issue” and
>    “issuewild” tags restrict TLS server cert issuance only. It would be quite
>    surprising if one day those tags are also used to restrict S/MIME cert
>    issuance. If anything, the sudden change in semantics would likely slow
>    adoption of CAA entirely as it will be viewed as a footgun that randomly
>    breaks things whenever the CA processing of existing CAA records changes.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Spasm <spasm-bounces@ietf.org> *On Behalf Of *Mike Ounsworth
> *Sent:* Wednesday, November 30, 2022 10:29 PM
> *To:* Stephen Farrell <stephen.farrell@cs.tcd.ie>; Corey Bonnell <
> Corey.Bonnell=40digicert.com@dmarc.ietf.org>; Seo Suchan <
> tjtncks@gmail.com>; spasm@ietf.org
> *Subject:* Re: [lamps] [EXTERNAL] Re: CAA processing for email addresses
>
>
>
> Hi Stephen,
>
>
>
> We should really hear from the author and/or CA/B F on the driver for
> this, but ...
>
>
>
> If you're running a gmail, vanity, alumni, whatever, email server and want
> to allow people to get their own S/MIME cert, then don't specify a
> issuemail CAA RR?
>
>
>
> I'm not the world's biggest CAA expert, but I imagine the analogous issue
> exist if you run a web hosting service and want to allow people to
> subdomain and bring their own cert .. then don't specify a CAA
>
>
>
> ---
>
> Mike Ounsworth
>
>
> ------------------------------
>
> *From:* Stephen Farrell <stephen.farrell@cs.tcd.ie>
> *Sent:* Wednesday, November 30, 2022, 6:51 PM
> *To:* Mike Ounsworth <Mike.Ounsworth@entrust.com>; Corey Bonnell <
> Corey.Bonnell=40digicert.com@dmarc.ietf.org>; Seo Suchan <
> tjtncks@gmail.com>; spasm@ietf.org <spasm@ietf.org>
> *Subject:* Re: [EXTERNAL] Re: [lamps] CAA processing for email addresses
>
>
>
> Hiya,
>
> On 30/11/2022 23:43, Mike Ounsworth wrote:
> > The gmails and yahoos don't do S/MIME right?, so are probably out of
> > scope here.
>
> Well, no. Not if this proposes restricting what they can
> subsequently do I'd say. Same for alumni and vanity mail
> providers too and probably others of the many and varied
> email corner cases perhaps.
>
> Let's not forget the bad side effects of dmarc "p=reject"
> which is also a well-intentioned and partly effective thing
> aimed at only a subset of email deployments, but that has
> affected many others.
>
> > It's probably the @<gov-dept>.gov's or
> > @<massivecorp>.com's who have robust enough S/MIME deployments to
> > care about restricting which PKI can issue for them.
> Even if so, (and it seems a reasonable guess), I don't
> know to what extent such email deployments have seen
> issues with certificate mis-issuance, which IIUC is the
> main reason for any CAA RR.
>
> Cheers,
> S.
>
> *Any email and files/attachments transmitted with it are confidential and
> are intended solely for the use of the individual or entity to whom they
> are addressed. If this message has been sent to you in error, you must not
> copy, distribute or disclose of the information it contains. Please notify
> Entrust immediately and delete the message from your system.*
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>