Crate geonetworking

Expand description

`geonetworking`

Rust tools for encoding and decoding GeoNetworking packets according to EN 302 636-4-1 v1.3.1 Supports #[no_std].

Usage

The geonetworking library decodes and encodes GeoNetworking packets according to EN 302 636-4-1 v1.3.1

Add geonetworking = { git = "https://github.com/consider-it/V2X-Geonetworking" } to the [dependencies] section of your project’s Cargo.toml manifest. The default features include data validation functionalities and JSON serialization with serde. If you do not wish to include JSON functionalities in your build, declare the dependency as follows: geonetworking = { git = "https://github.com/consider-it/V2X-Geonetworking", default-features = false }. The "validation" features requires the standard library as well as an openssl installation of major version 3.

Decoding

geonetworking provides a Decode trait that is implemented by the GeoNetworking Packet (containing all headers and payload), the subheaders BasicHeader CommonHeader Ieee1609Dot2Data (a.k.a. Secured Header) as well as the extended headers:

GeoUnicast
TopologicallyScopedBroadcast
SingleHopBroadcast
GeoBroadcast
GeoAnycast
Beacon
LSRequest
LSReply The trait’s decode method returns a Result-wrapped Decoded struct, which contains the decoded data and the number of consumed bytes.

use geonetworking::*;

// GeoNetworking Header with security and a payload of BTP-B and CAM
let data: &'static [u8] = &[
        0x12, 0x00, 0x05, 0x01, 0x03, 0x81, 0x00, 0x40, 0x03, 0x80, 0x5f, 0x20, 0x50, 0x02, 0x80, 0x00, 0x3b, 0x01, 0x00, 0x14, 0x00, 0x1e, 0x0d, 0xdf, 0x3f, 0x5b, 0x7d, 0xa0, 0xcd, 0xf2, 0x54, 0x1c, 0x81, 0x28, 0xaf, 0x07, 0xc5, 0xdd, 0xa5, 0x80, 0x04, 0x09, 0xf6, 0x00, 0x00, 0x00, 0x00, 0x07, 0xd1, 0x00, 0x00, 0x02, 0x02, 0xdf, 0x3f, 0x5b, 0x7d, 0xf2, 0x54, 0x40, 0x5a, 0x44, 0xc2, 0x35, 0xee, 0x61, 0xf5, 0xf4, 0xa2, 0x06, 0x20, 0x60, 0x00, 0x47, 0xbe, 0x50, 0x48, 0x9f, 0x7f, 0xa0, 0x02, 0x1c, 0xbf, 0xe9, 0xea, 0x83, 0x33, 0xff, 0x01, 0xff, 0xfa, 0x00, 0x28, 0x33, 0x00, 0x00, 0x1b, 0xfb, 0xc2, 0xff, 0x94, 0x36, 0x60, 0x7f, 0xff, 0x00, 0xc0, 0x01, 0x24, 0x00, 0x02, 0x34, 0xf4, 0x24, 0x7b, 0xf3, 0x0c, 0x02, 0x05, 0x80, 0x05, 0x01, 0x01, 0x7c, 0xe7, 0xf9, 0x81, 0x01, 0x01, 0x80, 0x03, 0x00, 0x80, 0x5d, 0x5d, 0xcb, 0xee, 0xfb, 0xe7, 0xd2, 0x2d, 0x30, 0x83, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0xbd, 0x2d, 0x05, 0x86, 0x00, 0x01, 0xe0, 0x01, 0x07, 0x80, 0x01, 0x24, 0x81, 0x04, 0x03, 0x01, 0xff, 0xfc, 0x80, 0x01, 0x25, 0x81, 0x05, 0x04, 0x01, 0xff, 0xff, 0xff, 0x80, 0x01, 0x8c, 0x81, 0x05, 0x04, 0x02, 0xff, 0xff, 0xe0, 0x00, 0x01, 0x8d, 0x80, 0x02, 0x02, 0x7e, 0x81, 0x02, 0x01, 0x01, 0x80, 0x02, 0x02, 0x7f, 0x81, 0x02, 0x01, 0x01, 0x00, 0x02, 0x03, 0xff, 0x80, 0x80, 0x82, 0xde, 0xa0, 0x8e, 0xa8, 0xe8, 0x3e, 0x46, 0x24, 0x4a, 0x8f, 0x98, 0xa1, 0xdf, 0x15, 0x1e, 0x93, 0x8d, 0x26, 0x39, 0xac, 0xda, 0xa4, 0x10, 0x80, 0x48, 0x80, 0xaa, 0x36, 0x2e, 0x85, 0x5d, 0xad, 0x81, 0x83, 0x5b, 0xd8, 0x00, 0xfc, 0xe3, 0x7f, 0x70, 0x70, 0xdf, 0xf5, 0x90, 0x27, 0xa3, 0x9d, 0x19, 0xae, 0x8d, 0xe9, 0x60, 0x76, 0x12, 0xcb, 0xb2, 0x30, 0x9a, 0xf5, 0xfe, 0x89, 0x43, 0x30, 0x08, 0x02, 0x8e, 0x29, 0x4f, 0xf7, 0xef, 0xae, 0xca, 0xbf, 0x82, 0x4c, 0xab, 0x93, 0x27, 0x04, 0xcb, 0x98, 0x20, 0x80, 0xf3, 0x42, 0x90, 0x0c, 0x1f, 0xda, 0x11, 0xf6, 0xda, 0x43, 0x40, 0x05, 0xed, 0x85, 0x80, 0x82, 0x36, 0x99, 0x42, 0xdc, 0x48, 0x8d, 0xe7, 0x2f, 0x81, 0xeb, 0x82, 0x3b, 0xf9, 0x3d, 0xbd, 0xa1, 0xad, 0xb6, 0x37, 0x4b, 0xcd, 0x3d, 0x41, 0x69, 0x07, 0x33, 0x50, 0xc2, 0x6b, 0x72, 0x8b, 0xbe, 0x37, 0x47, 0x18, 0x35, 0x4a, 0x6f, 0xf6, 0xc1, 0x93, 0x6b, 0x25, 0x59, 0x94, 0xb9, 0x13, 0x49, 0xd2, 0x47, 0x5f, 0x73, 0x61, 0x97, 0x8b, 0xd7, 0x93, 0x21, 0x57, 0x37, 0x53, 0xc1, 0x4d, 0x36, 
    ];
let result = Packet::decode(data).unwrap();
println!("Consumed {} bytes and decoded GeoNetworking packet {:?}", result.bytes_consumed, result.decoded);

Encoding a GeoNetworking Header

The crate’s Encode trait provides two (three with the json feature enabled) methods for encoding items: decode takes an Encoder as input and can be used for concatenating multiple items in one encoding. For encoding a single item decode_to_vec provides a shorthand that returns immediately the bytes of the encoding. Currently, only non-secured packets can be encoded.

use geonetworking::*;

let packet = Packet::Unsecured {
    basic: BasicHeader {
        version: 1,
        next_header: NextAfterBasic::CommonHeader,
        // The bits! macro accepts a comma-separated list of 1s and 0s (see below)
        // or a value (1 or 0) and a length value (usize), separated by a semicolon
        reserved: bits![0; 8],
        lifetime: Lifetime(80),
        remaining_hop_limit: 1,
    },
    common: CommonHeader {
        next_header: NextAfterCommon::BTPB,
        reserved_1: bits![0, 0, 0, 0],
        header_type_and_subtype: HeaderType::TopologicallyScopedBroadcast(
            BroadcastType::SingleHop,
        ),
        traffic_class: TrafficClass {
            store_carry_forward: false,
            channel_offload: false,
            traffic_class_id: 2,
        },
        flags: bits![0, 0, 0, 0, 0, 0, 0, 0],
        payload_length: 1,
        maximum_hop_limit: 1,
        reserved_2: bits![0, 0, 0, 0, 0, 0, 0, 0],
    },
    extended: Some(ExtendedHeader::SHB(SingleHopBroadcast {
        source_position_vector: LongPositionVector {
            gn_address: Address {
                manually_configured: false,
                station_type: StationType::Unknown,
                reserved: bits![0, 1, 0, 0, 0, 0, 0, 1, 1, 0],
                address: [0, 96, 224, 105, 87, 141],
            },
            timestamp: Timestamp(542947520),
            latitude: 535574568,
            longitude: 99765648,
            position_accuracy: false,
            speed: 680,
            heading: 2122,
        },
        media_dependent_data: [127, 0, 184, 0],
    })),
    payload: &[42]
};

/// Encode using an encoder
let mut encoder = Encoder::new();
packet.encode(&mut encoder).unwrap();

let output: Vec<u8> = encoder.into();

