Reduce num dependencies, improve class implementation and add explicit tags #7

Merged
Flakebi merged 1 commits from master into master 2018-12-14 08:17:59 -08:00
Flakebi commented 2018-12-09 03:38:15 -08:00 (Migrated from github.com)

Hi,
I used yasna to parse ASN.1 before, but as it is not maintained anymore since a while I switched to this library. It works great for almost everything I want to do, just one thing is missing to encode OpenSSL EC keys.
OpenSSL uses for some reason an explicitely tagged value, which is in general used to distinguish multiple optional values with the same type. In the encoding it is a block where the constructed flag is set and the type is not Universal which wraps another block.

I did some reading on ASN.1 and DER (mostly this) and came up with the following:

The default datatypes always have Universal as their class. If we
encounter another class while parsing, it is a tagged block.

I am not sure how (and if at all) we can distinguish explicitly and
implicitly tagged data. For now they should be parsed as unknown (or
explicit if they are a valid ASN.1 block).

PS: As a small change I copied a small pull request from yasna, that reduces the dependencies quite a bit by only importing the needed num crates.

Hi, I used [yasna](https://github.com/qnighy/yasna.rs) to parse ASN.1 before, but as it is not maintained anymore since a while I switched to this library. It works great for almost everything I want to do, just one thing is missing to encode OpenSSL EC keys. OpenSSL uses for some reason an explicitely tagged value, which is in general used to distinguish multiple optional values with the same type. In the encoding it is a block where the `constructed` flag is set and the type is not `Universal` which wraps another block. I did some reading on ASN.1 and DER (mostly [this](ftp://ftp.rsasecurity.com/pub/pkcs/ascii/layman.asc)) and came up with the following: The default datatypes always have Universal as their class. If we encounter another class while parsing, it is a tagged block. I am not sure how (and if at all) we can distinguish explicitly and implicitly tagged data. For now they should be parsed as unknown (or explicit if they are a valid ASN.1 block). PS: As a small change I copied [a small pull request](https://github.com/qnighy/yasna.rs/pull/7) from yasna, that reduces the dependencies quite a bit by only importing the needed num crates.
acw commented 2018-12-13 14:51:21 -08:00 (Migrated from github.com)

Interesting. The version number stuff is a no-brainer, obviously. Thanks for that.

I'm curious, do you have an online citation for your class/tag interaction? I'm not doubting you -- I looked at what I'll admit was a pretty basic set of resources when I wrote this -- but I'd love to have something I could point at. Failing that, I should accept that if my test cases pass, this must be a correct interpretation of spec. :)

Interesting. The version number stuff is a no-brainer, obviously. Thanks for that. I'm curious, do you have an online citation for your class/tag interaction? I'm not doubting you -- I looked at what I'll admit was a pretty basic set of resources when I wrote this -- but I'd love to have something I could point at. Failing that, I should accept that if my test cases pass, this must be a correct interpretation of spec. :)
Flakebi commented 2018-12-13 16:46:36 -08:00 (Migrated from github.com)

Thanks for taking the time to look at my pr.

I got most information from http://luca.ntop.org/Teaching/Appunti/asn1.html.
Sometimes it is a bit cryptic to read. In the beginning of section 2, it talks about the different classes of tags and for me it seems like only for Universal, the types are defined.

This StackOverflow answer gives a nice explanation why tagging is sometimes needed: https://stackoverflow.com/questions/3296761/i-need-an-example-to-understand-implicit-tagging-in-asn-1

I am by no mean an asn.1 expert, so if you find something that looks fishy, tell me.

Btw your quickcheck tests were really valuable and found one or two bugs in my changes. :)

Thanks for taking the time to look at my pr. I got most information from http://luca.ntop.org/Teaching/Appunti/asn1.html. Sometimes it is a bit cryptic to read. In the beginning of section 2, it talks about the different classes of tags and for me it seems like only for `Universal`, the types are defined. This StackOverflow answer gives a nice explanation why tagging is sometimes needed: https://stackoverflow.com/questions/3296761/i-need-an-example-to-understand-implicit-tagging-in-asn-1 I am by no mean an asn.1 expert, so if you find something that looks fishy, tell me. Btw your quickcheck tests were really valuable and found one or two bugs in my changes. :)
acw commented 2018-12-14 08:17:53 -08:00 (Migrated from github.com)

Cool, that helps. And yes, I ❤️ QuickCheck :)

Cool, that helps. And yes, I :heart: QuickCheck :)
acw commented 2018-12-14 08:23:49 -08:00 (Migrated from github.com)

... and this is now pushed to crates.io as 0.3.0. Thanks for the patch!

... and this is now pushed to crates.io as 0.3.0. Thanks for the patch!
Flakebi commented 2018-12-15 04:59:50 -08:00 (Migrated from github.com)

Thanks!

Thanks!
mehcode commented 2018-12-15 09:01:52 -08:00 (Migrated from github.com)

With this change, ToASN1::to_asn1_class feels very odd to use (as it passes in a class and ASN1Blocks no longer take the class in all forms.

@acw Also, have you thought about #5 ?

With this change, `ToASN1::to_asn1_class` feels very odd to use (as it passes in a class and ASN1Blocks no longer take the class in all forms. @acw Also, have you thought about #5 ?
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: acw/simple_asn1#7