On 14/5/2024 12:53 μ.μ., Martijn Katerbarg wrote:
>Thoughts? Disagreements? I know that Apple has already publiclyshared
an opinion
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1886467%23c13&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ccc5e5bc3c5844518497708dc73f8f6c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512760354884136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QWqJjIw8XcHlSKQ17G9764glFPOvtujhS%2BwOtvMSuG4%3D&reserved=0>on
this matter so I'm hoping to get more feedback from Members here :)
I do agree with the quoted statement.
Are you referring to /your/ quoted statement? I had two quotes in my
first email of the thread :-)
If compliance is asserted by the inclusion of a Policy OID, it would
come into scope. If not, then indeed it would seem, it’s not in scope.
I already answered that in
https://lists.cabforum.org/pipermail/servercert-wg/2024-May/004575.html
(apologies for starting the responses in reverse order).
To me this mainly raises the question: What is a CA allowed to do with
a SubCA Private Key. Section 6.1.7 states what a private key
corresponding to a Root Certificate may be used for. Do we need
something similar for private keys corresponding to Subordinate CAs?
Such a requirement could then indicate which type of objects may be
signed (such as CRLs, OCSP responses, TLS certs, precerts. Since the
requirements are related to TLS Certificates, in my opinion it would
be in scope to say that a Subordinate CA capable of issuing TLS
Certificates, may or may not issue clientAuth-only certificates, and
if so, according to which profile.
This is an interesting idea, I wouldn't object to it as long as we reach
consensus about the intent related to client authentication -and other
non-server-TLS, non-codeSigning, non-timeStamping, non-emailProtection-
leaf certificates.
Thanks,
Dimitris.
Regards,
Martijn
*From: *Servercert-wg <[email protected]> on behalf
of Dimitris Zacharopoulos (HARICA) via Servercert-wg
<[email protected]>
*Date: *Tuesday, 14 May 2024 at 11:33
*To: *CA/B Forum Server Certificate WG Public Discussion List
<[email protected]>
*Subject: *[Servercert-wg] Discussion about single-purpose client
authentication leaf certificates issued from a server TLS Issuing CA
CAUTION: This email originated from outside of the organization. Do
not click links or open attachments unless you recognize the sender
and know the content is safe.
Dear Members,
Following-up on an interesting public incident
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1886467%23c11&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ccc5e5bc3c5844518497708dc73f8f6c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512760354862106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WphkYw9Fbr%2FL0dqrFc83nBZLcYw2t7edPk3xMtDIz5Y%3D&reserved=0>,
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fworking-groups%2Fserver%2Fcharter%2F&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ccc5e5bc3c5844518497708dc73f8f6c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512760354875906%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EE7jB9F8aXgkXT8pAgZExAJsuhFDwBQ%2FEmQP%2BpVxBrc%3D&reserved=0>
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1886467%23c13&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ccc5e5bc3c5844518497708dc73f8f6c9%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512760354884136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QWqJjIw8XcHlSKQ17G9764glFPOvtujhS%2BwOtvMSuG4%3D&reserved=0>
on this matter so I'm hoping to get more feedback from Members here :)
Thanks,
Dimitris.
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
