[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDPKC


At 16:29 +0000 12/16/03, Marc Poulaud wrote:
Hi,

Appreciating this a PKI group, I wanted to know if there is any knowledge
of, or experience in IDPKC vs PKI. My intention is not to start a
religious war, but just understand if there is anything approaching a
consensus view. Also, does anybody know of any real/serious
implementations of IDPKC. I'll take private emails, if people feel it's
off topic.

Marc.
iSolve Ltd.

Marc,

Pardon this belated response.

One should put identity-based PKC (IDPKC) in perspective. The concept dates back to the mid-1980's when Adi Shamir first proposed the problem of deriving a key pair from an identifier, e.g., an e-mail address. Several methods of doing this were developed over the next 15 years, the most recent work is by Dan Boneh and his colleagues. It is arguably the most sophisticated from a crypto perspective, and the commercial, e-mail product based on their work also is the best in terms of solving some of the problems present in previous work. However, there are some limitations in all of these approaches, which I comment upon below.

First, in any large environment characterized by multiple administrative "domains," there is a need to have multiple CAs. No one CA will suffice to issue certs for all users. All IDPKC mechanisms rely on the ability of the sender of a message (I'll use the e-mail example here) to acquire some public values that are unique to the CA that serves the user to whom the mail is being sent. So, there has to be a way to securely acquire these public parameters, and to know which CA serves which users. This is generally equivalent to the problem of acquiring the right CA cert for the user. Only if the CAs align EXACTLY with the name space for the users would the problem be easier in the IDPKC context. (Personally I would prefer such alignment, but in practice it rarely happens!) Note that this characteristic is essential, because if one uses the wrong parameters, the e-mail will be decipherable by the CA whose parameters were used! So, in this part of the problem, it is not clear that IDPKC is a big win, because it would seem necessary, in general, to have some cert-like mechanism to securely distribute the CA public values, and to somehow bind each user to the CA that serves him/her.

Once one has the right set of parameters for the user in question, one can input the name of the user, e.g., his e-mail address, and generate the user's public key. but, this simple model does not work well, because it implies a need to change one's e-mail address to deal with compromise! So, IDPKC schemes have to add some parameter to the key generation process to accommodate the desire to keep the e-mail address constant while changing the key pair. The best solution I've seen for this problem (thanks for Boneh, et al.) is to use the current date as an additional input to the key generation process. This provides a very reasonable window for revocation, analogous to what one gets with daily CRL distribution, but without the need to push the CRLs or to contact OCSP servers on a daily basis.

Of course, there is no free lunch. The implication of the daily key pair change is that the users of a CA must receive new private keys from the CA on a daily basis, in order to be able to decipher incoming e-mail. One can argue about the magnitude of this problem, vs. the CRL and cert distribution problem. In the IDPKC case, one has to deliver private keys to all users served by a given CA daily, or allow these users to fetch the keys (for the current day and some set of prior days). These are private keys, so they need to be encrypted independently for each user. In a PKI, a CA has to make the certs and CRLs for its clients available to everyone who wants to communicate with the clients, presumably a much larger population. But, the certs are generally fairly static (e.g., annual or biannual renewal) and the certs and CRLs are signed public info that can be stored anywhere. So it is hard to say which problem is easier to solve, and there may not be one answer for all contexts.

The CAs in an IDPKC act as key escrow agents, implicitly, and may have to hold onto private keys for at least a moderate period of time, to allow users to retrieve and decrypt mail that arrived when the users were away or otherwise unable to acquire new keys. In contrast, in a traditional PKI, a user may generate a key pair and never disclose the private key to anyone, even his CA. So there are significant differences in the security offered for private keys in these two models, especially if the PKI makes use of hardware crypto tokens that generate their own key pairs.

Finally, what about signatures? I have not looked at what Boneh proposed for signatures, but in general signature generation/validation pose opposite problems from encryption/decryption. A sender needs his private signature key to sign each message, and the receiver needs to be able to verify that the key is authentic and not-revoked. IDPKC does not seem to be so well suited to the signature verification problem. if signature keys are managed the same way as encryption keys, then every recipient of a signed message needs to acquire the current, public signature key for the sender, which imposes a serious burden on distributing these keys if one does not use certs. Also, if a signature key is discovered to have been compromised AFTER a recipient retrieved it, how does the recipient learn of this? With CRLs a CA can add an entry when a "late discovery compromise" occurs, and depending on when the signed data is processed, this late entry might suffice to warn the receiver.

So, overall, I am not convinced that IDPKC is a significant, practical technology, at least as it has been described so far. It might prove useful in some contexts, but these contexts need to be carefully defined to permit a valid comparison with PKI technology.

Steve