Robert Wilton has entered the following ballot position for draft-ietf-tls-subcerts-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. I found section 5.1 on Clock Skew interesting and good to raise, but it was slightly unclear to me on several regards: 1) This text only writes about client clock skew. Isn't it also possible that a poorly maintained server might also suffer clock skew and a client using a delegated-certificate could be similarly affected? 2) It was a bit unclear to me what "The lifetime of the delegated credential should be set taking clock skew into account." was intending. Initially I had read this wondering if the peer should try and calculate the clock skew of the peer and allocate a certificate accordingly. But I presume that the actual intent is that when certificates are generated, the start time should probably be a few minutes in the past, and the certificate expiry should not be set to be exactly 7 days into the future, but perhaps a few minutes less to account for potential skew between clocks? I will leave it to the authors discretion to decide if they want to tighten or clarify this text at all. Regards, Rob _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
