ASN.1 module Ieee1609Dot2Dot1Protocol

OID: {iso(1) identified-organization(3) ieee(111) standards-association-numbered-series-standards(2) wave-stds(1609) dot2(2) extension-standards(255) dot1(1) interfaces(1) protocol(17) major-version-3(3) minor-version-2(2)}

Imports:

Data Elements:

SecurityMgmtPsid

This PSID, 0x23, identifies security management activities as defined in this document.

SecurityMgmtPsid ::= Psid (35)

ScmsPdu

This is the parent structure that encompasses all parent structures of interfaces defined in the SCMS. An overview of this structure is as follows:

ScmsPdu ::= SEQUENCE { version Uint8 (2), content CHOICE { aca-ee AcaEeInterfacePdu, aca-la AcaLaInterfacePdu, aca-ma AcaMaInterfacePdu, aca-ra AcaRaInterfacePdu, cert CertManagementPdu, eca-ee EcaEeInterfacePdu, ee-ma EeMaInterfacePdu, ee-ra EeRaInterfacePdu, la-ma LaMaInterfacePdu, la-ra LaRaInterfacePdu, ma-ra MaRaInterfacePdu, ... } }

ScmsPdu-Scoped

This structure defines a parameterized type for creating a scoped data as a subtype of ScmsPdu.

ScmsPdu-Scoped {Pdu} ::= ScmsPdu (WITH COMPONENTS { ..., content (CONSTRAINED BY { Pdu }) })

X509Certificate

This structure defines a parameterized type for creating an unsecured data as a subtype of Ieee1609Dot2Data. This structure defines a parameterized type for creating a signed data as a subtype of Ieee1609Dot2Data. This structure defines a parameterized type for creating an encrypted data as a subtype of Ieee1609Dot2Data. An overview of this structure is as follows:

NOTE: ITU-T X.509 certificates are encoded with the ASN.1 DER rather than the OER used in this document and so cannot be "directly" imported into these structures.

X509Certificate ::= OCTET STRING

X509SignerIdentifier

This type is used for clarity of definitions. This structure identifies an ITU-T X.509 certificate used to sign a signed data structure.

X509SignerIdentifier ::= CHOICE { certificate SequenceOfX509Certificate, ... }

SignerSingleCert

This structure defines a parameterized type for creating a certificate request, signed with an ITU-T X.509 certificate, as a subtype of Ieee1609Dot2Content. It makes use of the extension of Ieee1609Dot2Content. This structure defines a parameterized type for creating a signed then encrypted data as a subtype of Ieee1609Dot2Data. This structure defines a parameterized type for creating an encrypted then signed data as a subtype of Ieee1609Dot2Data.

NOTE: This parameterized type inadvertently adds some overhead. The Ieee1609Dot2Data-EncryptedSigned {Tbes, Psid} structure, because it puts Ieee1609Dot2Data-Encrypted inside Ieee1609Dot2Data-Signed {Tbs, Psid}, and because Ieee1609Dot2Data-Signed {Tbs, Psid} puts Tbs inside unsecuredData, Tbes is "Signed(Unsecured(Encrypted))" instead of "Signed(Encrypted)", which was the intent and also in the original CAMP design. Other documents that use material from this document could avoid this overhead by defining an alternative to Ieee1609Dot2Data-EncryptedSigned that creates an SPDU of form Signed(Encrypted), and defining alternatives to all the types in this document that use Ieee1609Dot2Data-EncryptedSigned such that the alternatives in turn use the SPDU of form Signed(Encrypted). This structure defines a parameterized type for creating a signed then encrypted certificate request as a subtype of Ieee1609Dot2Data. This structure defines a parameterized type for creating an encrypted data as a subtype of Ieee1609Dot2Data. An overview of this structure is as follows:

SignerSingleCert ::= SignerIdentifier (WITH COMPONENTS { certificate (SequenceOfCertificate (SIZE (1))) })

SignerSingleX509Cert

This structure is used to indicate an X509SignerIdentifier with a certificate chain of size 1.

SignerSingleX509Cert ::= X509SignerIdentifier (WITH COMPONENTS { certificate (SequenceOfX509Certificate (SIZE (1))) })

SignerSelf

This structure is used to indicate a SignerIdentifier of type self.

SignerSelf ::= SignerIdentifier (WITH COMPONENTS { self })

ScopedCertificateRequest

This structure defines the all certificate request structures as a scoped version of the ScmsPdu.

