Add IEEE 1609.2-2022 , ETSI TS 103097 standards, InnerSubtypeConstraint

[Nicceboy]

Adds following standards

• IEEE 1609.2 2022
• ETSI TS 103097
  • In two crates to avoid cyclic dependency

All structs will use bon as build pattern, unless newtype syntax is used.

Modifies rasn to add InnerSubtypeConstraint signature trait and relevant error messages.
Decode validation is left for the user. (validate_components() trait method available)

Adds benchmark for IEEE 1609.2 certificate.

Standards have high usage of ASN.1 classes and other information objects, not all might be absolutely correct. But I have tried to. Validation would require some external test data.

[XAMPPRocky]

Thank you for your PR! I didn't look at it too in depth because it's still in draft but I have some initial comments that we can talk about while work continues.

Modifies rasn to add InnerSubtypeConstraint signature trait and relevant error messages.
Decode validation is left for the user. (validate_components() trait method available)

Can we split out this part? Just makes it easier to review and merge quicker. Also do you think it's possible for rasn to handle this validation in the future? I haven't run into subtype constraints before.

IEEE 1609.2 2022
ETSI TS 103097

I noticed that the name for both crates is simply the name of the standard. Which to be seems rather unappealing, sure it is what the specific standard is called but I think we can polish those up, so they are more appealing. If you look at the other crates in the standards directory, for larger standards they are named after the encompassing standard, rather a specific standard, and multiple standard documents make up the implementation.

So in that in mind, what would think about calling "ieee1609dot2", "wave" (Wireless Access in Vehicular Environments), and "ts103097", "its" (Intelligent Transport Systems). This would also remove the need for the extensions to be a separate crate, it can just be a module in the its crate.

[Nicceboy]

Can we split out this part? Just makes it easier to review and merge quicker. Also do you think it's possible for rasn to handle this validation in the future? I haven't run into subtype constraints before.

If it is, it would be very difficult. I think procedural macros don't have access into enough information, or we would need to create some descriptive model in our own that describes component relationships and then generates some validation checks. But the effort might be similar on just writing that validation function manually.

This would be more likely a job for the compiler which has more information available.

So in that in mind, what would think about calling "ieee1609dot2", "wave" (Wireless Access in Vehicular Environments), and "ts103097", "its" (Intelligent Transport Systems). This would also remove the need for the extensions to be a separate crate, it can just be a module in the its crate.

Would it be problematic if they grow too large? WAVE has plenty of other standards as well.
E.g. there is ieee1609dot2dot1 and ieee1609dot2dot2 too, and they are very large as well.

Same comes to ITS part, there are dozens of standards. If we put everything into single crate, it would be tens of thousands of lines in the end.

When these standards are being used, only a specific part is usually needed, depending on the context. But it would make developing easier, and we can guarantee that there are no duplicate definitions of the same type, on the other hand.

Also, people who work with these standards, search them for exactly based on these naming conventions that they currently have. But maybe they are still well discoverable when in a single crate.

[Nicceboy]

Decode validation is left for the user. (validate_components() trait method available)

To clarify, I have currently created those methods manually for the types, but user has a choice whether they validate or not after decoding. Automatic creating of those validation methods need a lot of information across all dependent types.

[XAMPPRocky]

If it is, it would be very difficult. I think procedural macros don't have access into enough information, or we would need to create some descriptive model in our own that describes component relationships and then generates some validation checks. But the effort might be similar on just writing that validation function manually.

Right, what I'm imagining is a mix of proc macros and using traits to create a solver that can apply to any of the situations. We can open a separate issue for tracking building out support for this. I'm not opposed to for example, having the compiler generate the validation checks that map to the handwritten code now, and then if/when we can implement it in Rust, the generated code in the compiler can use that.

Would it be problematic if they grow too large? WAVE has plenty of other standards as well.
E.g. there is ieee1609dot2dot1 and ieee1609dot2dot2 too, and they are very large as well.

Same comes to ITS part, there are dozens of standards. If we put everything into single crate, it would be tens of thousands of lines in the end.

When these standards are being used, only a specific part is usually needed, depending on the context. But it would make developing easier, and we can guarantee that there are no duplicate definitions of the same type, on the other hand.

I don't consider it to be problematic, it's better to have be too big than too small IMO, especially initially. I'm not expecting these types to have a lot of churn on them since they are defined in a international standard. Most contributions will be improving quality of life of using them. Also if we change our minds, we can always split out parts of it into separate crates (e.g. "rasn-wave-1609" or "rasn-wave-messages").

Also regarding search, we can add the list of standards to the readme and as keywords to the cargo.toml, so that when they search the standards, these crates come up.

[Nicceboy]

Right, what I'm imagining is a mix of proc macros and using traits to create a solver that can apply to any of the situations. We can open a separate issue for tracking building out support for this. I'm not opposed to for example, having the compiler generate the validation checks that map to the handwritten code now, and then if/when we can implement it in Rust, the generated code in the compiler can use that.

We should somehow be able to pass the information with rasn structures, before automatic solver can work, which is the challenging part. For example,

SecuredCrl ::= Ieee1609Dot2Data (WITH COMPONENTS {..., 
  content (WITH COMPONENTS {
    signedData  (WITH COMPONENTS {..., 
      tbsData (WITH COMPONENTS {
        payload (WITH COMPONENTS {..., 
          data (WITH COMPONENTS {...,
             content (WITH COMPONENTS {
                unsecuredData (CONTAINING CrlContents)
            })
          })
        }),
        headerInfo (WITH COMPONENTS {..., 
          psid (CrlPsid),
          generationTime ABSENT,
          expiryTime ABSENT,
          generationLocation ABSENT,
          p2pcdLearningRequest ABSENT,
          missingCrlIdentifier ABSENT,
          encryptionKey ABSENT
        })
      })
    })
  })
})

Some of these types might come from external modules, and the presence of the fields of external types applies only for this specific newly created type. So the information is only valid on this type and it should be described in a way that solver can work with that, which seems a bit challenging, when also noting that the above syntax might not tell the exact type.

I don't consider it to be problematic, it's better to have be too big than too small IMO, especially initially. I'm not expecting these types to have a lot of churn on them since they are defined in a international standard. Most contributions will be improving quality of life of using them. Also if we change our minds, we can always split out parts of it into separate crates (e.g. "rasn-wave-1609" or "rasn-wave-messages").

What if we create then a single its crate for now? Splitting wave and its would still need three crates, because IEEE 1609.2 depends on ETSI TS 103097 and vice versa, for some parts. Future split could be its and its-security, if we already don't do that.
Maybe one big crate is less a problem if we limit the bundling with features.

[XAMPPRocky]

We can do one ITS crate. We could do features but we don't have to do them right now.