But if I understand that is only half of the picture. The recipient's IBE CA will still be able to decrypt, tho the sender's IBE CA may not as he does not have ability to compute pseudonym private keys for the other IBE CA. If you make it PFS, then that changes to the recipient's IBE CA can get away with active MITM rather than passive eavesdropping. An aside is that PKI for Psuedonym's is an interesting question. The pseudonym can't exactly go and be certified by someone else as an introducer without revealing generally identifying things about the network of trust. But ignoring this presuming that the identities were not subject to MITM from day one, and could build up a kind of WoT despite lack of out-of-band way to check info to base WoT signatures on. It would still be interesting to defend the pseudonym against MITM colluding with IBE CA that at some point after the pseudonym has transferred keys without insertion of a MITM from. This problem of addressing the who goes first problem for pseudonymous communicants appears somewhat related to Public Key Steganography where there is a similar scenario and threat model. (Anderson and Petitcolas"On The Limits of Steganography" http://www.petitcolas.net/fabien/publications/jsac98-limsteg.pdf). They also cite a "Prisoners' problem" which might be something you could extend involving a warden who is eavesdropping and prisoners who will be penalized if he can detect and identify communicants. My earlier comment: | Btw one other positive side-effect of IBE is the server can't | impersonate by issuing another certificate in a pseudonyms name | because there is definitionally only one certificate. may not be that useful a distinction as the IBE CA server also gets your private key, so he doesn't _need_ to generate a certificate impersonating you as a conventional rogue CA would. But if we could make the binding from pseudonym to the pseudonym's non-IBE public key strictly first come first served, so that the IBE CA's attemt to claim his later released non-IBE public key is the correct one would be detectable. Either secure time-stamping, extending the psuedonym name to include fingerprint as self-authenticator would allow this. Adam On Mon, May 10, 2004 at 06:45:56PM +0000, Jason Holt wrote:
Well, he can always generate private keys for any pseudonym, just as in cash systems where the bank can always issue bank notes. Here's what I'm suggesting, where "b" is a blinding function and n1... are random nyms: [...] (Alice generates random nonce na) HC_E(na, "Bob:agent", FBI)--->
(Bob generates random nb) <---HC_E(nb, "Alice:member", NRA)
Both generate session keys from Hash(na,nb).
The FBI can *always* impersonate an agent, because, well, they're the CA and they can make up pseudonymous agents all day long. But in this protocol, I believe they wouldn't be able to be a MITM and/or just eavesdrop on Alice&Bob.
That's because Bob only wants to talk to NRA members, and the FBI can't impersonate that.
Now, this is for an interactive session, rather than just sending a single request/response round like I discuss in the paper. But even then, policies are always respected. Just change "na" to "request" and "nb" to "response". Alice's policy is respected whether she talks to FBI-authorized-Bob or FBI-authorized-FBI, and the FBI doesn't get to read Bob's NRA-Alice-only repsonse.
-J