[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-serhrouchni-tls-certieee1609

TLS Working Group                                                B. Lonc
Internet-Draft                                                   Renault
Intended status: Informational                             June 12, 2015
Expires: December 14, 2015


 Transport Layer Security (TLS) Authentication using ITS ETSI and IEEE
                              certificates
                   draft-lonc-tls-certieee1609-01.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) [ETSI-ITS].

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 http://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 December 14, 2015.

Copyright Notice

   Copyright (c) 2015 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
   (http://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




Lonc                    Expires December 14, 2015               [Page 1]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


   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.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Message Flow  . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Client Hello  . . . . . . . . . . . . . . . . . . . . . .   6
     7.2.  Server Hello  . . . . . . . . . . . . . . . . . . . . . .   7
     7.3.  Client Authentication . . . . . . . . . . . . . . . . . .   7
   8.  Certificate Verification  . . . . . . . . . . . . . . . . . .   8
     8.1.  IEEE 1609.2 certificates  . . . . . . . . . . . . . . . .   8
     8.2.  ETSI TS 103 097 certificates  . . . . . . . . . . . . . .   9
   9.  IEEE - ETSI comparison  . . . . . . . . . . . . . . . . . . .  10
     9.1.  Certificate Encoding  . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  ETSI Encoding Example  . . . . . . . . . . . . . . .  12
   Appendix B.  IEEE Encoding Example  . . . . . . . . . . . . . . .  15
   Appendix C.  Co-authors' Addresses  . . . . . . . . . . . . . . .  17

1.  Introduction

   At present, TLS protocol uses X509 [RFC5246] and OpenPGP digital
   certificates [RFC6091] 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)
   [ETSI-ITS].  These standards were defined in order to secure
   communications in vehicular environments.  Existing certificates,
   such as X509 and OpenPGPG, 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.

   In addition, the purpose of these certificates is to provide privacy
   relying on geographical and/or temporal validity criteria, and
   minimizing the exchange of private data.

   Two new values referring the previously mentioned certificated are
   added to the "cert_type" extension defined in [RFC6091].



Lonc                    Expires December 14, 2015               [Page 2]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


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

   In order to negotiate the support of IEEE or ETSI certificate-based
   authentication, clients MAY include an extension of type "cert_type"
   in the extended client hello.  The "extension_data" field of this
   extension SHALL contain a list of supported certificate types
   proposed by the client, where:

               enum {
                   X.509(0), OpenPGP(1), RawPublicKey(2),
                   IEEE(3), ETSI(4), (255)
               }CertificateType;

   In case where the TLS server accepts the described extension, it
   selects one of the certificate types in the extension described here.
   The same extension type and structure will be used for the server's
   response to the extension described here.  Note that a server MAY
   send no certificate type if it either does not support it or wishes
   to 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 revert to a classical TLS handshake or decide
   not to proceed with the negotiation.

4.  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 "cert_type" [IANA value 9] extension who's purpose was
      previously described in Section 3.




Lonc                    Expires December 14, 2015               [Page 3]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


   o  The "elliptic_curves" [IANA value 10] extension which indicates
      the set of elliptic curves supported by the client.

   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.

   The ETSI and IEEE Standards propose the use of secp256r1 (aka NIST
   P-256) recommended by the NIST FIPS 186-4 standard [FIPS186].

   Elliptic curve algorithms require significantly shorter public keys
   to achieve the same security strength.  ECC is the digital signature
   algorithm of choice in the IEEE 1609.2 standard that specifies
   security services and procedures designed for vehicle communications.
   The ECDSA is specified in American National Standard (ANS) X9.62 .
   NIST approved the use of ECDSA and specified additional requirements
   in the FIPS Publication 186-4.

   ECDSA also produces smaller signatures than RSA.  The smaller key
   sizes and signature sizes of ECDSA mean lower message overheads when
   transporting ECDSA public keys over wireless networks compared with
   transporting RSA or DSA public keys.  This is important in a large
   vehicle network where vehicles may often have to exchange their
   public keys over bandwidth - limited wireless channels.  The smaller
   ECDSA key lengths can also translate into savings on computing power,
   storage and memory space, and energy required to achieve the same
   security strength [KARGL] [SCHUTZE] [PETIT] [ICSI].  This makes ECDSA
   attractive for resource - constrained mobile devices, such as vehicle
   on-board communication units.

   The Standard defines ECIES as the encryption algorithm.  Seen that
   this RFC aims to client authentication, the use of this algorithm can
   be optional for future use but not required.

   AES-CCM provides both authentication and confidentiality (encryption
   and decryption) and uses as its only primitive the AES encrypt block
   cipher operation.  This makes it amenable to compact implementations,
   which are advantageous in constrained envrionments.  Adoption outside
   of constrained environments is necessary to enable interoperability,
   such as that between web clients and embedded servers, or between
   embedded clients and web servers.








