Subject: [saag] subordinate vs intermediate certification authority

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Feb 2021 23:10:43 -0500

I thought I had cross-posted this, but apparently I did not:
  https://mailarchive.ietf.org/arch/msg/anima/3tNwWb9gBacdYMTr1TtXzSa_3_Q/

FC5280 uses the term "intermediate certificates", and they are presumably
issues by "intermediate" certification authorities.

That term does not appear, although:
     "intermediate CA certificates"
occurs.

RFC4949 defines "intermediate CA"
However, the usage in RFC4949 seems entirely related to cross-certification,
rather than a PKI that has multiple layers of certification authority!

RFC4949 defines "subordinate CA" in a way that implies it is part of the same
organization.
RFC5280 uses the term "subordinate" in section 3.2, but later in referring to
RFC1422, notes that in X509v3, we don't need the same structure.
In reading it, it feels that the term subordinate should refer to v1
certificates only.

At this point, in 2020, can someone give me some guidance on using these terms?

My intuition, which I have started to document at:
   https://www.ietf.org/archive/id/draft-richardson-t2trg-idevid-considerations-01.html#name-number-of-levels-of-certifi

is that if the Trust Anchor (Level one) and the Level Two Certification
Authority are under control of the same organization, then the Level Two is
an "intermediate" certification authority.

However, if the Anchor (level N) and the Level N+1 certification authority
are in different organizations (such as for an "Enterprise Certificate"),
then the Level N+1 is a subordinate CA.

This question comes from working on draft-ietf-anima-constrained-voucher,
in which we have a number of choices on which certificate (or public key) to
pin our constrained-RFC8366 voucher.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Feb 2021 23:48:11 -0500

On Wed, Feb 03, 2021 at 11:10:43PM -0500, Michael Richardson wrote:

> RFC5280 uses the term "intermediate certificates", and they are

FWIW, in the context of OpenSSL, Postfix, etc., I see/use the terms
"root CA certificate", "intermediate CA certificate" and "end-entity
certificate".  Where "root CA certificates" are self-signed, "end-entity
certificates" are the certificates of the peer, and everything in
between is just intermediate certificates.

>From a verifier perspective there is little reason to make distictions
on a more granular level.  Note that what may be an intermediate CA
certificate (or even end-entity certificate) in one context may the
trust anchor in another.  So the above terms are strictly about the
chain of issuance, separate from any question of which element in the
chain happens to be the trust anchor.

> then the Level N+1 is a subordinate CA.

Again, from the vantage point of the verifier, there's no practical way
to know.  Some of the Let's Encrypt CA certs are issued by DST others by
ISRG.  In common usage, I typically see these referred to as intermediate
certificates, but e.g. the ISRG CPS appears to prefer "subordinate":

    https://letsencrypt.org/documents/isrg-cp-v2.5/

    6.1.1.1 CA key pair generation

    For Root CA Key Pairs created after the Effective Date that are
    either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for
    a subordinate CA that is not the operator of the Root CA or an
    Affiliate of the Root CA, the CA SHALL:

explicitly distinguishing between arm's length subordinates and
subordinates affiliated with the root CA.  There's no mention
of intermediate certificates, rather The taxonomy appears to be

    6.1.5 Key sizes

        (1) Root CA Certificates

        (2) Subordinate CA Certificates

        (3) Subscriber Certificates

So as I see it, "intermediate" and "subordinate" are essentially
synonymous, with some technical communities using the former and others
the latter to mean basically the same thing.

-- 
    Viktor.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 4 Feb 2021 07:46:13 +0000

Michael

I also recognized the lack of clear definitions of these terms.

May be the definitions in the NIST glossary help.
https://csrc.nist.gov/glossary/term/Intermediate_Certification_Authority
"intermediate CA
A CA that is signed by a superior CA (e.g., a Root CA or another Intermediate CA) and signs CAs (e.g., another Intermediate or Subordinate CA). The Intermediate CA exists in the middle of a trust chain between the Trust Anchor, or Root, and the subscriber certificate issuing Subordinate CAs. From CNSSI 4009-2015 CNSSI 1300
A CA that is subordinate to another CA, and has a CA subordinate to itself. From NIST SP 800-32"
https://csrc.nist.gov/glossary/term/superior_CA
"superior CA
In a hierarchical PKI, a CA who has certified the certificate signature key of another CA, and who constrains the activities of that CA. (See subordinate CA). From NIST SP 800-32"
https://csrc.nist.gov/glossary/term/subordinate_CA
"subordinate CA
In a hierarchical PKI, a CA whose certificate signature key is certified by another CA, and whose activities are constrained by that other CA. (See superior CA). From NIST SP 800-32"

