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) dr
>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
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 for 25519/448 curves
All,
W
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
On 23 November 2015 at 10:56, Ilari Liusvaara wrote:
> I got the idea of using 32-bit sequence number arithmetic there too
> (window is -2G to 2G seconds around current time). I don't suppose
> any key will need to have TTL of over ~68 years...
I did too, but decoded that 2^64 is just easier.
__
I support early code point assignment of these curves.
Thanks,
dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I support early code point assignment.
It’s been suggested that as long as the CFRG signature curves document is not
finalized, we should wait with the eddsa_* ones. I don’t believe so. Anything
in any draft is subject to change up to the time it’s published and people who
implement internet dr
On 23 November 2015 at 12:56, Yoav Nir wrote:
> It’s been suggested that as long as the CFRG signature curves document is not
> finalized, we should wait with the eddsa_* ones. I don’t believe so. Anything
> in any draft is subject to change up to the time it’s published [...]
In your opinion,
Hiya,
On 23/11/15 14:21, Sean Turner wrote:
> All,
>
> We’ve received an early code point assignment for the following 4
Is the word "request" missing above? Either that or I'm forgetting
more than I suspected:-)
> (four) elliptic curve points that will go in the "Supported Groups"
> Registry:
if it's only a few weeks, let's just do all the signature code points
then.
-Ekr
On Mon, Nov 23, 2015 at 1:38 PM, Stephen Farrell
wrote:
>
> Hiya,
>
> On 23/11/15 14:21, Sean Turner wrote:
> > All,
> >
> > We’ve received an early code point assignment for the following 4
>
> Is the word "reque
On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
> On 23 November 2015 at 12:56, Yoav Nir wrote:
> > It’s been suggested that as long as the CFRG signature curves
> > document is not finalized, we should wait with the eddsa_* ones.
> > I don’t believe so. Anything in any draft is su
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 CertificateVerify is dangerous
in the sam
On 11/24/15 at 2:08 PM, ilariliusva...@welho.com (Ilari
Liusvaara) wrote:
My personal view is (I haven't asked Simon about this) is that:
- Ed25519 is currently technically stable. There seems to be consensus
not change it in any way that would break verification.
- Ed448 is unimplementable rig
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
> > signing is dangerous!).
>
> Th
14 matches
Mail list logo
