From: Steven M. Bellovin [mailto:smb(_at_)cs(_dot_)columbia(_dot_)edu]
More precisely -- when something is sufficiently complex,
it's inherently bug-prone. That is indeed a good reason to
push back on a design. The question to ask is whether the
*problem* is inherently complex -- when the complexity of the
solution significanlty exceeds the inherent complexity of the
problem, you've probably made a mistake. When the problem
itself is sufficiently complex, it's fair to ask if it should
be solved. Remember point (3) of RFC 1925.
I think that the term 'too complex' is probably meaningless and is in any case
an inaccurate explanation for the miseries of ASN.1 which are rather different
to the ones normally given.
People push back on protocols all the time for a range of reasons. Too complex
is a typically vague and unhelpful pushback. I note that all too often the
complexity of deployed protocols is the result of efforts of people to reduce
the complexity of the system to the point where it was insufficient for the
intended task.
Having had Tony Hoare as my college tutor at Oxford I have experienced a
particularly uncompromising approach to complexity. However the point Hoare
makes repeatedly is as simple as possible but no simpler.
In the case of ASN.1 I think the real problem is not the 'complexity' of the
encoding, it's the mismatch between the encoding used and the data types
supported in the languages that are used to implement ASN.1 systems.
DER encoding is most certainly a painful disaster, certainly DER encoding is
completely unnecessary in X.509 which is empirically demonstrated by the fact
that the Internet worked just fine without anyone noticing (ok one person
noticed) in the days when CAs issued BER encoded certs.
The real pain in ASN.1 comes from having to deal with piles of unnecessary
serialization/deserialization code.
The real power of S-Expressions is not the simplicity of the S-Expression.
Dealing with large structures in S-Expressions is a tedious pain to put it
mildly. The code to deal with serialization/deserialization is avoided because
the data structures are introspective (at least in Symbolics LISP which is the
only one I ever used).
If ASN.1 had been done right it would have been possible to generate the
serialization/deserialization code automatically from native data structures in
the way that .NET allows XML serialization classes to be generated
automatically.
Unfortunately ASN.1 went into committee as a good idea and came out a camel.
And all of the attempts to remove the hump since have merely created new humps.
At this point XML is not a bad choice for data encoding. I would like to see
the baroque SGML legacy abandonded (in particular eliminate DTDs entirely). XML
is not a perfect choice but is is not a bad one and done right can be efficient.
The problem in XML is that XML Schema was botched and in particular namespaces
and composition are botched. I think this could be fixed, perhaps.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf