IBE allows you to use any string of bits as a public key, and the private key is derived from it PKG after authentication. Creating a secret key in this way is not possible using methods such as RSA, or using a classic certificate authority, where pre-generated key pairs are needed before any encryption occurs.
IBE is a different approach and avoids the need to associate a public key with an identifier: authentication and authentication are independent and delimiters in the IBE scheme compared to those that are tightly connected to legacy PKIs. This means the need to generate, link, manage, publish, revoke, send defendants, etc. For public key certificates, it is deleted. In addition, if all keys are generated differently than the root key (s), there is no public key database, no escrow database, etc. This makes operational issues much easier.
As a rule, the keys of the IBE are too short. week, hour, etc., which eliminates the need for the cancellation process, as they naturally retire.
Given that a public key can be any arbitrary string, this means that time can be bound to a string, as well as policy information. This provides more flexibility when processing a public key with a public key and, of course, allows federation - very important in cloud environments, for example.
There are commercial implementations - the most famous is www.voltage.com. Its standardization is IEEE 1363.3 and IETF 5091 and others.
http://www.ietf.org/rfc/rfc5091.txt
source share