Vladimir Beker wrote: ...
of course you would need to specify the alg and parameters to derive the key as well ...
[Vladimir Beker] Agree with you. There are 2 issues here. One is derivation mechanism, another one is that many attributes of pin apply here. Probably the solution would be: To define new kind of object: derived_auth_key, which is the same as auth_key + derivation mechanism + the same id as auth. pin to be derived. So actually we have 2 records but define 1 real object. It is a bit dirty trick, but it allows not mixing attributes of key and pin
I guess this should be discussed in the iso7816-15 working group (in case you know someone who is in this group) or the pkcs mailing list.
that's not allowed. to quote pkcs15:
CommonObjectAttributes ::= SEQUENCE { ... authId Identifier OPTIONAL, ..., ... } (CONSTRAINED BY { -- authId should be present in the IC card case if flags.private is set. -- It must equal an authID in one AuthRecord in the AODF -- })
but I don't that many libraries stumble over this.
[Vladimir Beker] Strictly speaking you are right. But I would consider such thing as the least evil.
if interoperability is a concern you should adhere to pkcs15 (in case it's possible to fulfill your requirements with pkcs15, something I doubt)
Nils _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
