Ieee1609Dot2.md

# 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)}_
 @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.
 

## Imports:
 * **[Ieee1609Dot2BaseTypes](Ieee1609Dot2BaseTypes.md)** *{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)}*<br/>
  
 * **[EtsiTs103097ExtensionModule](EtsiTs103097ExtensionModule.md)** *{itu-t(0) identified-organization(4) etsi(0) itsDomain(5) wg5(5) secHeaders(103097) extension(2) major-version-1(1) minor-version-1(1)}*<br/>
  
## Data Elements:
### <a name="Ieee1609Dot2Data"></a>Ieee1609Dot2Data
This data type is used to contain the other data types in this
 clause. The fields in the Ieee1609Dot2Data have the following meanings:

Fields:
* protocolVersion of type [**Uint8**](Ieee1609Dot2BaseTypes.md#Uint8) (3)<br>
  contains the current version of the protocol. The
   version specified in this standard is version 3, represented by the
   integer 3. There are no major or minor version numbers.


* content of type [**Ieee1609Dot2Content**](#Ieee1609Dot2Content) <br>
  contains the content in the form of an Ieee1609Dot2Content.


   

>>>
NOTE:&emsp;Canonicalization: This data structure is subject to canonicalization
 for the relevant operations specified in 6.1.2. The canonicalization 
 applies to the Ieee1609Dot2Content.
>>>
```asn1
Ieee1609Dot2Data ::= SEQUENCE {
  protocolVersion Uint8(3),
  content         Ieee1609Dot2Content
}
```

### <a name="Ieee1609Dot2Content"></a>Ieee1609Dot2Content
In this structure:

Fields:
* unsecuredData of type [**Opaque**](Ieee1609Dot2BaseTypes.md#Opaque) <br>
  indicates that the content is an OCTET STRING to be
   consumed outside the SDS.


* signedData of type [**SignedData**](#SignedData) <br>
  indicates that the content has been signed according to
   this standard.


    
* encryptedData of type [**EncryptedData**](#EncryptedData) <br>
  indicates that the content has been encrypted
   according to this standard.


   
* signedCertificateRequest of type [**Opaque**](Ieee1609Dot2BaseTypes.md#Opaque) <br>
  indicates that the content is a 
   certificate request signed by an IEEE 1609.2 certificate or self-signed.


   
* signedX509CertificateRequest of type [**Opaque**](Ieee1609Dot2BaseTypes.md#Opaque) <br>
  indicates that the content is a 
   certificate request signed by an ITU-T X.509 certificate.


   
     ...,

>>>
NOTE:&emsp;Canonicalization: This data structure is subject to canonicalization 
 for the relevant operations specified in 6.1.2 if it is of type signedData.
 The canonicalization applies to the SignedData.
>>>
```asn1
Ieee1609Dot2Content ::=  CHOICE { 
  unsecuredData                Opaque, 
  signedData                   SignedData,
  encryptedData                EncryptedData,
  signedCertificateRequest     Opaque,
  ...,
  signedX509CertificateRequest Opaque
}
```

### <a name="SignedData"></a>SignedData
In this structure:

Fields:
* hashId of type [**HashAlgorithm**](Ieee1609Dot2BaseTypes.md#HashAlgorithm) <br>
  indicates the hash algorithm to be used to generate the hash
   of the message for signing and verification.


* tbsData of type [**ToBeSignedData**](#ToBeSignedData) <br>
  contains the data that is hashed as input to the signature.


   
* signer of type [**SignerIdentifier**](#SignerIdentifier) <br>
  determines the keying material and hash algorithm used to
   sign the data.


   
* signature of type [**Signature**](Ieee1609Dot2BaseTypes.md#Signature) <br>
  contains the digital signature itself, calculated as
   specified in 5.3.1.
     - If signer indicates the choice self, then the signature calculation
   is parameterized as follows:
       - Data input is equal to the COER encoding of the tbsData field
   canonicalized according to the encoding considerations given in 6.3.6.
       - Verification type is equal to self.
       - Signer identifier input is equal to the empty string.
     - If signer indicates certificate or digest, then the signature
   calculation is parameterized as follows:
       - Data input is equal to the COER encoding of the tbsData field
   canonicalized according to the encoding considerations given in 6.3.6.
       - Verification type is equal to certificate.
       - Signer identifier input equal to the COER-encoding of the
   Certificate that is to be used to verify the SPDU, canonicalized according
   to the encoding considerations given in 6.4.3.


   

>>>
NOTE:&emsp;Canonicalization: This data structure is subject to canonicalization 
 for the relevant operations specified in 6.1.2. The canonicalization 
 applies to the ToBeSignedData and the Signature.
>>>
```asn1
SignedData ::= SEQUENCE { 
  hashId    HashAlgorithm,
  tbsData   ToBeSignedData,
  signer    SignerIdentifier,
  signature Signature
}
```

### <a name="ToBeSignedData"></a>ToBeSignedData
This structure contains the data to be hashed when generating or
 verifying a signature. See 6.3.4 for the specification of the input to the
 hash.

Fields:
* payload of type [**SignedDataPayload**](#SignedDataPayload) <br>
  contains data that is provided by the entity that invokes
   the SDS.


* headerInfo of type [**HeaderInfo**](#HeaderInfo) <br>
  contains additional data that is inserted by the SDS.
   This structure is used as follows to determine the "data input" to the 
   hash operation for signing or verification as specified in 5.3.1.2.2 or 
   5.3.1.3.
     - If payload does not contain the field omitted, the data input to the 
   hash operation is the COER encoding of the ToBeSignedData. 
     - If payload field in this ToBeSignedData instance contains the field 
   omitted, the data input to the hash operation is the COER encoding of the
   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 
   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.


   

>>>
NOTE:&emsp;Canonicalization: This data structure is subject to canonicalization 
 for the relevant operations specified in 6.1.2. The canonicalization 
 applies to the SignedDataPayload if it is of type data, and to the 
 HeaderInfo.
>>>
```asn1
ToBeSignedData ::= SEQUENCE { 
  payload    SignedDataPayload,
  headerInfo HeaderInfo
}
```

### <a name="SignedDataPayload"></a>SignedDataPayload
This structure contains the data payload of a ToBeSignedData. This 
 structure contains at least one of the optional elements, and may contain 
 more than one. See 5.2.4.3.4 for more details.
 The security profile in Annex C allows an implementation of this standard 
 to state which forms of Signed�Data�Payload are supported by that 
 implementation, and also how the signer and verifier are intended to obtain
 the external data for hashing. The specification of an SDEE that uses 
 external data is expected to be explicit and unambiguous about how this 
 data is obtained and how it is formatted prior to processing by the hash 
 function.

Fields:
* data of type [**Ieee1609Dot2Data**](#Ieee1609Dot2Data)  OPTIONAL<br>
  contains data that is explicitly transported within the
   structure.


* extDataHash of type [**HashedData**](#HashedData)  OPTIONAL<br>
  contains the hash of data that is not explicitly 
   transported within the structure, and which the creator of the structure 
   wishes to cryptographically bind to the signature. 


   
* 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
   data in the hash calculation is specified in 6.3.6.


   
     ...,

>>>
NOTE:&emsp;Canonicalization: This data structure is subject to canonicalization 
 for the relevant operations specified in 6.1.2. The canonicalization 
 applies to the Ieee1609Dot2Data.
>>>
```asn1
SignedDataPayload ::= SEQUENCE { 
  data        Ieee1609Dot2Data OPTIONAL,
  extDataHash HashedData OPTIONAL,
  ...,
  omitted     NULL OPTIONAL
} (WITH COMPONENTS {..., data PRESENT} |
   WITH COMPONENTS {..., extDataHash PRESENT} |
   WITH COMPONENTS {..., omitted PRESENT})
```

### <a name="HashedData"></a>HashedData
This structure contains the hash of some data with a specified hash
 algorithm. See 5.3.3 for specification of the permitted hash algorithms.

Fields:
* sha256HashedData of type [**HashedId32**](Ieee1609Dot2BaseTypes.md#HashedId32) <br>
  indicates data hashed with SHA-256.


* sha384HashedData of type [**HashedId48**](Ieee1609Dot2BaseTypes.md#HashedId48) <br>
  indicates data hashed with SHA-384.


   
     ...,
* sm3HashedData of type [**HashedId32**](Ieee1609Dot2BaseTypes.md#HashedId32) <br>
  indicates data hashed with SM3.


   

>>>
NOTE:&emsp;Critical information fields: If present, this is a critical 
 information field as defined in 5.2.6. An implementation that does not 
 recognize the indicated CHOICE for this type when verifying a signed SPDU 
 shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, 
 that is, it is invalid in the sense that its validity cannot be established.
>>>
```asn1
HashedData::= CHOICE { 
  sha256HashedData HashedId32,
  ...,
  sha384HashedData HashedId48,
  sm3HashedData    HashedId32
}
```

### <a name="HeaderInfo"></a>HeaderInfo
This structure contains information that is used to establish
 validity by the criteria of 5.2.

Fields:
* psid of type [**Psid**](Ieee1609Dot2BaseTypes.md#Psid) <br>
  indicates the application area with which the sender is
   claiming the payload is to be associated.


* generationTime of type [**Time64**](Ieee1609Dot2BaseTypes.md#Time64)  OPTIONAL<br>
  indicates the time at which the structure was
   generated. See 5.2.5.2.2 and 5.2.5.2.3 for discussion of the use of this
   field.


   
* expiryTime of type [**Time64**](Ieee1609Dot2BaseTypes.md#Time64)  OPTIONAL<br>
  if present, contains the time after which the data
   is no longer considered relevant. If both generationTime and
   expiryTime are present, the signed SPDU is invalid if generationTime is
   not strictly earlier than expiryTime.


   
* generationLocation of type [**ThreeDLocation**](Ieee1609Dot2BaseTypes.md#ThreeDLocation)  OPTIONAL<br>
  if present, contains the location at which the
   signature was generated.


   
* p2pcdLearningRequest of type [**HashedId3**](Ieee1609Dot2BaseTypes.md#HashedId3)  OPTIONAL<br>
  if present, is used by the SDS to request 
   certificates for which it has seen identifiers and does not know the 
   entire certificate. A specification of this peer-to-peer certificate 
   distribution (P2PCD) mechanism is given in Clause 8. This field is used 
   for the separate-certificate-pdu flavor of P2PCD and shall only be present 
   if inlineP2pcdRequest is not present. The HashedId3 is calculated with the 
   whole-certificate hash algorithm, determined as described in 6.4.3, 
   applied to the COER-encoded certificate, canonicalized as defined in the 
   definition of Certificate.


   
* missingCrlIdentifier of type [**MissingCrlIdentifier**](#MissingCrlIdentifier)  OPTIONAL<br>
  if present, is used by the SDS to request
   CRLs which it knows to have been issued and have not received. This is
   provided for future use and the associated mechanism is not defined in
   this version of this standard.


   
* encryptionKey of type [**EncryptionKey**](Ieee1609Dot2BaseTypes.md#EncryptionKey)  OPTIONAL<br>
  if present, is used to provide a key that is to 
   be used to encrypt at least one response to this SPDU. The SDEE 
   specification is expected to specify which response SPDUs are to be 
   encrypted with this key. One possible use of this key to encrypt a 
   response is specified in 6.3.35, 6.3.37, and 6.3.34. An encryptionKey 
   field of type symmetric should only be used if the SignedData containing 
   this field is securely encrypted by some means.


   
* inlineP2pcdRequest of type [**SequenceOfHashedId3**](Ieee1609Dot2BaseTypes.md#SequenceOfHashedId3)  OPTIONAL<br>
  if present, is used by the SDS to request
   unknown certificates per the inline peer-to-peer certificate distribution
   mechanism is given in Clause 8. This field shall only be present if
   p2pcdLearningRequest is not present. The HashedId3 is calculated with the
   whole-certificate hash algorithm, determined as described in 6.4.3, applied
   to the COER-encoded certificate, canonicalized as defined in the definition
   of Certificate.


   
     ...,
* requestedCertificate of type [**Certificate**](#Certificate)  OPTIONAL<br>
  if present, is used by the SDS to provide
   certificates per the "inline" version of the peer-to-peer certificate
   distribution mechanism given in Clause 8.


   
* pduFunctionalType of type [**PduFunctionalType**](#PduFunctionalType)  OPTIONAL<br>
  if present, is used to indicate that the SPDU is
   to be consumed by a process other than an application process as defined
   in ISO 21177 [B14a]. See 6.3.23b for more details.


   
* contributedExtensions of type [**ContributedExtensionBlocks**](#ContributedExtensionBlocks)  OPTIONAL<br>
  if present, is used to contain additional 
   extensions defined using the ContributedExtensionBlocks structure.


   

>>>
NOTE:&emsp;Canonicalization: This data structure is subject to canonicalization 
 for the relevant operations specified in 6.1.2. The canonicalization
 applies to the EncryptionKey. If encryptionKey is present, and indicates
 the choice public, and contains a BasePublicEncryptionKey that is an
 elliptic curve point (i.e., of type EccP256CurvePoint or 
 EccP384CurvePoint), then the elliptic curve point is encoded in compressed
 form, i.e., such that the choice indicated within the Ecc*CurvePoint is
 compressed-y-0 or compressed-y-1.
 The canonicalization does not apply to any fields after the extension 
 marker, including any fields in contributedExtensions.
>>>
```asn1
HeaderInfo ::= SEQUENCE { 
  psid                  Psid,
  generationTime        Time64 OPTIONAL,
  expiryTime            Time64 OPTIONAL,
  generationLocation    ThreeDLocation OPTIONAL,
  p2pcdLearningRequest  HashedId3 OPTIONAL,
  missingCrlIdentifier  MissingCrlIdentifier OPTIONAL,
  encryptionKey         EncryptionKey OPTIONAL,
  ...,
  inlineP2pcdRequest    SequenceOfHashedId3 OPTIONAL,
  requestedCertificate  Certificate OPTIONAL,
  pduFunctionalType     PduFunctionalType OPTIONAL,
  contributedExtensions ContributedExtensionBlocks OPTIONAL
}
```

### <a name="MissingCrlIdentifier"></a>MissingCrlIdentifier
This structure may be used to request a CRL that the SSME knows to
 have been issued and has not yet received. It is provided for future use
 and its use is not defined in this version of this standard.

Fields:
* cracaId of type [**HashedId3**](Ieee1609Dot2BaseTypes.md#HashedId3) <br>
  is the HashedId3 of the CRACA, as defined in 5.1.3. The 
   HashedId3 is calculated with the whole-certificate hash algorithm, 
   determined as described in 6.4.3, applied to the COER-encoded certificate,
   canonicalized as defined in the definition of Certificate.


* crlSeries of type [**CrlSeries**](Ieee1609Dot2BaseTypes.md#CrlSeries) <br>
  is the requested CRL Series value. See 5.1.3 for more
   information.
   


   
```asn1
MissingCrlIdentifier ::= SEQUENCE { 
  cracaId   HashedId3,
  crlSeries CrlSeries,
  ...
}
```


### <a name="PduFunctionalType"></a>PduFunctionalType
This data structure identifies the functional entity that is 
 intended to consume an SPDU, for the case where that functional entity is 
 not an application process, and are instead security support services for an
 application process. Further details and the intended use of this field are 
 defined in ISO 21177 [B20].
```asn1
PduFunctionalType ::= INTEGER (0..255)
```

```asn1
tlsHandshake             PduFunctionalType ::= 1
iso21177ExtendedAuth     PduFunctionalType ::= 2
iso21177SessionExtension PduFunctionalType ::= 3
```


### <a name="ContributedExtensionBlocks"></a>ContributedExtensionBlocks
This type is used for clarity of definitions.
```asn1
ContributedExtensionBlocks ::= SEQUENCE (SIZE(1..MAX)) OF
  ContributedExtensionBlock
```

### <a name="ContributedExtensionBlock"></a>ContributedExtensionBlock
This data structure defines the format of an extension block
 provided by an identified contributor by using the temnplate provided
 in the class IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION constraint
 to the objects in the set Ieee1609Dot2HeaderInfoContributedExtensions.

Fields:
* contributorId of type [**IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION**](#IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION) .&id({
    Ieee1609Dot2HeaderInfoContributedExtensions
  })<br>
  uniquely identifies the contributor.


* extns of type **SEQUENCE**  (SIZE(1..MAX)) OF<br>
  contains a list of extensions from that contributor. 
   Extensions are expected and not required to follow the format specified 
   in 6.5.
   


   
```asn1
ContributedExtensionBlock ::= SEQUENCE {
  contributorId IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION.&id({
    Ieee1609Dot2HeaderInfoContributedExtensions
  }),
  extns         SEQUENCE (SIZE(1..MAX)) OF
    IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION.&Extn({
    Ieee1609Dot2HeaderInfoContributedExtensions
  }{@.contributorId})
}
```

### <a name="IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION"></a>IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION
This Information Object Class defines the class that provides a 
 template for defining extension blocks.

Fields:
* id of type [**HeaderInfoContributorId**](#HeaderInfoContributorId)  UNIQUE<br>
```asn1
IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION ::= CLASS {
  &id   HeaderInfoContributorId UNIQUE,
  &Extn
} WITH SYNTAX {&Extn IDENTIFIED BY &id}
```


### <a name="Ieee1609Dot2HeaderInfoContributedExtensions"></a>Ieee1609Dot2HeaderInfoContributedExtensions
This structure is an ASN.1 Information Object Set listing the 
 defined contributed extension types and the associated 
 HeaderInfoContributorId values. In this version of this standard two 
 extension types are defined: Ieee1609ContributedHeaderInfoExtension and 
 EtsiOriginatingHeaderInfoExtension.
```asn1
Ieee1609Dot2HeaderInfoContributedExtensions
  IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION ::= {
  {Ieee1609ContributedHeaderInfoExtension IDENTIFIED BY 
        ieee1609HeaderInfoContributorId} |
  {EtsiOriginatingHeaderInfoExtension IDENTIFIED BY
    etsiHeaderInfoContributorId},
  ...
}
```


### <a name="HeaderInfoContributorId"></a>HeaderInfoContributorId
This is an integer used to identify a HeaderInfo extension
 contributing organization. In this version of this standard two values are
 defined: 
   - ieee1609OriginatingExtensionId indicating extensions originating with 
 IEEE 1609.
   - etsiOriginatingExtensionId indicating extensions originating with 
 ETSI TC ITS.
```asn1
HeaderInfoContributorId ::= INTEGER (0..255)
```

```asn1
ieee1609HeaderInfoContributorId HeaderInfoContributorId ::= 1
etsiHeaderInfoContributorId     HeaderInfoContributorId ::= 2
```

### <a name="SignerIdentifier"></a>SignerIdentifier
This structure allows the recipient of data to determine which
 keying material to use to authenticate the data. It also indicates the
 verification type to be used to generate the hash for verification, as
 specified in 5.3.1.

Fields:
* digest of type [**HashedId8**](Ieee1609Dot2BaseTypes.md#HashedId8) <br>
  If the choice indicated is digest:
     - The structure contains the HashedId8 of the relevant certificate. The
   HashedId8 is calculated with the whole-certificate hash algorithm,
   determined as described in 6.4.3.
     - The verification type is certificate and the certificate data
   passed to the hash function as specified in 5.3.1 is the authorization
   certificate.


* certificate of type [**SequenceOfCertificate**](#SequenceOfCertificate) <br>
  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.
     - The verification type is certificate and the certificate data
   passed to the hash function as specified in 5.3.1 is the authorization
   certificate.


   
* self of type **NULL** <br>
  If the choice indicated is self:
     - The structure does not contain any data beyond the indication that
   the choice value is self.
     - The verification type is self-signed.


   

>>>
NOTE:&emsp;Canonicalization: This data structure is subject to canonicalization
 for the relevant operations specified in 6.1.2. The canonicalization 
 applies to every Certificate in the certificate field.
>>>
```asn1
SignerIdentifier ::= CHOICE { 
  digest      HashedId8,
  certificate SequenceOfCertificate,
  self        NULL,
  ...
}
```


### <a name="Countersignature"></a>Countersignature
This data structure is used to perform a countersignature over an
 already-signed SPDU. This is the profile of an Ieee1609Dot2Data containing
 a signedData. The tbsData within content is composed of a payload
 containing the hash (extDataHash) of the externally generated, pre-signed
 SPDU over which the countersignature is performed.
```asn1
Countersignature ::= Ieee1609Dot2Data (WITH COMPONENTS {...,
  content (WITH COMPONENTS {..., 
    signedData  (WITH COMPONENTS {..., 
      tbsData (WITH COMPONENTS {..., 
        payload (WITH COMPONENTS {..., 
          data ABSENT,
          extDataHash PRESENT
        }),
        headerInfo(WITH COMPONENTS {..., 
          generationTime PRESENT,
          expiryTime ABSENT,
          generationLocation ABSENT,
          p2pcdLearningRequest ABSENT,
          missingCrlIdentifier ABSENT,
          encryptionKey ABSENT
        })
      })
    })
  })
})
```

### <a name="EncryptedData"></a>EncryptedData
This data structure encodes data that has been encrypted to one or 
 more recipients using the recipients� public or symmetric keys as 
 specified in 5.3.4.

Fields:
* recipients of type [**SequenceOfRecipientInfo**](#SequenceOfRecipientInfo) <br>
  contains one or more RecipientInfos. These entries may
   be more than one RecipientInfo, and more than one type of RecipientInfo,
   as long as all entries are indicating or containing the same data encryption
   key.


* ciphertext of type [**SymmetricCiphertext**](#SymmetricCiphertext) <br>
  contains the encrypted data. This is the encryption of
   an encoded Ieee1609Dot2Data structure as specified in 5.3.4.2.


   

>>>
NOTE:&emsp;If the plaintext is raw data, i.e., it has not been output from a 
 previous operation of the SDS, then it is trivial to encapsulate it in an
 Ieee1609Dot2Data of type unsecuredData as noted in 4.2.2.2.2. For example,
 '03 80 08 01 23 45 67 89 AB CD EF' is the C-OER encoding of '01 23 45 67 
 89 AB CD EF' encapsulated in an Ieee1609Dot2Data of type unsecuredData. 
 The first byte of the encoding 03 is the protocolVersion, the second byte 
 80 indicates the choice unsecuredData, and the third byte 08 is the length 
 of the raw data '01 23 45 67 89 AB CD EF'.
>>>
```asn1
EncryptedData ::= SEQUENCE {
  recipients SequenceOfRecipientInfo,
  ciphertext SymmetricCiphertext
}
```

### <a name="RecipientInfo"></a>RecipientInfo
This data structure is used to transfer the data encryption key to
 an individual recipient of an EncryptedData. The option pskRecipInfo is
 selected if the EncryptedData was encrypted using the static encryption
 key approach specified in 5.3.4. The other options are selected if the
 EncryptedData was encrypted using the ephemeral encryption key approach
 specified in 5.3.4. The meanings of the choices are:


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

Fields:
* pskRecipInfo of type [**PreSharedKeyRecipientInfo**](#PreSharedKeyRecipientInfo) <br>
  The data was encrypted directly using a pre-shared 
   symmetric key.


* symmRecipInfo of type [**SymmRecipientInfo**](#SymmRecipientInfo) <br>
  The data was encrypted with a data encryption key,
   and the data encryption key was encrypted using a symmetric key.


   
* certRecipInfo of type [**PKRecipientInfo**](#PKRecipientInfo) <br>
  The data was encrypted with a data encryption key, 
   the data encryption key was encrypted using a public key encryption scheme,
   where the public encryption key was obtained from a certificate. In this 
   case, the parameter P1 to ECIES as defined in 5.3.5 is the hash of the 
   certificate, calculated with the whole-certificate hash algorithm, 
   determined as described in 6.4.3, applied to the COER-encoded certificate, 
   canonicalized as defined in the definition of Certificate.


   
* signedDataRecipInfo of type [**PKRecipientInfo**](#PKRecipientInfo) <br>
  The data was encrypted with a data encryption 
   key, the data encryption key was encrypted using a public key encryption 
   scheme, where the public encryption key was obtained as the public response 
   encryption key from a SignedData. In this case, if ECIES is the encryption 
   algorithm, then the parameter P1 to ECIES as defined in 5.3.5 is the 
   SHA-256 hash of the Ieee1609Dot2Data of type signedData containing the 
   response encryption key, canonicalized as defined in the definition of 
   Ieee1609Dot2Data.


    
* rekRecipInfo of type [**PKRecipientInfo**](#PKRecipientInfo) <br>
  The data was encrypted with a data encryption key, 
   the data encryption key was encrypted using a public key encryption scheme,
   where the public encryption key was not obtained from a Signed-Data or a 
   certificate. In this case, the SDEE specification is expected to specify 
   how the public key is obtained, and if ECIES is the encryption algorithm, 
   then the parameter P1 to ECIES as defined in 5.3.5 is the hash of the 
   empty string.


    

>>>
NOTE:&emsp;The material input to encryption is the bytes of the encryption key 
 with no headers, encapsulation, or length indication. Contrast this to 
 encryption of data, where the data is encapsulated in an Ieee1609Dot2Data.
>>>
```asn1
RecipientInfo ::= CHOICE {
  pskRecipInfo        PreSharedKeyRecipientInfo,
  symmRecipInfo       SymmRecipientInfo,
  certRecipInfo       PKRecipientInfo, 
  signedDataRecipInfo PKRecipientInfo, 
  rekRecipInfo        PKRecipientInfo 
}
```


### <a name="SequenceOfRecipientInfo"></a>SequenceOfRecipientInfo
This type is used for clarity of definitions.
```asn1
SequenceOfRecipientInfo ::= SEQUENCE OF RecipientInfo
```


### <a name="PreSharedKeyRecipientInfo"></a>PreSharedKeyRecipientInfo
This data structure is used to indicate a symmetric key that may 
 be used directly to decrypt a SymmetricCiphertext. It consists of the 
 low-order 8 bytes of the hash of the COER encoding of a 
 SymmetricEncryptionKey structure containing the symmetric key in question. 
 The HashedId8 is calculated with the hash algorithm determined as 
 specified in 5.3.9.3. The symmetric key may be established by any 
 appropriate means agreed by the two parties to the exchange.
```asn1
PreSharedKeyRecipientInfo ::= HashedId8
```

### <a name="SymmRecipientInfo"></a>SymmRecipientInfo
This data structure contains the following fields:

Fields:
* recipientId of type [**HashedId8**](Ieee1609Dot2BaseTypes.md#HashedId8) <br>
  contains the hash of the symmetric key encryption key 
   that may be used to decrypt the data encryption key. It consists of the 
   low-order 8 bytes of the hash of the COER encoding of a 
   SymmetricEncryptionKey structure containing the symmetric key in question. 
   The HashedId8 is calculated with the hash algorithm determined as 
   specified in 5.3.9.4. The symmetric key may be established by any 
   appropriate means agreed by the two parties to the exchange.


* encKey of type [**SymmetricCiphertext**](#SymmetricCiphertext) <br>
  contains the encrypted data encryption key within a 
   SymmetricCiphertext, where the data encryption key is input to the data 
   encryption key encryption process with no headers, encapsulation, or 
   length indication.
   


    
```asn1
SymmRecipientInfo ::= SEQUENCE { 
  recipientId HashedId8, 
  encKey      SymmetricCiphertext
}
```

### <a name="PKRecipientInfo"></a>PKRecipientInfo
This data structure contains the following fields:

Fields:
* recipientId of type [**HashedId8**](Ieee1609Dot2BaseTypes.md#HashedId8) <br>
  contains the hash of the container for the encryption
   public key as specified in the definition of RecipientInfo. Specifically,
   depending on the choice indicated by the containing RecipientInfo structure:
     - If the containing RecipientInfo structure indicates certRecipInfo,
   this field contains the HashedId8 of the certificate. The HashedId8 is
   calculated with the whole-certificate hash algorithm, determined as
   described in 6.4.3, applied to the COER-encoded certificate, canonicalized
   as defined in the definition of Certificate.
     - If the containing RecipientInfo structure indicates 
   signedDataRecipInfo, this field contains the HashedId8 of the 
   Ieee1609Dot2Data of type signedData that contained the encryption key, 
   with that Ieee��1609�Dot2��Data canonicalized per 6.3.4. The HashedId8 is 
   calculated with the hash algorithm determined as specified in 5.3.9.5.
     - If the containing RecipientInfo structure indicates rekRecipInfo, this 
   field contains the HashedId8 of the COER encoding of a PublicEncryptionKey 
   structure containing the response encryption key. The HashedId8 is 
   calculated with the hash algorithm determined as specified in 5.3.9.5.


* encKey of type [**EncryptedDataEncryptionKey**](#EncryptedDataEncryptionKey) <br>
  contains the encrypted data encryption key, where the data 
   encryption key is input to the data encryption key encryption process with 
   no headers, encapsulation, or length indication. 
   


    
```asn1
PKRecipientInfo ::= SEQUENCE { 
  recipientId HashedId8, 
  encKey      EncryptedDataEncryptionKey
}
```

### <a name="EncryptedDataEncryptionKey"></a>EncryptedDataEncryptionKey
This data structure contains an encrypted data encryption key, 
 where the data encryption key is input to the data encryption key 
 encryption process with no headers, encapsulation, or length indication.


 Critical information fields: If present and applicable to
 the receiving SDEE, this is a critical information field as defined in
 5.2.6. If an implementation receives an encrypted SPDU and determines that
 one or more RecipientInfo fields are relevant to it, and if all of those
 RecipientInfos contain an EncryptedDataEncryptionKey such that the
 implementation does not recognize the indicated CHOICE, the implementation
 shall indicate that the encrypted SPDU is not decryptable.

Fields:
* eciesNistP256 of type [**EciesP256EncryptedKey**](Ieee1609Dot2BaseTypes.md#EciesP256EncryptedKey) <br>
* eciesBrainpoolP256r1 of type [**EciesP256EncryptedKey**](Ieee1609Dot2BaseTypes.md#EciesP256EncryptedKey) <br>
   
* ecencSm2256 of type [**EcencP256EncryptedKey**](Ieee1609Dot2BaseTypes.md#EcencP256EncryptedKey) <br>
   
     ...,
```asn1
EncryptedDataEncryptionKey ::= CHOICE { 
  eciesNistP256        EciesP256EncryptedKey,
  eciesBrainpoolP256r1 EciesP256EncryptedKey,
  ...,
  ecencSm2256          EcencP256EncryptedKey
}
```

### <a name="SymmetricCiphertext"></a>SymmetricCiphertext
This data structure encapsulates a ciphertext generated with an
 approved symmetric algorithm.

Fields:
* aes128ccm of type [**One28BitCcmCiphertext**](#One28BitCcmCiphertext) <br>
* sm4Ccm of type [**One28BitCcmCiphertext**](#One28BitCcmCiphertext) <br>
   
     ...,

>>>
NOTE:&emsp;Critical information fields: If present, this is a critical
 information field as defined in 5.2.6. An implementation that does not
 recognize the indicated CHOICE value for this type in an encrypted SPDU
 shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, 
 that is, it is invalid in the sense that its validity cannot be established.
>>>
```asn1
SymmetricCiphertext ::= CHOICE {
  aes128ccm One28BitCcmCiphertext,
  ...,
  sm4Ccm    One28BitCcmCiphertext
}
```

### <a name="One28BitCcmCiphertext"></a>One28BitCcmCiphertext
This data structure encapsulates an encrypted ciphertext for any 
 symmetric algorithm with 128-bit blocks in CCM mode. The ciphertext is 
 16 bytes longer than the corresponding plaintext due to the inclusion of 
 the message authentication code (MAC). The plaintext resulting from a 
 correct decryption of the ciphertext is either a COER-encoded 
 Ieee1609Dot2Data structure (see 6.3.41), or a 16-byte symmetric key 
 (see 6.3.44).


 The ciphertext is 16 bytes longer than the corresponding plaintext.

 The plaintext resulting from a correct decryption of the
 ciphertext is a COER-encoded Ieee1609Dot2Data structure.

Fields:
* nonce of type **OCTET STRING**  (SIZE (12))<br>
  contains the nonce N as specified in 5.3.8.


* ccmCiphertext of type [**Opaque**](Ieee1609Dot2BaseTypes.md#Opaque) <br>
  contains the ciphertext C as specified in 5.3.8.


   

>>>
NOTE:&emsp;In the name of this structure, "One28" indicates that the 
 symmetric cipher block size is 128 bits. It happens to also be the case 
 that the keys used for both AES-128-CCM and SM4-CCM are also 128 bits long. 
 This is, however, not what �One28� refers to. Since the cipher is used in 
 counter mode, i.e., as a stream cipher, the fact that that block size is 128
 bits affects only the size of the MAC and does not affect the size of the
 raw ciphertext.
>>>
```asn1
One28BitCcmCiphertext ::= SEQUENCE {
  nonce         OCTET STRING (SIZE (12)),
  ccmCiphertext Opaque 
}
```


### <a name="Aes128CcmCiphertext"></a>Aes128CcmCiphertext
This type is defined only for backwards compatibility.
```asn1
Aes128CcmCiphertext ::= One28BitCcmCiphertext
```


### <a name="TestCertificate"></a>TestCertificate
This structure is a profile of the structure CertificateBase which
 specifies the valid combinations of fields to transmit implicit and
 explicit certificates.

>>>
NOTE:&emsp;Canonicalization: This data structure is subject to canonicalization 
 for the relevant operations specified in 6.1.2. The canonicalization 
 applies to the CertificateBase.
>>>
```asn1
TestCertificate ::= Certificate
```


### <a name="SequenceOfCertificate"></a>SequenceOfCertificate
This type is used for clarity of definitions.
```asn1
SequenceOfCertificate ::= SEQUENCE OF Certificate
```

### <a name="CertificateBase"></a>CertificateBase
The fields in this structure have the following meaning:

Fields:
* version of type [**Uint8**](Ieee1609Dot2BaseTypes.md#Uint8) (3)<br>
  contains the version of the certificate format. In this
   version of the data structures, this field is set to 3.


* type of type [**CertificateType**](#CertificateType) <br>
  states whether the certificate is implicit or explicit. This
   field is set to explicit for explicit certificates and to implicit for
   implicit certificates. See ExplicitCertificate and ImplicitCertificate for
   more details.


   
* issuer of type [**IssuerIdentifier**](#IssuerIdentifier) <br>
  identifies the issuer of the certificate.


   
* toBeSigned of type [**ToBeSignedCertificate**](#ToBeSignedCertificate) <br>
  is the certificate contents. This field is an input to
   the hash when generating or verifying signatures for an explicit
   certificate, or generating or verifying the public key from the
   reconstruction value for an implicit certificate. The details of how this
   field are encoded are given in the description of the
   ToBeSignedCertificate type.


   
* signature of type [**Signature**](Ieee1609Dot2BaseTypes.md#Signature)  OPTIONAL<br>
  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.
     - 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 canonicalized COER encoding of the certificate indicated by
   issuer. The canonicalization is carried out as specified in the 
   Canonicalization section of this subclause.


   

>>>
NOTE:&emsp;Whole-certificate hash: If the entirety of a certificate is hashed 
 to calculate a HashedId3, HashedId8, or HashedId10, the algorithm used for 
 this purpose is known as the whole-certificate hash. The method used to