Hi Esko, At the first glimpse I also assumed the MASA may add additional field, but it is not described in the draft. Specifically I assumed it must be specified in YANG as well. I think specifically in the case you mentioned, were the Registrar is also operating on the Voucher, it would be necessary to at least define an extension mechanism, which allows the registrar to handle extensions, which he may not know. Here, I was not sure if it could be handled by an OID for the manufacturer and an opaque container, which can be filled by the manufacturer. That way, the pledge for sure should be able to consume it, the registrar needs the mapping of manufacturer OID and structure of the opaque container, to evaluate it.
Best regards Steffen From: Esko Dijk <esko.d...@iotconsultancy.nl> Sent: Monday, October 21, 2024 10:07 PM To: Fries, Steffen (FT RPD CST) <steffen.fr...@siemens.com>; anima@ietf.org Subject: RE: Voucher Extensibility in RFC 8366bis This would be very useful to add. Initially I thought that a vendor can always extend the voucher with vendor-specific fields: since the MASA creates it and the Pledge consumes it, and both are from the same vendor, so the vendor can do what it wants. But, there's also a Registrar in the middle doing possibly a check of the voucher; and the Registrar is not of the same vendor. So we may need a formal defined 'container' item wherein all the further leafs/containers are vendor-specific. This approach is overall better and the Registrar knows where to expect any vendor-specific fields. A single field/leaf only would seem rather limiting, or not? Esko From: Fries, Steffen <steffen.fries=40siemens....@dmarc.ietf.org<mailto:steffen.fries=40siemens....@dmarc.ietf.org>> Sent: Friday, October 18, 2024 17:31 To: anima@ietf.org<mailto:anima@ietf.org> Subject: [Anima] Voucher Extensibility in RFC 8366bis Hi, As we are currently revising RFC 8366 I've got a question regarding the definition of leafs in the voucher. In the current version of the voucher definition there is no leaf, which allows to provide additional (vendor specific) values to the pledge. Would it make sense to allow this extensibility by providing an optional opaque leaf for this? Background for the question is that we are currently discussing a migration path from an existing onboarding approach to BRSKI support. Having at least the option to provide additional values may ease the switch to BRSKI by keeping information in the voucher, which is currently used in addition. Best regards Steffen -- Steffen Fries Siemens AG
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
