Hi David, I looked into IBE a while ago and my impression was that it is a technology in search of a problem.
Typically, you have a specific problem that you are trying to solve. You want to improve security in XMPP. A first step is to figure out what other people had been trying to do already (in XMPP and elsewhere). In this specific case there has been some amount of work already and so you may wonder why aren't the solutions widely deployed already. When you go through this exercise then you may find out that the problems that people are facing have little todo with anything that IBE could help with. On the IPR side of things: The issue essentially is that many people are reluctant to put technology into their products where they have fears of getting sued. Ciao Hannes On Mar 15, 2011, at 4:14 PM, David Núñez wrote: > Thank you for your response. Respect to your first point, one advantage of > the proposed scheme is that it is an alternative to digital certificates and > its associated distribution infrastructure, as it relies on the identity of > the users as public keys. > > Regarding to your second point.....I am not really familiar with the patents > world, so I don't understand the "slang" of that document. I understand that > it is not possible to read the RFC and, for example, release an open source > implementation (or at least, without their permission). Am I right? If so, > then maybe is not possible to carry out this proposal. However, I would like > to know other technical opinions regarding my proposal, leaving aside the > fact that maybe is not possible to do it because of legal reasons. > > Best regards, > David. > > El 11/03/2011, a las 15:40, Eric Rescorla escribió: > >> Sorry to be a downer, but no, I don't think this is of a lot of value: >> >> (1) IBE is primarily useful in contexts where there isn't an >> interactive channel between the two >> sides and so certificate discovery is inconvenient. That's not true in XMPP. >> >> (2) See: http://datatracker.ietf.org/ipr/950/ >> >> -Ekr >> >> >> On Fri, Mar 11, 2011 at 5:10 AM, David Núñez <[email protected]> wrote: >>> Hello all, >>> >>> My name is David Núñez and I am a PhD student on Computer Science. Since >>> the XSF is applying to this year's edition of Google Summer of Code, I >>> would like to know if someone in the XSF would be interested in >>> contributing to my proposal as a mentor. >>> >>> The purpose of my project is twofold: >>> 1) Implement an Identity-based encryption library based in [RFC5091]. This >>> goal is not directly related to XMPP, but to security in general. As far as >>> I know, there is no open source implementation of this RFC, and I think it >>> is interesting. It is a requirement for the second phase. >>> 2) Implement an XMPP library for an authenticated key agreement based on >>> clients identities (JIDs). This library could lead to establish end-to-end >>> encryption, using the clients identities for agreeing a session key and >>> then using symmetric-key encryption during the current session. This key >>> agreement scheme would be based in [IBAKE], that assures that the server is >>> unable to find out the session key. XMPP already provides mechanisms for >>> client-server authentication, which is an important requirement for the >>> distribution of the private-keys to clients. This library would imply to >>> define components both in server and client. >>> >>> First of all, I would like you to comment if my proposal has sense in the >>> XMPP landscape. And second, I would like to know if someone is particularly >>> interested in participating as a mentor. I'm looking forward to your >>> comments :) >>> >>> Regards, >>> David. >>> >>> References: >>> [RFC5091] X. Boyen and L. Martin. Identity-Based Cryptography Standard >>> (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 >>> Cryptosystems. >>> [IBAKE] V. Cakulev and G. Sundaram. IBAKE: Identity-Based Authenticated Key >>> Agreement. IETF draft. http://tools.ietf.org/html/draft-cakulev-ibake-03 >>> >>> >
