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

[Trevor Bentley]

Thanks, Achim.  Then I retract this as a bug report, and lower it to a 
confusing spec report :)

I do think you should clarify the language around e length when you add 
the new DO, though.  It's definitely not clear how it is to be used.

Also, there is one sentence in the spec that suggests Algorithm 
Attributes decides how on-device key generation is done:

"This DO announces information related to the supported algorithm of the 
card. ... The formats are used by the key generation in the card..."

It is never defined how they are used, but does say that they are.  The 
implication is that on-device generation should match the current 
Algorithm Attributes.

Yubikeys currently choose the RSA bit length of on-device generated keys 
based on the current Algorithm Attributes.  Isn't that the expected 
behavior?  Gnuk appears to do the same.  So, in current implementations, 
both "Algorithm ID" and "Length of modulus n in bit" are used during 
generation, but "Length of public exponent e in bit" is not.

-Trevor

On 2018-07-08 11:27, Achim Pietig wrote:
> Hi Trevor,
> 
> generation of keys is a complete internal function of a card, there is no influence to adjust parameters like e in the command data - all is depending on the development.
> In your implmentation you are free to set any valid defaults, e maybe fixed or within a range or is calculated by random - it's the choice of the developer.
> The Algorithm Attributes show how to interpret the key values during im- and export of private and public keys, but do not define internal rules for the generation.
> 
> So your example with several given values for e will not run within the current definitions. For your needs then a new information DO maybe of less priority.
> But if an implmentation allows changing of the Algorithm Attributes, it is useful to know what parameters/algorithms are suppported by the card. This cannot be evaluated at the moment and a software
> that wants to change an algorithm e. g. must know the implementation (internal list etc.). Also for key import it is useful to know what values a card will accept, to avoid try and error.
> For that purposes I will add such an information DO in the next version, but it will not solve your requirements to set special values for e...
> 
> Regards
> Achim
> 
> 
> Am 05.07.2018 um 14:09 schrieb Trevor Bentley:
>>> 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.
>>
>> Hmm, definitely a misunderstanding then.  The spec should be updated to clarify that.  "Length of public exponent e in bit" certainly implies that it will be the exact length of _e_ in bits, not
>> the... number of bits in the minimum number of 32-bit ints needed to contain it?  I'm still unclear on why it's 32 bits instead of 24.  Is e=3 encoded as e_bit_len=8 or e_bit_len=32?  What about
>> e=0x100000001 (33 bits)?
>>
>> When importing a key, it is ASN.1 encoded and already specifies both the lengths and values of each parameter.  Keys can be validated and rejected at time of import, without needing the algorithm
>> attributes DO.  Importing is not really a problem, but on-device key generation is.
>>
>> My understanding was that, when calling Generate Asymmetric Key Pair, it should generate a key with the bit lengths specified in Algorithm Attributes.  But if those fields aren't actually the bit
>> length of the parameters, but instead the bit length of some larger container, what is the generate command supposed to do?
>>
>>> 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.
>>
>> I still think there is that need, but only if the data can actually be used somehow.
>>
>> Maybe you can walk me through what the expected commands would be in the following situation:
>>
>> Smart Card supports:
>>   (1) (RSA n=2048,e=3)
>>   (2) (RSA n=2048,e=65537) *default
>>   (3) (RSA n=4096,e=257)
>>   (4) (RSA n=4096,e=65537)
>>
>> I want to generate (on device) four keys in a row, of type (1) then (2) then (3) then (4).  Is that possible, and if so, what would the algorithm attributes be set to before each generate command?
>>
>> If that is not supposed to be possible, then the need for a new DO is much less important.
>>
>> Thanks,
>>
>> Trevor
>>
>>