Hi Eliot I assumed it to be collocates with the RA and that the CA is separate.
Ok, well there we have it ;-) 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”? [stf] yes, store and forward would be what I have in mind. · 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?” [stf] This would be one way of doing it, although I’m not sure about the state enhancement as EST utilizes the binding to the TLS connection in the PKCS#10 request. And for an asynchronous operation, a self-containing container allowing a local (protected) storage may be better. This depends on the security of the domain registrar. There are further enrollment protocols, which feature this property. But from your answer before I gathered, that there is a 1:1 binding between BRSKI and EST. Technically, it should also be possible to also utilize alternative enrollment protocols. · 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? [stf] Probably not in every case. I would hope that each enrolling device is generating its key pair locally and only performs the certification request/response with the target PKI. But I’m sure there are also scenarios, in which also centrally generated keys is favored (e.g., if there is not sufficient entropy on the enrolling device). In the latter case encryption would be required. 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. [stf] Re-enrollment is an interesting question, but I think it could be handled in a similar way as the initial enrollment, assumed, it is initiated before the window of CA connectivity. Steffen Right? Eliot
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
