OpenPGP card specification enhancement for ECDSA support

[Andrey Jivsov]

Hello NIIBE,

I agree that you would want to support uncompressed ECC key 
representation at least because you never know where a key came from.

Having said this, GnuPG should change the key generation to generate 
"compliant" keys all the time. I do this in my software. There is no 
reason not to do so. This gives an option to use an efficient 
representation down the road, but that's not a requirement. One can 
still encode a compliant key per RFC6637 (uncompressed).

I can volunteer to write a patch for the compliant key generation for 
GnuPG when I find time.

On 03/03/2013 05:19 PM, NIIBE Yutaka wrote:
> Hello Andrey,
>
> On 2013-03-02 at 18:12 +0900, NIIBE Yutaka wrote:
>> On 2013-03-01 at 11:02 -0800, Andrey Jivsov wrote:
>>> Please consider using the compact representation of an ECC point:
>>> http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card.
>>
>> Thank you very much.  I didn't know this document.  All that I had
>> known about compression was x + (1-bit of y).
>
> I considered again.
>
> For new keys, we will be able to take advantage of this compact
> representation.  But, there are already ECDSA keys out there.
>
> I will limit key space for Gnuk for new keys, so that keys generated
> on Gnuk Token can be represented by the compact representation.  But,
> note that most users of Gnuk use writekey command, generating keys on
> host PC.
>
> I think that Gnuk Token should not limit key space for writekey
> command (host PC -> Gnuk Token), but should accept keys of other half
> space for inter-operablity.
>
> Speaking for GnuPG, same argument could be applied.
>
> It is true that there has been no released versions which support
> ECDSA yet.  But, it should handle any keys by any OpenPGP ECC
> implementations.  Besides, GnuPG supports SSH and X.509.  With the
> possibility of 50%, existing keys of ECDSA couldn't be represented by
> the compact representation.  I think that GnuPG should handle both of
> the compact representation and the uncompressed representation.
>