[Smcwg-public] CAA and S/MIME
Tim Hollebeek
tim.hollebeek at digicert.com
Fri Jan 29 18:18:30 UTC 2021
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#sectio
n-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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210129/86da3115/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210129/86da3115/attachment-0001.p7s>
More information about the Smcwg-public
mailing list