ニュースソース：TLSWG
TLS1.3のInternet-Draftが発表されました。
以下は2017年4月4日に公開されたThe Transport Layer Security (TLS) Protocol Version 1.3の証明書についての記載を要約したものです。
認証：
チャネルのサーバー側は常に認証されます。クライアント側はオプションで認証されます。認証は、非対称暗号（RSA、ECDSAなど）または事前共有鍵（PSK）を介して行われます。
PSK（事前共有鍵）以外の鍵交換方法を証明書認証に使用する場合、サーバーは証明書チェーンを含む証明書メッセージを送信します。
クライアントはサーバーがCertificateRequestメッセージによってクライアント認証を要求した場合にのみ、証明書メッセージを送信しなければなりません。
クライアントに適切な証明書がない場合は、証明書を含まない、つまり、空の “certificate_list”フィールドを含む証明書メッセージを送信しなければなりません。
certificate_request_context
このメッセージがCertificateRequestに対応している場合はcertificate_request_contextの値。サーバ認証の場合は値なし。certificate_list
CertificateEntryのチェーン。各々が1つの証明書と拡張値セットを含む。送信者の証明書はリストの最初のCertificateEntryに入っていなければならない。
次の証明書は、その前の証明書を証明する順番に並んでいる必要があり、 送信者の証明書は最初のCertificateEntryに入っていなければならない。トラストアンカーは事前の合意があれば省略可。拡張機能:
CertificateEntryの拡張値のセット。チェーン全体に適用される場合は最初のCertificateEntryに含める。
注：
TLS1.3より前のバージョンでは、実装段階で各証明書の順番に柔軟性を持たせることが可能でした。
TLSのバージョンの過渡期に対応し互換性を持たせるために、最初のエンドエンティティ証明書に続く証明書が任意の順序で任意のTLSバージョンの可能性があることを考慮に入れて実装する必要があります。
さらに、サーバのcertificate_listには常に値が入っている必要がありますが、クライアントは送信する適切な証明書がない場合、空のcertificate_listを送信することにも配慮する必要があります。