> On 14 Dec 2016, at 3:33, Martin Thomson <martin.thom...@gmail.com> wrote: > > On 13 December 2016 at 22:47, Yoav Nir <ynir.i...@gmail.com> wrote: >> 2. Change 4492bis: >> a. no new curves for ed25519 and ed448. >> b. Two new signature algorithms, and request values 7 and 8 for them. >> c. new hash algorithm 0x08 and call it something like “intrinsic” > > This, but with a small tweak: don't treat these values as requiring > special reservation (as we have done for existing hash/signature > values). > > Rather than blocking out all 0x08 hashes, which might be the > consequence of this change, we can say that a hash of 0x08 AND either > 0x07 or 0x08 identify these signature schemes. We need to be able to > allocate 0x0809 at some point later.
Aren’t we going to have separate registries for 1.2 and 1.3? We don’t want to force anyone to make the changes you had made (as part of 1.3) just to get EdDSA..And I need to request things from IANA based on 1.2 registries. > Maybe also include a reference to TLS 1.3 (informative only) and > mention that this is compatible with the change from SignatureAndHash > to SignatureScheme in TLS 1.3. Already got a reference to 1.3. Might as well add this. > Like Ilari, I have backported the TLS 1.3 change to TLS 1.2 and it > works fine. It actually fixed some old bugs (such being unable to > sign with P-521 and SHA-256, but trying anyway). The hashed input to P-521 is treated as a number. Why doesn’t it work if the number is smaller? Note that even SHA-512 is 9 bits “too small”. It’s the other way around that is challenging. But even that is well-defined. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
