On 08/18/2014 06:18 PM, Nadim Kobeissi wrote: > There's a lot of vague promises that are bundled with this model. For > example that "the notaries are continually audited." Is this really the > practical scenario?
Auditing is an attempt to achieve or approximate a global view into the key space. Many approaches for binding user identifiers to keys have some kind of auditing (see below). It is very useful to be able to ask "is the version of reality that i see the same one that everyone else sees, or am I being fed bullshit?" Is this practical? Probably more practical than the alternative. > Sticking to PGP is confusing. We have many protocols and projects out > there (Axolotl, or miniLock) that are focusing on primitives that are > newer, leaner and that offer new venues for key management. Matthew > Green recently wrote an excellent piece on this [1]. I also saw this > pretty comic comparison of PGP's primitives to Cure25519 today [2]. > > The fact that folks are resorting to such lengths to try and save PGP is > just clear indication that it's time to move on. Unless one feels that short keys magically produce good user experience, the topic of this thread does not have anything to do with OpenPGP, per se. I say this because no matter what type of public key you want to use you will have the same problem of key validation. There are a finite number of potential strategies that people have dreamed up, only one of which is made easier with short keys: Decentralized: * Don't use human memorable identifiers and just use the key or fingerprint as the identifier, possibly facilitated by using some usability trick like Qr codes or short authentication strings. * Non-verbal confirmation plus SAS (zrtp) * Shared secret * TOFU (albeit a very poor form of TOFU since there is no forward validation) * Web of Trust Infrastructure based: * Central authority, or finite set of authorities * Consensus among a finite set of authorities * Global append only log * Multiple append only logs * Network perspective * Authority call-back Many a very smart person has said, "screw this, the problem is too hard, lets just use keys as identifiers." Maybe they are right in the short term, but in the long term there is every reason to expect this problem to be solved and for humans to eventually enjoy human friendly identifiers. Although Matthew Green is usually astute, I thought his post on OpenPGP was very disappointing. OpenPGP is flexible, and most of his criticism consisted of straw man arguments regarding existing software and existing practice, not the protocol itself. Few have railed against the how people use OpenPGP more than I, but there is an important distinction between problems inherent in the space (like validation and pfs) and problems with OpenPGP. Yes, some people have a legitimate beef about non-repudiation, and it is stupid and easily fixed to not encrypt the subject, but async PFS is something on which the dust has not settled. I love Axolotl, and I think the choice of pre-keys is an acceptable concession, but plenty of reasonable people do not agree. Yes, actual OpenPGP implementations have bad defaults, are too flexible, and let you do horrible things (like fetch via fingerprint and think that means the fingerprint has been verified). But it is also a fracking work horse that runs a lot of important things. Any reasonable system to change how we do secure email can include a mechanism for capabilities discovery, and switch between S/MIME, OpenPGP, Axolotl, or whatever as appropriate. Creating a replacement for OpenPGP and S/MIME might be hard, but it is probably the easiest part of trying to make email secure and easy to use. -elijah _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
