Toerless Eckert <[email protected]> wrote: > Please also add your thoughts about this to: > https://github.com/anima-wg/brski-discovery/issues/4 (but discuss here > first).
okay.
> Question: How do we want to deal with certificate renewal/re-keying ?
Stick head in sand, hope universe winds down before 991231 arrives :-)
> Do we assume by default that any discovered BRSKI (variation)
> proxy/registar is capable to do renewal ? Technically this would not
Not sure why you write proxy/registrar.
It would be strictly the registrar, and there should be no need for a node
(not a pledge anymore) to discover a proxy to renew.
I assume that nodes do EST or they do CMP, and likely not both.
We put the overhead of supporting all the variations on the Registrar before,
and I'm okay with continuing to do that. A node, upon receiving a 404 or 403
or 5xx when trying to renew using a Registrar that it has discovered ought to
just
move along to another Registrar. There could many reasons for the Registrar
to have that renewal method broken, and I think it makes little sense to
optimize the CMP vs EST case while leaving the "disk full" (or SSD ran out of
spares and went read-only) case broken.
> When writing RFC8994, we did consider that not all existing EST servers
> would necessarily support BRSKI, and therefore instead of using
> AN_join_registrar, renewal was recommend to use SRV.est objective.
I'm not entirely sure I agreed with that at the time, but I'm happy with
that. SRV.cmp would be fine too.
> We
> did not define an equvalent proxy objective though, because already
> enrolled pledges would not need to use a proxy but could always connect
> directly to a registrar.
> Do we ever need renewal to go through a proxy ?
It's probably wrong.
If the node has lost so much network that it's no longer on the ACP (or the
IoT network), then it probably should go through onboarding again. It might
have moved, or something happened.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
