On 2011-07-06, Nico Williams wrote:
To be fair, when I wrote that "you have to know the schema and message
type in order to do a good job of parsing the message", what I had in
mind was an actual application, not a forensic/debug tool like
dumpasn1 [...]
To my mind the difference seemed to be about shallow versus deep
parsing. You can't really deep parse anything in BER with implicit
tagging, while you can fully parse and also renormalize the intermediate
levels of the parse tree. What is left behind is the stuff beyond
implicit tags, where you can't discern the precise, atomic data types
(which in effect become blobs of octets, then). Just as you said.
In this sense I would agree: to me parsing an input means parsing it
right down to the last bit. If there's anything you have to skip, or
munge, or skirt/skip over, that's not parsing proper, but shallow
parsing.
At the same time, I took Peter's comment to mean that he parses as deep
as is possible, in a deterministic fashion, and then goes on to add some
heuristic for even deeper debugging capability.
(Peter, correct me if I'm wrong.)
I don't see any real tension between these two approaches; one aims at
formal correctness, and the second goes for maximum informativeness in
decoding the stuff. But I'll have to say, I would personally want each
and every protocol out there to be parsed deep. Shallow parsing is a
highly useful debugging and development tool where polymorphism (and
even just general complexity) comes into play. But in the end, if we
talk about Parsing Inputs and Protocols, instead of a
developmental/debugging crutch towards it, we should always be able to
deep parse. Especially in the case of cryptographic protocols, we should
then also fail deep/hard/safe/atomically/with-a-single-fail-code, if the
input string fails to parse just right against an unambiguous grammar.
Against an efficient-to-parse, formal grammar, I might add...
An actual application implementation just needs to know the ASN.1
types of the message being decoded, and this is equally true of PER as
of BER. [...]
The main reason I answered like this was that I'm seeing the first steps
towards a vigorous agreement. :)
--
Sampo Syreeni, aka decoy - [email protected], http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
