Hi Eliot On 27 Nov 2018, at 11:49, Fries, Steffen <steffen.fr...@siemens.com<mailto:steffen.fr...@siemens.com>> wrote:
Getting back to my original question, do you see the asynchronous handling of pledge enrolment as part of the current charter of the working group? I don’t know (I'll leave the to the chairs). Assuming yes: [stf] okay :-) If yes, would you rather expect to see EST enhanced to handle asynchronous support or would it be better to allow for alternative enrolment protocol support on the domain registrar featuring the handling of self-contained objects? As the domain registrar is likely to be not a constraint device as a pledge, this choice could technically be provided, while the pledge has the freedom to choose, which enrolment to use. If the domain registrar is not there, that’s an easy one, right? Device just has to retry until the registrar is present (assuming it’s trying to onboard). Do you have requirements for more than that? If the domain registrar is there and the CA is not there, there are seemingly two choices: * Store and forward from the registrar; or * Reject the request until the CA is present [stf] yes, I would favor the first one. If we add a 3rd approach of forwarding to some intermediary component, then *it* has to store and forward. In any case, the registrar needs to return a status to the pledge, saying, “Thanks for checking in… check back with me in X minutes” (where X might be some value that can back off based on load. [stf] I think the registrar could do the store and forward. The registrar may even be co-located a local RA. Another alternative would be to refer to some 3rd player. [stf] yes, but this would need to be provided by the registrar as URI in some return message. To implement the store and forward, the registrar just needs a queue, but the pledge needs to remember the request (and any associated nonce). [stf] yes, this could be probably be handled by the state machine of the enrollment protocol. And I think that works out because any such behaviour would demand a few new EST RESTful endpoints. [stf] Hm. That would pose some requirements on the storage of the certification requests on the registrar, as EST protects the transport not necessarily the “rest”. This is where I referred to self-contained. If the registrar would support further enrollment protocols like CMP or SCEP it could easily store the request, until the RA or PKI becomes available. Eliot
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
