[Smcwg-public] [EXTERNAL] Re: CAA and S/MIME

Mon Feb 1 22:41:21 UTC 2021

FYI, https://tools.ietf.org/html/draft-biggs-acme-sso-00#section-6 seeks to "extend CAA to allow control over issuance of certificates for email addresses within that domain".

________________________________
From: Smcwg-public <smcwg-public-bounces at cabforum.org> on behalf of Dimitris Zacharopoulos (HARICA) via Smcwg-public <smcwg-public at cabforum.org>
Sent: 30 January 2021 08:57
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org>; Tim Hollebeek <tim.hollebeek at digicert.com>; Neil Dunbar <ndunbar at trustcorsystems.com>
Cc: Kirk Hall <Kirk.Hall at entrust.com>
Subject: Re: [Smcwg-public] [EXTERNAL] Re: CAA and S/MIME

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Not having these CAA records is a permission to issue. No DNS access is required to adjust anything.

If a concerned Domain Name owner wants to use CAA to restrict issuance to a specific set of CAs, they better know what they're doing because it might disable their ability to get publicly trusted certificates.

It's just like setting up SPF/DKIM (the mail system works fine without it). The mail admin should know what to do otherwise mails might be lost if something is not configured properly.

Dimitris.

On 30/1/2021 9:23 π.μ., Paul van Brouwershaven wrote:
Looking at it from a commercial point of view I get the interest to separate all type of certificates (everything that prevents issuance costs money). From a security point of view it's sounds like a firewall that only allows me to block known issues.

As in your firewall, you want to deny all and then start allowing what should pas through.

