Code change:
Many of the use cases for delegated credentials can also be addressed using purely server-side mechanisms that do not require changes to <del> client behavior (e.g., LURK I-D.mglt-lurk-tls-requirements).  These mechanisms, however, incur per-transaction latency, since the front- end server has to interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with TLS 1.3 I-D.ietf-tls-tls13. </del> <ins> client behavior (e.g., a PKCS#11 interface or a remote signing mechanism KEYLESS).  These mechanisms, however, incur per-transaction latency, since the front-end server has to interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per- transaction latency.  The figure below compares the message flows for these two mechanisms with TLS 1.3 RFC8446. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to support legacy clients. It is possible to address the short-lived certificate concerns above <del> by automating certificate issuance, e.g., with ACME I-D.ietf-acme- acme.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </del> <ins> by automating certificate issuance, e.g., with ACME RFC8555.  In addition to requiring frequent operationally-critical interactions with an external party, this makes the server operator dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance APIs like ACME may be useful for provisioning credentials within an operator network. </ins> 3. 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 <del> digitalSignature KeyUsage (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.  The credential has the following </del> <ins> digitalSignature KeyUsage (RFC 5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that are needed for this application.  The credential has the following </ins> structure: Relative time in seconds from the beginning of the delegation

Related discussion:
text: Use RFC references
Maybe use generic language, like "signing oracle" :)
ooh, naming things is so difficult :) Maybe "remote certificate signing offload"?
Please double-check. At least one of these appears to be wrong.
were you looking at the editor copy perhaps, does the latest draft appear wrong as well? URL i think the editor copy went out of sync
Ahh. I was seeing Richard as being out of date. I was also wondering if NAME wanted to consider affiliation adjustment also.
NAME Should we update your affiliation to Mozilla here?
Request an extension point from the IANA experts and add it to the document.
shipit. As these are all editorial changes, I don't think we need a long discussion.