IBC (Re: [Gzz] Re: [Gzz-commits] journals hemppah)

[Tuukka Hastrup]

On Fri, 25 Jul 2003, Benja Fallenstein wrote:

[on Identity Based Cryptography]

> > +      - no more certificate revokations, revokation lists etc
> 
> Um, this simply means that you cannot revoke a key. Then, of course, you 
> don't need CRLs either. You can also omit CRLs from a classic PKI if you 
> don't think you need to revoke keys.

When you revoke a key, aren't you telling "you're not supposed to use this 
public key anymore"? In IBC, you can include a time perioid in the 
identity. Doesn't that implicitly revoke the key after that time perioid?

> > +      - private keys are provided by a key server
> 
> It's noteworthy that IBC has built-in key escrow: The TTP has (or can 
> generate) the private key of every participant in the system.

You can distribute the trust among several TTP's: I guess the simplest 
would be to always encrypt several times, using different TTP's. It was 
also mentioned that the secret can be distributed so that no single TTP 
ever has the complete secret or any complete private key.

http://crypto.stanford.edu/ibe/

> > +      - looks promising w.r.t. Storm's pointer authentication

> What do you intend to use as the public keys? (Email addresses or IPs or 
> telephone numbers or domain names would not work, because they can 
> change possession over time.)

I don't know if this brainstorming is any use, but I could imagine some 
scheme where the identity and thus the public key is a Storm pointer name. 
Valid pointer blocks could only be issued with the secret key.


-- 
-- Trying to catch me? Just follow up my Electric Fingerprints
-- To help you: address@hidden
                http://www.iki.fi/Tuukka.Hastrup/
                IRCNet: Stugge/tuukkah @#pii,#fenfire,#ynna
                Jabber ID: address@hidden, ICQ #11321669