Subject: [lamps] 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: "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: Ryan Sleevi <[email-masked]>
Date: Thu, 4 Feb 2021 08:46:09 -0500

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

<snip>

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

I do not believe there is any practical value or point in treating these
terms as anything other than interchangeable, because that is broadly how
they have been used by the community for the past two-and-change decades.

A trust anchor can be an intermediate. A trust anchor can be a subordinate.
A trust anchor can have intermediates. A trust anchor can have subordinates.

If we want to grasp at a distinction between these terms, despite their
common usage making no such distinction, then at best, it is path vs policy.

An “intermediate” certificate is any certificate in the certification path
between the subject certificate (which may or may not be a leaf or
end-entity certificate) and the trust anchor. They are intermediates used
to extend the path.

A “subordinate” certificate is any certificate subject to the policies or
policy authority of a superior certificate, which may itself be a
subordinate certificate, a trust anchor, or a self-signed “root”
certificate.

The semantic and ontological distinction is, however, lost within the
noise, and attempting to distinguish between these two is, as a practical
matter, only going to lead to more confusion, much as a distinction between
“leaf” and “end-entity” can be argued to exist, but for all practical
intents, pointless to do so.

Terminology that focuses on organizational distinction within PKIs is
broadly irrelevant, even though it was very much an area of active debate
in those heady early days of PKI. In general, the experiences of the past
two decades have emphasized the primary importance of examining technical
capability, independent of policy authority.

---

From: Michael Jenkins <[email-masked]>
Date: Thu, 4 Feb 2021 09:20:11 -0500

> A trust anchor can be an intermediate. A trust anchor can be a
subordinate.

I'm pretty sure I know what you're trying to say, but these are confusing
at best. A trust anchor, by definition, isn't subordinate to anything. The
concepts of certificate and trust anchor are very different. The same
public signature verification key can be in a CA certificate (from the
point of view of an issuing CA), and can be installed as a trust anchor
(from the point of view of a relying party). Same public key, but two very
different uses. (I know that *you* know this, but I'm not assuming everyone
does.)

I do agree that a lot of application architectural baggage has been
attached to general-purpose terms through the years. Ultimately, a public
key is a public key; what it means - irrespective of format - is context
specific.

On Thu, Feb 4, 2021 at 8:46 AM Ryan Sleevi <[email-masked]> wrote:

> A trust anchor can be an intermediate. A trust anchor can be a
> subordinate. A trust anchor can have intermediates. A trust anchor can have
> subordinates.
>
>> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

-- 
Mike Jenkins
[email-masked] <[email-masked]> - if you want me to read it only
at my desk
[email-masked] - to read everywhere
443-634-3951

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 4 Feb 2021 10:57:40 -0500

On Thu, Feb 4, 2021 at 9:20 AM Michael Jenkins <[email-masked]>
wrote:

> at best. A trust anchor, by definition, isn't subordinate to anything.
>

I can understand that you’re taking a local, per-application view, but my
point of this statement is that it depends on your perspective.

Put differently: your trust anchor can be my subordinate, and my trust
anchor can be your subordinate.

These are not intrinsic properties of the PKI or its hierarchy that apply
in all cases, but rather, context-dependent based on local policy.

I think we agree on that much, but from the perspective of a relying party
validating a chain, they absolutely can encounter a trust anchor in a
subordinate certificate during verification, due to the peer providing
that. They simply ignore it, because they found their anchor :)

The concepts of certificate and trust anchor are very different. The same
>> An “intermediate” certificate is any certificate in the certification
>> path between the subject certificate (which may or may not be a leaf or

---

From: Russ Housley <[email-masked]>
Date: Thu, 4 Feb 2021 11:14:47 -0500

On Wed, Feb 3, 2021 at 11:11 PM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
At this point, in 2020, can someone give me some guidance on using these terms?

<snip>

There was no intention in RFC 5280 to imply anything about the organizational affiliation of the operator of a CA.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Feb 2021 16:38:44 +0000

*   Put differently: your trust anchor can be my subordinate, and my trust anchor can be your subordinate.

I agree with this.  I view “trust anchor” as an adjective like color; it can be added or changed according to local policy.  Whether or not something is a leaf, an intermediate, or a root is an intrinsic property of a specific signature chain.  I would rather it be a globally intrinsic property, but when you have to allow for cross-signing concessions must be made.

---

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

Ryan Sleevi <[email-masked]> wrote:
    > I do not believe there is any practical value or point in treating
    > these terms as anything other than interchangeable, because that is
    > broadly how they have been used by the community for the past
    > two-and-change decades.

okay.
If you are trying a diagram, which term would you use?

    > noise, and attempting to distinguish between these two is, as a
    > practical matter, only going to lead to more confusion, much as a
    > distinction between “leaf” and “end-entity” can be argued to exist, but
    > for all practical intents, pointless to do so.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 4 Feb 2021 12:37:15 -0500

> If you are trying a diagram, which term would you use?

In a diagram, I would use the strategy of RFC 4158. There are CAs, and
there are not-CAs :)

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Feb 2021 15:24:04 -0500

> On Feb 4, 2021, at 12:37, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> 
> On Thu, Feb 4, 2021 at 12:15 PM Michael Richardson <[email-masked]> wrote:
> 
> In a diagram, I would use the strategy of RFC 4158. There are CAs, and there are not-CAs :)  

I have come to where Ryan is.

As you noted, the term Intermediate CA, I think originally, applied to CA’s that issued cross-certificates. I have seen that term also applied to any CA that is sandwiched between two other CAs in the hierarchy. I have also seen the term subordinate CA refer to any CA that is below another. If you have this hierarchy:
Root +-> Intermediate CA -> Subordinate CA -> EE
     +-> Subordinate CA -> EE
