Non-interactive PIN not accepted, gpg hangs

[Laurent Blume]

Le 2015/10/01 13:07 +0200, Niibe Yutaka a écrit:
> I think that Nitrokey series would be a right solution, both for
> hardware-wise and their perspective.

So far, looks good, so I'm hopeful :)

> As Peter suggested, I feel that your use case is not directly related
> to OpenPGP.  It seems that you just need simple (non-interactive)
> public key authentication.

Bit more than that. Well, what's been asked for is the kitchen sink.
Apparently the PCI auditor said: «all private keys must be stored
outside the server».
Our main use for keys is straight GPG, for decrypting files, both
manually and automatically, but there are others involved, like LUKS,
S/MIME (also for files), Apache, ssh...
LUKS I've now done, using the GPG key in the Nitrokey and an agent
service to decrypt its passphrase non-interactively.
My next worry is checking what I can do if we need several private GPG
keys. Eg, have a bunch of NitroKeys?

> IIUC, I believe that Nitrokey community would be best place for such a
> use case.  I guess that they are open to diverse use cases other than
> OpenPGP, while I have narrow/tight perspective for my Gnuk Token,
> specifically limited to OpenPGP.

Yes, it's definitely where I'm going tor the for the other non-GPG kinds
when I get to them. In all likeliness, once I'm fully satisfied the
hardware is up to the task, Nitrokey will be hired for some expertise in
ironing the details. At least I'm going to push for that.

> I think that it is not that technically difficult to write an
> application to access Nitrokey (something) for simple non-interactive
> public key authentication.  If you say you made a mistake, it's just
> that it has not been directly supported by existing tool of GnuPG and
> its friends.

Technically, not difficult, but anything needing compilation is a huge
amount of maintenance and red tape overhead.

> OpenPGPcard compatible assumes it's users who control their computing.
> This can be done by reasonable cost, because there are less conflicts.
> 
> Most smartcard/token applications assume that it's a company (or other
> entity) who should control "consumers"' computing.  This is a
> different problem to solve, and some expensive solution is only to be
> expected, naturally, --- no wonder.

Yes, quite. I'll continue pushing for that elusive middle ground :)

Laurent