> On Mar 5, 2018, at 9:35 AM, Jörn Heissler <acme-sp...@joern.heissler.de> > wrote: > > On Mon, Mar 05, 2018 at 09:11:02 -0500, Felipe Gasper wrote: >> Regarding alternative formats, I think ACME over WebSocket would be a great >> thing. Replay-nonce would go away, and clients wouldn’t need to poll for the >> certificate unless the connection dropped. The server could send the >> certificate as soon as it’s ready. A simple handshake at the start could >> take the place of JWS, too. > > Moving to websocket would mean having to specify a new websocket based > protocol and reimplementing all servers/clients.
I would think “ACME/bidi” could live alongside ACME/HTTP. The bidirectional variant could be described in a separate RFC that gives the differences--which would basically just be how to translate the HTTP-specific parts of ACME/HTTP to “pure messages”. WebSocket wouldn’t necessarily be the only persistent-connection format; any reliable, message-oriented protocol (e.g., SCTP or WAMP “RawSocket”) could work. > You'd also need to consider MitM (e.g. by CDN or expensive enterprise MitM > appliances). Doing a handshake at the beginning won't be enough to keep > those from taking over a session after the handshake. > > If you wanted to eliminate the polling, it would be possible to change > the finalize endpoint to return the certificate directly, even if it > takes a while until the HTTP response is sent. This would alleviate the polling for the certificate but not for authz status. If I have an Order with, say, 5 authzs, I’ll still need to poll for the state of those. A transport layer that allows asynchronous server-to-client communication would facilitate quicker feedback to the client and a smoother user experience overall. -F _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
