UUID collisions would be handled by the list servers which would silently reject posts of user public keys to occupied UUID slots. User's would determine this by noting that a UUID query doesn't produce their public key, and then retry the post with a different UUID.
List servers would communicate among themselves to replicate the list globally. Karl From: George Michaelson [mailto:[email protected]] Sent: Wednesday, September 11, 2013 16:08 To: Karl Malbrain Cc: Phillip Hallam-Baker; Paul Wouters; [email protected] Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol unscaleable is a word which had currency in 16 bit computer days, and possibly in 32 bit computers when disks and bandwidth were untenably expensive. I am less sure that any enterprise which only has to scale to addressing 2 billion people in the next 5-10 years is 'unscaleable' in the real sense of the world. 'seems very inefficient' or 'seems like a problem which will carry its own sub-problems' or 'scaling this is a challenge which demands funding and eyeballs' are all less direct statements going to the same place. or do you believe UUID collide, and in fact cannot uniquely identify end entities casting the runes to make randoms? On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain <[email protected]<mailto:[email protected]>> wrote: The list is replicated but not centralized per-se. There is only one content. Larger servers could maintain their own copy of the replicated list for their own usage. As to the utility of the enhancement, MITM attachments/attacks are precluded by strong authentication of both the server and the client. The specific technical problem addressed is the ability of both parties to reliably obtain client public keys during TLS negotiation. From: Phillip Hallam-Baker [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, September 11, 2013 12:16 To: Paul Wouters Cc: Karl Malbrain; [email protected]<mailto:[email protected]> Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <[email protected]<mailto:[email protected]>> wrote: On Wed, 11 Sep 2013, Karl Malbrain wrote: From: Karl Malbrain Sent: Wednesday, September 11, 2013 11:43 To: 'Theodore Ts'o' Subject: RE: [perpass] proposed enhancement to TLS strong authentication protocol It's a WORM list. Users post requests to the list maintainers they trust with a GUID to register their public key, and then send this GUID as part of the TLS negotiation process. Seems to me to be basically like an unscalable central version of the TLSA record? https://tools.ietf.org/html/rfc6698 I think it can be decentralized and have been working on an architecture to do that for email security. But it does not really help much for authentication to random Web sites or for enterprise use either. -- Website: http://hallambaker.com/ _______________________________________________ perpass mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
