Hi Eliot OK, thanks. I'm interested in another scenario too: one where the operator will not accept using a connection to the open Internet and therefore will not accept any real-time access to any MASA. As I've said for several years, this is a highly likely scenario in some types of network which insist on air-gap security or for some other reason do not trust a MASA (see Randy Bush's comments a few weeks ago, e.g. https://mailarchive.ietf.org/arch/msg/anima/rK_rlT3JH0AFGlS47XSRqQB2DJI ).
For such networks the only solution I can see is that all MASAs are replaced by a single OASA (Operator Authorized Signing Authority) that is configured and controlled by the operator. It handles the Registrar-MASA protocol and returns vouchers exactly like a MASA, except that it emphatically isn't on the global Internet. The OASA would procure a long-life voucher (normally from the relevant MASA, via a nonceless registrar voucher-request) when a device is purchased and added to inventory, and then deliver that voucher or a short-term voucher when a registrar needs it. Instead of using the MASA URL for each manufacturer, registrar-to-OASA connections all use a locally defined URL for the OASA. Otherwise the protocol is standard BRSKI. Any thoughts? Yes, several. First, there is now a mailing list that is related to this, iot-onboard...@ietf.org<mailto:iot-onboard...@ietf.org>. This is a follow-up to the side meeting that took place at the IETF where we are at least documenting existing mechanisms and requirements. There is a GitHub repo https://github.com/iot-onboarding that people can commit into. We haven’t yet started the requirements aspect, except in as much as we are asking “How" [stf] Thank you for pointing that out. I already subscribed to the list. I completely agree, discussing the requirements is crucial. That was the reason I asked for the support of asynchronous handling. Second, I agree that there is a desire to handle the case where onboarding doesn’t go all the way out the door to the vendor. I think that is one use case, and a separate use case is where onboarding does. To me this boils down to a combination of Join Registrar functionality and a means to communicate proof of possession / proof of ownership to the device through that registrar. Let’s not create new entities if we can at all avoid doing so. [stf] Agreed. Although I’m not sure if store and forward could be solely a functionality of the domain registrar and not necessarily a new component. Getting back to my original question, do you see the asynchronous handling of pledge enrolment as part of the current charter of the working group? If yes, would you rather expect to see EST enhanced to handle asynchronous support or would it be better to allow for alternative enrolment protocol support on the domain registrar featuring the handling of self-contained objects? As the domain registrar is likely to be not a constraint device as a pledge, this choice could technically be provided, while the pledge has the freedom to choose, which enrolment to use. Steffen
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
