On Tue, Dec 31, 2013 at 8:21 AM, Michael Richardson <[email protected]>wrote:
> > Phillip Hallam-Baker <[email protected]> wrote: > > PGP has not met the original goal of becoming ubiquitous so replacing > > PGP seems to me to be a very worthwhile goal. Replacing STARTTLS with > > something that has message scope but is not end to end does not seem > > like a good proposition. > > I reluctantly agree that maintaining any kind of backwards compatibility > with > PGP or S/MIME SHOULD NOT be a requirement. > No, I did not say that. Backwards compatibility is probably a deployment requirement. But I don't think that there is any group that is slavishly devoted to PGP or nothing. There is an S/MIME or nothing group but that is a different matter and their commitment does not exclude adding PGP like features. My original point was that re-inventing the wheel is only a bad thing if a scheme has already succeeded and is ubiquitously deployed and in use. So people need not be afraid of re-inventing PGP or S/MIME but proposals for a new scheme that would meet the STARTTLS use cases have to meet a much higher bar. > (If it happens that I can leverage, through new code/protocol, my existing > web of trust, that could be a MAY) > I can make use of PGP keys and fingerprints in my proposal. But they are more limited than the phingerprints that I use in strong email addresses. In the current code a phingerprint is a digest of a master key that is only used to sign policy statements. which in turn authorize the use of encryption and/or signature keys. So there is always a policy layer. The advantage this brings is that if people are using my scheme the infrastructure will always support publication of a statement such as 'PGP format encryption preferred'. While S/MIME and PGP both lack this essential capability. [And no, the fact that some dufuses have made a hash of security policy in the past does not make it an impossible problem or one to avoid tackling] > PGP did not take off because it was too decentralized and therefore very > enterprise > hostile, and so it failed to get past early adopters. > S/MIME did not take off because it was too centralized and therefore early > adopter hostile. > I think the issue is actually simpler. The criteria for ubiquitous adoption of a security technology is that it has to be 100% right and S/MIME, PGP are only 95% there. Good enough for government work doesn't cut it for mass adoption of S/MIME. The PGP ideology gets in the way of PGP use. Building the toll booths and hoping the revenues will pay for building the highway is never a good strategy. > Both then ran up against webmail systems, e.g: hotmail/gmail/etc. in the > early 2000s, when having had the RSA patent run out, a renewed push could > have occured. That problem will affect any new solution as well. > I don't think Webmail needs to be considered a show stopper. I use Gmail to organize all my mail through mailing lists because it has the search capability and it can handle my mail volume (I am atg 8.09 GB (53%) of 15 GB used) I would have no problem using a different client to send encrypted mail and a browser extension could make reading encrypted mail possible. Making this work is important to me as I invented WebMail back when I was at CERN. Implementing Web Mail is what lead to the Content-Length header in HTTP after I discovered that the HTTP POST spec was broken in 1993. (And yes this is prior art for a certain patent claim). > I look forward to reviewing drafts, and running beta code. > Who is going to make money on this system? > What's the market incentive to deploy? > Good https://sourceforge.net/projects/prismproof The market incentive is that the Web+SLL gave us the Internet e-commerce boom which added several percent to world GDP in the 1990s. Email is the other killer application of the Internet and there is the potential for another economic boost albeit maybe a smaller one. Current e-commerce is limited to the patterns that are supported by our current security tools. If we add more security tools we may see more e-commerce patterns. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
