This section provides an overview of the basic security considerations that need to be taken into account before implementing the necessary security mechanisms. The security considerations described throughout [RFC 8446
] apply here as well.
In particular, the certificates used to establish a secure connection MAY
be obtained from an online repository. An online repository may be used to obtain the CA certificates in the chain of either participant in the secure session. ETSI TS 102 941 [TS102941
] provides a mechanism that can be used to securely obtain ITS certificates.
Conventions around certificate lifetime differ between ITS certificates and X.509 certificates, and in particular, ITS certificates may be relatively short lived compared with typical X.509 certificates. A party to a TLS session that accepts ITS certificates MUST
check the expiry time in the received ITS certificate and SHOULD
terminate a session when the certificate received in the handshake expires.
All ITS certificates use public-key cryptographic algorithms with an estimated strength on the order of 128 bits or more, specifically, Elliptic Curve Cryptography (ECC) based on curves with keys of length 256 bits or longer. An implementation of the techniques specified in this document SHOULD
require that if X.509 certificates are used by one of the parties to the session, those certificates are associated with cryptographic algorithms with (pre-quantum-computer) strength of at least 128 bits.
ITS certificates in TLS express the certificate holders permissions using two fields: a PSID, also known as an ITS Application Identifier (ITS-AID), which identifies a broad set of application activities that provide a context for the certificate holder's permissions, and a Service Specific Permissions (SSP) field associated with that PSID, which identifies which specific application activities the certificate holder is entitled to carry out within the broad set of activities identified by that PSID. For example, SAE [SAEJ29453
] uses PSID 0204099 to indicate activities around reporting weather and managing weather response activities, and an SSP that states whether the certificate holder is a Weather Data Management System (WDMS, i.e., a central road manager), an ordinary vehicle, or a vehicle belonging to a managed road maintenance fleet. For more information about PSIDs, see [IEEE1609.12
], and for more information about the development of SSPs, see [SAEJ29455
The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data of type signed, where the signature contained in this Ieee1609Dot2Data was generated using an ITS certificate. This certificate may include multiple PSIDs. When a CertificateVerify message of this form is used, the HeaderInfo within the Ieee1609Dot2Data MUST
have the pduFunctionalType field present and set to tlsHandshake. The background to this requirement is as follows: an ITS certificate may (depending on the definition of the application associated with its PSID(s)) be used to directly sign messages or to sign TLS CertificateVerify messages, or both. To prevent the possibility that a signature generated in one context could be replayed in a different context, i.e., that a message signature could be replayed as a CertificateVerify, or vice versa, the pduFunctionalType field provides a statement of intent by the signer as to the intended use of the signed message. If the pduFunctionalType field is absent, the message is a directly signed message for the application and MUST NOT
be interpreted as a CertificateVerify.
Note that each PSID is owned by an owning organization that has sole rights to define activities associated with that PSID. If an application specifier wishes to expand activities associated with an existing PSID (for example, to include activities over a secure session such as specified in this document), that application specifier must negotiate with the PSID owner to have that functionality added to the official specification of activities associated with that PSID.