<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Not having these CAA records is a permission to issue. No DNS access
is required to adjust anything.<br>
<br>
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.<br>
<br>
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. <br>
<br>
<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 30/1/2021 9:23 π.μ., Paul van
Brouwershaven wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM5PR11MB00738FDDCBEBE718F4D499A0F8B89@DM5PR11MB0073.namprd11.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="auto" style="direction: ltr; margin: 0; padding: 0;
font-family: sans-serif; font-size: 11pt; color: black; ">
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.<br>
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0;
font-family: sans-serif; font-size: 11pt; color: black; ">
As in your firewall, you want to deny all and then start
allowing what should pas through.
<br>
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0;
font-family: sans-serif; font-size: 11pt; color: black; ">
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).<br>
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0;
font-family: sans-serif; font-size: 11pt; color: black; ">
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.<br>
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0;
font-family: sans-serif; font-size: 11pt; color: black; ">
Should we not focus on security and control above convenience
and commercial interest?<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0;
font-family: sans-serif; font-size: 11pt; color: black; ">
<span id="ms-outlook-android-cursor"></span><br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0;
font-family: sans-serif; font-size: 11pt; color: black; ">
<span id="OutlookSignature">
<div dir="auto" style="direction: ltr; margin: 0; padding: 0;
font-family: sans-serif; font-size: 11pt; color: black; ">
Sent from my mobile device.</div>
</span></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
Dimitris Zacharopoulos (HARICA) <a class="moz-txt-link-rfc2396E" href="mailto:dzacharo@harica.gr"><dzacharo@harica.gr></a><br>
<b>Sent:</b> Saturday, January 30, 2021 7:57:34 AM<br>
<b>To:</b> Paul van Brouwershaven
<a class="moz-txt-link-rfc2396E" href="mailto:Paul.vanBrouwershaven@entrust.com"><Paul.vanBrouwershaven@entrust.com></a>; SMIME Certificate
Working Group <a class="moz-txt-link-rfc2396E" href="mailto:smcwg-public@cabforum.org"><smcwg-public@cabforum.org></a>; Tim Hollebeek
<a class="moz-txt-link-rfc2396E" href="mailto:tim.hollebeek@digicert.com"><tim.hollebeek@digicert.com></a>; Neil Dunbar
<a class="moz-txt-link-rfc2396E" href="mailto:ndunbar@trustcorsystems.com"><ndunbar@trustcorsystems.com></a><br>
<b>Cc:</b> Kirk Hall <a class="moz-txt-link-rfc2396E" href="mailto:Kirk.Hall@entrust.com"><Kirk.Hall@entrust.com></a><br>
<b>Subject:</b> [EXTERNAL] Re: [Smcwg-public] CAA and S/MIME</font>
<div> </div>
</div>
<div>
<div>WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender
and know the content is safe.<br>
</div>
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".<br>
<br>
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.<br>
<br>
<br>
Dimitris.<br>
<br>
<div class="x_moz-cite-prefix">On 29/1/2021 9:08 μ.μ., Paul van
Brouwershaven via Smcwg-public wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto" style="color:rgb(33,33,33);
background-color:rgb(255,255,255); text-align:left">
<span style="font-size:12pt">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?</span><br>
</div>
<div dir="auto" style="color:rgb(33,33,33);
background-color:rgb(255,255,255); text-align:left">
<span style="font-size:12pt"><br>
</span></div>
<div dir="auto" style="color:rgb(33,33,33);
background-color:rgb(255,255,255); text-align:left">
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.</div>
<div dir="auto" style="color:rgb(33,33,33);
background-color:rgb(255,255,255); text-align:left">
<br>
</div>
<div dir="auto" style="color:rgb(33,33,33);
background-color:rgb(255,255,255); text-align:left">
If you have a link to the relevant discussion on MDSP that
would be great!</div>
<div dir="auto" style="color:rgb(33,33,33);
background-color:rgb(255,255,255); text-align:left">
<br>
</div>
<div id="x_id-c49b608e-59a5-482a-9a5b-0b4c88792ac7"
class="x_ms-outlook-mobile-reference-message">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg"><strong>From:</strong> Tim
Hollebeek <a class="x_moz-txt-link-rfc2396E"
href="mailto:tim.hollebeek@digicert.com"
moz-do-not-send="true">
<tim.hollebeek@digicert.com></a><br>
<strong>Sent:</strong> Friday, 29 January 2021, 19:18<br>
<strong>To:</strong> Paul van Brouwershaven; Neil Dunbar;
SMIME Certificate Working Group<br>
<strong>Cc:</strong> Kirk Hall<br>
<strong>Subject:</strong> [EXTERNAL] RE: [Smcwg-public]
CAA and S/MIME<br>
</div>
<br>
<meta content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:Wingdings}@font-face
{font-family:"Cambria Math"}@font-face
{font-family:Calibri}@font-face
{font-family:Consolas}@font-face
{font-family:"Segoe UI"}p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}a:link, span.x_MsoHyperlink
{color:blue;
text-decoration:underline}pre
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New"}span.x_HTMLPreformattedChar
{font-family:Consolas}p.x_xmsonormal, li.x_xmsonormal, div.x_xmsonormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}p.x_xmsolistparagraph, li.x_xmsolistparagraph, div.x_xmsolistparagraph
{margin-right:0in;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}span.x_EmailStyle24
{font-family:"Calibri",sans-serif;
color:windowtext}.x_MsoChpDefault
{font-size:10.0pt}ol
{margin-bottom:0in}ul
{margin-bottom:0in}</style>
<div>WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the
sender and know the content is safe.<br>
</div>
<div class="x_WordSection1">
<p class="x_MsoNormal">Paul,</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">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.</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">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.</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">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.</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">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”).</p>
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">-Tim</p>
<p class="x_MsoNormal"> </p>
<div style="border:none; border-left:solid blue 1.5pt;
padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none; border-top:solid #E1E1E1
1.0pt; padding:3.0pt 0in 0in 0in">
<p class="x_MsoNormal"><b>From:</b> Paul van
Brouwershaven <a class="x_moz-txt-link-rfc2396E"
href="mailto:Paul.vanBrouwershaven@entrust.com"
moz-do-not-send="true">
<Paul.vanBrouwershaven@entrust.com></a> <br>
<b>Sent:</b> Friday, January 29, 2021 11:13 AM<br>
<b>To:</b> Neil Dunbar <a
class="x_moz-txt-link-rfc2396E"
href="mailto:ndunbar@trustcorsystems.com"
moz-do-not-send="true">
<ndunbar@trustcorsystems.com></a>; SMIME
Certificate Working Group <a
class="x_moz-txt-link-rfc2396E"
href="mailto:smcwg-public@cabforum.org"
moz-do-not-send="true">
<smcwg-public@cabforum.org></a>; Tim
Hollebeek <a class="x_moz-txt-link-rfc2396E"
href="mailto:tim.hollebeek@digicert.com"
moz-do-not-send="true">
<tim.hollebeek@digicert.com></a><br>
<b>Cc:</b> Kirk Hall <a
class="x_moz-txt-link-rfc2396E"
href="mailto:Kirk.Hall@entrust.com"
moz-do-not-send="true">
<Kirk.Hall@entrust.com></a><br>
<b>Subject:</b> Re: [Smcwg-public] CAA and S/MIME</p>
</div>
</div>
<p class="x_MsoNormal"> </p>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">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:</span></p>
</div>
<div>
<div>
<p class="x_MsoNormal" style="background:white"><span
style=""> </span></p>
<blockquote>
<pre style="background:white"><span style="color:black">The Certification Authority Authorization (CAA) DNS Resource Record</span></pre>
<pre style="background:white"><span style="color:black"> allows a DNS domain name holder to specify one or more Certification</span></pre>
<pre style="background:white"><span style="color:black"> Authorities (CAs) authorized to issue certificates for that domain</span></pre>
<pre style="background:white"><span style="color:black"> name.</span></pre>
</blockquote>
<p class="x_MsoNormal" style="background:white"><span
style=""> </span></p>
</div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">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).</span></p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">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).</span></p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal"><span style="color:black">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. </span><span
style="font-size:12.0pt; color:black">Rob pointed
me at the draft CAA specification that had
a policy property value instead of a CA domain
name.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black"><a
href="https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04*section-3.1.2__;Iw!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GtlLred0A$"
moz-do-not-send="true">https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2</a></span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">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..?</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">This would allow:
</span></p>
<div>
<p class="x_MsoNormal"><span
style="font-size:10.5pt; font-family:"Segoe
UI",sans-serif; color:black"> </span></p>
</div>
<div>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> $ORIGIN example.com</span><span style="color:black"></span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca1.example.net; policy=2.23.140.1" // Only cabforum</span><span style="color:black"></span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca2.example.net; policy=2.23.140.1.5" // SMIME</span><span style="color:black"></span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca3.example.net; policy=2.23.140.1.2" // DV, OV, IV</span><span style="color:black"></span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca4.example.net; policy=2.23.140.1.1" // EV</span><span style="color:black"></span></pre>
</div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">For <span style="background:white">
user </span>friendliness, we could define a new
parameter such as `type` with the same intention
but based on a name value:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">This would allow:</span></p>
</div>
<div>
<p class="x_MsoNormal"> </p>
</div>
<div>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> $ORIGIN example.com</span></pre>
<pre><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca1.example.net"</span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca2.example.net; type=smime"</span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca3.example.net; type=tls"</span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca4.example.net; type=tls-ev"</span></pre>
<pre><span style="font-family:"Calibri",sans-serif; color:#201F1E; background:white"> </span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">Where:</span></pre>
<pre style="margin-left:.5in; text-indent:-.25in; mso-list:l0 level1 lfo1; break-before:page"><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman""> </span></span></span><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">ca1 could issue any type of certificate not explicitly specified (so no S/MIME, or TLS certificates in this example)</span></pre>
<pre style="margin-left:.5in; text-indent:-.25in; mso-list:l0 level1 lfo1"><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman""> </span></span></span><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">ca2 could issue only smime certificates</span></pre>
<pre style="margin-left:.5in; text-indent:-.25in; mso-list:l0 level1 lfo1; break-before:page"><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman""> </span></span></span><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">ca3 could issue any type of TLS certificate except for EV</span></pre>
<pre style="margin-left:.5in; text-indent:-.25in; mso-list:l0 level1 lfo1; break-before:page"><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman""> </span></span></span><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">ca4 could issue only EV TLS certificates</span></pre>
<pre style="break-before:page"> </pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">Alternatively, we could define two parameters, one for the certificate type and one for the assurance level, this would give:</span></pre>
<pre style="break-before:page"> </pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> $ORIGIN example.com</span></pre>
<pre style="background:white"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca1.example.net"</span><span style="font-size:10.5pt; color:black"></span></pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca2.example.net; type=smime"</span><span style="color:black"></span></pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca3.example.net; type=tls"</span><span style="color:black"></span></pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca4.example.net; type=tls; level=ev;"</span><span style="color:black"></span></pre>
<p class="x_MsoNormal"> </p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">The challenge for all these methods
is how do we drop CAA limitations, as we want
something like:</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> $ORIGIN example.com</span></pre>
<pre style="background:white"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca1.example.net"</span><span style="font-size:10.5pt; font-family:"Calibri",sans-serif; color:black"></span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black; background:white"> . CAA 0 issue "*; type=smime"</span><span style="color:black; background:white"></span></pre>
<pre style="background:white; break-before:page"><span style="font-size:10.5pt; font-family:"Calibri",sans-serif; color:black"> </span></pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">But that is not allowed by the RFC.</span></pre>
<pre style="break-before:page"> </pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">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 .</span></pre>
<pre style="break-before:page"> </pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> $ORIGIN example.com</span></pre>
<pre style="background:white"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca1.example.net"</span><span style="font-size:10.5pt; color:black"></span></pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issuesmime "ca2.example.net"</span><span style="color:black"></span></pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issuetls "ca3.example.net"</span><span style="color:black"></span></pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issuetlsev "ca4.example.net"</span><span style="color:black"></span></pre>
<pre> </pre>
<pre style="break-before:page"><span style="font-size:12.0pt; font-family:"Calibri",sans-serif; color:black">Maybe we could simply create an 'unrestricted' parameter to overrule the RFC?:</span></pre>
<pre style="break-before:page"> </pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> $ORIGIN example.com</span></pre>
<pre style="background:white"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "ca1.example.net"</span><span style="font-size:10.5pt; color:black"></span></pre>
<pre style="background:white; break-before:page"><span style="font-size:12.0pt; font-family:Consolas; color:black"> . CAA 0 issue "; type=smime; unrestricted=true"</span><span style="color:black"></span></pre>
<pre> </pre>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black">Paul</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div class="x_MsoNormal" style="text-align:center"
align="center">
<hr width="98%" size="2" align="center">
</div>
<div id="x_divRplyFwdMsg">
<p class="x_MsoNormal"><b><span style="color:black">From:</span></b><span
style="color:black"> Smcwg-public <<a
href="mailto:smcwg-public-bounces@cabforum.org"
moz-do-not-send="true">smcwg-public-bounces@cabforum.org</a>>
on behalf of Tim Hollebeek via Smcwg-public <<a
href="mailto:smcwg-public@cabforum.org"
moz-do-not-send="true">smcwg-public@cabforum.org</a>><br>
<b>Sent:</b> Monday, October 26, 2020 15:25<br>
<b>To:</b> Neil Dunbar <<a
href="mailto:ndunbar@trustcorsystems.com"
moz-do-not-send="true">ndunbar@trustcorsystems.com</a>>;
SMIME Certificate Working Group <<a
href="mailto:smcwg-public@cabforum.org"
moz-do-not-send="true">smcwg-public@cabforum.org</a>><br>
<b>Subject:</b> [EXTERNAL]Re: [Smcwg-public] CAA
and S/MIME</span> </p>
<div>
<p class="x_MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="x_xmsonormal">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.</p>
<p class="x_xmsonormal"> </p>
<p class="x_xmsonormal">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.</p>
<p class="x_xmsonormal"> </p>
<p class="x_xmsonormal">-Tim</p>
<p class="x_xmsonormal"> </p>
<div style="border:none; border-left:solid blue
1.5pt; padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none; border-top:solid
#E1E1E1 1.0pt; padding:3.0pt 0in 0in 0in">
<p class="x_xmsonormal"><b>From:</b>
Smcwg-public <<a
href="mailto:smcwg-public-bounces@cabforum.org"
moz-do-not-send="true">smcwg-public-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Neil Dunbar via
Smcwg-public<br>
<b>Sent:</b> Monday, October 26, 2020 6:03
AM<br>
<b>To:</b> <a
href="mailto:smcwg-public@cabforum.org"
moz-do-not-send="true">smcwg-public@cabforum.org</a><br>
<b>Subject:</b> Re: [Smcwg-public] CAA and
S/MIME</p>
</div>
</div>
<p class="x_xmsonormal"> </p>
<p> </p>
<div>
<p class="x_xmsonormal">On 24/10/2020 16:21,
Stephen Davidson via Smcwg-public wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;
margin-bottom:5.0pt">
<p class="x_xmsonormal">Hello:</p>
<p class="x_xmsonormal"> </p>
<p class="x_xmsonormal">The topic of
Certification Authority Authorisation (CAA)
has arisen a number of times in relation to
the evolving S/MIME Baseline.</p>
<p class="x_xmsonormal">I highlight a discussion
on that subject related to the Mozilla policy:
<a
href="https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/135__;!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GspokrqcA$"
moz-do-not-send="true">
https://github.com/mozilla/pkipolicy/issues/135</a></p>
<p class="x_xmsonormal">A significant number of
email providers – such as gmail.com,
outlook.com, protonmail.com, and others – have
CAA records.</p>
<p class="x_xmsonormal"><br>
Questions for us to address later in our
discussions:</p>
<p class="x_xmsonormal"> </p>
<ul style="margin-top:0in" type="disc">
<li class="x_xmsolistparagraph"
style="margin-top:0in; margin-bottom:0in;
mso-list:l1 level1 lfo2">
Is CAA a desired requirement of the S/MIME
Baseline?</li>
<li class="x_xmsolistparagraph"
style="margin-top:0in; margin-bottom:0in;
mso-list:l1 level1 lfo2">
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?</li>
</ul>
<p class="x_xmsonormal"
style="margin-bottom:12.0pt"> </p>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Just my opinion, of course.</p>
<p>Neil</p>
<p>[*] Genuine question: would "issuewild" have
any meaning outside of TLS certificates?</p>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<fieldset class="x_mimeAttachmentHeader"></fieldset>
<pre class="x_moz-quote-pre">_______________________________________________
Smcwg-public mailing list
<a class="x_moz-txt-link-abbreviated" href="mailto:Smcwg-public@cabforum.org" moz-do-not-send="true">Smcwg-public@cabforum.org</a>
<a class="x_moz-txt-link-freetext" href="https://urldefense.com/v3/__https://lists.cabforum.org/mailman/listinfo/smcwg-public__;!!FJ-Y8qCqXTj2!IBoj6xSTMxPkjo7rD0Gkn1l3AXVVMPwz8K-fe_d1vIOudW99epByL8XEpO9PYRLC7GuY2WazZQ$" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
<br>
</body>
</html>