Transport Layer Security (TLS) Authentication using ITS ETSI and IEEE certificates
draft-tls-certieee1609-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Panos Kampanakis , Telecom Paristech | ||
| Last updated | 2018-03-21 | ||
| Replaced by | draft-msahli-ipwave-ieee1609 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tls-certieee1609-00
TLS Working Group P. Kampanakis, Ed.
Internet-Draft Cisco
Intended status: Informational M. Msahli, Ed.
Expires: September 19, 2018 Telecom ParisTech
March 18, 2018
Transport Layer Security (TLS) Authentication using ITS ETSI and IEEE
certificates
draft-tls-certieee1609-02.txt
Abstract
This document specifies the use of two new certificate types to
authenticate TLS entities. The first type enables the use of a
certificate specified by the Institute of Electrical and Electronics
Engineers (IEEE) [IEEE-ITS] and the second by the European
Telecommunications Standards Institute (ETSI) [ETSI103097].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Kampanakis & Msahli Expires September 19, 2018 [Page 1]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3
4. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 6
5. Certificate Verification . . . . . . . . . . . . . . . . . . 6
5.1. IEEE 1609.2 certificates . . . . . . . . . . . . . . . . 6
5.2. ETSI TS 103 097 certificates . . . . . . . . . . . . . . 6
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. TLS Server uses the ETSI or IEEE Certificates . . . . . . 6
6.2. TLS Server and TLS Client use the ETSI or the IEEE
Certificates . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Certificates comparison . . . . . . . . . . . . . . 12
A.1. ETSI vs IEEE . . . . . . . . . . . . . . . . . . . . . . 12
A.2. ETSI vs X.509 . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. ETSI Encoding Example . . . . . . . . . . . . . . . 14
Appendix C. IEEE Encoding Example . . . . . . . . . . . . . . . 17
Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
At present, TLS protocol uses X509 [RFC5246] and Raw Pubic Key
[RFC7250] in order to authenticate servers and clients. This
document describes the use of certificates specified either by the
Institute of Electrical and Electronics Engineers (IEEE) [IEEE-ITS]
or the European Telecommunications Standards Institute (ETSI)
[ETSI103097]. These standards are defined in order to secure
communications in vehicular environments. Existing certificates,
such as X509 and Raw Pubic Key, are designed for Internet use,
particularly for flexibility and extensibility, and are not optimized
for bandwidth and processing time to support delay-sensitive
applications. This is why size-optimized certificates that meet the
ITS requirements were designed and standardized.
Kampanakis & Msahli Expires September 19, 2018 [Page 2]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
Two new values referring the previously mentioned certificated are
added to the "client_certificate_type" and the
"server_certificate_type" extensions defined in [RFC7250].
2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Extension Overview
The extension format for extended client and server hellos, which
uses the "extension_data" field, is used to carry the
"Certificate_Type_Extension" Structure.defined in RFC7250. The
CertificateType structure is an enum with values taken from the TLS
Certificate Types In order to negotiate the support of IEEE or ETSI
certificate-based authentication:
- The clients MAY include an extension of type
"client_certificate_type" in the extended client hello.
- The servers MAY include an extension of type
"server_certificate_type" in the extended server hello.
The extension_data" field of this extension SHALL contain a list of
supported certificate types proposed by the client as provided in
figure below:
Kampanakis & Msahli Expires September 19, 2018 [Page 3]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
opaque ASN.1Cert <1..2^24-1>
struct {
select(certificate_type){
// certificate type defined in this document.
case ETSI:
ASN.1Cert certificate_list<1..2^24-1>
// certificate type defined in this document.
case IEEE:
ASN.1Cert certificate_list<1..2^24-1>
// RawPublicKey defined in RFC 7250
// certificate type defined in this document.
case RawPublicKey:
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>
// X.509 certificate defined in RFC 5246
case X.509:
ASN.1Cert certificate_list<1..2^24-1>
// Additional certificate type based on
// "TLS Certificate Types" subregistry
};
} Certificate;
In case where the TLS server accepts the described extension, it
selects one of the certificate types in the extension described here.
Note that a server MAY authenticate the client using other
authentication methods. The client MAY at its discretion either
continue the handshake, or respond with a fatal message alert.
The end-entity certificate's public key has to be compatible with one
of the certificate types listed in extension described here.
Servers aware of the extension described here but not wishing to use
it, SHOULD gracefully not proceed with the negotiation.
4. Message Flow
The "client_certificate_type" message MUST be sent as the first
handshake message as illustrated in Figure 1 below.
Kampanakis & Msahli Expires September 19, 2018 [Page 4]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
client_hello,
client_certificate_type,
server_certificate_type ->
<- server_hello,
client_certificate_type,
server_certificate_type,
certificate,
server_key_exchange,
certificate_request,
server_hello_done
certificate,
client_key_exchange,
certificate_verify,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 1: Message Flow with certificate type extension
4.1. Client Hello
In order to indicate the support of IEEE or ETSI certificates,
clients MUST include an extension of type "client_certificate_type"
to the extended client hello message. The hello extension mechanism
is described in Section 4.1.2 of TLS 1.3 [RFC6961].
The extension 'client_certificate_type' sent in the client hello MAY
carry a list of supported certificate types, sorted by client
preference. It is a list in the case where the client supports
multiple certificate types.
In a vehicular environment, privacy is important. In order to
preserve anonymity, a client MUST include IEEE or ETSI certificate
types in the "client_certificate_type" extension certificates.
Clients respond along with their certificates by sending a
"Certificate" message immediately followed by the "ClientKeyExchange"
message. The premaster secret is generated according to the cipher
algorithm selected by the server in the ServerHello.cipher_suite.
Kampanakis & Msahli Expires September 19, 2018 [Page 5]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
4.2. Server Hello
When the server receives the client hello containing the
client_certificate_type extension and/or the server_certificate_type
extension. The following outcomes are possible:
- The server supports the extension described in this document.
It selects a certificate type from the client_certificate_type
field in the extended client hello and must take into account the
client authentication list priority.
- The server does not support the proposed certificate type and
terminates the session with a fatal alert of type
"unsupported_certificate".
5. Certificate Verification
5.1. IEEE 1609.2 certificates
Verification of an IEEE 1609.2 certificate or certificate chain is
described in section 5.5.2 of [IEEE-ITS].
5.2. ETSI TS 103 097 certificates
Verification of ETSI TS 103 097 certificate or certificate chain is
described in annex F of [ETSI102941].
6. Examples
Some of exchanged messages examples are illustrated in Figures 2 and
3.
6.1. TLS Server uses the ETSI or IEEE Certificates
This example shows the TLS authentication, where the TLS client
indicates its ability to receive and to validate an IEEE and ETSI
certificate from the server. Therefore, the client populates the
server_certificate_type extension with the ETSI or IEEE certificate
type as presented in figure 2. In this exchange the client indicates
its ability to process the X.509 or the Raw Public Keys.
Kampanakis & Msahli Expires September 19, 2018 [Page 6]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
client_hello,
client_certificate_type= (X.509, Raw Public Key ) ->
server_certificate_type= ( IEEE ord ETSI certificate) ->
<- server_hello,
client_certificate_type= (X.509, Raw Public Key ) ->
server_certificate_type= ( IEEE ord ETSI certificate),
certificate,
certificate_request,
server_hello_done
certificate,
client_key_exchange,
certificate_verify,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 2: Example with ETSI or IEEE certificate
6.2. TLS Server and TLS Client use the ETSI or the IEEE Certificates
This section shows an example where the TLS client as well as the TLS
server use the ETSI or IEEE certificates. In consequence, both the
server and the client populate the Client_Certificate_type and
server_certificate_type with extension ETSI or IEEE certificates as
mentioned in figure 3.
Kampanakis & Msahli Expires September 19, 2018 [Page 7]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
client_hello,
client_certificate_type= ( IEEE ord ETSI certificate) ->
server_certificate_type= ( IEEE ord ETSI certificate) ->
<- server_hello,
server_certificate_type= ( IEEE ord ETSI certificate),
certificate,
client_certificate_type= ( IEEE ord ETSI certificate),
certificate,
certificate_request,
server_hello_done
certificate,
certificate_verify,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 3: TLS Client and TLS Server use the ETSI or IEEE Certificates
7. Security Considerations
This section provides an overview of the basic security
considerations which need to be taken into account before
implementing the necessary security mechanisms. The security
considerations described throughout [RFC5246] apply here as well.
For security considerations in a vehicular environment, the minimal
use of any TLS extensions is recommended such as :
o The "client_certificate_type" [IANA value 19] extension who's
purpose was previously described in [RFC7250].
o The "server_certificate_type" [IANA value 20] extension who's
purpose was previously described in [RFC7250].
o The "SessionTicket" [IANA value 35] extension for session
resumption.
In addition, servers SHOULD not support renegotiation [RFC5746] which
presented Man-In-The-Middle (MITM) type attacks over the past years.
Kampanakis & Msahli Expires September 19, 2018 [Page 8]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
8. Privacy Considerations
For privacy considerations in a vehicular environment the use of ETSI
and IEEE certificate is recommended for many reasons:
In order to address the risk of a personal data leakage, messages
exchanged for V2V communications are signed using pseudonym
certificates IEEE and ETSI
The purpose of these certificates is to provide privacy relying on
geographical and/or temporal validity criteria, and minimizing the
exchange of private data
9. IANA Considerations
Existing IANA references have not been updated yet to point to this
document.
IANA is asked to register two new values in the "TLS Certificate
Types" registry of Transport Layer Security (TLS) Extensions [TLS-
Certificate-Types-Registry], as follows:
o Value: TBD Description: IEEE Reference: [THIS RFC]
o Value: TBD Description: ETSI Reference: [THIS RFC]
10. Acknowledgements
This document borrows a lot from
[draft-serhrouchni-tls-certieee1609-00]. The authors wish to thank
Eric Rescola and Ilari Liusvaara for their feedback and suggestions
on improving this document. Thanks are due to Sean Turner for his
valuable and detailed comments.
11. References
11.1. Normative References
[ETSI102941]
ETSI, "ETSI TS 102 941 v1.1.9 (2016-04): Intelligent
Transport Systems (ITS); Security; Trust and Privacy
Management", April 2016.
[ETSI103097]
ETSI, "ETSI TS 103 097 v1.2.1 (2015-06): Intelligent
Transport Systems (ITS); Security; Security header and
certificate formats", June 2015.
Kampanakis & Msahli Expires September 19, 2018 [Page 9]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
[IEEE-ITS]
IEEE 1609.2, "IEEE Standard for Wireless Access in
Vehicular Environments - Security Services for
Applications and Management Messages", 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", May 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", August 2008.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension"", February 2010.
[RFC6961] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", August 2017.
[RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen,
"Using Raw Public Keys in Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS)", June 2014.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", June 2014.
11.2. Informative References
[draft-serhrouchni-tls-certieee1609-00]
KAISER, A., LABIOD, H., LONC, B., MSAHLI, M., and A.
SERHROUCHNI, "Transport Layer Security (TLS)
Authentication using ITS ETSI and IEEE certificates",
august 2017.
[FIPS186] FIPS 186-4, "Digital Signature Standard", July 2013.
[ICSI] ICST project, "Analysis of timeliness of communication for
IEEE 1609.2", 2013.
[KARGL] Kargl, F., Papadimitratos, P., Buttyan, L., Muter, M.,
Schoch, E., Wiedersheim, B., Thong, T., Calandriello, G.,
Held, A., Kung, A., and J. Hubaux, "Secure Vehicular
Communications: Implementation, Performance, and Research
Challenges", November 2008.
Kampanakis & Msahli Expires September 19, 2018 [Page 10]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
[PETIT] Petit, J., "Analysis of ECDSA authentication processing in
VANETs", December 2009.
[SCHUTZE] Schutze, T., "Automotive security: Cryptography for Car2X
communication", March 2011.
[X696] ITU-T X.696, "Information Technology - ASN.1 encoding
rules: Specification of Octet Encoding Rules (OER)",
august 2014.
Kampanakis & Msahli Expires September 19, 2018 [Page 11]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
Appendix A. Certificates comparison
A.1. ETSI vs IEEE
The ETSI and IEEE 1609.2 represent the active standardization groups
in Europe and U.S those dealing with the security of vehicular
communications. Although defined for the same purpose, the different
security requirements have led to the definition of different
certificate formats.
+-----------------------+-----------------------+
| ETSI Certificate | IEEE Certificate |
+-----------------------+-----------------------+
| Version | Version |
+-----------------------+-----------------------+
| | Type |
+-----------------------+-----------------------+
| Signer_info | IssuerIdentifier |
+-----------------------+-----------------------+
| Subject_info | |
| Subject_attributes | ToBeSignedCertificate |
| Validity_restrictions | |
+-----------------------+-----------------------+
| Signature | Signature |
+-----------------------+-----------------------+
Figure 4: Certificates comparison
As given in Figure 4, the IEEE certificate contains same data
strucutres as the one defined by ETSI except "Type" field, which
specifies the type of certificate if it is implicit or explicit.
The main differences are listed below:
o The structure of US Security Credentials Management System (SCMS)
is different from EU PKI
o Revocation distribution is not supported yet in ETSI TS 103 097
o SCMS provides high privacy for pseudonym resolution with 2 Linkage
Authorities (LA1 and LA2): LA1/2 generate 2 linkage values that
are added in the certificate. This allow to connect all short-
term certificates from a specific device for ease of revocation in
the event of misbehavior.
o Certificate Encoding
Kampanakis & Msahli Expires September 19, 2018 [Page 12]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
* As described in the IEEE 1609.2 and ETSI standards, the
internal representation of the certificate structure is encoded
into a flat octet string in network byte order (i.e. big-
endian).
* IEEE 1609.2 is developing for future an ASN.1 version of the
standard using X.696 (OER) [X696].
A.2. ETSI vs X.509
o Distinguished Name: There is no Distinguished Name based on X.500
in C-ITS certificates. Instead, Subject Names are defined as a
string of maximum 32 bytes. There are no naming convention for
Subject Names and the unicity of Subject Names for CAs and end-
entities is not required. Pseudonym certificates does not use
Distinguished Names for pseudonymous authentication (Subject Name
is empty): the digest of the certificate is used as unique
identifier. It is defined as a HashedID8 attribute which
represents the 8 least significant bytes of the SHA-256 hash
computation of the certificate.
o Geographical attributes: The C-ITS certificates of CAs and end-
entities may contain geographical validity attributes (location)
which doesn't exist in x509.
o Trust Assurance Level (TAL): The C-ITS certificates of CAs and
end-entities must contain a TAL:
* For the security of a V2X communication system, assurance about
the in-vehicle security of participants is vital: the receiver
of a message has to be able to rely on the fact that the sender
has generated the message correctly (i.e. the car sensors
information is accurate and of integrity). Hence, a security
breach on the sender would have an impact on all the receivers
of a message.
* Only vehicles with a reasonable "level of security" should be
able to obtain certificates from the PKI. The Car-to-Car
Communication Consortium (C2C-CC) introduced different levels
of trust, defined as Trust Assurance Levels and the
authorization tickets (i.e. pseudonym certificates) of the
vehicle must include the value of the vehicle TAL.
In order to authenticate end-entities in TLS with ETSI certificates
the following issues still have to be addressed:
o No certificate profile for ITS-S Centre (i.e. Internet Server) is
defined yet in ETSI TS 103 097 specification.
Kampanakis & Msahli Expires September 19, 2018 [Page 13]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
o A field is required in certificates for ITS-S Centre to provide
the server's FQDN (Fully Qualified Domain Name). To this end,
either the use of the Subject Name field is possible (although the
size is limited to 32 bytes) or a new SubjectAttribute may be
defined for this purpose.
Appendix B. ETSI Encoding Example
The hex sequence shown in Figure 5 presents an encoded secured
message with signed payload as a generic encoded octet string.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
+---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--
01 | 02 80 ba 80 02 02 01 53 88 de c6 40 c6 e1 9e 01
02 | 00 52 00 00 04 d4 81 34 8a cd d1 d9 9c 1f fb a4
03 | c7 0e 6d 2a 5d 13 ca b0 a1 e6 cf 63 22 9f 69 79
04 | b4 53 c0 15 c7 da 3a 12 7c 8f 39 44 59 b1 2f 94
05 | d4 cb 9a 12 ce e1 1d 87 40 8d 91 ac 95 6c 90 c8
06 | b3 b2 9f 4c 22 02 e0 21 0b 24 03 01 00 00 25 04
07 | 01 00 00 00 0b 01 15 04 39 83 15 4c bc 02 03 00
08 | 00 00 71 ff 9a 0d 80 16 ca cb cd d8 1c d1 4f 81
09 | 94 3c dd c7 74 51 1e 2b f7 15 7b 33 e5 4f 7b 6b
10 | 6e 5b 5d 07 94 70 be 40 a6 46 e0 55 9c 19 89 28
11 | b5 b8 ed cf bd c2 29 70 53 95 1d bc 51 cb d6 a3
12 | e1 d0 00 00 01 41 ae 0f 26 64 c0 05 24 01 55 20
13 | 50 02 80 00 31 01 00 14 00 30 14 4a d9 f8 7e 59
14 | 9e 09 2b 00 00 00 00 00 00 00 00 80 00 00 00 00
15 | 00 00 00 07 d1 00 00 01 02 00 00 00 02 09 2b 40
16 | 56 b4 9d 20 0d 69 3a 40 1f ff ff fc 22 30 d4 1e
17 | 40 00 0f c0 00 7e 02 76 ea 87 33 a9 d7 4f ff d0
18 | 84 14 00 00 43 01 00 00 61 6d 42 37 dd 2c ea b7
19 | 27 31 c2 3b cb 5d 61 8f 88 17 df 0d a8 7b d2 b8
20 | d3 54 8f 71 09 8a f1 88 d2 43 04 a8 61 6a 95 bf
21 | 5e 07 45 a1 06 e9 33 9f 9e 69 ba b3 3c bc 68 28
22 | 93 5a 66 ea 11 a0 37 69
Figure 5: Example of encoded ETSI secured message with signed payload
In the parsed data structure, the contents are presented in the form:
struct SecuredMessage {
uint8 protocol_version: 2
HeaderField<186> header_fields {
struct HeaderField {
HeaderFieldType type: signer_info (128)
struct SignerInfo signer {
SignerInfoType type: certificate (2)
struct Certificate certificate {
Kampanakis & Msahli Expires September 19, 2018 [Page 14]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
uint8 version: 2
struct SignerInfo signer_info {
SignerInfoType type: certificate_digest_with_sha256 (1)
HashedId8 digest: 5388DEC640C6E19E
}
struct SubjectInfo subject_info {
SubjectType subject_type: authorization_ticket (1)
opaque<0> subject_name:
}
SubjectAttribute<82> subject_attributes {
struct SubjectAttribute {
SubjectAttributeType type: verification_key (0)
struct PublicKey key {
PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_
sha256 (0)
struct EccPoint public_key {
EccPointType type: uncompressed (4)
opaque[32] x: D481348ACDD1D99C1FFBA4C70E6D2A5D
13CAB0A1E6CF63229F6979B453C015C7
opaque[32] y: DA3A127C8F394459B12F94D4CB9A12CE
E11D87408D91AC956C90C8B3B29F4C22
}
}
}
struct SubjectAttribute {
SubjectAttributeType type: assurance_level (2)
SubjectAssurance assurance_level: assurance level = 7,
confidence = 0
(bitmask = 11100000)
}
struct SubjectAttribute {
SubjectAttributeType type: its_aid_ssp_list (33)
ItsAidSsp<11> its_aid_ssp_list {
struct ItsAidSsp {
IntX its_aid: 36
opaque<3> service_specific_permissions: 010000
}
struct ItsAidSsp {
IntX its_aid: 37
opaque<4> service_specific_permissions: 01000000
}
}
}
}
ValidityRestriction<11> validity_restrictions {
struct ValidityRestriction {
ValidityRestrictionType type: time_start_and_end (1)
Time32 start_validity: 2015-03-05 00:00:00 UTC
Kampanakis & Msahli Expires September 19, 2018 [Page 15]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
Time32 end_validity: 2015-04-28 23:59:59 UTC
}
struct ValidityRestriction {
ValidityRestrictionType type: region (3)
struct GeographicRegion region {
RegionType region_type: none (0)
}
}
}
struct Signature {
PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_sha256
(0)
struct EcdsaSignature ecdsa_signature {
struct EccPoint R {
EccPointType type: x_coordinate_only (0)
opaque[32] x: 71FF9A0D8016CACBCDD81CD14F81943C
DDC774511E2BF7157B33E54F7B6B6E5B
}
opaque[32] s: 5D079470BE40A646E0559C198928B5B8
EDCFBDC2297053951DBC51CBD6A3E1D0
}
}
}
}
}
struct HeaderField {
HeaderFieldType type: generation_time (0)
Time64 generation_time: 2015-03-17 15:26:48.000 UTC
}
struct HeaderField {
HeaderFieldType type: its_aid (5)
IntX its_aid: 36
}
}
struct Payload payload_field {
PayloadType type: signed (1)
opaque<85> data: 2050028000310100140030144AD9F87E
599E092B000000000000000080000000
0000000007D10000010200000002092B
4056B49D200D693A401FFFFFFC2230D4
1E40000FC0007E0276EA8733A9D74FFF
D084140000
}
TrailerField<67> trailer_fields {
struct TrailerField {
TrailerFieldType type: signature (1)
struct Signature signature {
PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_sha256 (0)
Kampanakis & Msahli Expires September 19, 2018 [Page 16]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
struct EcdsaSignature ecdsa_signature {
struct EccPoint R {
EccPointType type: x_coordinate_only (0)
opaque[32] x: 616D4237DD2CEAB72731C23BCB5D618F
8817DF0DA87BD2B8D3548F71098AF188
}
opaque[32] s: D24304A8616A95BF5E0745A106E9339F
9E69BAB33CBC6828935A66EA11A03769
}
}
}
}
}
Figure 6: Example of parsed ETSI secured message with signed payload
Appendix C. IEEE Encoding Example
The hex sequence shown in Figure 7 presents an encoded signed data
structure as a flat encoded octet string.
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
+---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--
01 | 02 01 03 02 02 04 f3 db 4f 6f ca b6 49 65 01 09
02 | 63 65 72 74 4e 61 6d 65 31 01 05 e0 00 00 01 00
03 | 04 00 00 00 00 00 00 00 01 00 02 d4 a8 61 1d ce
04 | d8 8c a7 a2 e9 6a 8d 7e 49 0f 3c 9a 46 27 c0 72
05 | 26 ed 67 8d 04 74 41 02 00 03 9c b6 6f 87 4a 40
06 | 7c 21 83 40 22 db 6d 0a 80 d0 14 cb df 24 fc a0
07 | 83 f8 e2 00 81 b0 7c 14 b8 e7 02 19 90 d0 57 4b
08 | 14 d2 80 29 1f c4 e6 a6 73 12 68 74 96 77 c2 52
09 | 34 ae bb e4 29 da 16 60 61 19 74 c6 b3 53 98 0e
10 | 70 e3 3d 4f b9 03 99 76 05 44 e9 74 70 d9 92 bb
11 | 3c 37 92 c3 51 d4 7d 8e ea b1 03 0a e0 00 00 01
12 | 0c 73 6f 6d 65 20 63 6f 6e 74 65 6e 74 00 00 e7
13 | 2a dc 3e dc 09 00 00 00 00 00 00 00 00 00 00 00
14 | 02 ca bf a2 0d 82 ae 3e 25 a3 8c 9c dd 2e cf 94
15 | 9f cc 7c 7f d9 d8 83 89 f5 08 f7 aa bb 5b ef 21
16 | bd 7a 2e 79 6c c7 de 01 af b1 93 35 5b e2 f5 88
17 | 19 76 70 e4 ae 09 cf 3b ee
Figure 7: Example of encoded IEEE 1609.2 v2 signed data structure
In the parsed data structure, the contents are presented in the form:
protocol_version (0, 1): 02
type (1, 1): 01 (signed)
Kampanakis & Msahli Expires September 19, 2018 [Page 17]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
signed_data (2, 263):
signer (2, 169):
type (2, 1): 03 (certificate)
certificates (3, 168):
version_and_type (3, 1): 02 (explicit)
unsigned_certificate (4, 102):
holder_type (4, 1): 02 (identified localized)
cf (5, 1): 04 (encryption_key)
signer_id (6, 8): f3 db 4f 6f ca b6 49 65
signature_alg (14, 1): 01 (ECDSA NIST P256)
scope (15, 18):
id_scope (15, 18):
name_len (15, 1): 09
name (16, 9): 63 65 72 74 4e 61 6d 65 31
permissions (25, 7):
type (25, 1): 01 (specified)
permissions_list_len (26, 1): 05
permissions_list (27, 5):
psid (27, 4): e0 00 00 01
service_specific_permissions_len (31, 1): 00
region (32, 1):
region_type (32, 1): 04 (none)
expiration (33, 4): 00 00 00 00 (00:00:34 01 Jan 2004 UTC)
crl_series (37, 4): 00 00 00 01
verification_key (41, 30):
algorithm (41, 1): 00 (ECDSA NIST P224)
public_key (42, 29):
type (42, 1): 02 (compressed, lsb of y is 0)
x (43, 28):
d4 a8 61 1d ce d8 8c a7 a2 e9 6a 8d 7e 49 0f 3c
9a 46 27 c0 72 26 ed 67 8d 04 74 41
encryption_key (71, 35):
algorithm (71, 1): 02 (ECIES NIST P256)
supported_symm_alg (72, 1): 00 (AES 128 CCM)
public_key (73, 33):
type (73, 1): 03 (compressed, lsb of y is 1)
x (74, 32):
9c b6 6f 87 4a 40 7c 21 83 40 22 db 6d 0a 80 d0
14 cb df 24 fc a0 83 f8 e2 00 81 b0 7c 14 b8 e7
signature (106, 65):
ecdsa_signature (106, 65):
R (106, 33):
type (106, 1): 02 (compressed, lsb of y is 0)
x (107, 32):
19 90 d0 57 4b 14 d2 80 29 1f c4 e6 a6 73 12 68
74 96 77 c2 52 34 ae bb e4 29 da 16 60 61 19 74
s (139, 32):
c6 b3 53 98 0e 70 e3 3d 4f b9 03 99 76 05 44 e9
Kampanakis & Msahli Expires September 19, 2018 [Page 18]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
74 70 d9 92 bb 3c 37 92 c3 51 d4 7d 8e ea b1 03
unsigned_data (171, 37):
tf (171, 1): 0a (use_generation_time, use_location)
psid (172, 4): e0 00 00 01
data_len (176, 1): 0c
data (177, 12): 73 6f 6d 65 20 63 6f 6e 74 65 6e 74
generation_time (189, 9):
time (189, 8): 00 00 e7 2a dc 3e dc 09
(19:08:23 20 Jan 2012 UTC)
log_std_dev (197, 1): 00 (1.134666 ns or less)
generation_location (198, 10):
latitude (198, 4): 00 00 00 00
longitude (202, 4): 00 00 00 00
elevation (206, 2): 00 00
signature (208, 57):
ecdsa_signature (208, 57):
R (208, 29):
type (208, 1): 02 (compressed, lsb of y is 0)
x (209, 28):
ca bf a2 0d 82 ae 3e 25 a3 8c 9c dd 2e cf 94 9f
cc 7c 7f d9 d8 83 89 f5 08 f7 aa bb
s (237, 28):
5b ef 21 bd 7a 2e 79 6c c7 de 01 af b1 93 35 5b
e2 f5 88 19 76 70 e4 ae 09 cf 3b ee
Figure 8: Example of parsed IEEE 1609.2 v2 signed data structure
Appendix D. Contributors
o Nancy Cam-Winget
CISCO, USA
ncamwing@cisco.com
o Maik Seewald
CISCO, USA
maseewal@cisco.com
o Houda Labiod
Telecom Paristech, France
houda.labiod@telecom-paristech.fr
o Ahmed Serhrouchni
Telecom ParisTech
ahmed.serhrouchni@telecom-paristech.fr
Kampanakis & Msahli Expires September 19, 2018 [Page 19]
Internet-Draft IEEE and ETSI Certificate Types for TLS March 2018
Authors' Addresses
Panos Kampanakis (editor)
Cisco
USA
EMail: EMail: pkampana@cisco.com
Mounira Msahli (editor)
Telecom ParisTech
France
EMail: mounira.msahli@telecom-paristech.fr
Kampanakis & Msahli Expires September 19, 2018 [Page 20]