Pilot PKI Security Management Message Formats · 2016-07-28 · Pilot PKI Security Management...

CAR 2 CAR Communication Consortium

Pilot-PKI-SecManFormats v1.1 · 25.07.2013 of 15

Pilot PKI

Security Management Message Formats


Workgroup Security

Partners of the C2C-CC



Document information

Company: CAR 2 CAR Communication Consortium

Document title: C2C-CC Pilot PKI


Document ID: Pilot-PKI-SecManFormats

Confidence: CO: C2C-CC Partner RE: C2C-CC Members PU: Public

Version: 1.1 Date: 25.07.2013 Number of pages: 15

File name: Pilot-PKI_SecurityManagementFormats.docx

Author:

Company /Institute

Author Chapter

ESCRYPT Daniel Estor all

Fraunhofer SIT Norbert Bißmeyer all

Fraunhofer SIT Daniel Quanz all

Fraunhofer SIT Sebastian Mauthofer all

Approval:

Function Name Date Signature



Track changes

Title: CAR 2 CAR Communication Consortium Pilot PKI


Explanatory notes:

Issue Rev. Date Changes Edited by Approved

0 1 22.11.2012 Document template Estor

0 2 22.11.2012 Add LTC request / response

Minor corrections

Bißmeyer

0 3 23.11.12 Minor corrections Estor

0 4 23.11.12 Integrated signature and optional encryption in the protocol

Introduced SMMPayload,

Removed Webservice section

Estor

0 5 27.11.12 - changed all types to camel case

- added Crl, CrlRequest, ResponseAcknowledgment

- added references and links to 103097 in the appendix and in the description of the SMM formats

Bißmeyer

0 6 28.11.12 - Correction of section numbering

- Correction of SMM type names

Bißmeyer

0 7 12.12.12 - Correction in section 2.1

- Description in section 2 added

Bißmeyer

0 8 18.12.12 - Comments in 2.8 + 2.10 Quanz

0 9 18.12.12 - Correction in 2.6: type “self” added

- Correction in 2.7: typo “certificate_chain”

Quanz

0 10 19.12.12 Update + Comments in 2.7

Comments in 2.8 + 2.9

Update 2.10: Remove PublicKeys

Quanz

0 11 20.12.12 Removed number_of_certificates in 2.8 and 2.9, removed PKAlgorithm in 2.7

Corrected typo in 2.4 case signer_info

Estor

0 12 21.12.12 Recommendation to remove types in section 2.4 + 2.5

Quanz

0 13 25.02.13 Extended documentation about CRL Estor

0 14 21.03.13 Formats changed Estor, Bißmeyer, Mauthofer

0 15 27.03.13 Signatur + Signer added to LTC request

Estor, Bißmeyer

0 16 28.03.13 Corrected typos in 2.3, 2.11 and 2.13 Estor



0 17 02.04.13 Changes from Elmar Schoch added Bißmeyer, Mauthofer

0 18 10.04.13 Info about signature in the PcRequest, LtcRequest, Crl and ConfigurationResponse added.

Bißmeyer

0 19 11.04.13 Corrected typos in 2.2, 2.11, 2.13, 2.16 Estor

0 20 12.04.13 2.1 Changed list of CaCertificateRequests to only one request

Estor

0 21 16.04.13 2.10 CaCertificateResponse: allow list of CRLs

2.5 LtcResponse: Description of cert chain added.

2.3 SmmSignerInfo: Description of content added.

Version of 103 097 changed to v1.1.1

Bißmeyer

0 22 06.05.13 Description in section 2.13 changed Bißmeyer

1 0 28.05.13 Switch to final version number Bißmeyer

1 1 25.07.13 Minor text correction in section 2.5 (PcRequest)

Numbering corrected

Bißmeyer



Content

Partners of the C2C-CC ............................................................................................................... 1

Document information .................................................................................................................. 2

Track changes .............................................................................................................................. 3

Content ......................................................................................................................................... 5

1 Message Formats ................................................................................................................. 6

