Peter Williams wrote: > [...]
I noticed in passing that one cannot change a signature object, once [...] Keypairs, this situation seems unsatisfactory/./
> Can anyone remember why this key initialization behavour was > programmed. > I can change
I agree with you. The DeleteKey command was not embedded in the first protocol release because the JVM was not able to free the key object memory anycase. But the protocol is open, and the implementation too, so, if you added that command, and you're happy with one (or more) garbage key objects within your card (up to memory exhaustion), I agree it is someway useful to others, too. Furthermore, I don't know if there are JavaCards out there that perform garbage collection, at the moment. On those cards, your DeleteKey (or overwrite with different params) command would just work fine. Also, consider a card lifecycle: usually it is formatted once, and a change of the on-board key(s) is not so frequent (still justifying why the DeleteKey command APDU was missing in the first place). Of course, developers may need to do that more frequently...
it so I free and realloc a persisitent KeyPair, once a change in
Of course, this is the right way. As already pointed out, on the cards we were working with (almost three years ago), the old key object would have remained allocated as garbage, and never reclaimed....
(And, AFAICR, there were similar troubles with other JavaCard objects related to the actual signing algorithm).
As a final note, I would suggest leaving the ImportKey and GenerateKey behaviour untouched (e.g. they only allow to overwrite a key with same parameters), and instead add a DeleteKey command APDU.
So, just publish a URL to your changes.
Bye,
T._______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
