Here are preliminary comments on this draft:
1 - Both the title of the document and the abstract are misleading.
Identity-based Encryption Architecture
This document describes the security architecture required
to implement identity-based encryption, a public-key
encryption technology that uses a user's identity to
generate their public key.
The content of the document mandates the use of on-line trusted
server by the recipient. This major constraint neither appears in
the title, nor in the abstract.
A "real" Identity-based Encryption would mimic what is known today
as an "Identity-based signature system".
If it existed algorithms allowing to support a "real" Identity-based
Encryption system, it would have the following properties :
An off-line trusted authority would have a master private key and
a master public key.
The trusted authority would deliver to each of its registered users
a personal private key derived from the private key and their identity.
That trusted authority would then deliver to each registered user :
a personal private key, an identifier and the master public key.
When a registered user would like to receive an encrypted message, it would
provide to the sender both his identifier and the master public key.
The sender would use them to encrypt the message.
The recipient would decrypt the message using his personal private key.
I have no idea if someone has already invented an algorithm to support that
scheme, but in any case the wording "Identity-based Encryption" alone
should not be used to avoid confusion later.
Note: the identifier is that case is not simply the name of a user,
but at least his name, a validity period and a public "magic number".
2 - Since the abstract is unclear, by not mentioning the mandatory use
of an on-line trusted server, it is amazing to read in the overview
the following sentence:
Identity-based encryption (IBE) is a public-key
encryption technology that allows a public key to be
calculated from an identity and the corresponding private
key to be calculated from the public key.
Readers might think that anybody can compute the corresponding
private key from the public key. :-(
3 - The next question is whether the use of new algorithms is really necessary
to support an architecture where an on-line trusted server is called by the
recipients,
and where the sender uses both a public key and the recipient's identity.
It seems that a system where senders would encrypt both a random key
and the recipient's identity under the public key of an on-line trusted
authority would exhibit the same advantages / disadvantages. The sender
would encrypt the message under the random key. The recipient would need
to authenticate to the on-line server and pass the encrypted block to
the on-line server to recover the value of the random key.
Then it will be able to decrypt the encrypted message.
4 - It is questionable whether this draft should continued on the standard
track within the S-MIME working group. BTW, this draft is not written
in accordance wit the IETF template since the target category is not indicated.
Denis