On Tue, Jul 14, 2015 at 11:31:26AM +0200, Hubert Kario wrote:
> > ========================================
> > All certificates provided by the server SHOULD be signed by a
> > hash/signature algorithm pair indicated by the client's
> > "signature_algorithms" extension (or the defaults assumed in
> > its absence), where possible. If the server cannot produce a
> > certificate chain that is signed only via the indicated supported
> > pairs, then it SHOULD continue the handshake by sending the
> > client a certificate chain of its choice that may include algorithms
> > that are not known to be supported by the client. If the client
> > cannot construct an acceptable chain using the provided certificates
> > and decides to abort the handshake, then it MUST send an
> > "unsupported_certificate" alert message and close the connection.
> > ========================================
>
> What about the cert chain offered by client to server as a response to
> Certificate Request message?
>
> They are also under the limitation of using just the signature algorithms
> advertised as supported by server.
Exactly the same strategy should apply when client certificates
are in use, send compatible if possible, else send something you
have.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
