-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Port asn1c X.509 and LDAPv3 examples #6
Comments
This parses ENUMERATED with variants that have explicit variant numbers and default markers (...) but it does not reflect those new information in Rust, Protobuf or SQL yet. It just allows them to be parsed without failing the parser. Trying to generate Rust, Protobuf or SQL will result in a panic.
Although UPER is used - which does not care about tags at all - protobuf is using tags. Maybe it will be useful in the future, to remember the tags when converting a Model<Asn> to a Model<Rust> or Model<Protobuf> - i.e. if one is going to implement a BER or DER (de-)serializer.
I have a small list of features that are needed for my project.
|
Passing non-auto like tags or choice-indices will panic-fail the Model<Asn> to Model<Rust> conversion, as well as having an extensible type.
As just detected, the length determinant for the content of the extended CHOICE variants are missing - which is the reason the tests fail.
This allows the caller to recover from a new/unknown variant waiting to be deserialized by skipping it.
For LDAP, at least the following features are missing:
For X.509 Implicit, at least these features are missing:
For X.509 Explicit, at least these features are missing:
(found by manually reading through the file) |
Hello @kellerkindt |
@masihyeganeh I haven't followed up on this ticket specifically, but since you're here, we've built our own ASN.1 framework in Rust called picky-rs since then. It is not an ASN.1 compiler, but it lets you define structures with serde that will automatically map to ASN.1 DER. I don't know what your use case it, but maybe it can fit your needs. |
Thanks @awakecoding for your suggestion but actually |
@masihyeganeh sure, I totally understand. I haven't really given up on the ASN.1 compiler idea, but in order to get things working the serde_asn1_der approach worked very well for us. It's always difficult to find a compiler that handles all the types you need. I wonder if we couldn't attempt modifying asn1rs to generate code that picky-rs can consume, but that would be a project for another time :) is your project open source? I'm curious to see which ASN.1 data structures you have to deal with |
asn1c (https://github.com/vlm/asn1c) is arguably one of the most known and complete ASN.1 compilers. It has a few examples for common ASN.1 modules, such as X.509 and LDAPv3. If you compile asn1c from source with the examples, there's a script that generates the .asn1 files from the RFCs directly.
I pre-generated those for X.509 and LDAP3 and added them here for reference:
https://github.com/Devolutions/asn1rs/tree/examples/examples
For X.509, both the explicit and implicit modules are generated, I don't know which one is better.
I know the current readme says asn1rs won't work with most elaborate ASN.1 modules, but if there are complex ones it should support first, it should be X.509 and LDAPv3 :) I tried and both fail at this point, but I don't know enough of ASN.1 and asn1rs to see which part of the file is not handled correctly.
In all cases, it should be a good thing to include "clean" .asn1 files for useful specifications, known to work with asn1rs. With no_std support, imagine being able to a complete X.509 certificate parser and writer that works in WebAssembly, that would be amazing :)
The text was updated successfully, but these errors were encountered: