Vladimir Beker wrote: ...
[Vladimir Beker] This is obvious. What I wanted to do is the following: from the viewpoint of the user there is password (since I speak about human client). The password is converted to the encryption key (for instance, according to PKCS#5 - and this key is used for real authentication. This way I prevent eavesdropping and replay attacks by using challenge-response (alternatively I need SM but it supposes that both sides already share some secret).
not necessarily, some cards support key agreement with asymm. crypto (using for example cv certificates). Anyway the same applies to EXTERNAL AUTHENTICATE is case a symm. cipher is used.
However from the user point of view,
it is password, so min/max length and other password attributes still take place.
of course you can misuse a pin a object for this, but I don't think there's an elegant solution for this (using pkcs15, not to mention pkcs11 ;-)
2. When encoding access conditions of some object (which are in fact references to auth. objects) how can I encode ALWAYS and NEVER?
ALWAYS == no ac == no authId in the CommonObjectAttributes (NEVER, don't know perhaps an invalid authId, but personally I don't the necessity for this)
[Vladimir Beker] ALWAYS - you seem to be right. NEVER - well, I would like to
define access condition for object removal.
hmm, the currently supported AccessModes in pkcs15 are for read, update and execute ... no deletion, but I don't know if this list has been extended in iso7816-15 (btw: my above proposal for never is of course not in accordance with pkcs15). I would suggest setting the auth object required for removal in the authId field and if an application tries to access the object it will fail (even after verifying the auth object) but as the app. is not supposed to access this object this shouldn't be real problem.
Does it mean that I must support all of these options since other applications may choose any of them when creating objects on the card?
if you want other libraries to write on your card the answer is yes
[Vladimir Beker] And if I want to operate with cards prepared by other libraries on the smartcard of the type known to me?
other cards/libraries should fulfill your above requirements ?
The source of these last questions are very simple: if we don't get interoperability what's the reason to follow standard?
again it denpends on the intended usage scenario: if you have no control over the client software (and you want different libs to able to work with your card) you should either try to use pkcs15 (but the more complicated features you use in your profile , the less likely it is that your card will work with other libs) or supply detailed docs describing the card layout and hope that other developers write some support for it. On the other hand if the card is for a closed user group (company id card etc.) there's no real need to use pkcs15 (pkcs15 requires an asn.1 parser ...).
Cheers, Nils _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
