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

Tue May 14 15:54:40 UTC 2024

On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:
>
> 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
>
>

I think the policy OID is effectively completely ignored (along with 
anything in the subject of the certificate or other extensions) because 
the certificate is by design "incompatible for server TLS", so it is 
discarded by server TLS consumers which are conformant with RFC 5280.

It is misleading, but it is very difficult to add requirements around 
what a Certificate MUST NOT include (e.g. an existing TLS BR policy 
OID). I'd prefer to clarify that these are out-of-scope of the BRs as 
long as they are structured according to RFC 5280, and do not contain 
EKU=serverAuth, just like we did for the TC non-TLS subCA Profile.

Dimitris.

> 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
>
> _______________________________________________
> 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/9633c3a0/attachment-0001.html>