On Wed, Jul 5, 2017 at 12:50 AM, Martin Thomson <martin.thom...@gmail.com> wrote:
> On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > > So my question is why not go for the simpler approach and create new > > identifiers for the new signature algorithms? (similarly to RSA-PSS). > > Is there an advantage of re-using the ECDSA signature algorithm > > identifiers to mean something different in TLS 1.3? Was there some > > discussion on the topic on the list? > > > This was fairly extensively litigated. I remember Hannes asking > exactly the same question, but I forget which in-person meeting it > was. It might have been IETF 97. > > Unfortunately, any search I do on this subject turns up the hundreds > of emails on using signature algorithms for selecting certificates. > > What I've found is that this isn't that difficult to implement > correctly, even across versions. As David Benjamin suggested in > earlier emails, you can change to using a 16-bit codepoint in your > code. Then you add a curve-matching restriction if the selected > version is TLS 1.3 (or greater). > Well, it depends on the definition of correctly :) You can certainly have interoperation following something similar to what you describe, however the question is what about semantics. How do you translate that to the user? If one is careful with semantics and would like to let the user specify a policy of allowed operations/signature algorithms, he would have to specify two different signature algorithms, one for ecdsa with any curve, and another for the restricted to secp256r1, and then make sure that what is sent over the wire will be interpreted according to the policy by a TLS 1.2 or a TLS 1.3 server (which I find it quite impossible for any policy which requires anything else than a single curve and signature algorithm). That's why my question is on what is the advantage of the code point re-use, because I see only disadvantages. regards, Nikos
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