Allowing something new could be a internal request like you would for for all dns records (like you also do not give the whole company access to your dns system or your firewall and most corporate devices don't allow users to install any applications without prior approval).

If you let everything though you are out of control. Like in the early days of the internet we worked with block lists. Today everything is based on permit list, including SPF, DKIM and actually the CAA RFC.

Should we not focus on security and control above convenience and commercial interest?

Sent from my mobile device.
________________________________
From: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr><mailto:dzacharo at harica.gr>
Sent: Saturday, January 30, 2021 7:57:34 AM
To: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com><mailto:Paul.vanBrouwershaven at entrust.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org><mailto:smcwg-public at cabforum.org>; Tim Hollebeek <tim.hollebeek at digicert.com><mailto:tim.hollebeek at digicert.com>; Neil Dunbar <ndunbar at trustcorsystems.com><mailto:ndunbar at trustcorsystems.com>
Cc: Kirk Hall <Kirk.Hall at entrust.com><mailto:Kirk.Hall at entrust.com>
Subject: [EXTERNAL] Re: [Smcwg-public] CAA and S/MIME

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
I also believe that Domain Name owners should have a different tag per certificate type. It doesn't make sense to have a "one tag to rule them all".

So, if an owner wants to restrict ALL certificate issuance to one CA for TLS and S/MIME, two CAA records would need to be added.

Dimitris.

On 29/1/2021 9:08 μ.μ., Paul van Brouwershaven via Smcwg-public wrote:
Do I understand you correctly that in your opinion domain name owners should not have the ability to restrict all certificate issuance with a single record?

I don't think we can expect that a domain name owner would add CAA records for every ecosystem (if they even know about there existence) because these ecosystems want to be independent.

If you have a link to the relevant discussion on MDSP that would be great!

________________________________
From: Tim Hollebeek <tim.hollebeek at digicert.com><mailto:tim.hollebeek at digicert.com>
Sent: Friday, 29 January 2021, 19:18
To: Paul van Brouwershaven; Neil Dunbar; SMIME Certificate Working Group
Cc: Kirk Hall
Subject: [EXTERNAL] RE: [Smcwg-public] CAA and S/MIME

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

Paul,

You might want to review the previous discussions of this issue on MDSP, where it was made pretty clear, including by the author of the RFC, that the “issue” tag was intended to be specific to the web.  CAA for certificate type has also been discussed quite a bit here at the Forum recently (it was an idea we introduced about three years ago and were pushing), so you might want to review the long discussion of those proposals and why they didn’t move forward.

It’s not clear why you think there are problems with having both ‘issue’ and ‘issueesmime’, especially since your analysis seems to assume that if they’re both there, they interact in some way.  They should not, and that seems to be the source of the problems you’re trying to highlight.

What one wants is to be able to clearly state the policy for each ecosystem, without interactions.  Interactions between different certificate ecosystems are the cause of most of PKIs problems, and we should be looking to eliminate cross-PKI interactions, not introduce new ones.

It’s pretty straightforward to do that with a new tag.  No additional properties or semantics are required.  And the process of adding a new tag is something this group has already successfully done once (“CAA CONTACT”).

-Tim

From: Paul van Brouwershaven <Paul.vanBrouwershaven at entrust.com><mailto:Paul.vanBrouwershaven at entrust.com>
Sent: Friday, January 29, 2021 11:13 AM
To: Neil Dunbar <ndunbar at trustcorsystems.com><mailto:ndunbar at trustcorsystems.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org><mailto:smcwg-public at cabforum.org>; Tim Hollebeek <tim.hollebeek at digicert.com><mailto:tim.hollebeek at digicert.com>
Cc: Kirk Hall <Kirk.Hall at entrust.com><mailto:Kirk.Hall at entrust.com>
Subject: Re: [Smcwg-public] CAA and S/MIME

While the BR only specifies how CAA must be implemented/used for TLS certificates the CAA RFC is not limited to just TLS certificates, the RFC 8659 (and previously RFC 6844) begins with:

The Certification Authority Authorization (CAA) DNS Resource Record

   allows a DNS domain name holder to specify one or more Certification

   Authorities (CAs) authorized to issue certificates for that domain

   name.

This does make sense as this would create a `deny all, except` principle where you need to give explicit permission like as in a good firewall configuration. But I agree that there should be a possibility to change permission per certificate type and to drop restrictions where needed (such as for S/MIME with shared mail providers).

I'm currently not in favor of having a new S/MIME specific property, and one for client certs, document signing, etc. as where does it stop. It would also not allow to have separate `iodef` settings for example (or only enable them for TLS).

We could define one new parameter to define the certificate type, the standard already has a reversed policy property which was used in the draft RFC to limit issuance on policy OID. Rob pointed me at the draft CAA specification that had a policy property value instead of a CA domain name.

https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hallambaker-donotissue-04*section-3.1.2__%3BIw!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GtlLred0A%24&data=04%7C01%7Crob%40sectigo.com%7C9b99d469935b4ef8b36f08d8c4fd1e82%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637475938725037749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JEv8UyUUxUB%2BNaALVMOlnafd40JKeqvA4zYotYl%2FDZw%3D&reserved=0>

This could work with cabforum defined OID's, the advantage from using OID's is that it would support an OID prefix, and it would be easier for CAs to enforce. But it's not very user friendly..?

This would allow:

   $ORIGIN example.com

   .       CAA 0 issue "ca1.example.net; policy=2.23.140.1"   // Only cabforum

   .       CAA 0 issue "ca2.example.net; policy=2.23.140.1.5" // SMIME

   .       CAA 0 issue "ca3.example.net; policy=2.23.140.1.2" // DV, OV, IV

   .       CAA 0 issue "ca4.example.net; policy=2.23.140.1.1" // EV

For user friendliness, we could define a new parameter such as `type` with the same intention but based on a name value:

This would allow:

   $ORIGIN example.com

   .       CAA 0 issue "ca1.example.net"

   .       CAA 0 issue "ca2.example.net; type=smime"

   .       CAA 0 issue "ca3.example.net; type=tls"

   .       CAA 0 issue "ca4.example.net; type=tls-ev"

Where:

·        ca1 could issue any type of certificate not explicitly specified (so no S/MIME, or TLS certificates in this example)

·        ca2 could issue only smime certificates

·        ca3 could issue any type of TLS certificate except for EV

·        ca4 could issue only EV TLS certificates

Alternatively, we could define two parameters, one for the certificate type and one for the assurance level, this would give:

   $ORIGIN example.com

   .       CAA 0 issue "ca1.example.net"

   .       CAA 0 issue "ca2.example.net; type=smime"

   .       CAA 0 issue "ca3.example.net; type=tls"

   .       CAA 0 issue "ca4.example.net; type=tls; level=ev;"

The challenge for all these methods is how do we drop CAA limitations, as we want something like:

   $ORIGIN example.com

   .       CAA 0 issue "ca1.example.net"

   .       CAA 0 issue "*; type=smime"

But that is not allowed by the RFC.

If we would define a separate property per certificate type but follow the RFC and honoring the inheritance, we would still have the same challenge of stopping the inheritance .

   $ORIGIN example.com

   .       CAA 0 issue "ca1.example.net"

   .       CAA 0 issuesmime "ca2.example.net"

   .       CAA 0 issuetls "ca3.example.net"

   .       CAA 0 issuetlsev "ca4.example.net"

Maybe we could simply create an 'unrestricted' parameter to overrule the RFC?:

   $ORIGIN example.com

   .       CAA 0 issue "ca1.example.net"

   .       CAA 0 issue "; type=smime; unrestricted=true"

Paul

________________________________

From: Smcwg-public <smcwg-public-bounces at cabforum.org<mailto:smcwg-public-bounces at cabforum.org>> on behalf of Tim Hollebeek via Smcwg-public <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Sent: Monday, October 26, 2020 15:25
To: Neil Dunbar <ndunbar at trustcorsystems.com<mailto:ndunbar at trustcorsystems.com>>; SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Subject: [EXTERNAL]Re: [Smcwg-public] CAA and S/MIME

This is how I feel about the issue.  CAA is potentially an interesting improvement to the S/MIME ecosystem, but the current tags and implementation were meant for TLS, and shouldn’t be reused.

The RFC has an extension mechanism which can easily be used to add new tags for S/MIME issuance, and issuance of other kinds of non-TLS certificates.

-Tim

From: Smcwg-public <smcwg-public-bounces at cabforum.org<mailto:smcwg-public-bounces at cabforum.org>> On Behalf Of Neil Dunbar via Smcwg-public
Sent: Monday, October 26, 2020 6:03 AM
To: smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] CAA and S/MIME

