Re: OpenSSH certified keys

[William Ahern <william%25thandClement.com@localhost>]

On Tue, Mar 16, 2010 at 07:16:19PM -0400, Jeffrey Hutzelman wrote:
> --On Tuesday, March 16, 2010 02:14:45 PM -0700 William Ahern 
> <william%25thandClement.com@localhost> wrote:
> 
> >ASN.1 will continue to sit on the sidelines in the FOSS world as long as
> >there's no appealing library and/or compiler to make it the easy choice
> >for people. Indeed, using ASN.1 in a new proprietary product or protocol
> >is a very good way to keep FOSS competition at bay.
> 
> You mean, except for widely-deployed protocols like PKIX, Kerberos, SNMP, 
> and LDAP, all of which have multiple open-source implementations.

All of those protocols were created in the 1990's. Each open source
implementation wrote their own implementation of the relevant ASN.1 codecs,
largely only suited to their particular task. And they did so because the
particular protocol was already ubiquitous. Only SNMP has a significant
number of open source implementations, and SNMP is simplified.

AFAIK, there are no recent protocols that have used ASN.1. In fact, most use
XML largely because of the ubiquity of Clark's expat and, subsequently,
GNOME's libxml. (Hype obviously played a part, but those susceptible to hype
aren't as well represented in the class of those able to write decent
infrastructure software.)

The only library that OpenSSH currently depends on is OpenSSL, and their
implemention is horrible by their own admission (and manifestly
untrustworthy). OpenSSH is a conservative project, existing implementations
aren't suitable (and they'd have to be exceptional, I think, for OpenSSH to
accept a new dependency), and the project is understandably reticent to
write a huge new chunk of code.

If ASN.1 is to garner mindshare (and respect), it minimally needs something
like expat to reduce costs. As things stand, unless you work in telecom
there's no future for ASN.1. ASN.1 isn't on anyone's radar. Look at
phenomena like Google's Protocol Buffers. That and similar projects provide
nothing more (and usually not much less, either) than ASN.1. Why go thru the
bother of writing a new specification _and_ new code? It's not logical to my
mind, but that's the way things are. ASN.1 isn't as simple as line-oriented
protocols (which are in abundance), nor are there any best-of-breed
implementations. Therefore you see a flourishing of ad hoc designs.