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

[Corey Bonnell <[e-mail]>]

Hi Nicolas,

Thanks for raising this, reply inline.

 

*	Is there a reason the tags are not tied to the Key Usage of the certs? 

In particular for S/MIME, you may need to consider certificates only issued for digital signature and others only for encryption.

 

My current thinking on how CAA can be used to express more granular restrictions on issuance would be to define one or more parameters for the issuemail property tag to restrict the sub-types (signing, encryption, or dual use) of certificates that the single authorized CA can issue. I believe that such syntax would clearly delimit the semantics of different property tags and their associated parameters. Property tags are used to restrict the issuance of certificates that include particular names (in the S/MIME case, email addresses) to specific CAs. Parameters are then used to further restrict validation and issuance for those authorized CAs. For example:

 

CAA issuemail “ca.example.com” (restricts issuance to ca.example.com with no restrictions on key usage)

CAA issuemail “ca.example.com; key-usage=encryption” (restricts issuance to ca.example.com and further restricts issuance to encryption certs only)

 

I think it may be valuable to standardize such parameters to ensure that the parameter syntax for “S/MIME certificate type” is consistent across CAs as opposed to each CA defining their own bespoke syntax. One area that I’m mulling is whether we would want to define such parameter syntax in the current draft (which currently addresses the property tag) or spin up another draft to define the parameters for the new property tag. I can see pros and cons for both approaches (separation of concerns in different documents allows for more concise documents that facilitate easier reviews at the expense of more documents in flight). I’m rather new to the document authoring process so I’d appreciate any insights in this regard.

 

Thanks,

Corey

 

From: Spasm <[e-mail]> On Behalf Of Nicolas Lidzborski
Sent: Monday, December 5, 2022 6:16 PM
To: Corey Bonnell <Corey.Bonnell=[e-mail]>
Cc: Antonios Chariton <[e-mail]>; [e-mail]
Subject: Re: [lamps] [EXTERNAL] Re: CAA processing for email addresses

 

 

 

On Sun, Dec 4, 2022 at 4:24 PM Corey Bonnell <Corey.Bonnell=[e-mail] <mailto:[e-mail]> > wrote:

Hi Antonios,

Thanks for your comments. Responses inline.

 

*	Perhaps “mailissue” or “mail” is better (explained in the thread) or even “smime”. This allows for “smimeentity” and “smimeserver” for example, if there’s a future need for that.

 

I follow your logic in your previous message and think we should settle on a common convention in our two drafts. I’m partial to including a verb in the property tag to disambiguate the tag from other property tags that may be relevant to the specific certificate type but not specify any restrictions on the set of CAs that can issue. Additionally, I think there’s value in retaining the “verb-object” tag-naming convention established by RFC 6844/8659 with “issuewild”. Otherwise, there will be inconsistency in naming depending on the certificate type.

 

Is there a reason the tags are not tied to the Key Usage of the certs? 

In particular for S/MIME, you may need to consider certificates only issued for digital signature and others only for encryption.

 

*	I don’t know if I would make this critical

 

I agree with you and Phillip that this tag shouldn’t be critical by default. I’ll clarify this point in an update to the draft in the next few days. 

*	In terms of adoption, I would like to see CAA for S/MIME, and this is a good and simple way to achieve it.

 

I also see CAA for IP addresses as valuable for the ecosystem as well. I plan to give your draft a fuller read shortly and will follow up with any comments.

 

Thanks,

Corey

 

From: Antonios Chariton <[e-mail] <mailto:[e-mail]> > 
Sent: Friday, December 2, 2022 10:51 AM
To: [e-mail] <mailto:[e-mail]> 
Cc: Corey Bonnell <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] [EXTERNAL] Re: CAA processing for email addresses

 

I think that CAA for S/MIME is useful, and can help enforce policies for an enterprise, and even for large e-mail providers (although probably not for their main domain gmail.com <http://gmail.com>  / hotmail.com <http://hotmail.com>  / etc.). I participate here on my personal capacity and won’t speak on behalf of Gmail.

 

Two things I’d maybe consider, one of which is described in my thread[1] too:

 

- Perhaps “mailissue” or “mail” is better (explained in the thread) or even “smime”. This allows for “smimeentity” and “smimeserver” for example, if there’s a future need for that.

 

- I don’t know if I would make this critical

 

Marking this as critical will require all CAs (at least) to build support for it, otherwise its presence will block issuance of TLS certificates. My suggestion is to make this non-critical (as it is not necessary to use CAA for this domain at all), and then require parsing of CAA “mail” (or whatever) properties in the requirements that include this doc. In this case, it can be the CA/B Forum BRs. If they specify that CAs MUST follow / understand / support / conform to … RFCXXXX then you achieve the criticality in the publicly trusted space, without breaking all CAA implementations in the meantime.

 

I would argue that this property is not critical for a CA that does not issue S/MIME certs, and in my view the critical flag is for things necessary for all CAA uses, not just one.

 

In terms of adoption, I would like to see CAA for S/MIME, and this is a good and simple way to achieve it. The lack of Certificate Transparency in the space will make it more difficult to detect misissuance / non-conformity, but when detected it would make it hopefully easier to prove. Without speaking on behalf of any Root Program, I imagine this would help many stakeholders in the S/MIME ecosystem.

 

Antonis

 

 

1: https://mailarchive.ietf.org/arch/msg/spasm/dQLF1fQQPNX9A59YV4imXRz9ABw/

 

On 1 Dec 2022, at 22:42, Phillip Hallam-Baker <[e-mail] <mailto:[e-mail]> > wrote:

 

But this is not a proposal that would be relevant to Mail Service Operators like Gmail or Hotmail.

 

It is only relevant to enterprises running mail services under their own DNS name. Outsourcing that to a mail service provider would not impact the use of CAA or S/MIMe in the slightest.

 

 

On Thu, Dec 1, 2022 at 3:02 PM Stephen Farrell <[e-mail] <mailto:[e-mail]> > wrote:



On 01/12/2022 18:46, Phillip Hallam-Baker wrote:
> I support adoption of this draft.

In the absence of mail service operators who say they want
this, I'm against adoption. (If this does originate in CAB
forum, I'm not aware folks like that are represented there.)

If some mail service operators wanted this, I'd consider what
they said.

S.

_______________________________________________
Spasm mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/spasm

 

_______________________________________________
Spasm mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/spasm