Is there an assumption that the guy providing the blob and the guy
processing the blob are from the same vendor? (E. G. The Blob is
provision by the processor, and then sent as opaque by the device to a
processor from the same source as the provisioner)? Otherwise, I don't
see how this is interoperable? (I can understand why it may be
desirable, but we standardize things that interoperate.)
Yours,
Joel
On 3/12/2025 8:40 PM, Toerless Eckert wrote:
Why can't we simply have an array of records in the voucher model,
where each entry has an "IDentifier" , a boolean "public" and a binary value
blob.
If public=true it means that the syntax and semantic of the binary blob is
publically documented. We would have to figure out what the best way is to
provide a way for vendors to publish such information in a way that automated
software can best, ideally automatically find it.
PEN based IDentifier sounds like a good way to minimize administrative overhead
for IDentifier registration. It does not eliminate the problem of how to
most easily publicise the syntax/semantics of the binary blob.
The benefit of the "public" boolean is that registrar operators worried about
unknown side-channels would know whether they simply should prohibit the
side-channel (if its not public), or figure out how to hunt down the
syntax/semantics
so that it could be encoded.
Another issue that would be good to resolve, whether one likes the proposal so
far
or not: If the registrar operator does not like a secret side-channel, instead
of
failing the whole voucher communications immediately, maybe it would make sense
to
remove the array element thats undesirable. Of course, in that case each array
element would need its own separate integrity field and the overall voucher
integrity
could not include these "removable" extensions.
Cheers
Toerless
On Wed, Mar 12, 2025 at 05:25:46PM -0400, Michael Richardson wrote:
Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
> 1) new attributes in a standardized way (e.g. defined by IETF or
> others, vendors themselves). We are looking for a method of extending
> that's easier than spinning a new RFC each time that includes all the
> combined changes in one YANG model. E.g. something using a registry.
> The extending party would have to know YANG a bit; but not be an expert
> on YANG or what "augment" means and can/cannot do.
This was in the PR:
https://github.com/anima-wg/voucher/pull/79
> 2) vendor-specific data Created by MASA, consumed by Pledge. The data
> is not complying to a YANG model. Vendor / implementer knows near
> nothing about YANG/modules and wants to stay as far as possible from
> that.
> I understand that we wanted to tackle 1) in RFC8366bis, while 2) is
> under discussion - maybe.
https://github.com/anima-wg/voucher/pull/81
> While PEN-based spaces works for 1), it doesn't address case 2). For
Doing PEN-based SID allocation is still worth doing.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