/// Encode and return bytes
let bytes = packet.encode_to_vec().unwrap();

assert_eq!(output, bytes);

Validating a Packet

For packet validation to be available, the "validate" feature must be enabled. The Validate trait exposes a validate method that checks whether the implementing type is valid. validate runs the following checks:

The signature of a secured packet matches the certificate contained in the IEEE 1609.2 header
WIP The packet conforms to IEEE 1609.2 2016
WIP The packet conforms to ETSI TS 103 097 V2.1.1

`validate` returns

Ok(ValidationResult::Success) if all checks passed successful
Ok(ValidationResult::Failure { reason: String }) if a check failed
Ok(ValidationResult::NotApplicable { info: &'static str }) if no validation checks were run
Err(ValidationError) if an internal error occured during validation

use geonetworking::*;

// GeoNetworking Header with security and a payload of BTP-B and CAM
let data: &'static [u8] = &[
        0x12, 0x00, 0x05, 0x01, 0x03, 0x81, 0x00, 0x40, 0x03, 0x80, 0x81, 0xbd, 0x20, 0x50, 0x02, 0x80, 0x00, 0x99, 0x01, 0x00, 0x14, 0x00, 0xca, 0xb0, 0xa5, 0x28, 0x3d, 0x0a, 0x2c, 0xd5, 0x54, 0xcf, 0x1c, 0x7f, 0x37, 0xa3, 0x07, 0xc6, 0xb6, 0x44, 0x82, 0xcc, 0x0b, 0xbf, 0x00, 0x00, 0x00, 0x00, 0x07, 0xd1, 0x00, 0x00, 0x02, 0x02, 0xa5, 0x28, 0x3d, 0x0a, 0x54, 0xcf, 0x40, 0x5a, 0x44, 0x84, 0x14, 0x6e, 0x62, 0x11, 0x08, 0x80, 0xb8, 0x0b, 0x80, 0x00, 0x47, 0xa7, 0xce, 0x48, 0xbb, 0xf1, 0x01, 0x54, 0x08, 0x82, 0x98, 0x8a, 0x8f, 0x34, 0x12, 0x62, 0x01, 0x0a, 0x00, 0x28, 0x73, 0x00, 0x00, 0xcb, 0xff, 0x7d, 0x00, 0x54, 0x31, 0x92, 0x00, 0x09, 0xdf, 0xbf, 0xd8, 0x26, 0x75, 0x8f, 0x10, 0x07, 0x7f, 0x00, 0x1d, 0x40, 0x10, 0x4c, 0x69, 0x80, 0x95, 0xf7, 0xf5, 0xc6, 0x06, 0x5c, 0x64, 0x14, 0x06, 0x2b, 0xbf, 0x80, 0x70, 0x4b, 0x3b, 0x1e, 0xc0, 0x08, 0x1d, 0xfb, 0xf6, 0x82, 0x70, 0x98, 0xf1, 0x00, 0x31, 0xef, 0xe0, 0x1c, 0x13, 0x6c, 0xc7, 0x88, 0x01, 0x67, 0x7e, 0xfd, 0x60, 0x9e, 0x86, 0x3b, 0x00, 0x0b, 0x3b, 0xf8, 0xcb, 0x04, 0x7e, 0xb1, 0xc4, 0x00, 0x4f, 0xdf, 0xc5, 0xa8, 0x23, 0xdd, 0x8e, 0x20, 0x02, 0x7e, 0xfe, 0x2c, 0x41, 0x1c, 0xec, 0x67, 0x00, 0x13, 0xf7, 0xef, 0xa6, 0x09, 0xce, 0x63, 0x60, 0x00, 0xb3, 0x40, 0x01, 0x24, 0x00, 0x02, 0x3a, 0xff, 0x21, 0x55, 0xe9, 0x67, 0x81, 0x01, 0x01, 0x80, 0x03, 0x00, 0x80, 0x5d, 0x5d, 0xcb, 0xee, 0xfb, 0xe7, 0xd2, 0x2d, 0x30, 0x83, 0x00, 0x00, 0x00, 0x00, 0x00, 0x25, 0x47, 0x9a, 0x85, 0x86, 0x00, 0x01, 0xe0, 0x01, 0x07, 0x80, 0x01, 0x24, 0x81, 0x04, 0x03, 0x01, 0xff, 0xfc, 0x80, 0x01, 0x25, 0x81, 0x05, 0x04, 0x01, 0xff, 0xff, 0xff, 0x80, 0x01, 0x8c, 0x81, 0x05, 0x04, 0x02, 0xff, 0xff, 0xe0, 0x00, 0x01, 0x8d, 0x80, 0x02, 0x02, 0x7e, 0x81, 0x02, 0x01, 0x01, 0x80, 0x02, 0x02, 0x7f, 0x81, 0x02, 0x01, 0x01, 0x00, 0x02, 0x03, 0xff, 0x80, 0x80, 0x83, 0x84, 0x16, 0x11, 0x01, 0xf5, 0x8b, 0x0a, 0x44, 0x8d, 0xb0, 0x60, 0x45, 0x96, 0x21, 0xec, 0x8b, 0xaf, 0xf0, 0xb2, 0x35, 0xd3, 0x5d, 0xc5, 0xe0, 0xd9, 0x7b, 0x3e, 0xee, 0x12, 0xc1, 0x5e, 0xe7, 0x81, 0x80, 0x9c, 0x28, 0x35, 0xd1, 0xd5, 0x7e, 0x28, 0x92, 0xd9, 0xb8, 0x66, 0x75, 0xd8, 0x0a, 0x4b, 0x75, 0x7c, 0x55, 0x49, 0x8f, 0x58, 0x41, 0xf0, 0xc5, 0xca, 0xe7, 0x7a, 0x4d, 0xd4, 0xc3, 0x4a, 0x74, 0x7c, 0x0a, 0x34, 0xd8, 0x2b, 0x5f, 0x28, 0x35, 0xde, 0xc9, 0x9e, 0x39, 0x45, 0x59, 0xde, 0x3d, 0x5e, 0x40, 0x43, 0x0a, 0x5c, 0x7a, 0x7e, 0x6e, 0x26, 0x06, 0x36, 0x9b, 0x6a, 0x96, 0xb1, 0x2c, 0x80, 0x83, 0xf6, 0xd4, 0x0f, 0x37, 0x94, 0xf1, 0x02, 0xf3, 0x37, 0xe2, 0xa8, 0xb7, 0x2a, 0x82, 0xf9, 0xca, 0xe8, 0xf6, 0x7f, 0x9f, 0x32, 0xf4, 0xe4, 0x61, 0x22, 0x43, 0x95, 0x6a, 0xab, 0x81, 0x6b, 0x92, 0x71, 0x39, 0x11, 0xd7, 0xb6, 0xe2, 0x93, 0x6f, 0xc4, 0xef, 0x79, 0x2e, 0x41, 0x55, 0x02, 0x58, 0x0f, 0x4e, 0xf5, 0xca, 0x4c, 0x12, 0x6d, 0xd9, 0x76, 0x7f, 0xab, 0x9c, 0x87, 0xd7, 0x36, 0xa5,
    ];
let packet = Packet::decode(data).unwrap().decoded;
assert_eq!(packet.validate(), Ok(ValidationResult::Success));

Macros

bits

Structs

Address
AnonymousContributedExtensionBlockExtns
Anonymous SEQUENCE OF member
AppExtension
@brief This structure contains an individual AppExtension. AppExtensions specified in this standard are drawn from the ASN.1 Information Object Set SetCertExtensions. This set, and its use in the AppExtension type, is structured so that each AppExtension is associated with a CertIssueExtension and a CertRequestExtension and all are identified by the same id value. In this structure: @param id: identifies the extension type. @param content: provides the content of the extension.
BasicHeader
Beacon
BitmapSsp
@brief This structure represents a bitmap representation of a SSP. The mapping of the bits of the bitmap to constraints on the signed SPDU is PSID-specific. @note Consistency with issuing certificate: If a certificate has an appPermissions entry A for which the ssp field is bitmapSsp, A is consistent with the issuing certificate if the certificate contains one of the following:
BitmapSspRange
@brief This structure represents a bitmap representation of a SSP. The sspValue indicates permissions. The sspBitmask contains an octet string used to permit or constrain sspValue fields in issued certificates. The sspValue and sspBitmask fields shall be of the same length. @note Consistency with issuing certificate: If a certificate has an PsidSspRange value P for which the sspRange field is bitmapSspRange, P is consistent with the issuing certificate if the issuing certificate contains one of the following:
Bits
CertIssueExtension
@brief This field contains an individual CertIssueExtension. CertIssueExtensions specified in this standard are drawn from the ASN.1 Information Object Set SetCertExtensions. This set, and its use in the CertIssueExtension type, is structured so that each CertIssueExtension is associated with a AppExtension and a CertRequestExtension and all are identified by the same id value. In this structure: @param id: identifies the extension type. @param permissions: indicates the permissions. Within this field.
CertRequestExtension
@brief This field contains an individual CertRequestExtension. CertRequestExtensions specified in this standard are drawn from the ASN.1 Information Object Set SetCertExtensions. This set, and its use in the CertRequestExtension type, is structured so that each CertRequestExtension is associated with a AppExtension and a CertRequestExtension and all are identified by the same id value. In this structure: @param id: identifies the extension type. @param permissions: indicates the permissions. Within this field.
CertificateBase
@brief The fields in this structure have the following meaning: @param version: contains the version of the certificate format. In this version of the data structures, this field is set to 3. @param type: states whether the certificate is implicit or explicit. This field is set to explicit for explicit certificates and to implicit for implicit certificates. See ExplicitCertificate and ImplicitCertificate for more details. @param issuer: identifies the issuer of the certificate. @param toBeSigned: is the certificate contents. This field is an input to the hash when generating or verifying signatures for an explicit certificate, or generating or verifying the public key from the reconstruction value for an implicit certificate. The details of how this field are encoded are given in the description of the ToBeSignedCertificate type. @param signature: is included in an ExplicitCertificate. It is the signature, calculated by the signer identified in the issuer field, over the hash of toBeSigned. The hash is calculated as specified in 5.3.1, where:
CircularRegion
@brief This structure specifies a circle with its center at center, its radius given in meters, and located tangential to the reference ellipsoid. The indicated region is all the points on the surface of the reference ellipsoid whose distance to the center point over the reference ellipsoid is less than or equal to the radius. A point which contains an elevation component is considered to be within the circular region if its horizontal projection onto the reference ellipsoid lies within the region.
CommonHeader
ContributedExtensionBlock
@brief This data structure defines the format of an extension block provided by an identified contributor by using the temnplate provided in the class IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION constraint to the objects in the set Ieee1609Dot2HeaderInfoContributedExtensions. @param contributorId: uniquely identifies the contributor. @param extns: contains a list of extensions from that contributor. Extensions are expected and not required to follow the format specified in 6.5.
ContributedExtensionBlockExtns
Inner type With at least one member
ContributedExtensionBlocks
@brief This type is used for clarity of definitions. At least one member
CountryAndRegions
@brief A conformant implementation that supports CountryAndRegions shall support a regions field containing at least eight entries. A conformant implementation that implements this type shall recognize (in the sense of “be able to determine whether a two dimensional location lies inside or outside the borders identified by”) at least one value of UnCountryId and at least one value for a region within the country indicated by that recognized UnCountryId value. In this version of this standard, the only means to satisfy this is for a conformant implementation to recognize the value of UnCountryId indicating USA and at least one of the FIPS state codes for US states. The Protocol Implementation Conformance Statement (PICS) provided in Annex A allows an implementation to state which UnCountryId values it recognizes and which region values are recognized within that country. If a verifying implementation is required to check that an relevant geographic information in a signed SPDU is consistent with a certificate containing one or more instances of this type, then the SDS is permitted to indicate that the signed SPDU is valid even if some values of country or within regions are unrecognized in the sense defined above, so long as the recognized instances of this type completely contain the relevant geographic information. Informally, if the recognized values in the certificate allow the SDS to determine that the SPDU is valid, then it can make that determination even if there are also unrecognized values in the certificate. This field is therefore not a “critical information field” as defined in 5.2.6, because unrecognized values are permitted so long as the validity of the SPDU can be established with the recognized values. However, as discussed in 5.2.6, the presence of an unrecognized value in a certificate can make it impossible to determine whether the certificate is valid and so whether the SPDU is valid. In this type: @param countryOnly: is a UnCountryId as defined above. @param regions: identifies one or more regions within the country. If country indicates the United States of America, the values in this field identify the state or statistically equivalent entity using the integer version of the 2010 FIPS codes as provided by the U.S. Census Bureau (see normative references in Clause 0). For other values of country, the meaning of region is not defined in this version of this standard.
CountryAndSubregions
@brief A conformant implementation that supports CountryAndSubregions shall support a regionAndSubregions field containing at least eight entries. A conformant implementation that implements this type shall recognize (in the sense of be able to determine whether a two dimensional location lies inside or outside the borders identified by) at least one value of country and at least one value for a region within the country indicated by that recognized country value. In this version of this standard, the only means to satisfy this is for a conformant implementation to recognize the value of UnCountryId indicating USA and at least one of the FIPS state codes for US states. The Protocol Implementation Conformance Statement (PICS) provided in Annex A allows an implementation to state which UnCountryId values it recognizes and which region values are recognized within that country. If a verifying implementation is required to check that an relevant geographic information in a signed SPDU is consistent with a certificate containing one or more instances of this type, then the SDS is permitted to indicate that the signed SPDU is valid even if some values of country or within regionAndSubregions are unrecognized in the sense defined above, so long as the recognized instances of this type completely contain the relevant geographic information. Informally, if the recognized values in the certificate allow the SDS to determine that the SPDU is valid, then it can make that determination even if there are also unrecognized values in the certificate. This field is therefore not a “critical information field” as defined in 5.2.6, because unrecognized values are permitted so long as the validity of the SPDU can be established with the recognized values. However, as discussed in 5.2.6, the presence of an unrecognized value in a certificate can make it impossible to determine whether the certificate is valid and so whether the SPDU is valid. In this structure: @param countryOnly: is a UnCountryId as defined above. @param regionAndSubregions: identifies one or more subregions within country.
Decoded
Returns the value of a decoding attempt
EccP256CurvePointUncompressedP256
Inner type
EccP384CurvePointUncompressedP384
Inner type
EcdsaP256Signature
@brief This structure represents an ECDSA signature. The signature is generated as specified in 5.3.1. If the signature process followed the specification of FIPS 186-4 and output the integer r, r is represented as an EccP256CurvePoint indicating the selection x-only. If the signature process followed the specification of SEC 1 and output the elliptic curve point R to allow for fast verification, R is represented as an EccP256CurvePoint indicating the choice compressed-y-0, compressed-y-1, or uncompressed at the sender’s discretion. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2. When this data structure is canonicalized, the EccP256CurvePoint in rSig is represented in the form x-only. @note When the signature is of form x-only, the x-value in rSig is an integer mod n, the order of the group; when the signature is of form compressed-y-*, the x-value in rSig is an integer mod p, the underlying prime defining the finite field. In principle this means that to convert a signature from form compressed-y-* to form x-only, the converter checks the x-value to see if it lies between n and p and reduces it mod n if so. In practice this check is unnecessary: Haase’s Theorem states that difference between n and p is always less than 2*square-root(p), and so the chance that an integer lies between n and p, for a 256-bit curve, is bounded above by approximately square-root(p)/p or 2^(-128). For the 256-bit curves in this standard, the exact values of n and p in hexadecimal are: NISTp256:
EcdsaP384Signature
@brief This structure represents an ECDSA signature. The signature is generated as specified in 5.3.1. If the signature process followed the specification of FIPS 186-4 and output the integer r, r is represented as an EccP384CurvePoint indicating the selection x-only. If the signature process followed the specification of SEC 1 and output the elliptic curve point R to allow for fast verification, R is represented as an EccP384CurvePoint indicating the choice compressed-y-0, compressed-y-1, or uncompressed at the sender’s discretion. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2. When this data structure is canonicalized, the EccP384CurvePoint in rSig is represented in the form x-only. @note When the signature is of form x-only, the x-value in rSig is an integer mod n, the order of the group; when the signature is of form compressed-y-*, the x-value in rSig is an integer mod p, the underlying prime defining the finite field. In principle this means that to convert a signature from form compressed-y-* to form x-only, the converter checks the x-value to see if it lies between n and p and reduces it mod n if so. In practice this check is unnecessary: Haase’s Theorem states that difference between n and p is always less than 2*square-root(p), and so the chance that an integer lies between n and p, for a 384-bit curve, is bounded above by approximately square-root(p)/p or 2^(-192). For the 384-bit curve in this standard, the exact values of n and p in hexadecimal are:
EcencP256EncryptedKey
@brief This data structure is used to transfer a 16-byte symmetric key encrypted using SM2 encryption as specified in 5.3.3. The symmetric key is input to the key encryption process with no headers, encapsulation, or length indication. Encryption and decryption are carried out as specified in 5.3.5.2. @param v: is the sender’s ephemeral public key, which is the output V from encryption as specified in 5.3.5.2. @param c: is the encrypted symmetric key, which is the output C from encryption as specified in 5.3.5.2. The algorithm for the symmetric key is identified by the CHOICE indicated in the following SymmetricCiphertext. For SM2 this algorithm shall be SM4. @param t: is the authentication tag, which is the output tag from encryption as specified in 5.3.5.2.
EciesP256EncryptedKey
@brief This data structure is used to transfer a 16-byte symmetric key encrypted using ECIES as specified in IEEE Std 1363a-2004. The symmetric key is input to the key encryption process with no headers, encapsulation, or length indication. Encryption and decryption are carried out as specified in 5.3.5.1. @param v: is the sender’s ephemeral public key, which is the output V from encryption as specified in 5.3.5.1. @param c: is the encrypted symmetric key, which is the output C from encryption as specified in 5.3.5.1. The algorithm for the symmetric key is identified by the CHOICE indicated in the following SymmetricCiphertext. For ECIES this shall be AES-128. @param t: is the authentication tag, which is the output tag from encryption as specified in 5.3.5.1.
EcsigP256Signature
@brief This structure represents a elliptic curve signature where the component r is constrained to be an integer. This structure supports SM2 signatures as specified in 5.3.1.3.
Encoder
EncryptedData
EndEntityType
@brief This type indicates which type of permissions may appear in end-entity certificates the chain of whose permissions passes through the PsidGroupPermissions field containing this value. If app is indicated, the end-entity certificate may contain an appPermissions field. If enroll is indicated, the end-entity certificate may contain a certRequestPermissions field.
ExtId
@brief This type is used as an identifier for instances of ExtContent within an EXT-TYPE.
Extension
@brief This parameterized type represents a (id, content) pair drawn from the set ExtensionTypes, which is constrained to contain objects defined by the class EXT-TYPE.
GeoAnycast
In case of a circular area (GeoNetworking packet sub-type HST = 0), the fields shall be set to the following values:
GeoUnicast
GroupLinkageValue
@brief This is the group linkage value. See 5.1.3 and 7.3 for details of use.
HashedId3
@brief This type contains the truncated hash of another data structure. The HashedId3 for a given data structure is calculated by calculating the hash of the encoded data structure and taking the low-order three bytes of the hash output. The low-order three bytes are the last three bytes of the 32-byte hash when represented in network byte order. If the data structure is subject to canonicalization it is canonicalized before hashing. See Example below. The hash algorithm to be used to calculate a HashedId3 within a structure depends on the context. In this standard, for each structure that includes a HashedId3 field, the corresponding text indicates how the hash algorithm is determined. See also the discussion in 5.3.9. Example: Consider the SHA-256 hash of the empty string: SHA-256(“”) = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 The HashedId3 derived from this hash corresponds to the following: HashedId3 = 52b855.
HashedId8
@brief This type contains the truncated hash of another data structure. The HashedId8 for a given data structure is calculated by calculating the hash of the encoded data structure and taking the low-order eight bytes of the hash output. The low-order eight bytes are the last eight bytes of the hash when represented in network byte order. If the data structure is subject to canonicalization it is canonicalized before hashing. See Example below. The hash algorithm to be used to calculate a HashedId8 within a structure depends on the context. In this standard, for each structure that includes a HashedId8 field, the corresponding text indicates how the hash algorithm is determined. See also the discussion in 5.3.9. Example: Consider the SHA-256 hash of the empty string: SHA-256(“”) = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 The HashedId8 derived from this hash corresponds to the following: HashedId8 = a495991b7852b855.
HashedId10
@brief This type contains the truncated hash of another data structure. The HashedId10 for a given data structure is calculated by calculating the hash of the encoded data structure and taking the low-order ten bytes of the hash output. The low-order ten bytes are the last ten bytes of the hash when represented in network byte order. If the data structure is subject to canonicalization it is canonicalized before hashing. See Example below. The hash algorithm to be used to calculate a HashedId10 within a structure depends on the context. In this standard, for each structure that includes a HashedId10 field, the corresponding text indicates how the hash algorithm is determined. See also the discussion in 5.3.9. Example: Consider the SHA-256 hash of the empty string: SHA-256(“”) = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 The HashedId10 derived from this hash corresponds to the following: HashedId10 = 934ca495991b7852b855.
HashedId32
@brief This data structure contains the truncated hash of another data structure. The HashedId32 for a given data structure is calculated by calculating the hash of the encoded data structure and taking the low-order 32 bytes of the hash output. The low-order 32 bytes are the last 32 bytes of the hash when represented in network byte order. If the data structure is subject to canonicalization it is canonicalized before hashing. See Example below. The hash algorithm to be used to calculate a HashedId32 within a structure depends on the context. In this standard, for each structure that includes a HashedId32 field, the corresponding text indicates how the hash algorithm is determined. See also the discussion in 5.3.9. Example: Consider the SHA-256 hash of the empty string: SHA-256(“”) = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 The HashedId32 derived from this hash corresponds to the following: HashedId32 = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b8 55.
HashedId48
@brief This data structure contains the truncated hash of another data structure. The HashedId48 for a given data structure is calculated by calculating the hash of the encoded data structure and taking the low-order 48 bytes of the hash output. The low-order 48 bytes are the last 48 bytes of the hash when represented in network byte order. If the data structure is subject to canonicalization it is canonicalized before hashing. See Example below. The hash algorithm to be used to calculate a HashedId48 within a structure depends on the context. In this standard, for each structure that includes a HashedId48 field, the corresponding text indicates how the hash algorithm is determined. See also the discussion in 5.3.9. Example: Consider the SHA-384 hash of the empty string: SHA-384(“”) = 38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6 e1da274edebfe76f65fbd51ad2f14898b95b The HashedId48 derived from this hash corresponds to the following: HashedId48 = 38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e 1da274edebfe76f65fbd51ad2f14898b95b.
HeaderInfo
@brief This structure contains information that is used to establish validity by the criteria of 5.2. @param psid: indicates the application area with which the sender is claiming the payload is to be associated. @param generationTime: indicates the time at which the structure was generated. See 5.2.5.2.2 and 5.2.5.2.3 for discussion of the use of this field. @param expiryTime: if present, contains the time after which the data is no longer considered relevant. If both generationTime and expiryTime are present, the signed SPDU is invalid if generationTime is not strictly earlier than expiryTime. @param generationLocation: if present, contains the location at which the signature was generated. @param p2pcdLearningRequest: if present, is used by the SDS to request certificates for which it has seen identifiers and does not know the entire certificate. A specification of this peer-to-peer certificate distribution (P2PCD) mechanism is given in Clause 8. This field is used for the separate-certificate-pdu flavor of P2PCD and shall only be present if inlineP2pcdRequest is not present. The HashedId3 is calculated with the whole-certificate hash algorithm, determined as described in 6.4.3, applied to the COER-encoded certificate, canonicalized as defined in the definition of Certificate. @param missingCrlIdentifier: if present, is used by the SDS to request CRLs which it knows to have been issued and have not received. This is provided for future use and the associated mechanism is not defined in this version of this standard. @param encryptionKey: if present, is used to provide a key that is to be used to encrypt at least one response to this SPDU. The SDEE specification is expected to specify which response SPDUs are to be encrypted with this key. One possible use of this key to encrypt a response is specified in 6.3.35, 6.3.37, and 6.3.34. An encryptionKey field of type symmetric should only be used if the SignedData containing this field is securely encrypted by some means. @param inlineP2pcdRequest: if present, is used by the SDS to request unknown certificates per the inline peer-to-peer certificate distribution mechanism is given in Clause 8. This field shall only be present if p2pcdLearningRequest is not present. The HashedId3 is calculated with the whole-certificate hash algorithm, determined as described in 6.4.3, applied to the COER-encoded certificate, canonicalized as defined in the definition of Certificate. @param requestedCertificate: if present, is used by the SDS to provide certificates per the “inline” version of the peer-to-peer certificate distribution mechanism given in Clause 8. @param pduFunctionalType: if present, is used to indicate that the SPDU is to be consumed by a process other than an application process as defined in ISO 21177 [B14a]. See 6.3.23b for more details. @param contributedExtensions: if present, is used to contain additional extensions defined using the ContributedExtensionBlocks structure. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2. The canonicalization applies to the EncryptionKey. If encryptionKey is present, and indicates the choice public, and contains a BasePublicEncryptionKey that is an elliptic curve point (i.e., of type EccP256CurvePoint or EccP384CurvePoint), then the elliptic curve point is encoded in compressed form, i.e., such that the choice indicated within the Ecc*CurvePoint is compressed-y-0 or compressed-y-1. The canonicalization does not apply to any fields after the extension marker, including any fields in contributedExtensions.
HeaderInfoContributorId
@brief This is an integer used to identify a HeaderInfo extension contributing organization. In this version of this standard two values are defined:
Hostname
@brief This is a UTF-8 string as defined in IETF RFC 3629. The contents are determined by policy.
Ieee1609Dot2Data
KnownLatitude
@brief The known latitudes are from -900,000,000 to +900,000,000 in 0.1 microdegree intervals.
KnownLongitude
@brief The known longitudes are from -1,799,999,999 to +1,800,000,000 in 0.1 microdegree intervals.
LSReply
LSRequest
LaId
@brief This structure contains a LA Identifier for use in the algorithms specified in 5.1.3.4.
Lifetime
Lifetime field. Indicates the maximum tolerable time a packet may be buffered until it reaches its destination Bit 0 to Bit 5: LT sub-field Multiplier Bit 6 to Bit 7: LT sub-field Base
LinkageData
@brief This structure contains information that is matched against information obtained from a linkage ID-based CRL to determine whether the containing certificate has been revoked. See 5.1.3.4 and 7.3 for details of use.
LinkageSeed
@brief This structure contains a linkage seed value for use in the algorithms specified in 5.1.3.4.
LinkageValue
@brief This is the individual linkage value. See 5.1.3 and 7.3 for details of use.
LongPositionVector
MissingCrlIdentifier
@brief This structure may be used to request a CRL that the SSME knows to have been issued and has not yet received. It is provided for future use and its use is not defined in this version of this standard. @param cracaId: is the HashedId3 of the CRACA, as defined in 5.1.3. The HashedId3 is calculated with the whole-certificate hash algorithm, determined as described in 6.4.3, applied to the COER-encoded certificate, canonicalized as defined in the definition of Certificate. @param crlSeries: is the requested CRL Series value. See 5.1.3 for more information.
NinetyDegreeInt
@brief The integer in the latitude field is no more than 900,000,000 and no less than -900,000,000, except that the value 900,000,001 is used to indicate the latitude was not available to the sender.
One28BitCcmCiphertext
@brief This data structure encapsulates an encrypted ciphertext for any symmetric algorithm with 128-bit blocks in CCM mode. The ciphertext is 16 bytes longer than the corresponding plaintext due to the inclusion of the message authentication code (MAC). The plaintext resulting from a correct decryption of the ciphertext is either a COER-encoded Ieee1609Dot2Data structure (see 6.3.41), or a 16-byte symmetric key (see 6.3.44). The ciphertext is 16 bytes longer than the corresponding plaintext. The plaintext resulting from a correct decryption of the ciphertext is a COER-encoded Ieee1609Dot2Data structure. @param nonce: contains the nonce N as specified in 5.3.8. @param ccmCiphertext: contains the ciphertext C as specified in 5.3.8. @note In the name of this structure, “One28” indicates that the symmetric cipher block size is 128 bits. It happens to also be the case that the keys used for both AES-128-CCM and SM4-CCM are also 128 bits long. This is, however, not what One28 refers to. Since the cipher is used in counter mode, i.e., as a stream cipher, the fact that that block size is 128 bits affects only the size of the MAC and does not affect the size of the raw ciphertext.
OneEightyDegreeInt
@brief The integer in the longitude field is no more than 1,800,000,000 and no less than -1,799,999,999, except that the value 1,800,000,001 is used to indicate that the longitude was not available to the sender.
Opaque
OperatingOrganizationId
@brief This type is the AppExtension used to identify an operating organization. The associated CertIssueExtension and CertRequestExtension are both of type OperatingOrganizationId. To determine consistency between this type and an SPDU, the SDEE specification for that SPDU is required to specify how the SPDU can be used to determine an OBJECT IDENTIFIER (for example, by including the full OBJECT IDENTIFIER in the SPDU, or by including a RELATIVE-OID with clear instructions about how a full OBJECT IDENTIFIER can be obtained from the RELATIVE-OID). The SPDU is then consistent with this type if the OBJECT IDENTIFIER determined from the SPDU is identical to the OBJECT IDENTIFIER contained in this field. This AppExtension does not have consistency conditions with a corresponding CertIssueExtension. It can appear in a certificate issued by any CA.
PKRecipientInfo
@brief This data structure contains the following fields: @param recipientId: contains the hash of the container for the encryption public key as specified in the definition of RecipientInfo. Specifically, depending on the choice indicated by the containing RecipientInfo structure:
PduFunctionalType
@brief This data structure identifies the functional entity that is intended to consume an SPDU, for the case where that functional entity is not an application process, and are instead security support services for an application process. Further details and the intended use of this field are defined in ISO 21177 [B20]. @param tlsHandshake: indicates that the Signed SPDU is not to be directly consumed as an application PDU and is to be used to provide information about the holders permissions to a Transport Layer Security (TLS) (IETF 5246 [B15], IETF 8446 [B16]) handshake process operating to secure communications to an application process. See IETF [B15] and ISO 21177 [B20] for further information. @param iso21177ExtendedAuth: indicates that the Signed SPDU is not to be directly consumed as an application PDU and is to be used to provide additional information about the holders permissions to the ISO 21177 Security Subsystem for an application process. See ISO 21177 [B20] for further information. @param iso21177SessionExtension: indicates that the Signed SPDU is not to be directly consumed as an application PDU and is to be used to extend an existing ISO 21177 secure session. This enables a secure session to persist beyond the lifetime of the certificates used to establish that session.
PolygonalRegion
@brief This structure defines a region using a series of distinct geographic points, defined on the surface of the reference ellipsoid. The region is specified by connecting the points in the order they appear, with each pair of points connected by the geodesic on the reference ellipsoid. The polygon is completed by connecting the final point to the first point. The allowed region is the interior of the polygon and its boundary. A point which contains an elevation component is considered to be within the polygonal region if its horizontal projection onto the reference ellipsoid lies within the region. A valid PolygonalRegion contains at least three points. In a valid PolygonalRegion, the implied lines that make up the sides of the polygon do not intersect. @note This type does not support enclaves / exclaves. This might be addressed in a future version of this standard. @note Critical information fields: If present, this is a critical information field as defined in 5.2.6. An implementation that does not support the number of TwoDLocation in the PolygonalRegion when verifying a signed SPDU shall indicate that the signed SPDU is invalid. A compliant implementation shall support PolygonalRegions containing at least eight TwoDLocation entries.
Psid
@brief This type represents the PSID defined in IEEE Std 1609.12.
PsidGroupPermissions
@brief This structure states the permissions that a certificate holder has with respect to issuing and requesting certificates for a particular set of PSIDs. For examples, see D.5.3 and D.5.4. @param subjectPermissions: indicates PSIDs and SSP Ranges covered by this field. @param minChainLength: and chainLengthRange indicate how long the certificate chain from this certificate to the end-entity certificate is permitted to be. As specified in 5.1.2.1, the length of the certificate chain is the number of certificates “below” this certificate in the chain, down to and including the end-entity certificate. The length is permitted to be (a) greater than or equal to minChainLength certificates and (b) less than or equal to minChainLength + chainLengthRange certificates. A value of 0 for minChainLength is not permitted when this type appears in the certIssuePermissions field of a ToBeSignedCertificate; a certificate that has a value of 0 for this field is invalid. The value -1 for chainLengthRange is a special case: if the value of chainLengthRange is -1 it indicates that the certificate chain may be any length equal to or greater than minChainLength. See the examples below for further discussion. @param eeType: takes one or more of the values app and enroll and indicates the type of certificates or requests that this instance of PsidGroupPermissions in the certificate is entitled to authorize. Different instances of PsidGroupPermissions within a ToBeSignedCertificate may have different values for eeType.
PsidSsp
PsidSspRange
@brief This structure represents the certificate issuing or requesting permissions of the certificate holder with respect to one particular set of application permissions. @param psid: identifies the application area. @param sspRange: identifies the SSPs associated with that PSID for which the holder may issue or request certificates. If sspRange is omitted, the holder may issue or request certificates for any SSP for that PSID.
PublicEncryptionKey
@brief This structure specifies a public encryption key and the associated symmetric algorithm which is used for bulk data encryption when encrypting for that public key. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2 if it appears in a HeaderInfo or in a ToBeSignedCertificate. The canonicalization applies to the BasePublicEncryptionKey. See the definitions of HeaderInfo and ToBeSignedCertificate for a specification of the canonicalization operations.
RectangularRegion
@brief This structure specifies a rectangle on the surface of the WGS84 ellipsoid where the sides are given by lines of constant latitude or longitude. A point which contains an elevation component is considered to be within the rectangular region if its horizontal projection onto the reference ellipsoid lies within the region. A RectangularRegion is invalid if the northWest value is south of the southEast value, or if the latitude values in the two points are equal, or if the longitude values in the two points are equal; otherwise it is valid. A certificate that contains an invalid RectangularRegion is invalid. @param northWest: is the north-west corner of the rectangle. @param southEast is the south-east corner of the rectangle.
RegionAndSubregions
@brief The meanings of the fields in this structure are to be interpreted in the context of a country within which the region is located, referred to as the “enclosing country”. If this structure is used in a CountryAndSubregions structure, the enclosing country is the one indicated by the country field in the CountryAndSubregions structure. If other uses are defined for this structure in future, it is expected that that definition will include a specification of how the enclosing country can be determined. If the enclosing country is the United States of America:
SequenceOfAppExtensions
@brief This structure contains any AppExtensions that apply to the certificate holder. As specified in 5.2.4.2.3, each individual AppExtension type is associated with consistency conditions, specific to that extension, that govern its consistency with SPDUs signed by the certificate holder and with the CertIssueExtensions in the CA certificates in that certificate holders chain. Those consistency conditions are specified for each individual AppExtension below.
SequenceOfCertIssueExtensions
@brief This field contains any CertIssueExtensions that apply to the certificate holder. As specified in 5.2.4.2.3, each individual CertIssueExtension type is associated with consistency conditions, specific to that extension, that govern its consistency with AppExtensions in certificates issued by the certificate holder and with the CertIssueExtensions in the CA certificates in that certificate holders chain. Those consistency conditions are specified for each individual CertIssueExtension below.
SequenceOfCertRequestExtensions
@brief This field contains any CertRequestExtensions that apply to the certificate holder. As specified in 5.2.4.2.3, each individual CertRequestExtension type is associated with consistency conditions, specific to that extension, that govern its consistency with AppExtensions in certificates issued by the certificate holder and with the CertRequestExtensions in the CA certificates in that certificate holders chain. Those consistency conditions are specified for each individual CertRequestExtension below.
SequenceOfCertificate
@brief This type is used for clarity of definitions.
SequenceOfHashedId3
@brief This type is used for clarity of definitions.
SequenceOfIdentifiedRegion
@brief This type is used for clarity of definitions.
SequenceOfLinkageSeed
@brief This type is used for clarity of definitions.
SequenceOfOctetString
@brief This type is used for clarity of definitions.
SequenceOfPsid
@brief This type is used for clarity of definitions.
SequenceOfPsidGroupPermissions
@brief This type is used for clarity of definitions.
SequenceOfPsidSsp
@brief This type is used for clarity of definitions.
SequenceOfPsidSspRange
@brief This type is used for clarity of definitions.
SequenceOfRecipientInfo
@brief This type is used for clarity of definitions.
SequenceOfRectangularRegion
@brief This type is used for clarity of definitions.
SequenceOfRegionAndSubregions
@brief This type is used for clarity of definitions.
SequenceOfUint8
@brief This type is used for clarity of definitions.
SequenceOfUint16
@brief This type is used for clarity of definitions.
ShortPositionVector
SignedData
@brief In this structure: @param hashId: indicates the hash algorithm to be used to generate the hash of the message for signing and verification. @param tbsData: contains the data that is hashed as input to the signature. @param signer: determines the keying material and hash algorithm used to sign the data. @param signature: contains the digital signature itself, calculated as specified in 5.3.1.
SignedDataPayload
@brief This structure contains the data payload of a ToBeSignedData. This structure contains at least one of the optional elements, and may contain more than one. See 5.2.4.3.4 for more details. The security profile in Annex C allows an implementation of this standard to state which forms of Signed¬Data¬Payload are supported by that implementation, and also how the signer and verifier are intended to obtain the external data for hashing. The specification of an SDEE that uses external data is expected to be explicit and unambiguous about how this data is obtained and how it is formatted prior to processing by the hash function. @param data: contains data that is explicitly transported within the structure. @param extDataHash: contains the hash of data that is not explicitly transported within the structure, and which the creator of the structure wishes to cryptographically bind to the signature. @param omitted: indicates that there is external data to be included in the hash calculation for the signature.The mechanism for including the external data in the hash calculation is specified in 6.3.6. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2. The canonicalization applies to the Ieee1609Dot2Data.
SingleHopBroadcast
SubjectAssurance
SymmRecipientInfo
@brief This data structure contains the following fields: @param recipientId: contains the hash of the symmetric key encryption key that may be used to decrypt the data encryption key. It consists of the low-order 8 bytes of the hash of the COER encoding of a SymmetricEncryptionKey structure containing the symmetric key in question. The HashedId8 is calculated with the hash algorithm determined as specified in 5.3.9.4. The symmetric key may be established by any appropriate means agreed by the two parties to the exchange. @param encKey: contains the encrypted data encryption key within a SymmetricCiphertext, where the data encryption key is input to the data encryption key encryption process with no headers, encapsulation, or length indication.
ThreeDLocation
@brief This structure contains an estimate of 3D location. The details of the structure are given in the definitions of the individual fields below. @note The units used in this data structure are consistent with the location data structures used in SAE J2735 [B26], though the encoding is incompatible.
Timestamp
Expresses the time in milliseconds at which the latitude and longitude of the ITS-S were acquired by the GeoAdhoc router. The time is encoded as: TST = TST(TAI) % 2^32 where TST(TAI) is the number of elapsed TAI milliseconds since 2004-01-01 00:00:00.000 UTC
ToBeSignedCertificate
@brief The fields in the ToBeSignedCertificate structure have the following meaning: For both implicit and explicit certificates, when the certificate is hashed to create or recover the public key (in the case of an implicit certificate) or to generate or verify the signature (in the case of an explicit certificate), the hash is Hash (Data input) || Hash ( Signer identifier input), where:
ToBeSignedData
@brief This structure contains the data to be hashed when generating or verifying a signature. See 6.3.4 for the specification of the input to the hash. @param payload: contains data that is provided by the entity that invokes the SDS. @param headerInfo: contains additional data that is inserted by the SDS. This structure is used as follows to determine the “data input” to the hash operation for signing or verification as specified in 5.3.1.2.2 or 5.3.1.3.
TopologicallyScopedBroadcast
TrafficClass
Traffic class that represents Facility-layer requirements on packet transport
TwoDLocation
@brief This structure is used to define validity regions for use in certificates. The latitude and longitude fields contain the latitude and longitude as defined above. @note This data structure is consistent with the location encoding used in SAE J2735, except that values 900 000 001 for latitude (used to indicate that the latitude was not available) and 1 800 000 001 for longitude (used to indicate that the longitude was not available) are not valid.
Uint3
Uint8
@brief This atomic type is used in the definition of other data structures. It is for non-negative integers up to 255, i.e., (hex)ff.
Uint16
@brief This atomic type is used in the definition of other data structures. It is for non-negative integers up to 65,535, i.e., (hex)ff ff.
Uint32
@brief This atomic type is used in the definition of other data structures. It is for non-negative integers up to 4,294,967,295, i.e., (hex)ff ff ff ff.
Uint64
@brief This atomic type is used in the definition of other data structures. It is for non-negative integers up to 18,446,744,073,709,551,615, i.e., (hex)ff ff ff ff ff ff ff ff.
UnknownLatitude
@brief The value 900,000,001 indicates that the latitude was not available to the sender.
UnknownLongitude
@brief The value 1,800,000,001 indicates that the longitude was not available to the sender.
UnsecuredHeader
Helper struct for decoding unsecured GeoNetworking headers from JSON. This crate focuses on zero-copy decoding from binary packets, therefore, JSON deserialization features are limited to a subset of GeoNetworking types.
ValidityPeriod
@brief This type gives the validity period of a certificate. The start of the validity period is given by start and the end is given by start + duration.

Enums

AreaType
Area type used in header subtypes
BasePublicEncryptionKey
@brief This structure specifies the bytes of a public encryption key for a particular algorithm. Supported public key encryption algorithms are defined in 5.3.5. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2 if it appears in a HeaderInfo or in a ToBeSignedCertificate. See the definitions of HeaderInfo and ToBeSignedCertificate for a specification of the canonicalization operations.
BroadcastType
Broadcast type used in header subtypes
CertIssueExtensionPermissions
Inner type
CertRequestExtensionPermissions
Inner type
CertificateId
@brief This structure contains information that is used to identify the certificate holder if necessary. @param linkageData: is used to identify the certificate for revocation purposes in the case of certificates that appear on linked certificate CRLs. See 5.1.3 and 7.3 for further discussion. @param name: is used to identify the certificate holder in the case of non-anonymous certificates. The contents of this field are a matter of policy and are expected to be human-readable. @param binaryId: supports identifiers that are not human-readable. @param none: indicates that the certificate does not include an identifier. @note Critical information fields:
CertificateType
@brief This enumerated type indicates whether a certificate is explicit or implicit. @note Critical information fields: If present, this is a critical information field as defined in 5.2.5. An implementation that does not recognize the indicated CHOICE for this type when verifying a signed SPDU shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established.
DecodeError
Duration
@brief This structure represents the duration of validity of a certificate. The Uint16 value is the duration, given in the units denoted by the indicated choice. A year is considered to be 31556952 seconds, which is the average number of seconds in a year. @note Years can be mapped more closely to wall-clock days using the hours choice for up to 7 years and the sixtyHours choice for up to 448 years.
EccP256CurvePoint
@brief This structure specifies a point on an elliptic curve in Weierstrass form defined over a 256-bit prime number. The curves supported in this standard are NIST p256 as defined in FIPS 186-4, Brainpool p256r1 as defined in RFC 5639, and the SM2 curve as defined in GB/T 32918.5-2017. The fields in this structure are OCTET STRINGS produced with the elliptic curve point encoding and decoding methods defined in subclause 5.5.6 of IEEE Std 1363-2000. The x-coordinate is encoded as an unsigned integer of length 32 octets in network byte order for all values of the CHOICE; the encoding of the y-coordinate y depends on whether the point is x-only, compressed, or uncompressed. If the point is x-only, y is omitted. If the point is compressed, the value of type depends on the least significant bit of y: if the least significant bit of y is 0, type takes the value compressed-y-0, and if the least significant bit of y is 1, type takes the value compressed-y-1. If the point is uncompressed, y is encoded explicitly as an unsigned integer of length 32 octets in network byte order. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2 if it appears in a HeaderInfo or in a ToBeSignedCertificate. See the definitions of HeaderInfo and ToBeSignedCertificate for a specification of the canonicalization operations.
EccP384CurvePoint
@brief This structure specifies a point on an elliptic curve in Weierstrass form defined over a 384-bit prime number. The only supported such curve in this standard is Brainpool p384r1 as defined in RFC 5639. The fields in this structure are octet strings produced with the elliptic curve point encoding and decoding methods defined in subclause 5.5.6 of IEEE Std 1363-2000. The x-coordinate is encoded as an unsigned integer of length 48 octets in network byte order for all values of the CHOICE; the encoding of the y-coordinate y depends on whether the point is x-only, compressed, or uncompressed. If the point is x-only, y is omitted. If the point is compressed, the value of type depends on the least significant bit of y: if the least significant bit of y is 0, type takes the value compressed-y-0, and if the least significant bit of y is 1, type takes the value compressed-y-1. If the point is uncompressed, y is encoded explicitly as an unsigned integer of length 48 octets in network byte order. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2 if it appears in a HeaderInfo or in a ToBeSignedCertificate. See the definitions of HeaderInfo and ToBeSignedCertificate for a specification of the canonicalization operations.
EncodeError
EncryptedDataEncryptionKey
@brief This data structure contains an encrypted data encryption key, where the data encryption key is input to the data encryption key encryption process with no headers, encapsulation, or length indication. Critical information fields: If present and applicable to the receiving SDEE, this is a critical information field as defined in 5.2.6. If an implementation receives an encrypted SPDU and determines that one or more RecipientInfo fields are relevant to it, and if all of those RecipientInfos contain an EncryptedDataEncryptionKey such that the implementation does not recognize the indicated CHOICE, the implementation shall indicate that the encrypted SPDU is not decryptable.
EncryptionKey
@brief This structure contains an encryption key, which may be a public or a symmetric key. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2 if it appears in a HeaderInfo or in a ToBeSignedCertificate. The canonicalization applies to the PublicEncryptionKey. See the definitions of HeaderInfo and ToBeSignedCertificate for a specification of the canonicalization operations.
ExtendedHeader
GeographicRegion
HashAlgorithm
@brief This structure identifies a hash algorithm. The value sha256, indicates SHA-256. The value sha384 indicates SHA-384. The value sm3 indicates SM3. See 5.3.3 for more details. @note Critical information fields: This is a critical information field as defined in 5.2.6. An implementation that does not recognize the enumerated value of this type in a signed SPDU when verifying a signed SPDU shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established.
HashedData
@brief This structure contains the hash of some data with a specified hash algorithm. See 5.3.3 for specification of the permitted hash algorithms. @param sha256HashedData: indicates data hashed with SHA-256. @param sha384HashedData: indicates data hashed with SHA-384. @param sm3HashedData: indicates data hashed with SM3. @note Critical information fields: If present, this is a critical information field as defined in 5.2.6. An implementation that does not recognize the indicated CHOICE for this type when verifying a signed SPDU shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established.
HeaderType
Identifies the type of the GeoNetworking header
IdentifiedRegion
@brief This structure indicates the region of validity of a certificate using region identifiers. A conformant implementation that supports this type shall support at least one of the possible CHOICE values. The Protocol Implementation Conformance Statement (PICS) provided in Annex A allows an implementation to state which CountryOnly values it recognizes. @param countryOnly: indicates that only a country (or a geographic entity included in a country list) is given. @param countryAndRegions: indicates that one or more top-level regions within a country (as defined by the region listing associated with that country) is given. @param countryAndSubregions: indicates that one or more regions smaller than the top-level regions within a country (as defined by the region listing associated with that country) is given. Critical information fields: If present, this is a critical information field as defined in 5.2.6. An implementation that does not recognize the indicated CHOICE when verifying a signed SPDU shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established.
Ieee1609Dot2Content
@brief In this structure: @param unsecuredData: indicates that the content is an OCTET STRING to be consumed outside the SDS. @param signedData: indicates that the content has been signed according to this standard. @param encryptedData: indicates that the content has been encrypted according to this standard. @param signedCertificateRequest: indicates that the content is a certificate request signed by an IEEE 1609.2 certificate or self-signed. @param signedX509CertificateRequest: indicates that the content is a certificate request signed by an ITU-T X.509 certificate. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2 if it is of type signedData. The canonicalization applies to the SignedData.
IssuerIdentifier
@brief This structure allows the recipient of a certificate to determine which keying material to use to authenticate the certificate. If the choice indicated is sha256AndDigest, sha384AndDigest, or sm3AndDigest:
LocationServiceType
Subtype of location service
NextAfterBasic
Identifies the type of header immediately following the GeoNetworking Basic Header
NextAfterCommon
Identifies the type of header immediately following the GeoNetworking Common Header
Packet
PublicVerificationKey
@brief This structure represents a public key and states with what algorithm the public key is to be used. Cryptographic mechanisms are defined in 5.3. An EccP256CurvePoint or EccP384CurvePoint within a PublicVerificationKey structure is invalid if it indicates the choice x-only. @note Critical information fields: If present, this is a critical information field as defined in 5.2.6. An implementation that does not recognize the indicated CHOICE when verifying a signed SPDU shall indicate that the signed SPDU is invalid indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2. The canonicalization applies to the EccP256CurvePoint and the Ecc384CurvePoint. Both forms of point are encoded in compressed form, i.e., such that the choice indicated within the Ecc*CurvePoint is compressed-y-0 or compressed-y-1.
RecipientInfo
@brief This data structure is used to transfer the data encryption key to an individual recipient of an EncryptedData. The option pskRecipInfo is selected if the EncryptedData was encrypted using the static encryption key approach specified in 5.3.4. The other options are selected if the EncryptedData was encrypted using the ephemeral encryption key approach specified in 5.3.4. The meanings of the choices are: See Annex C.7 for guidance on when it may be appropriate to use each of these approaches. @param pskRecipInfo: The data was encrypted directly using a pre-shared symmetric key. @param symmRecipInfo: The data was encrypted with a data encryption key, and the data encryption key was encrypted using a symmetric key. @param certRecipInfo: The data was encrypted with a data encryption key, the data encryption key was encrypted using a public key encryption scheme, where the public encryption key was obtained from a certificate. In this case, the parameter P1 to ECIES as defined in 5.3.5 is the hash of the certificate, calculated with the whole-certificate hash algorithm, determined as described in 6.4.3, applied to the COER-encoded certificate, canonicalized as defined in the definition of Certificate. @note If the encryption algorithm is SM2, there is no equivalent of the parameter P1 and so no input to the encryption process that uses the hash of the certificate. @param signedDataRecipInfo: The data was encrypted with a data encryption key, the data encryption key was encrypted using a public key encryption scheme, where the public encryption key was obtained as the public response encryption key from a SignedData. In this case, if ECIES is the encryption algorithm, then the parameter P1 to ECIES as defined in 5.3.5 is the SHA-256 hash of the Ieee1609Dot2Data of type signedData containing the response encryption key, canonicalized as defined in the definition of Ieee1609Dot2Data. @note If the encryption algorithm is SM2, there is no equivalent of the parameter P1 and so no input to the encryption process that uses the hash of the Ieee1609Dot2Data. @param rekRecipInfo: The data was encrypted with a data encryption key, the data encryption key was encrypted using a public key encryption scheme, where the public encryption key was not obtained from a Signed-Data or a certificate. In this case, the SDEE specification is expected to specify how the public key is obtained, and if ECIES is the encryption algorithm, then the parameter P1 to ECIES as defined in 5.3.5 is the hash of the empty string. @note If the encryption algorithm is SM2, there is no equivalent of the parameter P1 and so no input to the encryption process that uses the hash of the empty string. @note The material input to encryption is the bytes of the encryption key with no headers, encapsulation, or length indication. Contrast this to encryption of data, where the data is encapsulated in an Ieee1609Dot2Data.
ServiceSpecificPermissions
@brief This structure represents the Service Specific Permissions (SSP) relevant to a given entry in a PsidSsp. The meaning of the SSP is specific to the associated Psid. SSPs may be PSID-specific octet strings or bitmap-based. See Annex C for further discussion of how application specifiers may choose which SSP form to use. @note Consistency with issuing certificate: If a certificate has an appPermissions entry A for which the ssp field is opaque, A is consistent with the issuing certificate if the issuing certificate contains one of the following:
Signature
SignerIdentifier
@brief This structure allows the recipient of data to determine which keying material to use to authenticate the data. It also indicates the verification type to be used to generate the hash for verification, as specified in 5.3.1. @param digest: If the choice indicated is digest:
SspRange
@brief This structure identifies the SSPs associated with a PSID for which the holder may issue or request certificates. @note Consistency with issuing certificate: If a certificate has a PsidSspRange A for which the ssp field is opaque, A is consistent with the issuing certificate if the issuing certificate contains one of the following:
StationType
SubjectPermissions
@brief This indicates the PSIDs and associated SSPs for which certificate issuance or request permissions are granted by a PsidGroupPermissions structure. If this takes the value explicit, the enclosing PsidGroupPermissions structure grants certificate issuance or request permissions for the indicated PSIDs and SSP Ranges. If this takes the value all, the enclosing PsidGroupPermissions structure grants certificate issuance or request permissions for all PSIDs not indicated by other PsidGroupPermissions in the same certIssuePermissions or certRequestPermissions field. @note Critical information fields:
SymmAlgorithm
@brief This enumerated value indicates supported symmetric algorithms. The algorithm identifier identifies both the algorithm itself and a specific mode of operation. The symmetric algorithms supported in this version of this standard are AES-128 and SM4. The only mode of operation supported is Counter Mode Encryption With Cipher Block Chaining Message Authentication Code (CCM). Full details are given in 5.3.8.
SymmetricCiphertext
@brief This data structure encapsulates a ciphertext generated with an approved symmetric algorithm. @note Critical information fields: If present, this is a critical information field as defined in 5.2.6. An implementation that does not recognize the indicated CHOICE value for this type in an encrypted SPDU shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established.
SymmetricEncryptionKey
@brief This structure provides the key bytes for use with an identified symmetric algorithm. The supported symmetric algorithms are AES-128 and SM4 in CCM mode as specified in 5.3.8.
ValidationError
ValidationResult
VerificationKeyIndicator
@brief The contents of this field depend on whether the certificate is an implicit or an explicit certificate. @param verificationKey: is included in explicit certificates. It contains the public key to be used to verify signatures generated by the holder of the Certificate. @param reconstructionValue: is included in implicit certificates. It contains the reconstruction value, which is used to recover the public key as specified in SEC 4 and 5.3.2. @note Critical information fields: If present, this is a critical information field as defined in 5.2.5. An implementation that does not recognize the indicated CHOICE for this type when verifying a signed SPDU shall indicate that the signed SPDU is invalid indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established. @note Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2. The canonicalization applies to the PublicVerificationKey and to the EccP256CurvePoint. The EccP256CurvePoint is encoded in compressed form, i.e., such that the choice indicated within the EccP256CurvePoint is compressed-y-0 or compressed-y-1.

Aes128CcmCiphertext
@brief This type is defined only for backwards compatibility.
Certificate
Countersignature
@brief This data structure is used to perform a countersignature over an already-signed SPDU. This is the profile of an Ieee1609Dot2Data containing a signedData. The tbsData within content is composed of a payload containing the hash (extDataHash) of the externally generated, pre-signed SPDU over which the countersignature is performed.
CountryOnly
@brief This type is defined only for backwards compatibility.
CrlSeries
@brief This integer identifies a series of CRLs issued under the authority of a particular CRACA.
Elevation
@brief This structure contains an estimate of the geodetic altitude above or below the WGS84 ellipsoid. The 16-bit value is interpreted as an integer number of decimeters representing the height above a minimum height of -409.5 m, with the maximum height being 6143.9 m.
ExplicitCertificate
@brief This is a profile of the CertificateBase structure providing all the fields necessary for an explicit certificate, and no others.
IValue
Ieee1609ContributedHeaderInfoExtension
@brief This structure uses the parameterized type Extension to define an Ieee1609ContributedHeaderInfoExtension as an open Extension Content field identified by an extension identifier. The extension identifier value is unique to extensions defined by ETSI and need not be unique among all extension identifier values defined by all contributing organizations.
Ieee1609HeaderInfoExtensionId
@brief This is an integer used to identify an Ieee1609ContributedHeaderInfoExtension.
ImplicitCertificate
@brief This is a profile of the CertificateBase structure providing all the fields necessary for an implicit certificate, and no others.
Latitude
@brief This type contains an INTEGER encoding an estimate of the latitude with precision 1/10th microdegree relative to the World Geodetic System (WGS)-84 datum as defined in NIMA Technical Report TR8350.2. The integer in the latitude field is no more than 900 000 000 and no less than ?900 000 000, except that the value 900 000 001 is used to indicate the latitude was not available to the sender.
Longitude
@brief This type contains an INTEGER encoding an estimate of the longitude with precision 1/10th microdegree relative to the World Geodetic System (WGS)-84 datum as defined in NIMA Technical Report TR8350.2. The integer in the longitude field is no more than 1 800 000 000 and no less than ?1 799 999 999, except that the value 1 800 000 001 is used to indicate that the longitude was not available to the sender.
PreSharedKeyRecipientInfo
@brief This data structure is used to indicate a symmetric key that may be used directly to decrypt a SymmetricCiphertext. It consists of the low-order 8 bytes of the hash of the COER encoding of a SymmetricEncryptionKey structure containing the symmetric key in question. The HashedId8 is calculated with the hash algorithm determined as specified in 5.3.9.3. The symmetric key may be established by any appropriate means agreed by the two parties to the exchange.
TestCertificate
Time32
Time64
@brief This data structure is a 64-bit integer giving an estimate of the number of (TAI) microseconds since 00:00:00 UTC, 1 January, 2004.
UnCountryId
@brief This type contains the integer representation of the country or area identifier as defined by the United Nations Statistics Division in October 2013 (see normative references in Clause 0). A conformant implementation that implements IdentifiedRegion shall recognize (in the sense of be able to determine whether a two dimensional location lies inside or outside the borders identified by) at least one value of UnCountryId. The Protocol Implementation Conformance Statement (PICS) provided in Annex A allows an implementation to state which UnCountryId values it recognizes. Since 2013 and before the publication of this version of this standard, three changes have been made to the country code list, to define the region “sub-Saharan Africa” and remove the “developed regions”, and “developing regions”. A conformant implementation may recognize these region identifiers in the sense defined in the previous paragraph. If a verifying implementation is required to check that relevant geographic information in a signed SPDU is consistent with a certificate containing one or more instances of this type, then the SDS is permitted to indicate that the signed SPDU is valid even if some instances of this type are unrecognized in the sense defined above, so long as the recognized instances of this type completely contain the relevant geographic information. Informally, if the recognized values in the certificate allow the SDS to determine that the SPDU is valid, then it can make that determination even if there are also unrecognized values in the certificate. This field is therefore not a “critical information field” as defined in 5.2.6, because unrecognized values are permitted so long as the validity of the SPDU can be established with the recognized values. However, as discussed in 5.2.6, the presence of an unrecognized value in a certificate can make it impossible to determine whether the certificate and the SPDU are valid.