On 25 January 2013 17:32, Trevor Perrin <tr...@trevp.net> wrote: > On Fri, Jan 25, 2013 at 8:55 AM, Emilia Kasper <ekas...@google.com> wrote: >>> > We've already implemented 5878 for OpenSSL and Apache. The wider benefit >>> > of >>> > a more general mechanism is that adding new types of authorization data >>> > (Revocation Transparency?) will in the future not require upgrading >>> > servers >>> > again. >>> >>> But this isn't an inherent virtue of 5878, it's due to the CT team >>> adding functionality to OpenSSL and Apache that allows specifying >>> server responses in a data file [3]. The server can parse the data >>> file and return whichever responses the client asks for, without >>> needing code changes to know their meaning. >>> >>> That's a great mechanism, but why not apply it to TLS Extensions? >>> Then we could deploy CT's timestamps (or other server auth data) >>> without needing server code changes *or* 5878. >>> >>> That would be the best of both worlds, wouldn't it? >> >> >> I'm not sure I follow; do you mean specifying TLS extension data in a data >> file? > > Yes, I think you could do something much like the authorization data > file, except that the file would be a list of TLS Extension responses > instead of 5878 responses. > > For any ClientHello extensions the server receives that have empty > extension_data, the server would look through this extension file and > add corresponding responses to its ServerHello. > > >> Surely that doesn't work for arbitrary extensions... > > No, but it would work for simple TLS Extensions that are just stapling > some data into the handshake. So, it would support things like CT's > SignedCertificateTimestamps, TACK, or other things (you mentioned a > "Revocation Transparency"; some sort of DNSSEC/DANE stapling; etc.) > > Anyways, I think this would be a fantastically useful mechanism that > would ease the common burden of these various stapling proposals in a > simple, clean way. If you're interested, I'd love to help with the > implementation...
I rather like this idea. Help welcome :-) _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
