ASN.1 Schema Documentation

Summary Tables

This section contains a set of tables presenting summary information about the ASN.1 schema.

►Schema Files Table
▼Schema Files Table
Schema Files
File nameModules
Module nameModule OIDDescription
1609dot2-base-types.asnIEEE1609dot2BaseTypes{iso (1) identified-organization (3) ieee (111) standards-association-numbered-series-standards (2) wave-stds (1609) dot2 (2) base (1) base-types (2) major-version-2 (2)}NOTE: Section references in this file are to clauses in IEEE Std 1609.2 unless indicated otherwise. Full forms of acronyms and abbreviations used in this file are specified in 3.2. The minor version of this module is 1.
►Modules Table
▼Modules Table
Modules
Module nameModule OIDDescriptionNumber
of
assignments		Incoming referencesOutgoing references
Module nameNumberModule nameNumber
IEEE1609dot2BaseTypes{iso (1) identified-organization (3) ieee (111) standards-association-numbered-series-standards (2) wave-stds (1609) dot2 (2) base (1) base-types (2) major-version-2 (2)}NOTE: Section references in this file are to clauses in IEEE Std 1609.2 unless indicated otherwise. Full forms of acronyms and abbreviations used in this file are specified in 3.2. The minor version of this module is 1.71
►PDU Types Table
▼PDU Types Table
PDU Types
Module nameType nameDescription
IEEE1609dot2BaseTypesCrlSeries

CrlSeries

This integer identifies a series of CRLs issued under the authority of a particular CRACA.
IEEE1609dot2BaseTypesEciesP256EncryptedKey

EciesP256EncryptedKey

This data structure is used to transfer a 16-byte symmetric key encrypted using ECIES as specified in IEEE Std 1363a-2004.

Encryption and decryption are carried out as specified in 5.3.4.

In this structure:
  • v
    is the sender’s ephemeral public key, which is the output V from encryption as specified in 5.3.4.
  • c
    is the encrypted symmetric key, which is the output C from encryption as specified in 5.3.4. The algorithm for the symmetric key is identified by the CHOICE indicated in the following SymmetricCiphertext.
  • t
    is the authentication tag, which is the output tag from encryption as specified in 5.3.4.
IEEE1609dot2BaseTypesEncryptionKey

EncryptionKey

This structure contains an encryption key, which may be a public or a symmetric key.
IEEE1609dot2BaseTypesGeographicRegion

GeographicRegion

This structure represents a geographic region of a specified form. A certificate is not valid if any part of the region indicated in its scope field lies outside the region indicated in the scope of its issuer.

Critical information fields:
  1. 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.
  2. If selected, rectangularRegion is a critical information field as defined in 5.2.6. An implementation that does not support the number of RectangularRegion in rectangularRegions when verifying a signed SPDU shall indicate that the signed SPDU is invalid. A compliant implementation shall support rectangularRegions fields containing at least eight entries.
  3. If selected, identifiedRegion is a critical information field as defined in 5.2.6. An implementation that does not support the number of IdentifiedRegion in identifiedRegion shall reject the signed SPDU as invalid. A compliant implementation shall support identifiedRegion fields containing at least eight entries.
In this structure:
  • circularRegion
    contains a single instance of the CircularRegion structure.
  • rectangularRegion
    is an array of RectangularRegion structures containing at least one entry. This field is interpreted as a series of rectangles, which may overlap or be disjoint. The permitted region is any point within any of the rectangles.
  • polygonalRegion
    contains a single instance of the PolygonalRegion structure.
  • identifiedRegion
    is an array of IdentifiedRegion structures containing at least one entry. The permitted region is any point within any of the identified regions.
IEEE1609dot2BaseTypesGroupLinkageValue

GroupLinkageValue

This is the group linkage value. See 5.1.3 and 7.3 for details of use.
IEEE1609dot2BaseTypesHashAlgorithm

HashAlgorithm

This structure identifies a hash algorithm. The value is sha256, indicates SHA-256 as specified in 5.3.3. The value sha384 indicates SHA-384 as specified in 5.3.3.

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.
IEEE1609dot2BaseTypesHashedId10

HashedId10

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. If the data structure is subject to canonicalization it is canonicalized before hashing. The low-order ten bytes are the last ten bytes of the hash when represented in network byte order. 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.

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.
IEEE1609dot2BaseTypesHashedId8

HashedId8

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. If the data structure is subject to canonicalization it is canonicalized before hashing. The low-order eight bytes are the last eight bytes of the hash when represented in network byte order. 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.

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.
IEEE1609dot2BaseTypesHostname

Hostname

This is a UTF-8 string as defined in IETF RFC 3629. The contents are determined by policy.
IEEE1609dot2BaseTypesIValue

IValue

This atomic type is used in the definition of other data structures.
IEEE1609dot2BaseTypesKnownLatitude

KnownLatitude

The known latitudes are from -900,000,000 to +900,000,000 in 0.1 microdegree intervals.
IEEE1609dot2BaseTypesKnownLongitude

KnownLongitude

The known longitudes are from -1,799,999,999 to +1,800,000,000 in 0.1 microdegree intervals.
IEEE1609dot2BaseTypesLaId

LaId

This structure contains a LA Identifier for use in the algorithms specified in 5.1.3.4.
IEEE1609dot2BaseTypesLinkageSeed

LinkageSeed

This structure contains a linkage seed value for use in the algorithms specified in 5.1.3.4.
IEEE1609dot2BaseTypesLinkageValue

LinkageValue

This is the individual linkage value. See 5.1.3 and 7.3 for details of use.
IEEE1609dot2BaseTypesOpaque

Opaque

This is a synonym for ASN.1 OCTET STRING, and is used in the definition of other data structures.
IEEE1609dot2BaseTypesPublicVerificationKey

PublicVerificationKey

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.

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.
IEEE1609dot2BaseTypesSequenceOfHashedId3

SequenceOfHashedId3

This type is used for clarity of definitions.
IEEE1609dot2BaseTypesSequenceOfPsid

SequenceOfPsid

This type is used for clarity of definitions.
IEEE1609dot2BaseTypesSequenceOfPsidSsp

SequenceOfPsidSsp

This type is used for clarity of definitions.
IEEE1609dot2BaseTypesSequenceOfPsidSspRange

SequenceOfPsidSspRange

This type is used for clarity of definitions.
IEEE1609dot2BaseTypesSignature

Signature

This structure represents a signature for a supported public key algorithm. It may be contained within SignedData or Certificate.

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.
IEEE1609dot2BaseTypesSubjectAssurance

SubjectAssurance

This field contains the certificate holder’s assurance level, which indicates the security of both the platform and storage of secret keys as well as the confidence in this assessment.

This field is encoded as defined in Table 1, where “A” denotes bit fields specifying an assurance level, “R” reserved bit fields, and “C” bit fields specifying the confidence.

Table 1: Bitwise encoding of subject assurance
Bit number 7 6 5 4 3 2 1 0
Interpretation A A A R R R C C
In Table 1, bit number 0 denotes the least significant bit. Bit 7 to bit 5 denote the device’s assurance levels, bit 4 to bit 2 are reserved for future use, and bit 1 and bit 0 denote the confidence.

The specification of these assurance levels as well as the encoding of the confidence levels is outside the scope of the present document. It can be assumed that a higher assurance value indicates that the holder is more trusted than the holder of a certificate with lower assurance value and the same confidence value.

NOTE: This field was originally specified in ETSI TS 103 097 and future uses of this field are anticipated to be consistent with future versions of that document.
IEEE1609dot2BaseTypesThreeDLocation

ThreeDLocation

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, though the encoding is incompatible.
IEEE1609dot2BaseTypesTime64

Time64

This type gives the number of (TAI) microseconds since 00:00:00 UTC, 1 January, 2004.
IEEE1609dot2BaseTypesUint3

Uint3

This atomic type is used in the definition of other data structures. It is for non-negative integers up to 7, i.e., (hex)07.
IEEE1609dot2BaseTypesUnknownLatitude

UnknownLatitude

The value 900,000,001 indicates that the latitude was not available to the sender.
IEEE1609dot2BaseTypesUnknownLongitude

UnknownLongitude

The value 1,800,000,001 indicates that the longitude was not available to the sender.
IEEE1609dot2BaseTypesValidityPeriod

