-
Notifications
You must be signed in to change notification settings - Fork 23
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
Decoding output a bit unintuitive #13
Comments
OK, interesting. Let me track back the reason for that particular Also, welcome fellow Haskell/Rust polyglot. |
Seems like I introduced that code in #7. I don’t remember why I wrote it that way, the goal was to parse OpenSSL EC keys, which contains explicitly tagged data. This comment might be the reason:
|
Hmmmm! Maybe we can work together so we don't replicate each others work? Specifically: @Flakebi: could you maybe commit an OpenSSL EC key or two in @ssadler: could you commit this test case somewhere reasonable, with an Maybe do this all in a |
I've made a branch here with the test: https://github.com/ssadler/simple_asn1/tree/fix/13 It passes without the the |
I added a small test with an explicit tag in #14. |
So, after doing some digging, I found this interesting quote:
(source, page 409) Which makes me think that the current implementation is definitely wrong, but that the example @ssadler brings up might also have a not-entirely intuitive resolution. Anyone else find any interesting quotes on the topic of explicit tags? |
I don't actually know how ASN works; my only thought is, was it tagged in Explicit mode? In this case there's no schema to indicate what mode it was tagged in, the parsing function just parses what it can according to what it knows. The only other thing that occurrs to me, and again limited by my lack of knowledge of ASN, is that the parser could eagerly descend into the element and parse the children. |
In the below script, the function
test_encode
prints:This is unexpected as the structure is the same in both occasions, and it appears to relate to this. I would expect the output to be as it is in
b
both times. I'm not exactly sure if the encoding is being done in the best way, but it conforms to the ASN model I am working with so I can't change it. For reference, the Haskell libraryasn1-encoding
produces the following:Test script:
The text was updated successfully, but these errors were encountered: