Draft: draft-ietf-tls-subcerts

Commentary: As discussed in and subsequent . 
 I have responded to the two comments . No idea why  is busted . 
 looks like the CI segfaulted :) I 'll manually test locally and merge 
 Please add yourself to acknowledgements as well . remove change in line 192 as well " Each delegated credential is bound to a specific version of TLS and signature " . somehow i ca nt comment on changes that you have n't made .
Mailing list commentary: Dear TLS WG , While we were implementing delegated credentials we came up with the following two problems . I thank for communicating the first to me . The first is that a delegated credential is pinned to a particular version of TLS . Unfortunately this means that the rollout of a new version of TLS ( which libraries consider that they can do on their own ) makes an existing set of delegated credentials unusable , and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version . This is similar to the issues prompting draft - wood - tls - external - psk - importer-00 where PSKs depend on negotiated parameters , and thus are difficult to use in practice . The second is that the DelegatedCredential indicates the algorithm that was used to sign it . Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate . I 'll submit a PR with text for security considerations / rewording the verification steps . Sincerely ,
Paragraph (version A):
As detailed in delegated-credentials, the delegated credential is
cryptographically bound to the end-entity certificate and the
protocol in which the credential may be used.  This document
specifies the use of delegated credentials in TLS 1.3 or later; their
use in prior versions of the protocol is explicitly disallowed.
Paragraph (version B):
As detailed in delegated-credentials, the delegated credential is
cryptographically bound to the end-entity certificate with which the
credential may be used.  This document specifies the use of delegated
credentials in TLS 1.3 or later; their use in prior versions of the
protocol is explicitly disallowed.
Paragraph (version A):
Each delegated credential is bound to a specific version of TLS
and signature algorithm.  This prevents them from being used for
other protocols or with other signature algorithms than service
owner allows.
Paragraph (version B):
Each delegated credential is bound to a specific signature
algorithm.  This prevents them from being used with other,
unintended, signature algorithms.
Paragraph (version A):
The version of TLS in which the credential will be used, where the
type ProtocolVersion is as defined in RFC8446.  This is expected
to match the protocol version that is negotiated by the client and
server.
Paragraph (version A):
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
signature algorithm chosen by the delegator.  Minimizing their
semantics in this way is intended to mitigate the risk of cross
protocol attacks involving delegated credentials.
Paragraph (version B):
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 and signature
algorithm chosen by the delegator.  Minimizing their semantics in
this way is intended to mitigate the risk of cross protocol attacks
involving delegated credentials.
Paragraph (version A):
Verify that expected_version matches the protocol version
indicated in the server's "supported_versions" extension.