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
Support for Optional
in ASN.1
#201
Comments
Hi @fjarri, thank you for opening this issue. I understand from where you are coming from. Indeed, this behavior is following the ASN.1 standard: a component inside a See for instance, the
You can see that all optional fields also have a context-specific tag denoted by the square brackets Serializing
This is arguably a better default for the Rust That being said, I think If you don’t care about ASN.1 / DER in particular and merely need a fast binary encoding as an implementation detail, maybe bincode or postcard will do a better job for you? I hope it helps! |
Thank you for the detailed reply, I suspected there was some reason for this behavior because of the standard. I wanted to use DER in my library to be a little more future-proof and allow easier introspection, but if it can't be mapped to Rust data model, I guess I'll have to stick with MessagePack. Feel free to close the issue if you are going to keep things as they are. |
Actually, I like the idea and am interested in forking the project with the explicit goal of serializing / deserializing DER using the serde data model only. This means that being able to implement most ASN.1 definitions from RFC is an explicit non-goal, but you would still get the advantage of using a wide-used binary format (future-proof, tooling…). One selling point of this crate would be the aforementioned |
Theoretically, yes, but this was a convenient time for me to switch to another format, since ABI was already being changed for other reasons. Plus the application where it is used is in a semi-beta stage, so there are no migration problems. I may or may not find another convenient moment later. But I am in the process of writing another library where I could use DER serialization, and I'm sure a lot of other people will find it useful too. Also, it would be great if you could take over https://crates.io/crates/serde_asn1_der since that's the place where everyone searching for "ASN1 DER serde" ends up. |
Hi again! Sorry for the delay. I had a look at https://crates.io/crates/serde_asn1_der |
A big issue with |
I opened a PR to address the first point: KizzyCode/serde_asn1_der-rust#5 cc @KizzyCode |
As for the human-readable part, this is a bug since DER is definitively not human readable – this will be fixed in any case once I understand the implications (this could be a breaking change in some circumstances). With regards to mappings: This is a limitation of the DER format; there is no standardized representation for mappings. Like @CBenoit said, a common "canonical" solution for this is a sequence of key-(attribute-)value-sequences. For example, X.509 v3 extensions are represented as a sequence of Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING } |
I don't think it's the right way of looking at things. DER does not support structures either, but we serialize structures into it as sequences of fields. Then the deserializer knows to pack it back into the structure. A structure is just a sequence with an implied contract (say, that the second value must be an integer), and the contract is enforced by the deserializer. Same for the mapping. It is again just a sequence with some implied contracts (every element is a 2-sequence, and all the first elements are unique), which will be enforced by a deserializer. DER itself does not need to support all the multitude of possible data structures. Even JSON does not really "support" mappings completely, there is no syntactical enforcement of key uniqueness, it is checked by the deserializer.
That is true, but: there is a de-facto standard, as you mentioned; and how many possible ways are there to serialize a mapping, anyway? Probably another one is a sequence of keys and a sequence of values, but that seems really forced. Moreover, even if it is not standard, it won't affect the people who implement existing specifications, because they know their target representation does not have a mapping, so they will not use it. And @CBenoit mentioned that
|
Well, there is a difference: ASN.1's sequences are designed as a direct 1:1 analogon to typed, ordered structs, whereas there is no native equivalent to mappings.
For example there is one problem with the simple map-representation above: DER has the contract that encodings are reproducable – each input has one and only one valid DER representation (this was actually one of the design goals behind DER as opposed to e.g. BER). This means: If you encode the same input twice, it must produce the same binary output every time – even on different systems with different environments and different implementations etc. One problem is that you need to define a strict ordering of elements. This is fine for types like arrays, vecs, tuples or structs, which carry information about their ordering we can use. However, other types – like In an early version of In general, I'm a bit torn apart... One of my backgrounds is cryptography and embedded development, and in this area implicit contracts like this are a no-go. However on the other hand, I realize that DER is tempting as efficient general-purpose serialization where requirements may not be as strict. It could be worth a shot to implement a best-effort map serialization behind a feature gate and see how this works IRL; but no promises 😅 Edit: One could also argue that I already made a similar implicit assumption for |
Currently
picky-asn1-der
simply skips anyNone
-valuedOptional
fields during serialization, which causes a subsequent deserialization to fail. Would it be possible to serialize a NULL value in this case, or does it somehow contradict the standard?The text was updated successfully, but these errors were encountered: