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

[Corey Bonnell <[e-mail]>]

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