Readability of dumpASN1.js output

[olibu]

This is not a bug issue but a discussion thread regarding the readability of dumpASN1.js

Remark: If you want to want to execute the dumpASN1.js first run the updateRFC.sh to create the required config files.

In general it is much more readable than the asn1parse from openssl ;)

I'm not sure about the purpose of the dump functionality, but I expect it should be used to get information about the content of the ASN1 data. Thus I would not include to much technical information. I would remove the following data (or maybe would hide them by default and only show them in a "detailed" mode:

• The pos ans size information "@97+30"
  • The position is already part of the indention and it is related to the byte structure which is not visible at all
  • The size is somehow confusing, too. As the values are formated like "2020-09-02 13:25:26 UTC"
• Constructed and Encapsulated
  • This has not been important in the last 15 years for me. I never missed this information in the UI version.
  • Maybe the could be represented by different colors
• Amount of elements
  • Is already represented as part of the indention
  • Maybe in a darker color?
• More clear separator between value and explanation
  • It's kind of difficult to differentiate between the value and label
  • Example: algorithm OBJECT_IDENTIFIER @315+3: 1.3.101.112|curveEd25519|EdDSA 25519 signature algorithm
  • I would prefer something like: algorithm OBJECT_IDENTIFIER: 1.3.101.112 (curveEd25519 | EdDSA 25519 signature algorithm)
  • The label could be in a darker color, too

[olibu]

A user friendly representation of the keyUsage would be great.

Extension SEQUENCE @541+14 (constructed): (3 elem)
          extnID OBJECT_IDENTIFIER @543+3: 2.5.29.15|keyUsage|X.509 extension
          critical BOOLEAN @548+1: true
          extnValue OCTET_STRING @551+4 (encapsulates): (4 byte)|03020186
            BIT_STRING @553+2: (7 bit)|1000011

Could look like

Extension SEQUENCE: (3 elem)
          extnID OBJECT_IDENTIFIER: 2.5.29.15 (keyUsage | X.509 extension)
          critical BOOLEAN: true
          extnValue OCTET_STRING: (4 byte) 03020186
            BIT_STRING: (7 bit) 1000011 (Digital Signature, Certificate Sign, CRL Sign)

[lapo-luchini]

I'm not sure about the purpose of the dump functionality

Main purpose was to have a way to dump the parsed data, in order to debug the parser itself.

Constructed and Encapsulated. This has not been important in the last 15 years for me. I never missed this information in the UI version.

Actually it has been there since (almost) the beginning… 🤣 (though visible only on hover, which makes sense as the information can be useful, but it's not as useful as to warrant being visible at all times)

A user friendly representation of the keyUsage would be great

I agree. the RFC does contain the name of the bits, and that could be done. Right now RFC parser is not decoding that, though.

More clear separator between value and explanation

I generally agree on this, especially on the "color change", a bit less so on the usage of parens instead of colons… but yes work can be done in that area.

As per the first quote this dump might be useful for someone else, but main objective was to aid myself during the writing of the parser, so it needed to show more stuff than generally useful "for the end user". This kind of data should eventually end up in the browser (optionally), and then I expect this CLI tool the be much less important at the time. But this is no reason not to have it improve anyways, of course.

[olibu]

In this case, coloring like in the UI and indention should make it a little bit more readable.

Parent ╠═ Child ║ ╠═ Child of Child ║ ╚═ Last Child of Child ╚═ Last Child

Or with single lines Parent ├ Child │├ Child of Child │└ Last Child of Child └ Last Child

[lapo-luchini]

Single lines look good to me. 👍🏼 It also makes sense to hide offset/size/constructed/encapsulated unless a parameter is used (maybe -v/--verbose?).