Correct, the producer and consumer of the voucher are by definition either the same organisation or two organisations having a business cooperation (includes joint interop testing). If two organisations, they could choose to only use standard fields in the voucher, or include organisation-specific fields with a custom data format that only they know.
Also the two organisations could agree on which of the standardized fields will be used: typically, only a subset is used. This is already assumed by present docs (BRSKI, cBRSKI). The Registrar optionally audits the voucher (in which case it's supposed to know about all the standardized fields in it). But for the voucher as defined in scope of 8366bis, the entire structure is signed - so no possibility to include removable parts there! In cBRSKI we do make use of removable parts but those are in the COSE signature structure (unprotected COSE header parameters), not in 8366bis scope. YANG rules don't apply there ;) Esko -----Original Message----- From: Toerless Eckert <[email protected]> Sent: donderdag 13 maart 2025 02:09 To: Joel Halpern <[email protected]> Cc: Michael Richardson <[email protected]>; Esko Dijk <[email protected]>; [email protected] Subject: Re: [Anima] Re: Hierarchy in YANG structures, CBOR-YANG delta encoding and vendor extendibility "Same guy processing" is what i think Eski and Michael would be happy with (vendor). Which is why from that perspective, standardization of the binary blob may not be required. I am trying to raise the desire for another guy (customer/operator) to also be able to process the information as part of standard security procedures at the edoge of an enterprise network. One side of communication (MASA) is outside of enterprise, the othre side is inside (pledge). The action of that observing party is to decode and analyze, maybe remove. E.g.: pretty much what advanced NAT/intrusion detection system would do as well. Except that we even have an application layer entity that can do it in case of BRSKI (registrar). Cheers Toerless On Wed, Mar 12, 2025 at 08:58:26PM -0400, Joel Halpern wrote: > 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 <[email protected]> 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 <[email protected]>, Sandelman Software Works > > > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > > > > > > > > > > > > -- --- [email protected] _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
