GRASP discovery of EST-COAPS server for renewals.

[mcr]

RFC8994 section 6.2.5.1 needs to be Extended to include an objective that describes where the EST server can be found that will take care of certificate renewals for devices which are already onboard.

[toerless]

Thoughts:

As in ACP [RFC8994], but with objective SRV.est-coaps - i already registered est-coaps.

The more fundamental question is whether we could simplify and just use the same objective as for the constrained brski registrar because the networks are never so large that a registrar can not also renewe certificates. In ANI we where worried about short-lived certificarte renewal load and therefore wanted to be able to split up registrar from mere est-servers (aka: so one can scale up est-server functionality without impacting registrars).

[mcr]

This is done in latest -18 document.

[mcr]

How does a device discover EST -coaps server using GRASP. Need to extend: 6.2.5.1. GRASP Objective for EST Server ACP nodes that are EST servers MUST announce their service in the ACP via GRASP Flood Synchronization (M_FLOOD) messages. See [RFC8990], Section 2.8.11 for the definition of this message type and Figure 4 for an example.

[M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, [["SRV.est", 4, 255 ], [O_IPv6_LOCATOR, h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] ]

[EskoDijk]

One key design concept of BRSKI (RFC 8995) is that the "Registrar" or JRC is defined as equivalent to the "EST server". So both are one and the same. So couldn't we just say we discover the Registrar (as already defined) and by that we've found the EST server?

(Or, is there a situation possible that a Registrar is not available anymore after initial bootstrap of all devices and that a "regular EST server" is placed in the network instead?)

[mcr]

One key design concept of BRSKI (RFC 8995) is that the "Registrar" or JRC is defined as equivalent to the "EST server". So both are one and the same. So couldn't we just say we discover the Registrar (as already defined) and by that we've found the EST server?

Yes/no.

(Or, is there a situation possible that a Registrar is not available anymore after initial bootstrap of all devices and that a "regular EST server" is placed in the network instead?)

Yes, that's the case. One is that the Registrar might be turned off/disabled when there are no devices to bootstrap. Either that means that it just becomes an EST server, or might be that it just gets powered off. The other case is that the network is big enough that there is a need for multiple EST servers to deal with all the devices renewing certificates at regular intervals. If the devices get synchronized in some way because of notAfter being all the same, then it could be that the EST server is going to get hit. A third situation is that the access to the right HSM to actually issue the certificates is only available during "office hours", when the people are there with the keys to enable it. Then, again, it might be important to have multiple EST server available so that all devices get connected, or that the EST server is never unavailable due to hardware or software fault.

[EskoDijk]

Hmm, these servers could advertise themselves as "Registrars" (JRC) but that may give the wrong signal if they are not actually Registrar. So it makes sense to have a separate discovery option for EST-servers.

Then we need to add the proposed section to our draft?

[mcr]

Hmm. Do we actually need to say anything? Or does RFC7030 and RFC9148 say everything there is to say about finding an EST server? (Well, it's RFC8994 for GRASP discovery of EST)

[EskoDijk]

Yes the idea here was we need to say something about GRASP discovery of the EST server, since it differs from the GRASP discovery of the EST server in RFC 8994. IPPROTO_TCP becomes IPPROTO_UDP for example.

So a reference to 8994 would be most useful for this and the mention of what would differ for the constrained case.

[EskoDijk]

Item marked as "future", because GRASP discovery is currently removed from the draft - this is saved up for draft-eckert-brski-discovery.