Hi Brian, > > [stf] Agreed. Although I’m not sure if store and forward could be solely a > > functionality of the domain registrar and not necessarily a > new component. > > 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? 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. > > I don't see any reason why the pledge-proxy-registrar chain would change in > any way. It's only obtaining the voucher that needs to be > asynchronous, to avoid the need for real-time communication with the MASA.
[stf] The communication chain as pledge-proxy-registrar would not change. Following your argumentation I actually see two asynchronous objects. One is the voucher (for which I thought the nonce-less variant could be used as asynchronous object). The other one is the PKCS#10 request. If the RA/CA is a separate component, to which the domain registrar has not a synchronous connection, the certificate request also needs to be handled in an asynchronous way. The domain proxy for instance may collect several certification requests from enrolling pledges and forward the requests to the RA/CA when available. Steffen _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