ValidityPeriod

This structure 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. In this structure:
  • start
    contains the starting time of the validity period.
  • duration
    contains the duration of the validity period.
►Type Assignments Table
▼Type Assignments Table
Type Assignments
Module nameType nameDescriptionNumber of
incoming
references		Number of
outgoing
references
IEEE1609dot2BaseTypesBasePublicEncryptionKey

BasePublicEncryptionKey

This structure specifies the bytes of a public encryption key for a particular algorithm. The only algorithm supported is ECIES over either the NIST P256 or the Brainpool P256r1 curve as specified in 5.3.4.		11
IEEE1609dot2BaseTypesBitmapSsp

BitmapSsp

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.

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 issuing certificate contains one of the following:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in A;
  • (OPTION 2) A PsidSspRange P for which the following holds:
    • The psid field in P is equal to the psid field in A and one of the following is true:
      • EITHER The sspRange field in P indicates all
      • OR The sspRange field in P indicates bitmapSspRange and for every bit set to 1 in the sspBitmask in P, the bit in the identical position in the sspValue in A is set equal to the bit in that position in the sspValue in P.
NOTE: A BitmapSsp B is consistent with a BitmapSspRange R if for every bit set to 1 in the sspBitmask in R, the bit in the identical position in B is set equal to the bit in that position in the sspValue in R. For each bit set to 0 in the sspBitmask in R, the corresponding bit in the identical position in B may be freely set to 0 or 1, i.e., if a bit is set to 0 in the sspBitmask in R, the value of corresponding bit in the identical position in B has no bearing on whether B and R are consistent.		1
IEEE1609dot2BaseTypesBitmapSspRange

BitmapSspRange

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.

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:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in P;
  • (OPTION 2) A PsidSspRange R for which the following holds:
    • The psid field in R is equal to the psid field in P and one of the following is true:
      • EITHER The sspRange field in R indicates all
      • OR The sspRange field in R indicates bitmapSspRange and for every bit set to 1 in the sspBitmask in R:
        • The bit in the identical position in the sspBitmask in P is set equal to 1, AND
        • The bit in the identical position in the sspValue in P is set equal to the bit in that position in the sspValue in R.

Reference ETSI TS 103 097 for more information on bitmask SSPs.		1
IEEE1609dot2BaseTypesCircularRegion

CircularRegion

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.		12
IEEE1609dot2BaseTypesCountryAndRegions

CountryAndRegions

In this structure:
  • countryOnly
    is a CountryOnly as defined above.
  • region
    identifies one or more regions within the country. If countryOnly 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 2). For other values of countryOnly, the meaning of region is not defined in this version of this standard.
12
IEEE1609dot2BaseTypesCountryAndSubregions

CountryAndSubregions

Critical information fields: If present, this is a critical information field as defined in 5.2.6. An implementation that does not recognize RegionAndSubregions or CountryAndSubregions values when verifying a signed SPDU shall indicate that the signed SPDU is invalid. A compliant implementation shall support CountryAndSubregions containing at least eight RegionAndSubregions entries.

In this structure:
  • country
    is a CountryOnly as defined above.
  • regionAndSubregions
    identifies one or more subregions within country. If country indicates the United States of America, the values in this field identify the county or county equivalent entity using the integer version of the 2010 FIPS codes as provided by the U.S. Census Bureau (see normative references in Clause 2). For other values of country, the meaning of regionAndSubregions is not defined in this version of this standard.
12
IEEE1609dot2BaseTypesCountryOnly

CountryOnly

This is 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 2).		31
IEEE1609dot2BaseTypesCrlSeries

CrlSeries

This integer identifies a series of CRLs issued under the authority of a particular CRACA.		1
IEEE1609dot2BaseTypesDuration

Duration

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; if it is desired to map years more closely to wall-clock days, this can be done using the hours choice for up to seven years and the sixtyHours choice for up to 448. In this structure:
  • microseconds
    contains the duration in microseconds.
  • milliseconds
    contains the duration in milliseconds.
  • seconds
    contains the duration in seconds.
  • minutes
    contains the duration in minutes.
  • hours
    contains the duration in hours.
  • sixtyHours
    contains the duration in sixty-hour periods.
  • years
    contains the duration in years.
11
IEEE1609dot2BaseTypesEccP256CurvePoint

EccP256CurvePoint

This structure specifies a point on an elliptic curve in Weierstrass form defined over a 256-bit prime number. This encompasses both NIST p256 as defined in FIPS 186-4 and Brainpool p256r1 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 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.		4
IEEE1609dot2BaseTypesEccP384CurvePoint

EccP384CurvePoint

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.		2
IEEE1609dot2BaseTypesEcdsaP256Signature

EcdsaP256Signature

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.

Encoding considerations: If this structure is encoded for hashing, the EccP256CurvePoint in rSig shall be taken to be of 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 x-value should be checked to see if it lies between n and p and reduced 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:
  • p = FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF
  • n = FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551
Brainpoolp256:
  • p = A9FB57DBA1EEA9BC3E660A909D838D726E3BF623D52620282013481D1F6E5377
  • n = A9FB57DBA1EEA9BC3E660A909D838D718C397AA3B561A6F7901E0E82974856A7
11
IEEE1609dot2BaseTypesEcdsaP384Signature

EcdsaP384Signature

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.

Encoding considerations: If this structure is encoded for hashing, the EccP256CurvePoint in rSig shall be taken to be of 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 x-value should be checked to see if it lies between n and p and reduced 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:
  • p = 8CB91E82A3386D280F5D6F7E50E641DF152F7109ED5456B412B1DA197FB71123 ACD3A729901D1A71874700133107EC53
  • n = 8CB91E82A3386D280F5D6F7E50E641DF152F7109ED5456B31F166E6CAC0425A7 CF3AB6AF6B7FC3103B883202E9046565
11
IEEE1609dot2BaseTypesEciesP256EncryptedKey

EciesP256EncryptedKey

This data structure is used to transfer a 16-byte symmetric key encrypted using ECIES as specified in IEEE Std 1363a-2004.

Encryption and decryption are carried out as specified in 5.3.4.

In this structure:
  • v
    is the sender’s ephemeral public key, which is the output V from encryption as specified in 5.3.4.
  • c
    is the encrypted symmetric key, which is the output C from encryption as specified in 5.3.4. The algorithm for the symmetric key is identified by the CHOICE indicated in the following SymmetricCiphertext.
  • t
    is the authentication tag, which is the output tag from encryption as specified in 5.3.4.
1
IEEE1609dot2BaseTypesElevation

Elevation

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.		11
IEEE1609dot2BaseTypesEncryptionKey

EncryptionKey

This structure contains an encryption key, which may be a public or a symmetric key.		2
IEEE1609dot2BaseTypesGeographicRegion

GeographicRegion

This structure represents a geographic region of a specified form. A certificate is not valid if any part of the region indicated in its scope field lies outside the region indicated in the scope of its issuer.

Critical information fields:
  1. 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.
  2. If selected, rectangularRegion is a critical information field as defined in 5.2.6. An implementation that does not support the number of RectangularRegion in rectangularRegions when verifying a signed SPDU shall indicate that the signed SPDU is invalid. A compliant implementation shall support rectangularRegions fields containing at least eight entries.
  3. If selected, identifiedRegion is a critical information field as defined in 5.2.6. An implementation that does not support the number of IdentifiedRegion in identifiedRegion shall reject the signed SPDU as invalid. A compliant implementation shall support identifiedRegion fields containing at least eight entries.
In this structure:
  • circularRegion
    contains a single instance of the CircularRegion structure.
  • rectangularRegion
    is an array of RectangularRegion structures containing at least one entry. This field is interpreted as a series of rectangles, which may overlap or be disjoint. The permitted region is any point within any of the rectangles.
  • polygonalRegion
    contains a single instance of the PolygonalRegion structure.
  • identifiedRegion
    is an array of IdentifiedRegion structures containing at least one entry. The permitted region is any point within any of the identified regions.
4
IEEE1609dot2BaseTypesGroupLinkageValue

GroupLinkageValue

This is the group linkage value. See 5.1.3 and 7.3 for details of use.
IEEE1609dot2BaseTypesHashAlgorithm

