Subject: [TLS] Server Signature Algorithms

From: Michael D'Errico <[email-masked]>
Date: Thu, 29 Oct 2009 12:45:34 -0700

There are now at least 3 instances where a TLS client needs to know the
server's list of supported signature algorithms:

    1. to compute the signature for the CertificateVerify message
    2. to compute the hash of the handshake messages in (1) without
       having to hold onto all of the messages
    3. to compute hashes for the proposed cached information extension

Rather than duplicate the list for each of these and any future needs,
it makes sense to send it once in a server hello extension.

The simplest option would be to use the existing signature algorithms
extension and make it symmetrical.  But if there is a deployed client
out there that aborts a connection if it receives a signature algorithm
extension, then a secondary option would be to create a new server-
signature-algorithms extension which is identical in structure to the
existing extension.

I would add that when the server sends its list of algorithms in the
extension, then it MUST NOT send a different list in the certificate
request message; in fact it SHOULD send an empty list.  TLS 1.3 can
decide whether to eliminate the list from CertificateRequest.

Mike

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 29 Oct 2009 20:17:17 -0700

If the existing signature algorithms extension is made symmetric, then
the server still will need to put the same list of algorithms in the
certificate request since it will not know whether the client knows
about the change.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 31 Oct 2009 10:07:26 +0200

> signature-algorithms extension which is identical in structure to the

I also agree, this is an elegant solution to solve the fact that the
client needs to store all handshake messages in memory.

regards,
Nikos