Jon Callas wrote:
I've been asked to speak at an Identity
conference and while I was musing on the
unsuitability of x.509/PKI for identity,
it occurred to me that one of the barriers
is that OpenPGP is not a standard, whereas
x.509 is.
Huh? OpenPGP isn't a standard? How?
Specifically (bearing in mind the emphasis
outlined below on mindspace) we lack the completed
RFC. That will be a big help.
In the last couple of years there's been a resurgence of OpenPGP-based
systems. I see new ones coming on line (usually in an email that says
something like, "Is this a competitor of yours?") about at the rate of
one every month or two, but I've gotten two of them this *week*. More
than one of these new people have contributed here. If anything, OpenPGP
is undergoing a renaissance right now. There are also other bits of
ground breaking on further adoption that I can't talk about, but I can
tell you that I don't see this pattern stopping.
Well that's encouraging news. Is there any way
we can get a picture on how many ventures out there
are building RFC2440 systems?
That's an open question! It would be nice
if there was a list or a forum of apps or a group
of people doing stuff. (There is this group, which
is strictly standards focused, and the cryptorights
mailing list that I am aware of.)
My products support both OpenPGP and X.509, and my official policy is to
be format agnostic. However, I'll say that while X.509 is a "standard"
it is a "standard" that you often have to make work by doing passive
fingerprinting on the certs. You look at it, infer what software or CA
created it, and special case the handling of the crypto system
accordingly. I'm not complaining, merely stating. For anyone who goes to
the trouble of walking the minefield of X.509 interoperability, this
"standard" is a huge barrier to entry to competition. Unlike OpenPGP,
where someone can knock off an interoperable system with a little bit of
work (hacking, if necessary your own previous systems and others like
the Perl module) and end up with something that works, X.509 takes
*work* to make interoperate, and this is a huge boon for anyone who
actually makes a living at this.
Everything you say makes sense. But when I was
mentioning barriers to entry, I was specifically
thinking in terms of the institutional mindset.
x.509 to them is telecoms, ISO, Verisign, billion
dollar companies, and all the associated mindspace
and presence that goes with a standard.
Whereas OpenPGP is .. what? A bunch of net geeks
mucking around with crypto mail. When they're
not fighting the government they're fighting
each other...
In those terms, which are the terms that any
company over a thousand employees buys on, x.509
is a standard, and OpenPGP is a frontier toy.
These people have no capability to drill down
through the sales blurb into what the software
does, or the crypto does. These are the people
who say "it is a standard if IBM says it is a
standard."
Yes, yes, there are open source toolkits for X.509. I've used them. My
conclusion was that those nice folks at GeoTrust provide a good service
for the money, especially when I compute my own hourly rate and the fact
that I could otherwise be doing something fun.
Be sure to tell them that, when you talk about the superiority of
"standards" to mere RFCs. :-)
Oh, don't get me wrong - my part is on how to
fix the broken x.509 models / how the RFC2440
model has delivered. But I feel it is important
to try and work out why it is that these big buyers
simply don't see the alternates. One of the
answers is their mindset that the x.509 thing
is a standard. And there isn't any competition
to that mindspace.
Not yet. Hence my suggestion that we start calling
it RFC2440 rather than OpenPGP. (I'm throwing that
out there more to point people at the issues rather
than expecting it to be a valuable idea.)
iang