I have been thinking about the problem on the lines Tony suggests and I think I might have a solution.
First off, yes hashes of public keys are great, see my UDF/SIN proposal which uses Base32 encoding so the identifiers can be read out over a phone. mb2gk-6duf5-ygyyl-jny5e-rwshz A SIN is a UDF that is bound to an Internet address to create a Vtrong Internet Name http://mathmesh.com/Documents/draft-hallambaker-sin.html [email protected] Both are useful, neither is very usable. For that we need a registry of some sort. One approach is to use a B****Chain and assign identifiers on a first come first served basis which allows for user friendly identifiers if you get in quick. Another is to use techniques to compress the hash result without losing work factor. If the first 25 bits of a hash are zero, they can be omitted. UDF supports this (there is a MSFT patent that covers some ways of doing this). However, none of these are really email addresses as we recognize them. They are really machine readable identifiers that are better used under the covers. So we start off with an email address or phone number and translate to one of these. OK so here is the alternative. We start off trying to resolve the email address in the normal fashion. [email protected] in the FOO protocol means 'look at the SRV/TXT records for _foo._tcp.example.com to find the service'. That is fine for [email protected] but what about [email protected] if Google isn't playing ball? The way I would handle these is with a shadow registry which is only consulted AFTER the DNS service. So I can register with the shadow registry today and make use of the service and people can contact me until Google decides to provide support and publishes SRVs to their own service. Ths shadow registry should ideally be open and unencumbered (not another XRI scheme please). It should validate registration requests against the authoritative source. So I have to authenticate myself to claim [email protected] on the service. (This is of course pretty easy if OpenID is supported). When names are registered in the shadow registry, the registration is bound to the hash of the users long term profile public key and enrolled in a hash chain. When using a system of this sort, the process would be something like: I decide to use the OpenDARE messenger service provided by prismproof.org (i.e. my personal node). I enroll as [email protected] and register [email protected] as an alias and point the SRV for hallambaker.com to prismproof.org. At this point, people can contact me by any one of [email protected], [email protected] or [email protected] using end-to-end secure messaging. In OpenDARE, there is a hierarchy of messages ranging from contact requests through to sending executable code. So anyone can send me a contact request but they can only send me longer messages if I accept them as a contact at which point we exchange our credentials and a long term binding is established. Now OpenDARE (Data At Rest Encryption) is one messaging protocol that we are currently building. But the infrastructure we use to achieve the usability and manage the private keys, devices etc. is designed to be multi-application. This is in part so we can provide support for legacy protocols like S/MIME, OpenPGP, SSH, etc. But it could be used by new applications as well. And in particular, contacts can be shared across applications. We could do the exact same thing for telephone numbers only in that case I see it more as a transitional technology. Telephone numbers are an identifier that should go away in the near future. On Mon, May 28, 2018 at 3:02 PM, Tony Arcieri <[email protected]> wrote: > Isn't the best alternative to a phone number an email address? It's > information people may already have in their Contacts so it should map well > to all of Signal's existing contact flows, and the problem of verifying > ownership of an email address is well-understood (I say this as someone > with p=reject DMARC rules) > > On Mon, May 28, 2018 at 11:22 AM Trevor Jameson <[email protected]> > wrote: > >> (Just found this in my drafts folder, having intended to send a week ago. >> Oops.) >> >> I wrote a proposal for alternative identifiers (as opposed to the common >> practice of using phone numbers) that has better properties, and I would >> like to share it here for review and comment. My broad intention is to >> implement this, assuming I am able to get in contact with OWS and get an OK >> from them first. >> >> I've written it up on the signal forums here: https://community. >> signalusers.org/t/a-proposal-for-alternative-primary-identifiers >> >> Cheers! >> -T >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging >> > > > -- > Tony Arcieri > > _______________________________________________ > Messaging mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/messaging > >
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
