Documentation update

# ASN.1 module Ieee1609Dot2

 OID: _{iso(1) identified-organization(3) ieee(111) standards-association-numbered-series-standards(2) wave-stds(1609) dot2(2) base(1) schema(1) major-version-2(2) minor-version-6(6)}_

 OID: _{iso(1) identified-organization(3) ieee(111) standards-association-numbered-series-standards(2) wave-stds(1609) dot2(2) base(1) schema(1) major-version-2(2) minor-version-7(7)}_

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

   ToBeSignedData, concatenated with the hash of the omitted payload. The hash

   of the omitted payload is calculated with the same hash algorithm that is 

   used to calculate the hash of the data input for signing or verification. 

   The data input to the hash operation is simply the COER enocding of the 

   The data input to the hash operation is simply the COER encoding of the 

   ToBeSignedData, concatenated with the hash of the omitted payload: there is

   no additional wrapping or length indication. As noted in 5.2.4.3.4, the 

   means by which the signer and verifier establish the contents of the 

   omitted payload are out of scope for this standard.

   omitted payload are outside the scope of this standard.

 structure contains at least one of the optional elements, and may contain 

 more than one. See 5.2.4.3.4 for more details.

 The security profile in Annex C allows an implementation of this standard 

 to state which forms of Signed¬Data¬Payload are supported by that 

 to state which forms of SignedDataPayload are supported by that 

 implementation, and also how the signer and verifier are intended to obtain

 the external data for hashing. The specification of an SDEE that uses 

 external data is expected to be explicit and unambiguous about how this 

* omitted of type **NULL**  OPTIONAL<br>

  indicates that there is external data to be included in the

   hash calculation for the signature.The mechanism for including the external

  indicates that there is data to be included in the hash

   calculation for the signature that is not included in the SPDU, either in

   data or by use of the extDataHash. The mechanism for including the omitted

   data in the hash calculation is specified in 6.3.6.

