Draft: draft-ietf-tls-subcerts

Commentary: 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 ? i think the editor copy went out of sync 
  . I was seeing  as being out of date . I was also wondering if wanted to consider affiliation adjustment also . 
 Should we update your affiliation to  here ? 
  an extension point from the IANA experts and add it to the document . 
 shipit . As these are all editorial changes , I do n't think we need a long discussion .
Paragraph (version A):
Many of the use cases for delegated credentials can also be addressed
using purely server-side mechanisms that do not require changes to
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.
Paragraph (version A):
It is possible to address the short-lived certificate concerns above
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.
Paragraph (version B):
Many of the use cases for delegated credentials can also be addressed
using purely server-side mechanisms that do not require changes to
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.
Paragraph (version B):
It is possible to address the short-lived certificate concerns above
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.
Paragraph (version B):
If a client decides to cache the certificate chain an re-validate it
when resuming a connection, the client SHOULD also cache the
associated delegated credential and re-validate it.