scd: change_keyattr_from_string for ECC.
Achim Pietig
achim at pietig.com
Tue Jul 21 08:37:09 CEST 2015
Hi,
answers in the text.
Regards
Achim
Am 21.07.2015 um 01:23 schrieb NIIBE Yutaka:
> On 07/20/2015 11:25 PM, Werner Koch wrote:
>> Why not use
>>
>> SCD SETATTR KEY-ATTR --force 3 1 rsa2048
>>
>> and handle card specific details in app-openpgp.c ?
>
> Yes, I'd like to support that. And, I'm wondering HOW we can
> implement that.
>
> When SCDaemon composes the data to be sent, it's like:
>
> 01 08 00 00 20 00
>
> where
>
> 01: RSA
> 08 00: 2048-bit modulus size (of n)
> 00 20: 32-bit exponent size (of e)
> 00: private key format from host to card is (e, p, q)
>
> OpenPGPcard allows four formats for RSA key (to be stored into the
> card);
>
> 00: e, p, q
> 01: e, p, q, n
> 02: e, p, q, dp, dq
> 03: e, p, q, dp, dq, n
>
My cards <= V2 do not allow to change the private key format byte and algo-ID, because it is hardware specific. You can change only byte 2-7.
Cards >= V3 allow changing byte one (algo-ID) and dependent from that changing byte 2-7 (RSA) or OID (ECC).
Other values are rejected.
Plain ISO cards that do not support parsing of data in PUT DATA may have a different behaviour - in most caeses they will not support this in general.
> When the key attribute is for RSA, and being asked (by a user) to
> change the size of RSA key, SCDaemon only change the size of public
> key in the key attribute data object (by reading out the data object,
> then writing the changed value). That is, SCDaemon does not change
> the format specifier of the key attribute.
>
That is OK for all card <= V2.
> When the key attribute is for ECC, and being asked to change it back
> to RSA, SCDaemon doesn't have an idea what format the card supports.
>
That is a problem because there is no feature list available - Extended Capabilites show only values needed for runtime.
Can be solved only by special tools from the card developers.
> So, I wonder: SCDaemon to
>
> (1) try all those four possibilities
> (2) have a card specific information which card/version support what
> (3) assume that (in future) the card has flag to specify which format
> (4) assume that
> the card ignore the format specifier by SCDaemon
> (5) not specify the format specifier and let the card decide it
> but... sending only 5-byte (01 08 00 00 20) for PUT DATA is OK?
>
> If (5) doesn't violate ISO 7816, this sounds good.
>
A featue list (all missing possibilities of the card) can be added, because there is only few usage I did not mention it up to now.
In PUT DATA the whole DO has to be sent, partial data are not possible.
A card may check the values (my do) and reject incompatible input - but there may be implementations that do not pasrse and allow all values.
In that case the card will not run properly after the changes.
More information about the Gnupg-devel
mailing list