> On Mar 12, 2018, at 22:46, Adam Roach <a...@nostrum.com> wrote: > > On 3/12/18 5:33 PM, Sean Turner wrote: >> >>> On Mar 12, 2018, at 19:58, Adam Roach <a...@nostrum.com> wrote: >>> >>> On 3/7/18 12:58 PM, Eric Rescorla wrote: >>>>>> - TLS SignatureScheme Registry: Values with the first byte in the >>>>>> range 0-253 (decimal) are assigned via Specification Required >>>>>> [RFC8126]. Values with the first byte 254 or 255 (decimal) are >>>>>> reserved for Private Use [RFC8126]. Values with the first byte in >>>>>> the range 0-6 or with the second byte in the range 0-3 that are >>>>>> not currently allocated are reserved for backwards compatibility. >>>>> Unless I misunderstand the compatibility mechanisms here, the reservation >>>>> of >>>>> first byte=0-6 seems to assume that no further assignments will be made >>>>> from >>>>> the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the >>>>> case, I >>>>> would expect the IANA considerations section to include a request that >>>>> the IANA >>>>> close the table to further registrations. The same comment applies to TLS >>>>> SignatureAlgorithm Registry. >>>> Agreed, but I'd like to hear from the chairs. >>> >>> I think we're still waiting to hear from the chairs on this topic. >>> >>> /a >> I think this got lost somewhere in the flurry of emails: >> >> See s17 of >> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >> We don’t close the registry because technically, if somebody really, really >> wanted to they could register values for earlier versions. > > Ah, thanks for the pointer. I don't agree with your evaluation that > draft-ietf-tls-iana-registry-updates preserves the ability to register values > for earlier versions, as it marks all remaining available codepoints > "reserved." That's effectively equivalent to what I'm asking for, though, so > my comment is addressed.
Subtly different but I’m glad you’re good with this ;) > There's still a potential mess brewing for the HashAlgorithm codepoints 224 > though 253 colliding with SignatureScheme values of 0xE000 - 0xFDFF, but it > seems pretty unlikely that SignatureScheme allocations will reach that point > before 1.2 and previous versions disappear. i may have been lazy when I just did 9-223. We could obviously remove this by marking 224-253 reserved for both the HashAlgorithm and SignatureAlgorithm registries. Note that there are also other unassigned values in 4-6 in SignatureAlgorithms and 7 in HashAlgorithm that should/could also be marked reserved. But, we can do that on the IANA draft in early April. spt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
