On Saturday 11 July 2015 17:09:27 Dave Garrett wrote: > On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote: > > Largely close enough. Feel free to borrow any text from the below > > that you find to be an improvement. > > > > ======================================== > > > > Whenever possible, all certificates provided by the server > > SHOULD be signed by a hash/signature algorithm pair indicated > > by the client's supported algorithms extension (or the defaults > > assumed in its absence). If the server cannot produce a > > certificate chain that is signed via only the indicated supported > > pairs, then it SHOULD continue the handshake by sending the > > client a certificate chain of its choice that may include > > hash/signature algoriths that are not known to be supported by > > the client. > > > > The public key in the leaf certificate must of course be > > compatible with the chosen cipher-suite, and the subsequent > > ServerKeyExchange message must be signed via a mutually supported > > hash/signature algorithm pair. > > > > If the client cannot construct a satisfactory chain using the > > provided certificates and decides to abort the handshake, then > > it MUST send an "unsupported_certificate" alert message and > > close the connection. > > > > ======================================== > > The middle bit is already in existing text above the section in question. > > New version with a little rewording and a typo fix. > > \/ > > ======================================== > 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. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
