anima-wg / constrained-voucher

This is a repo for the IETF Internet Draft about constrained vouchers in CBOR
2 stars 4 forks source link

Clarify usage of "assertion" field in Registrar's Voucher Request #160

Closed EskoDijk closed 2 years ago

EskoDijk commented 3 years ago

RFC 8995 section 3.3 Figure 8: Registrar's Voucher Request (RVR) contains the "assertion" field. The Pledge's assertion statement is carried forward by the Registrar to MASA. In section 5.5: assertion field is not listed as being mandatory present in the RVR. It mentions "All other fields MAY be omitted in the registrar voucher-request." So this implies the "assertion" field may be omitted too.

Can the Registrar omit the "assertion" field and why? (Note the MASA currently has to be able to handle both inclusion and omission of the field.)

mcr commented 3 years ago

The RFC8366 YANG says that it's a mandatory field, right? I think that RFC8995 is wrong here then. What reason is there to omit it?

EskoDijk commented 3 years ago

RFC 8995 refines it to be optional in the Voucher Request as follows; so RFC 8995 isn't wrong if it says the field can be absent.

refine "voucher/assertion" {
           mandatory false;
           description
             "Any assertion included in registrar voucher-requests
              SHOULD be ignored by the MASA.";
         }

The description forgets to mention how assertion is used in general in a Voucher Request. It could be read as "don't include assertion in the RVR". From other text in RFC 8995 we know at least the Pledge needs to use an assertion in PVR.

EskoDijk commented 2 years ago

Text proposed in PR, keeping in mind that the RFC 8995 example uses it and there's no immediate reason to omit the assertion field in RVR.