Lonc                    Expires December 14, 2015               [Page 4]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


5.  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: 3 Description: IEEE Reference: [THIS RFC]

   o  Value: 4 Description: ETSI Reference: [THIS RFC]

6.  Cipher Suites

   The table below defines ECC cipher suites that should be used
   [RFC7251]:

       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM = {0xC0,0xAC}
       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM = {0xC0,0xAD}
       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 = {0xC0,0xAE}
       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 = {0xC0,0xAF}

                      Figure 1: TLS ECC cipher suites

   Server implementations SHOULD support all of the previous cipher
   suites, and client implementations SHOULD support at least one of
   them.  Note that the versions "*_CCM_8" of cipher suites use a 64
   bits tag rather than a 128 bits tag.  Such cipher suites MAY be
   preferred in ITS networks to gain in bandwidth and message size but
   at the cost of a loss in integrity.

7.  Message Flow

   The "cert_type" message MUST be sent as the first handshake message
   as illustrated in Figure 1 below.















Lonc                    Expires December 14, 2015               [Page 5]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


        Client                                               Server

        ClientHello
        /*    with
        certificate type */          -------->
                                                        ServerHello
                                                /*    with
                                                certificate type */
                                                       Certificate*
                                                 ServerKeyExchange*
                                                CertificateRequest*
                                     <--------      ServerHelloDone

        Certificate
        ClientKeyExchange
        CertificateVerify*

        [ChangeCipherSpec]
        Finished                     -------->
                                                 [ChangeCipherSpec]
                                     <--------             Finished
        Application Data             <------->     Application Data


      * Indicates optional or situation-dependent messages that are not
      always sent.

          Figure 2: Message Flow with certificate type extension

7.1.  Client Hello

   In order to indicate the support of IEEE or ETSI certificates,
   clients MUST include an extension of type "cert_type" to the extended
   client hello message.  The hello extension mechanism is described in
   Section 7.4.1.4 of TLS 1.2 [RFC5246].

   The extension 'cert_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 "cert_type" extension prior to other supported
   certificates.

   A TLS client that proposes ECC algorithms in its ClientHello message
   SHOULD include "elliptic_curves" extension [RFC4492].



Lonc                    Expires December 14, 2015               [Page 6]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


   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.

7.2.  Server Hello

   If the server receives a client hello that contains the "cert_type"
   extension and chooses a cipher suite that requires a certificate,
   then two outcomes are possible.  The server MUST either, select a
   certificate type from the certificate_types field in the extended
   client hello and must take into account the client list priority, or
   terminate the session with a fatal alert of type
   "unsupported_certificate".

   The certificate type selected by the server is encoded in a
   CertificateTypeExtension structure, which is included in the extended
   server hello message using an extension of type "cert_type".

   Servers implementing ECC cipher suites MUST support "elliptic_curves"
   extension, and when a client uses this extension, servers MUST NOT
   negotiate the use of an ECC cipher suite unless they can complete the
   handshake while respecting the choice of curves and compression
   techniques specified by the client [RFC4492].

