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

[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