HashAlgorithm

This structure identifies a hash algorithm. The value is sha256, indicates SHA-256 as specified in 5.3.3. The value sha384 indicates SHA-384 as specified in 5.3.3.

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.
IEEE1609dot2BaseTypesHashedId10

HashedId10

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. If the data structure is subject to canonicalization it is canonicalized before hashing. The low-order ten bytes are the last ten bytes of the hash when represented in network byte order. 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.

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.
IEEE1609dot2BaseTypesHashedId3

HashedId3

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. If the data structure is subject to canonicalization it is canonicalized before hashing. The low-order three bytes are the last three bytes of the 32-byte hash when represented in network byte order. See Example below.

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.		1
IEEE1609dot2BaseTypesHashedId8

HashedId8

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. If the data structure is subject to canonicalization it is canonicalized before hashing. The low-order eight bytes are the last eight bytes of the hash when represented in network byte order. 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.

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.
IEEE1609dot2BaseTypesHostname

Hostname

This is a UTF-8 string as defined in IETF RFC 3629. The contents are determined by policy.
IEEE1609dot2BaseTypesIdentifiedRegion

IdentifiedRegion

This structure indicates the region of validity of a certificate using region identifiers.

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.		13
IEEE1609dot2BaseTypesIValue

IValue

This atomic type is used in the definition of other data structures.		1
IEEE1609dot2BaseTypesKnownLatitude

KnownLatitude

The known latitudes are from -900,000,000 to +900,000,000 in 0.1 microdegree intervals.		1
IEEE1609dot2BaseTypesKnownLongitude

KnownLongitude

The known longitudes are from -1,799,999,999 to +1,800,000,000 in 0.1 microdegree intervals.		1
IEEE1609dot2BaseTypesLaId

LaId

This structure contains a LA Identifier for use in the algorithms specified in 5.1.3.4.
IEEE1609dot2BaseTypesLatitude

Latitude

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.		21
IEEE1609dot2BaseTypesLinkageSeed

LinkageSeed

This structure contains a linkage seed value for use in the algorithms specified in 5.1.3.4.
IEEE1609dot2BaseTypesLinkageValue

LinkageValue

This is the individual linkage value. See 5.1.3 and 7.3 for details of use.
IEEE1609dot2BaseTypesLongitude

Longitude

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.		21
IEEE1609dot2BaseTypesNinetyDegreeInt

NinetyDegreeInt

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.		3
IEEE1609dot2BaseTypesOneEightyDegreeInt

OneEightyDegreeInt

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.		3
IEEE1609dot2BaseTypesOpaque

Opaque

This is a synonym for ASN.1 OCTET STRING, and is used in the definition of other data structures.
IEEE1609dot2BaseTypesPolygonalRegion

PolygonalRegion

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.

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.		11
IEEE1609dot2BaseTypesPsid

Psid

This type represents the PSID defined in IEEE Std 1609.12.		3
IEEE1609dot2BaseTypesPsidSsp

PsidSsp

This structure represents the permissions that the certificate holder has with respect to data for a single application area, identified by a Psid. If the ServiceSpecificPermissions field is omitted, it indicates that the certificate holder has the default permissions associated with that Psid.

Consistency with signed SPDU. As noted in 5.1.1, consistency between the SSP and the signed SPDU is defined by rules specific to the given PSID and is out of scope for this standard.

Consistency with issuing certificate.

If a certificate has an appPermissions entry A for which the ssp field is omitted, A is consistent with the issuing certificate if the issuing certificate contains a PsidSspRange P for which the following holds:
  • The psid field in P is equal to the psid field in A and one of the following is true:
    • The sspRange field in P indicates all.
    • The sspRange field in P indicates opaque and one of the entries in opaque is an OCTET STRING of length 0.
For consistency rules for other forms of the ssp field, see the following subclauses.		12
IEEE1609dot2BaseTypesPsidSspRange

PsidSspRange

This structure represents the certificate issuing or requesting permissions of the certificate holder with respect to one particular set of application permissions. In this structure:
  • psid
    identifies the application area.
  • 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.
12
IEEE1609dot2BaseTypesPublicEncryptionKey

PublicEncryptionKey

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.		12
IEEE1609dot2BaseTypesPublicVerificationKey

PublicVerificationKey

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.

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.		2
IEEE1609dot2BaseTypesRectangularRegion

RectangularRegion

This structure specifies a rectangle formed by connecting in sequence: (northWest.latitude, northWest.longitude), (southEast.latitude, northWest.longitude), (southEast.latitude, southEast.longitude), and (northWest.latitude, southEast.longitude). The points are connected 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 valid only if the northWest value is north and west of the southEast value, i.e., the two points cannot have equal latitude or equal longitude.		11
IEEE1609dot2BaseTypesRegionAndSubregions

RegionAndSubregions

Critical information fields: RegionAndSubregions is a critical information field as defined in 5.2.5. An implementation that does not detect or recognize the the region or subregions values when verifying a signed SPDU shall indicate that the signed SPDU is invalid.

In this structure:
  • region
    identifies a region within a country as specified under CountryAndRegions.
  • subregions
    identifies one or more subregions as specified under CountryAndSubregions.
12
IEEE1609dot2BaseTypesSequenceOfHashedId3

SequenceOfHashedId3

This type is used for clarity of definitions.		1
IEEE1609dot2BaseTypesSequenceOfIdentifiedRegion

SequenceOfIdentifiedRegion

This type is used for clarity of definitions.		11
IEEE1609dot2BaseTypesSequenceOfOctetString

SequenceOfOctetString

This type is used for clarity of definitions.		1
IEEE1609dot2BaseTypesSequenceOfPsid

SequenceOfPsid

This type is used for clarity of definitions.		1
IEEE1609dot2BaseTypesSequenceOfPsidSsp

SequenceOfPsidSsp

This type is used for clarity of definitions.		1
IEEE1609dot2BaseTypesSequenceOfPsidSspRange

SequenceOfPsidSspRange

This type is used for clarity of definitions.		1
IEEE1609dot2BaseTypesSequenceOfRectangularRegion

SequenceOfRectangularRegion

This type is used for clarity of definitions.		11
IEEE1609dot2BaseTypesSequenceOfRegionAndSubregions

SequenceOfRegionAndSubregions

This type is used for clarity of definitions.		11
IEEE1609dot2BaseTypesSequenceOfUint16

SequenceOfUint16

This type is used for clarity of definitions.		11
IEEE1609dot2BaseTypesSequenceOfUint8

SequenceOfUint8

This type is used for clarity of definitions.		11
IEEE1609dot2BaseTypesServiceSpecificPermissions

ServiceSpecificPermissions

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.

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:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in A;
  • (OPTION 2) A PsidSspRange P for which the following holds:
    • The psid field in P is equal to the psid field in A and one of the following is true:
      • The sspRange field in P indicates all.
      • The sspRange field in P indicates opaque and one of the entries in the opaque field in P is an OCTET STRING identical to the opaque field in A.
For consistency rules for other types of ServiceSpecificPermissions, see the following subclauses.		11
IEEE1609dot2BaseTypesSignature

Signature

This structure represents a signature for a supported public key algorithm. It may be contained within SignedData or Certificate.

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.		2
IEEE1609dot2BaseTypesSspRange

SspRange

This structure identifies the SSPs associated with a PSID for which the holder may issue or request certificates.

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:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in A;
  • (OPTION 2) a PsidSspRange P for which the following holds:
    • The psid field in P is equal to the psid field in A and one of the following is true:
      • The sspRange field in P indicates all.
      • The sspRange field in P indicates opaque, and the sspRange field in A indicates opaque, and every OCTET STRING within the opaque in A is a duplicate of an OCTET STRING within the opaque in P.
If a certificate has a PsidSspRange A for which the ssp field is all, A is consistent with the issuing certificate if the issuing certificate contains a PsidSspRange P for which the following holds:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in A;
  • (OPTION 2) A PsidSspRange P for which the psid field in P is equal to the psid field in A and the sspRange field in P indicates all.
For consistency rules for other types of SspRange, see the following subclauses.

NOTE: The choice “all” may also be indicated by omitting the SspRange in the enclosing PsidSspRange structure. Omitting the SspRange is preferred to explicitly indicating “all”.		12
IEEE1609dot2BaseTypesSubjectAssurance

