Ryan Sleevi <ryan-i...@sleevi.com> 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 [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima