Dustin Rogers <dusti...@hotmail.com> wrote: > In fact the native support for smart cards does not seem to support > network attached HSM "virtual tokens" devices at all. It could be > possible that I need to specify the local port the installed HSM agent > is running on, but I dont think I will be that lucky.
No, scdaemon doesn't support it. > I have this other scdaemon (gnupg-pkcs11-scd) working fine with gnupg 2.0, Well, I think that gnupg-pkcs11-scd is not supported by GnuPG, 2.0 or 2.1. It is a kind of... independently developed program, unfortunately. It was just coincidence (from my view point) it worked with GnuPG 2.0. It would be good if someone around gnupg-pkcs11-scd shares developement information with GnuPG. > but with manual pinentry for each operation. I cant get it working > with gnupg 2.1. (again, I am looking for the unattended pinentry > support the later version seems to have) Thus, I really dont think > this is an issue with the scdaemon I am using. Moreover, I can see the > INQUIRE PIN callback is there, the pinentry is just not > appearing. Really I would like to understand why the gpg-connect-agent > is allowing the pin call back through, and the gpg-agent itself is > not? Well, it's the detail of protocol between gpg-agent and scdaemon. INQUIRE NEEDPIN from scdaemon is not expected by gpg-agent when LEARN --force is issued. This situation is same in GnuPG 2.0. We don't know how gnupg-pkcs11-scd works, according to your log, it breaks the protocol for LEARN. gpg-agent only delegates back the INQUIRE NEEDPIN request to gpg when it is prepared: PKSIGN, PKDECRYPT, WRITEKEY, and generic SCD. For gpg-connect-agent with SCD command, it is prepared, thus it works. I think that it would be good to check why gnupg-pkcs11-scd called back with INQUIRE NEEDPIN for LEARN command. -- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
