| blob | e9c557cd6ff4accce1c4e0e0f8a3dd38ee8b0abf |
1 -- https://forge.etsi.org/rep/ITS/asn1/ieee1609.2/-/blob/ieee/Ieee1609Dot2.asn
2 --***************************************************************************--
3 -- IEEE Std 1609.2 --
4 --***************************************************************************--
6 /**
7 * @note Section references in this file are to clauses in IEEE Std
8 * 1609.2 unless indicated otherwise. Full forms of acronyms and
9 * abbreviations used in this file are specified in 3.2.
10 */
12 Ieee1609Dot2 {iso(1) identified-organization(3) ieee(111)
13 standards-association-numbered-series-standards(2) wave-stds(1609)
14 dot2(2) base(1) schema(1) major-version-2(2) minor-version-6(6)}
16 DEFINITIONS AUTOMATIC TAGS ::= BEGIN
18 IMPORTS
19 CERT-EXT-TYPE,
20 CrlSeries,
21 EccP256CurvePoint,
22 EcencP256EncryptedKey,
23 EciesP256EncryptedKey,
24 EncryptionKey,
25 EXT-TYPE,
26 Extension,
27 ExtId,
28 GeographicRegion,
29 GroupLinkageValue,
30 HashAlgorithm,
31 HashedId3,
32 HashedId8,
33 HashedId32,
34 HashedId48,
35 Hostname,
36 IValue,
37 LinkageValue,
38 Opaque,
39 Psid,
40 PsidSsp,
41 PsidSspRange,
42 PublicEncryptionKey,
43 PublicVerificationKey,
44 SequenceOfHashedId3,
45 SequenceOfPsidSsp,
46 SequenceOfPsidSspRange,
47 ServiceSpecificPermissions,
48 Signature,
49 SubjectAssurance,
50 SymmetricEncryptionKey,
51 ThreeDLocation,
52 Time64,
53 Uint3,
54 Uint8,
55 Uint16,
56 Uint32,
57 ValidityPeriod
58 FROM Ieee1609Dot2BaseTypes {iso(1) identified-organization(3) ieee(111)
59 standards-association-numbered-series-standards(2) wave-stds(1609) dot2(2)
60 base(1) base-types(2) major-version-2(2) minor-version-4(4)}
61 WITH SUCCESSORS
63 EtsiOriginatingHeaderInfoExtension
64 FROM EtsiTs103097ExtensionModule {itu-t(0) identified-organization(4) etsi(0)
65 itsDomain(5) wg5(5) secHeaders(103097) extension(2) major-version-1(1)
66 minor-version-0(0)}
67 WITH SUCCESSORS
68 ;
70 --***************************************************************************--
71 -- Secured Data --
72 --***************************************************************************--
74 /**
75 * @brief This data type is used to contain the other data types in this
76 * clause. The fields in the Ieee1609Dot2Data have the following meanings:
77 *
78 * @param protocolVersion: contains the current version of the protocol. The
79 * version specified in this standard is version 3, represented by the
80 * integer 3. There are no major or minor version numbers.
81 *
82 * @param content: contains the content in the form of an Ieee1609Dot2Content.
83 *
84 * @note Canonicalization: This data structure is subject to canonicalization
85 * for the relevant operations specified in 6.1.2. The canonicalization
86 * applies to the Ieee1609Dot2Content.
87 */
88 Ieee1609Dot2Data ::= SEQUENCE {
89 protocolVersion Uint8(3),
90 content Ieee1609Dot2Content
91 }
93 /**
94 * @brief In this structure:
95 *
96 * @param unsecuredData: indicates that the content is an OCTET STRING to be
97 * consumed outside the SDS.
98 *
99 * @param signedData: indicates that the content has been signed according to
100 * this standard.
101 *
102 * @param encryptedData: indicates that the content has been encrypted
103 * according to this standard.
104 *
105 * @param signedCertificateRequest: indicates that the content is a
106 * certificate request signed by an IEEE 1609.2 certificate or self-signed.
107 *
108 * @param signedX509CertificateRequest: indicates that the content is a
109 * certificate request signed by an ITU-T X.509 certificate.
110 *
111 * @note Canonicalization: This data structure is subject to canonicalization
112 * for the relevant operations specified in 6.1.2 if it is of type signedData.
113 * The canonicalization applies to the SignedData.
114 */
115 Ieee1609Dot2Content ::= CHOICE {
116 unsecuredData Opaque,
117 signedData SignedData,
118 encryptedData EncryptedData,
119 signedCertificateRequest Opaque,
120 ...,
121 signedX509CertificateRequest Opaque
122 }
124 /**
125 * @brief In this structure:
126 *
127 * @param hashId: indicates the hash algorithm to be used to generate the hash
128 * of the message for signing and verification.
129 *
130 * @param tbsData: contains the data that is hashed as input to the signature.
131 *
132 * @param signer: determines the keying material and hash algorithm used to
133 * sign the data.
134 *
135 * @param signature: contains the digital signature itself, calculated as
136 * specified in 5.3.1.
137 * - If signer indicates the choice self, then the signature calculation
138 * is parameterized as follows:
139 * - Data input is equal to the COER encoding of the tbsData field
140 * canonicalized according to the encoding considerations given in 6.3.6.
141 * - Verification type is equal to self.
142 * - Signer identifier input is equal to the empty string.
143 * - If signer indicates certificate or digest, then the signature
144 * calculation is parameterized as follows:
145 * - Data input is equal to the COER encoding of the tbsData field
146 * canonicalized according to the encoding considerations given in 6.3.6.
147 * - Verification type is equal to certificate.
148 * - Signer identifier input equal to the COER-encoding of the
149 * Certificate that is to be used to verify the SPDU, canonicalized according
150 * to the encoding considerations given in 6.4.3.
151 *
152 * @note Canonicalization: This data structure is subject to canonicalization
153 * for the relevant operations specified in 6.1.2. The canonicalization
154 * applies to the ToBeSignedData and the Signature.
155 */
156 SignedData ::= SEQUENCE {
157 hashId HashAlgorithm,
158 tbsData ToBeSignedData,
159 signer SignerIdentifier,
160 signature Signature
161 }
163 /**
164 * @brief This structure contains the data to be hashed when generating or
165 * verifying a signature. See 6.3.4 for the specification of the input to the
166 * hash.
167 *
168 * @param payload: contains data that is provided by the entity that invokes
169 * the SDS.
170 *
171 * @param headerInfo: contains additional data that is inserted by the SDS.
172 * This structure is used as follows to determine the "data input" to the
173 * hash operation for signing or verification as specified in 5.3.1.2.2 or
174 * 5.3.1.3.
175 * - If payload does not contain the field omitted, the data input to the
176 * hash operation is the COER encoding of the ToBeSignedData.
177 * - If payload field in this ToBeSignedData instance contains the field
178 * omitted, the data input to the hash operation is the COER encoding of the
179 * ToBeSignedData, concatenated with the hash of the omitted payload. The hash
180 * of the omitted payload is calculated with the same hash algorithm that is
181 * used to calculate the hash of the data input for signing or verification.
182 * The data input to the hash operation is simply the COER enocding of the
183 * ToBeSignedData, concatenated with the hash of the omitted payload: there is
184 * no additional wrapping or length indication. As noted in 5.2.4.3.4, the
185 * means by which the signer and verifier establish the contents of the
186 * omitted payload are out of scope for this standard.
187 *
188 * @note Canonicalization: This data structure is subject to canonicalization
189 * for the relevant operations specified in 6.1.2. The canonicalization
190 * applies to the SignedDataPayload if it is of type data, and to the
191 * HeaderInfo.
192 */
193 ToBeSignedData ::= SEQUENCE {
194 payload SignedDataPayload,
195 headerInfo HeaderInfo
196 }
198 /**
199 * @brief This structure contains the data payload of a ToBeSignedData. This
200 * structure contains at least one of the optional elements, and may contain
201 * more than one. See 5.2.4.3.4 for more details.
202 * The security profile in Annex C allows an implementation of this standard
203 * to state which forms of Signed�Data�Payload are supported by that
204 * implementation, and also how the signer and verifier are intended to obtain
205 * the external data for hashing. The specification of an SDEE that uses
206 * external data is expected to be explicit and unambiguous about how this
207 * data is obtained and how it is formatted prior to processing by the hash
208 * function.
209 *
210 * @param data: contains data that is explicitly transported within the
211 * structure.
212 *
213 * @param extDataHash: contains the hash of data that is not explicitly
214 * transported within the structure, and which the creator of the structure
215 * wishes to cryptographically bind to the signature.
216 *
217 * @param omitted: indicates that there is external data to be included in the
218 * hash calculation for the signature.The mechanism for including the external
219 * data in the hash calculation is specified in 6.3.6.
220 *
221 * @note Canonicalization: This data structure is subject to canonicalization
222 * for the relevant operations specified in 6.1.2. The canonicalization
223 * applies to the Ieee1609Dot2Data.
224 */
225 SignedDataPayload ::= SEQUENCE {
226 data Ieee1609Dot2Data OPTIONAL,
227 extDataHash HashedData OPTIONAL,
228 ...,
229 omitted NULL OPTIONAL
230 } (WITH COMPONENTS {..., data PRESENT} |
231 WITH COMPONENTS {..., extDataHash PRESENT} |
232 WITH COMPONENTS {..., omitted PRESENT})
235 /**
236 * @brief This structure contains the hash of some data with a specified hash
237 * algorithm. See 5.3.3 for specification of the permitted hash algorithms.
238 *
239 * @param sha256HashedData: indicates data hashed with SHA-256.
240 *
241 * @param sha384HashedData: indicates data hashed with SHA-384.
242 *
243 * @param sm3HashedData: indicates data hashed with SM3.
244 *
245 * @note Critical information fields: If present, this is a critical
246 * information field as defined in 5.2.6. An implementation that does not
247 * recognize the indicated CHOICE for this type when verifying a signed SPDU
248 * shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2,
249 * that is, it is invalid in the sense that its validity cannot be established.
250 */
251 HashedData::= CHOICE {
252 sha256HashedData HashedId32,
253 ...,
254 sha384HashedData HashedId48,
255 sm3HashedData HashedId32
256 }
258 /**
259 * @brief This structure contains information that is used to establish
260 * validity by the criteria of 5.2.
261 *
262 * @param psid: indicates the application area with which the sender is
263 * claiming the payload is to be associated.
264 *
265 * @param generationTime: indicates the time at which the structure was
266 * generated. See 5.2.5.2.2 and 5.2.5.2.3 for discussion of the use of this
267 * field.
268 *
269 * @param expiryTime: if present, contains the time after which the data
270 * is no longer considered relevant. If both generationTime and
271 * expiryTime are present, the signed SPDU is invalid if generationTime is
272 * not strictly earlier than expiryTime.
273 *
274 * @param generationLocation: if present, contains the location at which the
275 * signature was generated.
276 *
277 * @param p2pcdLearningRequest: if present, is used by the SDS to request
278 * certificates for which it has seen identifiers and does not know the
279 * entire certificate. A specification of this peer-to-peer certificate
280 * distribution (P2PCD) mechanism is given in Clause 8. This field is used
281 * for the separate-certificate-pdu flavor of P2PCD and shall only be present
282 * if inlineP2pcdRequest is not present. The HashedId3 is calculated with the
283 * whole-certificate hash algorithm, determined as described in 6.4.3,
284 * applied to the COER-encoded certificate, canonicalized as defined in the
285 * definition of Certificate.
286 *
287 * @param missingCrlIdentifier: if present, is used by the SDS to request
288 * CRLs which it knows to have been issued and have not received. This is
289 * provided for future use and the associated mechanism is not defined in
290 * this version of this standard.
291 *
292 * @param encryptionKey: if present, is used to provide a key that is to
293 * be used to encrypt at least one response to this SPDU. The SDEE
294 * specification is expected to specify which response SPDUs are to be
295 * encrypted with this key. One possible use of this key to encrypt a
296 * response is specified in 6.3.35, 6.3.37, and 6.3.34. An encryptionKey
297 * field of type symmetric should only be used if the SignedData containing
298 * this field is securely encrypted by some means.
299 *
300 * @param inlineP2pcdRequest: if present, is used by the SDS to request
301 * unknown certificates per the inline peer-to-peer certificate distribution
302 * mechanism is given in Clause 8. This field shall only be present if
303 * p2pcdLearningRequest is not present. The HashedId3 is calculated with the
304 * whole-certificate hash algorithm, determined as described in 6.4.3, applied
305 * to the COER-encoded certificate, canonicalized as defined in the definition
306 * of Certificate.
307 *
308 * @param requestedCertificate: if present, is used by the SDS to provide
309 * certificates per the "inline" version of the peer-to-peer certificate
310 * distribution mechanism given in Clause 8.
311 *
312 * @param pduFunctionalType: if present, is used to indicate that the SPDU is
313 * to be consumed by a process other than an application process as defined
314 * in ISO 21177 [B14a]. See 6.3.23b for more details.
315 *
316 * @param contributedExtensions: if present, is used to contain additional
317 * extensions defined using the ContributedExtensionBlocks structure.
318 *
319 * @note Canonicalization: This data structure is subject to canonicalization
320 * for the relevant operations specified in 6.1.2. The canonicalization
321 * applies to the EncryptionKey. If encryptionKey is present, and indicates
322 * the choice public, and contains a BasePublicEncryptionKey that is an
323 * elliptic curve point (i.e., of type EccP256CurvePoint or
324 * EccP384CurvePoint), then the elliptic curve point is encoded in compressed
325 * form, i.e., such that the choice indicated within the Ecc*CurvePoint is
326 * compressed-y-0 or compressed-y-1.
327 * The canonicalization does not apply to any fields after the extension
328 * marker, including any fields in contributedExtensions.
329 */
330 HeaderInfo ::= SEQUENCE {
331 psid Psid,
332 generationTime Time64 OPTIONAL,
333 expiryTime Time64 OPTIONAL,
334 generationLocation ThreeDLocation OPTIONAL,
335 p2pcdLearningRequest HashedId3 OPTIONAL,
336 missingCrlIdentifier MissingCrlIdentifier OPTIONAL,
337 encryptionKey EncryptionKey OPTIONAL,
338 ...,
339 inlineP2pcdRequest SequenceOfHashedId3 OPTIONAL,
340 requestedCertificate Certificate OPTIONAL,
341 pduFunctionalType PduFunctionalType OPTIONAL,
342 contributedExtensions ContributedExtensionBlocks OPTIONAL
343 }
345 /**
346 * @brief This structure may be used to request a CRL that the SSME knows to
347 * have been issued and has not yet received. It is provided for future use
348 * and its use is not defined in this version of this standard.
349 *
350 * @param cracaId: is the HashedId3 of the CRACA, as defined in 5.1.3. The
351 * HashedId3 is calculated with the whole-certificate hash algorithm,
352 * determined as described in 6.4.3, applied to the COER-encoded certificate,
353 * canonicalized as defined in the definition of Certificate.
354 *
355 * @param crlSeries: is the requested CRL Series value. See 5.1.3 for more
356 * information.
357 */
358 MissingCrlIdentifier ::= SEQUENCE {
359 cracaId HashedId3,
360 crlSeries CrlSeries,
361 ...
362 }
364 /**
365 * @brief This data structure identifies the functional entity that is
366 * intended to consume an SPDU, for the case where that functional entity is
367 * not an application process, and are instead security support services for an
368 * application process. Further details and the intended use of this field are
369 * defined in ISO 21177 [B20].
370 *
371 * @param tlsHandshake: indicates that the Signed SPDU is not to be directly
372 * consumed as an application PDU and is to be used to provide information
373 * about the holder�s permissions to a Transport Layer Security (TLS)
374 * (IETF 5246 [B15], IETF 8446 [B16]) handshake process operating to secure
375 * communications to an application process. See IETF [B15] and ISO 21177
376 * [B20] for further information.
377 *
378 * @param iso21177ExtendedAuth: indicates that the Signed SPDU is not to be
379 * directly consumed as an application PDU and is to be used to provide
380 * additional information about the holder�s permissions to the ISO 21177
381 * Security Subsystem for an application process. See ISO 21177 [B20] for
382 * further information.
383 *
384 * @param iso21177SessionExtension: indicates that the Signed SPDU is not to
385 * be directly consumed as an application PDU and is to be used to extend an
386 * existing ISO 21177 secure session. This enables a secure session to
387 * persist beyond the lifetime of the certificates used to establish that
388 * session.
389 */
390 PduFunctionalType ::= INTEGER (0..255)
392 tlsHandshake PduFunctionalType ::= 1
393 iso21177ExtendedAuth PduFunctionalType ::= 2
394 iso21177SessionExtension PduFunctionalType ::= 3
397 /**
398 * @brief This type is used for clarity of definitions.
399 */
400 ContributedExtensionBlocks ::= SEQUENCE (SIZE(1..MAX)) OF
401 ContributedExtensionBlock
403 /**
404 * @brief This Information Object Class defines the class that provides a
405 * template for defining extension blocks.
406 */
407 IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION ::= CLASS {
408 &id HeaderInfoContributorId UNIQUE,
409 &Extn
410 } WITH SYNTAX {&Extn IDENTIFIED BY &id}
412 /**
413 * @brief This data structure defines the format of an extension block
414 * provided by an identified contributor by using the temnplate provided
415 * in the class IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION constraint
416 * to the objects in the set Ieee1609Dot2HeaderInfoContributedExtensions.
417 *
418 * @param contributorId: uniquely identifies the contributor.
419 *
420 * @param extns: contains a list of extensions from that contributor.
421 * Extensions are expected and not required to follow the format specified
422 * in 6.5.
423 */
424 ContributedExtensionBlock ::= SEQUENCE {
425 contributorId IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION.&id({
426 Ieee1609Dot2HeaderInfoContributedExtensions
427 }),
428 extns SEQUENCE (SIZE(1..MAX)) OF
429 IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION.&Extn({
430 Ieee1609Dot2HeaderInfoContributedExtensions
431 }{@.contributorId})
432 }
434 /**
435 * @brief This structure is an ASN.1 Information Object Set listing the
436 * defined contributed extension types and the associated
437 * HeaderInfoContributorId values. In this version of this standard two
438 * extension types are defined: Ieee1609ContributedHeaderInfoExtension and
439 * EtsiOriginatingHeaderInfoExtension.
440 */
441 Ieee1609Dot2HeaderInfoContributedExtensions
442 IEEE1609DOT2-HEADERINFO-CONTRIBUTED-EXTENSION ::= {
443 {Ieee1609ContributedHeaderInfoExtension IDENTIFIED BY
444 ieee1609HeaderInfoContributorId} |
445 {EtsiOriginatingHeaderInfoExtension IDENTIFIED BY
446 etsiHeaderInfoContributorId},
447 ...
448 }
450 /**
451 * @brief This is an integer used to identify a HeaderInfo extension
452 * contributing organization. In this version of this standard two values are
453 * defined:
454 * - ieee1609OriginatingExtensionId indicating extensions originating with
455 * IEEE 1609.
456 * - etsiOriginatingExtensionId indicating extensions originating with
457 * ETSI TC ITS.
458 */
459 HeaderInfoContributorId ::= INTEGER (0..255)
461 ieee1609HeaderInfoContributorId HeaderInfoContributorId ::= 1
462 etsiHeaderInfoContributorId HeaderInfoContributorId ::= 2
465 /**
466 * @brief This structure allows the recipient of data to determine which
467 * keying material to use to authenticate the data. It also indicates the
468 * verification type to be used to generate the hash for verification, as
469 * specified in 5.3.1.
470 *
471 * @param digest: If the choice indicated is digest:
472 * - The structure contains the HashedId8 of the relevant certificate. The
473 * HashedId8 is calculated with the whole-certificate hash algorithm,
474 * determined as described in 6.4.3.
475 * - The verification type is certificate and the certificate data
476 * passed to the hash function as specified in 5.3.1 is the authorization
477 * certificate.
478 *
479 * @param certificate: If the choice indicated is certificate:
480 * - The structure contains one or more Certificate structures, in order
481 * such that the first certificate is the authorization certificate and each
482 * subsequent certificate is the issuer of the one before it.
483 * - The verification type is certificate and the certificate data
484 * passed to the hash function as specified in 5.3.1 is the authorization
485 * certificate.
486 *
487 * @param self: If the choice indicated is self:
488 * - The structure does not contain any data beyond the indication that
489 * the choice value is self.
490 * - The verification type is self-signed.
491 *
492 * @note Critical information fields:
493 * - If present, this is a critical information field as defined in 5.2.6.
494 * An implementation that does not recognize the CHOICE value for this type
495 * when verifying a signed SPDU shall indicate that the signed SPDU is invalid.
496 * - If present, certificate is a critical information field as defined in
497 * 5.2.6. An implementation that does not support the number of certificates
498 * in certificate when verifying a signed SPDU shall indicate that the signed
499 * SPDU is invalid. A compliant implementation shall support certificate
500 * fields containing at least one certificate.
501 *
502 * @note Canonicalization: This data structure is subject to canonicalization
503 * for the relevant operations specified in 6.1.2. The canonicalization
504 * applies to every Certificate in the certificate field.
505 */
506 SignerIdentifier ::= CHOICE {
507 digest HashedId8,
508 certificate SequenceOfCertificate,
509 self NULL,
510 ...
511 }
513 /**
514 * @brief This data structure is used to perform a countersignature over an
515 * already-signed SPDU. This is the profile of an Ieee1609Dot2Data containing
516 * a signedData. The tbsData within content is composed of a payload
517 * containing the hash (extDataHash) of the externally generated, pre-signed
518 * SPDU over which the countersignature is performed.
519 */
520 Countersignature ::= Ieee1609Dot2Data (WITH COMPONENTS {...,
521 content (WITH COMPONENTS {...,
522 signedData (WITH COMPONENTS {...,
523 tbsData (WITH COMPONENTS {...,
524 payload (WITH COMPONENTS {...,
525 data ABSENT,
526 extDataHash PRESENT
527 }),
528 headerInfo(WITH COMPONENTS {...,
529 generationTime PRESENT,
530 expiryTime ABSENT,
531 generationLocation ABSENT,
532 p2pcdLearningRequest ABSENT,
533 missingCrlIdentifier ABSENT,
534 encryptionKey ABSENT
535 })
536 })
537 })
538 })
539 })
542 --***************************************************************************--
543 -- Encrypted Data --
544 --***************************************************************************--
546 /**
547 * @brief This data structure encodes data that has been encrypted to one or
548 * more recipients using the recipients� public or symmetric keys as
549 * specified in 5.3.4.
550 *
551 * @param recipients: contains one or more RecipientInfos. These entries may
552 * be more than one RecipientInfo, and more than one type of RecipientInfo,
553 * as long as all entries are indicating or containing the same data encryption
554 * key.
555 *
556 * @param ciphertext: contains the encrypted data. This is the encryption of
557 * an encoded Ieee1609Dot2Data structure as specified in 5.3.4.2.
558 *
559 * @note Critical information fields:
560 * - If present, recipients is a critical information field as defined in
561 * 5.2.6. An implementation that does not support the number of RecipientInfo
562 * in recipients when decrypted shall indicate that the encrypted SPDU could
563 * not be decrypted due to unsupported critical information fields. A
564 * compliant implementation shall support recipients fields containing at
565 * least eight entries.
566 *
567 * @note If the plaintext is raw data, i.e., it has not been output from a
568 * previous operation of the SDS, then it is trivial to encapsulate it in an
569 * Ieee1609Dot2Data of type unsecuredData as noted in 4.2.2.2.2. For example,
570 * '03 80 08 01 23 45 67 89 AB CD EF' is the C-OER encoding of '01 23 45 67
571 * 89 AB CD EF' encapsulated in an Ieee1609Dot2Data of type unsecuredData.
572 * The first byte of the encoding 03 is the protocolVersion, the second byte
573 * 80 indicates the choice unsecuredData, and the third byte 08 is the length
574 * of the raw data '01 23 45 67 89 AB CD EF'.
575 */
576 EncryptedData ::= SEQUENCE {
577 recipients SequenceOfRecipientInfo,
578 ciphertext SymmetricCiphertext
579 }
581 /**
582 * @brief This data structure is used to transfer the data encryption key to
583 * an individual recipient of an EncryptedData. The option pskRecipInfo is
584 * selected if the EncryptedData was encrypted using the static encryption
585 * key approach specified in 5.3.4. The other options are selected if the
586 * EncryptedData was encrypted using the ephemeral encryption key approach
587 * specified in 5.3.4. The meanings of the choices are:
588 *
589 * See Annex C.7 for guidance on when it may be appropriate to use
590 * each of these approaches.
591 *
592 * @param pskRecipInfo: The data was encrypted directly using a pre-shared
593 * symmetric key.
594 *
595 * @param symmRecipInfo: The data was encrypted with a data encryption key,
596 * and the data encryption key was encrypted using a symmetric key.
597 *
598 * @param certRecipInfo: The data was encrypted with a data encryption key,
599 * the data encryption key was encrypted using a public key encryption scheme,
600 * where the public encryption key was obtained from a certificate. In this
601 * case, the parameter P1 to ECIES as defined in 5.3.5 is the hash of the
602 * certificate, calculated with the whole-certificate hash algorithm,
603 * determined as described in 6.4.3, applied to the COER-encoded certificate,
604 * canonicalized as defined in the definition of Certificate.
605 *
606 * @note If the encryption algorithm is SM2, there is no equivalent of the
607 * parameter P1 and so no input to the encryption process that uses the hash
608 * of the certificate.
609 *
610 * @param signedDataRecipInfo: The data was encrypted with a data encryption
611 * key, the data encryption key was encrypted using a public key encryption
612 * scheme, where the public encryption key was obtained as the public response
613 * encryption key from a SignedData. In this case, if ECIES is the encryption
614 * algorithm, then the parameter P1 to ECIES as defined in 5.3.5 is the
615 * SHA-256 hash of the Ieee1609Dot2Data of type signedData containing the
616 * response encryption key, canonicalized as defined in the definition of
617 * Ieee1609Dot2Data.
618 *
619 * @note If the encryption algorithm is SM2, there is no equivalent of the
620 * parameter P1 and so no input to the encryption process that uses the hash
621 * of the Ieee1609Dot2Data.
622 *
623 * @param rekRecipInfo: The data was encrypted with a data encryption key,
624 * the data encryption key was encrypted using a public key encryption scheme,
625 * where the public encryption key was not obtained from a Signed-Data or a
626 * certificate. In this case, the SDEE specification is expected to specify
627 * how the public key is obtained, and if ECIES is the encryption algorithm,
628 * then the parameter P1 to ECIES as defined in 5.3.5 is the hash of the
629 * empty string.
630 *
631 * @note If the encryption algorithm is SM2, there is no equivalent of the
632 * parameter P1 and so no input to the encryption process that uses the hash
633 * of the empty string.
634 *
635 * @note The material input to encryption is the bytes of the encryption key
636 * with no headers, encapsulation, or length indication. Contrast this to
637 * encryption of data, where the data is encapsulated in an Ieee1609Dot2Data.
638 */
639 RecipientInfo ::= CHOICE {
640 pskRecipInfo PreSharedKeyRecipientInfo,
641 symmRecipInfo SymmRecipientInfo,
642 certRecipInfo PKRecipientInfo,
643 signedDataRecipInfo PKRecipientInfo,
644 rekRecipInfo PKRecipientInfo
645 }
647 /**
648 * @brief This type is used for clarity of definitions.
649 */
650 SequenceOfRecipientInfo ::= SEQUENCE OF RecipientInfo
652 /**
653 * @brief This data structure is used to indicate a symmetric key that may
654 * be used directly to decrypt a SymmetricCiphertext. It consists of the
655 * low-order 8 bytes of the hash of the COER encoding of a
656 * SymmetricEncryptionKey structure containing the symmetric key in question.
657 * The HashedId8 is calculated with the hash algorithm determined as
658 * specified in 5.3.9.3. The symmetric key may be established by any
659 * appropriate means agreed by the two parties to the exchange.
660 */
661 PreSharedKeyRecipientInfo ::= HashedId8
663 /**
664 * @brief This data structure contains the following fields:
665 *
666 * @param recipientId: contains the hash of the symmetric key encryption key
667 * that may be used to decrypt the data encryption key. It consists of the
668 * low-order 8 bytes of the hash of the COER encoding of a
669 * SymmetricEncryptionKey structure containing the symmetric key in question.
670 * The HashedId8 is calculated with the hash algorithm determined as
671 * specified in 5.3.9.4. The symmetric key may be established by any
672 * appropriate means agreed by the two parties to the exchange.
673 *
674 * @param encKey: contains the encrypted data encryption key within a
675 * SymmetricCiphertext, where the data encryption key is input to the data
676 * encryption key encryption process with no headers, encapsulation, or
677 * length indication.
678 */
679 SymmRecipientInfo ::= SEQUENCE {
680 recipientId HashedId8,
681 encKey SymmetricCiphertext
682 }
684 /**
685 * @brief This data structure contains the following fields:
686 *
687 * @param recipientId: contains the hash of the container for the encryption
688 * public key as specified in the definition of RecipientInfo. Specifically,
689 * depending on the choice indicated by the containing RecipientInfo structure:
690 * - If the containing RecipientInfo structure indicates certRecipInfo,
691 * this field contains the HashedId8 of the certificate. The HashedId8 is
692 * calculated with the whole-certificate hash algorithm, determined as
693 * described in 6.4.3, applied to the COER-encoded certificate, canonicalized
694 * as defined in the definition of Certificate.
695 * - If the containing RecipientInfo structure indicates
696 * signedDataRecipInfo, this field contains the HashedId8 of the
697 * Ieee1609Dot2Data of type signedData that contained the encryption key,
698 * with that Ieee��1609�Dot2��Data canonicalized per 6.3.4. The HashedId8 is
699 * calculated with the hash algorithm determined as specified in 5.3.9.5.
700 * - If the containing RecipientInfo structure indicates rekRecipInfo, this
701 * field contains the HashedId8 of the COER encoding of a PublicEncryptionKey
702 * structure containing the response encryption key. The HashedId8 is
703 * calculated with the hash algorithm determined as specified in 5.3.9.5.
704 *
705 * @param encKey: contains the encrypted data encryption key, where the data
706 * encryption key is input to the data encryption key encryption process with
707 * no headers, encapsulation, or length indication.
708 */
709 PKRecipientInfo ::= SEQUENCE {
710 recipientId HashedId8,
711 encKey EncryptedDataEncryptionKey
712 }
714 /**
715 * @brief This data structure contains an encrypted data encryption key,
716 * where the data encryption key is input to the data encryption key
717 * encryption process with no headers, encapsulation, or length indication.
718 *
719 * Critical information fields: If present and applicable to
720 * the receiving SDEE, this is a critical information field as defined in
721 * 5.2.6. If an implementation receives an encrypted SPDU and determines that
722 * one or more RecipientInfo fields are relevant to it, and if all of those
723 * RecipientInfos contain an EncryptedDataEncryptionKey such that the
724 * implementation does not recognize the indicated CHOICE, the implementation
725 * shall indicate that the encrypted SPDU is not decryptable.
726 */
727 EncryptedDataEncryptionKey ::= CHOICE {
728 eciesNistP256 EciesP256EncryptedKey,
729 eciesBrainpoolP256r1 EciesP256EncryptedKey,
730 ...,
731 ecencSm2256 EcencP256EncryptedKey
732 }
734 /**
735 * @brief This data structure encapsulates a ciphertext generated with an
736 * approved symmetric algorithm.
737 *
738 * @note Critical information fields: If present, this is a critical
739 * information field as defined in 5.2.6. An implementation that does not
740 * recognize the indicated CHOICE value for this type in an encrypted SPDU
741 * shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2,
742 * that is, it is invalid in the sense that its validity cannot be established.
743 */
744 SymmetricCiphertext ::= CHOICE {
745 aes128ccm One28BitCcmCiphertext,
746 ...,
747 sm4Ccm One28BitCcmCiphertext
748 }
750 /**
751 * @brief This data structure encapsulates an encrypted ciphertext for any
752 * symmetric algorithm with 128-bit blocks in CCM mode. The ciphertext is
753 * 16 bytes longer than the corresponding plaintext due to the inclusion of
754 * the message authentication code (MAC). The plaintext resulting from a
755 * correct decryption of the ciphertext is either a COER-encoded
756 * Ieee1609Dot2Data structure (see 6.3.41), or a 16-byte symmetric key
757 * (see 6.3.44).
758 *
759 * The ciphertext is 16 bytes longer than the corresponding plaintext.
760 *
761 * The plaintext resulting from a correct decryption of the
762 * ciphertext is a COER-encoded Ieee1609Dot2Data structure.
763 *
764 * @param nonce: contains the nonce N as specified in 5.3.8.
765 *
766 * @param ccmCiphertext: contains the ciphertext C as specified in 5.3.8.
767 *
768 * @note In the name of this structure, "One28" indicates that the
769 * symmetric cipher block size is 128 bits. It happens to also be the case
770 * that the keys used for both AES-128-CCM and SM4-CCM are also 128 bits long.
771 * This is, however, not what �One28� refers to. Since the cipher is used in
772 * counter mode, i.e., as a stream cipher, the fact that that block size is 128
773 * bits affects only the size of the MAC and does not affect the size of the
774 * raw ciphertext.
775 */
776 One28BitCcmCiphertext ::= SEQUENCE {
777 nonce OCTET STRING (SIZE (12)),
778 ccmCiphertext Opaque
779 }
781 /**
782 * @brief This type is defined only for backwards compatibility.
783 */
784 Aes128CcmCiphertext ::= One28BitCcmCiphertext
786 --***************************************************************************--
787 -- Certificates and other Security Management --
788 --***************************************************************************--
790 /**
791 * @brief This structure is a profile of the structure CertificateBase which
792 * specifies the valid combinations of fields to transmit implicit and
793 * explicit certificates.
794 *
795 * @note Canonicalization: This data structure is subject to canonicalization
796 * for the relevant operations specified in 6.1.2. The canonicalization
797 * applies to the CertificateBase.
798 */
799 Certificate ::=
800 CertificateBase (ImplicitCertificate | ExplicitCertificate)
802 TestCertificate ::= Certificate
804 /**
805 * @brief This type is used for clarity of definitions.
806 */
807 SequenceOfCertificate ::= SEQUENCE OF Certificate
809 /**
810 * @brief The fields in this structure have the following meaning:
811 *
812 * @param version: contains the version of the certificate format. In this
813 * version of the data structures, this field is set to 3.
814 *
815 * @param type: states whether the certificate is implicit or explicit. This
816 * field is set to explicit for explicit certificates and to implicit for
817 * implicit certificates. See ExplicitCertificate and ImplicitCertificate for
818 * more details.
819 *
820 * @param issuer: identifies the issuer of the certificate.
821 *
822 * @param toBeSigned: is the certificate contents. This field is an input to
823 * the hash when generating or verifying signatures for an explicit
824 * certificate, or generating or verifying the public key from the
825 * reconstruction value for an implicit certificate. The details of how this
826 * field are encoded are given in the description of the
827 * ToBeSignedCertificate type.
828 *
829 * @param signature: is included in an ExplicitCertificate. It is the
830 * signature, calculated by the signer identified in the issuer field, over
831 * the hash of toBeSigned. The hash is calculated as specified in 5.3.1, where:
832 * - Data input is the encoding of toBeSigned following the COER.
833 * - Signer identifier input depends on the verification type, which in
834 * turn depends on the choice indicated by issuer. If the choice indicated by
835 * issuer is self, the verification type is self-signed and the signer
836 * identifier input is the empty string. If the choice indicated by issuer is
837 * not self, the verification type is certificate and the signer identifier
838 * input is the canonicalized COER encoding of the certificate indicated by
839 * issuer. The canonicalization is carried out as specified in the
840 * Canonicalization section of this subclause.
841 *
842 * @note Canonicalization: This data structure is subject to canonicalization
843 * for the relevant operations specified in 6.1.2. The canonicalization
844 * applies to the ToBeSignedCertificate and to the Signature.
845 *
846 * @note Whole-certificate hash: If the entirety of a certificate is hashed
847 * to calculate a HashedId3, HashedId8, or HashedId10, the algorithm used for
848 * this purpose is known as the whole-certificate hash. The method used to
849 * determine the whole-certificate hash algorithm is specified in 5.3.9.2.
850 */
851 CertificateBase ::= SEQUENCE {
852 version Uint8(3),
853 type CertificateType,
854 issuer IssuerIdentifier,
855 toBeSigned ToBeSignedCertificate,
856 signature Signature OPTIONAL
857 }
859 /**
860 * @brief This enumerated type indicates whether a certificate is explicit or
861 * implicit.
862 *
863 * @note Critical information fields: If present, this is a critical
864 * information field as defined in 5.2.5. An implementation that does not
865 * recognize the indicated CHOICE for this type when verifying a signed SPDU
866 * shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2,
867 * that is, it is invalid in the sense that its validity cannot be
868 * established.
869 */
870 CertificateType ::= ENUMERATED {
871 explicit,
872 implicit,
873 ...
874 }
876 /**
877 * @brief This is a profile of the CertificateBase structure providing all
878 * the fields necessary for an implicit certificate, and no others.
879 */
880 ImplicitCertificate ::= CertificateBase (WITH COMPONENTS {...,
881 type(implicit),
882 toBeSigned(WITH COMPONENTS {...,
883 verifyKeyIndicator(WITH COMPONENTS {reconstructionValue})
884 }),
885 signature ABSENT
886 })
888 /**
889 * @brief This is a profile of the CertificateBase structure providing all
890 * the fields necessary for an explicit certificate, and no others.
891 */
892 ExplicitCertificate ::= CertificateBase (WITH COMPONENTS {...,
893 type(explicit),
894 toBeSigned (WITH COMPONENTS {...,
895 verifyKeyIndicator(WITH COMPONENTS {verificationKey})
896 }),
897 signature PRESENT
898 })
900 /**
901 * @brief This structure allows the recipient of a certificate to determine
902 * which keying material to use to authenticate the certificate.
903 *
904 * If the choice indicated is sha256AndDigest, sha384AndDigest, or
905 * sm3AndDigest:
906 * - The structure contains the HashedId8 of the issuing certificate. The
907 * HashedId8 is calculated with the whole-certificate hash algorithm,
908 * determined as described in 6.4.3, applied to the COER-encoded certificate,
909 * canonicalized as defined in the definition of Certificate.
910 * - The hash algorithm to be used to generate the hash of the certificate
911 * for verification is SHA-256 (in the case of sha256AndDigest), SM3 (in the
912 * case of sm3AndDigest) or SHA-384 (in the case of sha384AndDigest).
913 * - The certificate is to be verified with the public key of the
914 * indicated issuing certificate.
915 *
916 * If the choice indicated is self:
917 * - The structure indicates what hash algorithm is to be used to generate
918 * the hash of the certificate for verification.
919 * - The certificate is to be verified with the public key indicated by
920 * the verifyKeyIndicator field in theToBeSignedCertificate.
921 *
922 * @note Critical information fields: If present, this is a critical
923 * information field as defined in 5.2.5. An implementation that does not
924 * recognize the indicated CHOICE for this type when verifying a signed SPDU
925 * shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2,
926 * that is, it is invalid in the sense that its validity cannot be
927 * established.
928 */
929 IssuerIdentifier ::= CHOICE {
930 sha256AndDigest HashedId8,
931 self HashAlgorithm,
932 ...,
933 sha384AndDigest HashedId8,
934 sm3AndDigest HashedId8
935 }
937 /**
938 * @brief The fields in the ToBeSignedCertificate structure have the
939 * following meaning:
940 *
941 * For both implicit and explicit certificates, when the certificate
942 * is hashed to create or recover the public key (in the case of an implicit
943 * certificate) or to generate or verify the signature (in the case of an
944 * explicit certificate), the hash is Hash (Data input) || Hash (
945 * Signer identifier input), where:
946 * - Data input is the COER encoding of toBeSigned, canonicalized
947 * as described above.
948 * - Signer identifier input depends on the verification type,
949 * which in turn depends on the choice indicated by issuer. If the choice
950 * indicated by issuer is self, the verification type is self-signed and the
951 * signer identifier input is the empty string. If the choice indicated by
952 * issuer is not self, the verification type is certificate and the signer
953 * identifier input is the COER encoding of the canonicalization per 6.4.3 of
954 * the certificate indicated by issuer.
955 *
956 * In other words, for implicit certificates, the value H (CertU) in SEC 4,
957 * section 3, is for purposes of this standard taken to be H [H
958 * (canonicalized ToBeSignedCertificate from the subordinate certificate) ||
959 * H (entirety of issuer Certificate)]. See 5.3.2 for further discussion,
960 * including material differences between this standard and SEC 4 regarding
961 * how the hash function output is converted from a bit string to an integer.
962 *
963 * @param id: contains information that is used to identify the certificate
964 * holder if necessary.
965 *
966 * @param cracaId: identifies the Certificate Revocation Authorization CA
967 * (CRACA) responsible for certificate revocation lists (CRLs) on which this
968 * certificate might appear. Use of the cracaId is specified in 5.1.3. The
969 * HashedId3 is calculated with the whole-certificate hash algorithm,
970 * determined as described in 6.4.3, applied to the COER-encoded certificate,
971 * canonicalized as defined in the definition of Certificate.
972 *
973 * @param crlSeries: represents the CRL series relevant to a particular
974 * Certificate Revocation Authorization CA (CRACA) on which the certificate
975 * might appear. Use of this field is specified in 5.1.3.
976 *
977 * @param validityPeriod: contains the validity period of the certificate.
978 *
979 * @param region: if present, indicates the validity region of the
980 * certificate. If it is omitted the validity region is indicated as follows:
981 * - If enclosing certificate is self-signed, i.e., the choice indicated
982 * by the issuer field in the enclosing certificate structure is self, the
983 * certificate is valid worldwide.
984 * - Otherwise, the certificate has the same validity region as the
985 * certificate that issued it.
986 *
987 * @param assuranceLevel: indicates the assurance level of the certificate
988 * holder.
989 *
990 * @param appPermissions: indicates the permissions that the certificate
991 * holder has to sign application data with this certificate. A valid
992 * instance of appPermissions contains any particular Psid value in at most
993 * one entry.
994 *
995 * @param certIssuePermissions: indicates the permissions that the certificate
996 * holder has to sign certificates with this certificate. A valid instance of
997 * this array contains no more than one entry whose psidSspRange field
998 * indicates all. If the array has multiple entries and one entry has its
999 * psidSspRange field indicate all, then the entry indicating all specifies
1000 * the permissions for all PSIDs other than the ones explicitly specified in
1001 * the other entries. See the description of PsidGroupPermissions for further
1002 * discussion.
1003 *
1004 * @param certRequestPermissions: indicates the permissions that the
1005 * certificate holder can request in its certificate. A valid instance of this
1006 * array contains no more than one entry whose psidSspRange field indicates
1007 * all. If the array has multiple entries and one entry has its psidSspRange
1008 * field indicate all, then the entry indicating all specifies the permissions
1009 * for all PSIDs other than the ones explicitly specified in the other entries.
1010 * See the description of PsidGroupPermissions for further discussion.
1011 *
1012 * @param canRequestRollover: indicates that the certificate may be used to
1013 * sign a request for another certificate with the same permissions. This
1014 * field is provided for future use and its use is not defined in this
1015 * version of this standard.
1016 *
1017 * @param encryptionKey: contains a public key for encryption for which the
1018 * certificate holder holds the corresponding private key.
1019 *
1020 * @param verifyKeyIndicator: contains material that may be used to recover
1021 * the public key that may be used to verify data signed by this certificate.
1022 *
1023 * @param flags: indicates additional yes/no properties of the certificate
1024 * holder. The only bit with defined semantics in this string in this version
1025 * of this standard is usesCubk. If set, the usesCubk bit indicates that the
1026 * certificate holder supports the compact unified butterfly key response.
1027 * Further material about the compact unified butterfly key response can be
1028 * found in IEEE Std 1609.2.1.
1029 *
1030 * @note usesCubk is only relevant for CA certificates, and the only
1031 * functionality defined associated with this field is associated with
1032 * consistency checks on received certificate responses. No functionality
1033 * associated with communications between peer SDEEs is defined associated
1034 * with this field.
1035 *
1036 * @param appExtensions: indicates additional permissions that may be applied
1037 * to application activities that the certificate holder is carrying out.
1038 *
1039 * @param certIssueExtensions: indicates additional permissions to issue
1040 * certificates containing endEntityExtensions.
1041 *
1042 * @param certRequestExtensions: indicates additional permissions to request
1043 * certificates containing endEntityExtensions.
1044 *
1045 * @note Canonicalization: This data structure is subject to canonicalization
1046 * for the relevant operations specified in 6.1.2. The canonicalization
1047 * applies to the PublicEncryptionKey and to the VerificationKeyIndicator.
1048 *
1049 * If the PublicEncryptionKey contains a BasePublicEncryptionKey that is an
1050 * elliptic curve point (i.e., of type EccP256CurvePoint or EccP384CurvePoint),
1051 * then the elliptic curve point is encoded in compressed form, i.e., such
1052 * that the choice indicated within the Ecc*CurvePoint is compressed-y-0 or
1053 * compressed-y-1.
1054 *
1055 * @note Critical information fields:
1056 * - If present, appPermissions is a critical information field as defined
1057 * in 5.2.6. If an implementation of verification does not support the number
1058 * of PsidSsp in the appPermissions field of a certificate that signed a
1059 * signed SPDU, that implementation shall indicate that the signed SPDU is
1060 * invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense
1061 * that its validity cannot be established.. A conformant implementation
1062 * shall support appPermissions fields containing at least eight entries.
1063 * It may be the case that an implementation of verification does not support
1064 * the number of entries in the appPermissions field and the appPermissions
1065 * field is not relevant to the verification: this will occur, for example,
1066 * if the certificate in question is a CA certificate and so the
1067 * certIssuePermissions field is relevant to the verification and the
1068 * appPermissions field is not. In this case, whether the implementation
1069 * indicates that the signed SPDU is valid (because it could validate all
1070 * relevant fields) or invalid (because it could not parse the entire
1071 * certificate) is implementation-specific.
1072 * - If present, certIssuePermissions is a critical information field as
1073 * defined in 5.2.6. If an implementation of verification does not support
1074 * the number of PsidGroupPermissions in the certIssuePermissions field of a
1075 * CA certificate in the chain of a signed SPDU, the implementation shall
1076 * indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that
1077 * is, it is invalid in the sense that its validity cannot be established.
1078 * A conformant implementation shall support certIssuePermissions fields
1079 * containing at least eight entries.
1080 * It may be the case that an implementation of verification does not support
1081 * the number of entries in the certIssuePermissions field and the
1082 * certIssuePermissions field is not relevant to the verification: this will
1083 * occur, for example, if the certificate in question is the signing
1084 * certificate for the SPDU and so the appPermissions field is relevant to
1085 * the verification and the certIssuePermissions field is not. In this case,
1086 * whether the implementation indicates that the signed SPDU is valid
1087 * (because it could validate all relevant fields) or invalid (because it
1088 * could not parse the entire certificate) is implementation-specific.
1089 * - If present, certRequestPermissions is a critical information field as
1090 * defined in 5.2.6. If an implementaiton of verification of a certificate
1091 * request does not support the number of PsidGroupPermissions in
1092 * certRequestPermissions, the implementation shall indicate that the signed
1093 * SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the
1094 * sense that its validity cannot be established. A conformant implementation
1095 * shall support certRequestPermissions fields containing at least eight
1096 * entries.
1097 * It may be the case that an implementation of verification does not support
1098 * the number of entries in the certRequestPermissions field and the
1099 * certRequestPermissions field is not relevant to the verification: this will
1100 * occur, for example, if the certificate in question is the signing
1101 * certificate for the SPDU and so the appPermissions field is relevant to
1102 * the verification and the certRequestPermissions field is not. In this
1103 * case, whether the implementation indicates that the signed SPDU is valid
1104 * (because it could validate all relevant fields) or invalid (because it
1105 * could not parse the entire certificate) is implementation-specific.
1106 */
1107 ToBeSignedCertificate ::= SEQUENCE {
1108 id CertificateId,
1109 cracaId HashedId3,
1110 crlSeries CrlSeries,
1111 validityPeriod ValidityPeriod,
1112 region GeographicRegion OPTIONAL,
1113 assuranceLevel SubjectAssurance OPTIONAL,
1114 appPermissions SequenceOfPsidSsp OPTIONAL,
1115 certIssuePermissions SequenceOfPsidGroupPermissions OPTIONAL,
1116 certRequestPermissions SequenceOfPsidGroupPermissions OPTIONAL,
1117 canRequestRollover NULL OPTIONAL,
1118 encryptionKey PublicEncryptionKey OPTIONAL,
1119 verifyKeyIndicator VerificationKeyIndicator,
1120 ...,
1121 flags BIT STRING {usesCubk (0)} (SIZE (8)) OPTIONAL,
1122 appExtensions SequenceOfAppExtensions,
1123 certIssueExtensions SequenceOfCertIssueExtensions,
1124 certRequestExtension SequenceOfCertRequestExtensions
1125 }
1126 (WITH COMPONENTS { ..., appPermissions PRESENT} |
1127 WITH COMPONENTS { ..., certIssuePermissions PRESENT} |
1128 WITH COMPONENTS { ..., certRequestPermissions PRESENT})
1130 /**
1131 * @brief This structure contains information that is used to identify the
1132 * certificate holder if necessary.
1133 *
1134 * @param linkageData: is used to identify the certificate for revocation
1135 * purposes in the case of certificates that appear on linked certificate
1136 * CRLs. See 5.1.3 and 7.3 for further discussion.
1137 *
1138 * @param name: is used to identify the certificate holder in the case of
1139 * non-anonymous certificates. The contents of this field are a matter of
1140 * policy and are expected to be human-readable.
1141 *
1142 * @param binaryId: supports identifiers that are not human-readable.
1143 *
1144 * @param none: indicates that the certificate does not include an identifier.
1145 *
1146 * @note Critical information fields:
1147 * - If present, this is a critical information field as defined in 5.2.6.
1148 * An implementation that does not recognize the choice indicated in this
1149 * field shall reject a signed SPDU as invalid.
1150 */
1151 CertificateId ::= CHOICE {
1152 linkageData LinkageData,
1153 name Hostname,
1154 binaryId OCTET STRING(SIZE(1..64)),
1155 none NULL,
1156 ...
1157 }
1159 /**
1160 * @brief This structure contains information that is matched against
1161 * information obtained from a linkage ID-based CRL to determine whether the
1162 * containing certificate has been revoked. See 5.1.3.4 and 7.3 for details
1163 * of use.
1164 */
1165 LinkageData ::= SEQUENCE {
1166 iCert IValue,
1167 linkage-value LinkageValue,
1168 group-linkage-value GroupLinkageValue OPTIONAL
1169 }
1171 /**
1172 * @brief This type indicates which type of permissions may appear in
1173 * end-entity certificates the chain of whose permissions passes through the
1174 * PsidGroupPermissions field containing this value. If app is indicated, the
1175 * end-entity certificate may contain an appPermissions field. If enroll is
1176 * indicated, the end-entity certificate may contain a certRequestPermissions
1177 * field.
1178 */
1179 EndEntityType ::=
1180 BIT STRING {app (0), enrol (1) } (SIZE (8)) --(ALL EXCEPT {})
1182 /**
1183 * @brief This structure states the permissions that a certificate holder has
1184 * with respect to issuing and requesting certificates for a particular set
1185 * of PSIDs. For examples, see D.5.3 and D.5.4.
1186 *
1187 * @param subjectPermissions: indicates PSIDs and SSP Ranges covered by this
1188 * field.
1189 *
1190 * @param minChainLength: and chainLengthRange indicate how long the
1191 * certificate chain from this certificate to the end-entity certificate is
1192 * permitted to be. As specified in 5.1.2.1, the length of the certificate
1193 * chain is the number of certificates "below" this certificate in the chain,
1194 * down to and including the end-entity certificate. The length is permitted
1195 * to be (a) greater than or equal to minChainLength certificates and (b)
1196 * less than or equal to minChainLength + chainLengthRange certificates. A
1197 * value of 0 for minChainLength is not permitted when this type appears in
1198 * the certIssuePermissions field of a ToBeSignedCertificate; a certificate
1199 * that has a value of 0 for this field is invalid. The value -1 for
1200 * chainLengthRange is a special case: if the value of chainLengthRange is -1
1201 * it indicates that the certificate chain may be any length equal to or
1202 * greater than minChainLength. See the examples below for further discussion.
1203 *
1204 * @param eeType: takes one or more of the values app and enroll and indicates
1205 * the type of certificates or requests that this instance of
1206 * PsidGroupPermissions in the certificate is entitled to authorize.
1207 * Different instances of PsidGroupPermissions within a ToBeSignedCertificate
1208 * may have different values for eeType.
1209 * - If this field indicates app, the chain is allowed to end in an
1210 * authorization certificate, i.e., a certficate in which these permissions
1211 * appear in an appPermissions field (in other words, if the field does not
1212 * indicate app and the chain ends in an authorization certificate, the
1213 * chain shall be considered invalid).
1214 * - If this field indicates enroll, the chain is allowed to end in an
1215 * enrollment certificate, i.e., a certificate in which these permissions
1216 * appear in a certReqPermissions permissions field (in other words, if the
1217 * field does not indicate enroll and the chain ends in an enrollment
1218 * certificate, the chain shall be considered invalid).
1219 */
1220 PsidGroupPermissions ::= SEQUENCE {
1221 subjectPermissions SubjectPermissions,
1222 minChainLength INTEGER DEFAULT 1,
1223 chainLengthRange INTEGER DEFAULT 0,
1224 eeType EndEntityType DEFAULT {app}
1225 }
1227 /**
1228 * @brief This type is used for clarity of definitions.
1229 */
1230 SequenceOfPsidGroupPermissions ::= SEQUENCE OF PsidGroupPermissions
1232 /**
1233 * @brief This indicates the PSIDs and associated SSPs for which certificate
1234 * issuance or request permissions are granted by a PsidGroupPermissions
1235 * structure. If this takes the value explicit, the enclosing
1236 * PsidGroupPermissions structure grants certificate issuance or request
1237 * permissions for the indicated PSIDs and SSP Ranges. If this takes the
1238 * value all, the enclosing PsidGroupPermissions structure grants certificate
1239 * issuance or request permissions for all PSIDs not indicated by other
1240 * PsidGroupPermissions in the same certIssuePermissions or
1241 * certRequestPermissions field.
1242 *
1243 * @note Critical information fields:
1244 * - If present, this is a critical information field as defined in 5.2.6.
1245 * An implementation that does not recognize the indicated CHOICE when
1246 * verifying a signed SPDU shall indicate that the signed SPDU is
1247 * invalidin the sense of 4.2.2.3.2, that is, it is invalid in the sense that
1248 * its validity cannot be established.
1249 * - If present, explicit is a critical information field as defined in
1250 * 5.2.6. An implementation that does not support the number of PsidSspRange
1251 * in explicit when verifying a signed SPDU shall indicate that the signed
1252 * SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the
1253 * sense that its validity cannot be established. A conformant implementation
1254 * shall support explicit fields containing at least eight entries.
1255 */
1256 SubjectPermissions ::= CHOICE {
1257 explicit SequenceOfPsidSspRange,
1258 all NULL,
1259 ...
1260 }
1262 /**
1263 * @brief The contents of this field depend on whether the certificate is an
1264 * implicit or an explicit certificate.
1265 *
1266 * @param verificationKey: is included in explicit certificates. It contains
1267 * the public key to be used to verify signatures generated by the holder of
1268 * the Certificate.
1269 *
1270 * @param reconstructionValue: is included in implicit certificates. It
1271 * contains the reconstruction value, which is used to recover the public key
1272 * as specified in SEC 4 and 5.3.2.
1273 *
1274 * @note Critical information fields: If present, this is a critical
1275 * information field as defined in 5.2.5. An implementation that does not
1276 * recognize the indicated CHOICE for this type when verifying a signed SPDU
1277 * shall indicate that the signed SPDU is invalid indicate that the signed
1278 * SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the
1279 * sense that its validity cannot be established.
1280 *
1281 * @note Canonicalization: This data structure is subject to canonicalization
1282 * for the relevant operations specified in 6.1.2. The canonicalization
1283 * applies to the PublicVerificationKey and to the EccP256CurvePoint. The
1284 * EccP256CurvePoint is encoded in compressed form, i.e., such that the
1285 * choice indicated within the EccP256CurvePoint is compressed-y-0 or
1286 * compressed-y-1.
1287 */
1288 VerificationKeyIndicator ::= CHOICE {
1289 verificationKey PublicVerificationKey,
1290 reconstructionValue EccP256CurvePoint,
1291 ...
1292 }
1294 /**
1295 * @brief This structure uses the parameterized type Extension to define an
1296 * Ieee1609ContributedHeaderInfoExtension as an open Extension Content field
1297 * identified by an extension identifier. The extension identifier value is
1298 * unique to extensions defined by ETSI and need not be unique among all
1299 * extension identifier values defined by all contributing organizations.
1300 */
1301 Ieee1609ContributedHeaderInfoExtension ::=
1302 Extension{{Ieee1609HeaderInfoExtensions}}
1304 /**
1305 * @brief This is an integer used to identify an
1306 * Ieee1609ContributedHeaderInfoExtension.
1307 */
1308 Ieee1609HeaderInfoExtensionId ::= ExtId
1310 p2pcd8ByteLearningRequestId Ieee1609HeaderInfoExtensionId ::= 1
1312 /**
1313 * @brief This is the ASN.1 Information Object Class that associates IEEE
1314 * 1609 HeaderInfo contributed extensions with the appropriate
1315 * Ieee1609HeaderInfoExtensionId value.
1316 */
1317 Ieee1609HeaderInfoExtensions EXT-TYPE ::= {
1318 {HashedId8 IDENTIFIED BY p2pcd8ByteLearningRequestId},
1319 ...
1320 }
1322 /**
1323 * @brief This structure contains any AppExtensions that apply to the
1324 * certificate holder. As specified in 5.2.4.2.3, each individual
1325 * AppExtension type is associated with consistency conditions, specific to
1326 * that extension, that govern its consistency with SPDUs signed by the
1327 * certificate holder and with the CertIssueExtensions in the CA certificates
1328 * in that certificate holder�s chain. Those consistency conditions are
1329 * specified for each individual AppExtension below.
1330 */
1331 SequenceOfAppExtensions ::= SEQUENCE (SIZE(1..MAX)) OF AppExtension
1333 /**
1334 * @brief This structure contains an individual AppExtension. AppExtensions
1335 * specified in this standard are drawn from the ASN.1 Information Object Set
1336 * SetCertExtensions. This set, and its use in the AppExtension type, is
1337 * structured so that each AppExtension is associated with a
1338 * CertIssueExtension and a CertRequestExtension and all are identified by
1339 * the same id value. In this structure:
1340 *
1341 * @param id: identifies the extension type.
1342 *
1343 * @param content: provides the content of the extension.
1344 */
1345 AppExtension ::= SEQUENCE {
1346 id CERT-EXT-TYPE.&id({SetCertExtensions}),
1347 content CERT-EXT-TYPE.&App({SetCertExtensions}{@.id})
1348 }
1350 /**
1351 * @brief This field contains any CertIssueExtensions that apply to the
1352 * certificate holder. As specified in 5.2.4.2.3, each individual
1353 * CertIssueExtension type is associated with consistency conditions,
1354 * specific to that extension, that govern its consistency with
1355 * AppExtensions in certificates issued by the certificate holder and with
1356 * the CertIssueExtensions in the CA certificates in that certificate
1357 * holder�s chain. Those consistency conditions are specified for each
1358 * individual CertIssueExtension below.
1359 */
1360 SequenceOfCertIssueExtensions ::=
1361 SEQUENCE (SIZE(1..MAX)) OF CertIssueExtension
1363 /**
1364 * @brief This field contains an individual CertIssueExtension.
1365 * CertIssueExtensions specified in this standard are drawn from the ASN.1
1366 * Information Object Set SetCertExtensions. This set, and its use in the
1367 * CertIssueExtension type, is structured so that each CertIssueExtension
1368 * is associated with a AppExtension and a CertRequestExtension and all are
1369 * identified by the same id value. In this structure:
1370 *
1371 * @param id: identifies the extension type.
1372 *
1373 * @param permissions: indicates the permissions. Within this field.
1374 * - all indicates that the certificate is entitled to issue all values of
1375 * the extension.
1376 * - specific is used to specify which values of the extension may be
1377 * issued in the case where all does not apply.
1378 */
1379 CertIssueExtension ::= SEQUENCE {
1380 id CERT-EXT-TYPE.&id({SetCertExtensions}),
1381 permissions CHOICE {
1382 specific CERT-EXT-TYPE.&Issue({SetCertExtensions}{@.id}),
1383 all NULL
1384 }
1385 }
1387 /**
1388 * @brief This field contains any CertRequestExtensions that apply to the
1389 * certificate holder. As specified in 5.2.4.2.3, each individual
1390 * CertRequestExtension type is associated with consistency conditions,
1391 * specific to that extension, that govern its consistency with
1392 * AppExtensions in certificates issued by the certificate holder and with
1393 * the CertRequestExtensions in the CA certificates in that certificate
1394 * holder�s chain. Those consistency conditions are specified for each
1395 * individual CertRequestExtension below.
1396 */
1397 SequenceOfCertRequestExtensions ::= SEQUENCE (SIZE(1..MAX)) OF CertRequestExtension
1399 /**
1400 * @brief This field contains an individual CertRequestExtension.
1401 * CertRequestExtensions specified in this standard are drawn from the
1402 * ASN.1 Information Object Set SetCertExtensions. This set, and its use in
1403 * the CertRequestExtension type, is structured so that each
1404 * CertRequestExtension is associated with a AppExtension and a
1405 * CertRequestExtension and all are identified by the same id value. In this
1406 * structure:
1407 *
1408 * @param id: identifies the extension type.
1409 *
1410 * @param permissions: indicates the permissions. Within this field.
1411 * - all indicates that the certificate is entitled to issue all values of
1412 * the extension.
1413 * - specific is used to specify which values of the extension may be
1414 * issued in the case where all does not apply.
1415 */
1416 CertRequestExtension ::= SEQUENCE {
1417 id CERT-EXT-TYPE.&id({SetCertExtensions}),
1418 permissions CHOICE {
1419 content CERT-EXT-TYPE.&Req({SetCertExtensions}{@.id}),
1420 all NULL
1421 }
1422 }
1424 /**
1425 * @brief This type is the AppExtension used to identify an operating
1426 * organization. The associated CertIssueExtension and CertRequestExtension
1427 * are both of type OperatingOrganizationId.
1428 * To determine consistency between this type and an SPDU, the SDEE
1429 * specification for that SPDU is required to specify how the SPDU can be
1430 * used to determine an OBJECT IDENTIFIER (for example, by including the
1431 * full OBJECT IDENTIFIER in the SPDU, or by including a RELATIVE-OID with
1432 * clear instructions about how a full OBJECT IDENTIFIER can be obtained from
1433 * the RELATIVE-OID). The SPDU is then consistent with this type if the
1434 * OBJECT IDENTIFIER determined from the SPDU is identical to the OBJECT
1435 * IDENTIFIER contained in this field.
1436 * This AppExtension does not have consistency conditions with a
1437 * corresponding CertIssueExtension. It can appear in a certificate issued
1438 * by any CA.
1439 */
1440 OperatingOrganizationId ::= OBJECT IDENTIFIER
1442 certExtId-OperatingOrganization ExtId ::= 1
1444 /**
1445 * @brief This Information Object is an instance of the Information Object
1446 * Class CERT-EXT-TYPE. It is defined to bind together the AppExtension,
1447 * CertIssueExtension, and CertRequestExtension types associated with the
1448 * use of an operating organization identifier, and to assocaute them all
1449 * with the extension identifier value certExtId-OperatingOrganization.
1450 */
1451 instanceOperatingOrganizationCertExtensions CERT-EXT-TYPE ::= {
1452 ID certExtId-OperatingOrganization
1453 APP OperatingOrganizationId
1454 ISSUE NULL
1455 REQUEST NULL
1456 }
1458 /**
1459 * @brief This Information Object Set is a collection of Information Objects
1460 * used to contain the AppExtension, CertIssueExtension, and
1461 * CertRequestExtension types associated with a specific use of certificate
1462 * extensions. In this version of this standard it only has a single entry
1463 * instanceOperatingOrganizationCertExtensions.
1464 */
1465 SetCertExtensions CERT-EXT-TYPE ::= {
1466 instanceOperatingOrganizationCertExtensions,
1467 ...
1468 }
1470 END