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
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to