>From the issue: <<< As far as I can see, the only timestamp used is expiration_date in the ServerConfiguration (apart from X.509 validity checks which require synchronised clocks). This is defined as seconds since UNIX epoch, and will overflow sooner than later. Maybe either use a relative amount of seconds here, or expand to a 64bit value!?
I suggest to use 32bit network byte order (same as ticket_lifetime_hint), which value are the seconds how long this configuration is valid, and thus may be cached for at most this amount of seconds. >>> I don't want to see this change to a relative time. That will mess with our ability to create ServerConfiguration objects that live outside of the handshake. I have no real objection to expanding this to 64bit though. (I'm personally OK with stating that this is modulo 2^32, but recognize how that might result in problems.) _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