On 24/10/2020 16:21, Stephen Davidson via Smcwg-public wrote:

Hello:

The topic of Certification Authority Authorisation (CAA) has arisen a number of times in relation to the evolving S/MIME Baseline.

I highlight a discussion on that subject related to the Mozilla policy: https://github.com/mozilla/pkipolicy/issues/135<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F135__%3B!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GspokrqcA%24&data=04%7C01%7Crob%40sectigo.com%7C9b99d469935b4ef8b36f08d8c4fd1e82%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637475938725037749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1hEPkUNikYsOy5GEaMFGR99Lexby5LU76X9V7dnRvdQ%3D&reserved=0>

A significant number of email providers – such as gmail.com, outlook.com, protonmail.com, and others – have CAA records.

Questions for us to address later in our discussions:

  *   Is CAA a desired requirement of the S/MIME Baseline?
  *   Should the S/MIME Baseline rely upon the existing requirements stated in the TLS BR, or is the S/MIME use case sufficiently different to merit a separate CAA tag?

Generally, I'm a fan of allowing organisations (however defined) to specify their policy requirements for publicly trusted certificates via CAA records; so I would say "yes", it is a desired requirement of the S/MIME baseline. I would certainly expect it to make its way into the root program requirements at some point, and having a pan-root program consensus on those requirements beats having overlapping or potentially conflicting requirements.

That said, I'm not a fan of ninja semantics (changing the meaning of a deployed resource where the deployer might not have considered its eventual full scope) - it seems to me that the "issue" and "issuewild" tags were framed with TLS certificates in mind[*], and I think extending "issue" to cover S/MIME could have effects on domain owners which were not expected. In other words, we would be saying to them that all certificates are hereby covered, without them having any means of expressing the policy "I want CA X to issue TLS certificates, but any CA could issue S/MIME certificates"; so I'm less of a fan of reducing the expressive potential of domain owners.

To that extent, I think that I'd prefer tags like "issue-tls", "issue-tls-wildcard", "issue-email", and so on, with similar semantics which work over "issue" and "issuewild" right now. Once those are in effect, then you could extend the "issue" tag to mean "all certificates" as a shorthand, while leaving finer detailed policy expressions. However, that goes further than anything the S/MIME WG could reasonably pronounce upon. But "issue-email" to cover S/MIME certs falls within its charter and seems to have a clearer scope. There's even an opportunity to allow domain owners to specify the validation methods permissible for issuance, but that's a whole different discussion.

Just my opinion, of course.

Neil

[*] Genuine question: would "issuewild" have any meaning outside of TLS certificates?

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/smcwg-public<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fsmcwg-public__%3B!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GuY2WazZQ%24&data=04%7C01%7Crob%40sectigo.com%7C9b99d469935b4ef8b36f08d8c4fd1e82%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637475938725047707%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o7YGpZK9cQxMGWc4dmdy%2BIEApRJ11DNeTlHHXy02PSA%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210201/ad58adf1/attachment-0001.html>