The intent is that the server pick the most preferred signature algorithm that is supported and meets local policy. Given the local policy aspect of the server's choice, it can be any one offered by the client. The client should not offer any that are not acceptable according o their local policy.
Russ > On Nov 14, 2018, at 2:07 AM, Loganaden Velvindron <logana...@gmail.com> wrote: > > Hi folks, > > Bob Beck of OpenBSD/LibreSSL reported this issue with an implementation: > " > Fun fact: The TLS 1.2 signature algorithms extension is sent in client > preference order. http://outlook.office365.com <https://t.co/EOcbx3oZpI> > then chooses the least preferred. every time. > Additional fun fact: I believe it is still standards compliant. RFC5246 says > only that it must be sent by the client in preference order. It does not say > the server must respect the order. > " > My suggestion would be something like: > Section 7.4.1.4.1 <https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1>. > current text: > > Servers MUST NOT send this extension. TLS servers MUST support > receiving this extension. > > Suggestion: > Servers MUST NOT send this extension. TLS servers MUST support receiving this > extension. TLS servers MUST respect the order in which the signature > algorithms are sent by the client.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
