Naming: agent-proximty vs. agent-invited (or similar)

[stfries]

Comment from Toerless that the uasage of "proximity" in the assertion may be misleading as it is a different concept as in RFC 8995:

For an assertion, the MASA would have to use an object signed by the pledge that includes information about the other side of the proximity. This is what the prior-signed-voucher-request is good for: Its signed by the pledge and includes the cert of the registrar whose proximity the pledge did validate via the TLS handshake.

If we logically want to map this to BRSKI-PRM, it still needs to be done via the prior-signed-voucher-request because thats all the pledge signs and hence what pledge/masa would at this point trust. If we use an https:// connection between registrar-agent and pledge and the registrar- agent LDevID, then we can use exactly the same logic as BRSKI, jus now with registrar-agent LDevID - this is what i proposed in my top-post.

If you folks do not want to use an https:// connection between pledge and registrar-agent, then i would at least change the name from "agent- proximity" to "agent-invited" or the like to make it clearer that we use a different type of assertion. And in this case the pledge would just indicate that it had received a Trigger PVR that was signed by that LDevID of the registrar agent thats included in the PVR in the prior-signed-voucher- request.

[stfries]

We took “proximity” here to underline that it is the same concept as in BRSKI, the pledge gets an artifact (the LDevID(RegAgt)) that it cn verify later on. As it was not provided directly but via an agent we picked the name agent-proximity.

relates to Issue #81

[mcr]

I'm not sure what the concern is. We have a new assertion, we have a freshness in the PVR that the Registrar-Agent provides. The Registrar-Agent and Pledge can assert that they were in contact.

[stfries]

Agreed in the design team May 09, 2023 to keep agent-proximity, also based on the introduction of optional TLS according to #82. Can be closed.