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 protected]> On Behalf Of Esko Dijk Sent: Wednesday, September 8, 2021 09:16 To: [email protected] Subject: [Anima] BRSKI: inclusion of "assertion" field in the Registrar's Voucher Request 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 protected]<mailto:[email protected]>
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
