On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton <noloa...@gmail.com> wrote: > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers > working group for their smart locks last year. I have no idea how much > of the code they are going to reuse (if any at all).
Chrome / Google is blocked on code-point assignment for deploying certificate compression. It appears that 26 is not a good pick and we thus wait in anticipation for a replacement. (The extensions space is effectively infinite: if we get close to running out, we can assign an "extended extensions" code point, which would contain a nested extensions block with 32-bit numbers instead. Therefore effort and delays resulting from treating it as a scarce resource are saddening. Speaking in a personal capacity, it looks like 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them randomly to avoid issues with concurrent applications and I offer 0xbb31 as a high-quality, random number. Since we had a triple collision in this case, random-assignment's virtues are currently particularly clear.) -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
