idnits 2.17.1 draft-serhrouchni-tls-certieee1609-01.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 (March 13, 2017) is 2602 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'THIS RFC' is mentioned on line 205, but not defined -- Looks like a reference, but probably isn't: '32' on line 555 == Unused Reference: 'RFC7251' is defined on line 277, but no explicit reference was found in the text ** 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group A. KAISER 3 Internet-Draft IRT SystemX 4 Intended status: Informational H. LABIOD 5 Expires: September 14, 2017 Telecom Paristech 6 B. LONC 7 Renault 8 M. MSAHLI 9 Telecom Paristech 10 A. SERHROUCHNI 11 Telecom ParisTech 12 March 13, 2017 14 Transport Layer Security (TLS) Authentication using ITS ETSI and IEEE 15 certificates 16 draft-serhrouchni-tls-certieee1609-01.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 September 14, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 6. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 5 67 7. Certificate Verification . . . . . . . . . . . . . . . . . . 6 68 7.1. IEEE 1609.2 certificates . . . . . . . . . . . . . . . . 6 69 7.2. ETSI TS 103 097 certificates . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 8.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Certificates comparison . . . . . . . . . . . . . . 7 74 A.1. ETSI vs IEEE . . . . . . . . . . . . . . . . . . . . . . 7 75 A.2. ETSI vs X.509 . . . . . . . . . . . . . . . . . . . . . . 8 76 Appendix B. ETSI Encoding Example . . . . . . . . . . . . . . . 9 77 Appendix C. IEEE Encoding Example . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 At present, TLS protocol uses X509 [RFC5246] and OpenPGP digital 83 certificates [RFC6091] in order to authenticate servers and clients. 84 This document describes the use of certificates specified either by 85 the Institute of Electrical and Electronics Engineers (IEEE) 86 [IEEE-ITS] or the European Telecommunications Standards Institute 87 (ETSI) [ETSI103097]. These standards were defined in order to secure 88 communications in vehicular environments. Existing certificates, 89 such as X509 and OpenPGPG, are designed for Internet use, 90 particularly for flexibility and extensibility, and are not optimized 91 for bandwidth and processing time to support delay-sensitive 92 applications. This is why size-optimized certificates that meet the 93 ITS requirements were designed and standardized. 95 In addition, the purpose of these certificates is to provide privacy 96 relying on geographical and/or temporal validity criteria, and 97 minimizing the exchange of private data. 99 Two new values referring the previously mentioned certificated are 100 added to the "cert_type" extension defined in [RFC6091]. 102 2. Requirements Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Extension Overview 110 In order to negotiate the support of IEEE or ETSI certificate-based 111 authentication, clients MAY include an extension of type "cert_type" 112 in the extended client hello. The "extension_data" field of this 113 extension SHALL contain a list of supported certificate types 114 proposed by the client, where: 116 enum { 117 X.509(0), OpenPGP(1), RawPublicKey(2), 118 IEEE(TBD), ETSI(TBD), (255) 119 }CertificateType; 121 In case where the TLS server accepts the described extension, it 122 selects one of the certificate types in the extension described here. 123 The same extension type and structure will be used for the server's 124 response to the extension described here. Note that a server MAY 125 send no certificate type if it either does not support it or wishes 126 to authenticate the client using other authentication methods. The 127 client MAY at its discretion either continue the handshake, or 128 respond with a fatal message alert. 130 The end-entity certificate's public key has to be compatible with one 131 of the certificate types listed in extension described here. 133 Servers aware of the extension described here but not wishing to use 134 it, SHOULD gracefully revert to a classical TLS handshake or decide 135 not to proceed with the negotiation. 137 4. Security Considerations 139 This section provides an overview of the basic security 140 considerations which need to be taken into account before 141 implementing the necessary security mechanisms. The security 142 considerations described throughout [RFC5246] apply here as well. 144 For security considerations in a vehicular environment, the minimal 145 use of any TLS extensions is recommended such as : 147 o The "cert_type" [IANA value 9] extension who's purpose was 148 previously described in Section 3. 150 o The "elliptic_curves" [IANA value 10] extension which indicates 151 the set of elliptic curves supported by the client. 153 o The "SessionTicket" [IANA value 35] extension for session 154 resumption. 156 In addition, servers SHOULD not support renegotiation [RFC5746] which 157 presented Man-In-The-Middle (MITM) type attacks over the past years. 159 The ETSI and IEEE Standards propose the use of secp256r1 (aka NIST 160 P-256) recommended by the NIST FIPS 186-4 standard [FIPS186]. 162 Elliptic curve algorithms require significantly shorter public keys 163 to achieve the same security strength. ECC is the digital signature 164 algorithm of choice in the IEEE 1609.2 standard that specifies 165 security services and procedures designed for vehicle communications. 166 The ECDSA is specified in American National Standard (ANS) X9.62 . 167 NIST approved the use of ECDSA and specified additional requirements 168 in the FIPS Publication 186-4. 170 ECDSA also produces smaller signatures than RSA. The smaller key 171 sizes and signature sizes of ECDSA mean lower message overheads when 172 transporting ECDSA public keys over wireless networks compared with 173 transporting RSA or DSA public keys. This is important in a large 174 vehicle network where vehicles may often have to exchange their 175 public keys over bandwidth - limited wireless channels. The smaller 176 ECDSA key lengths can also translate into savings on computing power, 177 storage and memory space, and energy required to achieve the same 178 security strength [KARGL] [SCHUTZE] [PETIT] [ICSI]. This makes ECDSA 179 attractive for resource - constrained mobile devices, such as vehicle 180 on-board communication units. 182 The Standard defines ECIES as the encryption algorithm. Seen that 183 this RFC aims to client authentication, the use of this algorithm can 184 be optional for future use but not required. 186 AES-CCM provides both authentication and confidentiality (encryption 187 and decryption) and uses as its only primitive the AES encrypt block 188 cipher operation. This makes it amenable to compact implementations, 189 which are advantageous in constrained envrionments. Adoption outside 190 of constrained environments is necessary to enable interoperability, 191 such as that between web clients and embedded servers, or between 192 embedded clients and web servers. 194 5. IANA Considerations 196 Existing IANA references have not been updated yet to point to this 197 document. 199 IANA is asked to register two new values in the "TLS Certificate 200 Types" registry of Transport Layer Security (TLS) Extensions [TLS- 201 Certificate-Types-Registry], as follows: 203 o Value: TBD Description: IEEE Reference: [THIS RFC] 205 o Value: TBD Description: ETSI Reference: [THIS RFC] 207 6. Message Flow 209 6.1. Client Hello 211 In order to indicate the support of IEEE or ETSI certificates, 212 clients MUST include an extension of type "cert_type" to the extended 213 client hello message. The hello extension mechanism is described in 214 Section 7.4.1.4 of TLS 1.2 [RFC5246]. 216 The extension 'cert_type' sent in the client hello MAY carry a list 217 of supported certificate types, sorted by client preference. It is a 218 list in the case where the client supports multiple certificate 219 types. 221 In a vehicular environment, privacy is important. In order to 222 preserve anonymity, a client MUST include IEEE or ETSI certificate 223 types in the "cert_type" extension. certificates. 225 A TLS client that proposes ECC algorithms in its ClientHello message 226 SHOULD include "elliptic_curves" extension [RFC4492]. 228 Clients respond along with their certificates by sending a 229 "Certificate" message immediately followed by the "ClientKeyExchange" 230 message. The premaster secret is generated according to the cipher 231 algorithm selected by the server in the ServerHello.cipher_suite. 233 7. Certificate Verification 235 7.1. IEEE 1609.2 certificates 237 Verification of an IEEE 1609.2 certificate or certificate chain is 238 described in section 5.5.2 of [IEEE-ITS]. 240 7.2. ETSI TS 103 097 certificates 242 Verification of ETSI TS 103 097 certificate or certificate chain is 243 described in annex F of [ETSI102941]. 245 8. References 247 8.1. Normative References 249 [ETSI103097] 250 ETSI, , "ETSI TS 103 097 v1.1.1 (2013-04): Intelligent 251 Transport Systems (ITS); Security; Security header and 252 certificate formats", April 2013. 254 [IEEE-ITS] 255 IEEE 1609.2, , "IEEE Standard for Wireless Access in 256 Vehicular Environments - Security Services for 257 Applications and Management Messages", 2013. 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", March 1997. 262 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 263 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 264 for Transport Layer Security (TLS)", May 2006. 266 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 267 (TLS) Protocol Version 1.2", August 2008. 269 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 270 "Transport Layer Security (TLS) Renegotiation Indication 271 Extension"", February 2010. 273 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 274 for Transport Layer Security (TLS) Authentication", 275 February 2011. 277 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 278 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 279 TLS", June 2014. 281 [ETSI102941] 282 ETSI, , "ETSI TS 102 941 v1.1.9 (2016-04): Intelligent 283 Transport Systems (ITS); Security; Trust and Privacy 284 Management", April 2016. 286 8.2. Informative References 288 [FIPS186] FIPS 186-4, , "Digital Signature Standard", July 2013. 290 [KARGL] Kargl, F., Papadimitratos, P., Buttyan, L., Muter, M., 291 Schoch, E., Wiedersheim, B., Thong, T.-V., Calandriello, 292 G., Held, A., Kung, A., and J.-P. Hubaux, "Secure 293 Vehicular Communications: Implementation, Performance, and 294 Research Challenges", November 2008. 296 [SCHUTZE] Schutze, T., "Automotive security: Cryptography for Car2X 297 communication", March 2011. 299 [PETIT] Petit, J., "Analysis of ECDSA authentication processing in 300 VANETs", December 2009. 302 [ICSI] ICST project, , "Analysis of timeliness of communication 303 for IEEE 1609.2", 2013. 305 [X696] ITU-T X.696, , "Information Technology - ASN.1 encoding 306 rules: Specification of Octet Encoding Rules (OER)", 307 august 2014. 309 Appendix A. Certificates comparison 311 A.1. ETSI vs IEEE 313 The ETSI and IEEE 1609.2 represent the active standardization groups 314 in Europe and U.S those dealing with the security of vehicular 315 communications. Although defined for the same purpose, the different 316 security requirements have led to the definition of different 317 certificate formats. 319 +-----------------------+-----------------------+ 320 | ETSI Certificate | IEEE Certificate | 321 +-----------------------+-----------------------+ 322 | Version | Version | 323 +-----------------------+-----------------------+ 324 | | Type | 325 +-----------------------+-----------------------+ 326 | Signer_info | IssuerIdentifier | 327 +-----------------------+-----------------------+ 328 | Subject_info | | 329 | Subject_attributes | ToBeSignedCertificate | 330 | Validity_restrictions | | 331 +-----------------------+-----------------------+ 332 | Signature | Signature | 333 +-----------------------+-----------------------+ 335 Figure 1: Certificates comparison 337 As given in Figure 1, the IEEE certificate contains same data 338 strucutres as the one defined by ETSI except "Type" field, which 339 specifies the type of certificate if it is implicit or explicit. 341 The main differences are listed below: 343 o The structure of US Security Credentials Management System (SCMS) 344 is different from EU PKI 346 o Revocation distribution is not supported yet in ETSI TS 103 097 348 o SCMS provides high privacy for pseudonym resolution with 2 Linkage 349 Authorities (LA1 and LA2): LA1/2 generate 2 linkage values that 350 are added in the certificate. This allow to connect all short- 351 term certificates from a specific device for ease of revocation in 352 the event of misbehavior. 354 o Certificate Encoding 356 * As described in the IEEE 1609.2 and ETSI standards, the 357 internal representation of the certificate structure is encoded 358 into a flat octet string in network byte order (i.e. big- 359 endian). 361 * IEEE 1609.2 is developing for future an ASN.1 version of the 362 standard using X.696 (OER) [X696]. 364 A.2. ETSI vs X.509 366 o Distinguished Name: There is no Distinguished Name based on X.500 367 in C-ITS certificates. Instead, Subject Names are defined as a 368 string of maximum 32 bytes. There are no naming convention for 369 Subject Names and the unicity of Subject Names for CAs and end- 370 entities is not required. Pseudonym certificates does not use 371 Distinguished Names for pseudonymous authentication (Subject Name 372 is empty): the digest of the certificate is used as unique 373 identifier. It is defined as a HashedID8 attribute which 374 represents the 8 least significant bytes of the SHA-256 hash 375 computation of the certificate. 377 o Geographical attributes: The C-ITS certificates of CAs and end- 378 entities may contain geographical validity attributes (location) 379 which doesn't exist in x509. 381 o Trust Assurance Level (TAL): The C-ITS certificates of CAs and 382 end-entities must contain a TAL: 384 * For the security of a V2X communication system, assurance about 385 the in-vehicle security of participants is vital: the receiver 386 of a message has to be able to rely on the fact that the sender 387 has generated the message correctly (i.e. the car sensors 388 information is accurate and of integrity). Hence, a security 389 breach on the sender would have an impact on all the receivers 390 of a message. 392 * Only vehicles with a reasonable "level of security" should be 393 able to obtain certificates from the PKI. The Car-to-Car 394 Communication Consortium (C2C-CC) introduced different levels 395 of trust, defined as Trust Assurance Levels and the 396 authorization tickets (i.e. pseudonym certificates) of the 397 vehicle must include the value of the vehicle TAL. 399 In order to authenticate end-entities in TLS with ETSI certificates 400 the following issues still have to be addressed: 402 o No certificate profile for ITS-S Centre (i.e. Internet Server) is 403 defined yet in ETSI TS 103 097 specification. 405 o A field is required in certificates for ITS-S Centre to provide 406 the server's FQDN (Fully Qualified Domain Name). To this end, 407 either the use of the Subject Name field is possible (although the 408 size is limited to 32 bytes) or a new SubjectAttribute may be 409 defined for this purpose. 411 Appendix B. ETSI Encoding Example 413 The hex sequence shown in Figure 2 presents an encoded secured 414 message with signed payload as a generic encoded octet string. 416 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 417 +---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- 418 01 | 02 80 ba 80 02 02 01 53 88 de c6 40 c6 e1 9e 01 419 02 | 00 52 00 00 04 d4 81 34 8a cd d1 d9 9c 1f fb a4 420 03 | c7 0e 6d 2a 5d 13 ca b0 a1 e6 cf 63 22 9f 69 79 421 04 | b4 53 c0 15 c7 da 3a 12 7c 8f 39 44 59 b1 2f 94 422 05 | d4 cb 9a 12 ce e1 1d 87 40 8d 91 ac 95 6c 90 c8 423 06 | b3 b2 9f 4c 22 02 e0 21 0b 24 03 01 00 00 25 04 424 07 | 01 00 00 00 0b 01 15 04 39 83 15 4c bc 02 03 00 425 08 | 00 00 71 ff 9a 0d 80 16 ca cb cd d8 1c d1 4f 81 426 09 | 94 3c dd c7 74 51 1e 2b f7 15 7b 33 e5 4f 7b 6b 427 10 | 6e 5b 5d 07 94 70 be 40 a6 46 e0 55 9c 19 89 28 428 11 | b5 b8 ed cf bd c2 29 70 53 95 1d bc 51 cb d6 a3 429 12 | e1 d0 00 00 01 41 ae 0f 26 64 c0 05 24 01 55 20 430 13 | 50 02 80 00 31 01 00 14 00 30 14 4a d9 f8 7e 59 431 14 | 9e 09 2b 00 00 00 00 00 00 00 00 80 00 00 00 00 432 15 | 00 00 00 07 d1 00 00 01 02 00 00 00 02 09 2b 40 433 16 | 56 b4 9d 20 0d 69 3a 40 1f ff ff fc 22 30 d4 1e 434 17 | 40 00 0f c0 00 7e 02 76 ea 87 33 a9 d7 4f ff d0 435 18 | 84 14 00 00 43 01 00 00 61 6d 42 37 dd 2c ea b7 436 19 | 27 31 c2 3b cb 5d 61 8f 88 17 df 0d a8 7b d2 b8 437 20 | d3 54 8f 71 09 8a f1 88 d2 43 04 a8 61 6a 95 bf 438 21 | 5e 07 45 a1 06 e9 33 9f 9e 69 ba b3 3c bc 68 28 439 22 | 93 5a 66 ea 11 a0 37 69 441 Figure 2: Example of encoded ETSI secured message with signed payload 443 In the parsed data structure, the contents are presented in the form: 445 struct SecuredMessage { 446 uint8 protocol_version: 2 447 HeaderField<186> header_fields { 448 struct HeaderField { 449 HeaderFieldType type: signer_info (128) 450 struct SignerInfo signer { 451 SignerInfoType type: certificate (2) 452 struct Certificate certificate { 453 uint8 version: 2 454 struct SignerInfo signer_info { 455 SignerInfoType type: certificate_digest_with_sha256 (1) 456 HashedId8 digest: 5388DEC640C6E19E 457 } 458 struct SubjectInfo subject_info { 459 SubjectType subject_type: authorization_ticket (1) 460 opaque<0> subject_name: 461 } 462 SubjectAttribute<82> subject_attributes { 463 struct SubjectAttribute { 464 SubjectAttributeType type: verification_key (0) 465 struct PublicKey key { 466 PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_ 467 sha256 (0) 468 struct EccPoint public_key { 469 EccPointType type: uncompressed (4) 470 opaque[32] x: D481348ACDD1D99C1FFBA4C70E6D2A5D 471 13CAB0A1E6CF63229F6979B453C015C7 472 opaque[32] y: DA3A127C8F394459B12F94D4CB9A12CE 473 E11D87408D91AC956C90C8B3B29F4C22 474 } 475 } 476 } 477 struct SubjectAttribute { 478 SubjectAttributeType type: assurance_level (2) 479 SubjectAssurance assurance_level: assurance level = 7, 480 confidence = 0 481 (bitmask = 11100000) 482 } 483 struct SubjectAttribute { 484 SubjectAttributeType type: its_aid_ssp_list (33) 485 ItsAidSsp<11> its_aid_ssp_list { 486 struct ItsAidSsp { 487 IntX its_aid: 36 488 opaque<3> service_specific_permissions: 010000 489 } 490 struct ItsAidSsp { 491 IntX its_aid: 37 492 opaque<4> service_specific_permissions: 01000000 493 } 494 } 495 } 496 } 497 ValidityRestriction<11> validity_restrictions { 498 struct ValidityRestriction { 499 ValidityRestrictionType type: time_start_and_end (1) 500 Time32 start_validity: 2015-03-05 00:00:00 UTC 501 Time32 end_validity: 2015-04-28 23:59:59 UTC 502 } 503 struct ValidityRestriction { 504 ValidityRestrictionType type: region (3) 505 struct GeographicRegion region { 506 RegionType region_type: none (0) 507 } 508 } 509 } 510 struct Signature { 511 PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_sha256 (0) 512 struct EcdsaSignature ecdsa_signature { 513 struct EccPoint R { 514 EccPointType type: x_coordinate_only (0) 515 opaque[32] x: 71FF9A0D8016CACBCDD81CD14F81943C 516 DDC774511E2BF7157B33E54F7B6B6E5B 517 } 518 opaque[32] s: 5D079470BE40A646E0559C198928B5B8 519 EDCFBDC2297053951DBC51CBD6A3E1D0 520 } 522 } 523 } 524 } 525 } 526 struct HeaderField { 527 HeaderFieldType type: generation_time (0) 528 Time64 generation_time: 2015-03-17 15:26:48.000 UTC 529 } 530 struct HeaderField { 531 HeaderFieldType type: its_aid (5) 532 IntX its_aid: 36 533 } 534 } 535 struct Payload payload_field { 536 PayloadType type: signed (1) 537 opaque<85> data: 2050028000310100140030144AD9F87E 538 599E092B000000000000000080000000 539 0000000007D10000010200000002092B 540 4056B49D200D693A401FFFFFFC2230D4 541 1E40000FC0007E0276EA8733A9D74FFF 542 D084140000 543 } 544 TrailerField<67> trailer_fields { 545 struct TrailerField { 546 TrailerFieldType type: signature (1) 547 struct Signature signature { 548 PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_sha256 (0) 549 struct EcdsaSignature ecdsa_signature { 550 struct EccPoint R { 551 EccPointType type: x_coordinate_only (0) 552 opaque[32] x: 616D4237DD2CEAB72731C23BCB5D618F 553 8817DF0DA87BD2B8D3548F71098AF188 554 } 555 opaque[32] s: D24304A8616A95BF5E0745A106E9339F 556 9E69BAB33CBC6828935A66EA11A03769 557 } 558 } 559 } 560 } 561 } 563 Figure 3: Example of parsed ETSI secured message with signed payload 565 Appendix C. IEEE Encoding Example 567 The hex sequence shown in Figure 4 presents an encoded signed data 568 structure as a flat encoded octet string. 570 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 571 +---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- 572 01 | 02 01 03 02 02 04 f3 db 4f 6f ca b6 49 65 01 09 573 02 | 63 65 72 74 4e 61 6d 65 31 01 05 e0 00 00 01 00 574 03 | 04 00 00 00 00 00 00 00 01 00 02 d4 a8 61 1d ce 575 04 | d8 8c a7 a2 e9 6a 8d 7e 49 0f 3c 9a 46 27 c0 72 576 05 | 26 ed 67 8d 04 74 41 02 00 03 9c b6 6f 87 4a 40 577 06 | 7c 21 83 40 22 db 6d 0a 80 d0 14 cb df 24 fc a0 578 07 | 83 f8 e2 00 81 b0 7c 14 b8 e7 02 19 90 d0 57 4b 579 08 | 14 d2 80 29 1f c4 e6 a6 73 12 68 74 96 77 c2 52 580 09 | 34 ae bb e4 29 da 16 60 61 19 74 c6 b3 53 98 0e 581 10 | 70 e3 3d 4f b9 03 99 76 05 44 e9 74 70 d9 92 bb 582 11 | 3c 37 92 c3 51 d4 7d 8e ea b1 03 0a e0 00 00 01 583 12 | 0c 73 6f 6d 65 20 63 6f 6e 74 65 6e 74 00 00 e7 584 13 | 2a dc 3e dc 09 00 00 00 00 00 00 00 00 00 00 00 585 14 | 02 ca bf a2 0d 82 ae 3e 25 a3 8c 9c dd 2e cf 94 586 15 | 9f cc 7c 7f d9 d8 83 89 f5 08 f7 aa bb 5b ef 21 587 16 | bd 7a 2e 79 6c c7 de 01 af b1 93 35 5b e2 f5 88 588 17 | 19 76 70 e4 ae 09 cf 3b ee 590 Figure 4: Example of encoded IEEE 1609.2 v2 signed data structure 592 In the parsed data structure, the contents are presented in the form: 594 protocol_version (0, 1): 02 595 type (1, 1): 01 (signed) 596 signed_data (2, 263): 597 signer (2, 169): 598 type (2, 1): 03 (certificate) 599 certificates (3, 168): 600 version_and_type (3, 1): 02 (explicit) 601 unsigned_certificate (4, 102): 602 holder_type (4, 1): 02 (identified localized) 603 cf (5, 1): 04 (encryption_key) 604 signer_id (6, 8): f3 db 4f 6f ca b6 49 65 605 signature_alg (14, 1): 01 (ECDSA NIST P256) 606 scope (15, 18): 607 id_scope (15, 18): 608 name_len (15, 1): 09 609 name (16, 9): 63 65 72 74 4e 61 6d 65 31 610 permissions (25, 7): 611 type (25, 1): 01 (specified) 612 permissions_list_len (26, 1): 05 613 permissions_list (27, 5): 614 psid (27, 4): e0 00 00 01 615 service_specific_permissions_len (31, 1): 00 616 region (32, 1): 617 region_type (32, 1): 04 (none) 618 expiration (33, 4): 00 00 00 00 (00:00:34 01 Jan 2004 UTC) 619 crl_series (37, 4): 00 00 00 01 620 verification_key (41, 30): 621 algorithm (41, 1): 00 (ECDSA NIST P224) 622 public_key (42, 29): 623 type (42, 1): 02 (compressed, lsb of y is 0) 624 x (43, 28): 625 d4 a8 61 1d ce d8 8c a7 a2 e9 6a 8d 7e 49 0f 3c 626 9a 46 27 c0 72 26 ed 67 8d 04 74 41 627 encryption_key (71, 35): 628 algorithm (71, 1): 02 (ECIES NIST P256) 629 supported_symm_alg (72, 1): 00 (AES 128 CCM) 630 public_key (73, 33): 631 type (73, 1): 03 (compressed, lsb of y is 1) 632 x (74, 32): 633 9c b6 6f 87 4a 40 7c 21 83 40 22 db 6d 0a 80 d0 634 14 cb df 24 fc a0 83 f8 e2 00 81 b0 7c 14 b8 e7 635 signature (106, 65): 636 ecdsa_signature (106, 65): 637 R (106, 33): 638 type (106, 1): 02 (compressed, lsb of y is 0) 639 x (107, 32): 640 19 90 d0 57 4b 14 d2 80 29 1f c4 e6 a6 73 12 68 641 74 96 77 c2 52 34 ae bb e4 29 da 16 60 61 19 74 642 s (139, 32): 643 c6 b3 53 98 0e 70 e3 3d 4f b9 03 99 76 05 44 e9 644 74 70 d9 92 bb 3c 37 92 c3 51 d4 7d 8e ea b1 03 645 unsigned_data (171, 37): 646 tf (171, 1): 0a (use_generation_time, use_location) 647 psid (172, 4): e0 00 00 01 648 data_len (176, 1): 0c 649 data (177, 12): 73 6f 6d 65 20 63 6f 6e 74 65 6e 74 650 generation_time (189, 9): 651 time (189, 8): 00 00 e7 2a dc 3e dc 09 652 (19:08:23 20 Jan 2012 UTC) 653 log_std_dev (197, 1): 00 (1.134666 ns or less) 654 generation_location (198, 10): 655 latitude (198, 4): 00 00 00 00 656 longitude (202, 4): 00 00 00 00 657 elevation (206, 2): 00 00 658 signature (208, 57): 659 ecdsa_signature (208, 57): 661 R (208, 29): 662 type (208, 1): 02 (compressed, lsb of y is 0) 663 x (209, 28): 664 ca bf a2 0d 82 ae 3e 25 a3 8c 9c dd 2e cf 94 9f 665 cc 7c 7f d9 d8 83 89 f5 08 f7 aa bb 666 s (237, 28): 667 5b ef 21 bd 7a 2e 79 6c c7 de 01 af b1 93 35 5b 668 e2 f5 88 19 76 70 e4 ae 09 cf 3b ee 670 Figure 5: Example of parsed IEEE 1609.2 v2 signed data structure 672 Authors' Addresses 674 Arnaud Kaiser 675 IRT SystemX 676 8 avenue de la Vauve 677 91120 Palaiseau 678 France 680 EMail: arnaud.kaiser@irt-systemx.fr 682 Houda Labiod 683 Telecom Paristech 684 46 rue Barrault 685 75634 Paris cedex 13 686 France 688 EMail: houda.labiod@telecom-paristech.fr 690 Brigitte Lonc 691 Renault 692 France 694 EMail: brigitte.lonc@renault.com 696 Mounira Msahli 697 Telecom Paristech 698 46 rue Barrault 699 Paris 75634 700 France 702 EMail: mounira.msahli@telecom-paristech.fr 703 Ahmed Serhrouchni 704 Telecom ParisTech 705 46 rue Barrault 706 Paris 75634 707 France 709 EMail: ahmed.serhrouchni@telecom-paristech.fr