ScopedCertificateRequest ::= ScmsPdu ( ScmsPdu-Scoped { AcaRaInterfacePdu (WITH COMPONENTS { raAcaCertRequest }) } | ScmsPdu-Scoped { EcaEeInterfacePdu (WITH COMPONENTS { eeEcaCertRequest }) } | ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { eeRaCertRequest }) } | ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { eeRaSuccessorEnrollmentCertRequest }) } )

SignedCertificateRequest

This structure defines the format of a signed certificate request. An overview of this structure is as follows:

The signature is generated on the hash of this structure, obtained per the rules specified for hashing data objects in 5.3.1 of IEEE Std 1609.2a-2017, where the parameter Data Input shall be the C-OER encoding of tbsRequest, and the parameter Signer Identifier Input depending on whether the request is self-signed or signed using an enrollment certificate:

SignedCertificateRequest ::= SEQUENCE { hashAlgorithmId HashAlgorithm, tbsRequest ScopedCertificateRequest, signer SignerIdentifier, signature Signature }

SignedX509CertificateRequest

This structure contains a certificate request signed with an ITU-T X.509 certificate. The only type of certificate request signed with an ITU-T X.509 certificate supported in this document is an authorization certificate request. An overview of this structure is as follows:

The signature is generated on the hash of this structure, obtained per the rules specified for hashing data objects in 5.3.1 of IEEE Std 1609.2a-2017, where the parameter Data Input shall be the C-OER encoding of tbsRequest, and the parameter Signer Identifier Input shall be the signer's certificate, that is, the ITU-T X.509 certificate contained in the OCTET STRING indicated by the first X509Certificate in signer. For example, if the signer is as below, the first 6 bytes are the ASN.1 encoding overhead, where 80 01 01 is the overhead for signer, and then 82 01 AC is the overhead introduced by the OCTET STRING encoding for the first (in this case, the only) X509Certificate; and the first X509Certificate is contained in the next 428 bytes (30 82 01 ... 00 00 00), so the parameter Signer Identifier Input shall be 30 82 01 ... 00 00 00.

An example X509SignerIdentifier with one X509Certificate:

80 01 01 82 01 AC 30 82 01 A8 30 82 01 4D A0 03 02 01 02 02 04 90 C5 9D 21 30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 24 31 0A 30 08 06 03 55 04 06 13 01 00 31 0A 30 08 06 03 55 04 0A 13 01 00 31 0A 30 08 06 03 55 04 03 13 01 00 30 1E 17 0D 30 30 30 31 30 31 30 30 30 30 30 30 5A 17 0D 30 30 30 31 30 31 30 30 30 30 30 30 5A 30 24 31 0A 30 08 06 03 55 04 06 13 01 00 31 0A 30 08 06 03 55 04 0A 13 01 00 31 0A 30 08 06 03 55 04 03 13 01 00 30 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 48 CE 3D 03 01 07 03 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A3 6D 30 6B 30 0A 06 03 55 1D 0E 04 03 04 01 00 30 0A 06 03 55 1D 23 04 03 04 01 00 30 0C 06 03 55 1D 13 01 01 FF 04 02 30 00 30 0E 06 03 55 1D 0F 01 01 FF 04 04 03 02 03 C8 30 0A 06 03 55 1D 25 04 03 04 01 00 30 0A 06 03 55 1D 1F 04 03 04 01 00 30 0F 06 08 2B 06 01 05 05 07 01 01 04 03 04 01 00 30 0A 06 03 55 1D 20 04 03 04 01 00 30 0A 06 08 2A 86 48 CE 3D 04 03 02 03 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

SignedX509CertificateRequest ::= SEQUENCE { hashAlgorithmId HashAlgorithm, tbsRequest ScopedCertificateRequest, signer X509SignerIdentifier, signature Signature }

AcaEeCertResponsePlainSpdu

This structure contains a certificate response for consumption by the EE. In the architecture of this document, although it is created by the ACA, it is made available to the EE via the RA as described in 8.2.

The ACA creates this response when 1) the compact unified butterfly key mechanism is not being used (that is, some other flavor of butterfly key is being used, or butterfly keys are not being used) and 2) it is not necessary to protect the EE's privacy from the RA, for example, when the certificate being returned is not a pseudonym certificate.

AcaEeCertResponsePlainSpdu ::= Ieee1609Dot2Data-Unsecured { ScmsPdu-Scoped { AcaEeInterfacePdu (WITH COMPONENTS { acaEeCertResponse }) } }

AcaEeCertResponsePrivateSpdu

