Skip to content
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

IMPLICIT/EXPLICIT tags #34

Open
masihyeganeh opened this issue Dec 24, 2020 · 5 comments
Open

IMPLICIT/EXPLICIT tags #34

masihyeganeh opened this issue Dec 24, 2020 · 5 comments

Comments

@masihyeganeh
Copy link

I can see that you have implemented ITU-T X.680 | ISO/IEC 8824-1, G.2.12.3 here:

fn assign_implicit_tags(fields: &[Field]) -> Vec<Field> {

But 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 of Tag. Maybe it should be Explicitness<Tag>.

For PER/UPER, both are the same as current implementation, but for BER/DER, explicit fields are their own type wrapped with a ContextSpecific. So It parses input bytes differently.

Can you please take a look at it?
It is blocking #10.

@kellerkindt
Copy link
Owner

kellerkindt commented Sep 27, 2021

I am considering adding a field next to the tag attribute:

#[derive(Debug, Clone, PartialOrd, PartialEq)]
pub struct Asn<RS: ResolveState = Resolved> {
pub tag: Option<Tag>,
pub r#type: Type<RS>,
pub default: Option<RS::ConstType>,
}

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:

pub trait Constraint {
const TAG: Tag;
}

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):

asn1rs/src/syn/io/uper.rs

Lines 549 to 571 in b6d5f77

#[inline]
#[allow(clippy::redundant_pattern_matching)] // allow for const_*!
fn write_utf8string<C: utf8string::Constraint>(
&mut self,
value: &str,
) -> Result<(), Self::Error> {
self.write_bit_field_entry(false, true)?;
self.with_buffer(|w| {
if !C::EXTENSIBLE {
let chars = value.chars().count() as u64;
let min = const_unwrap_or!(C::MIN, 0);
let max = const_unwrap_or!(C::MAX, u64::MAX);
if chars < min || chars > max {
return Err(Error::SizeNotInRange(chars, min, max));
}
}
// ITU-T X.691 | ISO/IEC 8825-2:2015, chapter 30.3
// For 'known-multiplier character string types' there is no min/max in the encoding
w.bits
.write_octetstring(None, None, false, value.as_bytes())
})
}

@masihyeganeh Does this fully cover the required use case?

@kurkpitaine
Copy link

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 ?

@kellerkindt
Copy link
Owner

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 :)

@ghost
Copy link

ghost commented Jan 13, 2023

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.

@kurkpitaine
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants