On 2018-11-29 00:26, Fries, Steffen wrote:
> 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.
Yes, I think we are in agreement, +- some terminology.
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
