Draft: draft-ietf-tls-subcerts

Commentary: Based on The delegation certificate MAY have the DelegationUsage extension marked critical . This also adds a " strict " flag to the extension that , if set , requires the server to offer a DC . An alternative that was discussed is to add an optional TLS - feature extension ( per RFC 7633 ) that would provide a " must - use - DC " feature , analogous to " must - staple - OCSP " . Howver , it 's possible for a certificate with such an extension to be used in a handshake without DCs if the client does n't indicate support for DCs .
Paragraph (version A):
A client which supports this document SHALL send an empty
"delegated_credential" extension in its ClientHello.  If the client
receives a delegated credential without indicating support, then the
client SHOULD abort with an "unexpected_message" alert.
Paragraph (version A):
If the extension is present, the server MAY send a delegated
credential extension.  If the extension is not present, the server
MUST NOT send a credential.  A credential MUST NOT be provided unless
a Certificate message is also sent.  The server MUST ignore the
extension unless TLS 1.2 or later is negotiated.
Paragraph (version A):
When negotiating TLS 1.3, and using delegated credentials, the server
MUST send the delegated credential as an extension in the
CertificateEntry of its end-entity certificate; the client SHOULD
ignore delegated credentials sent as extensions with any other
certificate.  When negotiating TLS 1.2, the delegated credential MUST
be sent as an extension in the ServerHello.
Paragraph (version B):
A client which supports this document SHALL send an empty
"delegated_credential" extension in its ClientHello.  If the client
receives a delegated credential without indicating support, then the
client MUST abort with an "unexpected_message" alert.
Paragraph (version B):
If the extension is present, the server MAY send a delegated
credential extension; if the extension is not present, the server
MUST NOT send a delegated credential.  A delegated credential MUST
NOT be provided unless a Certificate message is also sent.  The
server MUST ignore the extension unless TLS 1.2 or later is
negotiated.
Paragraph (version B):
When negotiating TLS 1.3, the server MUST send the delegated
credential as an extension in the CertificateEntry of its end-entity
certificate; the client SHOULD ignore delegated credentials sent as
extensions to any other certificate.  When negotiating TLS 1.2, the
delegated credential MUST be sent as an extension in the ServerHello.
Paragraph (version A):
Conforming CAs MUST mark this extension as non-critical.  This allows
the certificate to be used by service owners for clients that do not
support certificate delegation as well and not need to obtain two
certificates.
Paragraph (version B):
The extension MAY be marked crititcal.  (See Section 4.2 of RFC5280.)
If the strict boolean is set to true, then the server MUST use
delegated credential in the handshake; if no delegated credential is
offered, then the client MUST abort the handshake with an
"illegal_parameter" alert.
Paragraph (version B):
Marking the delegation certificate's DelegationUsage extension non-
critical allows the certificate to be used for clients that do not
support delegated credentials.  However, it may be desirable to
ensure that the delegation certificate is only used in handshakes in
which a delegated credential negotiated.  It suffices to mark the
extension crticial and set the strict boolean to true: if the client
does not support delegated credentials, then it will abort the
handshake if the certificate has the DelegationUsage extension (as
per Section 4.2 of RFC5280); if the client indicates support, but the
server does not offer a delegated credential, then the client will
abort the handshake (as per certificate-requirements).