idnits 2.17.1 draft-raza-ace-cbor-certificates-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 24, 2019) is 1768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-cbor-7049bis-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' == Outdated reference: A later version (-10) exists of draft-ietf-tls-certificate-compression-05 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-13 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group S. Raza 3 Internet-Draft J. Hoeglund 4 Intended status: Standards Track RISE AB 5 Expires: December 26, 2019 G. Selander 6 J. Mattsson 7 Ericsson AB 8 M. Furuhed 9 Nexus Group 10 June 24, 2019 12 CBOR Profile of X.509 Certificates 13 draft-raza-ace-cbor-certificates-02 15 Abstract 17 This document specifies a CBOR encoding and profiling of X.509 public 18 key certificate suitable for Internet of Things (IoT) deployments. 19 The full X.509 public key certificate format and commonly used ASN.1 20 encoding is overly verbose for constrained IoT environments. 21 Profiling together with CBOR encoding reduces the certificate size 22 significantly with associated known performance benefits. 24 The CBOR certificates are compatible with the existing X.509 25 standard, enabling the use of profiled and compressed X.509 26 certificates without modifications in the existing X.509 standard. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 26, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. X.509 Certificate Profile . . . . . . . . . . . . . . . . . . 4 64 3. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Deployment settings . . . . . . . . . . . . . . . . . . . . . 6 66 5. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 7 67 6. Native CBOR Certificates . . . . . . . . . . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 10.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. CBOR Certificate, CDDL . . . . . . . . . . . . . . . 10 75 Appendix B. X.509 Certificate Profile, ASN.1 . . . . . . . . . . 10 76 Appendix C. Certificate Example . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 One of the challenges with deploying a Public Key Infrastructure 82 (PKI) for the Internet of Things (IoT) is the size and encoding of 83 X.509 public key certificates, since those are not optimized for 84 constrained environments [RFC7228]. More compact certificate 85 representations are desirable. Due to the current PKI usage of X.509 86 certificates, keeping X.509 compatibility is necessary at least for a 87 transition period. However, the use of a more compact encoding with 88 the Concise Binary Object Representation (CBOR) 89 [I-D.ietf-cbor-7049bis] reduces the certificate size significantly 90 which has known performance benefits in terms of decreased 91 communication overhead, power consumption, latency, storage, etc. 93 CBOR is a data format designed for small code size and small message 94 size. CBOR builds on the JSON data model but extends it by e.g. 95 encoding binary data directly without base64 conversion. In addition 96 to the binary CBOR encoding, CBOR also has a diagnostic notation that 97 is readable and editable by humans. The Concise Data Definition 98 Language (CDDL) [RFC8610] provides a way to express structures for 99 protocol messages and APIs that use CBOR. [RFC8610] also extends the 100 diagnostic notation. 102 CBOR data items are encoded to or decoded from byte strings using a 103 type-length-value encoding scheme, where the three highest order bits 104 of the initial byte contain information about the major type. CBOR 105 supports several different types of data items, in addition to 106 integers (int, uint), simple values (e.g. null), byte strings (bstr), 107 and text strings (tstr), CBOR also supports arrays of data items and 108 maps of pairs of data items. For a complete specification and 109 examples, see [I-D.ietf-cbor-7049bis] and [RFC8610]. 111 This document specifies the CBOR certificate profile, which is a CBOR 112 based encoding and compression of the X.509 certificate format. The 113 profile is based on previous work on profiling of X.509 certificates 114 for Internet of Things deployments [X.509-IoT] which retains 115 backwards compatibility with X.509, and can be applied for 116 lightweight certificate based authentication with e.g. DTLS 117 [RFC6347] or EDHOC [I-D.selander-ace-cose-ecdhe]. The same profile 118 can be used for "native" CBOR encoded certificates, which further 119 optimizes the performance in constrained environments but are not 120 backwards compatible with X.509, see Section 6. 122 Other work has looked at reducing size of X.509 certificates. The 123 purpose of this document is to stimulate a discussion on CBOR based 124 certificates. Further optimizations of this profile are known and 125 will be included in future versions. 127 o Terminology {#terminology} 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 This specification makes use of the terminology in [RFC7228]. 137 2. X.509 Certificate Profile 139 This profile is inspired by [RFC7925] and mandates further 140 restrictions to enable reduction of certificate size. In this 141 section we list the required fields in an X.509 certificate needed by 142 devices in IoT deployments. The corresponding ASN.1 schema is given 143 in Appendix B. 145 In order to comply with this certificate profile, the following 146 restrictions MUST be applied: 148 o Version number. The X.509 standard has not moved beyond version 3 149 since 2008. With the introduction of certificate extensions new 150 certificate fields can be added without breaking the format, 151 making version changes less likely. Therefore this profile fixes 152 the version number to 3. 154 o Serial number. The serial number together with the identity of 155 the CA is the unique identifier of a certificate. The serial 156 number MUST be an unsigned integer. 158 o Signature algorithm. For the CBOR profile, the signature 159 algorithm is by default assumed to be ECDSA with SHA256. 161 o Issuer. Used to identify the issuing CA through a sequence of 162 name-value pairs. This profile is restricting this to one pair, 163 common name and associated string value. The common name MUST 164 uniquely identify the CA. Other fields MUST NOT be used. 166 o Validity. The following representation MUST be used: UTCTime- 167 format, YYMMDDhhmmss. This is the most compact format allowed by 168 the X.509 standard. 170 o Subject. The subject section has the same format as the issuer, 171 identifying the receiver of the public key through a sequence of 172 name-value pairs. This sequence is in the profile restricted to a 173 single pair, subject name and associated (unique) value. For an 174 IoT-device, the MAC-derived EUI-64 serves this purpose well. 176 o Subject public key info. For the IoT devices, elliptic curve 177 cryptography based algorithms have clear advantages. For the IoT 178 profile the public key algorithm is by default assumed to be 179 prime256v1. 181 o Issuer Unique ID and Subject Unique ID. These fields are optional 182 in X.509 and MUST NOT be used with the CBOR profile. 184 o Extensions. Extensions consist of three parts; an OID, a boolean 185 telling if it is critical or not, and the value. To maintain 186 forward compatibility, the CBOR profile does not restrict the use 187 of extensions. By the X.509-standard, any device must be able to 188 process eight extensions types. Since only four of them are 189 critical for IoT, this profile is making the other four optional. 190 Still mandatory to be understood are: 192 * Key Usage 194 * Subject Alternative Name 196 * Basic Constraints 198 * Extended Key Usage 200 o Certificate signature algorithm. This field duplicates the info 201 present in the signature algorithm field. By default assumed to 202 be ECDSA with SHA256. 204 o Certificate Signature. The field corresponds to the signature 205 done by the CA private key. For the CBOR profile, this is 206 restricted to ECDSA type signatures with a signature length of 64 207 bits. 209 3. CBOR Encoding 211 This section specifies the CBOR certificates, which are the result of 212 the CBOR encoding and lossless compression of the X.509 certificate 213 profile of the previous section. The CDDL representation is given in 214 Appendix A. 216 The encoding and compression has several components including: ASN.1 217 and base64 encoding is replaced with CBOR encoding, static fields are 218 elided, and compression of elliptic curve points. The field 219 encodings and associated savings are listed below. Combining these 220 different components reduces the certificate size significantly, see 221 Figure 1. 223 o Version number. The version number field is omitted in the 224 encoding. This saves 5 bytes. 226 o Serial number. The serial number is encoded as an unsigned 227 integer. Encoding overhead is reduced by one byte. 229 o Signature algorithm. If the signature algorithm is the default it 230 is omitted in the encoding, otherwise encoded as a one byte COSE 231 identifier. This saves 11 or 12 bytes. 233 o Issuer. Since the profile only allows the common name type, the 234 common name type specifier is omitted. In total, the issuer field 235 encoding overhead goes from 13 bytes to one byte. 237 o Validity. The time is encoded as UnixTime in integer format. The 238 validity is represented as a 'not before'-'not after' pair of 239 integer. This reduces the size from 32 to 11 bytes. 241 o Subject. An IoT subject is identified by a EUI-64, in turn based 242 on a 48bit unique MAC id. This is encoded using only 7 bytes 243 using CBOR. This is a reduction down from 36 bytes for the 244 corresponding ASN.1 encoding. 246 o Subject public key info. If the algorithm identifier is the 247 default, it is omitted, otherwise encoded as a one byte COSE 248 identifier. For the allowed ECC type keys, one of the public key 249 ECC curve point elements can be calculated from the other, hence 250 only one of the curve points is needed (point compression, see 251 [PointCompression]). These actions together, for the default 252 algorithm, reduce size from 91 to 35 bytes. 254 o Extensions. Minor savings are achieved by the compact CBOR 255 encoding. In addition, the relevant X.509 extension OIDs always 256 start with 0x551D, hence these two bytes can be omitted. 258 o Certificate signature algorithm. This algorithm field is always 259 the same as the above signature algorithm, and is omitted in the 260 encoding. 262 o Signature. Since the signature algorithm and resulting signature 263 length are known, padding and extra length fields which are 264 present in the ASN.1 encoding are omitted. The overhead for 265 encoding the 64-bit signature value is reduced from 11 to 2 bytes. 267 4. Deployment settings 269 CBOR certificates can be deployed with legacy X.509 certificates and 270 CA infrastructure. In order to verify the signature, the CBOR 271 certificate is used to recreate the original X.509 data structure to 272 be able to verify the signature. 274 For the currently used DTLS v1.2 protocol, where the handshake is 275 sent unencrypted, the actual encoding and compression can be done at 276 different locations depending on the deployment setting. For 277 example, the mapping between CBOR certificate and standard X.509 278 certificate can take place in a 6LoWPAN border gateway which allows 279 the server side to stay unmodified. This case gives the advantage of 280 the low overhead of a CBOR certificate over a constrained wireless 281 links. The conversion to X.509 within an IoT device will incur a 282 computational overhead, however, this is negligible compared to the 283 reduced communication overhead. 285 For the setting with constrained server and server-only 286 authentication, the server only needs to be provisioned with the CBOR 287 certificate and does not perform the conversion to X.509. This 288 option is viable when client authentication can be asserted by other 289 means. 291 For DTLS v1.3, because certificates are encrypted, the proposed 292 encoding needs to be done fully end-to-end, through adding the 293 encoding/decoding functionality to the server. A new certificate 294 format or new certificate compression scheme needs to be added. 295 While that requires changes on the server side, we believe it to be 296 in line with other proposals utilizing cbor encoding for 297 communication with resource constrained devices. 299 5. Expected Certificate Sizes 301 The profiling size saving mainly comes from enforcing removal of 302 issuer and subject info fields besides the common name. The encoding 303 savings are presented above in Section 3, for a sample certificate 304 given in Appendix C resulting in the numbers shown in Figure 1. 306 After profiling, all duplicated information has been removed, and 307 remaining text strings are minimal in size. Therefore no further 308 size reduction can be reached with general compression mechanisms. 309 (In practice the size might even grow slightly due to the compression 310 encoding information, as illustrated in the table below.) 312 +---------------------------------------------------+ 313 | | X.509 Profiled | CBOR Encoded | 314 +---------------------------------------------------+ 315 | Certificate Size | 313 | 144 | 316 +---------------------------------------------------+ 318 +-----------------------------------------------------------------+ 319 | | X.509 Profiled | CBOR Encoded | Zlib | 320 +-----------------------------------------------------------------+ 321 | Certificate Size | 313 | 144 | 319 | 322 +-----------------------------------------------------------------+ 324 Figure 1: Comparing Sizes of Certificates (bytes) 326 6. Native CBOR Certificates 328 Further performance improvements can be achieved with the use of 329 native CBOR certificates. In this case the signature is calculated 330 over the CBOR encoded structure rather than the ASN.1 encoded 331 structure. This removes entirely the need for ASN.1 and reduces the 332 processing in the authenticating devices. 334 This solution applies when the devices are only required to 335 authenticate with a set of native CBOR certificate compatible 336 servers, which may become a preferred approach for future 337 deployments. The mapping between X.509 and CBOR certificates enables 338 a migration path between the backwards compatible format and the 339 fully optimized format. 341 7. Security Considerations 343 The CBOR profiling of X.509 certificates does not change the security 344 assumptions needed when deploying standard X.509 certificates but 345 decreases the number of fields transmitted, which reduces the risk 346 for implementation errors. 348 Conversion between the certificate formats can be made in constant 349 time to reduce risk of information leakage through side channels. 351 The current version of the format hardcodes the signature algorithm 352 which does not allow for crypto agility. A COSE crypto algorithm can 353 be specified with small overhead, and this changed is proposed for a 354 future version of the draft. 356 8. Privacy Considerations 358 The mechanism in this draft does not reveal any additional 359 information compared to X.509. 361 Because of difference in size, it will be possible to detect that 362 this profile is used. 364 The gateway solution described in Section 4 requires unencrypted 365 certificates. 367 9. IANA Considerations 369 This document registers a compression algorithm in the registry 370 entitled "Certificate Compression Algorithm IDs", under the 371 "Transport Layer Security (TLS) Extensions" heading (see 372 [I-D.ietf-tls-certificate-compression]). 374 +------------------+--------------------------+ 375 | Algorithm Number | Description | 376 +------------------+--------------------------+ 377 | TBD | cbor-iot | 378 +------------------+--------------------------+ 380 10. References 382 10.1. Normative References 384 [I-D.ietf-cbor-7049bis] 385 Bormann, C. and P. Hoffman, "Concise Binary Object 386 Representation (CBOR)", draft-ietf-cbor-7049bis-05 (work 387 in progress), January 2019. 389 [I-D.ietf-tls-certificate-compression] 390 Ghedini, A. and V. Vasiliev, "TLS Certificate 391 Compression", draft-ietf-tls-certificate-compression-05 392 (work in progress), April 2019. 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 400 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 401 May 2017, . 403 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 404 Definition Language (CDDL): A Notational Convention to 405 Express Concise Binary Object Representation (CBOR) and 406 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 407 June 2019, . 409 10.2. Informative References 411 [I-D.selander-ace-cose-ecdhe] 412 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 413 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 414 cose-ecdhe-13 (work in progress), March 2019. 416 [PointCompression] 417 Miller, V., "Use of Elliptic Curves in Cryptography.", 418 Springer, Cham. Lecture Notes of the Institute for 419 Computer Sciences, Social Informatics and 420 Telecommunications Engineering, vol 218., 1986, 421 . 423 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 424 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 425 January 2012, . 427 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 428 Constrained-Node Networks", RFC 7228, 429 DOI 10.17487/RFC7228, May 2014, 430 . 432 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 433 Security (TLS) / Datagram Transport Layer Security (DTLS) 434 Profiles for the Internet of Things", RFC 7925, 435 DOI 10.17487/RFC7925, July 2016, 436 . 438 [X.509-IoT] 439 Forsby, F., Furuhed, M., Papadimitratos, P., and S. Raza, 440 "Lightweight X.509 Digital Certificates for the Internet 441 of Things.", Springer, Cham. Lecture Notes of the 442 Institute for Computer Sciences, Social Informatics and 443 Telecommunications Engineering, vol 242., July 2018, 444 . 446 Appendix A. CBOR Certificate, CDDL 448 certificate = [ 449 serial_number : uint, 450 issuer : text, 451 validity : [notBefore: int, notAfter: int], 452 subject : text / bytes 453 public_key : bytes 454 ? extensions : [+ extension], 455 signature : bytes 456 ? signature_alg + public_key_info : bytes 457 ] 459 extension = [ 460 oid : int, 461 ? critical : bool, 462 value : bytes 463 ] 465 Appendix B. X.509 Certificate Profile, ASN.1 467 IOTCertificate DEFINITIONS EXPLICIT TAGS ::= BEGIN 469 Certificate ::= SEQUENCE { 470 tbsCertificate TBSCertificate, 471 signatureAlgorithm SignatureIdentifier, 472 signature BIT STRING 473 } 475 TBSCertificate ::= SEQUENCE { 476 version \[0\] INTEGER {v3(2)}, 477 serialNumber INTEGER (1..MAX), 478 signature SignatureIdentifier, 479 issuer Name, 480 validity Validity, 481 subject Name, 482 subjectPublicKeyInfo SubjectPublicKeyInfo, 483 extensions \[3\] Extensions OPTIONAL 484 } 486 SignatureIdentifier ::= SEQUENCE { 487 algorithm OBJECT IDENTIFIER (ecdsa-with-SHA256) 488 Name ::= SEQUENCE SIZE (1) OF DistinguishedName 489 DistinguishedName ::= SET SIZE (1) OF CommonName 490 CommonName ::= SEQUENCE { 491 type OBJECT IDENTIFIER (id-at-commonName), 492 value UTF8String 493 -- For a CA, value is CA name, else EUI-64 in format 494 -- "01-23-54-FF-FE-AB-CD-EF" 495 } 497 Validity ::= SEQUENCE { 498 notBefore UTCTime, 499 notAfter UTCTime 500 } 502 SubjectPublicKeyInfo::= SEQUENCE { 503 algorithm AlgorithmIdentifier, 504 subjectPublicKey BIT STRING 505 } 507 AlgorithmIdentifier ::= SEQUENCE { 508 algorithm OBJECT IDENTIFIER (id-ecPublicKey), 509 parameters OBJECT IDENTIFIER (prime256v1) 510 } 511 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 513 Extension ::= SEQUENCE { 514 extnId OBJECT IDENTIFIER, 515 critical BOOLEAN DEFAULT FALSE, 516 extnValue OCTET STRING 517 } 519 ansi-X9-62 OBJECT IDENTIFIER ::= 520 {iso(1) member-body(2) us(840) 10045} 522 id-ecPublicKey OBJECT IDENTIFIER ::= 523 {ansi-X9-62 keyType(2) 1} 525 prime256v1 OBJECT IDENTIFIER ::= 526 {ansi-X9-62 curves(3) prime(1) 7} 528 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= 529 {ansi-X9-62 signatures(4) ecdsa-with-SHA2(3) 2} 531 id-at-commonName OBJECT IDENTIFIER ::= 532 {joint-iso-itu-t(2) ds(5) attributeType(4) 3} 534 END 536 Appendix C. Certificate Example 538 This section shows an example of an X.509 profiled certificate before 539 CBOR encoding. 541 Certificate: 542 Data: 543 Version: 3 (0x2) 544 Serial Number: DEC (HEX) 545 Signature Algorithm: ecdsa-with-SHA256 546 Issuer: <23 byte issuer ID> 547 Validity 548 Not Before: 549 Not After : 550 Subject: <23 byte UID> 551 Subject Public Key Info: 552 Public Key Algorithm: id-ecPublicKey 553 Public-Key: (256 bit) 554 pub: 555 .. .. .. 556 ASN1 OID: prime256v1 557 NIST CURVE: P-256 558 X509v3 extensions: 559 X509v3 Basic Constraints: critical 560 CA:FALSE 561 X509v3 Key Usage: 562 Digital Signature, Key Encipherment 563 Signature Algorithm: ecdsa-with-SHA256 564 .. .. ... 566 Authors' Addresses 568 Shahid Raza 569 RISE AB 571 Email: shahid.raza@ri.se 573 Joel Hoeglund 574 RISE AB 576 Email: joel.hoglund@ri.se 578 Goeran Selander 579 Ericsson AB 581 Email: goran.selander@ericsson.com 583 John Mattsson 584 Ericsson AB 586 Email: john.mattsson@ericsson.com 588 Martin Furuhed 589 Nexus Group 591 Email: martin.furuhed@nexusgroup.com