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

ot; Cc: "" Subject: Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy On Wed, Jul 5, 2017 at 1:46 PM Short, Todd mailto:tsh...@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: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy

On Wed, Jul 5, 2017 at 1:46 PM Short, Todd 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 > // tsh...@akamai.

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

But the maximum value doesn’t have to be listed twice if it’s already part of a value. So section 11 needs to change... -- -Todd Short // tsh...@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 mailto:d

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

0x 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 pr