9 sep 2008 kl. 20.51 skrev Dirk Meyer:
Hi, In the thread Thread 'Hosted solutions - client/user certs' started by Johansson Olle E. the idea of client cert with SASL came up. I want to use a new client. I do not trust that client for its life-time. E.g. a mobile phone can get stolen. It would be nice if this client can log into my account without having my password. XEP-0178 defines SASL-EXTERNAL but it is unclear where the certificate comes from.
I propose that you separate the public key, private key and the cert to be able to discuss the logic here. The cert is just a signed wrapper around the public key. The private key is a very important part. My idea was to have a client ID and a user ID. The user ID was allowed to delegate authority to clients by signing the client's public key in a cert format with the CN being the clients full JID, that is with a locked resource to prevent multiple logins. Storing it with pubsub seems like a smart idea. The question is how the "client" gets access to pubsub without authorization. That's food for thought. You don't want to open up for DOS attacks. Thinking about your original analogy with bluetooth or the AppleTV synch authorization, a shared secret might work. * The USER uploads a pin code to a pubsub node. * The CLIENT uploads a CERT to a pubsub node which has an ID in the form of a PIN number. * The User retrieves the cert request, signs it. This can be published in the open, as only the Client has the private key (hopefully). It's late and I'm tired, but give it some thought (or pick it apart in pieces while I sleep :-) ) /O
