Draft: draft-ietf-tls-tls13

Commentary: This PR includes CertificateRequest changes discussed at the TLS WG Interim : certificate_types , which are no longer needed . client cert selection by certificate extension values . This helps make CertificateRequest more specific and eliminate the need for the confusing " Choose a certificate " UI .
Paragraph (version A):
A list of the types of certificate types that the client may
offer.
Paragraph (version A):
A list of the hash/signature algorithm pairs that the server is
able to verify, listed in descending order of preference.
Paragraph (version B):
A list of the hash/signature algorithm pairs that the server is
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.
Paragraph (version A):
A list of the distinguished names X501 of acceptable
certificate_authorities, represented in DER-encoded format.  These
distinguished names may specify a desired distinguished name for a
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
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.
Paragraph (version A):
Any certificates provided by the client MUST be signed using a
hash/signature algorithm pair found in
supported_signature_algorithms.
Paragraph (version A):
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.
Paragraph (version A):
New ClientCertificateType values are assigned by IANA as described in
iana-considerations.
Paragraph (version B):
A list of the distinguished names X501 of acceptable
certificate_authorities, represented in DER-encoded format.  These
distinguished names may specify a desired distinguished name for a
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
send any certificate that meets the rest of the selection criteria
in the CertificateRequest, unless there is some external
arrangement to the contrary.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Separate specifications may define matching rules for other
certificate extensions.
Paragraph (version B):
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.
Paragraph (version A):
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.