scd bug: specifying 'e length' for RSA key-attr unsupported
trevor at yubico.com
Wed Jul 4 13:10:41 CEST 2018
> 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.
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.
More information about the Gnupg-devel