[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANNOUNCEMENT: SPKI mailing list and BOF at Los Angeles

At 13:36 2/23/96, peter (p.w.) whittaker wrote:
>> Absolutely. As I said, however, that doesn't mean that I necessarily
>> believe that X.509 would have been the result of taking out a blank
>> sheet of paper in an IETF context.
>
>Probably true.  On the other hand, considerable experience has been
>gained with X.509 certificates, so not dismissing them out of hand is a
>good thing....
>
>Note that the "DN problem" can be avoided rather simply:  in X.509
>certificates the Issuer and Subject names must be of type Name, where
>Name is defined in X.501; in X.501, Name is defined as a CHOICE type,
>with the choice currently limited to rdnSequence.
>
>There is nothing that prevents interested parties from extending the
>choice for experimental purposes, veriyfing that the choice is useful,
>then petitioning the ITU/ISO to formally add the new element to the
>CHOICE.  (I've been thinking about this approach and how it could be
>used to harmonize X.500 and the DNS for some time now; maybe one day
>I'll actually been able to bring this idea to the foreground, and spend
>some real time on it.)
>
>I do not write this to be disingenuous:  this may a suitable way of
>leveraging existing technologies as part of an effort to build a
>generalized PKI.

I don't wish to get into a religious war -- especially since I've been
in battles in that war often enough in the past -- but I believe this
reply is a solid example of what I find wrong with ASN.1 and part of what
I consider to be its misuse.  ASN.1 is *so* general that it seduces you
into adding choices in order to avoid conflict during the standard
definition process.  It is extremely good at that.  With ASN.1 you can
defer almost all the battles which would otherwise reduce a standards
effort to a shouting match.

The other side of that seemingly positive coin is that the implementor
is left to deal with the conflict which the standards committee postponed.
That requirement adds both work at the desk of the implementor and
CPU cycles executed during runtime.

I would strongly advocate starting with a blank sheet of paper and
avoiding ASN.1 during our process -- to avoid this very seduction.

IMHO, a good design is just general enough to permit the task to be
accomplished but no more.  It restricts programmers to the point that if
something is expressible in the design, it is probably correct.  The last thing
we want is to saddle the interpreter of certificates with the job of determining
if a cert is of correct format -- has the right fields -- has no conflicting
fields -- etc. when the only reason for the flexibility is avoidance of
conflict during the standards process.

On the subject of ASN.1 misuse, I wrote something earlier:

http://www.clark.net/pub/cme/P1363/asn1.html

 - Carl