0xFFFF is just the syntax for the maximum value in the enum.
The intent was to match the HashAlgorithm registry which makes 0xFE and
0xFF the private use values, so I would say the enum is correct and the
IANA considerations text is wrong. This ensures we don't collide with any
existing TLS 1.2 private use allocations.
On Wed, Jul 5, 2017 at 1:05 PM Short, Todd <tsh...@akamai.com> wrote:
> In section 4.2.3 the definitions oaf the signature scheme are thus:
>
> enum {
>
> ...
> /* Reserved Code Points */
> private_use(0xFE00..0xFFFF),
> (0xFFFF)
>
> } SignatureScheme;
>
>
> This indicates that if the first byte is 254 (0xFE) or 255 (0xFF), that is
> is for private use. However, in section 11, a new registry is defined for
> signature schemes:
>
> - TLS SignatureScheme Registry: Values with the first byte in the
> range 0-254 (decimal) are assigned via Specification Required
> [RFC5226 <https://tools.ietf.org/html/rfc5226>]. Values with the first
> byte 255 (decimal) are reserved
> for Private Use [RFC5226 <https://tools.ietf.org/html/rfc5226>].
>
>
> Indicates that values with the first byte of 254 are reserved/assigned,
> and that private use is for values with a first byte of 255.
> In addition, the value of 0xFFFF is listed twice in the SignatureScheme
> enumeration.
>
> I can do a PR, but it needs to be decided wether 0xFE is reserved/assigned
> or private_use, and whether 0xFFFF has any special value.
>
> --
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
