Re: [TLS] TLS 1.2 hash agility

> I'm sorry, I don't understand your point: the client tells
> the server what algorithms it supports. A compliant server
> MUST NOT send a certificate with a different algorithm,
> but rather abort the connection.

You understood my point correctly, but it was flawed....

> You and I seem to be assuming different semantics here:
> the design I propose is not a negotiation. The client says
> "I will accept stuff signed with X" and the server does
> likewise. The only restriction is that the signer use an
> algorithm within the other side's set. These sets need
> not intersect.

The only thing we disagree on is where the server should
put its preferences.  You've convinced me that it doesn't
much matter technically.

> Remember that the signature over
> the client's certificate and CertificateVerify is for the 
> client's benefit, not the servers, and vice versa....

I thought that the signature over the client's certificate
was to prove to the server that you have the corresponding
private key, and therefore that you are the entity named in
the certificate (and deserve access to private information
about that entity).

Mike

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls