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

[Dimitris Zacharopoulos (HARICA)]

Dear Members,

Following-up on an interesting public incident 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1886467#c11>, 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://cabforum.org/working-groups/server/charter/> 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://bugzilla.mozilla.org/show_bug.cgi?id=1886467#c13> 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/12881c46/attachment.html>