SubjectAssurance

This field contains the certificate holder’s assurance level, which indicates the security of both the platform and storage of secret keys as well as the confidence in this assessment.

This field is encoded as defined in Table 1, where “A” denotes bit fields specifying an assurance level, “R” reserved bit fields, and “C” bit fields specifying the confidence.

Table 1: Bitwise encoding of subject assurance
Bit number 7 6 5 4 3 2 1 0
Interpretation A A A R R R C C
In Table 1, bit number 0 denotes the least significant bit. Bit 7 to bit 5 denote the device’s assurance levels, bit 4 to bit 2 are reserved for future use, and bit 1 and bit 0 denote the confidence.

The specification of these assurance levels as well as the encoding of the confidence levels is outside the scope of the present document. It can be assumed that a higher assurance value indicates that the holder is more trusted than the holder of a certificate with lower assurance value and the same confidence value.

NOTE: This field was originally specified in ETSI TS 103 097 and future uses of this field are anticipated to be consistent with future versions of that document.
IEEE1609dot2BaseTypesSymmAlgorithm

SymmAlgorithm

This enumerated value indicates supported symmetric algorithms. The only symmetric algorithm supported in this version of this standard is AES-CCM as specified in 5.3.7.		1
IEEE1609dot2BaseTypesSymmetricEncryptionKey

SymmetricEncryptionKey

This structure provides the key bytes for use with an identified symmetric algorithm. The only supported symmetric algorithm is AES-128 in CCM mode as specified in 5.3.7.		1
IEEE1609dot2BaseTypesThreeDLocation

ThreeDLocation

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, though the encoding is incompatible.		3
IEEE1609dot2BaseTypesTime32

Time32

This type gives the number of (TAI) seconds since 00:00:00 UTC, 1 January, 2004.		11
IEEE1609dot2BaseTypesTime64

Time64

This type gives the number of (TAI) microseconds since 00:00:00 UTC, 1 January, 2004.		1
IEEE1609dot2BaseTypesTwoDLocation

TwoDLocation

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.		32
IEEE1609dot2BaseTypesUint16

Uint16

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.		7
IEEE1609dot2BaseTypesUint3

Uint3

This atomic type is used in the definition of other data structures. It is for non-negative integers up to 7, i.e., (hex)07.
IEEE1609dot2BaseTypesUint32

Uint32

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.		1
IEEE1609dot2BaseTypesUint64

Uint64

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.		1
IEEE1609dot2BaseTypesUint8

Uint8

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.		2
IEEE1609dot2BaseTypesUnknownLatitude

UnknownLatitude

The value 900,000,001 indicates that the latitude was not available to the sender.		1
IEEE1609dot2BaseTypesUnknownLongitude

UnknownLongitude

The value 1,800,000,001 indicates that the longitude was not available to the sender.		1
IEEE1609dot2BaseTypesValidityPeriod

ValidityPeriod

This structure 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. In this structure:
  • start
    contains the starting time of the validity period.
  • duration
    contains the duration of the validity period.
