<div dir="ltr"># Attendees <br><br>* Amanda Mendieta<br>* Aneta Wojczak<br>* Ben Wilson<br>* Bruce Morton<br>* Clint Wilson<br>* Corey Bonnell<br>* Dean Coclin<br>* Dimitris Zacharopoulus<br>* Inigo Barriera<br>* Janet Hines<br>* Kati Davids<br>* Niko Carpenter<br>* Paul van Brouwershaven<br>* Rebecca Kelley<br>* Ryan Sleevi<br>* Shelley Brewer<br>* Tim Hollebeek<br>* Trevoli Ponds-White<br>* Tyler Myers<br>* Wayne Thayer<br>* Wendy Brown<br><br># Agenda<br><br>* Reading of the Antitrust Statement by Tim<br>* Update from the Infrastructure WG for Github comment reflection<br>* Technically Constrained Sub-CA Profiles and Scope<br><br>## Github Comment Reflection<br><br>Tim asked for an update. Ryan shared that the Infrastructure group is not actively working on this, as it's waiting for someone to do the work. The current proposal wasn't to reflect every single comment to the list, but rather, weekly summaries of activity happening on GitHub. Based on Tim's description, Ryan wasn't sure if the proposal would address what Tim was wanting, so it would make sense to join the next infrastructure call or send to the infrastructure list what his desired reflection would be.<br><br>## Technically Constrained Sub-CA Profiles and Scope<br><br>Ryan summarized the discussion from the list, which was related to understanding the current requirements for technically constrained sub-CAs, and how the profiles work presently attempts to reflect this. The core question is if you have a CA subjected to the BRs, such as a Root CA, what are the rules for the certificates that are issued by that Root. Are there rules for all certificates that are issued, or do some certificates have no rules, provided certain criteria are met? The particular example was with nameConstraints, and whether there are syntactical rules for what you place in that extension, and are there validation rules for what you place in that extension. The discussion was how to interpret the current requirements, and whether the profiles work was imposing new restrictions, or if these are current, existing requirements, being made clearer?<br><br>Tim said that we also have to determine whether it recursively applies throughout the hierarchy, once we solve the first question about certificates the CA issues. Ryan suggested that we hold that discussion for now; we will eventually want to return to it, but we should focus on non-TLS CA issuance from a TLS-capable CA first. Another variation is a non-TLS leaf certificate from a TLS sub-CA. Those are a bit simpler, because these are both TLS CAs doing the issuance, and what are the rules for the TLS CA.<br><br>Tim agreed that this is a complicated topic, particularly around the borders for EKUs. When a CA is in scope, it seems that what it signs is also in scope, and figuring out how to express what it can sign while being careful about the contents/formats of the certificates it signs.<br><br>Ryan didn't see the difference here between what a CA can sign and the contents. One approach would be to say a "TLS CA" cannot issue non-TLS certificates, but that would likely make several existing CAs unhappy, if they have sub-CAs with TLS and emailProtection, as they'd no longer be able to issue e-mail certificates. It's a path that can be taken, but the downside is it doesn't give existing CAs many options. Unless we want to sunset TLS sub-CAs issuing non-TLS sub-CAs, which is an appealing endstate but perhaps too early now, then it seems we need to set some rules about the contents of the certificates to make the rules clearer.<br><br>Tim agreed, we should provide clarity here. The profiles are meant to express the current requirements, and some of the current requirements are legitimately unclear, and so some of this may be differences in opinion in the current language, and how best to capture that in a clearer way. Tim mentioned he had been discussing with Corey about whether or not it's a goal to allow completely malformed certificates to be issued from in-scope ICAs, and it seems unclear whether the BRs presently disallow it. However, this is something that shouldn't be happening today, and so it may make sense to explicitly forbid it.<br><br>Dimitris said that once an issuing CA is out of scope of the BRs, there are no rules the BRs can place on these CAs. You would not be able to define what misissuance is for these non-in-scope CAs. Dimitris agreed with Ryan that the scope is with the issuer, and thus if an issuer is in scope, the BRs can define what can be signed and prevent garbage. He believed they're largely in agreement with following 7.1.2.2 for issuing non-TLS sub-CAs from a TLS CA. Ryan gave an example of a TLS CA issuing a non-TLS certificate. Under 7.1.2.3, it would be misissuance if it was, for example, codeSigning, but would not be if it was a certificate for emailProtection, which is currently allowed. We need to clarify what we have in the existing rules, and potentially impose new requirements that provide clearer guidance.<br><br>Corey agreed in general with Dimitris on 7.1.2.2 being a reasonable place for non-TLS CAs from a TLS CA. However, there are concerns with how the requirements are written, such as Section 7.1.6.3, which as currently worded apply to all subordinate CAs and require a CA/Browser Forum policy OID, which doesn't make sense for a non-TLS CA. The BRs are not worded well to address these scenarios. Dimitris agreed, and that the profiles work can flush this out and see any incompatibilities with CAs.<br><br>Ryan stated that the question of scope has been discussed for years, going back to Peter Bowen and Gervase Markham and trying to make the scope more explicit for the BRs. How sections like 1.1, 8.1, and 7.1.6.3 all work together for the BRs. The goal of the profiles work is to try to provide clarity for all of this. If we can identify the certificate profiles, the ideal end result is to say that a given CA can sign this, this, and this profile, a CRL, and an OCSP response, and nothing else. One area to still be nailed down is precertificates, but Ryan was holding off on that work based on this discussion about scope. Ryan mentioned that Dimitris highlighted an example of once a non-TLS CA exists, everything beneath it is out of scope. Ryan disagreed that that was a clear/solved problem, but recognized it's been actively discussed for quite a while, so that's not clear. One of Ryan's goals, for the long term, is that once a CA is in scope, everything beneath that CA is in scope as well - every CA, every certificate, everything signed - as a way of reducing ambiguity. This was something other root programs have also discussed. Profiles is a first step to trying to bring clarity and identify compatibility problems with that end goal.<br><br>Ryan mentioned one of the questions with non-TLS sub CAs is what technically makes a non-TLS sub-CA. The suggestion that was advanced is a difference in EKU, even though that's only recently been supported by root programs. However, can that non-TLS sub-CA issue anything it wants in the subject? Can it issue certificates with arbitrary extensions? Can it issue certificates with all three fields in the AKI? Some of these requirements come from RFC 5280. If ETSI says RFC 5280 limits can be ignored, does that mean it's OK to ignore those limits in the subject of the non-TLS sub-CA? For nameConstraints, does it mean it's OK to issue a dNSName name constraint of "*.example,com" within the non-TLS sub-CA? Part of the conversation with Corey was about whether RFC 5280 forbids that or not, and do the BRs need language to address that?<br><br>Tim clarified and said ETSI has not said you can ignore RFC 5280, only that limits for a particular field won't be enforced. ETSI has said repeatedly if you're in scope of the BRs, you have to follow the BRs.<br><br>Ryan said that was a core question: is the subject for this non-TLS sub-CA in scope for the BRs? If so, the ETSI exception doesn't apply, and we should be clear. If not, we need to be OK with this not-5280 thing from a TLS CA.<br><br>Tim mentioned Scope had been heavily discussed in Scottsdale during the governance reform. The SCWG is not special. When we discussed roots with multiple hierarchies, we needed to make sure different WGs don't stomp on the toes of other WGs when it comes to ICAs. At one point, the discussion had been a baseline-baseline WG to discuss profiles for roots and ICAs, and rules that aren't really EKU related, rather than doing WG by WG. We'll need to figure out how to coordinate across WGs, to ensure SCWG isn't imposing requirements on other WGs. Given that we have many of the same participants, in theory we're doing that, but we need to be explicit here. And we need to be explicit about scope, which has been a longstanding problem, while also being mindful of the charters.<br><br>Wayne said his understanding of the endgame described by Ryan suggests hierarchies that won't be used for TLS and other purposes simultaneously. If you have roots that can only be used for TLS, doesn't the problem go away? Not that it would go away tomorrow, but eventually it goes away. <br><br>Tim agreed, and thinks it's completely legitimate to propose and write the requirement Ryan is talking about: to propose that TLS CAs cannot sign non-TLS CAs. He agrees with Ryan, but we're not there yet and can't write that requirement today, so what do we do in the meantime? How do we fix things we definitely don't want to happen, like signing completely invalid certificates, or Adobe PDFs, off of ICAs, which are things we don't want and most CAs wouldn't oppose, but how do we write that requirement that doesn't cause trouble for existing practice, and is this close to the existing requirement and current process?<br><br>Ryan said he was having trouble understanding Tim's position, so wanted to confirm. It sounded like Tim was saying there isn't a scope or charter prohibition on the SCWG saying a TLS CA could not issue a non-TLS/non-BR thing. There would still be compatibility issues, but it's not something the charter or scope prohibits. Tim agreed. Ryan then said that the baseline-baseline conversation Tim mentioned was in the context of multi-purpose hierarchies. Some root programs may still want to permit this, and others prohibit it. So Ryan wants to be mindful of the compatibility risks that could result while this is permitted, and the profiles work to account for it, but it doesn't seem like it's a charter or scope issue. The current goal is to safely address this while minimizing the compatibility issues, while still protecting the TLS ecosystem.<br><br>Ryan said the current discussion came from the question of whether you can issue a non-TLS sub-CA with invalid characters in the nameConstraints extension. The current profiles draft tries to answer this, and says "No". If a non-TLS sub-CA is issued by a TLS CA, Profiles says its in scope. The question about what is issued from that non-TLS sub-CA hasn't been tackled yet in the profile, and the question of what it can sign is not addressed. The current work is trying to address the elements for the non-TLS CA, and said that he believes 7.1.2.4 applies to that certificate. He agreed with Dimitris's earlier approach: specify the profiles, and then determine the compatibility risks from CAs.<br><br>Tim agreed that is heading in the right direction. His thinking has evolved over time from having to deal with lots of compliance escalations and questions. He's sensitive to the browser's concerns that if it's anywhere in the hierarchy, it can pose risks. Tim was a little less sympathetic to browsers that haven't gotten around to EKU chaining, but it's still a problem to be dealt with. Tim said it's reasonable to need to address the certificates on the boundary between in-scope and out-of-scope, but believed it could be done fairly minimally, just to address the set of fields necessary to determine something is out of scope, rather than needing to address everything.<br><br>Wendy said in chat that if an approach would be that a CA does not include a TLS EKU, and does not include a CABF policy OID, then anything that CA issues should be out of scope. Ryan said that's part of the discussion about what to make it in the future, but that currently, 7.1.2.4 places it in scope.<br><br>Wendy was having audio issues with her connection, but suggested (roughly) that with those two fields, relying party applications could require the presence of both the EKU and the policy OID, such that any certificates issued after a particular date must have those fields. Relying party applications would reject those certificates, thus addressing the concern about scope.<br><br>Ryan said this goes back to the previous discussion around policy OIDs. RFC 5280 has the notion of effective policy OID as an input, and a relying party application uses that input and ensures the entire certificate chain complies with that policy. Relying party applications widely don't implement this outside of those targeting US gov't systems; Microsoft does, but popular open-source libraries don't, because they predated the standards. EKU chaining was in wide use even before the policy OID work. This is further complicated by things like policyMappings, which has a number of edge cases, and outside of the US government, is not widely used.<br><br>Dimitris said that the ongoing work makes it absolutely clear the BRs apply if the policy OID applies. Similar to the EKU. Dimitris was not sure that browsers needed to check that, but from the CA perspective, it was clear that if the EKU was present, it was in scope.<br><br>Ryan mentioned EKU chaining is hugely controversial within the IETF, and has come up again in IETF LAMPs, and isn't standardized. The current BR requirement came from Microsoft's root program requirements, which is not surprising, because Microsoft implemented EKU chaining. Some of Mozilla's NSS implementations didn't, and Apple only recently began requiring EKU chaining in iOS 13 / macOS 15 in 2019. So we can't say it's always worked this way, but we're trying to find a way forward to balance things. One of the core questions, though, is whether you can have invalid ASN.1 extensions in a non-TLS sub-CA from a Root CA? Logically, we want to say that's prohibited, but trying to figure out how to say that is what profiles is trying to address.<br><br>Dimitris said he didn't hear any arguments against requiring well-formed extensions. One question remained for how Section 7.1.5 applies, and how nameConstraints on those non-TLS sub-CAs should look.<br><br>Ryan said the profiles work tries to keep the current requirements, which he believes presently requires including exclusions. The profiles work is trying to get us to the point of getting more of these out of scope.<br><br>Tim noted that we're out of time, and it makes sense to continue to discuss on the list. It's important to make sure the work provides clarity.<br><br>Ryan asked if there were any objections to trying to tackle the problem in the sense of "what can be signed, what can't be signed", with some cutoff where we say "Everything below, there are no rules". However, for things in scope, saying that all extensions need to be well-formed and defining what well-formed is. There were no objections.<br></div>