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

[Trevor Bentley]

> In my opinion, the key attributes are not well defined in the spec and
> host software needs guessing about behavior of card implementation.

I mostly agree.  The spec does state that all cards must support 65537, 
so at least there is a known value that can always be chosen.  But 
ideally, the smartcard spec would allow sending a special value (or 
omitting the field) to means 'card default'.  And ideally, GnuPG would 
still provide some method for the user to explicitly set a desired e bit 
len if the user does not want the default.

I've added Achim to this thread, as it would be nice to get his input.

> According to the spec, there is no information which key attribute
> (value and format) is supported by a specific card.  Here, host software
> needs guessing.
> 
> In the spec, IIRC, it suggests the value "32" for e's length in the key
> attributes, as well as the value 65537.  Well, 65537 can be represented
> by 32-bit.  IIRC, there is no place in the spec suggesting 17.  I know
> that with the background of OpenPGP format itself, 17 makes sense.

The spec doesn't provide a way to check if a length is supported. 
However, it is clear about 65537 being required, and recommends it as 
default:

SHALL accept (required):
--
Some smart cards with RSA algorithm support only one coding for the 
Public Exponent (e.g. 65537 dec.). The card may reject an imported key, 
if e does not match the internal requirements. But the card shall accept 
65537 dec. (010001) as value for e.
--

SHOULD use (recommended):
--
The card should use 65537 dec. (10001 bin.) as default value for e, but 
other values are accepted by the outside world.
--

I only see 32 specified in an example, which is just demonstrating that 
it can be used:
"Length of public exponent e in bit (e. g. 32 bit decimal = 0020), binary"

You are obviously correct that 65537 fits in 32 bits, but cards that 
don't accept exponents larger than 17 bits are typically going to refuse 
the larger length.  It may be _permitted_ to accept a 32-bit length and 
generate a 17-bit exponent within it, but in practice they almost 
certainly won't.  And rightly so, since accepting a 32-bit length 
strongly implies that it can actually handle them.

>> I believe this needs to be fixed in one of two ways:
>> 1) add an 'e length' argument to KEY-ATTR (and possibly a matching UI)
>> 2) use '17' instead of '32' as the hard-coded length, since all cards
>> are required to support it
> 
> Or, you can ask change of OpenPGP card implementation, following other
> OpenPGP card implementations.  And make things explicit in the spec.

I would suggest that as an 'and' instead of an 'or'.  I think it's best 
for GnuPG to support the existing spec as well as possible, and to 
encourage the spec to improve.

>> --
>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
>> OK
>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye
>> OK
>> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 1 rsa2048" /bye
> 
> Here, it returns "OK" for Achim's OpenPGPcard (I have the test version
> of 3.3) and Gnuk 1.2.

They are permitted to accept it, especially if they really do support 
32-bit exponents.  That doesn't change the fact that other cards, which 
implement the spec correctly, will fail.

As it stands today, GnuPG cannot switch from ECC to RSA on some smart 
cards that _correctly_ implement the 'OpenPGP application on ISO Smart 
Card Operating Systems', and I think that is worth fixing.

Thanks,

-Trevor