> On Mar 5, 2018, at 3:50 PM, Felipe Gasper <fel...@felipegasper.com> wrote: > > >> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman <mharde...@ipifony.com> >> wrote: >> >> Especially with CT logging being a pragmatic requirement, time-to-delivery >> for certificates is likely to increase (slightly) rather than decrease. > > Quick point: the alleviation of polling would go for authz status as well as > to certificate delivery. > > A certificate order that has 10 domains needs to poll for the status of all > 10 of those domains’ authorizations as well as the certificate issuance. > “ACME/bidi” would remove all 11 of those needs to poll. >
While it eliminates the need for those 11 targets to poll for, it adds the not insignificant infrastructure cost of nailing up a stateful connection. It’s worth mention that the past decade has seen massive improvements in the network stack from the low layer up through application layer apis as it would pertain to handling a great many of these connections, but there is still some cost to nailing up large numbers of concurrent connections. As others note, h2 offers numerous models under which you could achieve the same benefits of getting asynchronous return of results over a single TCP session. I would think that even if you have a clear, consistent, bidirectional communication channel that it would still make sense for the individual message content to remain unchanged. (Not optimizing out replay-nonce, etc.) As a general matter, protocols dealing with security and integrity probably achieve better and stronger implementations in the field when variability and supported cases are reduced to the minimum required to achieve the protocol’s goals. Where possible, I would think removal of edge cases, exceptions, and different handling for different messaging protocols would be a positive value. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
