[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IBC (Re: [Gzz] Re: [Gzz-commits] journals hemppah)
From: |
Tuukka Hastrup |
Subject: |
IBC (Re: [Gzz] Re: [Gzz-commits] journals hemppah) |
Date: |
Fri, 25 Jul 2003 09:55:56 +0300 (EEST) |
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