On Fri, Jan 19, 2018 at 04:47:59PM +0100, Richard Barnes wrote: > On Fri, Jan 19, 2018 at 4:38 PM, Ilari Liusvaara <[email protected]> > wrote: > > > On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote: > > > > AFAICT, the hard constraints are: > > > > - No taking site offline when validating. > > - The validation certificates are not publically trusted. > > - SNI needs to be set to the domain being validated. > > - Compliant with reasonably strict reading of "10 methods" (which > > essentially impiles the third point and using certificate to > > transmit data). > > > > I'm less worried about this constraint. If there's consensus for a change, > changes can be made to the BRs much more quickly than an RFC can be issued.
Oh yeah, the minimum process latency for changing BRs is ~7 weeks. However, that would take well-fleshed proposal to do it even close to that quick. Take note that "10 methods" took years. > > (I do not consider compatiblity with present software a hard > > requirment). > > > > > > Few ways that come to mind: > > > > - Have "acme" ALPN and send validation certificate for that. > > - Have some new TLS extension and send validation certificate for that. > > > > My inclination here would be to do the whole thing in a TLS extension: Have > the client send its value in an extension, and have the server respond in > an extension. It's what they're there for. You would need upgrades to TLS > stacks and new API for this, but IIRC, QUIC is going to require some > similar changes to make applications aware of extensions anyway. (Cf. > https://github.com/bifurcation/mint/pull/137 for EKR's minq implementation > of QUIC) Yes, that is one way, if BRs are easy enough to change. If they are not, then just change where the reply is sent, and it is compliant. Also, I consider TLS-SNI type methods to be UNSUITABLE for validating usual webservers. Anything that the method is suitable for should have special case support anyway (e.g., I had support in one TLS library, before I ripped the code out). > Any approach that relies on overloading an existing TLS field make me > nervous. If the field is there for some other purpose, then it seems > inevitable that you'll run into bugs of more or less the character we've > hit two times already. Yeah, as I said, custom extension provodes slightly better guarantees. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
