Re: [lamps] CAA processing for email addresses

[Corey Bonnell <[e-mail]>]

Hi Seo,

Thanks for further discussion on fleshing out criticality. Comments inline.

 

*	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?

Can you expand on the use case for a “mail-only” criticality bit? My first thought is that it’s unnecessary, because either the CA understands a given critical Property and knows it can ignore it because it is not relevant to the type of certificate to be issued, or it fails to issue because it doesn’t understand the critical Property. This behavior aligns with the intent of the criticality flag: is it a signal that the CA MUST understand the given Property or fail to issue.

 

*	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?

 

My understanding is that parameters are relevant solely to the specified issuer-domain-name; if the CA is not identified by the issuer-domain-name in the Property, then it need not understand or process any of the parameters.

 

Thanks,

Corey

 

From: Seo Suchan <[e-mail]> 
Sent: Thursday, December 15, 2022 9:20 PM
To: Corey Bonnell <[e-mail]>; [e-mail]
Subject: 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.	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.	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  <mailto:[e-mail]> <[e-mail]> On Behalf Of Seo Suchan
Sent: Wednesday, November 30, 2022 3:00 PM
To: [e-mail] <mailto:[e-mail]> 
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
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/spasm