Subject: [lamps] rollover of CA

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Sep 2021 10:09:49 -0400

Hi, sometime in 2021, we had a thread discussing how to rollover a
certification authority, and the process of signing old CA with new CA.
I know that I wrote emails about this, but I can't find them
either in the archives or in my outbox.

I also can't find the RFC which describes this... somewhere in the 2000s?

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

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 2 Sep 2021 11:08:58 -0400

I mean, there's https://datatracker.ietf.org/doc/html/rfc4210#section-4.4 ,
but that's more or less unsupported, and would strongly recommend against
it: the _key_ rollover creates vast issues with implementations.

Otherwise, if we're talking about (Subject + SPKI) changes, that's just
normal cross-certification. RFC 4158 is not widely supported in
implementations (particularly open-source software), so care must be taken.

Other protocols take different approaches (e.g. RFC 6489), tied in to the
overall protocol.

On Thu, Sep 2, 2021 at 10:10 AM Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Deb Cooley <[email-masked]>
Date: Thu, 2 Sep 2021 15:38:11 -0400

What exactly are you interested in?

Today's CA systems do this in a variety of ways.

We (US DOD) have Root CAs, and sub CAs.  We don't roll any of that over.
We stand up new Roots and new subCAs.  In general, we don't name them the
same.  When a new Root or sub CA is stood up, we make an announcement to
the community and there is an app that makes it easier to do the trust
store management. US Fed PKI just stood up a new Root CA for their Common
Policy Root CA - same thing, different name, different keys, different
dates, and (I think) different key sizes.

Some CA's will rekey.  Name remains the same, key changes, dates change (At
least the expiry date).  I'm not (personally) familiar with how this is
managed.   I want to say that Entrust's systems work that way (I could
easily be wrong tho).

Ryan can tell you more about how the public trust stores manage a Root CA
update/rekey/whatever.

Deb Cooley
[email-masked]

On Thu, Sep 2, 2021 at 11:09 AM Ryan Sleevi <[email-masked]> wrote:

> I mean, there's https://datatracker.ietf.org/doc/html/rfc4210#section-4.4
> , but that's more or less unsupported, and would strongly recommend against

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 3 Sep 2021 06:20:43 +0000

I remember being part of that discussion Michael.

RFC4210 describes it in section 4.2.
https://datatracker.ietf.org/doc/html/rfc4210#section-4.4

In reality I have only seen rollover using newWithOld, for example in ICAO 9303 part 12 (there called Link Certificate). The purpose being to be able to automatically update trust anchor with a new Root if you already trust the old Root.
https://www.icao.int/publications/Documents/9303_p12_cons_en.pdf

I have never understood the purpose  of, or seen a practical use, of OldWithNew. Therefore the CMP Update draft puts the link certificates as optional instead of mandatory.
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates#section-2.15

The old notion of having them as mandatory puts unrealistic burden on CA rollover imho.

Cheers,
Tomas

________________________________
From: Spasm <[email-masked]> on behalf of Deb Cooley <[email-masked]>
Sent: Thursday, September 2, 2021 9:38 PM
To: Ryan Sleevi <[email-masked]>
Cc: SPASM <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [lamps] rollover of CA

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [email-masked] with any questions.

We (US DOD) have Root CAs, and sub CAs.  We don't roll any of that over.  We stand up new Roots and new subCAs.  In general, we don't name them the same.  When a new Root or sub CA is stood up, we make an announcement to the community and there is an app that makes it easier to do the trust store management. US Fed PKI just stood up a new Root CA for their Common Policy Root CA - same thing, different name, different keys, different dates, and (I think) different key sizes.

Some CA's will rekey.  Name remains the same, key changes, dates change (At least the expiry date).  I'm not (personally) familiar with how this is managed.   I want to say that Entrust's systems work that way (I could easily be wrong tho).

Ryan can tell you more about how the public trust stores manage a Root CA update/rekey/whatever.

Deb Cooley
[email-masked]<mailto:[email-masked]>

On Thu, Sep 2, 2021 at 11:09 AM Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:
I mean, there's https://datatracker.ietf.org/doc/html/rfc4210#section-4.4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-4.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ol1o%2B3jtez%2BHp5nR48hT3drrlbQ83PRziNY23d4%2FUmI%3D&reserved=0> , but that's more or less unsupported, and would strongly recommend against it: the _key_ rollover creates vast issues with implementations.

