On Fri, 29 Mar 2019 at 14:02, Evgeny <xramt...@gmail.com> wrote: > > > On Fri, Mar 29, 2019 at 4:57 PM, Dave Cridland <d...@cridland.net> > wrote: > > > > That's interesting, because my understanding was that the result of > > ATT was that if I manually verify one of your keys, I could then > > transitively trust all of your keys - I didn't read this as being > > that I might trust any third party keys. > > Yes, I already corrected myself in the previous mail, sorry for > confusion. > > > Indeed, I consider this to be essentially a channel binding problem > > where we implicitly trust the "in person" channel - I think Winfried > > might have a story to tell on why that can be a fallacious assumption. > > What exactly is a fallacious assumption? > > Sorry, too much English. "Fallacious" simply means "based on mistaken beliefs", or simply "wrong". We cannot always trust the "in-person" channel.
In Winfried's case, he attended the 2016 FOSDEM key signing event where someone turned up with a specimen passport, and all but 20 people signed his key anyway since they naturally assumed that nobody would be doing that. Winfried was quite upset at the time, which is understandable, but I still can't stop laughing. > > I think you can (somewhat) combine them in the way that MLS does, > > where each person has an identity key which signs each device key, > > and that identity key can then be manually, WoT, or CA verified as > > the users desire. > > I'm simply not competent enough to resolve this, I'm working on CA > protocol in my XEP. > Nor am I - it requires proper cryptographers, who are working on these problems at the IETF anyway. > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
