Draft: draft-ietf-tls-subcerts

Commentary: Based on There is currently no binding of the credential to the signature scheme used to sign the handshake . The field of the encodes the DC public key type ; but there 's not a one - to - one correspondence between X.509 's and TLS . Hence , the TLS terminator could use a signature scheme to sign the handshake other than the scheme intended by the delegator . To prevent this , this PR adds the  that the TLS terminator selects in the " signature_algorithms " extension to scope of the delegation signature . In addition , it makes this and the protocol version explicit parameters of the Credential structure . This is intended to make debugging easier .
Paragraph (version A):
To remove these dependencies, this document proposes a limited
delegation mechanism that allows a TLS server operator to issue its
own credentials within the scope of a certificate issued by an
external CA.  Because the above problems do not relate to the CA's
inherent function of validating possession of names, it is safe to
make such delegations as long as they only enable the recipient of
the delegation to speak for names that the CA has authorized.  For
clarity, we will refer to the certificate issued by the CA as a
"certificate", or "deleagation certificate", and the one issued by
the operator as a "delegated credential".
Paragraph (version B):
To remove these dependencies, this document proposes a limited
delegation mechanism that allows a TLS server operator to issue its
own credentials within the scope of a certificate issued by an
external CA.  Because the above problems do not relate to the CA's
inherent function of validating possession of names, it is safe to
make such delegations as long as they only enable the recipient of
the delegation to speak for names that the CA has authorized.  For
clarity, we will refer to the certificate issued by the CA as a
"certificate", or "delegation certificate", and the one issued by the
operator as a "delegated credential".
Paragraph (version A):
While X.509 forbids end-entity certificates from being used as
issuers for other certificates, it is perfectly fine to use them to
issue other signed objects as long as the certificate contains the
digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a
new signed object format that would encode only the semantics that
are needed for this application.
Paragraph (version A):
Relative time in seconds from the beginning of the certificate's
notBefore value after which the delegated credential is no longer
valid.
Paragraph (version B):
Relative time in seconds from the beginning of the delegation
certificate's notBefore value after which the delegated credential
is no longer valid.
Paragraph (version B):
The signature algorithm of the credential key pair, where the type
SignatureScheme is as defined in the TLS 1.3 standard.
Paragraph (version B):
The version of TLS in which the credential will be used, where the
type ProtocolVersion is as defined in TLS 1.3.
Paragraph (version A):
The ProtocolVersion in which the delegated credential is to be
used, where ProtocolVersion is as defined in the TLS 1.3 standard.
Paragraph (version A):
The SignatureScheme of Credential.public_key, the signature scheme
used by the server to sign the handshake.