2
►Type Assignments Cross Reference Table
▼Type Assignments Cross Reference Table
Type Assignments Cross Reference
Module nameType nameIncoming referencesOutgoing references
Module nameEntity nameNumberModule nameEntity nameNumber
IEEE1609dot2BaseTypesBasePublicEncryptionKeyIEEE1609dot2BaseTypesPublicEncryptionKey1IEEE1609dot2BaseTypesEccP256CurvePoint2
IEEE1609dot2BaseTypesBitmapSspIEEE1609dot2BaseTypesServiceSpecificPermissions1
IEEE1609dot2BaseTypesBitmapSspRangeIEEE1609dot2BaseTypesSspRange1
IEEE1609dot2BaseTypesCircularRegionIEEE1609dot2BaseTypesGeographicRegion1IEEE1609dot2BaseTypesTwoDLocation1
IEEE1609dot2BaseTypesUint161
IEEE1609dot2BaseTypesCountryAndRegionsIEEE1609dot2BaseTypesIdentifiedRegion1IEEE1609dot2BaseTypesCountryOnly1
IEEE1609dot2BaseTypesSequenceOfUint81
IEEE1609dot2BaseTypesCountryAndSubregionsIEEE1609dot2BaseTypesIdentifiedRegion1IEEE1609dot2BaseTypesCountryOnly1
IEEE1609dot2BaseTypesSequenceOfRegionAndSubregions1
IEEE1609dot2BaseTypesCountryOnlyIEEE1609dot2BaseTypesCountryAndRegions1IEEE1609dot2BaseTypesUint161
IEEE1609dot2BaseTypesCountryAndSubregions1
IEEE1609dot2BaseTypesIdentifiedRegion1
IEEE1609dot2BaseTypesCrlSeriesIEEE1609dot2BaseTypesUint161
IEEE1609dot2BaseTypesDurationIEEE1609dot2BaseTypesValidityPeriod1IEEE1609dot2BaseTypesUint167
IEEE1609dot2BaseTypesEccP256CurvePointIEEE1609dot2BaseTypesBasePublicEncryptionKey2
IEEE1609dot2BaseTypesEcdsaP256Signature1
IEEE1609dot2BaseTypesEciesP256EncryptedKey1
IEEE1609dot2BaseTypesPublicVerificationKey2
IEEE1609dot2BaseTypesEccP384CurvePointIEEE1609dot2BaseTypesEcdsaP384Signature1
IEEE1609dot2BaseTypesPublicVerificationKey1
IEEE1609dot2BaseTypesEcdsaP256SignatureIEEE1609dot2BaseTypesSignature2IEEE1609dot2BaseTypesEccP256CurvePoint1
IEEE1609dot2BaseTypesEcdsaP384SignatureIEEE1609dot2BaseTypesSignature1IEEE1609dot2BaseTypesEccP384CurvePoint1
IEEE1609dot2BaseTypesEciesP256EncryptedKeyIEEE1609dot2BaseTypesEccP256CurvePoint1
IEEE1609dot2BaseTypesElevationIEEE1609dot2BaseTypesThreeDLocation1IEEE1609dot2BaseTypesUint161
IEEE1609dot2BaseTypesEncryptionKeyIEEE1609dot2BaseTypesPublicEncryptionKey1
IEEE1609dot2BaseTypesSymmetricEncryptionKey1
IEEE1609dot2BaseTypesGeographicRegionIEEE1609dot2BaseTypesCircularRegion1
IEEE1609dot2BaseTypesPolygonalRegion1
IEEE1609dot2BaseTypesSequenceOfIdentifiedRegion1
IEEE1609dot2BaseTypesSequenceOfRectangularRegion1
IEEE1609dot2BaseTypesGroupLinkageValue
IEEE1609dot2BaseTypesHashAlgorithm
IEEE1609dot2BaseTypesHashedId10
IEEE1609dot2BaseTypesHashedId3IEEE1609dot2BaseTypesSequenceOfHashedId31
IEEE1609dot2BaseTypesHashedId8
IEEE1609dot2BaseTypesHostname
IEEE1609dot2BaseTypesIdentifiedRegionIEEE1609dot2BaseTypesSequenceOfIdentifiedRegion1IEEE1609dot2BaseTypesCountryAndRegions1
IEEE1609dot2BaseTypesCountryAndSubregions1
IEEE1609dot2BaseTypesCountryOnly1
IEEE1609dot2BaseTypesIValueIEEE1609dot2BaseTypesUint161
IEEE1609dot2BaseTypesKnownLatitudeIEEE1609dot2BaseTypesNinetyDegreeInt1
IEEE1609dot2BaseTypesKnownLongitudeIEEE1609dot2BaseTypesOneEightyDegreeInt1
IEEE1609dot2BaseTypesLaId
IEEE1609dot2BaseTypesLatitudeIEEE1609dot2BaseTypesThreeDLocation1IEEE1609dot2BaseTypesNinetyDegreeInt1
IEEE1609dot2BaseTypesTwoDLocation1
IEEE1609dot2BaseTypesLinkageSeed
IEEE1609dot2BaseTypesLinkageValue
IEEE1609dot2BaseTypesLongitudeIEEE1609dot2BaseTypesThreeDLocation1IEEE1609dot2BaseTypesOneEightyDegreeInt1
IEEE1609dot2BaseTypesTwoDLocation1
IEEE1609dot2BaseTypesNinetyDegreeIntIEEE1609dot2BaseTypesKnownLatitude1
IEEE1609dot2BaseTypesLatitude1
IEEE1609dot2BaseTypesUnknownLatitude1
IEEE1609dot2BaseTypesOneEightyDegreeIntIEEE1609dot2BaseTypesKnownLongitude1
IEEE1609dot2BaseTypesLongitude1
IEEE1609dot2BaseTypesUnknownLongitude1
IEEE1609dot2BaseTypesOpaque
IEEE1609dot2BaseTypesPolygonalRegionIEEE1609dot2BaseTypesGeographicRegion1IEEE1609dot2BaseTypesTwoDLocation1
IEEE1609dot2BaseTypesPsidIEEE1609dot2BaseTypesPsidSsp1
IEEE1609dot2BaseTypesPsidSspRange1
IEEE1609dot2BaseTypesSequenceOfPsid1
IEEE1609dot2BaseTypesPsidSspIEEE1609dot2BaseTypesSequenceOfPsidSsp1IEEE1609dot2BaseTypesPsid1
IEEE1609dot2BaseTypesServiceSpecificPermissions1
IEEE1609dot2BaseTypesPsidSspRangeIEEE1609dot2BaseTypesSequenceOfPsidSspRange1IEEE1609dot2BaseTypesPsid1
IEEE1609dot2BaseTypesSspRange1
IEEE1609dot2BaseTypesPublicEncryptionKeyIEEE1609dot2BaseTypesEncryptionKey1IEEE1609dot2BaseTypesBasePublicEncryptionKey1
IEEE1609dot2BaseTypesSymmAlgorithm1
IEEE1609dot2BaseTypesPublicVerificationKeyIEEE1609dot2BaseTypesEccP256CurvePoint2
IEEE1609dot2BaseTypesEccP384CurvePoint1
IEEE1609dot2BaseTypesRectangularRegionIEEE1609dot2BaseTypesSequenceOfRectangularRegion1IEEE1609dot2BaseTypesTwoDLocation2
IEEE1609dot2BaseTypesRegionAndSubregionsIEEE1609dot2BaseTypesSequenceOfRegionAndSubregions1IEEE1609dot2BaseTypesSequenceOfUint161
IEEE1609dot2BaseTypesUint81
IEEE1609dot2BaseTypesSequenceOfHashedId3IEEE1609dot2BaseTypesHashedId31
IEEE1609dot2BaseTypesSequenceOfIdentifiedRegionIEEE1609dot2BaseTypesGeographicRegion1IEEE1609dot2BaseTypesIdentifiedRegion1
IEEE1609dot2BaseTypesSequenceOfOctetStringIEEE1609dot2BaseTypesSspRange1
IEEE1609dot2BaseTypesSequenceOfPsidIEEE1609dot2BaseTypesPsid1
IEEE1609dot2BaseTypesSequenceOfPsidSspIEEE1609dot2BaseTypesPsidSsp1
IEEE1609dot2BaseTypesSequenceOfPsidSspRangeIEEE1609dot2BaseTypesPsidSspRange1
IEEE1609dot2BaseTypesSequenceOfRectangularRegionIEEE1609dot2BaseTypesGeographicRegion1IEEE1609dot2BaseTypesRectangularRegion1
IEEE1609dot2BaseTypesSequenceOfRegionAndSubregionsIEEE1609dot2BaseTypesCountryAndSubregions1IEEE1609dot2BaseTypesRegionAndSubregions1
IEEE1609dot2BaseTypesSequenceOfUint16IEEE1609dot2BaseTypesRegionAndSubregions1IEEE1609dot2BaseTypesUint161
IEEE1609dot2BaseTypesSequenceOfUint8IEEE1609dot2BaseTypesCountryAndRegions1IEEE1609dot2BaseTypesUint81
IEEE1609dot2BaseTypesServiceSpecificPermissionsIEEE1609dot2BaseTypesPsidSsp1IEEE1609dot2BaseTypesBitmapSsp1
IEEE1609dot2BaseTypesSignatureIEEE1609dot2BaseTypesEcdsaP256Signature2
IEEE1609dot2BaseTypesEcdsaP384Signature1
IEEE1609dot2BaseTypesSspRangeIEEE1609dot2BaseTypesPsidSspRange1IEEE1609dot2BaseTypesBitmapSspRange1
IEEE1609dot2BaseTypesSequenceOfOctetString1
IEEE1609dot2BaseTypesSubjectAssurance
IEEE1609dot2BaseTypesSymmAlgorithmIEEE1609dot2BaseTypesPublicEncryptionKey1
IEEE1609dot2BaseTypesSymmetricEncryptionKeyIEEE1609dot2BaseTypesEncryptionKey1
IEEE1609dot2BaseTypesThreeDLocationIEEE1609dot2BaseTypesElevation1
IEEE1609dot2BaseTypesLatitude1
IEEE1609dot2BaseTypesLongitude1
IEEE1609dot2BaseTypesTime32IEEE1609dot2BaseTypesValidityPeriod1IEEE1609dot2BaseTypesUint321
IEEE1609dot2BaseTypesTime64IEEE1609dot2BaseTypesUint641
IEEE1609dot2BaseTypesTwoDLocationIEEE1609dot2BaseTypesCircularRegion1IEEE1609dot2BaseTypesLatitude1
IEEE1609dot2BaseTypesPolygonalRegion1IEEE1609dot2BaseTypesLongitude1
IEEE1609dot2BaseTypesRectangularRegion2
IEEE1609dot2BaseTypesUint16IEEE1609dot2BaseTypesCircularRegion1
IEEE1609dot2BaseTypesCountryOnly1
IEEE1609dot2BaseTypesCrlSeries1
IEEE1609dot2BaseTypesDuration7
IEEE1609dot2BaseTypesElevation1
IEEE1609dot2BaseTypesIValue1
IEEE1609dot2BaseTypesSequenceOfUint161
IEEE1609dot2BaseTypesUint3
IEEE1609dot2BaseTypesUint32IEEE1609dot2BaseTypesTime321
IEEE1609dot2BaseTypesUint64IEEE1609dot2BaseTypesTime641
IEEE1609dot2BaseTypesUint8IEEE1609dot2BaseTypesRegionAndSubregions1
IEEE1609dot2BaseTypesSequenceOfUint81
IEEE1609dot2BaseTypesUnknownLatitudeIEEE1609dot2BaseTypesNinetyDegreeInt1
IEEE1609dot2BaseTypesUnknownLongitudeIEEE1609dot2BaseTypesOneEightyDegreeInt1
IEEE1609dot2BaseTypesValidityPeriodIEEE1609dot2BaseTypesDuration1
IEEE1609dot2BaseTypesTime321

Schema Files

This section contains the schema files that constitute the ASN.1 schema.

►Schema File 1609dot2-base-types.asn
▼Schema File 1609dot2-base-types.asn

▼--***************************************************************************--

-- IEEE Std 1609.2: Base Data Types --

--***************************************************************************--

NOTE: Section references in this file are to clauses in IEEE Std 1609.2 unless indicated otherwise. Full forms of acronyms and abbreviations used in this file are specified in 3.2. The minor version of this module is 1.

▼IEEE1609dot2BaseTypes {iso (1) identified-organization (3) ieee (111)

standards-association-numbered-series-standards (2) wave-stds (1609) dot2 (2)

base (1) base-types (2) major-version-2 (2)}

DEFINITIONS AUTOMATIC TAGS ::=

BEGIN

▼EXPORTS

ALL;

►EXPORTS⋯;

▼--***************************************************************************--

-- Integer Types --

--***************************************************************************--

Uint3

This atomic type is used in the definition of other data structures. It is for non-negative integers up to 7, i.e., (hex)07.

Uint3 ::= INTEGER (0..7)

Uint8

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.

Uint8 ::= INTEGER (0..255)

Uint16

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.

Uint16 ::= INTEGER (0..65535)

Uint32

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.

Uint32 ::= INTEGER (0..4294967295)

Uint64

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.

Uint64 ::= INTEGER (0..18446744073709551615)

