[9fans] Another stupid problem

[9fans] Another stupid problem

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

Maybe I'll understand all these things eventually.  In the meantime,
in the attached picture, why does factotum report no key?

And why does IMAPD request a "client" key?  Is it the "public" key for
the incoming request that is being requested here?

++L

[-- Attachment #2: question.gif --]
[-- Type: image/gif, Size: 15222 bytes --]

Re: [9fans] Another stupid problem

[Russ Cox]

> Maybe I'll understand all these things eventually.  In the meantime,
> in the attached picture, why does factotum report no key?

The rsa protocol loops through the keys available,
presenting them to the program talking to factotum.
When the program finds a key it wants to use,
it continues.  Otherwise factotum runs out of keys
and it gives up.  That's what happened here.  You have
some rsa keys in your factotum, but not the one
corresponding to the X.509 certificate you have told
imapd to use.

> And why does IMAPD request a "client" key?  Is it the "public" key for
> the incoming request that is being requested here?

In the "rsa" protocol implementation, like most of the
protocols, it is the client side that holds the secret.
TLS is odd in that the server is authenticating to the
client but the client rarely authenticates to the server.
So the TLS server uses the rsa client protocol and vice
versa.

Russ

Re: [9fans] Another stupid problem

[Charles Forsyth]

> TLS is odd

first understatement of the day!

Re: [9fans] Another stupid problem

[Lucio De Re]

>> Maybe I'll understand all these things eventually.  In the meantime,
>> in the attached picture, why does factotum report no key?
> 
> The rsa protocol loops through the keys available,
> presenting them to the program talking to factotum.

Thank you, this type of explanation is not exactly readily available.
I guess it's my turn to add something to the wiki once I've figured
out the remaining details.

++L