Inconsistency in the description of assertion level of "agent-proximity"

[stfries]

BRSKI-PRM, section 5.1 the following is stated:
""Agent-proximity" is a statement in the PVR and in the voucher, that the registrar certificate was provided via the registrar-agent as defined in Section 6 and not directly to the pledge. "Agent-proximity" is therefore a weaker assertion then "proximity",..."

Section 6 of BRSKI-PRM states
"... This agent-proximity is similar to the proximity assertion by the MASA when using BRSKI. It is a stronger assertion than "logged", but it is weaker than the assertion "verified", which relies on ownership tracking."

In contrast, section 6.3 of draft RFC 8366bis states:

enum agent-proximity {
            value 3;
            description
              "Indicates that the voucher has been issued
               after the MASA has verified a statement that
               a registrar agent has made contact with the device.
               This type of voucher is weaker than straight
               proximity, but stronger than logged.";
          }

The strength of the described assertion may be interpreted differently. The intended goal was that agent-proximity is close to proximity, and stronger than verified or logged.

Proposal (1) to address this in BRSKI-PRM, section 6 by replacing the statement
"It is a stronger assertion than "logged", but it is weaker than the assertion "verified", which relies on ownership tracking."
with
"It is a stronger assertion than "verified" as it relies on an active exchange with the pledge in the target domain showing that the pledge was in contact with a registrar via a registrar-agent".

Proposal (2) to consider the "strength" of the assertion also in RFC 8366bis. Thie could be done by providing a "rating" like

1. logged
2. verified (actually "logged + verified")
3. agent-proximity
4. agent-proximity + verified
5. proximity
6. proximity + verified

[Michael Richardson]

I see that maybe it was a mistake to rank anything. I am open to removing all statements about strength.

[stfries]

As of design team meeting, August 1, 2023:

• Discussion resulted in decision to remove the comparison between the different assertions as there is no clear single metric of strength. The security properties of the different assertions are not comparable.
• main text should not make statements
• also potentially double check security considerations
• can be close afterwards.

[stfries]

removed strength comparison in section 5.1 and 6. Security considerations did not include any strength related statements.