Subject: Re: TLS: No policy OID. Was: Policy User Interfaces

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Feb 2004 21:48:36 +1300

Richard Levitte - VMS Whacker <[email-masked]> writes:

>In message <[email-masked]> on Wed, 18
Feb 2004 01:21:00 +1300, Peter Gutmann <[email-masked]> said:
>pgut001> Richard Levitte - VMS Whacker <[email-masked]> writes:
>pgut001>
>pgut001> >I choose to develop for tomorrow.  You?
>pgut001>
>pgut001> I choose to develop for what the market wants
>
>And quite often, "the market" looks at what's available today and tries to
>use that to solve their problems.

The market tends to look for the simplest, most straightforward way to solve
their problem.  Only geeks and bureaucrats go for the solution with the most
bells and whistles.

In 1997, I did a full (well, as full as was possible) implementation of
everything in what became RFC 2459 (that was the one where some time in about
'98 or '99 I ran it against sample certs from various public CAs and it
rejected 10 out of 11 as being invalid, showing the general level of PKIX
compliance in implementations, the Style Guide was from around that time too).
Since finishing it, I've spent at least an order of magnitude more time
endlessly hacking around with it to accomodate both changes in the spec and
broken implementations (the 10 out of 11) than it took to write the thing in
the first place.  What's worse, although I don't know what crypto protocols
I'll be working on in 10 years time, I do know that (assuming anyone is still
left using X.509, the US DoD I guess) I'll *still* be hacking around with that
code to handle spec changes and bugs in other implementations.  The pain never
ends.

In hindsight, I'd have been better off just doing a minimal implementation
(basicConstraints, keyUsage, that sort of thing) that works OK for most people
and left it at that.  99.99% of users would never have noticed, and it'd have
saved me endless work.

So developing for "tomorrow" when your target spec is an abstract wishlist a
foot thick isn't always a good idea.  Better to develop for a good estimate of
what might be useful tomorrow, and do the rest on a time&materials basis (i.e.
employ lazy evaluation of the spec requirements).  If I implemented even ten
percent of the stuff in the current stock of PKIX RFCs (assuming you could
somehow freeze them tomorrow), I'd still be working on them in 2080.

>pgut001> (with, admittedly, some attempt at speculating about what
>pgut001> it'll want tomorrow, and to counterbalance that a refusal to
>pgut001> develop crap if that's what people are asking for).  Seems to
>pgut001> be working OK, I haven't had to change jobs once in the last
>pgut001> 12 years.
>
>Good for you :-).

Let me explain the reason for that somewhat out-of-place comment... the
inevitable comeback to "this seems to work" is "well, that's just your
opinion".  What I was pointing out was that it's worked for over a decade, so
it seems to be a good strategy to follow.

Peter.