Original text:
Structure of this message: <del> %%% Authentication Messages enum { rsa_sign(1), dss_sign_RESERVED(2), rsa_fixed_dh_RESERVED(3), dss_fixed_dh_RESERVED(4), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20), ecdsa_sign(64), (255) } ClientCertificateType; A list of the types of certificate types that the client may offer. </del>  A list of the hash/signature algorithm pairs that the server is <del> able to verify, listed in descending order of preference. </del>  A list of the distinguished names X501 of acceptable 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>  Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication. The certificate type MUST be X.509v3 RFC5280, unless explicitly negotiated otherwise (e.g., RFC5081). <del> The end-entity certificate's public key (and associated restrictions) has to be compatible with the certificate types listed in CertificateRequest: </del> If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs. Note that this relaxes the constraints on certificate-signing algorithms found in prior versions of TLS.  Note that, as with the server certificate, there are certificates that use algorithms/algorithm combinations that cannot be currently used with TLS. registries and their allocation policies (unchanged from RFC4346) are listed below. <del> TLS ClientCertificateType Identifiers Registry: Future values in the range 0-63 (decimal) inclusive are assigned via Standards Action RFC2434.  Values in the range 64-223 (decimal) inclusive are assigned via Specification Required RFC2434.  Values from 224-255 (decimal) inclusive are reserved for Private Use RFC2434. </del> TLS Cipher Suite Registry: Future values with the first byte in the range 0-191 (decimal) inclusive are assigned via Standards Action RFC2434.  Values with the first byte in the range 192-254

Reviewer comments:
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.

Revised text:
Structure of this message:  <ins> %%% Authentication Messages opaque DistinguishedName<1..2^16-1>; </ins> A list of the hash/signature algorithm pairs that the server is  <ins> able to verify, listed in descending order of preference.  Any certificates provided by the client MUST be signed using a hash/ signature algorithm pair found in supported_signature_algorithms. </ins> A list of the distinguished names X501 of acceptable 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  <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. The certificate type MUST be X.509v3 RFC5280, unless explicitly negotiated otherwise (e.g., RFC5081).  If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs. Note that this relaxes the constraints on certificate-signing algorithms found in prior versions of TLS. <ins> If the certificate_extensions list in the certificate request message was non-empty, the end-entity certificate MUST match the extension OIDs recognized by the client, as described in certificate-request. </ins> Note that, as with the server certificate, there are certificates that use algorithms/algorithm combinations that cannot be currently used with TLS. registries and their allocation policies (unchanged from RFC4346) are listed below.  TLS Cipher Suite Registry: Future values with the first byte in the range 0-191 (decimal) inclusive are assigned via Standards Action RFC2434.  Values with the first byte in the range 192-254