[Smcwg-public] CAA and S/MIME

[Tim Hollebeek]

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> On Behalf Of Neil
Dunbar via Smcwg-public
Sent: Monday, October 26, 2020 6:03 AM
To: 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/20201026/b94fab9d/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/20201026/b94fab9d/attachment-0001.p7s>