[Servercert-wg] Removing the exception to allow non-critical name constraints

[Ryan Sleevi]

On Thu, Oct 17, 2019 at 7:39 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> Ryan,
>
> I think you should also consider
> https://crt.sh/mozilla-disclosures#disclosedbutconstrained which is a
> significantly larger set.
>

Thanks, Dimitris. You're right that I should have acknowledged that as well
(i.e. technically constrained sub-CAs in CCADB).

Part of the reason I did not is that the majority of that list is non-TLS
issuance; that is, e-mail, document signing, code signing, and
timestamping. The actual number is less than 125, and of those issued in
2019, something like 20.


> We should be careful with this change because it could impact legacy
> systems that don't support name constraints and would break compatibility.
> This is one of those things that will definitely break compatibility.
>

While I appreciate the caution, I want to highlight that there's nothing
actionable here, and so it's not a productive suggestion. The entire
purpose of this discussion is to move from something ambiguous, subjective,
and simultaneously valid and invalid, into something that is clear,
predictable, and consistent.

My original message highlighted the systems we identified that were
relevant for nameConstraints. The precise point of nameConstraints being
critical is to /break compatibility/ - because it means on systems that do
not support nameConstraints, they are unconstrained, which is not in line
with expectations. However, our BRs are clear that what is relevant is the
"Application Software Suppliers whose software is used by a substantial
portion of Relying Parties worldwide". I can understand that there may be
systems who are not up to date, but that doesn't mean that such a reason is
permitted, today, under the BRs.

I think it's important to resolve this, because it's presently subjective,
and it's questionable about whether it is /presently/ permitted. That is,
CAs issuing with non-critical nameConstraints are, arguably, today in
violation of the BRs, as I showed with the relevant data.

So the important piece is that, if we think this is valuable, we should
make a data-driven decision why and how. If CAs feel that it's valuable,
sharing the data that they use to demonstrate to their auditors compliance
with the Baseline Requirements, today, is useful, because that helps build
a clear picture about the decision making criteria. If browsers feel that
it's valuable, then sharing data about when, why, or how long, is similarly
useful. For example, Apple has famously, since 2011, supported their
devices for at least seven years from manufacture, continuing to provide
new OS versions for those devices. While it's true that updating to new OS
versions would resolve any issues for these clients, I can totally
understand and appreciate a recalcitrance to introduce a change that might
break these out-of-date devices. In that mindset, supporting things until
2022 might make sense - and it'd be clear, objective, data-driven decision.

On the other hand, I can totally appreciate a view that says that, because
these devices are out of date and not getting updates, Apple couldn't
respond (effectively) to any misissuance from these nameConstrained CAs,
and thus it's important to ensure these old devices are protected, by
ensuring nameConstraints are made critical.

And, to be clear, this isn't "just" an Apple problem, and I'm neither
trying to speak for them nor pick on them. They are simply an Application
Software Supplier whose software is used by a substantial portion of
Relying Parties worldwide. OpenSSL 0.9.8 similarly didn't support
nameConstraints, and when we adopted the ballot in 2012, the 0.9.8 branch
was still supported and receiving security updates.

So I want to make sure that we move the discussion forward productively,
into something that's clear and objective, and we know why. All of that
seems substantially better, particularly for CAs, than either indefinitely
supporting it or leaving it defined in such a way that a CA may be found
non-compliant by their Auditors and their Root Programs for something they
believed was acceptable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191017/2bfbf725/attachment.html>