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

[Mike Ounsworth <[e-mail]>]

Thanks for the explanations Corey.

I support adoption of this draft.

---
Mike Ounsworth

From: Corey Bonnell <Corey.Bonnell=[e-mail]>
Sent: December 1, 2022 8:26 AM
To: Mike Ounsworth <[e-mail]>; Stephen Farrell <[e-mail]>; Corey Bonnell <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Mike Ounsworth
Sent: Wednesday, November 30, 2022 10:29 PM
To: Stephen Farrell <[e-mail]<mailto:[e-mail]>>; Corey Bonnell <Corey.Bonnell=[e-mail]<mailto:Corey.Bonnell=[e-mail]>>; Seo Suchan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, November 30, 2022, 6:51 PM
To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; Corey Bonnell <Corey.Bonnell=[e-mail]<mailto:Corey.Bonnell=[e-mail]>>; Seo Suchan <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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.