Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy

That wasn’t important enough for to create a PR.

I did create PR 1044 to reconcile S4.2.3 and S11.

--
-Todd Short
// tshort@akamai.com
// "One if by land, two if by sea, three if by the Internet."

From: David Benjamin <davidben@chromium.org>
Date: Wednesday, July 5, 2017 at 1:53 PM
To: "Short, Todd" <tshort@akamai.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy

On Wed, Jul 5, 2017 at 1:46 PM Short, Todd <tshort@akamai.com<mailto:tshort@akamai.com>> wrote:
But the maximum value doesn’t have to be listed twice if it’s already part of a value.

Ah yes, you're right. My bad. I agree that line should not be there either.

So section 11 needs to change...

--
-Todd Short
// tshort@akamai.com<mailto:tshort@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Jul 5, 2017, at 1:22 PM, David Benjamin <davidben@chromium.org<mailto:davidben@chromium.org>> wrote:

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 <tshort@akamai.com<mailto:tshort@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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5226&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=5sk_b3-vIekmFErj0rRi5Gpm-jPXdqdlgGI7xYAILh4&e=>].  Values with the first byte 255 (decimal) are reserved

   for Private Use [RFC5226<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5226&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=5sk_b3-vIekmFErj0rRi5Gpm-jPXdqdlgGI7xYAILh4&e=>].

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
// tshort@akamai.com<mailto:tshort@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=EAWqDhMCo32S6c4de6RPEdpj7p-tif1Wz-ZbwHQRRaY&e=>