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 >> >>
