STEED - Usable end-to-end encryption

[Jerome Baum]

>> the lowest efford are discovery via personal web pages like doing XDR or
>> maybe webfinger. Most users wont be able to have special RRs - not even
> 
> Most users don't have personal web pages.  So what now?  Well many users
> have a facebook page - but this would make facebook mandatory and we
> woold need support from them (at least to guarantee that they don't
> break any assumptions).  Not much different to work with ISPs.

Look at how OpenID does it. I can use my personal web page if I want, or
I can go to one of the many providers and they'll create a "profile
page" for me. Some of them even support using my domain if I have one,
so I can have http://example.com/ without hosting worries.

I don't think a <link rel=""> implementation is "difficult" in any way
and not having a personal web page is an empty argument. But the real
problem (and part of why OpenID is still so un-popular) is that people
don't like usernames that start with "http://"
("h-tee-tee-pee-colon-forward-slash-forward-slash").

The core problem is that the lookup isn't email-to-certificate but
url-to-certificate, but the end-user wants to send something to my
email, not to my url. I suppose there are some things we could do about
this:

1. Drop the "http://" (make it an implicit default)

2. Add some <link rel="email"> type of element to the page so I can go
from url to email.

Now I can "email" jerome.example.com and it'll go to that page, lookup
my email and cert, encrypt to my cert and send to my email.

Just another random idea that could lead somewhere, or nowhere at all.

-- 
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA