Re: IDPKC

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

Steve,
That was a truly brilliant analysis of IDPKC!

It would however be nice to get a similarly educated analysis of
PKI in the form you have more faith in.  Like how you actually can
build shrink-wrapped, reliable, and user-friendly RP software based
on standards having the following characteristics:

      "RFC3280 [6] when taken to its extreme by exploring all possible
       valid uses, allows each EE certificate to be an entirely unique
       object with no relationship to other EE certificates belonging
       to the same PKI hierarchy, except for sharing a common trust
       anchor.  That is, a single CA may vouch for an arbitrary number
       of different certificate policies.  CAs conforming to RFC3280
       may also deploy subject DNs that may only be locally unique for
       the CA, potentially creating name space conflicts between
       different CAs.  In spite of the availability of X.509 policy
       extensions, limited efforts have been made to establish a common
       set of certificate policy identifiers, further complicating the
       handling of multiple CAs by relying parties"

Hoping for a better 2004 with more mutual understanding

Anders R

----- Original Message ----- 
From: "Stephen Kent" <kent@xxxxxxx>
To: "Marc Poulaud" <marc.poulaud@xxxxxxxxxxxxx>
Cc: <ietf-pkix@xxxxxxx>
Sent: Monday, December 29, 2003 23:45
Subject: 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