Re: [lamps] rollover of CA

[Michael Richardson <[e-mail]>]

Ryan Sleevi <[e-mail]> 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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [





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