On 2018-11-26 02:09, Eliot Lear wrote:
> Hi Steffen
>
>
>> On 23 Nov 2018, at 20:27, Fries, Steffen <steffen.fr...@siemens.com> wrote:
>>
>> 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.
>
> Ok, well there we have it ;-)
>
>>>
>>>>
>>>> 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.
>
>
> Right. And so with this, I think we do indeed have some questions:
>
> Does the registrar have to play the role of “store and forward” and retain
> state or is it better to say, “Call me back another time”?
> If we do want the registrar to retain state, then intermediate states need to
> be defined in EST, and perhaps in other mechanisms as well, to say, “Do you
> have my credential now?”
> If we are assuming that the registrar and the CA are not co-resident, then
> there is a question of protecting the credential, as you mention. Should
> that credential returned be encrypted?
>
> And so the real question, to me, is whether or not we are handling the case
> where one has something of a roaming CA, where it is only present on
> occasion, or has to handle (re)enrolments periodically.
Coud you (both of you, because the answers might be different) give a concrete
description of the real-world scenarios you are thinking about? Because to
me, it isn't clear where these requirements are coming from.
In particular, are they part of autonomic networking, or do they fit
elsewhere?
Brian
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
