OpenPGP card specification enhancement for ECDSA support

[Andrey Jivsov]

Hi NIIBE.

Please consider using the compact representation of an ECC point: 
http://tools.ietf.org/html/draft-jivsov-ecc-compact with the OpenPGP card.

I plan to submit a relevant proposal to use the compact representation 
in OpenPGP.

The benefit of the compact representation is that you will have to 
transmit less than half of bytes of the point over in the host-to-card 
protocol.

For this compact representation of the ECC point to work one needs to 
slightly adjust the key generation. It's always possible to do so with 
the proposed method, even with any existing method that generates keys 
on the card (one uses "black box" approach in this case).

The ideal scenario is when the key generation is already generating 
compliant keys. Thus, I suggest to change the key generation on the card 
to always return the compliant keys.

IMO we should all generate compliant OpenPGP keys in the entire OpenPGP 
ecosystem (and beyond as well, as keys are sometimes migrated between 
PKI and OpenPGP). Well, at least compliant keys are within our reach at 
OpenPGP.

( I will say that it's unfortunate that RFC 6637 was specified to use 
SEC format 04 | x | y. The reason is that at the time I didn't know 
about all the benefits that a *single* format such as 
http://tools.ietf.org/html/draft-jivsov-ecc-compact would bring. I plan 
to remedy this with another draft. So, it's a heads up. Please consider 
not using the SEC format. )

Thank you.

On 02/28/2013 10:22 PM, NIIBE Yutaka wrote:
> Hello,
>
> This message is CC-ed to GnuPG-Devel List.
>
> I am currently extending GnuPG so that it will support OpenPGP card
> with ECDSA feature in future.
>
> So far, following two things are modifications to the current OpenPGP
> card specification.
>
> Could you please give me comments?
>
>
> (1) 4.3.3.6 Algorithm Attributes
>
> ECDSA:
>
> Byte  Length    Value
> 01    01        Algorithm ID  (RFC6637) 13 = ECDSA
> 02-   Variable  OID (RFC6637)
>                    2A 86 48 CE 3D 03 01 07   NIST curve P-256
>                    2B 81 04 00 22            NIST curve P-384
>                    2B 81 04 00 23            NIST curve P-521
>
> I think that use of OID here would be best, since OID is used to
> identify the curve in OpenPGP ECC (RFC 6637).
>
>
> (2) 7.2.11 GENERATE ASYMMETRIC KEY PAIR
>
> Set of public key data objects for ECDSA
>
> 	81 xx Public key
>
>                In the format of uncompressed point:
>
>                   04 || x || y
>
>                where x and y are coordinate of the point P = (x, y).
> 	      Big-endian, zero-padded.
>                (c.f. Section 6. Conversion Primitives in RFC 6637)
>
> I think that curve specification (For example, Generator, Order, etc.)
> is defined by OID in the Algorithm Attributes, it's enough to return
> the public key, EC point, and it's natural to use standard encoding
> of uncompressed point.
>