I've got some code that dumps TLS diagnostic info and realised it was
displaying garbage values for some signature_algorithms entries. Section
4.2.3 of the RFC says:
In TLS 1.2, the extension contained hash/signature pairs. The
pairs are encoded in two octets, so SignatureScheme valu
As we are currently working on a 8446-bis, the best thing to do would be to
file a PR at:
https://github.com/tlswg/tls13-spec
Thanks,
-Ekr
On Thu, Jul 15, 2021 at 3:56 AM Peter Gutmann
wrote:
> I've got some code that dumps TLS diagnostic info and realised it was
> displaying garbage values fo
The SignatureScheme change was perhaps overly clever, but the intent is
that you can process them the same at both versions and backport
the single-enum interpretation. (That's what we do.) The key observation is
that TLS 1.3's allocations will never overlap with a defined TLS 1.2 hash
or signature
Hi,
For those that have not already attending Netdev, Netdev conf 0x15 has been
running since July 7 but it runs for 3 weeks but the talk sessions don't
start until Monday. As usual a lot of IETF relevant talks.
See: https://netdevconf.info/0x15/accepted-sessions.html
The fee is USD $50. Students
Regarding
> so where 1.2 uses { hash, sig } 1.3 uses values equivalent to { sig, hash
}.
While some TLS 1.3 SignatureScheme enum values might appear to have the sig
in the upper octet and hash in the lower octet, that is not the case and
SignatureSchemes for TLS 1.3 only exist as combinations with
