Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

Andrey Jivsov <> Thu, 03 January 2013 07:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0505A21F8917 for <>; Wed, 2 Jan 2013 23:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d2vGcA-n9l13 for <>; Wed, 2 Jan 2013 23:07:02 -0800 (PST)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:32]) by (Postfix) with ESMTP id 2B83C21F88F1 for <>; Wed, 2 Jan 2013 23:07:02 -0800 (PST)
Received: from ([]) by with comcast id jK2o1k0051zF43QA3K71ST; Thu, 03 Jan 2013 07:07:01 +0000
Received: from [] ([]) by with comcast id jK701k0052g33ZR8kK71kj; Thu, 03 Jan 2013 07:07:01 +0000
Message-ID: <>
Date: Wed, 02 Jan 2013 23:07:00 -0800
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1357196821; bh=QtljU/MwWYppd9DPd41b0D60S1N5M2HE4xwWhvKO6ho=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mnl8AM9/9QdGR4fMVaO1EQFCmCZGcvexq2K0lUM6MZKO5vZ/lUpqkcc4O5tYjl1ih tqlV4hwP+abXl26NCxZxCcktUnF9LQylgkFpGs16S0spds9eBr9DhOtRV02mMhAs6x 3rbH1fNyN0UYucPDTTQNfRpTfMOiH0ToN7Ivq4ExUresbMeZQGsJBsBM8kF7H1d+Hw T+v+1HNJCqdcsaU7ZyUDAoUch2iK/GhutodRiFchw7uef592c08kCcatA2+XJ3C9ge D1DEHLURNgScyomXEn7vaZWoMO5e7dp0OfaOSeiffVgh/Ylhte+eowtZ+lm6e9+6r0 gp26penBD9tFg==
X-Mailman-Approved-At: Thu, 03 Jan 2013 09:55:16 -0800
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Jan 2013 07:07:03 -0000

Sorry for bringing up this so late, but I just noticed the discussion 
about the point compression in this thread.

I posted the "Compact representation of an elliptic curve point" that I think is 
helpful as a generic definition of a compressed point.

I know that -03 
moved away from the compressed representation, but the preceding 
discussion is one of the reasons why I created this draft. It's 
unfortunate that with current state of ECC at IETF there is always an 
uncertainty/complexity such as "do we use an uncompressed point or 
compressed point; and there is IPR". There is also an issue of what's 
hashed and how the {x,y} is encoded. In the end in practice this means 
that there is no compression used.

I want to add as an alternative point of view that for new features or 
protocols there is also a way to reduce complexity by using only the 
compact point representation, such as in