Re: [Anima] BRSKI support for asynchronous processing
Hi Eliot 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. I think the way to put this is that the Registrar is assumed to be integral/co-resident with the CA. I assumed it to be collocates with the RA and that the CA is separate. 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. To be clear, are we concerned about the EST request or the BRSKI request? The CA need not be available for BRSKI, but it does need to be available for EST. I should have been more specific. I was referring to the EST request. The BRSKI request regarding the voucher is assumed to a proxy residing inside the plant. I assumed a strong binding of EST and BRSKI. Steffen ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] BRSKI support for asynchronous processing
Hi Steffen > On 23 Nov 2018, at 17:53, Fries, Steffen wrote: > > 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. I think the way to put this is that the Registrar is assumed to be integral/co-resident with the CA. > > 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. To be clear, are we concerned about the EST request or the BRSKI request? The CA need not be available for BRSKI, but it does need to be available for EST. Eliot signature.asc Description: Message signed with OpenPGP ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] BRSKI support for asynchronous processing
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 Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