Otherwise, if we're talking about (Subject + SPKI) changes, that's just normal cross-certification. RFC 4158 is not widely supported in implementations (particularly open-source software), so care must be taken.

Other protocols take different approaches (e.g. RFC 6489), tied in to the overall protocol.

On Thu, Sep 2, 2021 at 10:10 AM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

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

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2BFJW5VpaD2K%2FWLw9cHTWcj3e02Q1z2Ob%2FB%2FS1uNb6k%3D&reserved=0>
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2BFJW5VpaD2K%2FWLw9cHTWcj3e02Q1z2Ob%2FB%2FS1uNb6k%3D&reserved=0>

---

From: "Brown, Wendy (10421)" <[email-masked]>
Date: Fri, 3 Sep 2021 12:21:19 +0000

In the case of longer lived certificates (for example within Federal PKI most subscriber certs are 3 year) having the old CA key signed by the new key allows the certificates signed by the older key to be trusted with a path through the newer key to a trust anchor without having to maintain 2 distinct paths to that same trust anchor.

e-e -> ICA old key -> ICA new key - > root
vs
e-e -> ICA old key -> root AND  e-e -> ICA new key -> root

Key rollover is still fairly common within the US federal government.

Wendy Brown
Protiviti Government Services
[email-masked]

From: Tomas Gustavsson <[email-masked]>
Sent: Friday, September 3, 2021 2:21 AM
To: Deb Cooley <[email-masked]>; Ryan Sleevi <[email-masked]>
Cc: SPASM <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [lamps] rollover of CA

Cheers,
Tomas

________________________________
From: Spasm <[email-masked]<mailto:[email-masked]>> on behalf of Deb Cooley <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 2, 2021 9:38 PM
To: Ryan Sleevi <[email-masked]<mailto:[email-masked]>>
Cc: SPASM <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lamps] rollover of CA

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [email-masked]<mailto:[email-masked]> with any questions.

Deb Cooley

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2BFJW5VpaD2K%2FWLw9cHTWcj3e02Q1z2Ob%2FB%2FS1uNb6k%3D&reserved=0>
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2BFJW5VpaD2K%2FWLw9cHTWcj3e02Q1z2Ob%2FB%2FS1uNb6k%3D&reserved=0>
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Sep 2021 14:56:34 +0200

I think the issue is that RFC 7030 references RFC 4210.  And enterprises 
may indeed roll their CAs for a myriad of reasons, not the least of 
which could be mergers, mishandled private keys, and planned changes,.  
So some advice may be needed here, if 4210 isn't the right answer.

Eliot

