Signature and Cipher Limitations for Keys</h3> <p>There is no more a fixed signature or cipher algorithm for a key. All possible combinations allowed by the Java Card API and the card abilities are possible.</p>
Changing the semantics on this seems unhelpful, because it removes functionality that many security policies will now be assuming. A change of implementation is ok. I suggest that you add a run-time control, which allows the card issuer (or other key creator) to once again control the defined usages of a key. Whereas before, said usages were defined as in the semantics of CreateKey APDU, its ok to replace that create-time control with a run time access control decision - which could be declared to accomplish the same effect as the original (construction-time) policy or have a more open policy. Perhaps the easy way to implement a run time key usage control is to define another ACL class, and define the key usage bits. Then attach this bit array to each key, and perform enforcement. If the suggestion is not ok, consider another: have a bit in the APDU which allows the key to be created with the new semantics, leaving absence of the new APDU parameter bit meaning: stay with conventional key usage definition, on key object creation. > http://www.inf.tu-dresden.de/~ko189283/MuscleCard/Changes.xhtml > > (XHTML, but at least Opera and Mozilla can it.) > > Karsten > > > > > Thanks, > > Dave > > > > _______________________________________________ > > Muscle mailing list > > [email protected] > > http://lists.drizzle.com/mailman/listinfo/muscle > > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
