Open masihyeganeh opened 3 years ago
I am considering adding a field next to the tag attribute:
Something like
pub enum TagExplicitness {
Explicit,
Implicit,
}
#[derive(Debug, Clone, PartialOrd, PartialEq)]
pub struct Asn<RS: ResolveState = Resolved> {
pub tag: Option<Tag>,
pub tag_explicitness: Option<TagExplicitness>,
pub r#type: Type<RS>,
pub default: Option<RS::ConstType>,
}
As well as adding a non-optional field here:
Like so:
pub trait Constraint {
const TAG: Tag;
const TAG_EXPLICITNESS: TagExplicitness;
}
Which could then be used within the impls via C::TAG_EXPLICITNESS
(like C::EXTENSIBLE
below):
@masihyeganeh Does this fully cover the required use case?
Hello 👋🏻
I am currently implementing COER encoding support on this crate. CHOICE encoding works with tags. For now, the compiler generates only universal tags, which is wrong when there are multiple choices of the same type, it should be context-specific tags. Did you start working on this ?
Hi there. I did not start to implement my proposal from above. I am not familiar with the tagging behaviour of ASN.1, because I only use the uPER encoding - so I am very thankful for any kind of support and feedback. Feel free to recommend a better proposal than above, to add yet failing test-cases to fix regarding the tag behaviour or any other kind of PR :)
Hello there,
first of all thanks for the great crate! I also need IMPLICIT/EXPLICIT Tag support - with DER Encoding. Is there someone already doing this (e.g. in a fork?). Otherwise I can try to have a look at it.
Hi 👋🏻 I started looking at it a year ago but did not dig it. I may look at it in the future but not sure at all.
Hello there,
first of all thanks for the great crate!
I also need IMPLICIT/EXPLICIT Tag support - with DER Encoding. Is there someone already doing this (e.g. in a fork?). Otherwise I can try to have a look at it.
I can see that you have implemented
ITU-T X.680 | ISO/IEC 8824-1, G.2.12.3
here: https://github.com/kellerkindt/asn1rs/blob/5ab96c129c0cb8dfa4ea7797a58a513a7abe04b1/asn1rs-model/src/gen/rust/walker.rs#L861But can you please implement
ITU-T X.680 | ISO/IEC 8824-1, G.2.12.5
too? There is a good, simple explanation of it in let's encrypt docs.I'm not sure how it should be after parsing. Now
field.tag
is of kind ofTag
. Maybe it should beExplicitness<Tag>
.For
PER/UPER
, both are the same as current implementation, but forBER/DER
, explicit fields are their own type wrapped with aContextSpecific
. So It parses input bytes differently.Can you please take a look at it? It is blocking #10.