[cabf_validation] Draft Minutes of the Validation Subcommittee - September 9, 2021

[Ryan Sleevi]

# Attendees

* Amanda Mendieta
* Aneta Wojczak
* Ben Wilson
* Bruce Morton
* Clint Wilson
* Corey Bonnell
* Dean Coclin
* Dimitris Zacharopoulus
* Inigo Barriera
* Janet Hines
* Kati Davids
* Niko Carpenter
* Paul van Brouwershaven
* Rebecca Kelley
* Ryan Sleevi
* Shelley Brewer
* Tim Hollebeek
* Trevoli Ponds-White
* Tyler Myers
* Wayne Thayer
* Wendy Brown

# Agenda

* Reading of the Antitrust Statement by Tim
* Update from the Infrastructure WG for Github comment reflection
* Technically Constrained Sub-CA Profiles and Scope

## Github Comment Reflection

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.

## Technically Constrained Sub-CA Profiles and Scope

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?

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210923/65283e79/attachment-0001.html>