Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP

On 16/04/2015 16:29 pm, Derek Atkins wrote:
> Ian,
>
> ianG <iang(_at_)iang(_dot_)org> writes:
>
> > Context:  I'm not saying I want to open up the debate.  My context is
> > that I'm already doing it.  In effect <advert> I abandoned OpenPGP 2
> > years back so that I could build my own PKI to suit my today's
> > requirements </advert>.  To add further flesh to that, PHB is doing
> > the same.  Jon will also have something to say on this, and others...
> >
> > In short, the reality is that PKIs are evolving around us, so the
> > question is not whether to do it, it's already happening.
> >
> > The question is whether to bring it back in house?
> I'm not sure why you need to abandon OpenPGP to do this.  Me, I'm
> building a PKI *using* OpenPGP.  It's actually working quite well,
> although I wish there were more standard ways to do the things I
> need/want to do.  But there's definitely enough flexibility in 4880 to
> do everything I want/need.

Right, that was what I was doing until recently.  Hence my historical 
interest in OpenPGP.
What caused the shift was a combination of bugs & failures, and outright 
cost.  I was working to get old software up and going, and had to get 
three different implementations of OpenPGP to behave.  I failed on all 
three, for different reasons.  So in the end I bit the bullet and wrote 
the stuff I needed directly [0] [1] [2].

> Perhaps what we need is (as already suggested by Jon) a document or set
> of documents that define how to do different types of PKI using OpenPGP
> data structures.

I would say: let's ground it to experience.  I'm uninterested in the 
pontifications of a group of cafe academics.  If you have real cases 
that are working for you, I'm interested in seeing that document.


iang



[0]   It took 1 month to write and another month to roll out through the 
rest of the code.  Since then it's been golden, a lot smaller, all 
totally aligned.
The older code bases probably cost me from 1-2 months of delay just in 
failing to get them going.  The first one that failed was Perl OpenPGP 
which relied on some maths library that just refused to install.  So 
this caused me to write the entire Perl application into Java - at a 
cost of 1-2m, but I always wanted to eliminate Perl ;)
The second failure was a combination of ye olde Cryptix and BouncyCastle 
OpenPGP implementations.  Part of the factor was that I drowned in the 
lower layer packets and APIs that just weren't documented enough, and 
the code was huge and opaque and comment shy.  Another part was 
dependency on JCE.  I hit something that was impossible on Android, too 
many dependencies, and decided enough was enough.

[1] Topic drift:  The approach I employ is also highly distinct to the 
older ways of doing things.  In the past, good design was based on 
packets and APIs.  We heavily standardised the packets & algs, then 
composed up from there, providing an API to build from individual bricks 
and knobs.
In a newer emerging method, if I may call it that, we standardise on 
high level interfaces and instead build vertical silo mini-protocols.  I 
now have a series of these heavy weight objects that do entire 
higher-level protocol things, that in some cases compose on other such 
objects.  However the internals of how they do it aren't the standard.
DJB's cryptobox is an example of this approach in the wild.

In contrast, the anti-pattern is Java's JCA.  There, you pass in strings 
like "AES/CBC/HMACSHA1" and have the Java Control Engine compose the 
things you're allowed to do.  Just to make the point, this is bad.

[2] It's also worth mentioning that back in the old days I had a team of 
people doing this stuff.  These days, it's just me.  So cost of 
development is a real killer issue.  I'm always looking for ways to 
build big powerful crypto stuff efficiently...
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp