On Fri, Oct 25, 2019 at 7:03 AM Stephen Farrell <[email protected]> wrote:
> > > On 25/10/2019 14:45, Eric Rescorla wrote: > > Are you suggesting that these strings appear on the wire in DNS? > > Nope. > > > Or is this > > just an internal implementation covnenience? > > A bit more than that, but yes. I have a (temporary) tool for > generating these files and then need to import the output from > that into e.g. nginx or lighttpd. Some applications support > more than one TLS library, so having a well defined format > seems like it'd help with ESNI deployment. > > Basically this is the same logic that lead to pkcs8 PrivateKey > being worth documenting in an RFC. > OK. I don't think this needs to be documented in this draft, but if you wanted to write some other draft.... -Ekr > Cheers, > S. > > > > > -Ekr > > > > > > On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell < > [email protected]> > > wrote: > > > >> > >> Hiya, > >> > >> To date, my ESNI code [1] has been dealing with files containing > >> the binary encoding of ESNIKeys and a separate PEM file containing > >> the related private key. > >> > >> As part of getting nginx to work with ESNI [2], it'd be easier > >> for me to deal with a single file containing both private key > >> and the ESNIKeys (or ESNIConfig) value. (One of the upstream > >> maintainers didn't like how I handled configuring ESNI, so the > >> change is really to make him happier, but I think it's likely > >> a generally useful thing:-) > >> > >> Since mixing binary and PEM encoding in one file would be ickky, > >> it'd be nice if we had a PEM file convention for the public keys > >> used in ESNI. And of course, it'd be much nicer if everyone did > >> the same thing here. > >> > >> What I'm coding up now would handle files like: > >> > >> " > >> -----BEGIN ESNIKEY----- > >> > >> > /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6j > >> /gAAAABc995+AAA= > >> -----END ENSIKEY----- > >> " > >> > >> ...where the content is (unsurprisingly:-) a base64 encoded ESNIKeys. > >> > >> And if both the private and public components are in one file, > >> it'd look like: > >> > >> " > >> ----BEGIN PRIVATE KEY----- > >> MC4CAQAwBQYDK2VuBCIEICAHxXknil9tI2qZ+USRouNwXp0LxlUB85l0/xbhZ4Va > >> -----END PRIVATE KEY----- > >> -----BEGIN ESNIKEY----- > >> > >> > /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6j > >> /gAAAABc995+AAA= > >> -----END ENSIKEY----- > >> " > >> > >> I'd be happy to change that however increases the probability > >> that other code bases do the same thing. > >> > >> If this is useful, I could do up a PR with a bit of text saying > >> to use "ESNIKEY" (or whatever) as the label when storing these > >> things in PEM files. Given RFC7468 documents other PEM file > >> things, it seems reasonable to do the same for ESNI. > >> > >> Cheers, > >> S. > >> > >> [1] https://github.com/sftcd/openssl/tree/master/esnistuff > >> [2] https://github.com/sftcd/nginx > >> _______________________________________________ > >> TLS mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/tls > >> > > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