7.3.  Client Authentication

   Client authentication is done upon specific request of the server.
   This procedure SHALL be done as described in section 7.4.4 of
   [RFC5246].

   The figure below depicts the format of the CertificateRequest
   message.


















Lonc                    Expires December 14, 2015               [Page 7]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


           enum {
               rsa_sign(1), dss_sign(2), rsa_fixed_dh(3),
               dss_fixed_dh(4), rsa_ephemeral_dh_RESERVED(5),
               dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20),
               ECDSA_sign(64), (255)
           } ClientCertificateType;

           opaque DistinguishedName<1..2^16-1>;

           struct {
               ClientCertificateType certificate_types<1..2^8-1>;
               SignatureAndHashAlgorithm
                   supported_signature_algorithms<2^16-1>;
               DistinguishedName certificate_authorities<0..2^16-1>;
           } CertificateRequest;

           Figure 3: Structure of the CertificateRequest message

   The CertificateRequest SHALL be filled as follow:

   ClientCertificateType     ECDSA_sign(64)

   SignatureAndHashAlgorithm {0x04,0x03} (ECDSA-SHA256)

   DistinguishedName         It MAY be used by the server to specify a
                             list of certificate authorities it trusts
                             (i.e.  AA/PCA or EA/LTCA).  If possible,
                             the client SHOULD then reply with a
                             certificate signed by one of the
                             certificate authorities trusted by the
                             server in order to avoid sending the
                             certificate chain.  A certificate authority
                             is identified by its HashedId8 as defined
                             in section 4.2.12 of [ETSI-ITS].  That is,
                             DistinguishedName is a list of HashedId8.
                             If not used this field MUST be empty.

8.  Certificate Verification

8.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].








Lonc                    Expires December 14, 2015               [Page 8]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


8.2.  ETSI TS 103 097 certificates

   The format of an ETSI TS 103 097 certificate is depicted in the
   figure below.

    +------+-------+--------+----------+-------+-----+----------+------+
    |      |       |        | verifi-  |assu-  |its  | validity |      |
    | ver- |signer |subject | cation/  |rance  |_aid | _restri- |sign- |
    | sion |_info  |_info   | encryp-  |_level |_ssp | ctions   |ature |
    |      |       |        | tion key |       |     |          |      |
    +------+-------+--------+----------+-------+-----+----------+------+

               Figure 4: ETSI TS 103 097 certificate format

   The verification process of an ETSI TS 103 097 certificate SHALL
   follow these steps:

   1.  Verify that the certificate content is conform to one of ETSI
       profiles (RCA, EA, AA, EC, AT).  If not, the verification has
       failed and the message SHALL be discarded.

   2.  Verify the certificate's signer identity:

       *  If the certificate digest included in "signer_info" is known,
          goto step 3.

       *  Else:

          +  If it is a root certificate digest, the verification has
             failed (error - untrusted RCA) and the message SHALL be
             discarded.

          +  Else: pause the current certificate verification process
             and start verification of the next certificate in the chain
             (which SHALL be the signer's certificate) recursively by
             restarting from step 1.  Once verified, resume the
             certificate verification previously paused.

   3.  Verify that the certificate is not in the Certificate Revocation
       List (CRL).  If it is, the verification has failed (error -
       certificate in CRL) and the message SHALL be discarded.

   4.  Verify the signature of the certificate (see [RFC4492] for
       details).

   5.  Verify "subject_info": "subject_name" SHALL be a 32 bytes hash of
       the server URL.  Note that this step is only done by clients that




Lonc                    Expires December 14, 2015               [Page 9]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


       are verifying a server's certificate.  In the opposite case this
       step SHALL be ignored.

   6.  Verify "validity_restrictions": only the validity of time is
       checked, the validity of space (i.e. geographical region) is
       ignored.

   7.  Verify the "its_aid_ssp": ITS-AID included in the certificate
       SHALL be consistent with those included in the signer's
       certificate (heritage).

9.  IEEE - ETSI comparison

   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.

9.1.  Certificate Encoding

   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].

