<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
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;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=en-SE link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language: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."><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 lang=SV style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'>I do agree with the quoted statement. 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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language: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?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language: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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;mso-fareast-language: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 <servercert-wg-bounces@cabforum.org> on behalf of Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg@cabforum.org><br><b>Date: </b>Tuesday, 14 May 2024 at 11:33<br><b>To: </b>CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><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">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">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">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></body></html>