Re: [Endymail] Hashes of key as addresses

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

On Thu, Aug 28, 2014 at 9:34 PM, Leo Vegoda <[e-mail]> wrote:
> On Thu, Aug 28, 2014 at 07:23:20PM -0400, Phillip Hallam-Baker wrote:
>
> [...]
>
>> 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.
>
> Can you please expand on this point? I think that if this is solved
> then public key information would be far easier but that without it
> we'll really struggle to communicate the secure form of an e-mail
> address.

Well first off, this is obviously an area where there are likely to be
many ideas. So this is not something I want to weld into the client
right now. The proper place therefore for the capability would be in a
Web Service. In the past I worked on XKMS with Stephen and others. But
these days curly brackets are more fashionable than angle braces so I
think we want to go for a JSON service.

I have two specs defining an interface to the services:

1) OmniPublish: A Web service used by the key holder to manage their
keys. So this is the interface to the key publication mechanism,
notarization, certification, recovery and similar services.

2) OmniQuery: A Web service used by a party wanting to establish a
connection to an Internet end point which may be a Service or an
account.

These are both designed to support a broad spectrum of uses. But as it
turns out end to end email turns out to be the hardest security
problem to solve and so pretty much all the features are used.

[Links to all this stuff is on prismproof.org]


These specifications are designed to be as generic as possible and not
make constraining assumptions. But for there to be a system there
obviously needs to be some sort of infrastructure that takes the
information published though OmniPublish, processes it in some fashion
and delivers it on request in response to an OmniQuery.

As I said, I think there will be many ideas and this is a good thing.
But lets get one thing straight, lets make it so anyone who has a good
idea on how to join the two interfaces up just needs to write that
part of the code and not have to write their own email clients to test
it out.

The idea of OmniQuery is that it is a Web Service that acts like a
meta-directory on steroid. The OmniQuery broker can obtain the
information it returns in any way that makes sense.



So that said, here are some examples of how the two can be connected:

1) CA based certificate issue

CA issued email certs don't address every use case. In particular they
don't address use cases where the trust relationships are
non-hierarchical. But that does not change the fact that we have about
5 million users of S/MIME, most of whom work in organizations that are
hierarchical and issued certificates accordingly.

There have been many proposals for directories that map domains to
certificate servers. And an OmniQuery broker could acquire information
through those sources.


2) Certificate Transparency Notary Service

Lets say that a self-signed certificate is generated and published to
some party that enrolls it in a CT notary log and the log is public
and the OmniQuery service reads the log. The OmniQuery service now has
raw material that it could use to respond to key queries.


3) Combination of 1 and 2.

Lets say I set up a CT service for self signed email certs. Given that
Comodo offers free email certs, why not return them a freebie cert so
that they can use their S/MIME mail to sign mail?

Alternatively, won't a party running a log want to verify that a
request comes from the actual holder of the email address? If so they
will act like a CA even if they don't have all the process, audits
etc.


4) Web of Trust.

I really can't do justice to this here but the brief version is that
the PGP Web of Trust is a crock because it does not scale. But add in
a CT notary type service and a small number of CA validated links and
suddenly you get a Web of Trust that is stronger than either the PKIX
or Web of Trust model on its own.

[Been talking about this for several months BTW].