SequenceOfUint8

This type is used for clarity of definitions.

SequenceOfUint8 ::= SEQUENCE OF Uint8

SequenceOfUint16

This type is used for clarity of definitions.

SequenceOfUint16 ::= SEQUENCE OF Uint16

▼--***************************************************************************--

-- OCTET STRING Types --

--***************************************************************************--

Opaque

This is a synonym for ASN.1 OCTET STRING, and is used in the definition of other data structures.

Opaque ::= OCTET STRING

HashedId3

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. If the data structure is subject to canonicalization it is canonicalized before hashing. The low-order three bytes are the last three bytes of the 32-byte hash when represented in network byte order. See Example below.

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.

HashedId3 ::= OCTET STRING (SIZE (3))

HashedId8

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. If the data structure is subject to canonicalization it is canonicalized before hashing. The low-order eight bytes are the last eight bytes of the hash when represented in network byte order. 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.

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.

HashedId8 ::= OCTET STRING (SIZE (8))

HashedId10

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. If the data structure is subject to canonicalization it is canonicalized before hashing. The low-order ten bytes are the last ten bytes of the hash when represented in network byte order. 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.

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.

HashedId10 ::= OCTET STRING (SIZE (10))

SequenceOfHashedId3

This type is used for clarity of definitions.

SequenceOfHashedId3 ::= SEQUENCE OF HashedId3

▼--***************************************************************************--

-- Time Structures --

--***************************************************************************--

Time32

This type gives the number of (TAI) seconds since 00:00:00 UTC, 1 January, 2004.

Time32 ::= Uint32

Time64

This type gives the number of (TAI) microseconds since 00:00:00 UTC, 1 January, 2004.

Time64 ::= Uint64

ValidityPeriod

This structure 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. In this structure:
  • start
    contains the starting time of the validity period.
  • duration
    contains the duration of the validity period.

▼ValidityPeriod ::= SEQUENCE {

start Time32,

duration Duration

}

►ValidityPeriod ::= SEQUENCE {⋯}

Duration

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; if it is desired to map years more closely to wall-clock days, this can be done using the hours choice for up to seven years and the sixtyHours choice for up to 448. In this structure:
  • microseconds
    contains the duration in microseconds.
  • milliseconds
    contains the duration in milliseconds.
  • seconds
    contains the duration in seconds.
  • minutes
    contains the duration in minutes.
  • hours
    contains the duration in hours.
  • sixtyHours
    contains the duration in sixty-hour periods.
  • years
    contains the duration in years.

▼Duration ::= CHOICE {

microseconds Uint16,

milliseconds Uint16,

seconds Uint16,

minutes Uint16,

hours Uint16,

sixtyHours Uint16,

years Uint16

}

►Duration ::= CHOICE {⋯}

▼--***************************************************************************--

-- Location Structures --

--***************************************************************************--

GeographicRegion

This structure represents a geographic region of a specified form. A certificate is not valid if any part of the region indicated in its scope field lies outside the region indicated in the scope of its issuer.

Critical information fields:
  1. 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.
  2. If selected, rectangularRegion is a critical information field as defined in 5.2.6. An implementation that does not support the number of RectangularRegion in rectangularRegions when verifying a signed SPDU shall indicate that the signed SPDU is invalid. A compliant implementation shall support rectangularRegions fields containing at least eight entries.
  3. If selected, identifiedRegion is a critical information field as defined in 5.2.6. An implementation that does not support the number of IdentifiedRegion in identifiedRegion shall reject the signed SPDU as invalid. A compliant implementation shall support identifiedRegion fields containing at least eight entries.
In this structure:
  • circularRegion
    contains a single instance of the CircularRegion structure.
  • rectangularRegion
    is an array of RectangularRegion structures containing at least one entry. This field is interpreted as a series of rectangles, which may overlap or be disjoint. The permitted region is any point within any of the rectangles.
  • polygonalRegion
    contains a single instance of the PolygonalRegion structure.
  • identifiedRegion
    is an array of IdentifiedRegion structures containing at least one entry. The permitted region is any point within any of the identified regions.

▼GeographicRegion ::= CHOICE {

circularRegion CircularRegion,

rectangularRegion SequenceOfRectangularRegion,

polygonalRegion PolygonalRegion,

identifiedRegion SequenceOfIdentifiedRegion,

...

}

►GeographicRegion ::= CHOICE {⋯}

CircularRegion

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.

▼CircularRegion ::= SEQUENCE {

center TwoDLocation,

radius Uint16

}

►CircularRegion ::= SEQUENCE {⋯}

RectangularRegion

This structure specifies a rectangle formed by connecting in sequence: (northWest.latitude, northWest.longitude), (southEast.latitude, northWest.longitude), (southEast.latitude, southEast.longitude), and (northWest.latitude, southEast.longitude). The points are connected 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 valid only if the northWest value is north and west of the southEast value, i.e., the two points cannot have equal latitude or equal longitude.

▼RectangularRegion ::= SEQUENCE {

northWest TwoDLocation,

southEast TwoDLocation

}

►RectangularRegion ::= SEQUENCE {⋯}

SequenceOfRectangularRegion

This type is used for clarity of definitions.

SequenceOfRectangularRegion ::= SEQUENCE OF RectangularRegion

PolygonalRegion

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.

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.

PolygonalRegion ::= SEQUENCE SIZE (3..MAX) OF TwoDLocation

TwoDLocation

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.

▼TwoDLocation ::= SEQUENCE {

latitude Latitude,

longitude Longitude

}

►TwoDLocation ::= SEQUENCE {⋯}

IdentifiedRegion

This structure indicates the region of validity of a certificate using region identifiers.

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.

▼IdentifiedRegion ::= CHOICE {

countryOnly CountryOnly,

countryAndRegions CountryAndRegions,

countryAndSubregions CountryAndSubregions,

...

}

►IdentifiedRegion ::= CHOICE {⋯}

SequenceOfIdentifiedRegion

This type is used for clarity of definitions.

SequenceOfIdentifiedRegion ::= SEQUENCE OF IdentifiedRegion

CountryOnly

This is 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 2).

CountryOnly ::= Uint16

CountryAndRegions

In this structure:
  • countryOnly
    is a CountryOnly as defined above.
  • region
    identifies one or more regions within the country. If countryOnly 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 2). For other values of countryOnly, the meaning of region is not defined in this version of this standard.

▼CountryAndRegions ::= SEQUENCE {

countryOnly CountryOnly,

regions SequenceOfUint8

}

►CountryAndRegions ::= SEQUENCE {⋯}

CountryAndSubregions

Critical information fields: If present, this is a critical information field as defined in 5.2.6. An implementation that does not recognize RegionAndSubregions or CountryAndSubregions values when verifying a signed SPDU shall indicate that the signed SPDU is invalid. A compliant implementation shall support CountryAndSubregions containing at least eight RegionAndSubregions entries.

In this structure:
  • country
    is a CountryOnly as defined above.
  • regionAndSubregions
    identifies one or more subregions within country. If country indicates the United States of America, the values in this field identify the county or county equivalent entity using the integer version of the 2010 FIPS codes as provided by the U.S. Census Bureau (see normative references in Clause 2). For other values of country, the meaning of regionAndSubregions is not defined in this version of this standard.

▼CountryAndSubregions ::= SEQUENCE {

country CountryOnly,

regionAndSubregions SequenceOfRegionAndSubregions

}

►CountryAndSubregions ::= SEQUENCE {⋯}

RegionAndSubregions

Critical information fields: RegionAndSubregions is a critical information field as defined in 5.2.5. An implementation that does not detect or recognize the the region or subregions values when verifying a signed SPDU shall indicate that the signed SPDU is invalid.

In this structure:
  • region
    identifies a region within a country as specified under CountryAndRegions.
  • subregions
    identifies one or more subregions as specified under CountryAndSubregions.

▼RegionAndSubregions ::= SEQUENCE {

region Uint8,

subregions SequenceOfUint16

}

►RegionAndSubregions ::= SEQUENCE {⋯}

SequenceOfRegionAndSubregions

This type is used for clarity of definitions.

SequenceOfRegionAndSubregions ::= SEQUENCE OF RegionAndSubregions

ThreeDLocation

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, though the encoding is incompatible.

▼ThreeDLocation ::= SEQUENCE {

latitude Latitude,

longitude Longitude,

elevation Elevation

}

►ThreeDLocation ::= SEQUENCE {⋯}

Latitude

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.

Latitude ::= NinetyDegreeInt

Longitude

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.

Longitude ::= OneEightyDegreeInt

Elevation

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.

Elevation ::= Uint16

NinetyDegreeInt

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.

▼NinetyDegreeInt ::= INTEGER {

min (-900000000),

max (900000000),

unknown (900000001)

} (-900000000..900000001)

►NinetyDegreeInt ::= INTEGER {⋯} (-900000000..900000001)

KnownLatitude

The known latitudes are from -900,000,000 to +900,000,000 in 0.1 microdegree intervals.

KnownLatitude ::= NinetyDegreeInt (min..max)

UnknownLatitude

The value 900,000,001 indicates that the latitude was not available to the sender.

UnknownLatitude ::= NinetyDegreeInt (unknown)

OneEightyDegreeInt

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.

▼OneEightyDegreeInt ::= INTEGER {

min (-1799999999),

max (1800000000),

unknown (1800000001)

} (-1799999999..1800000001)

►OneEightyDegreeInt ::= INTEGER {⋯} (-1799999999..1800000001)

KnownLongitude

The known longitudes are from -1,799,999,999 to +1,800,000,000 in 0.1 microdegree intervals.

KnownLongitude ::= OneEightyDegreeInt (min..max)

UnknownLongitude

The value 1,800,000,001 indicates that the longitude was not available to the sender.

UnknownLongitude ::= OneEightyDegreeInt (unknown)

▼--***************************************************************************--

-- Crypto Structures --

--***************************************************************************--

Signature

This structure represents a signature for a supported public key algorithm. It may be contained within SignedData or Certificate.

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.

▼Signature ::= CHOICE {

ecdsaNistP256Signature EcdsaP256Signature,

ecdsaBrainpoolP256r1Signature EcdsaP256Signature,

...,

ecdsaBrainpoolP384r1Signature EcdsaP384Signature

}

►Signature ::= CHOICE {⋯}

EcdsaP256Signature

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.

Encoding considerations: If this structure is encoded for hashing, the EccP256CurvePoint in rSig shall be taken to be of 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 x-value should be checked to see if it lies between n and p and reduced 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:
  • p = FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF
  • n = FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551
Brainpoolp256:
  • p = A9FB57DBA1EEA9BC3E660A909D838D726E3BF623D52620282013481D1F6E5377
  • n = A9FB57DBA1EEA9BC3E660A909D838D718C397AA3B561A6F7901E0E82974856A7

▼EcdsaP256Signature ::= SEQUENCE {

rSig EccP256CurvePoint,

sSig OCTET STRING (SIZE (32))

}

►EcdsaP256Signature ::= SEQUENCE {⋯}

EcdsaP384Signature

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.

Encoding considerations: If this structure is encoded for hashing, the EccP256CurvePoint in rSig shall be taken to be of 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 x-value should be checked to see if it lies between n and p and reduced 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:
  • p = 8CB91E82A3386D280F5D6F7E50E641DF152F7109ED5456B412B1DA197FB71123 ACD3A729901D1A71874700133107EC53
  • n = 8CB91E82A3386D280F5D6F7E50E641DF152F7109ED5456B31F166E6CAC0425A7 CF3AB6AF6B7FC3103B883202E9046565

▼EcdsaP384Signature ::= SEQUENCE {

rSig EccP384CurvePoint,

sSig OCTET STRING (SIZE (48))

}

►EcdsaP384Signature ::= SEQUENCE {⋯}

EccP256CurvePoint

This structure specifies a point on an elliptic curve in Weierstrass form defined over a 256-bit prime number. This encompasses both NIST p256 as defined in FIPS 186-4 and Brainpool p256r1 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 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.

▼EccP256CurvePoint ::= CHOICE {

x-only OCTET STRING (SIZE (32)),

fill NULL,

compressed-y-0 OCTET STRING (SIZE (32)),

compressed-y-1 OCTET STRING (SIZE (32)),

▼ uncompressedP256 SEQUENCE {

x OCTET STRING (SIZE (32)),

y OCTET STRING (SIZE (32))

}

► uncompressedP256 SEQUENCE {⋯}

}

►EccP256CurvePoint ::= CHOICE {⋯}

EccP384CurvePoint

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.

▼EccP384CurvePoint ::= CHOICE {

x-only OCTET STRING (SIZE (48)),

fill NULL,

compressed-y-0 OCTET STRING (SIZE (48)),

compressed-y-1 OCTET STRING (SIZE (48)),

▼ uncompressedP384 SEQUENCE {

x OCTET STRING (SIZE (48)),

y OCTET STRING (SIZE (48))

}

► uncompressedP384 SEQUENCE {⋯}

}

►EccP384CurvePoint ::= CHOICE {⋯}

SymmAlgorithm

This enumerated value indicates supported symmetric algorithms. The only symmetric algorithm supported in this version of this standard is AES-CCM as specified in 5.3.7.

SymmAlgorithm ::= ENUMERATED {aes128Ccm, ...}

HashAlgorithm

This structure identifies a hash algorithm. The value is sha256, indicates SHA-256 as specified in 5.3.3. The value sha384 indicates SHA-384 as specified in 5.3.3.

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.

HashAlgorithm ::= ENUMERATED {sha256, ..., sha384}

EciesP256EncryptedKey

This data structure is used to transfer a 16-byte symmetric key encrypted using ECIES as specified in IEEE Std 1363a-2004.

Encryption and decryption are carried out as specified in 5.3.4.

In this structure:
  • v
    is the sender’s ephemeral public key, which is the output V from encryption as specified in 5.3.4.
  • c
    is the encrypted symmetric key, which is the output C from encryption as specified in 5.3.4. The algorithm for the symmetric key is identified by the CHOICE indicated in the following SymmetricCiphertext.
  • t
    is the authentication tag, which is the output tag from encryption as specified in 5.3.4.

▼EciesP256EncryptedKey ::= SEQUENCE {

v EccP256CurvePoint,

c OCTET STRING (SIZE (16)),

t OCTET STRING (SIZE (16))

}

►EciesP256EncryptedKey ::= SEQUENCE {⋯}

EncryptionKey

This structure contains an encryption key, which may be a public or a symmetric key.

▼EncryptionKey ::= CHOICE {

public PublicEncryptionKey,

symmetric SymmetricEncryptionKey

}

►EncryptionKey ::= CHOICE {⋯}

PublicEncryptionKey

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.

▼PublicEncryptionKey ::= SEQUENCE {

supportedSymmAlg SymmAlgorithm,

publicKey BasePublicEncryptionKey

}

►PublicEncryptionKey ::= SEQUENCE {⋯}

BasePublicEncryptionKey

This structure specifies the bytes of a public encryption key for a particular algorithm. The only algorithm supported is ECIES over either the NIST P256 or the Brainpool P256r1 curve as specified in 5.3.4.

▼BasePublicEncryptionKey ::= CHOICE {

eciesNistP256 EccP256CurvePoint,

eciesBrainpoolP256r1 EccP256CurvePoint,

...

}

►BasePublicEncryptionKey ::= CHOICE {⋯}

PublicVerificationKey

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.

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.

▼PublicVerificationKey ::= CHOICE {

ecdsaNistP256 EccP256CurvePoint,

ecdsaBrainpoolP256r1 EccP256CurvePoint,

...,

ecdsaBrainpoolP384r1 EccP384CurvePoint

}

►PublicVerificationKey ::= CHOICE {⋯}

SymmetricEncryptionKey

This structure provides the key bytes for use with an identified symmetric algorithm. The only supported symmetric algorithm is AES-128 in CCM mode as specified in 5.3.7.

▼SymmetricEncryptionKey ::= CHOICE {

aes128Ccm OCTET STRING (SIZE (16)),

...

}

►SymmetricEncryptionKey ::= CHOICE {⋯}

▼--***************************************************************************--

-- PSID / ITS-AID --

--***************************************************************************--

PsidSsp

This structure represents the permissions that the certificate holder has with respect to data for a single application area, identified by a Psid. If the ServiceSpecificPermissions field is omitted, it indicates that the certificate holder has the default permissions associated with that Psid.

