Subject: Semi-annual reminder: dumpasn1 utility available

From: [email-masked] (Peter Gutmann)
Date: Fri, 8 Dec 2000 12:07:41 (NZDT)

This is a semi-annual reminder to people about dumpasn1, which picks apart
ASN.1 data and displays it in human-readable form.  I do actually update this
every now and then, so it's worth checking every few months for new copies.
Recent (within the last 6-12 months) features include automatic detection of
stuff encapsulated inside bit/octet strings (no more -o or -b options),
detection of encapsulated text strings disguised as something else, the ability
to display text alongside a hex dump of data, an attempt at displaying
BMPStrings under Windows (which for console apps doesn't actually work anything
like what the docs would have you believe, if anyone can get it to display non
8859-1 characters let me know), and an indication of which bit is set if you've
got a large string of zero bits with a single 1 bit at the start (this was
motivated by the need to pick apart CMP error codes).

Available as usual from http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.{c|.cfg}
for the source code and config file.

Peter.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 9 Dec 2000 17:32:56 +0100

Peter,

> ASN.1 data and displays it in human-readable form. 

I have to comments to this:

1. It seems like a very nice little utility which I had no problem to get running!

2. Referring to the XML vs ASN.1 debate I do not think human-readable is entirely correct
as ASN.1 does not support that.  At least when I dissassembled a PKCS #7
package I could not see tags like Certificate, Subject, Issuer etc.  AFAIK (this
is not much when it comes to ASN.1) you have to _know_ in advance what kind of data
structures you are dealing with in order to display such information.

<snip>

Anyway, a very good utility!

Anders

---

From: [email-masked] (Terry Hayes)
Date: Sat, 09 Dec 2000 09:56:34 -0800

> structures you are dealing with in order to display such information.

And you have to _know_ in advance what the "Certificate", "Subject" and 
"Issuer" might be representing, how they should be processed, and what 
they might be useful for.  "Human-readable" doesn't help write programs.

Terry

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 9 Dec 2000 21:48:11 +0100

Terry,
 
> they might be useful for.  "Human-readable" doesn't help write programs.

Absolutely true, but if the elements represent data that two or more parties have to
agree upon, as for purchase orders (or why not ACs?), it helps a bit if the format gives some
aid to the debugging process.  Debugging was BTW the sole reason for me trying out Peter's
Dumpasn1 tool.  Using XML I would neither have had to "guess" element usage, nor use a "debugger".

Anders

---

From: <[email-masked]>
Date: Sat, 9 Dec 2000 22:37:14 +0100

> 2. Referring to the XML vs ASN.1 debate I do not think
> human-readable is entirely correct as ASN.1 does not
> support that.  At least when I dissassembled a PKCS #7
> package I could not see tags like Certificate, Subject,
> Issuer etc.  AFAIK (this is not much when it comes to
> ASN.1) you have to _know_ in advance what kind of data

And by the way - I recently posted an EDDF announcement that received much
more attention in sci.crypt than it did here, although it is the people in
this group that it was primarily aimed at.

EDDF is an ASN.1-based data format that does exactly what you say ASN.1
doesn't do on its own: it provides some inherent sense for ASN.1 structures
in a manner very similar to XML. Of course, it is also technically much more
sound than XML. ;-)

If anyone is interested, I can compile a FAQ based on the recent discussion
in sci.crypt and post it here.

Regards,

denis

//
//  KEEP REAL CRYPTO, SAVE REAL MONEY
//  globera offers support for Crypto++, as well as
//  professional consulting and integration services
//  for practical applications of cryptography.
    Thanks to our location, we can offer quality
    services at compellingly reasonable rates.
    http://www.globera.com/services

---

From: "Khaja E. Ahmed" <[email-masked]>
Date: Sat, 9 Dec 2000 14:17:01 -0800

I think what we are talking about here is the degree of readability or ease
of readability rather than just readability as a binary value.  I suspect
there are more people who "know in advance" what a "certificate"  or a
"subject" is than can recognize an OID representing these attributes.   I
suspect it can be agreed that "human readability" is not a binary value but
a continuum.  ASN.1 and XML are, it is being argued, at different spots on
this continuum.  XML is _more_ human readable than ASN.1.

Recognizing the highly subjective / non-quantifiable nature of such
assertions, it may be stated that:

1.) One needs to "know more" in order to read and understand ASN.1 encoded
information than would be necessary to read and understand the same
information encoded in XML.
2.) It takes less time to become proficient in XML than it does in ASN.1

At least that is what some people seen to believe.

Khaja

----- Original Message -----
From: "Terry Hayes" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, December 09, 2000 9:56 AM
Subject: ASN.1 readability (was Re: Semi-annual reminder: dumpasn1 utility
available)

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Sat, 09 Dec 2000 20:21:38 -0500

Anders Rundgren wrote (in part):

snip 

>  Using XML I would neither have had to "guess" element 
>  usage, nor use a "debugger".

Really? Consider the ASN.1 value

   concord INTEGER ::= 3

which could be transferred directly as text or DER 
encoded into the binary value 0x020103.

What does representing this value using XML mark 
up such as  

   <concord> 3 </concord> 

tell you? 

Do I mean a how I rate a city, a quantity of grapes,
or that the treaty is behind door number number three?

I agree of course that the mark up format may be easier
for programmers who lack tools or reasonable skills and 
training to debug. But consider actual usage. 

I may debug this message for a short while during a
program development period, then deploy the program 
and transfer this message billions of times with no
human intervention. 

Why would I wish to transfer 22 bytes of information 
instead of three? 

What advantage does transferring 19 extra bytes give 
my application?

Once deployed, will it matter to the performance of
the program whether or not this message can be easily 
read by a human?

If a client should receive a broken message from my
program, will the users lot be improved if they can
correct the broken message with NotePad?

Phil

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 10 Dec 2000 10:05:36 +0100

Phil,

> or that the treaty is behind door number number three?

I don't think that XML will solve all information problems, but if you get a whole
bunch of data like in the PKCS #7 blob I reffered to and you would like to cross-check
that with the specification (which was exactly what I tried to do), XML-based data would
be much simpler.

> training to debug. But consider actual usage. 

This is both right and wrong.  If we consider things that for a lot of reasons
must be identically interpreted by a LARGE audience like the X509 certificate, any
coding scheme would do, ASN.1 included.

What sparked my interest in XML in conjunction with PKI was things like the AC which IMO
(but not in everyones opinion), could proliferate in completely local attribute schemes
as well as international or application-specific schemes.  These schemes will have
practically nothing but the header in common.  They may also change content frequently
(i.e. there will be versioning of attribute data).  If that really becomes the case, ASN.1
would be a bad choice.  But as you probably have noted the AC already has contenders
like S2ML so I don't think we will see that much AC implementations. 

Being in the computer business since 20 years I see program/format/message
incompatibilities becoming more and more the #1 problem/plauge.
The upgrading processes costs zillions of dollars each year.  ASN.1 does not
address this problem properly.

> and transfer this message billions of times with no

For stable structures this is 100% true.  But is the world stable?

> Why would I wish to transfer 22 bytes of information 

Certainly not.  See answer above.

> What advantage does transferring 19 extra bytes give 

Nothing of course!

> correct the broken message with NotePad?

OK, I actually don't believe (hope at least!) that this is how XML incompatibilities will be handled.
The XML schema thing gives you a useful versioning capability that at least will make it 100%
clear if you are digesting the right stuff or not.  At least a starter although not a cure.  I don't
believe there is a cure for message incompatibilities.  Some XML proponents do.  They are
obviously selling something they cannot deliver!

Anders