2 Format Specification ............................................................................................................. 7 2.1 SecurityManagementMessage ...................................................................................... 7 2.2 SmmType ....................................................................................................................... 7 2.3 SmmSignerInfo .............................................................................................................. 8 2.4 SmmSignerInfoType ...................................................................................................... 8 2.5 PcRequest ..................................................................................................................... 9 2.6 PcResponse ................................................................................................................... 9 2.7 LtcRequest ................................................................................................................... 10 2.8 LtcResponse ................................................................................................................ 10 2.9 RequestErrorCode ....................................................................................................... 10 2.10 RequestError ................................................................................................................ 11 2.11 ResponseAcknowledgment ......................................................................................... 11 2.12 CaCertificateRequest ................................................................................................... 11 2.13 CaCertificateResponse ................................................................................................ 11 2.14 CrlRequest ................................................................................................................... 12 2.15 Crl ................................................................................................................................ 12 2.16 ToBeSignedCrl ............................................................................................................. 12 2.17 CrlDataType ................................................................................................................. 13 2.18 CaConfigurationRequest .............................................................................................. 13 2.19 CaConfigurationResponse ........................................................................................... 14

3 Appendix 1 – References .................................................................................................... 15 3.1 List of abbreviations ..................................................................................................... 15 3.2 Applicable documents .................................................................................................. 15 3.3 Related documents ...................................................................................................... 15



1 Message Formats

This document defines formats of Security Management Messages (SMM) for the Pilot PKI of the Car 2 Car Communication Consortium. These message formats are used in the communication between an ITS station and the Certificate Authorities. In this document, message formats for the following processes are defined:

Request and response of CA certificates and certificates that were issued by a CAs as specified in section 2.12 and 2.13.

Request, response and response acknowledgement of long-term certificates as specified in section 2.7 and 2.8.

Request, response and response acknowledgement of pseudonym certificates as specified in section 2.5 and 2.6.

Request and response of CRLs as specified in section 2.14 and 2.15.

End-to-end encryption and integrity protection is out of the scope of this document. For the Pilot PKI, the preferred solution is to use SOAP webservices over https with server authentication via TLS. However, the format also allows for encapsulation of an SMM into a SecuredMessage as defined in ETSI TS 103 097 [1].

The message formats for inter-CA communication are not defined in this document.

The SMM presentation language is equal to the presentation language specified in ETSI TS 103 097 [1].



2 Format Specification

2.1 SecurityManagementMessage

struct {

uint8 protocol_version;

SmmType type;

select(type) {

case request_error:

RequestError error_message;

case ltc_request:

LtcRequest ltc_request;

case ltc_response:

LtcResponse ltc_response;

case pc_request:

PcRequest pc_request;

case pc_response:

PcResponse pc_response;

case response_ack:

ResponseAcknowledgment response_ack;

case crl_request:

CrlRequest crl_request;

case crl_response:

Crl crl;

case ca_cert_request:

CaCertificateRequest ca_cert_request;

case ca_cert_response:

CaCertificateResponse ca_cert_response<var>;

case ca_configuration_request:

CaConfigurationRequest config_request;

case ca_configuration_response:

CaConfigurationResponse config_response;

}

} SecurityManagementMessage;

2.2 SmmType

enum {

request_error(0),

ltc_request(1),

ltc_response(2),

pc_request(3),

pc_response(4),

response_ack(5),

crl_request(6),

crl_response(7),

ca_cert_request(8),

ca_cert_response(9),

ca_configuration_request(10),



ca_configuration_response(11),

reserved(240..250),

(2^8-1)

} SmmType;

2.3 SmmSignerInfo

struct {

SmmSignerInfoType type;

select(type){

case self:

;

case certificate_digest_with_ecdsap256:

HashedId8 digest;

case certificate:

Certificate certificate;

case certificate_chain:

Certificate certificate_chain<var>;

case encrypted:

EncryptionParameters enc_params;

RecipientInfo recipients<var>;

opaque enc_data<var>;

case module_id:

unknown:

opaque info<var>;

}

} SmmSignerInfo;

The following fields are defined in ETSI TS 103 097 [1]:

HashedId8

Certificate

RecipientInfo

EncryptionParameters

In the case of encrypted signer information (type = encrypted), enc_data shall contain a serialized SmmSignerInfo structure.

The remaining structure elements are following the descriptions of the SignerInfo in ETSI TS 103 097 [1].

2.4 SmmSignerInfoType

enum {

self(0),

certificate_digest_with_ecdsap256(1),

certificate(2),

certificate_chain(3),

encrypted (6),

module_id (7),

reserved(240..255),

(2^8-1)

} SmmSignerInfoType;



2.5 PcRequest

struct {

uint8 certificate_protocol_version;

SmmSignerInfo signerInfo;

PublicKey verification_keys<var>;

PublicKey encryption_keys<var>;

SubjectAttribute subject_attributes<var>;

ValidityRestriction validity_restrictions<var>;

Signature signature;

} PcRequest;

The certificate_protocol_version shall contain the desired certificate version. Encryption keys are optional. The number of encryption keys must be smaller or equal to the number of verification keys.

