fix text that says to use RFC9148 discovery

[mcr]

EskoDijk 6 days ago
I don't get this part. It's a pledge, so it needs to find a BRSKI Registrar, not an EST server. So the discovery in RFC 9148 is irrelevant at this stage. Later on, once the voucher is received, the pledge will do EST functions directly with the registrar over the same DTLS connection, so there's still no need to discover an EST server.

Maybe later if it wants to renew its cert, it can use EST server discovery but I think it could even in that case use BRSKI Registrar discovery since the Registrar is defined to also act as EST server (or not?).

Member
@EskoDijk EskoDijk 6 days ago
I thought we agreed in the call that a pledge would only discover a device of type "join proxy", which in Far cases would yield a true join proxy and in Near use cases would yield a join proxy function hosted at the Registrar's machine. (So like a registrar, pretending to be a join proxy.) Then the pledge only has to do one type of discovery and doesn't have to decide which that is, which makes the protocol simpler and better testable/interoperable.

[EskoDijk]

Proposed fix is to just replace one RFC number. I think the reference was wrong:

OLD
Discoverable port numbers are usually returned for Join Proxy resources in the of the payload (see section 4.1 of [RFC9148].

NEW
Discoverable port numbers are usually returned for Join Proxy resources in the of the payload (see section 4.1 of [RFC6690].

[EskoDijk]

This part will be updated to point to cBRSKI, which defines the Pledge's discovery actions!
So closing the issue here already. The CJP draft will define how the JP discovers a registrar.