[Smcwg-public] [EXTERNAL] Re: CAA and S/MIME
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Sat Jan 30 08:57:40 UTC 2021
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>
> *Sent:* Saturday, January 30, 2021 7:57:34 AM
> *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:* [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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04*section-3.1.2__;Iw!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GtlLred0A$>
>>
>> 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://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/135__;!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GspokrqcA$>
>>
>> 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://urldefense.com/v3/__https://lists.cabforum.org/mailman/listinfo/smcwg-public__;!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GuY2WazZQ$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210130/da609798/attachment-0001.html>
More information about the Smcwg-public
mailing list