<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 14/5/2024 12:53 Î¼.μ., Martijn
      Katerbarg wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:SA1PR17MB650353336B167C8FCB29EA9AE3E32@SA1PR17MB6503.namprd17.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator"
        content="Microsoft Word 15 (filtered medium)">
      <style>@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;}@font-face
        {font-family:Aptos;
        panose-1:2 11 0 4 2 2 2 2 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:12.0pt;
        font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Aptos",sans-serif;
        color:windowtext;}span.apple-converted-space
        {mso-style-name:apple-converted-space;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}div.WordSection1
        {page:WordSection1;}</style>
      <div class="WordSection1">
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US">></span><span style="color:#212121">Thoughts?
            Disagreements? I know that Apple has already publicly<span
              class="apple-converted-space"> </span></span><a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1886467%23c13&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ccc5e5bc3c5844518497708dc73f8f6c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512760354884136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QWqJjIw8XcHlSKQ17G9764glFPOvtujhS%2BwOtvMSuG4%3D&reserved=0"
title="Original URL:
https://bugzilla.mozilla.org/show_bug.cgi?id=1886467#c13

Click to follow link." moz-do-not-send="true"><span
              style="color:#0078D7">shared an opinion</span></a><span
            class="apple-converted-space"><span style="color:#212121"> </span></span><span
            style="color:#212121">on this matter so I'm hoping to get
            more feedback from Members here :)</span><o:p></o:p></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="SV"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US">I do agree with the quoted statement. </span></p>
      </div>
    </blockquote>
    <br>
    Are you referring to <i>your</i> quoted statement? I had two quotes
    in my first email of the thread :-)<br>
    <br>
    <blockquote type="cite"
cite="mid:SA1PR17MB650353336B167C8FCB29EA9AE3E32@SA1PR17MB6503.namprd17.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US">If compliance is asserted by the inclusion of a
            Policy OID, it would come into scope. If not, then indeed it
            would seem, it’s not in scope.</span></p>
      </div>
    </blockquote>
    <br>
    I already answered that in
    <a class="moz-txt-link-freetext" href="https://lists.cabforum.org/pipermail/servercert-wg/2024-May/004575.html">https://lists.cabforum.org/pipermail/servercert-wg/2024-May/004575.html</a>
    (apologies for starting the responses in reverse order).<br>
    <blockquote type="cite"
cite="mid:SA1PR17MB650353336B167C8FCB29EA9AE3E32@SA1PR17MB6503.namprd17.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US"><o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US">To me this mainly raises the question: What is
            a CA allowed to do with a SubCA Private Key. Section 6.1.7
            states what a private key corresponding to a Root
            Certificate may be used for. Do we need something similar
            for private keys corresponding to Subordinate CAs?</span></p>
      </div>
    </blockquote>
    <br>
    <blockquote type="cite"