The definition of intermediate CA from the NIST glossary differs to the one in RFC 4949, but I think it fits better for todays use. The definition of subordinate CA seems to fit well also with RFC 4949.

I often read the term "Issuing CA" referring to those CAs issuing end entity certificates.
https://www.omnisecu.com/security/public-key-infrastructure/certificate-authority-ca-hierarchy.php
But I am not aware of any official definition. Sometime the term issuing CA is also used more general to refer to the CA that's issued any certificate, not only an end entities.

Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[email-masked]> Im Auftrag von Michael Richardson
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaila
> rchive.ietf.org%2Farch%2Fmsg%2Fanima%2F3tNwWb9gBacdYMTr1TtXzSa_3
> _Q%2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C255
> 1cabf1d654a19be8308d8c8c2f242%7C38ae3bcd95794fd4addab42e1495d55a%
> 7C1%7C0%7C637480086901728875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C200
> 0&amp;sdata=GtWLDA9UZnBbTgy4SPKe5GP2PcTnjz9x5SnL2HRxwZY%3D&a
> mp;reserved=0
> 
> In reading it, it feels that the term subordinate should refer to v1 certificates
> only.
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Farchive%2Fid%2Fdraft-richardson-t2trg-idevid-considerations-
> 01.html%23name-number-of-levels-of-
> certifi&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2551
> cabf1d654a19be8308d8c8c2f242%7C38ae3bcd95794fd4addab42e1495d55a%7
> C1%7C0%7C637480086901728875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C200
> 0&amp;sdata=abLRY9YWMtjjKzmrCsVgRV8pJj8At2rF74vGzTITV%2B4%3D&a
> mp;reserved=0
> 
> However, if the Anchor (level N) and the Level N+1 certification authority are
> in different organizations (such as for an "Enterprise Certificate"), then the
> Level N+1 is a subordinate CA.
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Feb 2021 12:13:22 -0500

>> RFC4949 defines "intermediate CA" RFC4949 defines "subordinate CA" in
    >> a way that implies it is part of the same RFC5280 uses the term
    >> "subordinate" in section 3.2, but later in referring to
    >>

    > certificate".  Where "root CA certificates" are self-signed,
    > "end-entity certificates" are the certificates of the peer, and
    > everything in between is just intermediate certificates.

    > on a more granular level.

