idnits 2.17.1 draft-raza-ace-cbor-certificates-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 : ---------------------------------------------------------------------------- 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 (March 11, 2019) is 1866 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 (-08) exists of draft-ietf-cbor-cddl-07 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-12 -- 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: September 12, 2019 G. Selander 6 J. Mattsson 7 Ericsson AB 8 M. Furuhed 9 Nexus Group 10 March 11, 2019 12 CBOR Profile of X.509 Certificates 13 draft-raza-ace-cbor-certificates-01 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 September 12, 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 . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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) [I-D.ietf-cbor-cddl] provides a way to express 99 structures for protocol messages and APIs that use CBOR. 100 [I-D.ietf-cbor-cddl] also extends the 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 [I-D.ietf-cbor-cddl]. 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 fixed to 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 fixed to prime256v1. 180 o Issuer Unique ID and Subject Unique ID. These fields are optional 181 in X.509 and MUST NOT be used with the CBOR profile. 183 o Extensions. Extensions consist of three parts; an OID, a boolean 184 telling if it is critical or not, and the value. To maintain 185 forward compatibility, the CBOR profile does not restrict the use 186 of extensions. By the X.509-standard, any device must be able to 187 process eight extensions types. Since only four of them are 188 critical for IoT, this profile is making the other four optional. 189 Still mandatory to be understood are: 191 * Key Usage 193 * Subject Alternative Name 195 * Basic Constraints 197 * Extended Key Usage 199 o Certificate signature algorithm. This field duplicates the info 200 present in the signature algorithm field. Fixed to ECDSA with 201 SHA256. 203 o Certificate Signature. The field corresponds to the signature 204 done by the CA private key. For the CBOR profile, this is 205 restricted to ECDSA type signatures with a signature length of 64 206 bits. 208 3. CBOR Encoding 210 This section specifies the CBOR certificates, which are the result of 211 the CBOR encoding and lossless compression of the X.509 certificate 212 profile of the previous section. The CDDL representation is given in 213 Appendix A. 215 The encoding and compression has several components including: ASN.1 216 and base64 encoding is replaced with CBOR encoding, static fields are 217 elided, and compression of elliptic curve points. The field 218 encodings and associated savings are listed below. Combining these 219 different components reduces the certificate size significantly, see 220 Figure 1. 222 o Version number. The version number field is omitted in the 223 encoding. This saves 5 bytes. 225 o Serial number. The serial number is encoded as an unsigned 226 integer. Encoding overhead is reduced by one byte. 228 o Signature algorithm. The signature algorithm is known from the 229 profile and is omitted in the ecoding. This saves 12 bytes. 231 o Issuer. Since the profile only allows the common name type, the 232 common name type specifier is omitted. In total, the issuer field 233 encoding overhead goes from 13 bytes to one byte. 235 o Validity. The time is encoded as UnixTime in integer format. The 236 validity is represented as a 'not before'-'not after' pair of 237 integer. This reduces the size from 32 to 11 bytes. 239 o Subject. An IoT subject is identified by a EUI-64, in turn based 240 on a 48bit unique MAC id. This is encoded using only 7 bytes 241 using CBOR. This is a reduction down from 36 bytes for the 242 corresponding ASN.1 encoding. 244 o Subject public key info. The algorithm identifier is known from 245 the profile restrictions and is omitted. One of the public key 246 ECC curve point elements can be calculated from the other, hence 247 only one of the curve points is needed (point compression, see 248 [PointCompression]). These actions together reduce size from 91 249 to 35 bytes. 251 o Extensions. Minor savings are achieved by the compact CBOR 252 encoding. In addition, the relevant X.509 extension OIDs always 253 start with 0x551D, hence these two bytes can be omitted. 255 o Certificate signature algorithm. The signature algorithm is known 256 from the profile and is omitted in the ecoding. 258 o Signature. Since the signature algorithm and resulting signature 259 length are known, padding and extra length fields which are 260 present in the ASN.1 encoding are omitted. The overhead for 261 encoding the 64-bit signature value is reduced from 11 to 2 bytes. 263 4. Deployment settings 265 CBOR certificates can be deployed with legacy X.509 certificates and 266 CA infrastructure. In order to verify the signature, the CBOR 267 certificate is used to recreate the original X.509 data structure to 268 be able to verify the signature. 270 For the currently used DTLS v1.2 protocol, where the handshake is 271 sent unencrypted, the actual encoding and compression can be done at 272 different locations depending on the deployment setting. For 273 example, the mapping between CBOR certificate and standard X.509 274 certificate can take place in a 6LoWPAN border gateway which allows 275 the server side to stay unmodified. This case gives the advantage of 276 the low overhead of a CBOR certificate over a constrained wireless 277 links. The conversion to X.509 within an IoT device will incur a 278 computational overhead, however, this is negligible compared to the 279 reduced communication overhead. 281 For the setting with constrained server and server-only 282 authentication, the server only needs to be provisioned with the CBOR 283 certificate and does not perform the conversion to X.509. This 284 option is viable when client authentication can be asserted by other 285 means. 287 For DTLS v1.3, because certificates are encrypted, the proposed 288 encoding needs to be done fully end-to-end, through adding the 289 endcoding/decoding functionality to the server. A new certificate 290 format or new certificate compression scheme needs to be added. 291 While that requires changes on the server side, we believe it to be 292 in line with other proposals utilizing cbor encoding for 293 communication with resource constrained devices. 295 5. Expected Certificate Sizes 297 The profiling size saving mainly comes from enforcing removal of 298 issuer and subject info fields besides the common name. The encoding 299 savings are presented above in Section 3, for a sample certificate 300 given in Appendix C resulting in the numbers shown in Figure 1. 302 +---------------------------------------------------+ 303 | | X.509 Profiled | CBOR Encoded | 304 +---------------------------------------------------+ 305 | Certificate Size | 342 | 164 | 306 +---------------------------------------------------+ 308 Figure 1: Comparing Sizes of Certificates (bytes) 310 6. Native CBOR Certificates 312 Further performance improvements can be achieved with the use of 313 native CBOR certificates. In this case the signature is calculated 314 over the CBOR encoded structure rather than the ASN.1 encoded 315 structure. This removes entirely the need for ASN.1 and reduces the 316 processing in the authenticating devices. 318 This solution applies when the devices are only required to 319 authenticate with a set of native CBOR certificate compatible 320 servers, which may become a preferred approach for future 321 deployments. The mapping between X.509 and CBOR certificates enables 322 a migration path between the backwards compatible format and the 323 fully optimized format. 325 7. Security Considerations 327 The CBOR profiling of X.509 certificates does not change the security 328 assumptions needed when deploying standard X.509 certificates but 329 decreases the number of fields transmitted, which reduces the risk 330 for implementation errors. 332 Conversion between the certificate formats can be made in constant 333 time to reduce risk of information leakage through side channels. 335 The current version of the format hardcodes the signature algorithm 336 which does not allow for crypto agility. A COSE crypto algorithm can 337 be specified with small overhead, and this changed is proposed for a 338 future version of the draft. 340 8. Privacy Considerations 342 The mechanism in this draft does not reveal any additional 343 information compared to X.509. 345 Because of difference in size, it will be possible to detect that 346 this profile is used. 348 The gateway solution described in Section 4 requires unencrypted 349 certificates. 351 9. IANA Considerations 353 None. 355 10. References 357 10.1. Normative References 359 [I-D.ietf-cbor-7049bis] 360 Bormann, C. and P. Hoffman, "Concise Binary Object 361 Representation (CBOR)", draft-ietf-cbor-7049bis-05 (work 362 in progress), January 2019. 364 [I-D.ietf-cbor-cddl] 365 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 366 definition language (CDDL): a notational convention to 367 express CBOR and JSON data structures", draft-ietf-cbor- 368 cddl-07 (work in progress), February 2019. 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 376 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 377 May 2017, . 379 10.2. Informative References 381 [I-D.selander-ace-cose-ecdhe] 382 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 383 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 384 cose-ecdhe-12 (work in progress), February 2019. 386 [PointCompression] 387 Miller, V., "Use of Elliptic Curves in Cryptography.", 388 Springer, Cham. Lecture Notes of the Institute for 389 Computer Sciences, Social Informatics and 390 Telecommunications Engineering, vol 218., 1986, 391 . 393 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 394 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 395 January 2012, . 397 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 398 Constrained-Node Networks", RFC 7228, 399 DOI 10.17487/RFC7228, May 2014, 400 . 402 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 403 Security (TLS) / Datagram Transport Layer Security (DTLS) 404 Profiles for the Internet of Things", RFC 7925, 405 DOI 10.17487/RFC7925, July 2016, 406 . 408 [X.509-IoT] 409 Forsby, F., Furuhed, M., Papadimitratos, P., and S. Raza, 410 "Lightweight X.509 Digital Certificates for the Internet 411 of Things.", Springer, Cham. Lecture Notes of the 412 Institute for Computer Sciences, Social Informatics and 413 Telecommunications Engineering, vol 242., July 2018, 414 . 416 Appendix A. CBOR Certificate, CDDL 418 certificate = [ 419 serial_number : uint, 420 issuer : text, 421 validity : [notBefore: int, notAfter: int], 422 subject : text / bytes 423 public_key : bytes 424 ? extensions : [+ extension], 425 signature : bytes 426 ] 428 extension = [ 429 oid : int, 430 ? critical : bool, 431 value : bytes 432 ] 434 Appendix B. X.509 Certificate Profile, ASN.1 436 IOTCertificate DEFINITIONS EXPLICIT TAGS ::= BEGIN 438 Certificate ::= SEQUENCE { 439 tbsCertificate TBSCertificate, 440 signatureAlgorithm SignatureIdentifier, 441 signature BIT STRING 442 } 444 TBSCertificate ::= SEQUENCE { 445 version \[0\] INTEGER {v3(2)}, 446 serialNumber INTEGER (1..MAX), 447 signature SignatureIdentifier, 448 issuer Name, 449 validity Validity, 450 subject Name, 451 subjectPublicKeyInfo SubjectPublicKeyInfo, 452 extensions \[3\] Extensions OPTIONAL 453 } 455 SignatureIdentifier ::= SEQUENCE { 456 algorithm OBJECT IDENTIFIER (ecdsa-with-SHA256) 457 Name ::= SEQUENCE SIZE (1) OF DistinguishedName 458 DistinguishedName ::= SET SIZE (1) OF CommonName 459 CommonName ::= SEQUENCE { 460 type OBJECT IDENTIFIER (id-at-commonName), 461 value UTF8String 462 -- For a CA, value is CA name, else EUI-64 in format 463 -- "01-23-54-FF-FE-AB-CD-EF" 465 } 467 Validity ::= SEQUENCE { 468 notBefore UTCTime, 469 notAfter UTCTime 470 } 472 SubjectPublicKeyInfo::= SEQUENCE { 473 algorithm AlgorithmIdentifier, 474 subjectPublicKey BIT STRING 475 } 477 AlgorithmIdentifier ::= SEQUENCE { 478 algorithm OBJECT IDENTIFIER (id-ecPublicKey), 479 parameters OBJECT IDENTIFIER (prime256v1) 480 } 481 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 483 Extension ::= SEQUENCE { 484 extnId OBJECT IDENTIFIER, 485 critical BOOLEAN DEFAULT FALSE, 486 extnValue OCTET STRING 487 } 489 ansi-X9-62 OBJECT IDENTIFIER ::= 490 {iso(1) member-body(2) us(840) 10045} 492 id-ecPublicKey OBJECT IDENTIFIER ::= 493 {ansi-X9-62 keyType(2) 1} 495 prime256v1 OBJECT IDENTIFIER ::= 496 {ansi-X9-62 curves(3) prime(1) 7} 498 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= 499 {ansi-X9-62 signatures(4) ecdsa-with-SHA2(3) 2} 501 id-at-commonName OBJECT IDENTIFIER ::= 502 {joint-iso-itu-t(2) ds(5) attributeType(4) 3} 504 END 506 Appendix C. Certificate Example 508 This section shows an example of an X.509 profiled certificate before 509 CBOR encoding. 511 Certificate: 512 Data: 513 Version: 3 (0x2) 514 Serial Number: DEC (HEX) 515 Signature Algorithm: ecdsa-with-SHA256 516 Issuer: <23 byte issuer ID> 517 Validity 518 Not Before: 519 Not After : 520 Subject: <23 byte UID> 521 Subject Public Key Info: 522 Public Key Algorithm: id-ecPublicKey 523 Public-Key: (256 bit) 524 pub: 525 .. .. .. 526 ASN1 OID: prime256v1 527 NIST CURVE: P-256 528 X509v3 extensions: 529 X509v3 Basic Constraints: critical 530 CA:FALSE 531 X509v3 Key Usage: 532 Digital Signature, Key Encipherment 533 Signature Algorithm: ecdsa-with-SHA256 534 .. .. ... 536 Authors' Addresses 538 Shahid Raza 539 RISE AB 541 Email: shahid.raza@ri.se 543 Joel Hoeglund 544 RISE AB 546 Email: joel.hoglund@ri.se 548 Goeran Selander 549 Ericsson AB 551 Email: goran.selander@ericsson.com 552 John Mattsson 553 Ericsson AB 555 Email: john.mattsson@ericsson.com 557 Martin Furuhed 558 Nexus Group 560 Email: martin.furuhed@nexusgroup.com