This structure contains a certificate response for consumption by the EE. In the architecture of this document, although it is created by the ACA, it is made available to the EE via the RA as described in 8.2.

The ACA creates this response when 1) the compact unified butterfly key mechanism is not being used (that is, some other flavor of butterfly key is being used, or butterfly keys are not being used) and 2) it is necessary to protect the EE's privacy from the RA, for example when the certificate being returned is a pseudonym certificate.

The structure consists of a signed SPDU containing an encrypted SPDU.

The encrypted SPDU is encrypted with the response encryption key that was provided to the ACA for that purpose. This key is determined as follows:

See 9.3 for more material about butterfly keys.

The resulting Ieee1609Dot2Data of content type encryptedData is signed by the same ACA certificate that was used to issue the certificate field in the AcaEeCertResponse. If this structure is signed by a different ACA certificate, it is invalid. The ACA certificate shall follow the ACA certificate profile given in 7.6.3.2.

If the original request indicated the use of "compact unified" butterfly key mechanism by including the additionalParams.compactUnified field, the response shall be a AcaEeCertResponseCubkSpdu, not a AcaEeCertResponsePrivateSpdu.

NOTE:

  1. How the ACA obtains the response encryption key. This document provides the RaAcaCertRequest structure to allow the RA to indicate whether the original or unified butterfly key mechanism is to be used via the flags field. The encryption key for encrypting AcaEeCertResponse is calculated by the indicated method even if the RA does not use an RaAcaCertRequest as defined in this document to communicate the certificate request to the ACA.
  2. Consistency between inner and outer signers, and the IEEE Std 1609.2 model. This SPDU introduces a new type of validity condition by requiring that the ACA that signs the outer signed SPDU is also the ACA that issued the certificate inside the encrypted SPDU. This requires that to verify the inner "SPDU", that is, the certificate, the verifier needs to store the information from the outer SPDU. This is not a violation of the IEEE 1609.2 model: Subclause 4.2.2.3 of IEEE Std 1609.2 considers all operations carried out on received data to be atomic and does not put any restrictions on the information that is stored between operations. However, implementers' attention is drawn to the fact that because the IEEE 1609.2 approach enables SPDUs to be nested within one another as Ieee1609Dot2Data, in principle an implementation could be built that iterated through the layers of a nested SPDU within a single call from the invoking application instance. (IEEE Std 1609.2 was consciously designed to enable this approach: Although the primitives provided in IEEE Std 1609.2 only support the series-of-single-operations approach, an implementation could layer this "one-invocation processing" on top of the IEEE 1609.2 interface as an optimization.) A "one-invocation processing" implementation of that type would have to anticipate situations of coupling between inner and outer SPDUs like the one created by this AcaEeCertResponsePrivateSpdu, and allow the invoking certificate management service to check consistency at the application layer, perhaps by (for example) returning the signing certificates for all nested signed SPDUs. How this is to be implemented is implementation specific; this note is intended as a notification of this potential issue to implementers planning to implement one-invocation processing.
AcaEeCertResponsePrivateSpdu ::= Ieee1609Dot2Data-EncryptedSigned { ScmsPdu-Scoped { AcaEeInterfacePdu (WITH COMPONENTS { acaEeCertResponse }) }, SecurityMgmtPsid }

AcaEeCertResponseCubkSpdu

This structure contains a certificate response for consumption by the EE. In the architecture of this document, although it is created by the ACA, it is made available to the EE via the RA as described in 8.2.

The ACA creates a certificate response in this form when the compact unified butterfly key mechanism is being used. If the RaAcaCertRequest structure was used to communicate between the RA and the ACA, the RA indicated use of compact unified butterfly keys by setting the cubk (1) bit in the bkType field in the corresponding RaAcaCertRequest.

The AcaEeCertResponse is encrypted by the ACA using the cocoon public key for encryption. See 9.3.4.2 for how the ACA derives the cocoon public key for encryption, using the tbsCert.verifyKeyIndicator field in the corresponding RaAcaCertRequest as the input cocoon public key for signing Bt. See 9.3.4.1 for how the EE derives the corresponding cocoon private key for encryption.

AcaEeCertResponseCubkSpdu ::= Ieee1609Dot2Data-Encrypted { ScmsPdu-Scoped { AcaEeInterfacePdu (WITH COMPONENTS { acaEeCertResponse }) } }

RaAcaCertRequestSpdu

