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]> 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]] > *Sent:* Wednesday, September 11, 2013 12:16 > *To:* Paul Wouters > *Cc:* Karl Malbrain; [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]> 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] > https://www.ietf.org/mailman/listinfo/perpass > >
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
