scd bug: specifying 'e length' for RSA key-attr unsupported

[Achim Pietig]

Hi,

I think there is a missunderstanding in the meaning of the key format (lenght of e). The given length in the Algorithm Attributes is the format representation and has nothing to do with the legnth of
the content. For im-/export of public and private keys an ASN.1 coding is used, this format can handle only full bytes (1 byte = 8 bits). To present a content of 65537, you need at least 3 bytes,
filled up with leading zero bits. Because 3 byte is an uncommon representation we decided to use 4 bytes or 32 bits (unsigned long) for the representation of e-values. It is not possible to code 17
for the length, all length information in the Algorithm Attributs shall have a value that can be divided by 8 without remainder. This is valid for keys (p, q) also - they have to be filled up with
leading zeros.

If there is a need to see the supported values of the card, like algorithms and their possible length, an additional DO is needed, where all this information of the card features are stored. It can be
evalutated before changing the Algorithm Attributs and/or for key im-/export.

>> Yes, I agree with this.  It should support either min/max length for cards that support ranges, or a list of discrete values for cards with absolute requirements.  A card might support _exactly_
>> e=3 or e=65537, for instance, and specifying the range "2 to 17 bits" isn't quite right.  It is similarly common to only support discrete n lengths, e.g. n=1024/2048/3072/4096.

I think this DO should contain each supported algorithm (like RSA, EC-ANSI, EC-brainpool) in a list with their specific values as range or fixed entry.
The representation to the outside world then is still in compliance with the definitions in Algorithm Attributes.

Regards
Achim


Am 04.07.2018 um 13:10 schrieb Trevor Bentley:
>> Some international standards (e. g. ISO 7816-15) define a fixed value for e (65537) and many card implementations follow this. So I definied for the OpenPGP card, that a value of 65537 shall be
>> accepted, to be compatible to existing cards if they want to add the OpenPGP card application. Other values are optional, depending on the implementation (my implementations allow any running values
>> for p, q, e).
> 
> For this reason, I think the current implementation in GnuPG should change to send a bit length of 17.  This is backed by two reasons:
> 
> 1) All cards that implement the OpenPGP for Smart Cards spec must support it, and presumably Gnuk and the others will keep working.
> 
> 2) GnuPG's 'gen-key' already defaults to 65537, and sends bit length 17 to KEY-ATTR when importing keys.  So gpg is already defaulting to 17 everywhere except when switching the card from EC to RSA mode.
> 
>> The best thing to me to solve this is a new information DO, where all supported algorithms of an implementation are listed with their min/max values. This new object will not 'disturbe' older
>> implementions and can be evalutated for setting new algorithm attributes and for key import.
>>
>> If you and Niibe agree, I will make a proposal and add it to the next specification.
>> The actual version of the specification however is 3.3.2 that I sent to Werner some time ago, but there are no new functionalities - only editorial enhancements and many examples.
> 
> Yes, I agree with this.  It should support either min/max length for cards that support ranges, or a list of discrete values for cards with absolute requirements.  A card might support _exactly_ e=3
> or e=65537, for instance, and specifying the range "2 to 17 bits" isn't quite right.  It is similarly common to only support discrete n lengths, e.g. n=1024/2048/3072/4096.
> 
> I strongly suggest that the response should clearly mark what the card considers 'default' for an algorithm.  It should be trivial for GnuPG to ask the card what settings it wants and set it to that,
> without having to make any guesses or assumptions.
> 
> Thanks,
> 
> -Trevor
> 
>