Re: [TLS] TLS 1.2 and CertificateRequest message

[Michael D'Errico <[e-mail]>]

I remember participating in the discussion that led to this design.  I
argued that since we added a signature algorithms extension to allow
negotiation of the client's preferred algorithms, it made the most
sense to make the extension symmetric so the server could notify the
client of its preferred algorithms in its hello message as well.

There was opposition to my argument, that the list of algorithms belongs
where it is needed, in the certificate request message.  The term
"locality of reference" was thrown around as a justification.  Not being
an official member of the working group, and since nobody else seemed to
prefer my idea, I forfeited the point.

To solidify this design choice the definition of the signature algorithms
extension states that the server MUST NOT send it.

My own implementation holds onto all the handshake messages and calculates
the hashes of them when needed.  If you'd like to test interoperability
with my server, https://www.mikestoolbox.net will ask you for a client
certificate.

Mike


Nikos Mavrogiannopoulos wrote:
> Hello,
>  I've been taking a look at TLS 1.2 and it seems that there is some new
> negotiation added at the CertificateRequest message. At this message the
> server is supposed to send a list of allowed algorithm for signature
> calculation, and the client should respond with a signature that depends
> on the previously exchanged handshake messages.
> 
> In previous versions of TLS a client could just start the hash
> calculation for this signature during the exchange to avoid storing the
> actual messages up to this point. However with this negotiation at this
> point it is quite impossible to do that approach and as far as I
> understand needs to follow the store approach.
> 
> My questions now are:
> 1. How is this implemented in compliant software today?
> 
> 2. Why this negotiation was added? I see no added value of having such
> negotiation at a so late point.
> 
> regards,
> Nikos