Hi everyone, We are currently in the process of discussing different scenarios and approaches for the onboarding of (IoT) devices in plants, substations, or cloud-based services. The current BRSKI document provides here a good approach to address the case in which a pledge has an online connection to a domain registrar to request a voucher for enrolling in a target domain including the enrollment at the PKI. For the enrollment there exists the binding between the certification request (as PKCS#10 object) and the communication connection. I would see this as synchronous approach, as the interaction between the pledge and the domain registrar and also the PKI (CA) is based on a "live" communication connection.
Besides this, we see further use cases, in which the connection to the PKI is not always available. This may be the case if the connection to the CA is only temporary available or not directly available. Here, the approach would require a rather asynchronous handling. In such a setup the domain registrar could for instance store the object (certification request) and forward it upon connectivity to the PKI for further processing. The forward may be based on a communication connection or even manually. This asynchronous approach requires that the object itself is self-protecting ensuring its integrity (like a PKCS#7 wrapping of the PKCS#10 request or similar). Based on the specified BRSKI features, we did not see the support for this type of requirements directly. Before starting a discussion about potential solution approaches, I would like to get some sense, if this use case is also considered as target scenario for BRSKI. If yes, are there already ideas on how to address asynchronous objects? We already had some discussion in our group about potential approaches to handle such an requirement and I think it could be an interesting enhancement of a domain registrar to support both use cases, synchronous and asynchronous object processing. Since the domain registrar should be less restricted than the onboarding devices, the devices could have an option which approach to choose. Any thought on this? Best regards Steffen -- Steffen Fries Siemens AG, Corporate Technology
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
