Hi Steffen > On 27 Nov 2018, at 11:49, Fries, Steffen <[email protected]> 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: > 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 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. Another alternative would be to refer to some 3rd player. To implement the store and forward, the registrar just needs a queue, but the pledge needs to remember the request (and any associated nonce). And I think that works out because any such behaviour would demand a few new EST RESTful endpoints. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
