Discovery of proxy/registrar for certificate renewal vs. initial enrollment

[toerless]

A) RFC8994/RFC8995:
For BRSKI in the context of ACP/RFC8994, there is a clear set of objectives allowing to find registrar/proxy and renewal server via GRASP:

objective: AN_registrar - announced by registrar to be discovered by proxies. Not used by pledges because this is announced only via ACP and pledges can not access ACP.
objective: AN_join_proxy - announced by BRSKI join proxies via GRASP DULL (single hop) to tbe discovered by pledges.

Once RFC8995/BRSKI pledges are enrolled and have access to ACP, they renew their certificate looking for objective: SRV.est. This was done to allow that est servers can be separate from BRSKI servers, e.g.: so not all EST servers need to be upgraded to become BRSKI servers.

B) brski-discovery:

Do we, and if so how generalize discovery for certificate renewal ?
If we don't specify anything i think we will have no defined certificate renewal specified outside of RFC8994 across the different BRSKI documents (lets validate this assessment first).

[EskoDijk]

When not using GRASP, DNS-SD discovery of an EST server (RFC 7030 compliant) for renewal is definitely possible, by re-using the existing registered service name. See https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=enroll for the registration of "est".

So discovery is done with a DNS-SD QType=PTR unicast query for the name "_est._tcp." , where is determined by one of the methods in RFC 6763 Section 11 - it's complicated because there is no single de facto method, but multiple. Note that should not be "local" typically, because the EST server in most deployments wouldn't be a link-local entity.

On top of this it's also possible to discover BRSKI Registrars specifically - to find only BRSKI+EST servers that are aware of RFC 8995. Though it's doubtful if a client having to discover 2 names is useful/efficient. In this case the name would be "_brski-registrar._tcp.".

DNS unicast queries can also be secured in various standard ways (e.g. TLS).
There's also a protocol available soon (SRP) to let EST servers and Registrars automatically register their presence in the DNS, if manual DNS configuration is not wanted.

So in principle all the building blocks for cert renewal are already there. This draft could clarify/explain how it works.

[becarpenter]

When not using GRASP, DNS-SD discovery of an EST server (RFC 7030 compliant) for renewal is definitely possible...

Of course. Just a reminder, however, that GRASP discovery was designed to work on 'bare metal', with no dependencies except on very basic IPv6 (SLAAC ) and on a self-deploying ACP. Are we clear what the dependencies are when using DNS-SD?

[EskoDijk]

@becarpenter Right - I don't think we have clearly written down yet these different BRSKI use cases, each with different underlying dependencies.

One example use case is using BRSKI in a Thread mesh network. There is no ACP in this case: just an IPv6 mesh network that mixes application traffic and mesh management traffic. There is DNS and SRP services made available to all nodes in the mesh via Thread Border Routers (services available after node onboarding). There's no GRASP. Logically, a node needing to renew its certificate uses the standard way for the Thread network: it discovers the "est" service(s) using unicast DNS-SD, picks one, and connects to it using DTLS.

But this is just one example context: there may be multiple others. Not sure yet how we can deal with these "context variations" in the best way, for the draft. There should not be too many that we need to describe!