```

### <a name="HeaderInfo"></a>HeaderInfo

This structure contains information that is used to establish

This structure contains the following information that is used to establish

 validity by the criteria of 5.2.

Fields:

 contributing organization. In this version of this standard two values are

 defined: 

   - ieee1609OriginatingExtensionId indicating extensions originating with 

 IEEE 1609.

 IEEE Std 1609.

   - etsiOriginatingExtensionId indicating extensions originating with 

 ETSI TC ITS.

```asn1

  If the choice indicated is certificate:

     - The structure contains one or more Certificate structures, in order

   such that the first certificate is the authorization certificate and each

   subsequent certificate is the issuer of the one before it.

   subsequent certificate is the issuer of the one before it. The certificate

   chain may be of any length. It should not include the root CA certificate

   (as the receiving SDS is assumed to know all valid root CAs already).

     - The verification type is certificate and the certificate data

   passed to the hash function as specified in 5.3.1 is the authorization

   certificate.

      tbsData (WITH COMPONENTS {..., 

        payload (WITH COMPONENTS {..., 

          data ABSENT,

          extDataHash PRESENT

          extDataHash PRESENT,

          omitted ABSENT

        }),

        headerInfo(WITH COMPONENTS {..., 

          generationTime PRESENT,

 selected if the EncryptedData was encrypted using the static encryption

 key approach specified in 5.3.4. The other options are selected if the

 EncryptedData was encrypted using the ephemeral encryption key approach

 specified in 5.3.4. The meanings of the choices are:

 See Annex C.7 for guidance on when it may be appropriate to use

 each of these approaches.

 specified in 5.3.4. The meanings of the choices are as follows:

Fields:

* pskRecipInfo of type [**PreSharedKeyRecipientInfo**](#PreSharedKeyRecipientInfo) <br>

See C.8 for guidance on when it may be appropriate to use each of these

 approaches.

>>>

NOTE: The material input to encryption is the bytes of the encryption key 

### <a name="TestCertificate"></a>TestCertificate

This structure is a profile of the structure CertificateBase which

This structure is a profile of the structure CertificateBase, which

 specifies the valid combinations of fields to transmit implicit and

 explicit certificates.

  is included in an ExplicitCertificate. It is the

   signature, calculated by the signer identified in the issuer field, over

   the hash of toBeSigned. The hash is calculated as specified in 5.3.1, where:

     - Data input is the encoding of toBeSigned following the COER.

     - Data input is the encoding of toBeSigned, canonicalized as described

   next.

     - Signer identifier input depends on the verification type, which in

   turn depends on the choice indicated by issuer. If the choice indicated by

   issuer is self, the verification type is self-signed and the signer

 following meaning:

 For both implicit and explicit certificates, when the certificate

 is hashed to create or recover the public key (in the case of an implicit

 certificate) or to generate or verify the signature (in the case of an

 explicit certificate), the hash is Hash (Data input) || Hash (

 Signer identifier input), where:

   - Data input is the COER encoding of toBeSigned, canonicalized

 as described above.

   - Signer identifier input depends on the verification type,

 which in turn depends on the choice indicated by issuer. If the choice

 indicated by issuer is self, the verification type is self-signed and the

 signer identifier input is the empty string. If the choice indicated by

 issuer is not self, the verification type is certificate and the signer

 identifier input is the COER encoding of the canonicalization per 6.4.3 of

 the certificate indicated by issuer.

 In other words, for implicit certificates, the value H (CertU) in SEC 4,

 section 3, is for purposes of this standard taken to be H [H

 (canonicalized ToBeSignedCertificate from the subordinate certificate) ||

* region of type [**GeographicRegion**](Ieee1609Dot2BaseTypes.md#GeographicRegion)  OPTIONAL<br>

  if present, indicates the validity region of the

   certificate. If it is omitted the validity region is indicated as follows:

     - If enclosing certificate is self-signed, i.e., the choice indicated

   certificate. If it is omitted the validity region is determined as follows:

     - If the enclosing certificate is self-signed, i.e., the choice indicated

   by the issuer field in the enclosing certificate structure is self, the

   certificate is valid worldwide.

     - Otherwise, the certificate has the same validity region as the

     ...,

* appExtensions of type [**SequenceOfAppExtensions**](#SequenceOfAppExtensions) <br>

* appExtensions of type [**SequenceOfAppExtensions**](#SequenceOfAppExtensions)  OPTIONAL<br>

  indicates additional permissions that may be applied

   to application activities that the certificate holder is carrying out. 

* certIssueExtensions of type [**SequenceOfCertIssueExtensions**](#SequenceOfCertIssueExtensions) <br>

* certIssueExtensions of type [**SequenceOfCertIssueExtensions**](#SequenceOfCertIssueExtensions)  OPTIONAL<br>

  indicates additional permissions to issue 

   certificates containing endEntityExtensions. 

   certificates containing appExtensions. 

* certRequestExtension of type [**SequenceOfCertRequestExtensions**](#SequenceOfCertRequestExtensions)  OPTIONAL<br>

The above algorithm is applied recursively, i.e. if region is omitted from

 the issuing certificate, then the issuing certificate of that certificate is

 inspected to determine if region is present, and so on. A certificate,

 therefore, has global geographic validity as defined in 5.2.6.6.3.1 if

 region is not present in the certificate or in any certificate in its chain.

 Otherwise, i.e., if region is present in the certificate or in at least one

 certificate in its chain, the certificate has area validity as defined in

 5.2.6.6.3.1.

 The use of the validity region to determine geographic consistency of an

 SPDU is specified in 5.2.6.6.3.1. The use of the validity region to

 determine geographic consistency of a subordinate certificate with an

 issuing certificate is specified in 5.1.2.4.

 If this field is present, at least one of the bits in the field shall be

 non-zero.

* certRequestExtension of type [**SequenceOfCertRequestExtensions**](#SequenceOfCertRequestExtensions) <br>

 If the PublicEncryptionKey contains a BasePublicEncryptionKey that is an 

 elliptic curve point (i.e., of type EccP256CurvePoint or EccP384CurvePoint),

  verifyKeyIndicator     VerificationKeyIndicator,

  ...,

  flags                  BIT STRING {usesCubk (0)} (SIZE (8)) OPTIONAL,

  appExtensions          SequenceOfAppExtensions,

  certIssueExtensions    SequenceOfCertIssueExtensions,

  certRequestExtension   SequenceOfCertRequestExtensions

  appExtensions          SequenceOfAppExtensions OPTIONAL,

  certIssueExtensions    SequenceOfCertIssueExtensions OPTIONAL,

  certRequestExtension   SequenceOfCertRequestExtensions OPTIONAL

}

(WITH COMPONENTS { ..., appPermissions PRESENT} |

 WITH COMPONENTS { ..., certIssuePermissions PRESENT} |

   Different instances of PsidGroupPermissions within a ToBeSignedCertificate

   may have different values for eeType.

     - If this field indicates app, the chain is allowed to end in an 

   authorization certificate, i.e., a certficate in which these permissions 

   authorization certificate, i.e., a certificate in which these permissions 

   appear in an appPermissions field (in other words, if the field does not 

   indicate app and the chain ends in an authorization certificate, the 

   chain shall be considered invalid).

     - If this field indicates enroll, the chain is allowed to end in an 

   enrollment certificate, i.e., a certificate in which these permissions 

   appear in a certReqPermissions permissions field (in other words, if the 

   appear in a certRequestPermissions permissions field (in other words, if the 

   field does not indicate enroll and the chain ends in an enrollment 

   certificate, the chain shall be considered invalid).

### <a name="Ieee1609HeaderInfoExtensions"></a>Ieee1609HeaderInfoExtensions

This is the ASN.1 Information Object Class that associates IEEE 

This is the ASN.1 Information Object Set that associates IEEE 

 1609 HeaderInfo contributed extensions with the appropriate 

 Ieee1609HeaderInfoExtensionId value.

 In this Information Object Set:

   - p2pcd8ByteLearningRequestId identifies that the extension is an 8-byte

 peer-to-peer certificate distribution request as specified in 8.4.2.

```asn1

Ieee1609HeaderInfoExtensions EXT-TYPE ::= {

  {HashedId8 IDENTIFIED BY p2pcd8ByteLearningRequestId},

### <a name="OperatingOrganizationId"></a>OperatingOrganizationId

This type is the AppExtension used to identify an operating 

 organization. The associated CertIssueExtension and CertRequestExtension 

 are both of type OperatingOrganizationId.

 To determine consistency between this type and an SPDU, the SDEE 

 specification for that SPDU is required to specify how the SPDU can be 

 used to determine an OBJECT IDENTIFIER (for example, by including the 

 full OBJECT IDENTIFIER in the SPDU, or by including a RELATIVE-OID with 

 clear instructions about how a full OBJECT IDENTIFIER can be obtained from

 the RELATIVE-OID). The SPDU is then consistent with this type if the 

 OBJECT IDENTIFIER determined from the SPDU is identical to the OBJECT 

 organization. See 5.2.6.6.7.2 for discussion of how the

 OperatingOrganizationId can be integrated into the SPDU payload by an

 SDEE specifier.

 A certificate may have an OperatingOrganizationId associated with it even if

 the certificate does not contain an OperatingOrganizationId field. If the

 certificate does not contain an OperatingOrganizationId field, the

 associated OperatingOrganizationId is determined as follows:

   - If the certificate is self-signed, that is, the choice indicated by the

 issuer field in the enclosing certificate structure is self, the

 certificate has no OperatingOrganizationId associated with it.

   -  Otherwise, the certificate has the same OperatingOrganizationId as

 the certificate that issued it.

 The above algorithm is applied recursively, i.e. if

 OperatingOrganizationId is omitted from the issuing certificate, then

 the issuing certificate of that certificate is inspected to determine if

 OperatingOrganizationId is present, and so on.

 Consistency with SPDU payload. As discussed in 5.2.6.6.7.2, the SPDU payload

 design might or might not include OperatingOrganizationId material. 

 If OperatingOrganizationId material appears in the SPDU payload, then the

 SDEE specification is expected to state that consistency is required between

 the payload and the certificate (although, as discussed in 5.2.6.6.7.2, this

 approach is not recommended).

 If consistency is required between the OperatingOrganizationID

 and operating organization information represented by an OBJECT

 IDENTIFIER in the SPDU payload, then the SDEE specification for that SPDU is

 required to specify how the SPDU can be used to determine an OBJECT

 IDENTIFIER of the same length as the OperatingOrganizationId in the

 certificate (e.g., by including the full OBJECT IDENTIFIER in the SPDU, or

 by including a RELATIVE-OID with clear instructions about how a full OBJECT

 IDENTIFIER can be obtained from the RELATIVE-OID, or by truncating an

 OBJECT IDENTIFIER from the message to be the same length as the OBJECT

 IDENTIFIER in the certificate). The SPDU is then consistent with this type

 if the OBJECT IDENTIFIER determined from the SPDU is identical to the OBJECT

 IDENTIFIER contained in this field.

 This AppExtension does not have consistency conditions with a 

 corresponding CertIssueExtension. It can appear in a certificate issued 

 by any CA.

 Consistency with issuing certificate. This AppExtension does not have

 consistency conditions with a corresponding CertIssueExtension. It can

 appear in a certificate issued by any CA.

 Consistency with certificate request signing certificate. This AppExtension

 does not have consistency conditions with a corresponding

 CertRequestExtension. It can appear in a certificate request signed by any

 certificate containing certRequestPermissions, i.e. by any enrollment

 certificate.

```asn1

OperatingOrganizationId ::= OBJECT IDENTIFIER

```

This Information Object is an instance of the Information Object 

 Class CERT-EXT-TYPE. It is defined to bind together the AppExtension, 

 CertIssueExtension, and CertRequestExtension types associated with the 

 use of an operating organization identifier, and to assocaute them all 

 with the extension identifier value certExtId-OperatingOrganization.

This Information Object Set is a collection of Information Objects 

 used to contain the AppExtension, CertIssueExtension, and 

 CertRequestExtension types associated with a specific use of certificate 

# ASN.1 module Ieee1609Dot2BaseTypes

 OID: _{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) minor-version-4(4)}_

 OID: _{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) minor-version-5(5)}_

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

### <a name="Time32"></a>Time32

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

 January, 2004.

 January 2004.

```asn1

Time32 ::= Uint32

```

### <a name="Time64"></a>Time64

This data structure is a 64-bit integer giving an estimate of the 

 number of (TAI) microseconds since 00:00:00 UTC, 1 January, 2004.

 number of (TAI) microseconds since 00:00:00 UTC, 1 January 2004.

```asn1

Time64 ::= Uint64

```

 Implementation Conformance Statement (PICS) provided in Annex A allows 

 an implementation to state which UnCountryId values it recognizes and 

 which region values are recognized within that country.

 If a verifying implementation is required to check that an relevant 

 If a verifying implementation is required to check that relevant 

 geographic information in a signed SPDU is consistent with a certificate 

 containing one or more instances of this type, then the SDS is permitted 

 to indicate that the signed SPDU is valid even if some values of country 

 (PICS) provided in Annex A allows an implementation to state which 

 UnCountryId values it recognizes and which region values are recognized 

 within that country.

 If a verifying implementation is required to check that an relevant 

 If a verifying implementation is required to check that relevant 

 geographic information in a signed SPDU is consistent with a certificate 

 containing one or more instances of this type, then the SDS is permitted 

 to indicate that the signed SPDU is valid even if some values of country 

 to as the "enclosing country". If this structure is used in a 

 CountryAndSubregions structure, the enclosing country is the one indicated 

 by the country field in the CountryAndSubregions structure. If other uses 

 are defined for this structure in future, it is expected that that 

 definition will include a specification of how the enclosing country can 

 be determined.

 are defined for this structure in the future, it is anticipated (in the

 sense of 4.4) that that definition will include a specification of how the

 enclosing country can be determined.

 If the enclosing country is the United States of America:

 - The region field identifies the state or statistically equivalent 

 entity using the integer version of the 2010 FIPS codes as provided by the

 geographic information. Informally, if the recognized values in the 

 certificate allow the SDS to determine that the SPDU is valid, then it 

 can make that determination even if there are also unrecognized values 

 in the certificate. This field is therefore not not a "critical 

 in the certificate. This field is therefore not a "critical 

 information field" as defined in 5.2.6, because unrecognized values are 

 permitted so long as the validity of the SPDU can be established with the 

 recognized values. However, as discussed in 5.2.6, the presence of an 

```

### <a name="ThreeDLocation"></a>ThreeDLocation

This structure contains an estimate of 3D location. The details of

 the structure are given in the definitions of the individual fields below.

This structure contains an estimate of 3D location.

Fields:

* latitude of type [**Latitude**](#Latitude) <br>

 generated as specified in 5.3.1.

 If the signature process followed the specification of FIPS 186-4

 If the signature process followed the specification of FIPS 186-5

 and output the integer r, r is represented as an EccP256CurvePoint

 indicating the selection 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

 prime defining the finite field. In principle, this means that to convert a

 signature from form compressed-y-\* to form x-only, the converter checks 

 the x-value to see if it lies between n and p and reduces it mod n if so. 

 In practice this check is unnecessary: Haase's Theorem states that 

 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<sup>(-128)</sup>. For the 

 generated as specified in 5.3.1.

 If the signature process followed the specification of FIPS 186-4

 If the signature process followed the specification of FIPS 186-5

 and output the integer r, r is represented as an EccP384CurvePoint

 indicating the selection 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 

 prime defining the finite field. In principle, this means that to convert a 

 signature from form compressed-y-* to form x-only, the converter checks the

 x-value to see if it lies between n and p and reduces it mod n if so. In

 practice this check is unnecessary: Haase's Theorem states that difference

 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<sup>(-192)</sup>. For the 384-bit curve

### <a name="EccP256CurvePoint"></a>EccP256CurvePoint

This structure specifies a point on an elliptic curve in Weierstrass

 form defined over a 256-bit prime number. The curves supported in this

 standard are NIST p256 as defined in FIPS 186-4, Brainpool p256r1 as

 standard are NIST p256 as defined in FIPS 186-5, Brainpool p256r1 as

 defined in RFC 5639, and the SM2 curve as defined in GB/T 32918.5-2017.

 The fields in this structure are OCTET STRINGS produced with the elliptic

 curve point encoding and decoding methods defined in subclause 5.5.6 of

 PSID-specific.

>>>

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.

NOTE: Where a BitmapSsp in an authorization certificate is being compared

 with a BitmapSspRange in an issuing certificate, the rules given above imply

 that the BitmapSsp: (a) cannot be longer than BitmapSspRange in the issuing

 cert; (b) Can be shorter than the BitmapSspRange but must be long enough to

 reach the last "1" bit in the sspBitmask.

>>>

```asn1

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

 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

 encoding of the confidence levels is outside the scope of this

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

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

>>>