Consistency with signed SPDU. As noted in 5.1.1, consistency between the SSP and the signed SPDU is defined by rules specific to the given PSID and is out of scope for this standard.

Consistency with issuing certificate.

If a certificate has an appPermissions entry A for which the ssp field is omitted, A is consistent with the issuing certificate if the issuing certificate contains a PsidSspRange P for which the following holds:
  • The psid field in P is equal to the psid field in A and one of the following is true:
    • The sspRange field in P indicates all.
    • The sspRange field in P indicates opaque and one of the entries in opaque is an OCTET STRING of length 0.
For consistency rules for other forms of the ssp field, see the following subclauses.

▼PsidSsp ::= SEQUENCE {

psid Psid,

ssp ServiceSpecificPermissions OPTIONAL

}

►PsidSsp ::= SEQUENCE {⋯}

SequenceOfPsidSsp

This type is used for clarity of definitions.

SequenceOfPsidSsp ::= SEQUENCE OF PsidSsp

Psid

This type represents the PSID defined in IEEE Std 1609.12.

Psid ::= INTEGER (0..MAX)

SequenceOfPsid

This type is used for clarity of definitions.

SequenceOfPsid ::= SEQUENCE OF Psid

ServiceSpecificPermissions

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.

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:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in A;
  • (OPTION 2) A PsidSspRange P for which the following holds:
    • The psid field in P is equal to the psid field in A and one of the following is true:
      • The sspRange field in P indicates all.
      • The sspRange field in P indicates opaque and one of the entries in the opaque field in P is an OCTET STRING identical to the opaque field in A.
For consistency rules for other types of ServiceSpecificPermissions, see the following subclauses.

▼ServiceSpecificPermissions ::= CHOICE {

opaque OCTET STRING (SIZE (0..MAX)),

...,

bitmapSsp BitmapSsp

}

►ServiceSpecificPermissions ::= CHOICE {⋯}

BitmapSsp

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.

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 issuing certificate contains one of the following:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in A;
  • (OPTION 2) A PsidSspRange P for which the following holds:
    • The psid field in P is equal to the psid field in A and one of the following is true:
      • EITHER The sspRange field in P indicates all
      • OR The sspRange field in P indicates bitmapSspRange and for every bit set to 1 in the sspBitmask in P, the bit in the identical position in the sspValue in A is set equal to the bit in that position in the sspValue in P.
NOTE: A BitmapSsp B is consistent with a BitmapSspRange R if for every bit set to 1 in the sspBitmask in R, the bit in the identical position in B is set equal to the bit in that position in the sspValue in R. For each bit set to 0 in the sspBitmask in R, the corresponding bit in the identical position in B may be freely set to 0 or 1, i.e., if a bit is set to 0 in the sspBitmask in R, the value of corresponding bit in the identical position in B has no bearing on whether B and R are consistent.

BitmapSsp ::= OCTET STRING (SIZE (0..31))

PsidSspRange

This structure represents the certificate issuing or requesting permissions of the certificate holder with respect to one particular set of application permissions. In this structure:
  • psid
    identifies the application area.
  • 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.

▼PsidSspRange ::= SEQUENCE {

psid Psid,

sspRange SspRange OPTIONAL

}

►PsidSspRange ::= SEQUENCE {⋯}

SequenceOfPsidSspRange

This type is used for clarity of definitions.

SequenceOfPsidSspRange ::= SEQUENCE OF PsidSspRange

SspRange

This structure identifies the SSPs associated with a PSID for which the holder may issue or request certificates.

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:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in A;
  • (OPTION 2) a PsidSspRange P for which the following holds:
    • The psid field in P is equal to the psid field in A and one of the following is true:
      • The sspRange field in P indicates all.
      • The sspRange field in P indicates opaque, and the sspRange field in A indicates opaque, and every OCTET STRING within the opaque in A is a duplicate of an OCTET STRING within the opaque in P.
If a certificate has a PsidSspRange A for which the ssp field is all, A is consistent with the issuing certificate if the issuing certificate contains a PsidSspRange P for which the following holds:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in A;
  • (OPTION 2) A PsidSspRange P for which the psid field in P is equal to the psid field in A and the sspRange field in P indicates all.
For consistency rules for other types of SspRange, see the following subclauses.

NOTE: The choice “all” may also be indicated by omitting the SspRange in the enclosing PsidSspRange structure. Omitting the SspRange is preferred to explicitly indicating “all”.

▼SspRange ::= CHOICE {

opaque SequenceOfOctetString,

all NULL,

...,

bitmapSspRange BitmapSspRange

}

►SspRange ::= CHOICE {⋯}

BitmapSspRange

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.

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:
  • (OPTION 1) A SubjectPermissions field indicating the choice all and no PsidSspRange field containing the psid field in P;
  • (OPTION 2) A PsidSspRange R for which the following holds:
    • The psid field in R is equal to the psid field in P and one of the following is true:
      • EITHER The sspRange field in R indicates all
      • OR The sspRange field in R indicates bitmapSspRange and for every bit set to 1 in the sspBitmask in R:
        • The bit in the identical position in the sspBitmask in P is set equal to 1, AND
        • The bit in the identical position in the sspValue in P is set equal to the bit in that position in the sspValue in R.

Reference ETSI TS 103 097 for more information on bitmask SSPs.

▼BitmapSspRange ::= SEQUENCE {

sspValue OCTET STRING (SIZE (1..32)),

sspBitmask OCTET STRING (SIZE (1..32))

}

►BitmapSspRange ::= SEQUENCE {⋯}

SequenceOfOctetString

This type is used for clarity of definitions.

SequenceOfOctetString ::= SEQUENCE (SIZE (0..MAX)) OF OCTET STRING (SIZE

(0..MAX))

▼--***************************************************************************--

-- Certificate Components --

--***************************************************************************--

SubjectAssurance

This field contains the certificate holder’s assurance level, which indicates the security of both the platform and storage of secret keys as well as the confidence in this assessment.

This field is encoded as defined in Table 1, where “A” denotes bit fields specifying an assurance level, “R” reserved bit fields, and “C” bit fields specifying the confidence.

Table 1: Bitwise encoding of subject assurance
Bit number 7 6 5 4 3 2 1 0
Interpretation A A A R R R C C
In Table 1, bit number 0 denotes the least significant bit. Bit 7 to bit 5 denote the device’s assurance levels, bit 4 to bit 2 are reserved for future use, and bit 1 and bit 0 denote the confidence.

The specification of these assurance levels as well as the encoding of the confidence levels is outside the scope of the present document. It can be assumed that a higher assurance value indicates that the holder is more trusted than the holder of a certificate with lower assurance value and the same confidence value.

NOTE: This field was originally specified in ETSI TS 103 097 and future uses of this field are anticipated to be consistent with future versions of that document.

SubjectAssurance ::= OCTET STRING (SIZE (1))

CrlSeries

This integer identifies a series of CRLs issued under the authority of a particular CRACA.

CrlSeries ::= Uint16

▼--***************************************************************************--

-- Pseudonym Linkage --

--***************************************************************************--

IValue

This atomic type is used in the definition of other data structures.

IValue ::= Uint16

Hostname

This is a UTF-8 string as defined in IETF RFC 3629. The contents are determined by policy.

Hostname ::= UTF8String (SIZE (0..255))

LinkageValue

This is the individual linkage value. See 5.1.3 and 7.3 for details of use.

LinkageValue ::= OCTET STRING (SIZE (9))

GroupLinkageValue

This is the group linkage value. See 5.1.3 and 7.3 for details of use.

▼GroupLinkageValue ::= SEQUENCE {

jValue OCTET STRING (SIZE (4)),

value OCTET STRING (SIZE (9))

}

►GroupLinkageValue ::= SEQUENCE {⋯}

LaId

This structure contains a LA Identifier for use in the algorithms specified in 5.1.3.4.

LaId ::= OCTET STRING (SIZE (2))

LinkageSeed

This structure contains a linkage seed value for use in the algorithms specified in 5.1.3.4.

LinkageSeed ::= OCTET STRING (SIZE (16))

END

HTML generated by OSS Nokalva's ASN1Doc utility