Re: [lamps] CAA processing for email addresses

Some extended though over critical flag: would we need a namespace for 
email related and/or reserve a bit in CAA flag bit that mean critical 
just for mail CAs while not breaking cert for TLS CAs?

and CAs should understand most TLS-related CAA records (ex. RFC8657's 
acme relayed validationmethod and accounturi) but ignore it as it 
doesn't apply to them? this kinda looks asymmetrical, but we can't just 
ignore critical flag because we are not TLS CA, right?

not sure how different types of CAs will handle CAA records that says 
critical on tin but possibly not about them.

2022-12-01 5:47AM written by Corey Bonnell:
>
> Hi Seo,
>
> Comments inline.
>
>   * 1. marking this record critical will make block TLS certificate
>     for that domain unless they understand this. I think that is a
>     footgun worth mention.
>
> Thanks, that’s a great point. I’ll make a note of this and add it to 
> the Security Considerations in the next update.
>
>   * 2. there are 'free to register' email domains. would it be
>     acceptable to them to limit client's certificate choice?
>
> Fundamentally, CAA is a mechanism for domains to express the allowed 
> set of CAs that may issue certificates. Given that the mailbox 
> provider owns/controls the domain name in question, I believe it is 
> entirely acceptable for such a mailbox provider to limit the set of 
> CAs that can issue S/MIME certificates for the provider’s domain.
>
> Thanks,
>
> Corey
>
> *From:* Spasm <spasm-bounces@ietf.org> *On Behalf Of *Seo Suchan
> *Sent:* Wednesday, November 30, 2022 3:00 PM
> *To:* spasm@ietf.org
> *Subject:* Re: [lamps] CAA processing for email addresses
>
> some thoughts:
>
> 1. marking this record critical will make block TLS certificate for 
> that domain unless they understand this. I think that is a footgun 
> worth mention.
>
> 2. there are 'free to register' email domains. would it be acceptable 
> to them to limit client's certificate choice?
>
> for example, Google can set a issuemail record on gmail.com with a 
> contracted CA and force user go get s/mime from that CA.
>
> 2022-12-01 오전 2:17에 Corey Bonnell 이(가) 쓴글:
>
>     Hello,
>
>     Over the past several years, there have been discussions [1][2][3]
>     on extending CAA such that it can be used for domains to express
>     restrictions on the issuance of certificates for email addresses
>     (e.g., S/MIME certificates, etc.). With the recent passage of the
>     initial version of the CA/Browser Forum S/MIME Baseline
>     Requirements, there is a renewed interest in mandating that
>     publicly trusted CAs process CAA records prior to the issuance of
>     S/MIME certificates in an upcoming version of the requirements. In
>     order to provide a full specification for CAA processing for email
>     addresses, I drafted an I-D for a new CAA property tag:
>     https://www.ietf.org/archive/id/draft-bonnell-caa-issuemail-00.html.
>     I am hopeful that such a specification can be reviewed here such
>     that any update to the S/MIME Baseline Requirements that mandates
>     CAA processing can directly reference the specification.
>
>     Given that CAA is a topic that is firmly within the scope of this
>     WG, I wanted to circulate the draft here and would appreciate
>     feedback and comments.
>
>     Thanks,
>
>     Corey
>
>     [1]
>     https://groups.google.com/g/mozilla.dev.security.policy/c/NIc2Nwa9Msg
>
>     [2] https://github.com/mozilla/pkipolicy/issues/135
>
>     [3]
>     https://lists.cabforum.org/pipermail/smcwg-public/2020-October/000040.html
>
>
>
>     _______________________________________________
>
>     Spasm mailing list
>
>     Spasm@ietf.org
>
>     https://www.ietf.org/mailman/listinfo/spasm
>