ASN.1 Editor (at http://lipingshare.com/Asn1Editor/) does a pretty good
job regrarding decoding
without knowledge of the format.
Regards,
Sascha
Steven Reddie schrieb:
I understand you're point. I can imagine some interesting things done with
XSLT.
I guess I just haven't come across a case in practice (other than pretty
printing) where I needed to decode without knowledge of the format of the
data. I also feel that there are worse things done with ASN.1, from the
standpoint of being able to parse the data in it's entirety without
knowledge of the format, that make this implicit tagging issue pale in
comparison, such as encoding entire objects into an OCTET STRING member of a
structure. The value of an X.509 extension is a good example where, even in
the absence of implicit tagging, the content of the extension value is
largely unknown:
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
Regards,
Steven
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Thursday, 8 September 2005 10:35 PM
To: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
Is this a concern for real applications, things other than pretty
printers and protocol dumpers?
Yes.
I agree that it makes it difficult to
understand the
content without a format description, but it's no worse than some
proprietary encoding. Is translating into XML without knowing the
"language" of the format something that needs to be done?
Yes. A generic BER->XML converter and XML->BER converter would be
very handy. That would easily let people interact with a variety of BER
applications even in languages that don't manipulate raw binary very well.
Another example is a C++ BER decoder. When an integer is received,
it is expected to decode it into its integral value. But how can it do that
if it can't tell what's an integer and what isn't?
I would have
thought that anything that isn't understood should be left as a "black
box"
blob for a downstream decoder to handle.
The idea is to be able to convert BER encoded integers from the BER
binary form to host form in once place. The idea is to convert BER encoded
floating point values, bit streams, strings, and the like into the
appropriate native format once, when they're received.
It's a horrible mixing of layers to have the protocol engine receive
decoded objects from the BER decoder and then have to pass objects into
another BER decoder (or back into it), once it figured out what type they
were.
How fun would it be to code, say, a telnet server if TCP required a
similar mechanism?
You get similar things in XML
where there might be a <Base64Certificate>MIIB...=</Base64Certificate>.
I don't think they're really similar because it's not clear there's
a better way in this case. It's obvious that BER can provide a better way --
explicit typing. Frankly, I think it's a real shame the BER specification
didn't say that if you want to send a BER-encoded integer, you should do it
in an object of type INTEGER.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
