The issues that consume most time in standards process are the ones that everyone can have an opinion on. If we are building a time machine then everyone can argue about what color to paint it but none of us has a sensible opinion on the time travel mechanism other than that we don't know how to make it.
So most of the problems of securing email end to end come down to plumbing. Over the past couple of months I have been trying to perform triage on the problem, isolating the parts that are 'research' from the parts that are 'plumbing'. The first iteration was basically to copy the design of XKMS and isolate all the PKI components in a Web Service. But we can further divide the problem inside the PKI space as follows: Case A: We know the public key of the other party Case B: We know the message digest of the public key of the other party Case C: We have no information about the public key of the other party The difficulty of these three cases is very different yet in the current approaches we are forced to solve the difficult problem of case C even for cases A and B! Case A does not need any infrastructure at all but SSH seems to get along just fine. Case B only requires the ability to resolve the digest to a public key which is essentially just an index lookup. If we had an end to end email security system that was only secure after first use or if the counterparty provided their strong email address with the digest of their key it would cover a huge number of use cases. And we can build that without any 'infrastructure' dependence at all beyond a web server or two. There is still a research problem to solve case C, but we don't need to insist on that problem being solved or even knowing that we can solve it to start work on cases A and B. Now I believe that I have also solved case C but that is another issue and one that has a longer argument to justify it. The point is we can do useful work to make end to end email security usable now even if my proposal for the hard problem turns out not to work. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