On 03.09.21 14:21, Brown, Wendy (10421) wrote:
>
> In the case of longer lived certificates (for example within Federal 
> PKI most subscriber certs are 3 year) having the old CA key signed by 
> the new key allows the certificates signed by the older key to be 
> trusted with a path through the newer key to a trust anchor without 
> having to maintain 2 distinct paths to that same trust anchor.
>
> *From:* Tomas Gustavsson <[email-masked]>
> *Sent:* Friday, September 3, 2021 2:21 AM
> *To:* Deb Cooley <[email-masked]>; Ryan Sleevi 
> <[email-masked]>
> *Cc:* SPASM <[email-masked]>; Michael Richardson <[email-masked]>
> *Subject:* Re: [lamps] rollover of CA
>
> <https://datatracker.ietf.org/doc/html/rfc4210#section-4.4>
>
> In reality I have only seen rollover using newWithOld, for example in 
> ICAO 9303 part 12 (there called Link Certificate). The purpose being 
> to be able to automatically update trust anchor with a new Root if you 
> already trust the old Root.
>
> <https://www.icao.int/publications/Documents/9303_p12_cons_en.pdf>
>
> I have never understood the purpose  of, or seen a practical use, of 
> OldWithNew. Therefore the CMP Update draft puts the link certificates 
> as optional instead of mandatory.
>
> <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates#section-2.15>
>
> ------------------------------------------------------------------------
>
> *From:*Spasm <[email-masked] <mailto:[email-masked]>> 
> on behalf of Deb Cooley <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Thursday, September 2, 2021 9:38 PM
> *To:* Ryan Sleevi <[email-masked] <mailto:[email-masked]>>
> *Cc:* SPASM <[email-masked] <mailto:[email-masked]>>; Michael 
> Richardson <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: [lamps] rollover of CA
>
> *CAUTION:*External Sender - Be cautious when clicking links or opening 
> attachments. Please email [email-masked] 
> <mailto:[email-masked]> with any questions.
>
> We (US DOD) have Root CAs, and sub CAs.  We don't roll any of that 
> over.  We stand up new Roots and new subCAs.  In general, we don't 
> name them the same.  When a new Root or sub CA is stood up, we make an 
> announcement to the community and there is an app that makes it easier 
> to do the trust store management. US Fed PKI just stood up a new Root 
> CA for their Common Policy Root CA - same thing, different name, 
> different keys, different dates, and (I think) different key sizes.
>
> Some CA's will rekey.  Name remains the same, key changes, dates 
> change (At least the expiry date).  I'm not (personally) familiar with 
> how this is managed.   I want to say that Entrust's systems work that 
> way (I could easily be wrong tho).
>
> [email-masked] <mailto:[email-masked]>
>
>     I mean, there's
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-4.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ol1o%2B3jtez%2BHp5nR48hT3drrlbQ83PRziNY23d4%2FUmI%3D&reserved=0>
>     , but that's more or less unsupported, and would strongly
>     recommend against it: the _key_ rollover creates vast issues with
>     implementations.
>
>     Otherwise, if we're talking about (Subject + SPKI) changes, that's
>     just normal cross-certification. RFC 4158 is not widely supported
>     in implementations (particularly open-source software), so care
>     must be taken.
>
>     On Thu, Sep 2, 2021 at 10:10 AM Michael Richardson
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>         Michael Richardson <[email-masked]
>         <mailto:[email-masked]>>  . o O ( IPv6 IøT consulting )
>         [email-masked] <mailto:[email-masked]>
>         <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2BFJW5VpaD2K%2FWLw9cHTWcj3e02Q1z2Ob%2FB%2FS1uNb6k%3D&reserved=0>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf8cbc66140924bef39b908d96e49446d%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637662083233446087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V%2BFJW5VpaD2K%2FWLw9cHTWcj3e02Q1z2Ob%2FB%2FS1uNb6k%3D&reserved=0>
>
> NOTICE: Protiviti is a global consulting and internal audit firm 
> composed of experts specializing in risk and advisory services. 
> Protiviti is not licensed or registered as a public accounting firm 
> and does not issue opinions on financial statements or offer 
> attestation services. This electronic mail message is intended 
> exclusively for the individual or entity to which it is addressed. 
> This message, together with any attachment, may contain confidential 
> and privileged information. Any views, opinions or conclusions 
> expressed in this message are those of the individual sender and do 
> not necessarily reflect the views of Protiviti Inc. or its affiliates. 
> Any unauthorized review, use, printing, copying, retention, disclosure 
> or distribution is strictly prohibited. If you have received this 
> message in error, please immediately advise the sender by reply email 
> message to the sender and delete all copies of this message. Thank you.
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 13:45:28 -0400

Ryan Sleevi <[email-masked]> wrote:

    rs> I mean, there's
    rs> https://datatracker.ietf.org/doc/html/rfc4210#section-4.4, but that's
    rs> more or less unsupported, and would strongly recommend against it:
    rs> the _key_ rollover creates vast issues with implementations.

That's the section I was looking for.
Thank you for being my google :-)

This is for ANIMA's constrained-voucher/constrained-BRSKI-EST mechanism.
It is relatively greenfield.

For a variety of implementations, in draft-ietf-anima-constrained-voucher
(inheriting from draft-ietf-ace-est-coaps, almost RFC9148) the trust anchor
return prefers to use application/pkix-cert rather than RFC7030's
"application/pkcs7-mime; smime-type=certs-only", which avoids having a bunch
of useless CMS code.

The downside of this is that we can have a single trust anchor returned.
We have discussed being able to call /crts multiple times to get multiple
anchors.  (/crts/0, crts/1...).
The RFC4210 process to deal with key rollover creates a new certificate chain
that new nodes need to have, and in the constrained situation, we don't have
a good way to figure out how to transmit this during certificate renewal.

In the P2MP data collection IoT network, where the nodes only talk to "the
cloud", then it's probably trivial for the cloud server to have both the
previous CA and the new CA to validate the nodes.  They can renew as they
like.  The (D)TLS connection from the nodes needs to always use the
RFC8446 _4.2.4.  Certificate Authorities_ extension to indicate which anchor the node
has loaded so that the cloud can respond with new or old certificate.
Arranging for one or two cloud servers to have this double certificate is a
pain, but it can be done.

