> On Nov 21, 2018, at 4:50 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
>
> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here. Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is equivalent to an absent signature_algorithms
> extension (Section 7.4.1.4.1)
>
> [...]
>
> We think that treating an empty supported_signature_algorithms field
> as an error is the best response and plan to implement that change.
> We'll send a fatal alert if we receive one.
Sounds reasonable, provided the application did or would have actually
provided a client certificate to use. If the application would have
continued with an empty certificate list, and no CertificateVerify,
then hanging up is arguably counter-productive. Of course the server
should still not send a certificate request that could never be satisfied,
so perhaps snatching victory from the jaws of defeat is not worth the
trouble even when the client has no certificate to send?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
