<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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="moz-cite-prefix">On 29/1/2021 9:08 μ.μ., Paul van
Brouwershaven via Smcwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:010001774f8bdd4b-ef868c77-9dc5-409e-9746-32f7160a1b9e-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
<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 style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
<span style="font-size: 12pt;"><br>
</span></div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
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 style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
<br>
</div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
If you have a link to the relevant discussion on MDSP that would
be great!</div>
<div style="color: rgb(33, 33, 33); background-color: rgb(255,
255, 255); text-align: left;" dir="auto">
<br>
</div>
<div id="id-c49b608e-59a5-482a-9a5b-0b4c88792ac7"
class="ms-outlook-mobile-reference-message">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg"><strong>From:</strong> Tim Hollebeek
<a class="moz-txt-link-rfc2396E" href="mailto:tim.hollebeek@digicert.com"><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.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}pre
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New"}span.HTMLPreformattedChar
{font-family:Consolas}p.xmsonormal, li.xmsonormal, div.xmsonormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}p.xmsolistparagraph, li.xmsolistparagraph, div.xmsolistparagraph
{margin-right:0in;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif}span.EmailStyle24
{font-family:"Calibri",sans-serif;
color:windowtext}.MsoChpDefault
{font-size:10.0pt}div.WordSection1
{}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="WordSection1">
<p class="MsoNormal">Paul,</p>
<p class="MsoNormal"> </p>
<p class="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="MsoNormal"> </p>
<p class="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="MsoNormal"> </p>
<p class="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="MsoNormal"> </p>
<p class="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="MsoNormal"> </p>
<p class="MsoNormal">-Tim</p>
<p class="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="MsoNormal"><b>From:</b> Paul van Brouwershaven
<a class="moz-txt-link-rfc2396E" href="mailto:Paul.vanBrouwershaven@entrust.com"><Paul.vanBrouwershaven@entrust.com></a>
<br>
<b>Sent:</b> Friday, January 29, 2021 11:13 AM<br>
<b>To:</b> Neil Dunbar
<a class="moz-txt-link-rfc2396E" href="mailto:ndunbar@trustcorsystems.com"><ndunbar@trustcorsystems.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><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> Re: [Smcwg-public] CAA and S/MIME</p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="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="MsoNormal" style="background:white"><span
style="font-size:11.5pt; font-family:"Segoe
UI",sans-serif; color:black"> </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="MsoNormal" style="background:white"><span
style="font-size:11.5pt; font-family:"Segoe
UI",sans-serif; color:black"> </span></p>
</div>
<p class="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="MsoNormal"> </p>
</div>
<div>
<p class="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="MsoNormal"> </p>
</div>
<div>
<p class="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="MsoNormal"><span style="font-size:12.0pt;
color:black"><a
href="https://datatracker.ietf.org/doc/html/draft-hallambaker-donotissue-04#section-3.1.2"
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="MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="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="MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;
color:black">This would allow:
</span></p>
<div>
<p class="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="MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="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="MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;
color:black">This would allow:</span></p>
</div>
<div>
<p class="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="MsoNormal"> </p>
</div>
<div>
<p class="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="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="MsoNormal"><span style="font-size:12.0pt;
color:black">Paul</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;
color:black"> </span></p>
</div>
<div class="MsoNormal" style="text-align:center"
align="center">
<hr width="98%" size="2" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="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="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="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="xmsonormal"> </p>
<p class="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="xmsonormal"> </p>
<p class="xmsonormal">-Tim</p>
<p class="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="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="xmsonormal"> </p>
<p> </p>
<div>
<p class="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="xmsonormal">Hello:</p>
<p class="xmsonormal"> </p>
<p class="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="xmsonormal">I highlight a discussion on
that subject related to the Mozilla policy:
<a
href="https://github.com/mozilla/pkipolicy/issues/135"
moz-do-not-send="true">https://github.com/mozilla/pkipolicy/issues/135</a></p>
<p class="xmsonormal">A significant number of email
providers – such as gmail.com, outlook.com,
protonmail.com, and others – have CAA records.</p>
<p class="xmsonormal"><br>
Questions for us to address later in our
discussions:</p>
<p class="xmsonormal"> </p>
<ul style="margin-top:0in" type="disc">
<li class="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="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="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="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Smcwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a>
</pre>
</blockquote>
<br>
</body>
</html>