Section 1 says:

This allows server operators to limit the exposure of keys
in cases where they do not realize a compromise has occurred.

I suggest an alternative:

This allows server operators to limit the exposure of keys
in cases where it might be difficult to determine whether a
compromise has occurred.

Add explicit support for DTLS. Verified on-list that there appears to be no issues:
https://mailarchive.ietf.org/arch/msg/tls/4cQ6lDVf7wMd3IXqUrfxYvMdQEE/

Need to add normative reference to DTLS as well "DTLS Okay" = Yes in IANA considerations section.

In draft-ietf-tls-subcerts-04 and later version, the signature context string change to "TLS, server delegated credentials"and "TLS, client delegated credentials", and we found it will bring some problems in our practice.
In cloud native scenario, a service always corresponding to a fixed credential, a service can be a server or a client at the same time. So we have to deploy two delegated credential in a service for mtls. That's really do harm to our credential manage but bring no security improvement.
Actually, similar context string in tls1.3 handshake(rfc 8446) is useful because of user can easily distinguish the behavior of client and server. And in our practice, there is no need to make a distinction between client and server in credential, the context string maybe can change to the same in client and server, format can like this "TLS, handshake delegated credentials"

Draft only said that: " If the extension is present, the server MAY send a delegated credential ".
Should sever abort connection when server dc SignatureScheme mismatch SignatureSchemeList in client dc extension? Or just ignore this extension？

Please double-check. At least one of these appears to be wrong.

I found that there is no standard format for saving delegated credential in file, and I think it is necessary to define a standard format like pem or others.
Something like that:
------------Begin Delegated Credential-----------
....
------------End Delegated Credential-----------

Are there considerations about supporting or not supporting other CertificateTypes than X509?

If others are intended to be used, especially RawPublicKey(2) raise the question, how the valid_time

Time, in seconds relative to the delegation certificate's notBefore value, after which the delegated credential is no longer valid.

may be handled. One idea would be to define a default value for notBefore to be used with CertificateTypes, which don't carry such a date.

I consider this mechanism very valuable in order to be able to use RawPublicKey(2) with special hardware (HSM) to protect the RFC7250/long living private keys, and use a short living private keys of the subcerts on server nodes, especially, when it gets required to scale them up.

Currently the codepoint is TBD

.Add some additional text to highlight that sig on server cert and DC can be different.

from mail.

Requested module is under the DoD INFOSEC arc instead of the standard PKIX arc.

The string over which the delegation signature is computed contains the SubjectPublicKeyInfo of the DC public key. This in turn contains an AlgorithmIdentifier. Does an X.509 AlgorithmIdentifier determine a unique TLS SignatureScheme?

If not, this could lead to key agility issues. The server could indicate a different signature algorithm (via the signature_scheme extension) than it uses to sign the handshake. I'm not sure if this leads to an attack, but it's a bit ugly. What we could do is replace the SubjectPublicKeyInfo with the DER-encoded public key and the SignatureScheme. This way the delegation signature binds to the DC to the signature_algirhtm indicated by the server.

Tweak some of the text in s4.1.1 to be explain downgrade protections.

from mail.

The text in s7.6, needs an intro to explain why it talks about TLS 1.2 when this extension is only applicable to TLS 1.3.

From mail.

Suggestion from Hannes Tschofenig at IETF 106

Not having an ASN.1 module for the certificate extension has bit us in the a** before. I will make one and add it in as an appendix.

Refactor intro to:

1. Use case
2. Problem description
3. Solution

from mail.

Need to address ARTART and GENART directorate reviews.

There has been a lot of confusion about this draft's use. It's a signing key delegation, not a credential delegation, so maybe we should call a spade a spade.

Allow the client to send a list of signature schemes that are supported in a delegated credential handshake.

Maybe use generic language, like "signing oracle" :)

If done, it seems the best path forward would be prohibiting servers from sending DCs with longer validity periods. This has a couple of benefits, and probably some downfalls:

