ACE Working Group S. Raza Internet-Draft J. Hoeglund Intended status: Standards Track RISE AB Expires: April 25, 2019 G. Selander J. Mattsson Ericsson AB October 22, 2018 CBOR Profile of X.509 Certificates draft-raza-ace-cbor-certificates-00 Abstract This document specifies a CBOR encoding and profiling of X.509 public key certificate suitable for Internet of Things (IoT) deployments. The full X.509 public key certificate format and commonly used ASN.1 encoding is overly verbose for constrained IoT environments. Profiling together with CBOR encoding reduces the certificate size significantly with associated known performance benefits. The CBOR certificates are compatible with the existing X.509 standard, enabling the use of profiled and compressed X.509 certificates without modifications in the existing X.509 standard. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 25, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Raza, et al. Expires April 25, 2019 [Page 1] Internet-Draft CBOR Profile of X.509 Certificates October 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. X.509 Certificate Profile . . . . . . . . . . . . . . . . . . 3 3. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Deployment settings . . . . . . . . . . . . . . . . . . . . . 6 5. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 7 6. Native CBOR Certificates . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. CBOR Certificate, CDDL . . . . . . . . . . . . . . . 9 Appendix B. X.509 Certificate Profile, ASN.1 . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction One of the challenges with deploying a Public Key Infrastructure (PKI) for the Internet of Things (IoT) is the size and encoding of X.509 public key certificates, since those are not optimized for constrained environments [RFC7228]. More compact certificate representations are desirable. Due to the current PKI usage of X.509 certificates, keeping X.509 compatibility is necessary at least for a transition period. However, the use of a more compact encoding with the Concise Binary Object Representation (CBOR) [I-D.ietf-cbor-7049bis] reduces the certificate size significantly which has known performance benefits in terms of decreased communication overhead, power consumption, latency, storage, etc. CBOR is a data format designed for small code size and small message size. CBOR builds on the JSON data model but extends it by e.g. encoding binary data directly without base64 conversion. In addition to the binary CBOR encoding, CBOR also has a diagnostic notation that is readable and editable by humans. The Concise Data Definition Language (CDDL) [I-D.ietf-cbor-cddl] provides a way to express Raza, et al. Expires April 25, 2019 [Page 2] Internet-Draft CBOR Profile of X.509 Certificates October 2018 structures for protocol messages and APIs that use CBOR. [I-D.ietf-cbor-cddl] also extends the diagnostic notation. CBOR data items are encoded to or decoded from byte strings using a type-length-value encoding scheme, where the three highest order bits of the initial byte contain information about the major type. CBOR supports several different types of data items, in addition to integers (int, uint), simple values (e.g. null), byte strings (bstr), and text strings (tstr), CBOR also supports arrays of data items and maps of pairs of data items. For a complete specification and examples, see [I-D.ietf-cbor-7049bis] and [I-D.ietf-cbor-cddl]. This document specifies the CBOR certificate profile, which is a CBOR based encoding and compression of the X.509 certificate format. The profile is based on previous work on profiling of X.509 certificates for Internet of Things deployments [X.509-IoT] which retains backwards compatibility with X.509, and can be applied for lightweight certificate based authentication with e.g. DTLS [RFC6347] or EDHOC [I-D.selander-ace-cose-ecdhe]. The same profile can be used for "native" CBOR encoded certificates, which further optimizes the performance in constrained environments but are not backwards compatible with X.509, see Section 6. Other work has looked at reducing size of X.509 certificates. The purpose of this document is to stimulate a discussion on CBOR based certificates. Further optimizations of this profile are known and will be included in future versions. o Terminology {#terminology} The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification makes use of the terminology in [RFC7228]. 2. X.509 Certificate Profile This profile is inspired by [RFC7925] and mandates further restrictions to enable reduction of certificate size. In this section we list the required fields in an X.509 certificate needed by devices in IoT deployments. The corresponding ASN.1 schema is given in Appendix B. In order to comply with this certificate profile, the following restrictions MUST be applied: Raza, et al. Expires April 25, 2019 [Page 3] Internet-Draft CBOR Profile of X.509 Certificates October 2018 o Version number. The X.509 standard has not moved beyond version 3 since 2008. With the introduction of certificate extensions new certificate fields can be added without breaking the format, making version changes less likely. Therefore this profile fixes the version number to 3. o Serial number. The serial number together with the identity of the CA is the unique identifier of a certificate. The X.509 standard does not specify the signedness of the serial number, but this profile requires an unsigned integer. o Signature algorithm. For the CBOR profile, the signature algorithm is fixed to ECDSA with SHA256. o Issuer. Used to identify the issuing CA through a sequence of name-value pairs. This profile is restricting this to one pair, common name and associated string value. The common name MUST uniquely identify the CA. Other fields MUST NOT be used. o Validity. The following representation MUST be used: UTCTime- format, YYMMDDhhmmss. This is the most compact format allowed by the X.509 standard. o Subject. The subject section has the same format as the issuer, identifying the receiver of the public key through a sequence of name-value pairs. This sequence is in the profile restricted to a single pair, subject name and associated (unique) value. For an IoT-device, the MAC-derived EUI-64 serves this purpose well. o Subject public key info. For the IoT devices, elliptic curve cryptography based algorithms have clear advantages. For the IoT profile the public key algorithm is fixed to prime256v1. o Issuer Unique ID and Subject Unique ID. These fields are optional in X.509 and MUST NOT be used with the CBOR profile. o Extensions. Extensions consist of three parts; an OID, a boolean telling if it is critical or not, and the value. To maintain forward compatibility, the CBOR profile does not restrict the use of extensions. By the X.509-standard, any device must be able to process eight extensions types. Since only four of them are critical for IoT, this profile is making the other four optional. Still mandatory to be understood are: * Key Usage * Subject Alternative Name Raza, et al. Expires April 25, 2019 [Page 4] Internet-Draft CBOR Profile of X.509 Certificates October 2018 * Basic Constraints * Extended Key Usage o Certificate signature algorithm. This field duplicates the info present in the signature algorithm field. Fixed to ECDSA with SHA256. o Certificate Signature. The field corresponds to the signature done by the CA private key. For the CBOR profile, this is restricted to ECDSA type signatures with a signature length of 64 bits. 3. CBOR Encoding This section specifies the CBOR certificates, which are the result of the CBOR encoding and lossless compression of the X.509 certificate profile of the previous section. The CDDL representation is given in Appendix A. The encoding and compression has several components including: ASN.1 and base64 encoding is replaced with CBOR encoding, static fields are elided, and compression of elliptic curve points. The field encodings and associated savings are listed below. Combining these different components reduces the certificate size significantly, see Figure 1. o Version number. The version number field is omitted in the encoding. This saves 5 bytes. o Serial number. The serial number is encoded as an unsigned integer. Encoding overhead is reduced by one byte. o Signature algorithm. The signature algorithm is known from the profile and is omitted in the ecoding. This saves 12 bytes. o Issuer. Since the profile only allows the common name type, the common name type specifier is omitted. In total, the issuer field encoding overhead goes from 13 bytes to one byte. o Validity. The time is encoded as UnixTime in integer format. The validity is represented as a 'not before'-'not after' pair of integer. This reduces the size from 32 to 11 bytes. o Subject. An IoT subject is identified by a EUI-64, in turn based on a 48bit unique MAC id. This is encoded using only 7 bytes using CBOR. This is a reduction down from 36 bytes for the corresponding ASN.1 encoding. Raza, et al. Expires April 25, 2019 [Page 5] Internet-Draft CBOR Profile of X.509 Certificates October 2018 o Subject public key info. The algorithm identifier is known from the profile restrictions and is omitted. One of the public key ECC curve point elements can be calculated from the other, hence only one of the curve points is needed (point compression, see [PointCompression]). These actions together reduce size from 91 to 35 bytes. o Extensions. Minor savings are achieved by the compact CBOR encoding. In addition, the relevant X.509 extension OIDs always start with 0x551D, hence these two bytes can be omitted. o Certificate signature algorithm. The signature algorithm is known from the profile and is omitted in the ecoding. o Signature. Since the signature algorithm and resulting signature length are known, padding and extra length fields which are present in the ASN.1 encoding are omitted. The overhead for encoding the 64-bit signature value is reduced from 11 to 2 bytes. 4. Deployment settings CBOR certificates can be deployed with legacy X.509 certificates and CA infrastructure. In order to verify the signature, the CBOR certificate is used to recreate the original X.509 data structure to be able to verify the signature. For the currently used DTLS v1.2 protocol, where the handshake is sent unencrypted, the actual encoding and compression can be done at different locations depending on the deployment setting. For example, the mapping between CBOR certificate and standard X.509 certificate can take place in a 6LoWPAN border gateway which allows the server side to stay unmodified. This case gives the advantage of the low overhead of a CBOR certificate over a constrained wireless links. The conversion to X.509 within an IoT device will incur a computational overhead, however, this is negligible compared to the reduced communication overhead. For the setting with constrained server and server-only authentication, the server only needs to be provisioned with the CBOR certificate and does not perform the conversion to X.509. This option is viable when client authentication can be asserted by other means. For DTLS v1.3 the encoding needs to be done fully end-to-end, through adding the endcoding/decoding functionality to the server. Raza, et al. Expires April 25, 2019 [Page 6] Internet-Draft CBOR Profile of X.509 Certificates October 2018 5. Expected Certificate Sizes The profiling size saving mainly comes from enforcing removal of issuer and subject info fields besides the common name. The encoding savings are presented above in Section 3, resulting in the numbers shown in Figure 1. +-------------------------------------------------------------+ | | X.509 | X.509 Profiled | CBOR Encoded | +-------------------------------------------------------------+ | Cert. Size | 450 | 392 | 238 | +-------------------------------------------------------------+ Figure 1: Comparing Sizes of Certificates (bytes) 6. Native CBOR Certificates Further performance improvements can be achieved with the use of native CBOR certificates. In this case the signature is calculated over the CBOR encoded structure rather than the ASN.1 encoded structure. This removes entirely the need for ASN.1 and reduces the processing in the authenticating devices. This solution applies when the devices are only required to authenticate with a set of native CBOR certificate compatible servers, which may become a preferred approach for future deployments. The mapping between X.509 and CBOR certificates enables a migration path between the backwards compatible format and the fully optimized format. 7. Security Considerations The CBOR profiling of X.509 certificates does not change the security assumptions needed when deploying standard X.509 certificates but decreases the number of fields transmitted, which reduces the risk for implementation errors. Conversion between the certificate formats can be made in constant time to reduce risk of information leakage through side channels. 8. Privacy Considerations The mechanism in this draft does not reveal any additional information compared to X.509. Because of difference in size, it will be possible to detect that this profile is used. Raza, et al. Expires April 25, 2019 [Page 7] Internet-Draft CBOR Profile of X.509 Certificates October 2018 The gateway solution described in Section 4 requires unencrypted certificates. 9. IANA Considerations None. 10. References 10.1. Normative References [I-D.ietf-cbor-7049bis] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", draft-ietf-cbor-7049bis-03 (work in progress), September 2018. [I-D.ietf-cbor-cddl] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures", draft-ietf-cbor- cddl-05 (work in progress), August 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [I-D.selander-ace-cose-ecdhe] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- cose-ecdhe-10 (work in progress), September 2018. [PointCompression] Miller, V., "Use of Elliptic Curves in Cryptography.", Springer, Cham. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol 218., 1986, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . Raza, et al. Expires April 25, 2019 [Page 8] Internet-Draft CBOR Profile of X.509 Certificates October 2018 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, . [X.509-IoT] Forsby, F., Furuhed, M., Papadimitratos, P., and S. Raza, "Lightweight X.509 Digital Certificates for the Internet of Things.", Springer, Cham. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol 242., July 2018, . Appendix A. CBOR Certificate, CDDL certificate = [ serial_number : uint, issuer : text, validity : [notBefore: int, notAfter: int], subject : text / bytes public_key : bytes ? extensions : [+ extension], signature : bytes ] extension = [ oid : int, ? critical : bool, value : bytes ] Appendix B. X.509 Certificate Profile, ASN.1 IOTCertificate DEFINITIONS EXPLICIT TAGS ::= BEGIN Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm SignatureIdentifier, signature BIT STRING } TBSCertificate ::= SEQUENCE { Raza, et al. Expires April 25, 2019 [Page 9] Internet-Draft CBOR Profile of X.509 Certificates October 2018 version [0] INTEGER {v3(2)}, serialNumber INTEGER (1..MAX), signature SignatureIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, extensions [3] Extensions OPTIONAL } SignatureIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER (ecdsa-with-SHA256) Name ::= SEQUENCE SIZE (1) OF DistinguishedName DistinguishedName ::= SET SIZE (1) OF CommonName CommonName ::= SEQUENCE { type OBJECT IDENTIFIER (id-at-commonName), value UTF8String -- For a CA, value is CA name, else EUI-64 in format -- "01-23-54-FF-FE-AB-CD-EF" } Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } SubjectPublicKeyInfo::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER (id-ecPublicKey), parameters OBJECT IDENTIFIER (prime256v1) } Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnId OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } ansi-X9-62 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 10045} id-ecPublicKey OBJECT IDENTIFIER ::= {ansi-X9-62 keyType(2) 1} Raza, et al. Expires April 25, 2019 [Page 10] Internet-Draft CBOR Profile of X.509 Certificates October 2018 prime256v1 OBJECT IDENTIFIER ::= {ansi-X9-62 curves(3) prime(1) 7} ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {ansi-X9-62 signatures(4) ecdsa-with-SHA2(3) 2} id-at-commonName OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) ds(5) attributeType(4) 3} END Authors' Addresses Shahid Raza RISE AB Email: shahid.raza@ri.se Joel Hoeglund RISE AB Email: joel.hoglund@ri.se Goeran Selander Ericsson AB Email: goran.selander@ericsson.com John Mattsson Ericsson AB Email: john.mattsson@ericsson.com Raza, et al. Expires April 25, 2019 [Page 11]