cite="mid:SA1PR17MB650353336B167C8FCB29EA9AE3E32@SA1PR17MB6503.namprd17.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US"><o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US">Such a requirement could then indicate which
            type of objects may be signed (such as CRLs, OCSP responses,
            TLS certs, precerts. Since the requirements are related to
            TLS Certificates, in my opinion it would be in scope to say
            that a Subordinate CA capable of issuing TLS Certificates,
            may or may not issue clientAuth-only certificates, and if
            so, according to which profile.</span></p>
      </div>
    </blockquote>
    <br>
    This is an interesting idea, I wouldn't object to it as long as we
    reach consensus about the intent related to client authentication
    -and other non-server-TLS, non-codeSigning, non-timeStamping,
    non-emailProtection-
    leaf certificates.<br>
    <br>
    <br>
    Thanks,<br>
    Dimitris.<br>
    <blockquote type="cite"
cite="mid:SA1PR17MB650353336B167C8FCB29EA9AE3E32@SA1PR17MB6503.namprd17.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US"><o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"
            lang="EN-US">Regards,<br>
            <br>
            Martijn<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
        <div id="mail-editor-reference-message-container">
          <div>
            <div
style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
              <p class="MsoNormal" style="margin-bottom:12.0pt"><b><span
                    style="color:black">From: </span></b><span
                  style="color:black">Servercert-wg
                  <a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg-bounces@cabforum.org"><servercert-wg-bounces@cabforum.org></a> on behalf
                  of Dimitris Zacharopoulos (HARICA) via Servercert-wg
                  <a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
                  <b>Date: </b>Tuesday, 14 May 2024 at 11:33<br>
                  <b>To: </b>CA/B Forum Server Certificate WG Public
                  Discussion List <a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
                  <b>Subject: </b>[Servercert-wg] Discussion about
                  single-purpose client authentication leaf certificates
                  issued from a server TLS Issuing CA<o:p></o:p></span></p>
            </div>
            <div
style="border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt">
              <p class="MsoNormal"
                style="line-height:12.0pt;background:#FAFA03"><span
style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:black">CAUTION:
                  This email originated from outside of the
                  organization. Do not click links or open attachments
                  unless you recognize the sender and know the content
                  is safe.<o:p></o:p></span></p>
            </div>
            <p class="MsoNormal"><o:p> </o:p></p>
            <div>
              <p class="MsoNormal">Dear Members,<br>
                <br>
                Following-up on an interesting <a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1886467%23c11&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ccc5e5bc3c5844518497708dc73f8f6c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512760354862106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WphkYw9Fbr%2FL0dqrFc83nBZLcYw2t7edPk3xMtDIz5Y%3D&reserved=0"
                  moz-do-not-send="true">public incident</a>, I would
                like to have a discussion about the scope of the TLS BRs
                as specified in the SCWG Charter and in the actual TLS
                BRs, especially when it comes to single-purpose "client
                authentication" certificates (i.e. leaf certificates
                that include the <i>id-kp-clientAuth</i> and DO NOT
                include the<i> id-kp-serverAuth</i> KeyPurposeId in
                their extKeyUsage extension).<o:p></o:p></p>
              <p>The TLS BRs describe the profiles of Subordinate CA
                Certificates issued from a Root that is in-scope for
                server TLS authentication, even for the case of
                Technically-Constrained non-TLS CA Certificates. There
                was a lot of discussion about whether this is permitted
                based on the SCWG Charter and there was consensus that
                Browsers want to make sure that there are some minimum
                expectations about the structure of such non-TLS CA
                certificates, especially the adherence to RFC 5280. I
                recall that there was also consensus that whatever is
                issued off of these TC non-TLS CAs is not in scope of
                the TLS BRs.<o:p></o:p></p>
              <p><u>Does this seem like a fair statement about intent of
                  the group on the expectations of TC non-TLS CAs and
                  their leaf certificates?</u><o:p></o:p></p>
              <p>Technically Constrained non-TLS Issuing CAs have a
                defined profile in the TLS BRs but IMO it cannot, and
                should not mandate the profile of non-TLS leaf
                certificates based on the <a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fworking-groups%2Fserver%2Fcharter%2F&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ccc5e5bc3c5844518497708dc73f8f6c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512760354875906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EE7jB9F8aXgkXT8pAgZExAJsuhFDwBQ%2FEmQP%2BpVxBrc%3D&reserved=0"
                  moz-do-not-send="true">CA/Browser Forum Server
                  Certificate Working Group Charter</a> which states
                (emphasis mine):<o:p></o:p></p>
              <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
                <p class="MsoNormal"><i>(a) To specify Baseline
                    Requirements, Extended Validation Guidelines, and
                    other acceptable practices for the issuance and
                    management of <b>TLS server certificates used for
                      authenticating servers accessible through the
                      Internet</b></i><o:p></o:p></p>
              </blockquote>
              <p>It gets more interesting when an Issuing CA that is
                technically capable of issuing server authentication TLS
                Certificates (by including the<i> id-kp-serverAuth</i>
                KeyPurposeId in its extKeyUsage extension), also
                includes the <i>id-kp-clientAuth</i> KeyPurposeId, thus
                being technically capable of issuing client
                authentication TLS Certificates.<o:p></o:p></p>
              <p>Please recall that a few years back multi-purpose
                Issuing CAs existed, where the EKU was not present, and
                even if it was, it allowed the inclusion of various
                KeyPurposeIds.<o:p></o:p></p>
              <p>Is it ok for such an Issuing CA to create a
                single-purpose client authentication TLS Certificate,
                one that is structured according to RFC 5280 (thus can
                be successfully parsed by Relying Party RFC
                5280-conformant software), contains an extKeyUsage
                extension which contains the <i>id-kp-clientAuth</i>
                and DOES NOT include the <i>id-kp-serverAuth</i>
                KeyPurposeId?<o:p></o:p></p>
              <p>My understanding is that these particular leaf
                certificates are allowed to be issued by a server TLS
                capable CA and they are considered out-of-scope of the
                BRs, in the sense that <b>they are not TLS Server
                  Certificates</b>. The SCWG has accepted this "risk"
                with the client authentication certificates by allowing
                the co-existence of <i>id-kp-clientAuth</i> and<i>
                  id-kp-serverAuth </i>KeyPurposeIds and the explicit
                dis-allowance of <i>id-kp-emailProtection,
                  id-kp-codeSigning, id-kp-timeStamping,
                  anyExtendedKeyUsage</i> in the CA Certificate
                profiles.<o:p></o:p></p>
              <p>The first paragraph of the TLS BRs (section 1.1)
                states:<o:p></o:p></p>
              <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
                <p class="MsoNormal"><i>.....for the issuance and
                    management of Publicly-Trusted TLS Server
                    Certificates;</i><o:p></o:p></p>
              </blockquote>
              <p class="MsoNormal" style="margin-bottom:12.0pt">Provided
                these certificates follow RFC 5280 and can be properly
                parsed, Browsers should never consider such certificates
                server TLS certificates. They are by design "technically
                constrained".<br>
                <br>
                Thoughts? Disagreements? I know that Apple has already
                publicly <a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1886467%23c13&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ccc5e5bc3c5844518497708dc73f8f6c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512760354884136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QWqJjIw8XcHlSKQ17G9764glFPOvtujhS%2BwOtvMSuG4%3D&reserved=0"
                  moz-do-not-send="true">shared an opinion</a> on this
                matter so I'm hoping to get more feedback from Members
                here :)<br>
                <br>
                <br>
                Thanks,<br>
                Dimitris.<br>
                <br>
                <o:p></o:p></p>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>