[Security] XEP-0189 and XEP-0178 Interaction

Dave Cridland dave at cridland.net
Tue Sep 9 15:04:42 CDT 2008

On Tue Sep  9 19:51:43 2008, Dirk Meyer wrote:
> BTW, if a bad client removes all certificates except its own, you
> still have control because you always have the password login.

Clients might also be able to change the password... That's possible  
now with the right XEPs.

> Comments on that? And where to put it? XEP-0189? XEP-0178? A new  
> XEP?
> And a question for server developer: how complicated is it to add a
> feature like this?

I'm thoroughly against "special" pubsub nodes, because they  
complicate the processing of pubsub/PEP requests.

So I'd be inclined to have a provisioning <iq/>, which might  
(possibly optionally) publish internally to XEP-0189. It also then  
has the ability to refuse to provision the certificate.

As to how difficult this is - not very.

I've done "proper" CA-based X.509 authentication in our  
implementation, and that's moderately complex, but do-able.

Doing simple certificate comparison, on the other hand, is pretty  
easy, since you just load in an X.509 object and check for equality.  
I think I could implement this reasonably quickly.

But I don't think you want this. I think you want to have a user  
control a "mini-me" account for automata - so maybe they get a fixed  
resource, and low rights - no ability to change certificates,  
passwords, or even roster items - and that'scomparitively much harder  
to do.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Security mailing list