Randy Armstrong (OPC) <[email protected]> wrote: > It would be easy to drop in a OPC UA aware registrar and implement all > of the BRKSI flows back to the MASA. The only nuisance factor is the > 'prior-signed-voucher-request'. If MASA's are willing allow this field > to be omitted and to trust the Registrar then nothing more needs to > done. If MASA's need this field then we could get it from the Device > via OPC UA but producing the CMS message adds an additional burden on > low end devices (i.e. the need to pull in libraries that provide the > same functionality as OPC UA but do it in different format).
Please spend some time reading RFC8366 and RFC8572 (SZTP). prior-signed-voucher-request is how BRSKI establishes proximity over a local TLS connection, and you seem to want to avoid that technology. That's not the only kind of *voucher request*, and RFC8366 allows vouchers to have other kinds of assertions. It sounds like you would be very happy with supply-chain integration of vouchers, and the RFC8572 use of "verified" vouchers would fit well. In order to support resale, some mechanism of updating the trust anchors would have to be profiled. RFC8572 uses CMS signed JSON for vouchers, and for some configuration assertions, and while RESTCONF is an option, it's not the only option. I have downloaded the OPC documents, and I'll skim them tomorrow. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
