anima-wg/brski-discovery

brski-discovery

brski-discovery's Issues

Proposal for core-lf encoding of variations

Capturing discussion from Nov 14 BRSKI meeting.

Original proposal from Esko:

request: REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp

reply: RES: 2.05 Content
coaps://[fe80::c78:e3c4:58a0:a4ad]:8485;rt=brski.jp;brv=”jose cms”

KNX might be using CORE-LF, so that might be a community to help validating CORE-LF work we do. M2M might also use CORE-LF.

There is prior work mapping DNS to CORE-LF and vice versa.
Mentioned in CORE WG if there was interest in generic mapping.
Might only want to do mapping from DNS-SD to CORE-LF, because that is most complex.

Problem: Encoding of TXT record of RFC6763. Aka: Lets not do a generic mapping unless another WG like CORE is interested. Generic mapping is more work.

May want to do priority/weight from DNS-SD... or not.. How important is it.

Tweaks suggested for section 'Variation Types and Choices'

replace

enroll: : A variation in the URI endpoints used for enrollment of the pledge with keying material (trust anchors and certificate (chain)). This document introduces the choices "est" as introduced by {{BRSKI}} (to indicate the {{EST}} protocol) and "cmp" to indicate the lightweight CMP profile ({{lwCMP}}) introduced by {{BRSKI-AE}}. It also reserved the choice "scep" to indicate {{SCEP}}. This is only a reservation, because no specification for the use of {{SCEP}} with BRSKI exist.

by

enroll: : A variation in the URI endpoints used for enrollment of the pledge with keying material (trust anchors and certificate (chain)). This document introduces the choices

• "est" as introduced by {{BRSKI}} to indicate the {{EST}} protocol, which is default
• "cmp" to indicate the {{CMP}} protocol according to the Lightweight CMP profile ({{lwCMP}}). The respective adaptations to BRSKI have been introduced by {{BRSKI-AE}}.
• "scep" to indicate {{SCEP}}. This is only a reservation, because no specification for the use of {{SCEP}} with BRSKI exists.

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

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).

GRASP objective names inside / outside of RFC8994 ACP

Issues mostly as a reminder to think about it:

Initially when RFC8990...RFC8995 was written, the GRASP objectives in support of BRSKI to be used exclusively via the ACP, hence they where called AN_registrar and AN_join_proxy.

In brski discovery we should clarify whether or not these objective names are valid by default ubiquitously across any possible instances of how GRASP is built, not only ACP.

Unless we come up with good reasons not to say so, i think this is what we should write into brski discovery for clarification to make it clear that such reuse is fine. Any draft that needs different objective names for whatever reason is still free to do so.

Please remove me from the list of authors

for the reason recently mentioned.

Me being mentioned as a contributor is fine.