<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 14/5/2024 7:52 μ.μ., Aaron Gable
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEmnEreYZkUmMwBU9zNB=CYp=BEn-_TN_ej+s0=U7rk6u1An4A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">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.</div>
</blockquote>
<br>
While I agree that this sounds reasonable to clarify and ensure it
is applicable unambiguously, to the best of my recollection, the
intent of this group when drafting the profiles ballot was not what
you describe. I'd be happy to be shown otherwise. I do recall Tim
Hollebeek strongly objecting to adding requirements for non-TLS
Certificates.<br>
<br>
The current BRs do not require strict server TLS hierarchies, that
was never the intent. If that was the case, it would not be allowed
to create TC non-TLS Intermediates from a Root that is in-scope of
the TLS BRs.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEreYZkUmMwBU9zNB=CYp=BEn-_TN_ej+s0=U7rk6u1An4A@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
</div>
</blockquote>
<br>
<br>
The badly formed cert issue should definitely be addressed, just
like it has been addressed for the TC non-TLS subCA profile. At a
minimum it must conform to RFC 5280. But just as we had
multi-purpose hierarchies, and we support non-TLS subCAs, maybe we
should add similar language to cover the case of non-TLS leaf
certificates.<br>
<br>
However, if the group wants to proceed with "clarifying"* that CA
Certificates technically capable of issuing server TLS Certificates
SHALL NOT issue end-entity Certificates that do not include the
serverAuth EKU, I'm all for it. I still don't see the harm in doing
so from a RP security perspective but I won't object to clear and
unambiguous rules that all CAs and auditors interpret the same way.<br>
<br>
I'm not sure if this issue deserves some dedicated time for
discussion at the upcoming F2F but Inigo could add it as an agenda
item. At the very least we should capture the group's preference and
proceed accordingly.<br>
<br>
Dimitris.<br>
<br>
<br>
* "Clarifying" has been used before as a way of adding new
requirements.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEreYZkUmMwBU9zNB=CYp=BEn-_TN_ej+s0=U7rk6u1An4A@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Aaron</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, May 14, 2024 at
8:49 AM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true"
class="moz-txt-link-freetext">dzacharo@harica.gr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <br>
<br>
<div>On 14/5/2024 5:58 μ.μ., Aaron Gable wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On Tue, May 14,
2024, 02:33 Dimitris Zacharopoulos (HARICA) via
Servercert-wg <<a
href="mailto:servercert-wg@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <o:p>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 <o:i>id-kp-clientAuth and
DOES NOT include the <o:i>id-kp-serverAuth
KeyPurposeId?</o:i></o:i></o:p> </div>
</blockquote>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Speaking in a personal capacity, it is
my opinion that no, such issuance is not acceptable.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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".</div>
<div dir="auto"><br>
</div>
<div dir="auto">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".</div>
<div dir="auto"><br>
</div>
<div dir="auto">Aaron</div>
<div class="gmail_quote" dir="auto">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
</div>
</div>
</blockquote>
<br>
Thanks Aaron, I tried to first establish the <i>intent</i>
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.<br>
<br>
Dimitris.<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>