idnits 2.17.1 draft-serhrouchni-tls-certieee1609-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([IEEE-ITS], [ETSI103097]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In addition, servers SHOULD not support renegotiation [RFC5746] which presented Man-In-The-Middle (MITM) type attacks over the past years. -- The document date (October 21, 2016) is 2744 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'THIS RFC' is mentioned on line 208, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 253, but not defined -- Looks like a reference, but probably isn't: '32' on line 732 ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA Working Group A. KAISER 3 Internet-Draft IRT SystemX 4 Intended status: Informational H. LABIOD 5 Expires: April 24, 2017 Telecom Paristech 6 B. LONC 7 Renault 8 M. MSAHLI 9 Telecom Paristech 10 A. SERHROUCHNI 11 Telecom ParisTech 12 October 21, 2016 14 Transport Layer Security (TLS) Authentication using ITS ETSI and IEEE 15 certificates 16 draft-serhrouchni-tls-certieee1609-00.txt 18 Abstract 20 This document specifies the use of two new certificate types to 21 authenticate TLS entities. The first type enables the use of a 22 certificate specified by the Institute of Electrical and Electronics 23 Engineers (IEEE) [IEEE-ITS] and the second by the European 24 Telecommunications Standards Institute (ETSI) [ETSI103097]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 24, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 62 3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 6 68 7.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7 69 7.3. Client Authentication . . . . . . . . . . . . . . . . . . 7 70 8. Certificate Verification . . . . . . . . . . . . . . . . . . 8 71 8.1. IEEE 1609.2 certificates . . . . . . . . . . . . . . . . 8 72 8.2. ETSI TS 103 097 certificates . . . . . . . . . . . . . . 8 73 9. Certificates comparison . . . . . . . . . . . . . . . . . . . 10 74 9.1. ETSI vs IEEE . . . . . . . . . . . . . . . . . . . . . . 10 75 9.2. ETSI vs X.509 . . . . . . . . . . . . . . . . . . . . . . 11 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Appendix A. ETSI Encoding Example . . . . . . . . . . . . . . . 13 80 Appendix B. IEEE Encoding Example . . . . . . . . . . . . . . . 16 81 Appendix C. Co-authors' Addresses . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 At present, TLS protocol uses X509 [RFC5246] and OpenPGP digital 87 certificates [RFC6091] in order to authenticate servers and clients. 88 This document describes the use of certificates specified either by 89 the Institute of Electrical and Electronics Engineers (IEEE) 90 [IEEE-ITS] or the European Telecommunications Standards Institute 91 (ETSI) [ETSI103097]. These standards were defined in order to secure 92 communications in vehicular environments. Existing certificates, 93 such as X509 and OpenPGPG, are designed for Internet use, 94 particularly for flexibility and extensibility, and are not optimized 95 for bandwidth and processing time to support delay-sensitive 96 applications. This is why size-optimized certificates that meet the 97 ITS requirements were designed and standardized. 99 In addition, the purpose of these certificates is to provide privacy 100 relying on geographical and/or temporal validity criteria, and 101 minimizing the exchange of private data. 103 Two new values referring the previously mentioned certificated are 104 added to the "cert_type" extension defined in [RFC6091]. 106 2. Requirements Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Extension Overview 114 In order to negotiate the support of IEEE or ETSI certificate-based 115 authentication, clients MAY include an extension of type "cert_type" 116 in the extended client hello. The "extension_data" field of this 117 extension SHALL contain a list of supported certificate types 118 proposed by the client, where: 120 enum { 121 X.509(0), OpenPGP(1), RawPublicKey(2), 122 IEEE(TBD), ETSI(TBD), (255) 123 }CertificateType; 125 In case where the TLS server accepts the described extension, it 126 selects one of the certificate types in the extension described here. 127 The same extension type and structure will be used for the server's 128 response to the extension described here. Note that a server MAY 129 send no certificate type if it either does not support it or wishes 130 to authenticate the client using other authentication methods. The 131 client MAY at its discretion either continue the handshake, or 132 respond with a fatal message alert. 134 The end-entity certificate's public key has to be compatible with one 135 of the certificate types listed in extension described here. 137 Servers aware of the extension described here but not wishing to use 138 it, SHOULD gracefully revert to a classical TLS handshake or decide 139 not to proceed with the negotiation. 141 4. Security Considerations 142 This section provides an overview of the basic security 143 considerations which need to be taken into account before 144 implementing the necessary security mechanisms. The security 145 considerations described throughout [RFC5246] apply here as well. 147 For security considerations in a vehicular environment, the minimal 148 use of any TLS extensions is recommended such as : 150 o The "cert_type" [IANA value 9] extension who's purpose was 151 previously described in Section 3. 153 o The "elliptic_curves" [IANA value 10] extension which indicates 154 the set of elliptic curves supported by the client. 156 o The "SessionTicket" [IANA value 35] extension for session 157 resumption. 159 In addition, servers SHOULD not support renegotiation [RFC5746] which 160 presented Man-In-The-Middle (MITM) type attacks over the past years. 162 The ETSI and IEEE Standards propose the use of secp256r1 (aka NIST 163 P-256) recommended by the NIST FIPS 186-4 standard [FIPS186]. 165 Elliptic curve algorithms require significantly shorter public keys 166 to achieve the same security strength. ECC is the digital signature 167 algorithm of choice in the IEEE 1609.2 standard that specifies 168 security services and procedures designed for vehicle communications. 169 The ECDSA is specified in American National Standard (ANS) X9.62 . 170 NIST approved the use of ECDSA and specified additional requirements 171 in the FIPS Publication 186-4. 173 ECDSA also produces smaller signatures than RSA. The smaller key 174 sizes and signature sizes of ECDSA mean lower message overheads when 175 transporting ECDSA public keys over wireless networks compared with 176 transporting RSA or DSA public keys. This is important in a large 177 vehicle network where vehicles may often have to exchange their 178 public keys over bandwidth - limited wireless channels. The smaller 179 ECDSA key lengths can also translate into savings on computing power, 180 storage and memory space, and energy required to achieve the same 181 security strength [KARGL] [SCHUTZE] [PETIT] [ICSI]. This makes ECDSA 182 attractive for resource - constrained mobile devices, such as vehicle 183 on-board communication units. 185 The Standard defines ECIES as the encryption algorithm. Seen that 186 this RFC aims to client authentication, the use of this algorithm can 187 be optional for future use but not required. 189 AES-CCM provides both authentication and confidentiality (encryption 190 and decryption) and uses as its only primitive the AES encrypt block 191 cipher operation. This makes it amenable to compact implementations, 192 which are advantageous in constrained envrionments. Adoption outside 193 of constrained environments is necessary to enable interoperability, 194 such as that between web clients and embedded servers, or between 195 embedded clients and web servers. 197 5. IANA Considerations 199 Existing IANA references have not been updated yet to point to this 200 document. 202 IANA is asked to register two new values in the "TLS Certificate 203 Types" registry of Transport Layer Security (TLS) Extensions [TLS- 204 Certificate-Types-Registry], as follows: 206 o Value: TBD Description: IEEE Reference: [THIS RFC] 208 o Value: TBD Description: ETSI Reference: [THIS RFC] 210 6. Cipher Suites 212 The table below defines ECC cipher suites that should be used 213 [RFC7251]: 215 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM = {0xC0,0xAC} 216 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM = {0xC0,0xAD} 217 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 = {0xC0,0xAE} 218 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {0xC0,0xAF} 220 Figure 1: TLS ECC cipher suites 222 Server implementations SHOULD support all of the previous cipher 223 suites, and client implementations SHOULD support at least one of 224 them. Note that the versions "*_CCM_8" of cipher suites use a 64 225 bits tag rather than a 128 bits tag. Such cipher suites MAY be 226 preferred in ITS networks to gain in bandwidth and message size but 227 at the cost of a loss in integrity. 229 7. Message Flow 231 The "cert_type" message MUST be sent as the first handshake message 232 as illustrated in Figure 1 below. 234 Client Server 236 ClientHello 237 /* with 238 certificate type */ --------> 239 ServerHello 240 /* with 241 certificate type */ 242 Certificate 243 ServerKeyExchange* 244 CertificateRequest 245 <-------- ServerHelloDone 247 Certificate 248 ClientKeyExchange 249 CertificateVerify 251 [ChangeCipherSpec] 252 Finished --------> 253 [ChangeCipherSpec] 254 <-------- Finished 255 Application Data <-------> Application Data 257 * Indicates optional or situation-dependent messages that are not 258 always sent. Note that this document makes mandatory all messages 259 but the ServerKeyExchange. 261 Figure 2: Message Flow with certificate type extension 263 7.1. Client Hello 265 In order to indicate the support of IEEE or ETSI certificates, 266 clients MUST include an extension of type "cert_type" to the extended 267 client hello message. The hello extension mechanism is described in 268 Section 7.4.1.4 of TLS 1.2 [RFC5246]. 270 The extension 'cert_type' sent in the client hello MAY carry a list 271 of supported certificate types, sorted by client preference. It is a 272 list in the case where the client supports multiple certificate 273 types. 275 In a vehicular environment, privacy is important. In order to 276 preserve anonymity, a client MUST include IEEE or ETSI certificate 277 types in the "cert_type" extension prior to other supported 278 certificates. 280 A TLS client that proposes ECC algorithms in its ClientHello message 281 SHOULD include "elliptic_curves" extension [RFC4492]. 283 Clients respond along with their certificates by sending a 284 "Certificate" message immediately followed by the "ClientKeyExchange" 285 message. The premaster secret is generated according to the cipher 286 algorithm selected by the server in the ServerHello.cipher_suite. 288 7.2. Server Hello 290 If the server receives a client hello that contains the "cert_type" 291 extension and chooses a cipher suite that requires a certificate, 292 then two outcomes are possible. The server MUST either, select a 293 certificate type from the certificate_types field in the extended 294 client hello and must take into account the client list priority, or 295 terminate the session with a fatal alert of type 296 "unsupported_certificate". 298 The certificate type selected by the server is encoded in a 299 CertificateTypeExtension structure, which is included in the extended 300 server hello message using an extension of type "cert_type". 302 Servers implementing ECC cipher suites MUST support "elliptic_curves" 303 extension, and when a client uses this extension, servers MUST NOT 304 negotiate the use of an ECC cipher suite unless they can complete the 305 handshake while respecting the choice of curves and compression 306 techniques specified by the client [RFC4492]. 308 7.3. Client Authentication 310 Client authentication is done upon specific request of the server. 311 This procedure SHALL be done as described in section 7.4.4 of 312 [RFC5246]. 314 The figure below depicts the format of the CertificateRequest 315 message. 317 enum { 318 rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), 319 dss_fixed_dh(4), rsa_ephemeral_dh_RESERVED(5), 320 dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20), 321 ECDSA_sign(64), (255) 322 } ClientCertificateType; 324 opaque DistinguishedName<1..2^16-1>; 326 struct { 327 ClientCertificateType certificate_types<1..2^8-1>; 328 SignatureAndHashAlgorithm 329 supported_signature_algorithms<2^16-1>; 330 DistinguishedName certificate_authorities<0..2^16-1>; 332 } CertificateRequest; 334 Figure 3: Structure of the CertificateRequest message 336 The CertificateRequest SHALL be filled as follow: 338 ClientCertificateType ECDSA_sign(64) 340 SignatureAndHashAlgorithm {0x04,0x03} (ECDSA-SHA256) 342 DistinguishedName It MAY be used by the server to specify a 343 list of certificate authorities it trusts 344 (i.e. AA/PCA or EA/LTCA). If possible, 345 the client SHOULD then reply with a 346 certificate signed by one of the 347 certificate authorities trusted by the 348 server in order to avoid sending the 349 certificate chain. A certificate authority 350 is identified by its HashedId8 as defined 351 in section 4.2.12 of [ETSI103097]. That 352 is, DistinguishedName is a list of 353 HashedId8. If not used this field MUST be 354 empty. 356 8. Certificate Verification 358 8.1. IEEE 1609.2 certificates 360 Verification of an IEEE 1609.2 certificate or certificate chain is 361 described in section 5.5.2 of [IEEE-ITS]. 363 8.2. ETSI TS 103 097 certificates 365 The format of an ETSI TS 103 097 certificate is depicted in the 366 figure below. 368 +------+-------+--------+------------+----------+------+ 369 | | | | | | | 370 | ver- |signer |subject | subject_ | validity |sign- | 371 | sion |_info |_info | attributes | _restri- |ature | 372 | | | | | ctions | | 373 +------+-------+--------+------------+----------+------+ 374 ___________/\___________ 375 / \ 376 +----------+-------+-----+ 377 | verifi- | assu- |its | 378 | cation/ | rance |_aid | 379 | encryp- |_level |_ssp | 380 | tion key | | | 381 +----------+-------+-----+ 383 Figure 4: ETSI TS 103 097 certificate format 385 Verification of an ETSI TS 103 097 certificate or certificate chain 386 is described in annex F of [ETSI102941]. We add additional checks 387 below: 389 1. Verify the certificate's signer identity: 391 * If the certificate digest included in "signer_info" is known, 392 goto step 2. 394 * Else: 396 + If it is a root certificate digest, the verification has 397 failed (error - untrusted RCA) and the message SHALL be 398 discarded. 400 + Else: pause the current certificate verification process 401 and start verification of the next certificate in the chain 402 (which SHALL be the signer's certificate) recursively by 403 applying verification algorithm of [ETSI102941]. Once 404 verified, resume the certificate verification previously 405 paused. 407 2. Verify that the certificate is not in the Certificate Revocation 408 List (CRL). If it is, the verification has failed (error - 409 certificate in CRL) and the message SHALL be discarded. 411 3. Verify the signature of the certificate (see [RFC4492] for 412 details). 414 4. Verify "subject_info": "subject_name" SHALL be a 32 bytes hash of 415 the server URL. Note that this step is only done by clients that 416 are verifying a server's certificate. In the opposite case this 417 step SHALL be ignored. 419 5. Verify "validity_restrictions": only the validity of time is 420 checked, the validity of space (i.e. geographical region) is 421 ignored. 423 9. Certificates comparison 425 9.1. ETSI vs IEEE 427 The ETSI and IEEE 1609.2 represent the active standardization groups 428 in Europe and U.S those dealing with the security of vehicular 429 communications. Although defined for the same purpose, the different 430 security requirements have led to the definition of different 431 certificate formats. 433 +-----------------------+-----------------------+ 434 | ETSI Certificate | IEEE Certificate | 435 +-----------------------+-----------------------+ 436 | Version | Version | 437 +-----------------------+-----------------------+ 438 | | Type | 439 +-----------------------+-----------------------+ 440 | Signer_info | IssuerIdentifier | 441 +-----------------------+-----------------------+ 442 | Subject_info | | 443 | Subject_attributes | ToBeSignedCertificate | 444 | Validity_restrictions | | 445 +-----------------------+-----------------------+ 446 | Signature | Signature | 447 +-----------------------+-----------------------+ 449 Figure 5: Certificates comparison 451 As given in Figure 5, the IEEE certificate contains same data 452 strucutres as the one defined by ETSI except "Type" field, which 453 specifies the type of certificate if it is implicit or explicit. 455 The main differences are listed below: 457 o The structure of US Security Credentials Management System (SCMS) 458 is different from EU PKI 460 o Revocation distribution is not supported yet in ETSI TS 103 097 462 o SCMS provides high privacy for pseudonym resolution with 2 Linkage 463 Authorities (LA1 and LA2): LA1/2 generate 2 linkage values that 464 are added in the certificate. This allow to connect all short- 465 term certificates from a specific device for ease of revocation in 466 the event of misbehavior. 468 o Certificate Encoding 469 * As described in the IEEE 1609.2 and ETSI standards, the 470 internal representation of the certificate structure is encoded 471 into a flat octet string in network byte order (i.e. big- 472 endian). 474 * IEEE 1609.2 is developing for future an ASN.1 version of the 475 standard using X.696 (OER) [X696]. 477 9.2. ETSI vs X.509 479 o Distinguished Name: There is no Distinguished Name based on X.500 480 in C-ITS certificates. Instead, Subject Names are defined as a 481 string of maximum 32 bytes. There are no naming convention for 482 Subject Names and the unicity of Subject Names for CAs and end- 483 entities is not required. Pseudonym certificates does not use 484 Distinguished Names for pseudonymous authentication (Subject Name 485 is empty): the digest of the certificate is used as unique 486 identifier. It is defined as a HashedID8 attribute which 487 represents the 8 least significant bytes of the SHA-256 hash 488 computation of the certificate. 490 o Geographical attributes: The C-ITS certificates of CAs and end- 491 entities may contain geographical validity attributes (location) 492 which doesn't exist in x509. 494 o Trust Assurance Level (TAL): The C-ITS certificates of CAs and 495 end-entities must contain a TAL: 497 * For the security of a V2X communication system, assurance about 498 the in-vehicle security of participants is vital: the receiver 499 of a message has to be able to rely on the fact that the sender 500 has generated the message correctly (i.e. the car sensors 501 information is accurate and of integrity). Hence, a security 502 breach on the sender would have an impact on all the receivers 503 of a message. 505 * Only vehicles with a reasonable "level of security" should be 506 able to obtain certificates from the PKI. The Car-to-Car 507 Communication Consortium (C2C-CC) introduced different levels 508 of trust, defined as Trust Assurance Levels and the 509 authorization tickets (i.e. pseudonym certificates) of the 510 vehicle must include the value of the vehicle TAL. 512 In order to authenticate end-entities in TLS with ETSI certificates 513 the following issues still have to be addressed: 515 o No certificate profile for ITS-S Centre (i.e. Internet Server) is 516 defined yet in ETSI TS 103 097 specification. 518 o A field is required in certificates for ITS-S Centre to provide 519 the server's FQDN (Fully Qualified Domain Name). To this end, 520 either the use of the Subject Name field is possible (although the 521 size is limited to 32 bytes) or a new SubjectAttribute may be 522 defined for this purpose. 524 10. References 526 10.1. Normative References 528 [ETSI103097] 529 ETSI, , "ETSI TS 103 097 v1.1.1 (2013-04): Intelligent 530 Transport Systems (ITS); Security; Security header and 531 certificate formats", April 2013. 533 [IEEE-ITS] 534 IEEE 1609.2, , "IEEE Standard for Wireless Access in 535 Vehicular Environments - Security Services for 536 Applications and Management Messages", 2013. 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", March 1997. 541 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 542 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 543 for Transport Layer Security (TLS)", May 2006. 545 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 546 (TLS) Protocol Version 1.2", August 2008. 548 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 549 "Transport Layer Security (TLS) Renegotiation Indication 550 Extension"", February 2010. 552 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 553 for Transport Layer Security (TLS) Authentication", 554 February 2011. 556 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 557 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 558 TLS", June 2014. 560 [ETSI102941] 561 ETSI, , "ETSI TS 102 941 v1.1.9 (2016-04): Intelligent 562 Transport Systems (ITS); Security; Trust and Privacy 563 Management", April 2016. 565 10.2. Informative References 567 [FIPS186] FIPS 186-4, , "Digital Signature Standard", July 2013. 569 [KARGL] Kargl, F., Papadimitratos, P., Buttyan, L., Muter, M., 570 Schoch, E., Wiedersheim, B., Thong, T.-V., Calandriello, 571 G., Held, A., Kung, A., and J.-P. Hubaux, "Secure 572 Vehicular Communications: Implementation, Performance, and 573 Research Challenges", November 2008. 575 [SCHUTZE] Schutze, T., "Automotive security: Cryptography for Car2X 576 communication", March 2011. 578 [PETIT] Petit, J., "Analysis of ECDSA authentication processing in 579 VANETs", December 2009. 581 [ICSI] ICST project, , "Analysis of timeliness of communication 582 for IEEE 1609.2", 2013. 584 [X696] ITU-T X.696, , "Information Technology - ASN.1 encoding 585 rules: Specification of Octet Encoding Rules (OER)", 586 august 2014. 588 Appendix A. ETSI Encoding Example 590 The hex sequence shown in Figure 6 presents an encoded secured 591 message with signed payload as a generic encoded octet string. 593 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 594 +---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- 595 01 | 02 80 ba 80 02 02 01 53 88 de c6 40 c6 e1 9e 01 596 02 | 00 52 00 00 04 d4 81 34 8a cd d1 d9 9c 1f fb a4 597 03 | c7 0e 6d 2a 5d 13 ca b0 a1 e6 cf 63 22 9f 69 79 598 04 | b4 53 c0 15 c7 da 3a 12 7c 8f 39 44 59 b1 2f 94 599 05 | d4 cb 9a 12 ce e1 1d 87 40 8d 91 ac 95 6c 90 c8 600 06 | b3 b2 9f 4c 22 02 e0 21 0b 24 03 01 00 00 25 04 601 07 | 01 00 00 00 0b 01 15 04 39 83 15 4c bc 02 03 00 602 08 | 00 00 71 ff 9a 0d 80 16 ca cb cd d8 1c d1 4f 81 603 09 | 94 3c dd c7 74 51 1e 2b f7 15 7b 33 e5 4f 7b 6b 604 10 | 6e 5b 5d 07 94 70 be 40 a6 46 e0 55 9c 19 89 28 605 11 | b5 b8 ed cf bd c2 29 70 53 95 1d bc 51 cb d6 a3 606 12 | e1 d0 00 00 01 41 ae 0f 26 64 c0 05 24 01 55 20 607 13 | 50 02 80 00 31 01 00 14 00 30 14 4a d9 f8 7e 59 608 14 | 9e 09 2b 00 00 00 00 00 00 00 00 80 00 00 00 00 609 15 | 00 00 00 07 d1 00 00 01 02 00 00 00 02 09 2b 40 610 16 | 56 b4 9d 20 0d 69 3a 40 1f ff ff fc 22 30 d4 1e 611 17 | 40 00 0f c0 00 7e 02 76 ea 87 33 a9 d7 4f ff d0 612 18 | 84 14 00 00 43 01 00 00 61 6d 42 37 dd 2c ea b7 613 19 | 27 31 c2 3b cb 5d 61 8f 88 17 df 0d a8 7b d2 b8 614 20 | d3 54 8f 71 09 8a f1 88 d2 43 04 a8 61 6a 95 bf 615 21 | 5e 07 45 a1 06 e9 33 9f 9e 69 ba b3 3c bc 68 28 616 22 | 93 5a 66 ea 11 a0 37 69 618 Figure 6: Example of encoded ETSI secured message with signed payload 620 In the parsed data structure, the contents are presented in the form: 622 struct SecuredMessage { 623 uint8 protocol_version: 2 624 HeaderField<186> header_fields { 625 struct HeaderField { 626 HeaderFieldType type: signer_info (128) 627 struct SignerInfo signer { 628 SignerInfoType type: certificate (2) 629 struct Certificate certificate { 630 uint8 version: 2 631 struct SignerInfo signer_info { 632 SignerInfoType type: certificate_digest_with_sha256 (1) 633 HashedId8 digest: 5388DEC640C6E19E 634 } 635 struct SubjectInfo subject_info { 636 SubjectType subject_type: authorization_ticket (1) 637 opaque<0> subject_name: 638 } 639 SubjectAttribute<82> subject_attributes { 640 struct SubjectAttribute { 641 SubjectAttributeType type: verification_key (0) 642 struct PublicKey key { 643 PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_ 644 sha256 (0) 645 struct EccPoint public_key { 646 EccPointType type: uncompressed (4) 647 opaque[32] x: D481348ACDD1D99C1FFBA4C70E6D2A5D 648 13CAB0A1E6CF63229F6979B453C015C7 649 opaque[32] y: DA3A127C8F394459B12F94D4CB9A12CE 650 E11D87408D91AC956C90C8B3B29F4C22 651 } 652 } 653 } 654 struct SubjectAttribute { 655 SubjectAttributeType type: assurance_level (2) 656 SubjectAssurance assurance_level: assurance level = 7, 657 confidence = 0 658 (bitmask = 11100000) 659 } 660 struct SubjectAttribute { 661 SubjectAttributeType type: its_aid_ssp_list (33) 662 ItsAidSsp<11> its_aid_ssp_list { 663 struct ItsAidSsp { 664 IntX its_aid: 36 665 opaque<3> service_specific_permissions: 010000 666 } 667 struct ItsAidSsp { 668 IntX its_aid: 37 669 opaque<4> service_specific_permissions: 01000000 670 } 671 } 672 } 673 } 674 ValidityRestriction<11> validity_restrictions { 675 struct ValidityRestriction { 676 ValidityRestrictionType type: time_start_and_end (1) 677 Time32 start_validity: 2015-03-05 00:00:00 UTC 678 Time32 end_validity: 2015-04-28 23:59:59 UTC 679 } 680 struct ValidityRestriction { 681 ValidityRestrictionType type: region (3) 682 struct GeographicRegion region { 683 RegionType region_type: none (0) 684 } 685 } 686 } 687 struct Signature { 688 PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_sha256 (0) 689 struct EcdsaSignature ecdsa_signature { 690 struct EccPoint R { 691 EccPointType type: x_coordinate_only (0) 692 opaque[32] x: 71FF9A0D8016CACBCDD81CD14F81943C 693 DDC774511E2BF7157B33E54F7B6B6E5B 694 } 695 opaque[32] s: 5D079470BE40A646E0559C198928B5B8 696 EDCFBDC2297053951DBC51CBD6A3E1D0 697 } 698 } 699 } 700 } 701 } 702 struct HeaderField { 703 HeaderFieldType type: generation_time (0) 704 Time64 generation_time: 2015-03-17 15:26:48.000 UTC 705 } 706 struct HeaderField { 707 HeaderFieldType type: its_aid (5) 708 IntX its_aid: 36 710 } 711 } 712 struct Payload payload_field { 713 PayloadType type: signed (1) 714 opaque<85> data: 2050028000310100140030144AD9F87E 715 599E092B000000000000000080000000 716 0000000007D10000010200000002092B 717 4056B49D200D693A401FFFFFFC2230D4 718 1E40000FC0007E0276EA8733A9D74FFF 719 D084140000 720 } 721 TrailerField<67> trailer_fields { 722 struct TrailerField { 723 TrailerFieldType type: signature (1) 724 struct Signature signature { 725 PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_sha256 (0) 726 struct EcdsaSignature ecdsa_signature { 727 struct EccPoint R { 728 EccPointType type: x_coordinate_only (0) 729 opaque[32] x: 616D4237DD2CEAB72731C23BCB5D618F 730 8817DF0DA87BD2B8D3548F71098AF188 731 } 732 opaque[32] s: D24304A8616A95BF5E0745A106E9339F 733 9E69BAB33CBC6828935A66EA11A03769 734 } 735 } 736 } 737 } 738 } 740 Figure 7: Example of parsed ETSI secured message with signed payload 742 Appendix B. IEEE Encoding Example 744 The hex sequence shown in Figure 8 presents an encoded signed data 745 structure as a flat encoded octet string. 747 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 748 +---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- 749 01 | 02 01 03 02 02 04 f3 db 4f 6f ca b6 49 65 01 09 750 02 | 63 65 72 74 4e 61 6d 65 31 01 05 e0 00 00 01 00 751 03 | 04 00 00 00 00 00 00 00 01 00 02 d4 a8 61 1d ce 752 04 | d8 8c a7 a2 e9 6a 8d 7e 49 0f 3c 9a 46 27 c0 72 753 05 | 26 ed 67 8d 04 74 41 02 00 03 9c b6 6f 87 4a 40 754 06 | 7c 21 83 40 22 db 6d 0a 80 d0 14 cb df 24 fc a0 755 07 | 83 f8 e2 00 81 b0 7c 14 b8 e7 02 19 90 d0 57 4b 756 08 | 14 d2 80 29 1f c4 e6 a6 73 12 68 74 96 77 c2 52 757 09 | 34 ae bb e4 29 da 16 60 61 19 74 c6 b3 53 98 0e 758 10 | 70 e3 3d 4f b9 03 99 76 05 44 e9 74 70 d9 92 bb 759 11 | 3c 37 92 c3 51 d4 7d 8e ea b1 03 0a e0 00 00 01 760 12 | 0c 73 6f 6d 65 20 63 6f 6e 74 65 6e 74 00 00 e7 761 13 | 2a dc 3e dc 09 00 00 00 00 00 00 00 00 00 00 00 762 14 | 02 ca bf a2 0d 82 ae 3e 25 a3 8c 9c dd 2e cf 94 763 15 | 9f cc 7c 7f d9 d8 83 89 f5 08 f7 aa bb 5b ef 21 764 16 | bd 7a 2e 79 6c c7 de 01 af b1 93 35 5b e2 f5 88 765 17 | 19 76 70 e4 ae 09 cf 3b ee 767 Figure 8: Example of encoded IEEE 1609.2 v2 signed data structure 769 In the parsed data structure, the contents are presented in the form: 771 protocol_version (0, 1): 02 772 type (1, 1): 01 (signed) 773 signed_data (2, 263): 774 signer (2, 169): 775 type (2, 1): 03 (certificate) 776 certificates (3, 168): 777 version_and_type (3, 1): 02 (explicit) 778 unsigned_certificate (4, 102): 779 holder_type (4, 1): 02 (identified localized) 780 cf (5, 1): 04 (encryption_key) 781 signer_id (6, 8): f3 db 4f 6f ca b6 49 65 782 signature_alg (14, 1): 01 (ECDSA NIST P256) 783 scope (15, 18): 784 id_scope (15, 18): 785 name_len (15, 1): 09 786 name (16, 9): 63 65 72 74 4e 61 6d 65 31 787 permissions (25, 7): 788 type (25, 1): 01 (specified) 789 permissions_list_len (26, 1): 05 790 permissions_list (27, 5): 791 psid (27, 4): e0 00 00 01 792 service_specific_permissions_len (31, 1): 00 793 region (32, 1): 794 region_type (32, 1): 04 (none) 795 expiration (33, 4): 00 00 00 00 (00:00:34 01 Jan 2004 UTC) 796 crl_series (37, 4): 00 00 00 01 797 verification_key (41, 30): 798 algorithm (41, 1): 00 (ECDSA NIST P224) 799 public_key (42, 29): 800 type (42, 1): 02 (compressed, lsb of y is 0) 801 x (43, 28): 802 d4 a8 61 1d ce d8 8c a7 a2 e9 6a 8d 7e 49 0f 3c 803 9a 46 27 c0 72 26 ed 67 8d 04 74 41 804 encryption_key (71, 35): 806 algorithm (71, 1): 02 (ECIES NIST P256) 807 supported_symm_alg (72, 1): 00 (AES 128 CCM) 808 public_key (73, 33): 809 type (73, 1): 03 (compressed, lsb of y is 1) 810 x (74, 32): 811 9c b6 6f 87 4a 40 7c 21 83 40 22 db 6d 0a 80 d0 812 14 cb df 24 fc a0 83 f8 e2 00 81 b0 7c 14 b8 e7 813 signature (106, 65): 814 ecdsa_signature (106, 65): 815 R (106, 33): 816 type (106, 1): 02 (compressed, lsb of y is 0) 817 x (107, 32): 818 19 90 d0 57 4b 14 d2 80 29 1f c4 e6 a6 73 12 68 819 74 96 77 c2 52 34 ae bb e4 29 da 16 60 61 19 74 820 s (139, 32): 821 c6 b3 53 98 0e 70 e3 3d 4f b9 03 99 76 05 44 e9 822 74 70 d9 92 bb 3c 37 92 c3 51 d4 7d 8e ea b1 03 823 unsigned_data (171, 37): 824 tf (171, 1): 0a (use_generation_time, use_location) 825 psid (172, 4): e0 00 00 01 826 data_len (176, 1): 0c 827 data (177, 12): 73 6f 6d 65 20 63 6f 6e 74 65 6e 74 828 generation_time (189, 9): 829 time (189, 8): 00 00 e7 2a dc 3e dc 09 830 (19:08:23 20 Jan 2012 UTC) 831 log_std_dev (197, 1): 00 (1.134666 ns or less) 832 generation_location (198, 10): 833 latitude (198, 4): 00 00 00 00 834 longitude (202, 4): 00 00 00 00 835 elevation (206, 2): 00 00 836 signature (208, 57): 837 ecdsa_signature (208, 57): 838 R (208, 29): 839 type (208, 1): 02 (compressed, lsb of y is 0) 840 x (209, 28): 841 ca bf a2 0d 82 ae 3e 25 a3 8c 9c dd 2e cf 94 9f 842 cc 7c 7f d9 d8 83 89 f5 08 f7 aa bb 843 s (237, 28): 844 5b ef 21 bd 7a 2e 79 6c c7 de 01 af b1 93 35 5b 845 e2 f5 88 19 76 70 e4 ae 09 cf 3b ee 847 Figure 9: Example of parsed IEEE 1609.2 v2 signed data structure 849 Appendix C. Co-authors' Addresses 851 Houda Labiod 852 Telecom Paristech 853 46 rue Barrault 854 75634 Paris cedex 13 855 France 856 Email: houda.labiod@telecom-paristech.fr 858 Francois Lonc 859 Telecom Paristech 860 46 rue Barrault 861 75634 Paris cedex 13 862 France 863 Email: francois.lonc@telecom-paristech.fr 865 Ahmed Serhrouchni 866 Telecom Paristech 867 46 rue Barrault 868 75634 Paris cedex 13 869 France 870 Email: ahmed.serhrouchni@telecom-paristech.fr 872 Arnaud Kaiser 873 IRT SystemX 874 8 avenue de la Vauve 875 91120 Palaiseau 876 France 877 Email: arnaud.kaiser@irt-systemx.fr 879 Authors' Addresses 881 Arnaud Kaiser 882 IRT SystemX 883 8 avenue de la Vauve 884 91120 Palaiseau 885 France 887 EMail: arnaud.kaiser@irt-systemx.fr 889 Houda Labiod 890 Telecom Paristech 891 46 rue Barrault 892 75634 Paris cedex 13 893 France 895 EMail: houda.labiod@telecom-paristech.fr 896 Brigitte Lonc 897 Renault 898 France 900 EMail: brigitte.lonc@renault.com 902 Mounira Msahli 903 Telecom Paristech 904 46 rue Barrault 905 Paris 75634 906 France 908 EMail: mounira.msahli@telecom-paristech.fr 910 Ahmed Serhrouchni 911 Telecom ParisTech 912 46 rue Barrault 913 Paris 75634 914 France 916 EMail: ahmed.serhrouchni@telecom-paristech.fr