Subject: Re: [Anima] [lamps] rollover of CA

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    [

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

---

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.