The signerInfo contains information about the request signer. Unless a certificate policy or profile explicitly allows other types of SmmSignerInfo, it shall be encrypted using the public key of the LTCA that issued the message signer's LTC. The signature shall be calculated over the encoding of the protocol_version of the SecurityManagementMessage and all preceding fields of the PcRequest, including all encoded lengths. The private key corresponding to the LTC shall be used for the signature.

The following fields are defined in TS 103 097 [1]:

PublicKey

SubjectAttribute

ValidityRestriction

Signature

The number of encryption_keys shall be smaller or equal to the number of verification_keys.

Unless explicitly stated in a certificate policy or profile, the subject_attribute list shall neither contain public keys nor a reconstruction value. It may contain an assurance level1 and any combination of its_aid_list, its_aid_ssp_list, its_aid_priority_list and its_id_priority_ssp_list as long as every its_aid is contained at most in one of the lists. All given subject_attributes shall be in the order as defined in ETSI TS 103 097 [1]. The ValidityRestrictions shall be used as in ETSI TS 103 097 [1]

The SubjectInfo is not part of the request because the pseudonym certificate does not contain a name and the SubjectType is set by the PCA to the appropriate value.

2.6 PcResponse

struct {

Certificate issued_certificates<var>;


} PcResponse;


Certificate

The field certificate_chain shall contain the certificate of the issuing PCA and optionally the certificate of the RCA that has issued the PCA certificate.



2.7 LtcRequest

struct {

uint8 certificate_protocol_version;

SmmSignerInfo signerInfo;

SubjectInfo subject_info;




} LtcRequest;

The signerInfo contains information about the request signer. The signature shall be calculated over all proceeding fields of the LtcRequest structure without any prior canonicalization.


SubjectInfo

PublicKey

SubjectAttribute

ValidityRestriction

The subject_attributes shall contain one verification public key and optionally one encryption public key.

The LtcRequest shall be signed using the private key according to the signerInfo.

The list of subject attributes may contain an assurance level and any combination of its_aid_list, its_aid_ssp_list, its_aid_priority_list and its_id_priority_ssp_list as long as every its_aid is contained at most in one of the lists.

The signature shall be calculated over the encoding of the protocol_version of the SecurityManagementMessage and all preceding fields of the LtcRequest, including all encoded lengths.

2.8 LtcResponse

struct {

Certificate issued_certificate;


} LtcResponse;


Certificate

The field certificate_chain shall contain the certificate of the issuing LTCA and optionally the certificate of the RCA that has issued the LCA certificate. The last element of the chain is the LTCA certificate that issued the LTC and the first element of the chain is the root certificate that issued the LTCA certificate. The chain may optionally be empty or contain only the LTCA certificate.

2.9 RequestErrorCode

enum {

verification_failure(0),

csr_cert_expired(1),

csr_cert_revoked(2),

csr_cert_unauthorized(3),

request_denied(4),



csr_cert_unknown (5),

canonical_identity_unknown (6),

ca_not_available(7),

message_processing_error(8),

request_in_process(9),

message_parsing_error(10),

ca_configuration_request_error(11),

reserved(240..255),

(2^8-1)

} RequestErrorCode;

2.10 RequestError

struct {

opaque request_hash[10];

RequestErrorCode reason;

} RequestError;

The request_hash is the first 10 bytes of the SHA-256 hash of the LtcRequest or PcRequest.

2.11 ResponseAcknowledgment

struct {

opaque request_hash[10];

} ResponseAcknowledgment;

The request_hash is the first 10 bytes of the SHA-256 hash of the LtcRequest or PcRequest.

2.12 CaCertificateRequest

struct {

HashedId8 requested_certificates<var>;

} CaCertificateRequest;


HashedId8

A CaCertificateRequest can be directed to any CA. However, LTCAs and PCAs shall not return Root CA certificates. If requested_certificates is an empty list, the contacted CA shall contain its own default certificate. The definition of the default certificate is out of scope of this document.

2.13 CaCertificateResponse

struct {

Certificate requested_certificates<var>;

Crl crl_path<var>;

} CaCertificateResponse;


Certificate



If the responding CA is not a Root CA, the crl_path shall be empty and the list requested_certificates shall contain the requested certificates in the same order as they appear in the CaCertificateRequest. The crl_path shall contain at most one CRL.

If the responding CA is a Root CA, a CaCertificateResponse shall contain one crl_path consisting of the most recent CRL which contians the signer's certificate and optionally the certificate of the CA that issued the CRL signer's certificate. The list of certificates shall contain all certificates that could appear on the CRL given in crl_path.

