> We put the overhead of supporting all the variations on the Registrar before,
For an implementation this makes sense. But, it could be that a particular
domain owner doesn't want all methods to be supported, still. E.g. some
security or policy concerns (whether these are justified or not). Then a method
may get disabled on the server.
But to let the device retry the same Registrar later on, or try multiple in
case of error, seems fine to me in general. For renewal, retrying the next day
or so is quite acceptable - if the renewal is only triggered by date/time of
the old certificate.
> Not sure why you write proxy/registrar.
What Michael indicates was also my understanding: once the Pledge is onboarded,
it gains access to the domain's network, and it has no need of any proxy
anymore.
For cert renewal it should discover directly an EST, or CMP, or ...., server
that's capable of renewal. For EST, the server is I think required to offer
renewal - so any EST server should do.
And because a BRSKI Registrar that supports EST for onboarding (the default),
will include an EST server, it is possible for the device to discover "BRSKI
Registrar" and use this as an EST server.
So options are:
1) discover an EST server - RFC 9148 defines a method using CoAP resource type
(rt=ace.est.sren), which can be used with multicast CoAP discovery (not ideal
in mesh networks), or with a Resource Directory. It's not mandatory for a
server to offer this discovery per 9148.
The cBRSKI draft could, if we want, define more details here, or make it
REQUIRED for compliant servers to support discovery. Or alternatively we just
say "go discover a Registrar" (point 2).
2) discover a BRSKI Registrar - the combo of cBRSKI-draft and cJP-draft
together ought to define this case.
3) address of renewal server could be pushed into the device via a higher-layer
communication i.e. the application layer. This "push" could happen at the
moment that the device is requested to re-enroll itself, in some
application-specific way.
There's currently no standard protocol message defined AFAIK to trigger a
client to start the re-enrollment process.
Esko
-----Original Message-----
From: Anima <[email protected]> On Behalf Of Michael Richardson
Sent: Thursday, November 23, 2023 20:09
To: Toerless Eckert <[email protected]>; [email protected]
Subject: Re: [Anima] Discovery of renewal server /
draft-eckert-anima-brski-discovery / draft-ietf-anima-brski-ae /
draft-ietf-anima-brski-prim
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*
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
