Problem parsing and encoding Option for CHOICE about rasn HOT 10 CLOSED

Alright, I've now both implemented SET encoding/decoding, and to test that everything would work as expected, I actually implemented RFC 5280 myself. It's available under standards/pkix. Check it out, and I will release it in a couple of days, once I've added documentation and written release notes.

from rasn.

This particular spec which I have problem with is all encoded using implicit tags. You can find the GeneralName spec on the top of page 127 and DistributionPoints related specs at the bottom of page 128. They are all in Apendix A.2, so the tags are implicit.

from rasn.

Thank you for your issue! I'll look into this, I remember not being completely happy with how I implemented options, so it could be wrong.

from rasn.

@Albibek Okay, I believe I've fixed the issue, though to be honest I couldn't ever get your example to fail, so I might have been missing something (see tests/x509.rs).

from rasn.

Yep, sorry I didn't add asserts initially, was just analysing visually. I can see now that the structure is parsed, but encoding the same structure back does not give the same byte string in the second test.

I may be wrong, but it seems that the tag becomes explicit somehow. I've fixed the gist to contain the assertion, so you could get a better view on it.

from rasn.

I'm still debugging it, but this is the exact diff between the two at the moment, using pretty-assertions. Expected is on the left, and rasn is on the right.

Diff < left / right > :
 [
     48,
<    120,
>    114,
     48,
<    58,
>    112,
>    128,
>    110,
     160,
<    56,
<    160,
<    54,
>    108,
     134,
     52,
     104,
     116,
     116,
     112,
     58,
     47,
     47,
     99,
     114,
     108,
     51,
     46,
     100,
     105,
     103,
     105,
     99,
     101,
     114,
     116,
     46,
     99,
     111,
     109,
     47,
     68,
     105,
     103,
     105,
     67,
     101,
     114,
     116,
     65,
     115,
     115,
     117,
     114,
     101,
     100,
     73,
     68,
     82,
     111,
     111,
     116,
     67,
     65,
     46,
     99,
     114,
     108,
<    48,
<    58,
<    160,
<    56,
<    160,
<    54,
     134,
     52,
     104,
     116,
     116,
     112,
     58,
     47,
     47,
     99,
     114,
     108,
     52,
     46,
     100,
     105,
     103,
     105,
     99,
     101,
     114,
     116,
     46,
     99,
     111,
     109,
     47,
     68,
     105,
     103,
     105,
     67,
     101,
     114,
     116,
     65,
     115,
     115,
     117,
     114,
     101,
     100,
     73,
     68,
     82,
     111,
     111,
     116,
     67,
     65,
     46,
     99,
     114,
     108,
 ]

from rasn.

Hmm, could you clarify what version of the module you're using? there's one with explicit tags and one with implicit tags, and that would be relevant to how we encode this.

from rasn.

Hmm, could you clarify what version of the module you're using? there's one with explicit tags and one with implicit tags, and that would be relevant to how we encode this.

Not sure what do you mean by this. In Cargo.toml I'm importing only main branch of rasn

rasn = { git = "https://github.com/XAMPPRocky/rasn.git", branch = "main" }

And then, in .rs file I import everything as

use rasn::{de::Decode, types::*, *};

Am I missing some options allowing me to specify which tags to use?

from rasn.

Not sure what do you mean by this.

RFC5280 contains two ASN.1 modules, one with EXPLICIT TAGS and another with IMPLICIT TAGS. Whichever one you use would change how you'd structure the rasn data structures.

from rasn.

Wow, that is really cool, thank you, it works now! I can now migrate to using your library in my whole solution.

Also had to fix an error in my test: the certificate apparently had a list of distribution points instead of one point with the list of names. I've updated the gist for historical reasons.

from rasn.