I agree we should use a different number than 26 for certificate compression. I don't see a problem with assigning 27 and reserving 26 for now.
On Wed, May 30, 2018 at 8:13 PM, Adam Langley <a...@imperialviolet.org> wrote: > 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
