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