This structure is the SPDU used to send a signed RaAcaCertRequest. For the signature to be valid the signing certificate shall conform to the RA certificate profile given in 7.6.3.10, contain a PSID equal to SecurityMgmtPsid and a corresponding SSP containing the C-OER encoding of a SecurityMgmtSsp indicating RaSsp. The toBeSigned.certRequestPermissions field of the RA certificate shall permit the requested permissions in the raAcaCertRequest.tbsCert.appPermissions field.

RaAcaCertRequestSpdu ::= Ieee1609Dot2Data-SignedCertRequest { ScmsPdu-Scoped { AcaRaInterfacePdu (WITH COMPONENTS { raAcaCertRequest }) }, SignerSingleCert }

AcaRaCertResponseSpdu

This structure is the SPDU used to send a signed AcaRaCertResponse. For the signature to be valid the signing certificate shall contain a PSID equal to SecurityMgmtPsid and a corresponding SSP containing the C-OER encoding of a SecurityMgmtSsp indicating AcaSsp.

AcaRaCertResponseSpdu ::= Ieee1609Dot2Data-Signed { ScmsPdu-Scoped { AcaRaInterfacePdu (WITH COMPONENTS { acaRaCertResponse }) }, SecurityMgmtPsid }

CompositeCrlSpdu

This structure is the SPDU used to send an unsecured CompositeCrl. It is used to create composite CRL files as specified in 8.5.

CompositeCrlSpdu ::= Ieee1609Dot2Data-Unsecured { ScmsPdu-Scoped { CertManagementPdu (WITH COMPONENTS { compositeCrl }) } }

CertificateChainSpdu

This structure is the SPDU used to send an unsecured CertificateChain. It is used to create certificate chain files as specified in 8.4.

CertificateChainSpdu ::= Ieee1609Dot2Data-Unsecured { ScmsPdu-Scoped { CertManagementPdu (WITH COMPONENTS { certificateChain }) } }

MultiSignedCtlSpdu

This structure is the SPDU used to send an unsecured MultiSignedCtl.

MultiSignedCtlSpdu ::= Ieee1609Dot2Data-Unsecured { ScmsPdu-Scoped { CertManagementPdu (WITH COMPONENTS { multiSignedCtl }) } }

CtlSignatureSpdu

This structure is the SPDU used to send a signed ToBeSignedCtlSignature. For the signature to be valid, the signing certificate shall match the elector certificate profile in 7.6.3.6. This means that the signature is calculated as specified in IEEE Std 1609.2, with the data input to the hash process consisting of the C-OER encoding of the tbsData that includes the ToBeSignedCtlSignature.

CtlSignatureSpdu ::= Ieee1609Dot2Data-Signed { ScmsPdu-Scoped { CertManagementPdu (WITH COMPONENTS { tbsCtlSignature }) }, SecurityMgmtPsid }

EeEcaCertRequestSpdu

This structure is the SPDU used to send a signed CertManagementInfoStatus. For the signature to be valid the signing certificate shall conform to the RA certificate profile given in 7.6.3.10 or the DC certificate profile given in 7.6.3.4. This structure is the SPDU used to send a signed EeEcaCertRequest, as follows:

EeEcaCertRequestSpdu ::= Ieee1609Dot2Data-SignedCertRequest { ScmsPdu-Scoped { EcaEeInterfacePdu (WITH COMPONENTS { eeEcaCertRequest }) }, SignerSelf }

EcaEeCertResponseSpdu

This structure is the SPDU used to send a signed EcaEeCertResponse. For the signature to be valid, the signing certificate shall contain a PSID equal to SecurityMgmtPsid and a corresponding SSP containing the C-OER encoding of a SecurityMgmtSsp indicating EcaSsp.

EcaEeCertResponseSpdu ::= Ieee1609Dot2Data-Signed { ScmsPdu-Scoped { EcaEeInterfacePdu (WITH COMPONENTS { ecaEeCertResponse }) }, SecurityMgmtPsid }

EeRaCertRequestSpdu

This structure is the SPDU used to send a signed then encrypted EeRaCertRequest. It is a choice of the IEEE 1609.2 authenticated certificate request, which may be any kind of EE-RA certificate request, and the ITU-T X.509 certificate request, which is required to be an authorization certificate request.

EeRaCertRequestSpdu ::= Ieee1609Dot2Data ( EeRa1609Dot2AuthenticatedCertRequestSpdu | EeRaX509AuthenticatedCertRequestSpdu )

EeRaX509AuthenticatedCertRequestSpdu

