does picky-asn1 support BER?

[Firstyear]

Hi there!

I was needing an x509 crate and who ever should I find makes an excellent set of crates in this space!

Currently I know that devolutions is using my ldap3 library, but it's using an alternate asn library. If picky-asn1 supported ber, I'd have no problems changing it over to collaborate more with you all.

And if picky-asn1 doesn't support BER today, what would it take to add it?

Thanks!

[CBenoit]

Hi! Thank you for considering collaborating further with us!!

Unfortunately, I don’t think I can recommend you picky as a low-level building block for DER (and BER, even if we were to support it). I believe that using serde as our deserializer / serializer engine was not a great idea.

The reason is that it’s impossible to map the whole ASN.1 data model into the serde data model. It is possible to map the serde data model into the ASN.1 data model, but the other way around is simply not possible. In a sense the ASN.1 data model is a superset of the serde data model, it has more types. It’s possible to build a serde Serializer and Deserializer for a subset of DER/BER, and that’s still nice, but we realized it was a poor fit to implement the data structures defined in the various specifications and RFCs. Indeed, these data structures are requiring types which cannot be modelized using serde data model. This led us to implement a few workarounds.

Here are some workarounds:

• Some types are special cased directly in the deserializer
• Some types are special cased directly in the serializer
• Some types have custom Serialize / Deserialize implementations assuming the DER serializer / deserializer is used and modifies the DER directly

Again, these workarounds are strongly suggesting that the serde data model is not a good fit. I have to admit that we are not using serde as it was meant to be used, and, as a result, even though our data structures are implementing the Serialize and Deserialize traits, they are kind of assuming the serializer will be picky-asn1-der, and will behave strangely with other serde serializers (e.g.: serde_json). Implementing a BER serializer / deserializer the same way we did for DER is possible, but we would need similar workarounds again…

Incidentally, the der crate by RustCrypo is exactly how I would rewrite picky-asn1 / picky-asn1-der today if I had the time for that. Instead, I just recommend using this crate for DER needs. Unfortunately, I don’t think it’s possible to use it for BER yet.

Out of curiosity, why are you considering changing your ASN.1 library?

[Firstyear]

Incidentally, the der crate by RustCrypo is exactly how I would rewrite picky-asn1 / picky-asn1-der today if I had the time for that. Instead, I just recommend using this crate for DER needs. Unfortunately, I don’t think it’s possible to use it for BER yet.

Out of curiosity, why are you considering changing your ASN.1 library?

At the moment we're using the lber / nom parser which has it's quirks but it works. There's a lot we could improve in ldap3.

It was more that I know Devolutions uses ldap3, and if you have an ASN1 library that is supported, I would trust it as a building block for ldap3. It's sometimes good to re-examine our building blocks and who works on them.

Saying this, the der crate from RustCrypto seems good, I'll see if they are considering BER as well.

[CBenoit]

At the moment we're using the lber / nom parser which has it's quirks but it works. There's a lot we could improve in ldap3.

It was more that I know Devolutions uses ldap3, and if you have an ASN1 library that is supported, I would trust it as a building block for ldap3. It's sometimes good to re-examine our building blocks and who works on them.

Saying this, the der crate from RustCrypto seems good, I'll see if they are considering BER as well.

That’s a good idea! Alternatively, the asn1-rs crate is looking quite good too and supports both DER and BER! I know that the author has been working on Kerberos / LDAP stacks for a few years. It may be worth to check it out.

[Firstyear]

Fantastic! I'll follow up and see what's going on there too. Thanks so much. :)

[Firstyear]

Actually, even a cursory glance shows most of their protocols are FromBer/Der only. We'd need to look into to writing the encoding side. Part of what brought this up is that soon I'll need to write a CA and you have picky-asn1 and x509 that's used by rust-tss-esapi which I'm quite involved in, but also a KDC so I'll need KRB support too. So I was hoping to standardise on a single framework for these, and since I trust you and your work I was hoping I could jump over to the picky-asn1 crates.

The asn1-rs crate looks good but mostly it seems to be one way. So maybe I'll have to put in some work for that. I'd like us all to be in a place where we have a solid base to work from be in ldap or x509.

[CBenoit]

The asn1-rs crate looks good but mostly it seems to be one way. So maybe I'll have to put in some work for that. I'd like us all to be in a place where we have a solid base to work from be in ldap or x509.

At least the doc mentions DER and BER encoders: https://docs.rs/asn1-rs/latest/asn1_rs/#berder-encoders
The ToBer trait appears missing, but since DER is a subset of BER, it’s okay to use ToDer instead as long as you don’t need a special feature unique to BER.

However, as you said, crates built on top such as x509-parser appears to be one-way only, so we would need to re-implement all of that…

[CBenoit]

Of course, you can use picky crates for KDC and X509 certificates, they works well, but the building blocks we used could have been better, and today I think that the right approach for DER/BER is not the one we took. Sadly, we can't just fix it either.

All that being said, if you would still rather use picky-asn1, it's absolutely possible to build a picky-asn1-ber crate. Essentially, you could copy paste picky-asn1-der and make the deserializer more lenient.

[Firstyear]

Right now I'm looking at the rust crypto der crate, I think it may be the best option long term then :)