Hi Tero,
Every single option adds complexity, so I do not think we should add
more optional things.
Point compression is not the focus of our draft. Given the opposition it is
facing here, I suggest to wait for further
replies and if point compression turns out to be objected by the majority
Hi,
On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote:
Hi David,
Point compression is simply the ommission of the x-value, and for point
expansion, functions are included in OpenSSL and
other crypto libraries. Thus, such mistakes should only occur if someone
decides to implement the
Hi Derek,
On Wed, November 7, 2012 10:27 am, Derek Atkins wrote:
Hi,
On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote:
Hi David,
Point compression is simply the ommission of the x-value, and for point
expansion, functions are included in OpenSSL and
other crypto libraries. Thus,
Hi Valery,
On Wed, November 7, 2012 10:18 pm, Valery Smyslov wrote:
Hi Dan,
I suspect the IKEv3 in its current form is susceptible to very simple DoS
attack.
Suppose we have Alice, Bob and Malory. Alice wants to communicate with
Bob,
Malory wants to not allow her to do it. For this
On 11/8/12 3:26 AM, Johannes Merkle johannes.mer...@secunet.com wrote:
Hi Tero,
Every single option adds complexity, so I do not think we should add
more optional things.
Point compression is not the focus of our draft. Given the opposition it
is facing here, I suggest to wait for further
On Nov 8, 2012, at 4:24 PM, David McGrew (mcgrew) wrote:
On 11/8/12 3:26 AM, Johannes Merkle johannes.mer...@secunet.com wrote:
Hi Tero,
Every single option adds complexity, so I do not think we should add
more optional things.
Point compression is not the focus of our draft.
David McGrew (mcgrew) writes:
Just a note: the relative saving of point compression is larger when
sending hash + URL instead of the CERT.
What's the scenario here? If hash + URL is sent, the certificate still
has to be retrieved.
Usually not, as it is already cached in the client. I.e.
