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

[Achim Pietig]

Hi all,

the problem is not the definition of the Algorithm Attributes, but the lack of an information object to see what functions the card will support.
I often got questions what algorithm the card supports - the actual definitions are presenting the 'status quo' only, but not other features of the implemention.

See my answers to your discussion in between the text below.

Regards
Achim


Am 04.07.2018 um 10:26 schrieb 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 Algorithm Attributs only define the format of the key representation (e. g. for key import), but not the allowed content.
In principle any running values are allowed, only the representation/format shall be in accordance with the alg-attributs - with some exceptions ;)
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).

The actual definition is 15 years old and many features where added without changing several data Objects (DO), with respect to existing implmentations. In most cases we add new DOs that can be used
for new functionalities. I think the actual definition is OK for that purpose - for addressing your problem (what values are allowed) a new information object maybe helpful.

> 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.
> 
--> The alg-attributs define the allowed format for presenting keys, actual you cannot see what values an implementiation will accept - you only know that all cards will/must accept e=65537.
You are rigth, that other values must be known by the outside world by knowledge (e. g. data sheet of the card) or try and error.

>>> 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.
> 
--> The problem does not only appear to the value of e, but to all values that can be set in algorithm attributs (what algos do the card support? What key length for RSA or ELC?).
GnuPG actual is orientated to the my implementions and GNUK for historic reasons, there where not many implementations in the past ;)

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.


> 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.
>
--> The specification allows other length codings for e, so if an implementation sets the algorithm attributs to a different length than 32 bits, it should work (should be accepted by GnuPG and other
software). My implementations always use 32 bits for e-values - so it may be possible that other length expressions are not tested in the past, by lack of test cards...

> 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
> 
>