[Smcwg-public] CAA and S/MIME
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Sat Jan 30 06:57:34 UTC 2021
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>
> *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>
> *Sent:* Friday, January 29, 2021 11:13 AM
> *To:* Neil Dunbar <ndunbar at trustcorsystems.com>; SMIME Certificate
> Working Group <smcwg-public at cabforum.org>; Tim Hollebeek
> <tim.hollebeek at digicert.com>
> *Cc:* Kirk Hall <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://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2>
>
> 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://github.com/mozilla/pkipolicy/issues/135>
>
> 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
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210130/c9cf6991/attachment-0001.html>
More information about the Smcwg-public
mailing list