[Endymail] Hashes of key as addresses

[Phillip Hallam-Baker <[e-mail]>]

Using hashes of keys as addresses is very powerful. There are
basically three types of address in such schemes:

1) traditional human readable

2) hash of key

3) Traditional human readable + hash of key.


So in PPE we use all three in different situations:

1) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA

2) [e-mail]

3) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?[e-mail]


We can apply the same approach with value to other situations. Lets
say Alice owns example.com. We can create a strong domain name in the
same way:

ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?example.com

Note here that unlike in the PGP world where we generally use the hash
of the encryption key, PPE almost always uses the hash of a master key
that signs the encryption/authentication/etc key. This might have been
considered impractical in 1992 when machines were CPU limited but it
isn't a problem today.

Making this separation solves a lot of usability problems down the line.


Now obviously nobody is going to want to read out a strong email
address over the phone. But if we have the right discovery
infrastructure in place they don't need to.

And this is where TRANS/CT might come in (or something like it).
Because one of the things you would want to do with a freshly minted
key is to record the public part and some binding assertion in a
notary service. So it is natural to have a feature in the key manager
that allows you to say 'generate a key and register it with notary
xyz.com.'

I don't think I want to be registering my key with multiple notaries
as I think they should be talking to each other in the manner of
USENET of old. So one publication point should be enough.

But once the key is registered we have also created the raw material
that a key publication scheme might use.