I added my detailed comment to the Github issue! My assumption now is that a single assertion enum in the Voucher is sufficient for all cases.
This assumes that for use cases where the vendor wants to enable or disable specific "features" in the Pledge right away during the onboarding process, vendor-specific extra fields in the Voucher can be used. That's more clean than trying to embed such information in the assertion field or a new "proximity" field or so. If we want to allocate a standard leaf (JSON map , CBOR map) for such vendor-specific info then this can also be defined in 8366bis. Esko -----Original Message----- From: Fries, Steffen <steffen.fries=40siemens....@dmarc.ietf.org> Sent: Tuesday, September 10, 2024 15:55 To: Michael Richardson <mcr+i...@sandelman.ca>; anima@ietf.org Subject: [Anima] Re: Question regarding use of assertions in vouchers in RFC8366bis Hi Michael, I put this as point for discussion in the related git (https://github.com/anima-wg/voucher/issues/63) My current assumption would be to introduce another voucher component, which relates to the MASA - customer relationship to avoid mixing all in one assertion (enum). This is more for to address potential future scenarios, as currently I would assume the pledge does not distinguish between different assertion components. Best regards Steffen > -----Original Message----- > From: Michael Richardson <mcr+i...@sandelman.ca> > Sent: Monday, September 9, 2024 9:11 PM > To: Fries, Steffen (T CST) <steffen.fr...@siemens.com>; anima@ietf.org > Subject: Re: [Anima] Re: Question regarding use of assertions in vouchers in > RFC8366bis > > > Fries, Steffen <steffen.fr...@siemens.com> wrote: > > Hi Esko > > > What irritates me is the statement in the YANG definition of RFC > 8366bis: > > "Indicates that the voucher has been issued after > > okay, so let's do better text. > > > Therefore the question for me is not quite answered, if the MASA gets a > > PVR with a nonce and is able to verify proximity, but does not know the > > customer domain, he could provide both values, "proximity" as he could > > verify that the pledge was in direct contact with the registrar and > > "logged" because he does not know the customer domain (maybe I'm > > relating to much in the "trust-on-first-use" statement in the YANG > > description, which I understand as trust-on-first-use for the MASA when > > seeing a PVR from an unknown domain. > > I think that I'd pick proximity. > > Some manufacturers and some device classes are reasonable for TOFU, some are > not. > In between full supply chain integration would be some kind of Trust-on-First- > Customer. > In that case, the customer domain has to be a known *customer*, but which > device > they get is TOFU. > It would be good to come up with words to explain this. > > If you think it should be reflected in the new/additional voucher types, I'm > certain > open to that idea. > > > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
