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> Sent: Friday, October 18, 2024 17:31 To: 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