This structure is the SPDU used to send a signed then encrypted IEEE 1609.2 authenticated certificate request. The EE signs this structure using its enrollment certificate. The enrollment certificate shall conform to the enrollment certificate profile given in 7.6.3.7. The EE encrypts the signed structure using the encryptionKey from the RA's certificate. This structure is the SPDU used to send a signed then encrypted ITU-T X.509authenticated certificate request. The EE signs this structure using its enrollment certificate. The enrollment certificate shall conform to the enrollment certificate profile given in 7.6.3.8. The EE encrypts the signed structure using the encryptionKey from the RA's certificate.

EeRaX509AuthenticatedCertRequestSpdu ::= Ieee1609Dot2Data-Encrypted { Ieee1609Dot2Data-SignedX509AuthenticatedCertRequest { ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { eeRaCertRequest }) }, SignerSingleX509Cert } }

RaEeCertAckSpdu

This structure is the SPDU used to send a signed RaEeCertAck to acknowledge the receipt of an EeRaCertRequestSpdu. For the signature to be valid the signing certificate shall conform to the RA certificate profile given in 7.6.3.10.

RaEeCertAckSpdu ::= Ieee1609Dot2Data-Signed { ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { raEeCertAck }) }, SecurityMgmtPsid }

RaEeCertInfoSpdu

This structure is the SPDU used to create an unsigned .info file to be included in a certificate batch zip file as specified in 8.2. This SPDU is used if the RaEeCertInfo does not contain an acpcTreeId field.

RaEeCertInfoSpdu ::= Ieee1609Dot2Data-Unsecured { ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { raEeCertInfo (WITH COMPONENTS { acpcTreeId ABSENT }) }) } }

RaEeCertAndAcpcInfoSpdu

This structure is the SPDU used to create a signed .info file to be included in a certificate batch zip file as specified in 8.2. This SPDU is used if the RaEeCertInfo contains an acpcTreeId field. For the signature to be valid the signing certificate shall conform to the RA certificate profile given in 7.6.3.10.

RaEeCertAndAcpcInfoSpdu ::= Ieee1609Dot2Data-Signed { ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { raEeCertInfo (WITH COMPONENTS { acpcTreeId PRESENT }) }) }, SecurityMgmtPsid }

EeRaDownloadRequestPlainSpdu

This structure is the SPDU used to send an unsecured EeRaDownloadRequest.

EeRaDownloadRequestPlainSpdu ::= Ieee1609Dot2Data-Unsecured { ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { eeRaDownloadRequest }) } }

EeRaDownloadRequestSpdu

This structure is the SPDU used to send a signed then encrypted EeRaDownloadRequest. The EE signs this structure using its enrollment certificate. The enrollment certificate shall conform to the enrollment certificate profile given in 7.6.3.7. The EE encrypts the signed structure using the encryptionKey from the RA's certificate.

EeRaDownloadRequestSpdu ::= Ieee1609Dot2Data-SignedEncrypted { ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { eeRaDownloadRequest }) }, SecurityMgmtPsid }

RaEeEnrollmentCertAckSpdu

This structure is the SPDU used to send a signed then encrypted EeEcaCertRequestSpdu. The EE signs this structure using its enrollment certificate. The enrollment certificate shall conform to the enrollment certificate profile given in 7.6.3.7. The EE encrypts the signed structure using the encryptionKey from the RA's certificate. This structure is the SPDU used to send a signed RaEeCertInfo. For the signature to be valid the signing certificate shall conform to the RA certificate profile given in 7.6.3.10.

RaEeEnrollmentCertAckSpdu ::= Ieee1609Dot2Data-Signed { ScmsPdu-Scoped { EeRaInterfacePdu (WITH COMPONENTS { raEeCertInfo (WITH COMPONENTS { acpcTreeId ABSENT }) }) }, SecurityMgmtPsid }

SecurityMgmtSsp

This parent structure defines the SSP for SecurityMgmtPsid and encompasses all SSP structures defined in this document. An overview of this structure is as follows:

When this structure is used to form an entry in the opaque field of an SspRange in an IEEE 1609.2 certificate, the contents of that OCTET STRING shall be the C-OER encoding of the relevant SecurityMgmtSsp.

NOTE:

  1. The LOP is in the SSP for backward compatibility reasons, and in practice, in this design the LOP does not have a certificate.
  2. Previous versions of this structure accidentally introduced incompatibility with implementations based on non-standardized but deployed predecessors to this document. In particular, the version field inside the individual SSP structures was changed from Uint8(1) to Uint8(2), without any technical need for the change. To address this incompatibility, subtyping (i.e., (1) or (2)) has been removed, and guidance has been provided for assigning values to the version field.
