gpg-agent

Hi list,

I'm trying to get gpg-agent and monkeysphere to play nice with each
other as per http://www.programmierecke.net/howto/gpg-ssh.html

According to it, 'gpg-agent remembers the once added key and you never
have to register it again' and 'Not using gpg-agent, has the
disadvantage of having to register the key every login-session with
"monkeysphere s" again.'

If I understand that correctly, that means that by following the given
instructions, I should not have to do "monkeysphere s" ever again, as
gpg-agent will remember the key.

However, I have so far been unsuccessful.  Everything works perfectly
fine except that every time I login again, I have to do "monkeysphere
s", which gives me: 'Enter passphrase for key Tim Guirgies
<Lt.Infiltrator <at> gmail.com>:' in the terminal; just thought I'd mention
it in case it's relevant and it's meant to give me the gtk window for
passphrase prompting.

So, has anybody tried this before and been successful?  Anybody got any
ideas?

Tim

--

-- 
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org   - against proprietary attachments

Re: gpg-agent

On Tue, 6 Sep 2011 01:14:56 +1000, Tim Guirgies <lt.infiltrator <at> gmail.com> wrote:
> I'm trying to get gpg-agent and monkeysphere to play nice with each
> other as per http://www.programmierecke.net/howto/gpg-ssh.html
>
> According to it, 'gpg-agent remembers the once added key and you never
> have to register it again' and 'Not using gpg-agent, has the
> disadvantage of having to register the key every login-session with
> "monkeysphere s" again.'

Hi, Tim.  As far as I know, no ssh agent caches your key permanently.
And in fact I hope they don't, since that would actually be a really bad
idea.  A permanent "cache" would mean that the unencrypted key material
would have to be stored to disk in order to have it available to the
next login session, or after reboot, which of course is a big nono.  The
agent should flush the cache after logout.

If you're trying to cache the key permanently, I don't know how to help
you.  If you just want to cache it for a long time, or for the duration
of your login session, see the default-cache-ttl-ssh option, described
in the gpg-agent(1) man page.

jamie.

Verifying TLS-client with MSVA on the server side

Hi,

I want to use a custom callback in AnyEvent::TLS (verify_cb, via
AnyEvent::MPRPC::Server), to verify a client who is making a connection
to a host. The client can easily verify the server using the MSVA; if
you like you can check out http://movb.de/anyevent-mprpc-msva/server.pl
for a possible implementation.

The client, however, might not provide a service and hence has no
reasonable "context". I don't really know how to approach this, if I
want the server to verify the TLS-client using monkeysphere.

Would the first step be to convert the client's TLS key into an OpenPGP
key (with pem2openpgp) and import the public key part into the server's
keyring in /v/l/monkeysphere/host?

If that's OK, what would the next steps be? How can the server know who
he's talking to, if all he has is the client's TLS-certificate?

TIA,
Tobias

Re: Verifying TLS-client with MSVA on the server side

Tobias Nissen wrote:
> I want to use a custom callback in AnyEvent::TLS (verify_cb, via
> AnyEvent::MPRPC::Server), to verify a client who is making a
> connection to a host. The client can easily verify the server using
> the MSVA; if you like you can check out
> http://movb.de/anyevent-mprpc-msva/server.pl

I mean http://movb.de/anyevent-mprpc-msva/client.pl of course.

The JSON part is hackery and only works because JSON::RPC::Client::
call() doesn't really care about it's input.

Re: Verifying TLS-client with MSVA on the server side

Hi Tobias--

On 09/07/2011 01:11 PM, Tobias Nissen wrote:
> I want to use a custom callback in AnyEvent::TLS (verify_cb, via
> AnyEvent::MPRPC::Server), to verify a client who is making a connection
> to a host. The client can easily verify the server using the MSVA; if
> you like you can check out http://movb.de/anyevent-mprpc-msva/server.pl
> for a possible implementation.

great!  client-side verification of TLS isn't something that has had
much work yet; i'm glad to hear you're interested in it.

> The client, however, might not provide a service and hence has no
> reasonable "context". I don't really know how to approach this, if I
> want the server to verify the TLS-client using monkeysphere.

the "context" in this case is what kind of connection is being made --
regardless of whether the peer is a client or a server.

so if you're running a webserver, and doing client-side auth, you'd want
the context to be "https".  If you're writing a mailserver, the context
should be "smtp", etc.

Since the peer.type will be "client" instead of "server" (the default),
the name → OpenPGP User ID string conversion should behave differently.

again, this is pretty much unexplored territory, so if you have ideas or
suggestions about how it should be done, you have a lot of opportunity
to drive the discussion here :)

Re: Verifying TLS-client with MSVA on the server side

Hi Daniel,

Daniel Kahn Gillmor wrote:
> On 09/07/2011 01:11 PM, Tobias Nissen wrote:
>> I want to use a custom callback in AnyEvent::TLS (verify_cb, via
>> AnyEvent::MPRPC::Server), to verify a client who is making a
>> connection to a host. The client can easily verify the server using
>> the MSVA; if you like you can check out
>> http://movb.de/anyevent-mprpc-msva/server.pl for a possible
>> implementation.
> 
> great!  client-side verification of TLS isn't something that has had
> much work yet; i'm glad to hear you're interested in it.

I thought, with all the cryptography involved using TLS, why bother and
implement and separate authentication scheme, when I could just let
monkeysphere do the job. But apparently this won't work out of the
box 

>> The client, however, might not provide a service and hence has no
>> reasonable "context". I don't really know how to approach this, if I
>> want the server to verify the TLS-client using monkeysphere.
> 
> the "context" in this case is what kind of connection is being made --
> regardless of whether the peer is a client or a server.
> 
> so if you're running a webserver, and doing client-side auth, you'd
> want the context to be "https".  If you're writing a mailserver, the
> context should be "smtp", etc.
> 

TTL for authorized_keys