For P2P communication, including that used by RFC8994 (IKEv2 connections
among peers), then using RFC4210 seems like a better win.
IKEv2 includes a CertREQ which allows each end to see whether the other end
needs the chain.    On ACP networks (with 10G+ links) there is really no
significant downside to passing an extra 300 byte certificate signing the new
CA with the old CA.

For pure RFC7030 "certs-only" download, we can get this extra certificate
in easily.

DTLS connections between nodes in an LLN can use the same mechanism, but the
cost of the extra certificate is significant and so we'd like not to have to
send it around unless actually needed.

Esko, we could go into some significant detail here.
There are some operational parts here that are pretty clear to me, but there
are a few unknowns that remain.

One thought is that we can retain the old trust anchor when we get a new
LDevID, and a new certificate.   That lets new nodes continue to trust old
nodes.  This removes the need for nodes with LDevID0 to know that they need
to send some newCA->oldCA certificate.  The new nodes would have the oldCA->newCA
certificate, so the old nodes can verify the chain.

But, it would also be nice to know when the transition is likely to be
complete so that nodes could stop sending the extra bytes.

So another thought that I had was to define an extension somewhere (maybe in
the certificate oldCA->newCA?) which indicates a time at which the node
should return to get some update to trust anchors, but not necessarily to
renew a certificate.

The other interesting thing is whether the nodes with oldCA could cache the
oldCA->newCA certificate, and then would be able to state both as trust
anchors, avoiding the new to send that certificate everytime DTLS between
nodes rekeys.

{My reading of MATTER spec didn't reveal any rollover support. Hmm}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 14:01:00 -0400

> What exactly are you interested in?

Ryan got it exactly.
This is about rollover of CAs in IoT systems.
These aren't public today, but it needs to rekey, not-re-enroll.
There is a fair bit of concern out there about

    > over.  We stand up new Roots and new subCAs.  In general, we don't name
    > them the same.  When a new Root or sub CA is stood up, we make an

So, by "don't name them the same", you mean, the new one is "Federal Super
Issuer 2021" vs "Federal Super Issuer 2011"?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 14:08:22 -0400

> ICAO 9303 part 12 (there called Link Certificate). The purpose being to
    > be able to automatically update trust anchor with a new Root if you

    > OldWithNew.

OldWithNew allows a device with an OldCert to be trusted by a device that
has the NewCert.   If the device would simply retain the OldCA, then it's not
needed.

However a device which has been recently commissioned might have never seen
the oldCA.   If it has to validate a connection from a device which has been offline for
awhile, it would an issue.
In practice, how would the old device ever get the OldWithNew Link Certificate?
That implies that the OldWithNew Link Certificate would never get sent
inband, but rather needs to be provided to new devices when they enroll.

For a practical explanation of this, and the risks of it, I refer you to:
  https://www.youtube.com/watch?v=4HJ-Y8YTo8Q   :-)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Sep 2021 14:24:58 -0400

Eliot Lear <[email-masked]> wrote:
    > I think the issue is that RFC 7030 references RFC 4210.  And
    > enterprises may indeed roll their CAs for a myriad of reasons, not the
    > least of which could be mergers, mishandled private keys, and planned
    > changes,.  So some advice may be needed here, if 4210 isn't the right
    > answer.

It's not that RFC4210 is wrong, it's that it's a bit abstract.

In IoT deployments, there are many slightly different aspects of how things
will be used that affects how one makes it unclear how to concretely do
RFC4210.

These differences are perhaps worth writing down somewhere.

I think that one major category is outbound P2MP (IoT node -> cloud).
A second one is "inbound" P2MP CollectionSystem->Node (often not cloud).
The third one, which many IETF efforts assume, but industry does not commonly
do, is node<-->node.
A fourth one might be where two nodes connect to a cloud/server resource, and
are then put in touch with other using credentials provided by the server,
or perhaps even just keyed by the server.  Most forms of secure multicast are
basically like this.

It's quite likely that some networks do a combination of these for different
purposes.

---

From: Deb Cooley <[email-masked]>
Date: Mon, 6 Sep 2021 06:43:29 -0400

simply CA10 is replaced by CA11.  Merely a one up counter.

On Fri, Sep 3, 2021 at 2:01 PM Michael Richardson <[email-masked]>
wrote:

> name