And, you need to explain the differences between the two types you might get wrapped around the axe handle.

I know somebody will correct me if I am wrong, but I think RFC 5280 uses the term intermediate to refer to any certificate that is between the trust anchor and the EE. For example, in the inhibitAnyPolicy and basicConstraints extensions definitions and processing.

I hope this helps.

spt

---

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:47:00 -0500

Russ Housley <[email-masked]> wrote:
    mcr> point, in 2020, can someone give me some guidance on using these terms?

    > <snip>

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

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

    > There was no intention in RFC 5280 to imply anything about the
    > organizational affiliation of the operator of a CA.

Yes, I agree that 5280 didn't really say anything like that.
I'm suggesting based upon all the things I've read that this might be a way
to decide which to use.

Re-reading the NIST references the Hendrik posted, it seems that
"intermediate CA" might also be used to refer to a CA that does not issue
EE's itself, but *only* signs other (subordinate) CAs.

So three-level PKI (root, issuing-CA, EE), would not have intermediate CAs,
but a four-level PKI would.

---

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: Russ Housley <[email-masked]>
Date: Sun, 7 Feb 2021 10:35:01 -0500

> but a four-level PKI would.

In your example, I think the issuing-CA can be called an Intermediate CA.

Russ

---

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

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

---

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: 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: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: Ryan Sleevi <[email-masked]>
Date: Mon, 8 Feb 2021 14:08:59 -0500

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

> which a public CA cert is *somehow* involved.
>

Yes, and I'm explicitly telling you this is fundamentally unsafe and
unsound by design :)

You cannot simply "reuse" existing PKIs, bound by existing / other policy
agreements, and expect a stable interoperability with a different policy
authority. Put differently: you cannot mix and match different PKI policy
authorities (where application vendor + specific use case == the policy
authority). The notion of a unified policy authority (e.g. ITU as envisaged
by X.509v1, IETF as envisaged by RFC 1422, RSA DSI as envisaged by RFC
1114) does not exist, and has functionally never existed :)

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

Do not do that. I'm saying this is fundamentally insecure to indicate an
expected intermediate if that intermediate is not part of a PKI solely
subject to your Policy Authority.

For example, device manufacturer CAs, which are licensed by a device
manufacturer consortium (e.g. as done for USB-IF with respect to USB
certificates, Wireless Power Consortium) are examples of a singular policy
authority. CAs in that group do not (and MUST NOT) participate in other
PKIs.

However, once you have that, any distinction between "subordinates" and
"intermediates" is largely moot, with respect to technical specifications,
because at _best_ (and to great confusion), the distinction is with respect
to technical capability vs policy supervision, but you've already
established a singular policy authority.

---

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

On Mon, Feb 8, 2021 at 2:09 PM Ryan Sleevi <[email-masked]> wrote:

> authority.

The problem is deeper than that.

The PKIs bind keys to names. Neither the naming scheme of the WebPKI nor
the naming scheme of DNS is a remotely appropriate fit for IoT.

The policy incompatibilities are a consequence of the naming mismatch.

The device PKIs I have been involved with that used PKIX, all used a
namespace that was separate from everything else. And fo course, once you
do that, if the names don't have to be human readable, a direct trust model
in which the name is a fingerprint of the public key works much better.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 8 Feb 2021 20:42:06 +0100

Ryan,

> On 8 Feb 2021, at 20:08, Ryan Sleevi <[email-masked] <mailto:[email-masked]>> wrote:
> 
> When we are talking about pinning we are talking about an environment in which a public CA cert is somehow involved.
> 
> Yes, and I'm explicitly telling you this is fundamentally unsafe and unsound by design :)
> 
> You cannot simply "reuse" existing PKIs, bound by existing / other policy agreements, and expect a stable interoperability with a different policy authority.

So that we understand one another, I have heard your arguments about reusing PKI for a purpose other than what the policies were intended to cover, but above and in separate EMU WG discussions.   We don’t yet understand the right technology solution, and are nowhere near ready to discuss the policy aspects.   Let’s assume for the moment that public CAs were created specifically for this new purpose, and go from there, and figure out what the right technology answer is, and later worry about policy.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2021 22:57:26 -0500

OK to make concrete what I am talking about. The WebPKI was designed back
when Bill Gates threw a tantrum because parsing cert chains of 3 on a 20MHz
Win95 PC was a real performance suck. We were VERY limited in what we could
get away with.

Fast forward and, well multi-homed Web servers aren't ever going away. You
are never going to have an IP address serving just one domain. Oh and we
really shouldn't be disclosing the service the user is connecting to until
after we have an encrypted tunnel to the host.

So what this says to me is that hosts need to have a certificate to
authenticate the host and only after the host is authenticated do we get on
to negotiate the trust context with the service.

And we weren't thinking about that 29 years ago but we should be thinking
about it now.

One of the major advantages of this approach is that you can slip a proxy
service in really easily.

This used to be a research organization once. Seems I am one of the few
left doing research.

Maybe I should just buy myself the castle with the moat and retire.

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

>
>
>
> Ryan,
>
> On 8 Feb 2021, at 20:08, Ryan Sleevi <[email-masked]> wrote:
>
>>
> So that we understand one another, I have heard your arguments about
> reusing PKI for a purpose other than what the policies were intended to
> cover, but above and in separate EMU WG discussions.   We don’t yet
> understand the right *technology *solution, and are nowhere *near* ready
> to discuss the policy aspects.   Let’s assume for the moment that public
> CAs were created specifically for this new purpose, and go from there, and
> figure out what the right technology answer is, and later worry about
> policy.
>
> Eliot

---

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.