[Servercert-wg] Subject name requirements for CA Certificates

[Ryan Sleevi]

On Wed, Oct 9, 2019 at 12:27 PM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Ryan,
>
>
>
> I agree with Rob.  It’s clear that your view is not shared by everyone and
> evangelizing your view on the mail lists won’t help those that read the BRs
> as their source of truth.  We need to go through a BR update and explicitly
> state what’s permitted and what isn’t so that EVERYONE is on same page with
> interpretation and have the correct historical interpretation.  These specs
> need to stand on their own. Even those that read most of the emails on
> these lists are not all sharing the same interpretation so it’s important
> we get the rules explicitly stated in the BRs.
>
>
>
> Take the EVGL, section 9.2.9 that says: CAs SHALL NOT include any Subject
> attributes except as specified in Section 9.2.  This implies that other
> sections which list sets of fields without this statement may include other
> items not explicitly listed, else why make this statement there and nowhere
> else?
>
>
>
> Take for example the BRs, 7.1.2.1 Root CA Certificate.  It lists
> basicConstraints, keyUsage, certificatePolicies and extendedKeyUsage.  Are
> these the ONLY extensions permitted? No,
>
>
>
> Section 7.1.2.3 lists 6 extensions.  Is this the only set of extensions
> permitted in subscriber certificates?  No, certainly subjectAltName is
> permitted (mandated).  If this is permitted and not on the list, why not
> others like Netscape Certificate Type, Logo Type extension (
> https://www.ietf.org/rfc/rfc3709.txt), and more?  If the list of
> extensions needs to be limited to a set, then that NEEDS to be in the BRs.
>
>
>
> Need I continue?
>

Doug,

Thanks for the reply. The funny part is, I think most of your reply is
entirely consistent with what I said. The specs do need to stand on their
own. To suggest that there is no text to suggest things are Default-Deny is
to also accept that there is no text to support things are Default-Allow,
as you're seemingly implicitly suggesting here. I discussed this in greater
length in my reply to Rob, in
https://cabforum.org/pipermail/servercert-wg/2019-October/001169.html

When it comes to disagreements about the expectations, however, I hope
we're in agreement that CAs are expected to meet and abide by Root Program
Requirements first and foremost, and that those are the core expectation.
The Baseline Requirements do not replace nor override Root Program
expectations, and in matters of disagreement, it is ultimately at the
discretion of the Root Program to clarify. I hope we're in clear agreement
there, because if not, that's a more fundamental issue. I'm trying to
clarify that Google's expectation here is that everything that is not
explicitly permitted is denied. This is, in our view, the only
internally-consistent way to read the BRs, and the only way to read the BRs
as meeting our expectations of providing a defensible security boundary and
way to reason about CA behaviour.

To your specific examples, I appreciate you raising them, because they
highlight why viewing things as Default-Allow is problematic.

- You cited 9.2.9; I've responded to that already, in
https://cabforum.org/pipermail/servercert-wg/2019-October/001169.html ;
perhaps you'd not seen that message yet, as it was a reply to Rob, the same
message you're replying to here. I encourage you to read the discussion
around SC16, which is similar to the discussion now.
- You cite 7.1.2.1 as an example of why Default-Deny would be problematic.
However, you can read 7.1.2.4, which is the explicit allowance for other
extensions. This also applies to 7.1.2.3, as 7.1.2.4 is explicit that it
applies to All Certificates.
- You side the subjectAltName omission as an example; however, 7.1.2.4
combined with 7.1.4.2.1 addresses this, explicitly permitting it and
explicitly defining how the Applicant can otherwise demonstrate the right
to assert the data in a public context.

Thus, for each of the cases where you've suggested that adopting a view of
Default-Deny is problematic, you can see that the BRs have explicit
provisions to permit the additional extensions. Thus, a view that the
default is Default-Allow is not internally consistent, which is the issue.

I greatly appreciate you raising these examples, because they're all
examples of the BRs making explicit provisions to permit something. The
exception, the explicit denial you mentioned in 9.2.9, was something
explicitly added in SC16 as a clarification of existing requirements.
GlobalSign endorsed this ballot, so presumably it agreed with the
rationale, that it was a clarification of existing requirements? The only
way they could be existing requirements is a Default-Deny perspective, and
the only way it could have been seen as ambiguous is if Default-Deny was
acknowledged as a valid expectation.

If there are other examples you're aware of, where taking a view of
"Default-Deny" leads to undesirable interpretations, I think it'd be great
to highlight them. I'm all on board for fixing those. That's what I was
explicitly asking for in
https://cabforum.org/pipermail/servercert-wg/2019-October/001169.html , so
if you're aware of other issues, please continue, we should clarify them :)
As to your point about being clear about the overall expectations, you'll
find we're in deep agreement, as
https://cabforum.org/pipermail/servercert-wg/2019-October/001169.html is
also asking for CAs to suggest language that they would feel would best
clarify that, as a whole, the default way to read the BRs is everything
that is not explicitly permitted is prohibited.

Taking a step up a level, what's at question here is what's the way to
"read the BRs". If you think about it like translating from another
language which may not be familiar (e.g. think the Rosetta Stone), when you
think you've got a translation of a given word or symbol, you then work to
make sure it's consistent with every other usage of that word or symbol. If
it results in nonsense, it likely means you've got a bad translation. Or,
to use a different metaphor, you can think of it like filling in a
crossword puzzle. If you think you have a solution for 6-Across, and you've
already filled in 9-Down, you need to make sure that the answer you have is
consistent, and that the same letter appears in the same place for both
answers. If you end up with different letters, it means that one or both of
the answers is wrong.

I'm trying to highlight that the answer for "6-Across" can't be that "All
other name types are permitted", when that's not consistent with "9-Down",
which is the repeated and explicit enumeration of when things are
permitted. Nor is it also consistent with "11-Down", which was SC16, which
clarified the existing interpretation: That unless something is explicitly
permitted, it's denied.

My message in
https://cabforum.org/pipermail/servercert-wg/2019-October/001169.html was
trying to highlight that we shouldn't try to solve this by going through
every list, and adding an "Unless otherwise permitted, then forbidden";
that's a solution that causes more issues than it solves, because it
codifies Default-Allow. I'm interested in finding a solution that
clarifies, for the documents as a whole, the existing Root Program
expectation: "Everything not explicitly listed as allowed is forbidden",
and then making sure that we have explicit allowances for anything else
that might be forbidden.

This is not about evangelizing to convince CAs that the view is
Default-Deny. I'm stating the expectation is Default-Deny, and if there's
confusion about that, and there seems to be, we should resolve this,
ideally in the BRs. We're in clear agreement here, more than you realize :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191009/dd10376a/attachment.html>