[TLS] Issue #348: 32bit timestamp in ServerConfiguration

>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

Re: [TLS] Early code point assignments for 25519/448 curves

Thanks Sean, I support early code point assignment for these curves. Cheers, Andrei -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner Sent: Monday, November 23, 2015 6:21 AM To: Subject: [TLS] Early code point assignments

[TLS] Early code point assignments for 25519/448 curves

All, We’ve received an early code point assignment for the following 4 (four) elliptic curve points that will go in the "Supported Groups" Registry: // ECDH functions. ecdh_x25519 ecdh_x448 // Signature curves. eddsa_ed25519 eddsa_ed448 These points will be included in the following 2 (two)

Re: [TLS] Early code point assignments for 25519/448 curves

On 23 November 2015 at 14:08, Ilari Liusvaara wrote: > Also, the prehashes might not be the same for Ed25519ph and Ed448ph, > plus I consider interfaces that let one use this dangerous (IUF > signing is dangerous!). That suggests that the construction of

Re: [TLS] Early code point assignments for 25519/448 curves

On Mon, Nov 23, 2015 at 02:20:15PM -0800, Martin Thomson wrote: > On 23 November 2015 at 14:08, Ilari Liusvaara > wrote: > > Also, the prehashes might not be the same for Ed25519ph and Ed448ph, > > plus I consider interfaces that let one use this dangerous (IUF > >

Re: [TLS] Issue #348: 32bit timestamp in ServerConfiguration

On Mon, Nov 23, 2015 at 10:28:41AM -0800, Martin Thomson wrote: > >From the issue: > > 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