Peter Williams wrote:
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.
Yes, possible. But this limit was artificial introduced, because of the
missing garbage collection. Are there some practical examples were it
makes sense to restrict the key to only signing or verification or
decryption or encryption with a certain algorithm?
The never used MSCKeyPolicy would become a meaning. From the
libmusclecard API side it is possible. The key policy can be integrated
in the CreateKey command APDU. Would also be compatible if it is
appended at the ending. (Compatibility means for me: New applications
with the new semantic can also handle old cards. Old application can
access new cards is hard, but I try.) A bigger problem is where to save
this rights.
The CreateKey command can be extended to support key policies. Also no
problem.
Although it is a mix of the raw key format and the policy, internal the
key policy (and by the way also information about the partner key) can
be appended to the stored key blob in the object manager. External this
information is removed and the usual key blob is returned. Stays
compatible in all directions.
ListKeys has to be extended and should report the key policy.
This is a next step when the other things are working.
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
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