SecurityMgmtSsp ::= CHOICE { elector ElectorSsp, root RootCaSsp, pg PgSsp, ica IcaSsp, eca EcaSsp, aca AcaSsp, crl CrlSignerSsp, dcm DcmSsp, la LaSsp, lop LopSsp, ma MaSsp, ra RaSsp, ee EeSsp, ..., dc DcSsp }

ElectorSsp

This structure defines the SSP for an elector when it is authorizing SecurityMgmtPsid messages.

ElectorSsp ::= SEQUENCE { version Uint8, ... }

RootCaSsp

This structure defines the SSP for a root CA when it is authorizing SecurityMgmtPsid messages.

RootCaSsp ::= SEQUENCE { version Uint8, ... }

PgSsp

This structure defines the SSP for a policy generator when it is authorizing SecurityMgmtPsid messages.

PgSsp ::= SEQUENCE { version Uint8, ... }

IcaSsp

This structure defines the SSP for an intermediate CA when it is authorizing SecurityMgmtPsid messages.

IcaSsp ::= SEQUENCE { version Uint8, ... }

EcaSsp

This structure defines the SSP for an enrollment CA when it is authorizing SecurityMgmtPsid messages.

EcaSsp ::= SEQUENCE { version Uint8, ... }

AcaSsp

This structure defines the SSP for an authorization CA when it is authorizing SecurityMgmtPsid messages.

AcaSsp ::= SEQUENCE { version Uint8, ... }

CrlSignerSsp

This structure defines the SSP for a CRL signer when it is authorizing SecurityMgmtPsid messages.

NOTE: The SSP for a CRL signer when signing CRLs is associated with PSID 0x0100 and is defined in IEEE Std 1609.2.

CrlSignerSsp ::= SEQUENCE { version Uint8, ... }

DcmSsp

This structure defines the SSP for a device configuration manager when it is authorizing SecurityMgmtPsid messages.

DcmSsp ::= SEQUENCE { version Uint8, ... }

LaSsp

This structure defines the SSP for a linkage authority (LA) when it is authorizing SecurityMgmtPsid messages.

LaSsp ::= SEQUENCE { version Uint8, laId Uint16, ... }

LopSsp

This structure defines the SSP for a location obscurer proxy (LOP) when it is authorizing SecurityMgmtPsid messages.

NOTE: The LOP is in the SSP for backward compatibility reasons, and in practice, in this design the LOP does not have a certificate.

LopSsp ::= SEQUENCE { version Uint8, ... }

MaSsp

This structure defines the SSP for a misbehavior authority when it is authorizing SecurityMgmtPsid messages. The certificate containing this SSP is the MA Certificate to which an end entity should encrypt misbehavior reports related to the indicated PSIDs.

MaSsp ::= SEQUENCE { version Uint8, relevantPsids SequenceOfPsid, ... }

RaSsp

This structure defines the SSP for an RA when it is authorizing SecurityMgmtPsid messages.

RaSsp ::= SEQUENCE { version Uint8, ... }

EeSsp

This structure defines the SSP for an end entity when it is authorizing SecurityMgmtPsid messages.

EeSsp ::= SEQUENCE { version Uint8, ... }

DcSsp

This structure defines the SSP for a distribution center when it is authorizing SecurityMgmtPsid messages.

DcSsp ::= SEQUENCE { version Uint8, ... }

AcpcSsp

This is a container for ACPC-related SSPs, specifying one SSP for each role. The AcpcSsp is associated with the AcpcPsid in the certificate access manager (CAM) certificate's appPermissions field. An overview of this structure is as follows:

When this structure is used to form a ServiceSpecificPermissions field in an IEEE 1609.2 certificate:

When this structure is used to form an entry in the opaque field of an SspRange in an IEEE 1609.2 certificate, the contents of that OCTET STRING shall be the C-OER encoding of the relevant AcpcSsp.

NOTE: New versions of the CAM SSP are expected to be handled by extending this structure rather than by use of a version number in the CamSsp structure.

AcpcSsp ::= CHOICE { cam CamSsp, ... }

CamSsp

This is a list of the ACPC Tree IDs for which the containing CAM certificate is entitled to sign a SignedAprvBinaryTree or a SignedIndividualAprv. The SSP entitles the certificate holder to sign either of these structures.

CamSsp ::= SEQUENCE (SIZE(1..MAX)) OF AcpcTreeId