[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Fri, Oct 11, 2019 at 9:50 AM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Getting back to Ryan’s initial post that subordinate CAs are being issued
> with more than the 3 field listed in Section 7.1.4.3.1.  Is it time to
> discuss the topic with the intent (at least from the CA perspective) that
> we propose a ballot that permits additional fields such as OU, S, and L to
> permit relying parties to have a better and more detailed understanding of
> the CA entity issuing the certificates?
>
>
>
> By the way, Root program members weren’t listed in Ryan’s email and some
> of them are also at fault for not following the strict default DENY for CA
> subject DN:
>

I appreciate the enthusiasm, but unfortunately, I think you overlooked an
important detail in that analysis.

You want to look after Ballot 199 was voted in, because prior to that,
there rules were different. You can find the review notice at
https://cabforum.org/pipermail/public/2017-May/010984.html , which the
rules came into effect 2017-06-08.

This means the only violation is https://crt.sh/?id=1600419523&opt=cablint
. While this is a good example, it doesn't quite match your description of
who is responsible. This is because the "Issuer" of the certificate is the
responsible CA, not the "Subject". Sectigo is the issuer here, so this is a
Sectigo issue, not an Apple issue. Similarly, the Microsoft example you
provided is not a Microsoft issue - DigiCert issued those certificates
(even though they were totally fine and compliant, when they were issued)

That said, I really appreciate you checking the results here. I think it's
a great thing to do, because I totally make mistakes here, and the great
thing about CT is folks can point out if I've overlooked something in my
analysis. It's also a great example of how the requirements change over
time, and why it's so important for CAs to carefully examine those changes
and implications, whether they be to root program policies or to the BRs.
This is exactly what my original message was looking at: trying to
understand why some changes aren't adopted, with the seeming answer being
that "Folks are reading with Default-Allow, rather than Default-Deny", and
wanting to fix that issue at the source.

If we can get that clearer: that the BRs as a whole are Default-Deny, then
the only issues that should hopefully remain are "CAs not paying attention
to the requirements", rather than "CAs coming to different conclusions
about the expectations", and that works much better for everyone (... well,
except those ignoring the changes :P)

I think we need to formalize this in the BRs via ballot so that it’s clear
> to everyone:
>
>    1. what can go into a Subordinate CA certificate and
>    2. what can/must go into a Cross Certificate as this is different and
>    driven exclusively by the DN of the 2 roots being cross certified)
>
> There is whole hearted agreement here that we should clarify this, and any
other case, via Ballot, so that it's absolutely clear. You can see I tried
to lay out a hopefully uncontroversial plan in
https://cabforum.org/pipermail/servercert-wg/2019-October/001178.html ,
including our willingness to overlook these violations, provided we can
make forward progress here in the Forum.

It's important, however, that we don't treat this as a one-off problem,
which we can see with SC16 failing to fix the systemic issue. We should
make it clear that what isn't permitted is forbidden, and then we can make
sure that it's clear that anything that might be inadvertently forbidden is
permitted. So I think your (a) is a part of that effort - but fixing (a)
won't fix the systemic issue, and we should and need to fix that, to avoid
issues continuing to crop-up, like Curt mentioned. As I mentioned in the
above thread, if we're making progress on the systemic issue, we're totally
willing to overlook the (a) issue being highlighted here, until we can get
something comprehensive in place.

For (b), I agree that it's going to be a tricky conversation.

The language here needs to be very precise; just saying "Cross Certificate"
here opens up a lot of loopholes for interpretation, which can be used to
abuse the permissiveness and lead to the wrong result. For example, if we
just said "cross certificate", we could end up with a situation where
someone who wants to stick arbitrary stuff in certificates would first
generate a self-signed version of that certificate, with junk in the DN.
They would then rely on a loophole (such as "CAs may sign non-compliant
DNs, provided they are for the purposes of a cross-certificate" or some
sort), and issue an intermediate with that junk in it! That's just one
obvious example of how one might "abuse" (if malicious) or "misinterpret"
(if benign) attempts at a carve-out.

There's a broader question hidden here about whether such
cross-certificates are necessarily good for the ecosystem, especially when
they effectively hinder the promotion of a reasonable profile for
intermediates and roots. It admittedly does make it easier for CA
operators, because it means as few changes to their systems and past
operating practices, but it's not clear that such a lack of agility is good
for users or the ecosystem.

I think there's a totally reasonable middle ground here, to make sure we
don't get lost in the weeds here or have to hash that stuff out now. For
example, I can totally see a path where, instead of wholesale forbidding
such cross-certificates, we instead allowing cross-certificates to be
issued with non-compliant DNs, but only if they meet certain conditions
(e.g. if the validity period is 3 years or less, and only if issued within
the next two years). That would give us two years to discuss the tradeoffs
and determine whether to permanently enshrine it, or to encourage
alternative practices, and makes it so that if things need to change, they
might be reasonably implementable by clients in 2025, quite some time away.

This sort of natural sunset is a good example of applying a strategy of
"why". I don't think this approach is dispositive towards the result: after
all, I think it's totally valid that the answer may be "This is good and we
should permanently allow it" - rather than having to worry about taking it
out later. It also allows for the possibility of "We're still discussing
this, we're making good progress but it's tricky, let's allow it for
another year while we work out the details". This sort of approach helps
make sure we're all making progress, and constantly asking the right
question: "Why". But it also makes sure that we're able to make progress on
this, and have the discussion that's needed to get to the conclusion;
punting the discussion, but not indefinitely so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191011/d22eae1c/attachment.html>