<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 24/10/2020 16:21, Stephen Davidson
      via Smcwg-public wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:DM6PR14MB30180623AEC50A15C218823BE51B0@DM6PR14MB3018.namprd14.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:654071215;
        mso-list-type:hybrid;
        mso-list-template-ids:1077562224 -350328926 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-start-at:4;
        mso-level-number-format:bullet;
        mso-level-text:-;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Calibri",sans-serif;
        mso-fareast-font-family:Calibri;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hello:<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">The topic of Certification Authority
          Authorisation (CAA) has arisen a number of times in relation
          to the evolving S/MIME Baseline.<o:p></o:p></p>
        <p class="MsoNormal">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><o:p></o:p></p>
        <p class="MsoNormal">A significant number of email providers –
          such as gmail.com, outlook.com, protonmail.com, and others –
          have CAA records.<o:p></o:p></p>
        <p class="MsoNormal"><br>
          Questions for us to address later in our discussions:<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <ul style="margin-top:0in" type="disc">
          <li class="MsoListParagraph"
            style="margin-left:0in;mso-list:l0 level1 lfo1">Is CAA a
            desired requirement of the S/MIME Baseline?<o:p></o:p></li>
          <li class="MsoListParagraph"
            style="margin-left:0in;mso-list:l0 level1 lfo1">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?<o:p></o:p></li>
        </ul>
        <p class="MsoNormal"><o:p><br>
          </o:p></p>
      </div>
    </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.<br>
    </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.<br>
    </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.<br>
    </p>
    <p>Just my opinion, of course.</p>
    <p>Neil</p>
    <p>[*] Genuine question: would "issuewild" have any meaning outside
      of TLS certificates?<br>
    </p>
  </body>
</html>