1. Clients can "insist" on DC rotation with higher frequency than that which is ensured by servers.
2. It may simplify logic used to serve up DCs, especially if a server decides to offer "tiers" of DCs with different validity periods.

Sending maliciously small validity periods seems to be no worse that the normal keyless design, wherein private key operations are shipped over the wire.

This might make clock synchronization worse, though. That is, if the client is unaware of its clock skew problem and offers a small validity period for DCs, then the likelihood of the connection failing should increase. (I don't have data to back this up. @siyengar might?)

In section 3, the document says:

The secret key used to sign ...

Please change "secret" to "private". Later in the sentence, [RFC5280]
is referenced, and it talks about "private key" in this context.

From Martin:

I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case.

Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use.

A little bit of a nod in this direction might go a long way to avoiding deployment problems.

Request an extension point from the IANA experts and add it to the document.

There are a few interactions that could use security considerations text:

1. Some clients re-validate the certificate chain during resumptions. We should mention that you might want to cache the dcs as well and revalidate them

Open question:
Is there any risk for a server accepting a ticket associated with a DC to resume a connection if it would not have issued a DC on that connection for a full handshake. I think the answer to this is no risk.

TLS 1.3 prohibits the use of PKCS#1v1.5 signatures, but this doesn't really say anything about the situation. A question came up about it. It might help to be explicit.

From Martin:

The security considerations don't cover the potential for misissuance creating a credential that is as long-lived as the certificate, but they probably should.

The version posted at https://tlswg.org/tls-subcerts/draft-ietf-tls-subcerts.html is not up-to-date with git master. If this is being published from the gh-pages branch, note that that has not been updated since 2018-08-08.

Setting up a token per https://github.com/martinthomson/i-d-template/blob/master/doc/REPO.md#automatic-update-for-editors-copy should work.

Right now it pushes to a local folder which won't end up elsewhere:

git -C /tmp/ghpages4231 push origin gh-pages
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 2 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 23.60 KiB | 5.90 MiB/s, done.
Total 5 (delta 2), reused 0 (delta 0)
To /home/travis/build/tlswg/tls-subcerts/.
   fb76536..ac5c767  gh-pages -> gh-pages

Use RFC references

Paul provided an AD review that can be found here.

Raised by Juraj, Nimrod, Robert

The paper below, and several others, concern "...prefix hijacking on the network layer, which may lead to traffic blackholing or transparent interception".

https://dl.acm.org/citation.cfm?id=2834102

How does this draft interact with problems in things like BGP? Could it make those kinds of problems even more difficult to track down? This is not an objection, but I was surprised not to see it in the Security Considerations.

From Martin:

The authors seem to use title case and sentence case interchangeably for titles.

There is a potential issue for credential renewal. On the credential owners side there is a risk that if the owner entirely depends upon the delegated credential lifetime to renew it could miss the fact that the underlying certificate has already expired will cause clients to fail validation.

This can be addressed by adding the following to section 3:

"Peers MUST NOT issue credentials with a validity period longer than the maximum validity period or extend beyond the validity period of the X.509 certificate"

Or there could be an addition to the operational section that talks about renewal.

"5.2 Credential Renewal

Credentials must be renewed before they expire and before the issuing X.509 certificate expires. "

From Russ:

I guess I ask the authors to add a paragraph to the rationale section that says something about why this extension was used instead of an extended key usage.

From Watson:

One of the hard requirements for our deployment was that the same
certificate be useable with DCs and without. A different EKU would be
more problematic then an extension for this purpose, and while it
might be more or less irritating for implementors depending on how
their stack works (sorry Rich -
https://boringssl-review.googlesource.com/c/boringssl/+/33666/1 might
serve as inspiration, but the client side got dropped for similar
issues). We know the extension doesn't bust things, I don't know an
EKU would, and the root program issues make me hesitate.