idnits 2.17.1 draft-raza-ace-cbor-certificates-00.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 (October 22, 2018) is 2006 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) -- Looks like a reference, but probably isn't: '0' on line 432 -- Looks like a reference, but probably isn't: '3' on line 439 == Outdated reference: A later version (-16) exists of draft-ietf-cbor-7049bis-03 -- 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-05 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-10 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: April 25, 2019 G. Selander 6 J. Mattsson 7 Ericsson AB 8 October 22, 2018 10 CBOR Profile of X.509 Certificates 11 draft-raza-ace-cbor-certificates-00 13 Abstract 15 This document specifies a CBOR encoding and profiling of X.509 public 16 key certificate suitable for Internet of Things (IoT) deployments. 17 The full X.509 public key certificate format and commonly used ASN.1 18 encoding is overly verbose for constrained IoT environments. 19 Profiling together with CBOR encoding reduces the certificate size 20 significantly with associated known performance benefits. 22 The CBOR certificates are compatible with the existing X.509 23 standard, enabling the use of profiled and compressed X.509 24 certificates without modifications in the existing X.509 standard. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. X.509 Certificate Profile . . . . . . . . . . . . . . . . . . 3 62 3. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Deployment settings . . . . . . . . . . . . . . . . . . . . . 6 64 5. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 7 65 6. Native CBOR Certificates . . . . . . . . . . . . . . . . . . 7 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Appendix A. CBOR Certificate, CDDL . . . . . . . . . . . . . . . 9 73 Appendix B. X.509 Certificate Profile, ASN.1 . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 One of the challenges with deploying a Public Key Infrastructure 79 (PKI) for the Internet of Things (IoT) is the size and encoding of 80 X.509 public key certificates, since those are not optimized for 81 constrained environments [RFC7228]. More compact certificate 82 representations are desirable. Due to the current PKI usage of X.509 83 certificates, keeping X.509 compatibility is necessary at least for a 84 transition period. However, the use of a more compact encoding with 85 the Concise Binary Object Representation (CBOR) 86 [I-D.ietf-cbor-7049bis] reduces the certificate size significantly 87 which has known performance benefits in terms of decreased 88 communication overhead, power consumption, latency, storage, etc. 90 CBOR is a data format designed for small code size and small message 91 size. CBOR builds on the JSON data model but extends it by e.g. 92 encoding binary data directly without base64 conversion. In addition 93 to the binary CBOR encoding, CBOR also has a diagnostic notation that 94 is readable and editable by humans. The Concise Data Definition 95 Language (CDDL) [I-D.ietf-cbor-cddl] provides a way to express 96 structures for protocol messages and APIs that use CBOR. 97 [I-D.ietf-cbor-cddl] also extends the diagnostic notation. 99 CBOR data items are encoded to or decoded from byte strings using a 100 type-length-value encoding scheme, where the three highest order bits 101 of the initial byte contain information about the major type. CBOR 102 supports several different types of data items, in addition to 103 integers (int, uint), simple values (e.g. null), byte strings (bstr), 104 and text strings (tstr), CBOR also supports arrays of data items and 105 maps of pairs of data items. For a complete specification and 106 examples, see [I-D.ietf-cbor-7049bis] and [I-D.ietf-cbor-cddl]. 108 This document specifies the CBOR certificate profile, which is a CBOR 109 based encoding and compression of the X.509 certificate format. The 110 profile is based on previous work on profiling of X.509 certificates 111 for Internet of Things deployments [X.509-IoT] which retains 112 backwards compatibility with X.509, and can be applied for 113 lightweight certificate based authentication with e.g. DTLS 114 [RFC6347] or EDHOC [I-D.selander-ace-cose-ecdhe]. The same profile 115 can be used for "native" CBOR encoded certificates, which further 116 optimizes the performance in constrained environments but are not 117 backwards compatible with X.509, see Section 6. 119 Other work has looked at reducing size of X.509 certificates. The 120 purpose of this document is to stimulate a discussion on CBOR based 121 certificates. Further optimizations of this profile are known and 122 will be included in future versions. 124 o Terminology {#terminology} 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 This specification makes use of the terminology in [RFC7228]. 134 2. X.509 Certificate Profile 136 This profile is inspired by [RFC7925] and mandates further 137 restrictions to enable reduction of certificate size. In this 138 section we list the required fields in an X.509 certificate needed by 139 devices in IoT deployments. The corresponding ASN.1 schema is given 140 in Appendix B. 142 In order to comply with this certificate profile, the following 143 restrictions MUST be applied: 145 o Version number. The X.509 standard has not moved beyond version 3 146 since 2008. With the introduction of certificate extensions new 147 certificate fields can be added without breaking the format, 148 making version changes less likely. Therefore this profile fixes 149 the version number to 3. 151 o Serial number. The serial number together with the identity of 152 the CA is the unique identifier of a certificate. The X.509 153 standard does not specify the signedness of the serial number, but 154 this profile requires an unsigned integer. 156 o Signature algorithm. For the CBOR profile, the signature 157 algorithm is fixed to ECDSA with SHA256. 159 o Issuer. Used to identify the issuing CA through a sequence of 160 name-value pairs. This profile is restricting this to one pair, 161 common name and associated string value. The common name MUST 162 uniquely identify the CA. Other fields MUST NOT be used. 164 o Validity. The following representation MUST be used: UTCTime- 165 format, YYMMDDhhmmss. This is the most compact format allowed by 166 the X.509 standard. 168 o Subject. The subject section has the same format as the issuer, 169 identifying the receiver of the public key through a sequence of 170 name-value pairs. This sequence is in the profile restricted to a 171 single pair, subject name and associated (unique) value. For an 172 IoT-device, the MAC-derived EUI-64 serves this purpose well. 174 o Subject public key info. For the IoT devices, elliptic curve 175 cryptography based algorithms have clear advantages. For the IoT 176 profile the public key algorithm is fixed to prime256v1. 178 o Issuer Unique ID and Subject Unique ID. These fields are optional 179 in X.509 and MUST NOT be used with the CBOR profile. 181 o Extensions. Extensions consist of three parts; an OID, a boolean 182 telling if it is critical or not, and the value. To maintain 183 forward compatibility, the CBOR profile does not restrict the use 184 of extensions. By the X.509-standard, any device must be able to 185 process eight extensions types. Since only four of them are 186 critical for IoT, this profile is making the other four optional. 187 Still mandatory to be understood are: 189 * Key Usage 191 * Subject Alternative Name 192 * Basic Constraints 194 * Extended Key Usage 196 o Certificate signature algorithm. This field duplicates the info 197 present in the signature algorithm field. Fixed to ECDSA with 198 SHA256. 200 o Certificate Signature. The field corresponds to the signature 201 done by the CA private key. For the CBOR profile, this is 202 restricted to ECDSA type signatures with a signature length of 64 203 bits. 205 3. CBOR Encoding 207 This section specifies the CBOR certificates, which are the result of 208 the CBOR encoding and lossless compression of the X.509 certificate 209 profile of the previous section. The CDDL representation is given in 210 Appendix A. 212 The encoding and compression has several components including: ASN.1 213 and base64 encoding is replaced with CBOR encoding, static fields are 214 elided, and compression of elliptic curve points. The field 215 encodings and associated savings are listed below. Combining these 216 different components reduces the certificate size significantly, see 217 Figure 1. 219 o Version number. The version number field is omitted in the 220 encoding. This saves 5 bytes. 222 o Serial number. The serial number is encoded as an unsigned 223 integer. Encoding overhead is reduced by one byte. 225 o Signature algorithm. The signature algorithm is known from the 226 profile and is omitted in the ecoding. This saves 12 bytes. 228 o Issuer. Since the profile only allows the common name type, the 229 common name type specifier is omitted. In total, the issuer field 230 encoding overhead goes from 13 bytes to one byte. 232 o Validity. The time is encoded as UnixTime in integer format. The 233 validity is represented as a 'not before'-'not after' pair of 234 integer. This reduces the size from 32 to 11 bytes. 236 o Subject. An IoT subject is identified by a EUI-64, in turn based 237 on a 48bit unique MAC id. This is encoded using only 7 bytes 238 using CBOR. This is a reduction down from 36 bytes for the 239 corresponding ASN.1 encoding. 241 o Subject public key info. The algorithm identifier is known from 242 the profile restrictions and is omitted. One of the public key 243 ECC curve point elements can be calculated from the other, hence 244 only one of the curve points is needed (point compression, see 245 [PointCompression]). These actions together reduce size from 91 246 to 35 bytes. 248 o Extensions. Minor savings are achieved by the compact CBOR 249 encoding. In addition, the relevant X.509 extension OIDs always 250 start with 0x551D, hence these two bytes can be omitted. 252 o Certificate signature algorithm. The signature algorithm is known 253 from the profile and is omitted in the ecoding. 255 o Signature. Since the signature algorithm and resulting signature 256 length are known, padding and extra length fields which are 257 present in the ASN.1 encoding are omitted. The overhead for 258 encoding the 64-bit signature value is reduced from 11 to 2 bytes. 260 4. Deployment settings 262 CBOR certificates can be deployed with legacy X.509 certificates and 263 CA infrastructure. In order to verify the signature, the CBOR 264 certificate is used to recreate the original X.509 data structure to 265 be able to verify the signature. 267 For the currently used DTLS v1.2 protocol, where the handshake is 268 sent unencrypted, the actual encoding and compression can be done at 269 different locations depending on the deployment setting. For 270 example, the mapping between CBOR certificate and standard X.509 271 certificate can take place in a 6LoWPAN border gateway which allows 272 the server side to stay unmodified. This case gives the advantage of 273 the low overhead of a CBOR certificate over a constrained wireless 274 links. The conversion to X.509 within an IoT device will incur a 275 computational overhead, however, this is negligible compared to the 276 reduced communication overhead. 278 For the setting with constrained server and server-only 279 authentication, the server only needs to be provisioned with the CBOR 280 certificate and does not perform the conversion to X.509. This 281 option is viable when client authentication can be asserted by other 282 means. 284 For DTLS v1.3 the encoding needs to be done fully end-to-end, through 285 adding the endcoding/decoding functionality to the server. 287 5. Expected Certificate Sizes 289 The profiling size saving mainly comes from enforcing removal of 290 issuer and subject info fields besides the common name. The encoding 291 savings are presented above in Section 3, resulting in the numbers 292 shown in Figure 1. 294 +-------------------------------------------------------------+ 295 | | X.509 | X.509 Profiled | CBOR Encoded | 296 +-------------------------------------------------------------+ 297 | Cert. Size | 450 | 392 | 238 | 298 +-------------------------------------------------------------+ 300 Figure 1: Comparing Sizes of Certificates (bytes) 302 6. Native CBOR Certificates 304 Further performance improvements can be achieved with the use of 305 native CBOR certificates. In this case the signature is calculated 306 over the CBOR encoded structure rather than the ASN.1 encoded 307 structure. This removes entirely the need for ASN.1 and reduces the 308 processing in the authenticating devices. 310 This solution applies when the devices are only required to 311 authenticate with a set of native CBOR certificate compatible 312 servers, which may become a preferred approach for future 313 deployments. The mapping between X.509 and CBOR certificates enables 314 a migration path between the backwards compatible format and the 315 fully optimized format. 317 7. Security Considerations 319 The CBOR profiling of X.509 certificates does not change the security 320 assumptions needed when deploying standard X.509 certificates but 321 decreases the number of fields transmitted, which reduces the risk 322 for implementation errors. 324 Conversion between the certificate formats can be made in constant 325 time to reduce risk of information leakage through side channels. 327 8. Privacy Considerations 329 The mechanism in this draft does not reveal any additional 330 information compared to X.509. 332 Because of difference in size, it will be possible to detect that 333 this profile is used. 335 The gateway solution described in Section 4 requires unencrypted 336 certificates. 338 9. IANA Considerations 340 None. 342 10. References 344 10.1. Normative References 346 [I-D.ietf-cbor-7049bis] 347 Bormann, C. and P. Hoffman, "Concise Binary Object 348 Representation (CBOR)", draft-ietf-cbor-7049bis-03 (work 349 in progress), September 2018. 351 [I-D.ietf-cbor-cddl] 352 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 353 definition language (CDDL): a notational convention to 354 express CBOR and JSON data structures", draft-ietf-cbor- 355 cddl-05 (work in progress), August 2018. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 363 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 364 May 2017, . 366 10.2. Informative References 368 [I-D.selander-ace-cose-ecdhe] 369 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 370 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 371 cose-ecdhe-10 (work in progress), September 2018. 373 [PointCompression] 374 Miller, V., "Use of Elliptic Curves in Cryptography.", 375 Springer, Cham. Lecture Notes of the Institute for 376 Computer Sciences, Social Informatics and 377 Telecommunications Engineering, vol 218., 1986, 378 . 380 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 381 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 382 January 2012, . 384 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 385 Constrained-Node Networks", RFC 7228, 386 DOI 10.17487/RFC7228, May 2014, 387 . 389 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 390 Security (TLS) / Datagram Transport Layer Security (DTLS) 391 Profiles for the Internet of Things", RFC 7925, 392 DOI 10.17487/RFC7925, July 2016, 393 . 395 [X.509-IoT] 396 Forsby, F., Furuhed, M., Papadimitratos, P., and S. Raza, 397 "Lightweight X.509 Digital Certificates for the Internet 398 of Things.", Springer, Cham. Lecture Notes of the 399 Institute for Computer Sciences, Social Informatics and 400 Telecommunications Engineering, vol 242., July 2018, 401 . 403 Appendix A. CBOR Certificate, CDDL 405 certificate = [ 406 serial_number : uint, 407 issuer : text, 408 validity : [notBefore: int, notAfter: int], 409 subject : text / bytes 410 public_key : bytes 411 ? extensions : [+ extension], 412 signature : bytes 413 ] 415 extension = [ 416 oid : int, 417 ? critical : bool, 418 value : bytes 419 ] 421 Appendix B. X.509 Certificate Profile, ASN.1 423 IOTCertificate DEFINITIONS EXPLICIT TAGS ::= BEGIN 425 Certificate ::= SEQUENCE { 426 tbsCertificate TBSCertificate, 427 signatureAlgorithm SignatureIdentifier, 428 signature BIT STRING 429 } 431 TBSCertificate ::= SEQUENCE { 432 version [0] INTEGER {v3(2)}, 433 serialNumber INTEGER (1..MAX), 434 signature SignatureIdentifier, 435 issuer Name, 436 validity Validity, 437 subject Name, 438 subjectPublicKeyInfo SubjectPublicKeyInfo, 439 extensions [3] Extensions OPTIONAL 440 } 442 SignatureIdentifier ::= SEQUENCE { 443 algorithm OBJECT IDENTIFIER (ecdsa-with-SHA256) 444 Name ::= SEQUENCE SIZE (1) OF DistinguishedName 445 DistinguishedName ::= SET SIZE (1) OF CommonName 446 CommonName ::= SEQUENCE { 447 type OBJECT IDENTIFIER (id-at-commonName), 448 value UTF8String 449 -- For a CA, value is CA name, else EUI-64 in format 450 -- "01-23-54-FF-FE-AB-CD-EF" 451 } 453 Validity ::= SEQUENCE { 454 notBefore UTCTime, 455 notAfter UTCTime 456 } 458 SubjectPublicKeyInfo::= SEQUENCE { 459 algorithm AlgorithmIdentifier, 460 subjectPublicKey BIT STRING 461 } 463 AlgorithmIdentifier ::= SEQUENCE { 464 algorithm OBJECT IDENTIFIER (id-ecPublicKey), 465 parameters OBJECT IDENTIFIER (prime256v1) 466 } 467 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 469 Extension ::= SEQUENCE { 470 extnId OBJECT IDENTIFIER, 471 critical BOOLEAN DEFAULT FALSE, 472 extnValue OCTET STRING 473 } 475 ansi-X9-62 OBJECT IDENTIFIER ::= 476 {iso(1) member-body(2) us(840) 10045} 478 id-ecPublicKey OBJECT IDENTIFIER ::= 479 {ansi-X9-62 keyType(2) 1} 481 prime256v1 OBJECT IDENTIFIER ::= 482 {ansi-X9-62 curves(3) prime(1) 7} 484 ecdsa-with-SHA256 OBJECT IDENTIFIER ::= 485 {ansi-X9-62 signatures(4) ecdsa-with-SHA2(3) 2} 487 id-at-commonName OBJECT IDENTIFIER ::= 488 {joint-iso-itu-t(2) ds(5) attributeType(4) 3} 490 END 492 Authors' Addresses 494 Shahid Raza 495 RISE AB 497 Email: shahid.raza@ri.se 499 Joel Hoeglund 500 RISE AB 502 Email: joel.hoglund@ri.se 504 Goeran Selander 505 Ericsson AB 507 Email: goran.selander@ericsson.com 509 John Mattsson 510 Ericsson AB 512 Email: john.mattsson@ericsson.com