Draft: draft-ietf-tls-tls13

Commentary: The peer must advertise extensions before they can be sent with a certificate message . 
 I fixed it with a period . 
 statusrequest and signedcertificatestatus timestamps are allowed in the CertificateRequest message according to Certificate extensions ( ) however say : Is this also the intended behavior for client certificates , or should it instead require extensions to be advertised in CertificateRequest ? ( This is relevant for future extensions . ) No idea why a client would bother sending SCT or statusrequest extensions , but that is not forbidden by the TLS 1.3 spec . The status_request ( RFC 6066 ) and extensions are written such that it seems unusable in client certs though . 
 I 'd say it 's both - for those extensions to be in client side Certificate message they need to be both in   and in Certificate Request . That 's because any extensions in Certificate Request must have been first advertised in   
 That 's not correct . You can advertise stuff in CR that 's not in CH ( e.g. , X.509 OIDs ) .  , good catch . PR welcome . 
 that 's rather ugly - to this point only the cookie extension was of a " you support it even if you do n't advertise it " , I do n't like adding more exceptions to that rule ... 
 It 's been this way for some time . 
 It 's much simpler this way . As in the text EKR pointed to , extensions come in request / response pairs , so there is only one kind of flow to worry about . In your version , client certificate extensions have this weird three - phase bit which ends up meaning extra logic in implementations . This additionally is more flexible . Suppose I am willing to send an SCT on my client certificate , but I do n't have anything useful to do with the server one . ( The inverse is more likely for SCTs but consider a future bit of certificate metadata . ) In your version , there is no way to distinguish " I want an SCT " from " I wo n't explode if you request one of me " . 
 That 's what I meant - the Certificate Request ones are not described as " unsolicited " . I do n't think this is a useful distinction to make . But I digress . If we make all Certificate Request extensions unsolicited , that 's fine by me . But I think that it 's a significant change from TLS 1.2 , and should be documented as such . 
 TLS 1.2 had no extension mechanism for CertificateRequest : 
 CertificateRequest extensions were intended to be unsolicited , yeah .
Paragraph (version A):
A set of extension values for the CertificateEntry.  The
"Extension" format is defined in extensions.  Valid extensions
include OCSP Status extension (RFC6066) and
SignedCertificateTimestamps (RFC6962).  An extension MUST only be
present in a Certificate message if the corresponding ClientHello
extension was presented in the initial handshake.  If an extension
applies to the entire chain, it SHOULD be included in the first
CertificateEntry.
Paragraph (version B):
A set of extension values for the CertificateEntry.  The
"Extension" format is defined in extensions.  Valid extensions for
server certificates include OCSP Status extension (RFC6066) and
SignedCertificateTimestamps (RFC6962).  Extensions in the
Certificate message from the server MUST correspond to one from
the ClientHello message, extensions in the Certificate from the
client MUST correspond with an extension in the CertificateRequest
message from the server.  If an extension applies to the entire
chain, it SHOULD be included in the first CertificateEntry.