Re: [saag] [lamps] subordinate vs intermediate certification authority

[Ryan Sleevi <[e-mail]>]

On Sat, Feb 6, 2021 at 4:00 PM Michael Richardson <[e-mail]>
wrote:

>
> Dr. Pala <[e-mail]> wrote:
>     > Developers and Practitioners (see the note on OpenSSL's conventions)
>     > seem to support more the "Intermediate CA" for technical
> conversations
>     > while "Subordinate CA" is usually referred to in the context of PKI
>     > policies.
>
> I think that this is the key point which you are supporting.
>
>     > RFC3647 talks about subordinate organizations instead - maybe that is
>     > the concept you need to use? What is weird about the question is the
>     > different logical levels that you are trying to put together:
> business
>     > relationships and certification chains.
>
> The issue comes up with pinning as it relates to ownership.
> It's not a problem if every organization that can own Things has it's own
> private CA.  Pinning that CA works great.
> Pinning some other EE is very much more specific, but also, may be too
> ephemeral.
>
> Where it gets complex is when organizations have outsourced the CA
> function elsewhere.
> It's meaningless to pin LetsEncrypt or GoDaddy.  It might be meaningful to
> pin a Subordinate CA signed by some public CA though.
>

No one, anywhere, should ever pin to a CA that they don’t directly control,
and even then, they still shouldn’t :)

Pinning is just a poor-man’s attempt at a server controlling the client’s
trust anchors, and thus inevitably runs into issues, since client policy is
inherently _client_ policy. Especially important is never pinning to a
so-called “public” CA, precisely because their very existence is predicated
on client policy that is intentionally not controlled/controllable by
servers.

I stand by the statement that is mostly misguided to highlight any
distinction between these terms (subordinate and intermediate). The model
of PKI that 3647 envisioned, tied to The Directory, doesn’t exist. While it
provides a useful framework, the model of policy and business relationships
is not a generic model in practice, unfortunately, and so one cannot just
liberally sprinkle the terms in and expect there to be a distinction of
note to the reader.

In general, it should be a red flag if such a distinction is necessary,
because it’s indicative of an assumption of human-/business-/policy-based
practices, vs technical practices, and thus inevitably going to cause
significant interoperability issues, as both humans and policies are rarely
all alike and identical.