On 15/5/2024 7:27 μ.μ., Clint Wilson wrote:
Apologies if I’m replying to the wrong thread, but I wanted to comment
on one point here.
On May 14, 2024, at 8:54 AM, Dimitris Zacharopoulos (HARICA) via
Servercert-wg <[email protected]> wrote:
On 14/5/2024 1:27 μ.μ., Adriano Santoni via Servercert-wg wrote:
I would agree to consider out-of-scope (of the BRs) a leaf
certificate with EKU=clientAuth issued by a SubCA that has
EKU={server,client}, provided of course the leaf certificate does
not assert a BR TLS policy OID because this would be contradictory.
Besides, at least one widely used linter considers a certificate
in-scope if it contains EKU=serverAuth and/or it contains a BR
policy OID, which seems quite logical to me.
Adriano
I think the policy OID is effectively completely ignored (along with
anything in the subject of the certificate or other extensions)
because the certificate is by design "incompatible for server TLS",
so it is discarded by server TLS consumers which are conformant with
RFC 5280.
I don’t think it’s entirely germane whether or not the policy OID is
discarded by an application; the inclusion of the policy OID itself is
a violation of RFC 5280 by the CA (if it’s included in a certificate
or certificate chain where the leaf certificate being validated
doesn’t comply with the policy referenced by the OID).
According to section 4.2.1.12
<https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12>of RFC
5280, a conforming implementation must use the certificate if one of the
indicated purposes of the EKU is used. In my understanding, a Browser
implementation that expects the /id-kp-serverAuth/ EKU MUST NOT trust a
certificate that does not include that EKU or the /anyExtendedKeyUsage/.
AFAIK there no similar strong requirement for the policy tree. For many
years, CAs used custom Policy OIDs to indicate conformance with a
certain standard and it was very difficult for Certificate Consumers to
work with that information to make restrictions.
I guess my point is that the EKU is checked first, and the policy OID
check comes later. Both must be ok for the certificate to be trusted.
Does that make sense?
Thanks!
-Clint
It is misleading, but it is very difficult to add requirements around
what a Certificate MUST NOT include (e.g. an existing TLS BR policy
OID). I'd prefer to clarify that these are out-of-scope of the BRs as
long as they are structured according to RFC 5280, and do not contain
EKU=serverAuth, just like we did for the TC non-TLS subCA Profile.
Dimitris.
Il 14/05/2024 11:33, Dimitris Zacharopoulos (HARICA) via
Servercert-wg ha scritto:
NOTICE: Pay attention - external email - Sender is
0100018f76738e97-739d5cad-6797-4977-b997-150e338d5740-000...@amazonses.com
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
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
