[ massive cross-post stripped down to just ietf-open-pgp ]
From: Gunther Schadow
<gunther(_at_)gusw(_dot_)dialup(_dot_)fu-berlin(_dot_)de>
I have a strong personal distaste with S/MIME, as the PKCS specs
require ASN.1, X500 and other OSI stuff that does not merge very well
with the rest of the Internet infrastructure.
No one can argue with personal taste. But my personal experience is
contrary to those who believe that "ASN.1, X.500, and other OSI stuff"
is difficult to use, difficult to program, and inevitably results in
slow, bloated code.
Is your distaste the result of having actually written an S/MIME user agent
or X.509 certificate library, or is it just a fear of the unknown? In
an effort to teach myself X.509, I wrote a certificate parser from scratch,
rather than reuse code available from my employer, or the excellent
software from Eric Young, Consensus, SECUDE, and elsewhere.
Going in to that exercise, I regarded ASN.1 as a regrettable but necessary
evil. Coming out, I have a new-found respect for ASN.1 as a protocol
documentation language and for BER as a universal, application-independent
serialization/marshalling mechanism.
Precisely what do you mean by "the rest of the Internet infrastructure"?
* The bits-in-boxes diagrams that document the TCP/IP stack? Those are
easy to understand, but not quite flexible enough for use in describing
application-layer protocols.
* Various BNF/EBNF notations?
* Protocol-specific notations such as the one defined by a whole chapter
in the TLS specification?
* XDR (as used by ONC-RPC)?
* S-expressions, or hybrid ASCII-binary encodings (as used by SPKI)?
* SGML/HTML/XML?
* other private/domain-specific notations I know nothing about or am
not even aware of (DCE-RPC, CORBA, ...)?
All of these arguably have their place, but the sheer number of them
suggests that there is no "Internet infrastructure" to which all of them
belong but from which ASN.1 is, for some reason, excluded.
To the contrary, I believe that there is significant benefit in using
a common protocol description language across multiple protocols - it
enables the community's investment in knowledge, tools, code samples, and
most importantly, lessons learned, to be amortized over diverse application
domains. To cite just one example, the ASN.1 OBJECT IDENTIFIER is a powerful
mechanism for achieving global registration of almost anything (data
structures, algorithms, protocols, policies, etc.) that requires agreement
between implementors, guaranteed uniqueness, and support for both
standardized and local object definitions. How many different defined
constants or GUIDs does the world need to refer to the MD5 hash algorithm?
And to be more practical and less philosophical, I believe that ASN.1
can more than hold it's own from a code size, memory usage, and runtime
perspective against the alternatives. It would be interesting to see
(no, Jon, I'm not volunteering to write them! :-) benchmarks of the
kilobytes and microseconds required to parse PGP, SPKI, and X.509 certs,
or of ASN.1 vs. "native" representations for both PGP and SPKI certs.