Hello all.

Since Toni can't look at this issue soon, I'm trying to fix it myself.
The problem is that, at least with Aventra MyEID, every key gets created 
in a way that requires CHV1 for crypto ops, even if --insecure is specified.

It seems the root of the problem lies in the profile: changing 
CRYPTO=$PIN to CRYPTO=NONE works around it, but it's surely sub-optimal.

Another, maybe related, problem is that, IIUC the profile syntax, only 
one PIN can be specified, so I can't say that (for example):
- central office handles card initialization (w/ SO-PIN)
- a key must be "authorized" (generated in presence of) a delegated 
technician (CHV1) -- maybe to later issue a certificate that requires 
face-to-face recognition
- doing crypto ops on that key may be protected by a PIN (any CHV, as 
specified by -a N) or left unsecured (--insecure)
- more keys can be generated by the user w/o requiring the technician

While to leave it unprotected I can play with the profile, I don't see 
any way to protect it with a different pin (unless I can specify 
directly CHVn instead of $PIN, and even then I could think some 
scenarios where it would require quite a lot of profiles juggling).

I still find it quite difficult to follow code flow, even if I'm 
beginning to understand it a bit... So any pointer could be helpful.

Tks,
  Diego.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to