NOTE: A response to a CA certificate request may be a list containing several CaCertificateResponse.entries.

2.14 CrlRequest

struct {

HashedId8 issuer;

CrlSeries crl_series;

} CrlRequest;


HashedId8

CrlSeries

A CRL is always signed by a CRL signer. It only contains revoked certificates that were issued by the same Root CA that issued the CRL signer. The fields in this structure have the following meaning:

A CRL is always issued on behalf of a Root CA. Thus, the field issuer represents the RCA on whose behalf the requested CRL is being issued.

crl_series: A CA may define several CRL series to separate the CRL domains. The field series represents the series for which the CRL is requested.

The CA shall respond to this request by either providing the most recent full CRL.

2.15 Crl

struct {

uint8 version;

SignerInfo signer;

ToBeSignedCrl unsigned_crl;


} Crl;


SignerInfo

Signature

The signature shall be calculated over the encoding of all preceding fields including all encoded lengths.

2.16 ToBeSignedCrl

struct {

HashedId8 ca_id;

CrlSeries crl_series;



uint32 crl_serial;

Time32 start_period;

Time32 issue_date;

Time32 next_crl;

CrlDataType type;

select (type) {

case id_only:

HashedId8 entries<var>;

unknown:

opaque other_entries<var>;

}

} ToBeSignedCrl;


CrlSeries

HashedId8

Time32

The fields in this structure have the following meaning:

crl_series represents the CRL series for which this CRL is used.

ca_id contains the low-order eight octets of the hash of the certificate of the RCA for which this CRL is being issued.

crl_serial is a counter that should increment by 1 for every CRL within the given CRL series for the given issuer.

start_period and issue_date specify the time period that this CRL covers. The CRL shall include all certificates belonging to that crl_series that were revoked between start_period and issue_date. CRLs from the same issuer for the same crl_series may have overlapping time periods. If this is the case, any certificate revoked during the overlap period shall appear on multiple CRLs.

next_crl contains the time when the next CRL is expected to be issued.

entries contains identifiers for each revoked certificate.

2.17 CrlDataType

enum {

id_only(0),

(2^8-1)

} CrlDataType;

2.18 CaConfigurationRequest

struct {

HashedId8 ca<var>;

} CaConfigurationRequest;

An ITS-S can request the configuration from a CA in order to prepare subsequent certificate requests. This configuration aims to reduce the number of invalid certificate requests.


HashedId8



If the ca list is empty the receiver shall answer with its own configuration. Otherwise the configuration of all contained CAs shall be aggregated in the response representing the least common configuration. If one of the given is not known or the aggregation is not possible a RequestError is returned.

2.19 CaConfigurationResponse

struct {

SignerInfo signerInfo;



uint16 parallel_cert_number;


} CaConfigurationResponse;

The response contains the configuration of the CA.

The following fields are defined in TS 103 097 [1]:

SignerInfo

SubjectAttribute

ValidityRestriction

Signature

The parallel_cert_number is the maximum number of pseudonym certificates that can be issued for the same time interval. It can be defined that the requester can use several pseudonyms with the same start and expiry date. This allows a flexible usage of the currently valid pseudonym certificates and thus allows for optimized privacy algorithms.

The signature shall be calculated over the encoding of the protocol_version of the SecurityManagementMessage and all preceding fields of the CaConfigurationResponse, including all encoded lengths.



3 Appendix 1 – References

3.1 List of abbreviations

C2C-CC Car 2 Car Communication Consortium

CA Certificate Authority

CRL Certificate Revocation List

ITS Intelligent transportation system

LTCA Long-term Certificate Authority

PCA Pseudonym Certificate Authority

RCA Root Certificate Authority

SMM Security Management Message

3.2 Applicable documents

[AD-1]

[AD-2]

[AD-3]

[AD-4]

[AD-5]

[AD-6]

[AD-7]

[AD-8]

[AD-9]

3.3 Related documents

[1] ETSI TS 103 097 v1.1.1 (2013-04), Intelligent Transport Systems (ITS); Security; Security Header and Certificate Formats

[2] IEEE Std. 1609.2-2012 (draft D12): "Wireless Access in Vehicular Environments - Security Services for Applications and Management Messages"

[RD-1]

[RD-2]

[RD-3]

[RD-4]

■ End of Document ■

Pilot PKI Security Management Message Formats · 2016-07-28 · Pilot PKI Security Management...

Documents

Transcript of Pilot PKI Security Management Message Formats · 2016-07-28 · Pilot PKI Security Management...