Re: [TLS] ESNI PEM files

On Fri, Oct 25, 2019 at 7:03 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <
> stephen.farrell@cs.tcd.ie>
> > 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
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> >
>