4 ms·

I can go over it -- I should note that I like ASN.1 (as described by X.690). As part of a project where I needed to parse X.509 certificates I wrote a simple A

I can go over it -- I should note that I like ASN.1 (as described by X.690). As part of a project where I needed to parse X.509 certificates I wrote a simple ASN.1 -> X.509 parser which does the mapping in place. This can be found at [0]. So while it's possible to decode the structure of an ASN.1 object and many nested things, getting at a meaning requires understanding the schema of the objects being parsed since tags only describe the data type in a limited way. For example, to get the public key from an X.509 certificate you can easily do that -- but it will be an opaque ASN.1 structure unless you know if it's an RSA key or an ECDSA key, which is encoded as data in another ASN.1 OID somewhere, not as PART of the ASN.1 tag. So if you wanted to get the exponent for an X.509 certificate (like x509_to_exponent() does), then you need to know the schema for that type of public key -- here, it's specified in PKCS#1 (because only RSA is supported by this software), a completely unrelated standard. [0] https://cackey.rkeene.org/fossil/artifact/bc9c145e70285c54?ln https://cackey.rkeene.org/fossil/artifact/bc9c145e70285c54?l...

pas 5y ago
That makes sense. After all if you have an arbitrary JSON (or XML) you don't know what is that, unless you have a schema, then you can check conformance, etc. And probably given a schema it's easy to give the user (developer) bound methods that reference some value in that "structured blob", and of course it's possible to reuse that method with other blobs. (While having some error handling of course.) But how come people have aversions with ASN1? Is it just stylistic as with XML? (And that it's used as the substrate for a bunch of old harebrained standards and protocols - all with artisanal shitghetti C codecs instead of the aforementioned robust parser + schema?)
- rkeene2 5y ago
  The difference is really just that the ASN.1 tag really just contains the data type, with limited application-level space to describe it. JSON/XML let you us an arbitrary string to "tag" data. ASN.1, on the other hand, has many more types (as we can see in this article!) including dates, big integers, choices, sequences, and more.
  - pas 5y ago
    Sorry, I wasn't precise enough. I meant some kind of JSON with just arrays and cryptic object names - like the OIDs for ASN1 - or XML where everything is just called <node>. So yes, it makes things less "introspectable", but any serious protocol needs a well-defined schema anyway. (And that's why GraphQL and OpenApi/JsonSchema, and before that WSDL/SOAP were so popular.) It seems strange that people "hate" ASN1. At best the problem seems to be the libraries, or that no sane restricted subset has emerged over the years...?
    - rkeene2 5y ago
      I've been thinking about a good way to explain this for a couple of days I think the best way is convert the ASN.1 to some psuedo-typed-JSON. For an X.509v3 public key, the ASN.1 would look like this in JSON-with-types: [ [ [type:<oid>]: "1.2.840.113549.1.1.1", [type:<null>] ], [type:<bitstring>]: <encoded>[ [type:<bigint>]: 39054839120582390568029762340674230..., [type:<bigint>]: 65537 ] ] "<encoded>" here means an ASN.1 value is serialized and then contained as a binary string. As you can see here, you only know the structure and type. This falls apart here at the "bitstring" value -- it's an opaque binary blob, which happens to be ASN.1 again, which you would only know if you know the schema. If we converted this to something more self-describing it would look more like (borrowed kind of from TJSON): { "publicKeyInfo:<o<oid,...>>": { "publicKeyType:<oid>": "1.2.840.113549.1.1.1", "publicKeyParams:<null>": null }, "publicKey:<o>": { "n:<bigint>": "39054839120582390568029762340674230...", "e:<bigint>": "65537" } } Having this kind of human description in addition to the type and structure makes it easier to work with if you don't know what's inside the structures.
      - pas 5y ago
        Thanks! This indeed is absolutely horribly insane, yet I guess there are some good-ish reasons for why this is the way this is.

pas 5y ago

That makes sense. After all if you have an arbitrary JSON (or XML) you don't know what is that, unless you have a schema, then you can check conformance, etc. And probably given a schema it's easy to give the user (developer) bound methods that reference some value in that "structured blob", and of course it's possible to reuse that method with other blobs. (While having some error handling of course.) But how come people have aversions with ASN1? Is it just stylistic as with XML? (And that it's used as the substrate for a bunch of old harebrained standards and protocols - all with artisanal shitghetti C codecs instead of the aforementioned robust parser + schema?)

rkeene2 5y ago
The difference is really just that the ASN.1 tag really just contains the data type, with limited application-level space to describe it. JSON/XML let you us an arbitrary string to "tag" data. ASN.1, on the other hand, has many more types (as we can see in this article!) including dates, big integers, choices, sequences, and more.
- pas 5y ago
  Sorry, I wasn't precise enough. I meant some kind of JSON with just arrays and cryptic object names - like the OIDs for ASN1 - or XML where everything is just called <node>. So yes, it makes things less "introspectable", but any serious protocol needs a well-defined schema anyway. (And that's why GraphQL and OpenApi/JsonSchema, and before that WSDL/SOAP were so popular.) It seems strange that people "hate" ASN1. At best the problem seems to be the libraries, or that no sane restricted subset has emerged over the years...?
  - rkeene2 5y ago
    I've been thinking about a good way to explain this for a couple of days I think the best way is convert the ASN.1 to some psuedo-typed-JSON. For an X.509v3 public key, the ASN.1 would look like this in JSON-with-types: [ [ [type:<oid>]: "1.2.840.113549.1.1.1", [type:<null>] ], [type:<bitstring>]: <encoded>[ [type:<bigint>]: 39054839120582390568029762340674230..., [type:<bigint>]: 65537 ] ] "<encoded>" here means an ASN.1 value is serialized and then contained as a binary string. As you can see here, you only know the structure and type. This falls apart here at the "bitstring" value -- it's an opaque binary blob, which happens to be ASN.1 again, which you would only know if you know the schema. If we converted this to something more self-describing it would look more like (borrowed kind of from TJSON): { "publicKeyInfo:<o<oid,...>>": { "publicKeyType:<oid>": "1.2.840.113549.1.1.1", "publicKeyParams:<null>": null }, "publicKey:<o>": { "n:<bigint>": "39054839120582390568029762340674230...", "e:<bigint>": "65537" } } Having this kind of human description in addition to the type and structure makes it easier to work with if you don't know what's inside the structures.
    - pas 5y ago
      Thanks! This indeed is absolutely horribly insane, yet I guess there are some good-ish reasons for why this is the way this is.