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

[Aaron Gable]

That makes sense. I guess I'm saying that the intent of "Intermediates
which are part of the WebPKI must not issue certificates which are not part
of the WebPKI" makes sense to me.

Imagine that a publicly trusted Subordinate CA issues a "certificate" which
is so badly malformed that it does not match any of the profiles allowed by
the BRs, and it's even difficult to tell which profile it may have been
intended to match before things went wrong. This feels to me like it should
be treated as a misissuance: it should not have been possible for a CA to
sign such an artifact, and the fact that it is possible merits an
investigation and incident report.

But the difference between such a malformed certificate and a certificate
which asserts clientAuth but not serverAuth is only one of degree, not one
of kind. They are both certificates which are issued by a publicly-trusted
Subordinate CA, but which do not conform to a BRs profile. If issuing a
clientAuth-only cert should be okay, but issuing a badly malformed cert
should not be, where and how does one draw the line between them?

Aaron

On Tue, May 14, 2024 at 8:49 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 14/5/2024 5:58 μ.μ., Aaron Gable wrote:
>
> On Tue, May 14, 2024, 02:33 Dimitris Zacharopoulos (HARICA) via
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
>> 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?
>>
>
> Speaking in a personal capacity, it is my opinion that no, such issuance
> is not acceptable.
>
> I agree that the resulting end-entity client-auth-only certificate is out
> of scope of the BRs, and is not in and of itself misissued. However, the
> issuing intermediate itself is still in scope of the BRs, and its behavior
> can be contained by them. By virtue of issuing the clientAuth cert, the
> issuing intermediate has violated the BRs requirement that "all
> certificates that it issues MUST comply with one of the following
> certificate profiles".
>
> One could even argue that, having issued a certificate which does not
> comply with a BR profile, the issuing intermediate must be revoked within 7
> days, per BRs Section 4.9.1.2 (5): "The Issuing CA SHALL revoke a
> Subordinate CA Certificate [if...] the Issuing CA is made aware that the...
> Subordinate CA has not complied with this document".
>
> Aaron
>
>>
> Thanks Aaron, I tried to first establish the *intent* of the group before
> digging in the actual BRs. If we agree that the intent was to place rules
> only for Server TLS leaf Certificates but not for Client TLS Certificates,
> then we need to acknowledge that, and work within the document to fix any
> conflicts.
>
> Dimitris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240514/9e7d699b/attachment-0001.html>