Hi Dimitris, I guess I’m confused about how this is relevant to the scope of the CA/BF as it seems quite orthogonal to the questions you posed initially. Regardless of how clients check certificates, the question is about the issuance of a certificate. As a side-note, the question that comes to mind for me is what would be the reason to allow issuance of clientAuth-only certificates by a subCA that also issues TBR-compliant TLS certificates? Why is such a thing necessary or valuable? Regardless of the conclusion to the questions you posed, I’m failing to see why we would want any other outcome than to have subCAs which issue TBR-compliant TLS certificate always and only issue TBR-compliant TLS certificates. Perhaps if you could help me understand the motivations behind seeking clarity on this, I would be better able to understand how/why these questions have been posed (even if those motivations are simple idle curiosity, that would still help).
However, leaving aside that there’s likely some level of ignorance on my part, to the extent I understand it, the question at hand is essentially: Is it compliant for a CA, that wants to be considered compliant with the TBRs, to issue a certificate which asserts compliance with the TBRs — by way of including an OID under the CA/BF OID arc defined to represent a certificate’s compliance with the Policy document associated with that OID — where the issued certificate does not match one of the profiles defined in Section 7.1 of the TBRs? Breaking this apart, there are several aspects to consider. First, does the CA want to be considered compliant with the TBRs? If not, then it doesn’t matter which TBR OIDs they assert because they’re not intending to be considered compliant. If the CA doesn’t have a relying party they’re expecting to rely on their assertions in general, then the rest of the question is relatively moot; on the other hand, if the CA’s assertions are intended to be accurate and treated as such, then it’s a pretty important foundational point I think. For the purposes of this discussion, I’m assuming the CA does want to be considered compliant with the TBRs because if that’s not the case then the conclusions to the rest of this don’t really matter. Second, are TBR OIDs defined by their node owner as representing compliance with the TLS Baseline Requirements? Based on what’s documented in https://cabforum.org/resources/object-registry/, I believe this is clearly the case. For example, issuing a certificate with the 2.23.140.1.2.2 OID is a representation that the “Certificate [was] issued in compliance with the TLS Baseline Requirements – Organization identity asserted”. Maybe this should be brought into 7.1.6.1 of the TBRs, but I don’t think that’s necessary to come to a conclusion here. Third, does inclusion of a TBR OID in a certificate issued by such a CA constitute that CA asserting that certificate’s compliance with the TBRs? Combined with the fact that the OID itself defines this to be the case, my reading of Section 4.2.1.4 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.4> of RFC 5280[1] is that if a Policy OID is present in a certificate — or any certificate subordinate to a certificate in which it’s present — then the certificate has been issued under the Policy document represented by that OID. Fourth, does a certificate which meets the above conditions (i.e. wants to be considered compliant, includes a TBR OID), need to match one of the profiles in the TBRs? Section 7.1 announces quite clearly that "the CA SHALL issue Certificates in accordance with the profile specified in these Requirements” and further reinforces in Section 7.1.2 that (emphasis mine) "If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles”. There are possible problematic interpretations of this, but I find it difficult to grasp a truly good-faith reading of this as meaning anything other than “Yes, a certificate which includes a TBR OID is asserting compliance with the TBRs and thus, the certificate itself must comply with one of the certificate profiles defined in the TBRs.” That doesn’t mean there’s not room to improve the language, especially in 7.1.2 (which I’ve highlighted before in Issue 495 (https://github.com/cabforum/servercert/issues/495)). I personally also think the statements in 7.1 and 7.1.2 go quite a bit further than just this constrained example of a certificate which explicitly indicates its own compliance with the TBRs, but to keep the discussion focused I’m only opining on that specific scenario. Fifth, does the certificate match one of the profiles defined in Section 7.1 of the TBRs? Here we have to look at the certificate in question, with a couple components quickly narrowing our search within Section 7.1. In your first email, you indicated the question is about a leaf certificate, so all the profiles where basicConstraints:cA=TRUE can be discarded (7.1.2.1 - 7.1.2.6). Next you indicated that the certificate in question does not include the serverAuth EKU, so we can discard all profiles where the extendedKeyUsage extension requires inclusion of the serverAuth value (7.1.2.7 and 7.1.2.9). Finally, you indicated that the certificate in question does include the clientAuth EKU, so we can discard any remaining profile that doesn’t allow the clientAuth EKU (7.1.2.8). This brings us to the end of the list of 9 certificate profiles defined in the TBRs today without finding any that match the certificate described. Based on this sequence of assessment, I’m personally led to the conclusion that such a certificate is indeed not compliant. Please let me know where I’ve misunderstood your question or arrived at incorrect conclusions so I can better understand the model you’re describing. Thanks very much! -Clint [1] - The specific text of 5280 is: In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. In a CA certificate, these policy information terms limit the set of policies for certification paths that include this certificate. > On May 15, 2024, at 11:56 AM, Dimitris Zacharopoulos (HARICA) > <dzach...@harica.gr> wrote: > > > > 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 <servercert-wg@cabforum.org> >>> <mailto: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). > > 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 >>>>> >>>>> <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 <mailto: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