10.  References

10.1.  Normative References

   [ETSI-ITS]
              ETSI, , "ETSI TS 103 097 v1.1.1 (2013-04): Intelligent
              Transport Systems (ITS); Security; Security header and
              certificate formats", April 2013.

   [IEEE-ITS]
              IEEE 1609.2, , "IEEE Standard for Wireless Access in
              Vehicular Environments - Security Services for
              Applications and Management Messages", 2013.

   [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.



Lonc                    Expires December 14, 2015              [Page 10]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


   [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.

   [RFC6091]  Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
              for Transport Layer Security (TLS) Authentication",
              February 2011.

   [RFC7251]  McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
              CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
              TLS", June 2014.

10.2.  Informative References

   [FIPS186]  FIPS 186-4, , "Digital Signature Standard", July 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.

   [SCHUTZE]  Schutze, T., "Automotive security: Cryptography for Car2X
              communication", March 2011.

   [PETIT]    Petit, J., "Analysis of ECDSA authentication processing in
              VANETs", December 2009.

   [ICSI]     ICST project, , "Analysis of timeliness of communication
              for IEEE 1609.2", 2013.

   [X696]     ITU-T X.696, , "Information Technology - ASN.1 encoding
              rules: Specification of Octet Encoding Rules (OER)",
              august 2014.














Lonc                    Expires December 14, 2015              [Page 11]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


Appendix A.  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 {
          uint8 version: 2
          struct SignerInfo signer_info {
            SignerInfoType type: certificate_digest_with_sha256 (1)
            HashedId8 digest: 5388DEC640C6E19E
          }
          struct SubjectInfo subject_info {



Lonc                    Expires December 14, 2015              [Page 12]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


            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
              Time32 end_validity: 2015-04-28 23:59:59 UTC
            }
            struct ValidityRestriction {
              ValidityRestrictionType type: region (3)
              struct GeographicRegion region {
                RegionType region_type: none (0)



Lonc                    Expires December 14, 2015              [Page 13]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


              }
            }
          }
          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)
        struct EcdsaSignature ecdsa_signature {
          struct EccPoint R {
            EccPointType type: x_coordinate_only (0)
            opaque[32] x: 616D4237DD2CEAB72731C23BCB5D618F
                          8817DF0DA87BD2B8D3548F71098AF188
          }
          opaque[32] s: D24304A8616A95BF5E0745A106E9339F



Lonc                    Expires December 14, 2015              [Page 14]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


                        9E69BAB33CBC6828935A66EA11A03769
        }
      }
    }
  }
}

   Figure 6: Example of parsed ETSI secured message with signed payload

Appendix B.  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 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)
      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)



Lonc                    Expires December 14, 2015              [Page 15]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


              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
                    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):



Lonc                    Expires December 14, 2015              [Page 16]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


          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 signed data structure

Appendix C.  Co-authors' Addresses

   Houda Labiod
   Telecom Paristech
   46 rue Barrault
   75634 Paris cedex 13
   France
   Email: houda.labiod@telecom-paristech.fr

   Francois Lonc
   Telecom Paristech
   46 rue Barrault
   75634 Paris cedex 13
   France
   Email: francois.lonc@telecom-paristech.fr

   Ahmed Serhrouchni
   Telecom Paristech
   46 rue Barrault
   75634 Paris cedex 13
   France
   Email: ahmed.serhrouchni@telecom-paristech.fr

   Arnaud Kaiser
   IRT SystemX
   8 avenue de la Vauve
   91120 Palaiseau



Lonc                    Expires December 14, 2015              [Page 17]


Internet-Draft   IEEE and IETF Certificate Types for TLS       June 2015


   France
   Email: arnaud.kaiser@irt-systemx.fr

Author's Address

   Brigitte Lonc
   Renault
   1 avenue du Golf
   78288 Guyancourt
   France

   EMail: brigitte.lonc@renault.com







































Lonc                    Expires December 14, 2015              [Page 18]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/