Re: [perpass] ID based encryption for email

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Dec 31, 2013 at 8:21 AM, Michael Richardson
<[e-mail]>wrote:

>
> Phillip Hallam-Baker <[e-mail]> 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/