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 <servercert-wg@cabforum.org> 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). 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 >>> <mailto: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 >>> Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org> >>> https://lists.cabforum.org/mailman/listinfo/servercert-wg >> >> >> _______________________________________________ >> Servercert-wg mailing list >> Servercert-wg@cabforum.org <mailto:Servercert-wg@cabforum.org> >> https://lists.cabforum.org/mailman/listinfo/servercert-wg > > _______________________________________________ > Servercert-wg mailing list > Servercert-wg@cabforum.org > https://lists.cabforum.org/mailman/listinfo/servercert-wg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg