Original text:
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 <del> "certificate", or "deleagation certificate", and the one issued by the operator as a "delegated credential". </del>  2. 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 <del> are needed for this application. </del>  <del> Relative time in seconds from the beginning of the certificate's notBefore value after which the delegated credential is no longer valid. </del>  The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280.  The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. <del> The ProtocolVersion in which the delegated credential is to be used, where ProtocolVersion is as defined in the TLS 1.3 standard. The SignatureScheme of Credential.public_key, the signature scheme used by the server to sign the handshake. </del>  DelegatedCredential.scheme. <del> DelegatedCredential.cred. </del> The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and

Reviewer comments:
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 SignatureScheme 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.

Revised text:
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  <ins> "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential". </ins> 2. 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  <ins> are needed for this application.  The credential has the following structure: </ins>  <ins> Relative time in seconds from the beginning of the delegation certificate's notBefore value after which the delegated credential is no longer valid. The signature algorithm of the credential key pair, where the type SignatureScheme is as defined in the TLS 1.3 standard. The version of TLS in which the credential will be used, where the type ProtocolVersion is as defined in TLS 1.3. </ins> The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280. <ins> The delegated credential has the following structure: </ins> The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.  <ins> DelegatedCredential.cred. </ins> DelegatedCredential.scheme.  The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and