[
Lists Home |
Date Index |
Thread Index
]
frank@therichards.org (Frank) writes:
>If a spec is hard to implement, surely it's hard to implement securely.
>Certainly that applies if it's hard to understand.
>
>If it is hard to implement, what is gained by the tradeoff?
I'm not entirely sure that "ASN.1 is hard to implement" as a general
thing. I haven't tried doing it myself, but it does seem like a fairly
straightforward process in the research I've done.
The problem isn't necessarily that the spec is impossible or that only
geniuses can keep up with BER/PER/etc. The problem - coming from an XML
perspective - is that ASN.1 comes from a very different cultural
background and a different set of assumptions about how best to process
data.
In my explorations, ASN.1 toolkits felts more to me like data-binding
kits than XML parsers. There doesn't seem to be much notion of anything
like an "ASN.1 infoset", a set of containers and properties you can
explore without necessarily knowing the bindings. ASN.1 feels
effectively schema-driven, designed from the outset to be optimized for
a world where processes are tightly bound. There aren't general ASN.1
"parsers" in the same sense that there are XML parsers, or at least
there weren't last time I looked.
Folks who actually care about XML per se are often looking for looser
bindings. ASN.1 chafes against the kinds of assumptions that are common
in XML, like that I might conceivably work on found documents with no
accompanying metadata.
ASN.1 is not for me, for all of those reasons. At the same time,
however, I think ASN.1 makes sense for a lot of applications where XML
is currently in vogue, because it was built from the outset with
data-binding priorities and benefits in mind.
(I don't think ASN.1 likely has worse security than XML, either.)
|
