I've reviewed it, it's mostly fine. 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. 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. Nits: The authors seem to use title case and sentence case interchangeably for titles. On Mon, Jun 1, 2020, at 14:52, Joseph Salowey wrote: > Reminder: the last call expires this week. > > On Mon, May 18, 2020 at 12:56 PM Joseph Salowey <j...@salowey.net> wrote: > > This is the Working Group Last Call for "Delegated Credentials for TLS" > > available at https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/. > > Please review the document and respond to the list with any comments by > > June 2, 2020. > > > > Cheers, > > > > Chris, Joe & Sean > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
