[Servercert-wg] Discussion about single-purpose client authentication leaf certificates issued from a server TLS Issuing CA

Tue May 14 15:59:30 UTC 2024

On 14/5/2024 12:53 μ.μ., Martijn Katerbarg wrote:
>
> >Thoughts? Disagreements? I know that Apple has already publiclyshared 
> an opinion 
> <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>on 
> this matter so I'm hoping to get more feedback from Members here :)
>
> I do agree with the quoted statement.
>

Are you referring to /your/ quoted statement? I had two quotes in my 
first email of the thread :-)

> 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.
>

I already answered that in 
https://lists.cabforum.org/pipermail/servercert-wg/2024-May/004575.html 
(apologies for starting the responses in reverse order).
>
> 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?
>

> 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.
>

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.

Thanks,
Dimitris.
>
> Regards,
>
> Martijn
>
> *From: *Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf 
> of Dimitris Zacharopoulos (HARICA) via Servercert-wg 
> <servercert-wg at cabforum.org>
> *Date: *Tuesday, 14 May 2024 at 11:33
> *To: *CA/B Forum Server Certificate WG Public Discussion List 
> <servercert-wg at cabforum.org>
> *Subject: *[Servercert-wg] Discussion about single-purpose client 
> authentication leaf certificates issued from a server TLS Issuing CA
>
> 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.
>
> Dear Members,
>
> Following-up on an interesting public incident 
> <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>, 
> 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 /id-kp-clientAuth/ and DO NOT 
> include the/id-kp-serverAuth/ KeyPurposeId in their extKeyUsage 
> extension).
>
> 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.
>
> _Does this seem like a fair statement about intent of the group on the 
> expectations of TC non-TLS CAs and their leaf certificates?_
>
> 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 CA/Browser Forum Server 
> Certificate Working Group Charter 
> <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> 
> which states (emphasis mine):
>
>     /(a) To specify Baseline Requirements, Extended Validation
>     Guidelines, and other acceptable practices for the issuance and
>     management of *TLS server certificates used for authenticating
>     servers accessible through the Internet*/
>
> It gets more interesting when an Issuing CA that is technically 
> capable of issuing server authentication TLS Certificates (by 
> including the/id-kp-serverAuth/ KeyPurposeId in its extKeyUsage 
> extension), also includes the /id-kp-clientAuth/ KeyPurposeId, thus 
> being technically capable of issuing client authentication TLS 
> Certificates.
>
> 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.
>
> 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 /id-kp-clientAuth/ and DOES NOT include the 
> /id-kp-serverAuth/ KeyPurposeId?
>
> 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 *they are not 
> TLS Server Certificates*. The SCWG has accepted this "risk" with the 
> client authentication certificates by allowing the co-existence of 
> /id-kp-clientAuth/ and/id-kp-serverAuth /KeyPurposeIds and the 
> explicit dis-allowance of /id-kp-emailProtection, id-kp-codeSigning, 
> id-kp-timeStamping, anyExtendedKeyUsage/ in the CA Certificate profiles.
>
> The first paragraph of the TLS BRs (section 1.1) states:
>
>     /.....for the issuance and management of Publicly-Trusted TLS
>     Server Certificates;/
>
> 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".
>
> Thoughts? Disagreements? I know that Apple has already publicly shared 
> an opinion 
> <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> 
> on this matter so I'm hoping to get more feedback from Members here :)
>
>
> Thanks,
> Dimitris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240514/8c875f63/attachment.html>