Change:
root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space.  If the certificate_authorities list is empty, then the client MAY <del> send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary. The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. certificate_types has been present in TLS since SSL 3.0, but was somewhat underspecified.  Much of its functionality is superseded by supported_signature_algorithms.  The following rules apply: Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms. The end-entity certificate provided by the client MUST contain a key that is compatible with certificate_types.  If the key is a signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms. New ClientCertificateType values are assigned by IANA as described in iana-considerations. </del> <ins> send any certificate that meets the rest of the selection criteria in the CertificateRequest, unless there is some external arrangement to the contrary. A list of certificate extension OIDs RFC5280 with their allowed values, represented in DER-encoded format.  Some certificate extension OIDs allow multiple values (e.g.  Extended Key Usage). If the server has included a non-empty certificate_extensions list, the client certificate MUST contain all of the specified extension OIDs that the client recognizes.  For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well).  However, the client MUST ignore and skip any unrecognized certificate extension OIDs.  If the client has ignored some of the required certificate extension OIDs, and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the session without client authentication, or terminate the session with a fatal unsupported_certificate alert.  PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types. Depending on the type, matching certificate extension values are not necessarily bitwise-equal.  It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs.  This document defines matching rules for two standard certificate extensions defined in RFC5280: The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension. The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension. The special anyExtendedKeyUsage OID MUST NOT be used in the request. Separate specifications may define matching rules for other certificate extensions. </ins> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.

Discussion:
This PR includes CertificateRequest changes discussed at the TLS WG Interim: Removes certificate_types, which are no longer needed. Adds client cert selection by certificate extension values. This helps make CertificateRequest more specific and eliminate the need for the confusing "Choose a certificate" UI.