Yes, I agree that there is no important distinction from a chain validation
point of view.

    >> However, if the Anchor (level N) and the Level N+1 certification
    >> authority are in different organizations (such as for an "Enterprise
    >> Certificate"), then the Level N+1 is a subordinate CA.

    > to know.  Some of the Let's Encrypt CA certs are issued by DST others
    > by ISRG.  In common usage, I typically see these referred to as
    > intermediate certificates, but e.g. the ISRG CPS appears to prefer
    > "subordinate":

That seems to be consistent with my hypothesis that the term "subordinate"
represents a split in administrative authority.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 4 Feb 2021 15:38:38 -0500

> represents a split in administrative authority.

Sort of, only they explicitly distinguish between affiliate and
unaffiliated subordinate CAs, thus implying that the "split" in question
is not always a feature of subordinate CAs.

The NIST terminology mentioned in this thread makes intermediate a
subclass of subordinate, where intermediate CAs issue subordinate CA
certs, rather than end-entity certs.

My take is that the terminology is all over the place, and I mostly
don't care, but where you need to be precise, you need to carefully
state the definitions that hold in your document...

-- 
    Viktor.

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 5 Feb 2021 06:16:51 -0700

Hi Michael, all,

I would not add specific significance to terminology that has been used 
interchangeably for many years. In the public eye "Intermediate CA" or 
"Subordinate CA" are equivalent (used in different contexts, though). If 
you want to make the distinction because in your work you want to 
differentiate if a CA is run by the same organization that runs the 
Trust Anchors, I would suggest you make it very explicit in the text so 
as not to confuse people.

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.

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.

I hope this helps,

Cheers,
Max

On 2/3/21 9:10 PM, Michael Richardson wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 15:42:11 -0500

Thanks for the many emails on this; I think that it was useful to me.

    > May be the definitions in the NIST glossary help.

Thanks, that's a good place to go.
I think that the NIST definitions are probably good enough for now.
(I wish revising RFC4949 was cheaper)

    > From NIST SP 800-32"
    > https://csrc.nist.gov/glossary/term/subordinate_CA "subordinate CA In a
    > hierarchical PKI, a CA whose certificate signature key is certified by
    > another CA, and whose activities are constrained by that other CA. (See
    > superior CA). From NIST SP 800-32"

    > The definition of intermediate CA from the NIST glossary differs to the
    > one in RFC 4949, but I think it fits better for todays use. The
    > definition of subordinate CA seems to fit well also with RFC 4949.

...

my conclusion is that mostly, the terms are interchangeable, but that
"subordinate" might be used when there is a clearer "constrained".
For instance, if there were a Path Constraint by the superior CA.

Or: all subordinate CAs are intermediate CAs, but not vv.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 15:48:59 -0500

> certs, rather than end-entity certs.

Yes, this comment made me go back and re-read the definition again, and a
light went on.

    > state the definitions that hold in your document...

It sure seems like might be a place where doing it once (in a new document) might help.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 15:59:37 -0500

> while "Subordinate CA" is usually referred to in the context of PKI

I think that this is the key point which you are supporting.

    > 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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 6 Feb 2021 16:34:02 -0500

On Sat, Feb 06, 2021 at 03:59:37PM -0500, Michael Richardson wrote:

> 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.

Are you trying to get at generalising the issue described at:

    http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html

(where I track sloppy SMTP server operators who've pinned the now retired
Let's Encrypt "X3" CA, and have failed to keep up with the times)?

The number of MX hosts with such TLSA RRs is falling as they eventually
notice (or the issue is brought to their attention).  And, fortunately,
with DANE TLSA RRs published in their DNS zone, they can update the pin
on their end, without having to ask the world to update some local copy.

There is a tiny population of SMTP operators who've attempted to publish
TLSA RRs that pin the EE public key of a provider's SMTP server they
don't control.  That's a mistake, and they eventually figure this out
and drop unmaintainable TLSA RRs for servers they don't control.

-- 
    Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 21:04:34 -0500

>     http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html

Hi, that's a very interesting read, and I also haven't seen the diagram at:
   https://letsencrypt.org/certificates/#intermediate-certificates

I also really like the rounded box with the wave bottom to represent a certificate.
I've been looking for a good icon for certificates, it seems for years :-)

    > (where I track sloppy SMTP server operators who've pinned the now
    > retired Let's Encrypt "X3" CA, and have failed to keep up with the
    > times)?

As I understand your page, this is case where example.com is declaring via
DANE-TA what their intended CA is.  Because of the way that LE is changing
their PKI structure, the declared pin point is no longer the "DST Root CA X3",
but now R3/E1/R4/E1.

But, why would they pin that, rather than X1/X2?
Ah, I guess because X1/X2 also sign CAs other than LetsEncrypt.
So this is where the issue is similar.

The difference is that the pinning is not being declared by the serving entity,
but rather by the client entity.  (Mostly, this is not TOFU, btw)

    > on their end, without having to ask the world to update some local

Yes, it makes sense to do it this way here.

    > There is a tiny population of SMTP operators who've attempted to
    > publish TLSA RRs that pin the EE public key of a provider's SMTP server
    > they don't control.  That's a mistake, and they eventually figure this
    > out and drop unmaintainable TLSA RRs for servers they don't control.

An analogy, perhaps imperfect, to email operations would be an MUA
which was attempting to pin the key of their IMAPS/SMTP-submit server.
For a provider to which they believe they have a relationship with, in the
sense that their provider owns their mailbox.
This analogy could go further, and perhaps it should continue in DANISH.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 8 Feb 2021 11:48:57 -0500

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

> function elsewhere.

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2021 12:13:36 -0500

On Mon, Feb 8, 2021 at 11:49 AM Ryan Sleevi <[email-masked]> wrote:

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

Almost agree. Should not pin to a PKIX CA.

> on client policy that is intentionally not controlled/controllable by

I agree.

Pinning is a great idea in principle and PKIX pinning turns out to be a
lousy idea in practice. The fundamental problem is that every PKIX cert is
written from the assumption it will expire. And that is why trust anchors
in PKIX aren't actually PKIX certificates. This is true even when PKIX
syntax is used for distribution.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Feb 2021 12:44:36 -0500

> on client policy that is intentionally not controlled/controllable by

With DANE-TA(2), the server is *asserting* the trust-anchor that's
relevant for validation of its certificate.  It is not a pin as such.
The real trust-anchor is the DNSKEY RRset that ultimately signs the
chain leading to validated TLSA records.

Clients that implement DANE-TA(2) support will use whatever appears in
the TLSA record, so there's no assumption of client policy.  (Indeed
less assumption of client policy than with WebPKI, where one must
tacitly assume that the CA one has elected to issue one's certs is
trusted by the relevant clients).

That said, a few operators have on some occasion been too sloppy to
ensure that the actual certificate they deploy matches the trust anchor
listed in their own TLSA records.  This is entirely a server-side issue:
operational negligence, unrelated to client policy.

One can criticise choosing to publish TLSA RRs that "pin" one's own
issuer CA as a potentially fragile configuration, and indeed I rather
recommend DANE-EE(3) instead, and this is what most DANE users use.

Thus, use of DANE-TA(2) is not a potential conflict with client policy,
and with care, e.g. by delaying new EE cert deployment when the issuer
CA keys change, until new TLSA RRs have been published for a few TTLs,
one can use DANE-TA(2) safely even with a third-party issuing CA (most
typically Let's Encrypt these days).  However, I don't recommend this
except perhaps as a fallback, just in case the DANE-EE(3) rollover is
botched.

> Almost agree. Should not pin to a PKIX CA.

Perhaps this is the short version of what I tried to spell out in more
detail.

-- 
    Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 8 Feb 2021 18:59:43 +0100

Ryan,

> 
> 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 think we’ve lost the point of the discussion.  In this case, the client starts with just one CA in its trusted root cache, and maybe not any.  These are small devices, and that one cert is a manufacturer CA.

When we are talking about pinning we are talking about an environment in which a public CA cert is somehow involved.  That “somehow” is very much up in the air. Another way of addressing this is with a domain constraint, but the problem with such a constraint is that the device needs to understand DNS, and it may or may not, in which case some sort of other method is needed to signal that a particular intermediate needs to be in the chain for validation.

The manufacturer is the only trusted element in this picture, as far as the device is concerned, but it IS trusted in this scenario to explicitly configure trust for the device.  Thus it is in a very good position to signal that a particular intermediate certificate must be present in the chain.  How to do that?

That’s the question of the hour, as I see it.  And how to do it such that it doesn’t completely cause various libraries to cough up blood?  BIGGER question.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2021 13:41:15 -0500

> chain leading to validated TLSA records.

Using DNS to anchor WebPKI certs is like trying to nail oak posts to jello.

All you have is a chain of trust up to the ICANN yacht club root of trust.
You don't own a DNS name, you rent it. And companies that charge $250,000
to apply to register a name have shown themselves to be untrustworthy.

> trusted by the relevant clients).

And ten years after DANE started, those widely deployed clients would be?

> operational negligence, unrelated to client policy.

No, it is a protocol failure. There are no incompetent users, only
incompetent service providers. There are no incompetent administrators,
only incompetent protocol architects.

The sine qua non for all security policy is to automate the management of
the services so that the policy advertisements are always up to date.

> Perhaps this is the short version of what I tried to spell out in more

DNSSEC is simply the WebPKI with a minimum of two trusted parties per path
(ICANN + TLD registry). Oh and a heck of a lot more registries.

If people want to pin keys to a name, the only way to do that in a
practical way is to make the naming system and PKI co-extensive. That is
not a feature that can be added to DNSSEC or to PKIX.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2021 13:46:14 -0500

On Mon, Feb 8, 2021 at 1:40 PM Eliot Lear <lear=[email-masked]>
wrote:

> I think we’ve lost the point of the discussion.  In this case, the client
> starts with just one CA in its trusted root cache, and maybe not any.
> These are small devices, and that one cert is a manufacturer CA.
>
> When we are talking about pinning we are talking about an environment in
> which a public CA cert is *somehow* involved.  That “somehow” is very
> much up in the air. Another way of addressing this is with a domain
> constraint, but the problem with such a constraint is that the device needs
> to understand DNS, and it may or may not, in which case some sort of other
> method is needed to signal that a particular intermediate needs to be in
> the chain for validation.
>
> The manufacturer is the only trusted element in this picture, as far as
> the device is concerned, but it IS trusted in this scenario to
> *explicitly* configure trust for the device.  Thus it is in a very good
> position to signal that a particular intermediate certificate must be
> present in the chain.  How to do that?
>
> That’s the question of the hour, as I see it.  And how to do it such that
> it doesn’t completely cause various libraries to cough up blood?  BIGGER
> question.
>

If I had to deliver something in 12 months, I would take Microsoft's
Certificate Trust Lists as a starting point.

The better answer for IoT PKI is to start from scratch with trust
assertions that don't expire, a naming system in which permanent name
allocation is cheap and to make use of threshold cryptography to address
the fact that end users can't trust manufacturer keys and manufacturers
would be nuts to accept the liability of issuing end user keys.

Something like the Mathematical Mesh.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Feb 2021 15:03:35 -0500

> Using DNS to anchor WebPKI certs is like trying to nail oak posts to jello.

[ Colourful aside ignored. ]

> to apply to register a name have shown themselves to be untrustworthy.

At least I know who it chains to.

> And ten years after DANE started, those widely deployed clients would be?

Postfix, Exim, Power-MTA, Halon MTA, Cisco ESA, Microsoft Azure hosted
Exchange (scheduled to go live this month), gmx.de, Protonmail, Postini,
mailbox.org, ...

Of ~14 million DNSSEC signed domains, 2.54 million have DANE TLSA RRs
for their MX hosts.

> > This is entirely a server-side issue: operational negligence,
> > unrelated to client policy.
> 
> incompetent service providers. There are no incompetent
> administrators, only incompetent protocol architects.

I disagree, but the protocol failure, if you really insist on calling it
one, resulted from a compromise, where some folks wanted DANE to be
simple and just support DANE-EE(3), but some others wanted more
features, and so DANE has four certificate usages, of which only 2 are
suitable for SMTP, but almost everyone is wisely using DANE-EE(3).

Once I release "danebot" (in alpha now), which makes it easy to manage
DANE-EE(3) reliably with Let's Encrypt, more users will switch to
DANE-EE(3) and DANE-TA(2) should become increasingly rare.

> The sine qua non for all security policy is to automate the management
> of the services so that the policy advertisements are always up to
> date.

100% agreement, hence "danebot" coming to github soon.

> (ICANN + TLD registry). Oh and a heck of a lot more registries.

A system that eliminates redundant third parties in asserting domain
control.  The same ICANN root and registrars are also trusted parties
in DV cert issuance.

> not a feature that can be added to DNSSEC or to PKIX.

If the names are *DNS* names, then the parties that can delegate and
transfer control of domains are the natural parties to publish
assertions about trusted keys for those domains.

Some would redesign the domain hierarchy with various block-chain like
schemes, I don't expect these to succeed, but have no prior objections
to exploring other trust models.  Whatever the model, it should not
have redundant trusted 3rd-parties publishing assertions that the
principals can publish directly.

-- 
    Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2021 18:54:51 -0500

Thank you folks for the discussion.

> rather than a PKI that has multiple layers of certification authority!

Based upon the discussion on the list, the NIST references, and a look 
at the US GOV Federal  https://fpki.idmanagement.gov/tools/fpkigraph/

It seems that actually the Intermediate CA has extensive use related to 
cross-certification.  To the extent that the term has been used in our 
documents, it is usually associated with path validation, and this is 
usually important when bridge CAs are involved.

I will use the term subordinate CA when speaking about a multi-level 
PKI.  If I had the opportunity to update RFC4949 and RFC5280, it would 
be to add subordinate/superior CA to the document, with references to 
the NIST documents.