Some bits about SCdaemon

[Simon Josefsson]

Werner Koch <wk at gnupg.org> writes:

> On Thu, 15 Mar 2007 14:20, simon at josefsson.org said:
>
>> * Get a list of private keys, some information about it (e.g., RSA?
>>   DSA? etc) and their related X.509 or OpenPGP cert.  Possibly the
>>   user should be able to use a fingerprint or similar to indicate a
>>   particular key or certificate.
>
> This is possible for the current smart card.  Send "SCD LEARN" to the
> gpg-agent. 

I'll try start implement this using smartcards, and hope that it will
be easy to adapt the code to non-smartcard cases later on.

> Listing all available private on-disk keys is not yet possible.  The
> only reason for this is that an implementation of the gpg-agent
> protocol might not allow to list the keys because they are stored on a
> HSM which does not implement such a feature.  However, for the current
> implementation it would be easy to add such a command.  For now you
> need to know the public key to check whether gpg-agent has the private
> part.

Adding that functionality would be really useful for GnuTLS.

Another idea is for gpg-agent to present a pull-down list with private
keys, and have the user chose one of them.  Mozilla works this way
when you have multiple private keys locally.

Possibly, GnuTLS can also tell the agent for which CAs it should
bother to list private keys for, since the TLS server typically tell
you this.

>> * Ask GnuPG 2.x to sign something using a particular key.  I suppose
>>   some external component, typically gpg-agent or seahorse, would be
>>   responsible for authorization the request and get the passphrase, I
>>   don't think that belongs in GnuTLS.  Possibly for servers, having a
>>   callback via GnuTLS to get the passphrase would be useful.
>
> The cetral place is gpg-agent.  It will take care of signing and
> decryption and may divert processing to scdaemon.

Good.

> The idea is that you always try to use gpg-agent and only if it is not
> available, use scdaemon directly.  Using gpg-agent has the advantage
> that it will take care of the PIN.
>
> For servers you would use gpg-preset-passphrase to tell gpg-agent in
> advance about a passphrase.  A callback is not easy to implement.  The
> pnly way I see is to have a special pinentry whcih loops back to the
> actual application (we recently discussed this on emacs-devel).

Right, I think it makes sense to only talk to gpg-agent.

Maybe gpg-agent could act as a proxy for gpgsm --server too?  Although
I might not need to talk with gpgsm after all...

> I once thought about that.  But I doubt that you really need it.
> Check out gnupg/sm/call-agent.c on how decryption and signing can be
> delegated to gpg-agent/scdaemon.

Ok, I see.  Why doesn't it use the scdaemon-proxy in the agent?  Is
the scdaemon-proxy idea in the agent a new invention?

/Simon