Subject: [Anima] BRSKI: inclusion of "assertion" field in the Registrar's Voucher Request

From: Esko Dijk <[email-masked]>
Date: Wed, 8 Sep 2021 07:16:04 +0000

FYI, I’ve created a new minor issue for draft-constrained-voucher, https://github.com/anima-wg/constrained-voucher/issues/160
which wasn’t fully clear from RFC 8995.

The question is whether a Registrar can omit the “assertion” field in its Voucher Request (seems yes), and why it would do that.
With current specs it looks like the MASA must be able to handle both cases of inclusion and omission of this field.

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: [email-masked]

---

From: Esko Dijk <[email-masked]>
Date: Thu, 16 Sep 2021 15:41:18 +0000

FYI this issue is still open and I forgot to mention it today!
The original BRSKI design idea isn’t clear to me; it is either A or B

A) Assertion from the Pledge is carried forward (replicated) by the Registrar. So the RVR includes the assertion field. (Registrar is asserting its proximity to the Pledge. With the embedded PVR being the proof.)
B) Assertion field is only present when the sender makes an actual assertion statement to the receiver, so PVR includes it (as a proximity assertion e.g., with additional field describing the target of the proximity assertion in the form of a Registrar cert). But RVR does not include ‘proximity’ since the Registrar isn’t asserting anything towards MASA.

Any input is helpful here; we can make a choice in one of the next calls.
In case we select option A this would be Updating RFC 8995.

Esko

From: Anima <[email-masked]> On Behalf Of Esko Dijk
Sent: Wednesday, September 8, 2021 09:16
To: [email-masked]
Subject: [Anima] BRSKI: inclusion of "assertion" field in the Registrar's Voucher Request

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: [email-masked]<mailto:[email-masked]>