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@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
