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

[Dimitris Zacharopoulos (HARICA)]

On 15/5/2024 9:21 π.μ., Roman Fischer wrote:
>
> Hi Dimitris,
>
> I was thinking more along the line: What if we had TLS leaf 
> certificates with e.g. the country field missing. Such a cert would 
> not comply to the TLS BR and since the ICA signed such a non-complying 
> cert, it would need to be revoked too… Which IMHO makes no sense at 
> all. 😊
>

Indeed, it doesn't :)

> Rgds
> Roman
>
> *From:*Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf 
> Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg
> *Sent:* Mittwoch, 15. Mai 2024 07:20
> *To:* servercert-wg at cabforum.org
> *Subject:* Re: [Servercert-wg] Discussion about single-purpose client 
> authentication leaf certificates issued from a server TLS Issuing CA
>
> On 15/5/2024 7:35 π.μ., Roman Fischer via Servercert-wg wrote:
>
>     Dear Aaron,
>
>     Interesting line of argumentation. Wouldn’t that conclude that
>     -every- mis-issuance of a leaf certificate would be a violation of
>     "all certificates that it issues MUST comply with one of the
>     following certificate profiles" and thus would require the ICA to
>     be revoked? That can’t be the intent of the regulation, right?
>
>
> Roman,
>
> TC non-TLS subCAs already have a defined certificate profile described 
> in the BRs so there is no need to revoke such an ICA. I think you 
> might be referring to non-TLS Subscriber Certificates issued by those 
> TC non-TLS SubCAs?
>
>
> Dimitris.
>
>
>     Rgds
>     Roman
>
>     *From:*Servercert-wg <servercert-wg-bounces at cabforum.org>
>     <mailto:servercert-wg-bounces at cabforum.org> *On Behalf Of *Aaron
>     Gable via Servercert-wg
>     *Sent:* Dienstag, 14. Mai 2024 16:59
>     *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
>     <mailto:dzacharo at harica.gr>; CA/B Forum Server Certificate WG
>     Public Discussion List <servercert-wg at cabforum.org>
>     <mailto:servercert-wg at cabforum.org>
>     *Subject:* Re: [Servercert-wg] Discussion about single-purpose
>     client authentication leaf certificates issued from a server TLS
>     Issuing CA
>
>     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
>
>
>
>     _______________________________________________
>
>     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/20240515/7bd9bbd0/attachment.html>