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

[Adriano Santoni]

I would agree to consider out-of-scope (of the BRs) a leaf certificate 
with EKU=clientAuth issued by a SubCA that has EKU={server,client}, 
provided of course the leaf certificate does not assert a BR TLS policy 
OID because this would be contradictory.

Besides, at least one widely used linter considers a certificate 
in-scope if it contains EKU=serverAuth and/or it contains a BR policy 
OID, which seems quite logical to me.

Adriano


Il 14/05/2024 11:33, Dimitris Zacharopoulos (HARICA) via Servercert-wg 
ha scritto:
> NOTICE: Pay attention - external email - Sender is 
> 0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000000 at amazonses.com 
>
>
>
>
> 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.
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240514/f92f9dbb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240514/f92f9dbb/attachment.p7s>