idnits 2.17.1 draft-mattsson-cose-cbor-cert-compress-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 (July 13, 2020) is 1355 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 693 -- Looks like a reference, but probably isn't: '3' on line 700 == Unused Reference: 'I-D.ietf-tls-certificate-compression' is defined on line 489, but no explicit reference was found in the text == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-06 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Raza 3 Internet-Draft J. Hoeglund 4 Intended status: Standards Track RISE AB 5 Expires: January 14, 2021 G. Selander 6 J. Mattsson 7 Ericsson AB 8 M. Furuhed 9 Nexus Group 10 July 13, 2020 12 CBOR Profile of X.509 Certificates 13 draft-mattsson-cose-cbor-cert-compress-01 15 Abstract 17 This document specifies a CBOR encoding/compression of RFC 7925 18 profiled certificates. By using the fact that the certificates are 19 profiled, the CBOR certificate compression algorithms can in many 20 cases compress RFC 7925 profiled certificates with over 50%. This 21 document also specifies COSE headers for CBOR encoded certificates as 22 well as the use of the CBOR certificate compression algorithm with 23 TLS Certificate Compression in TLS 1.3 and DTLS 1.3. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 14, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 61 3. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Deployment settings . . . . . . . . . . . . . . . . . . . . . 7 63 5. Expected Certificate Sizes . . . . . . . . . . . . . . . . . 8 64 6. Native CBOR Certificates . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. CBOR Certificate Types Registry . . . . . . . . . . . . . 9 68 8.2. CBOR Certificate Signature Algorithms Registry . . . . . 9 69 8.3. CBOR Certificate Public Key Algorithms Registry . . . . . 10 70 8.4. COSE Header Parameters Registry . . . . . . . . . . . . . 10 71 8.5. TLS Certificate Compression Algorithm IDs Registry . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 9.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Appendix A. Example CBOR Certificates . . . . . . . . . . . . . 13 76 A.1. Example X.509 Certificate . . . . . . . . . . . . . . . . 13 77 A.2. Example CBOR Certificate Compression . . . . . . . . . . 15 78 A.3. Example Native CBOR Certificate . . . . . . . . . . . . . 15 79 Appendix B. X.509 Certificate Profile, ASN.1 . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 One of the challenges with deploying a Public Key Infrastructure 85 (PKI) for the Internet of Things (IoT) is the size and encoding of 86 X.509 public key certificates [RFC5280], since those are not 87 optimized for constrained environments [RFC7228]. More compact 88 certificate representations are desirable. Due to the current PKI 89 usage of X.509 certificates, keeping X.509 compatibility is necessary 90 at least for a transition period. However, the use of a more compact 91 encoding with the Concise Binary Object Representation (CBOR) 92 [RFC7049] reduces the certificate size significantly which has known 93 performance benefits in terms of decreased communication overhead, 94 power consumption, latency, storage, etc. 96 CBOR is a data format designed for small code size and small message 97 size. CBOR builds on the JSON data model but extends it by e.g. 98 encoding binary data directly without base64 conversion. In addition 99 to the binary CBOR encoding, CBOR also has a diagnostic notation that 100 is readable and editable by humans. The Concise Data Definition 101 Language (CDDL) [RFC8610] provides a way to express structures for 102 protocol messages and APIs that use CBOR. [RFC8610] also extends the 103 diagnostic notation. 105 CBOR data items are encoded to or decoded from byte strings using a 106 type-length-value encoding scheme, where the three highest order bits 107 of the initial byte contain information about the major type. CBOR 108 supports several different types of data items, in addition to 109 integers (int, uint), simple values (e.g. null), byte strings (bstr), 110 and text strings (tstr), CBOR also supports arrays [] of data items, 111 maps {} of pairs of data items, and sequences of data items. For a 112 complete specification and examples, see [RFC7049], [RFC8610], and 113 [RFC8742]. 115 RFC 7925 [RFC7925] specifies a certificate profile for Internet of 116 Things deployments which can be applied for lightweight certificate 117 based authentication with e.g. TLS [RFC8446], DTLS 118 [I-D.ietf-tls-dtls13], COSE [RFC8152], or EDHOC 119 [I-D.ietf-lake-edhoc]. This document specifies the CBOR encoding/ 120 compression of RFC 7925 profiled X.509 certificates based on 121 [X.509-IoT]. Two variants are defined using exactly the same CBOR 122 encoding and differing only in what is being signed: 124 o The CBOR compressed X.509 certificate, which can be decompressed 125 into a certificate that can be verified by code compatible with 126 RFC 7925. 128 o The "native" CBOR encoded certificate, which further optimizes the 129 performance in constrained environments but is not backwards 130 compatible with RFC 7925, see Section 6. 132 Other work has looked at reducing the size of X.509 certificates. 133 The purpose of this document is to stimulate a discussion on CBOR 134 based certificates: what field values (in particular for 135 'issuer'/'subject') are relevant for constrained IoT applications, 136 what is the maximum compression that can be expected with CBOR, and 137 what is the right trade-off between compactness and generality. 139 This document specifies COSE headers for use of the CBOR certificate 140 encoding with COSE. The document also specifies the CBOR certificate 141 compression algorithm for use as TLS Certificate Compression with TLS 142 1.3 and DTLS 1.3. 144 2. Notational Conventions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 This specification makes use of the terminology in [RFC7228]. 154 3. CBOR Encoding 156 This section specifies the content and encoding for CBOR 157 certificates, with the overall objective to produce a very compact 158 representation of the certificate profile defined in [RFC7925]. The 159 CBOR certificate can be either a CBOR compressed X.509 certificate, 160 in which case the signature is calculated on the DER encoded ASN.1 161 data in the X.509 certificate, or a native CBOR certificate, in which 162 case the signature is calculated directly on the CBOR encoded data 163 (see Section 6). In both cases the certificate content is adhering 164 to the restrictions given by [RFC7925]. The corresponding ASN.1 165 schema is given in Appendix A. 167 The encoding and compression has several components including: ASN.1 168 DER and base64 encoding are replaced with CBOR encoding, static 169 fields are elided, and elliptic curve points are compressed. The 170 X.509 fields and their CBOR encodings are listed below. Combining 171 these different components reduces the certificate size 172 significantly, which is not possible with general purpose 173 compressions algorithms, see Figure 1. 175 CBOR certificates are defined in terms of RFC 7925 profiled X.509 176 certificates: 178 o version. The 'version' field is known (fixed to v3), and is 179 omitted in the CBOR encoding. 181 o serialNumber. The 'serialNumber' field is encoded as a CBOR byte 182 string. This allows encoding of all lengths with minimal 183 overhead. 185 o signature. The 'signature' field is always the same as the 186 'signatureAlgorithm' field and always omitted from the CBOR 187 encoding. 189 o issuer. In the general case, the Distinguished Name is encoded as 190 CBOR map, but if only CN is present the value can be encoded as a 191 single text value. 193 o validity. The 'notBefore' and 'notAfter' UTCTime fields are ASCII 194 string of the form "yymmddHHMMSSZ". They are encoded as the 195 unsigned integers using the following invertible encoding 196 (Horner's method with different bases). The resulting integer n 197 always fit in a 32 bit usigned integer. 199 n = SS + 60 * (MM + 60 * (HH + 24 * (dd + 32 * (mm + 13 * yy)))) 201 Decoding can be done by a succession of modulo and substraction 202 operations. I.e. SS = n mod 60, MM = ((n - SS) / 60) mod 60, 203 etc. 205 o subject. The 'subject' field is restricted to specifying the 206 value of the common name. By RFC 7925 an IoT subject is 207 identified by either an EUI-64 for clients, or by a FQDN for 208 servers. An EUI-64 mapped from a 48-bit MAC address is encoded as 209 a CBOR byte string of length 6. Other EUI-64 is encoded as a CBOR 210 byte string of length 8. A FQDN is encoded as a CBOR text string. 212 o subjectPublicKeyInfo. If the 'algorithm' field is the default 213 (id-ecPublicKey and prime256v1), it is omitted in the CBOR 214 encoding, otherwise it is included in the 215 subjectPublicKeyInfo_algorithm field encoded as an int, (see 216 Section 8). The 'subjectPublicKey' is encoded as a CBOR byte 217 string. Public keys of type id-ecPublicKey are point compressed 218 as defined in Section 2.3.3 of [SECG]. 220 o extensions. The 'extensions' field is encoded as a CBOR array 221 where each extension is represented with an int. This is the most 222 compact representation of the allowed extensions. The extensions 223 mandated to be supported by RFC 7925 is encodeded as specified 224 below, where critical extensions are encoded with a negative sign. 225 TODO: need to make things mod 3 instead. 227 I.e. non-critical keyUsage keyAgreement is encoded as 5, critical 228 basicConstraints cA is encodes as -3, and non-criticical 229 extKeyUsage id-kp-codeSigning + id-kp-OCSPSigning is encoded as 230 22. 232 If subjectAltName is present, the value is placed at the end of 233 the array encoded as a byte or text string following the encoding 234 rules for the subject field. If the array contains a single int, 235 extensions is encoded as the int instead of an array. 237 subjectAltName = 1 239 basicConstraints = 2 + cA 240 keyUsage = 3 + digitalSignature 241 + 2 * keyAgreement + 4 * keyCertSign 243 extKeyUsage = 10 + id-kp-serverAuth + 2 * id-kp-clientAuth 244 + 4 * id-kp-codeSigning + 8 * id-kp-OCSPSigning 246 o signatureAlgorithm. If the 'signatureAlgorithm' field is the 247 default (ecdsa-with-SHA256) it is omitted in the CBOR encoding, 248 otherwise it is included in the signatureAlgorithm field encoded 249 as an CBOR int (see Section 8). 251 o signatureValue. Since the signature algorithm and resulting 252 signature length are known, padding and extra length fields which 253 are present in the ASN.1 encoding are omitted and the 254 'signatureValue' field is encoded as a CBOR byte string. For 255 native CBOR certificates the signatureValue is calculated over the 256 certificate CBOR sequence excluding the signatureValue. 258 In addition to the above fields present in X.509, the CBOR ecoding 259 introduces an additional field 261 o type. A CBOR int used to indicate the type of CBOR certificate. 262 Currently type can be a native CBOR certificate (type = 0) or a 263 CBOR compressed X.509 certificates (type = 1), see Section 8. 265 The following Concise Data Definition Language (CDDL) defines a 266 group, the elements of which are to be used in an unadorned CBOR 267 Sequence [RFC8742]. The member names therefore only have documentary 268 value. 270 certificate = ( 271 type : int, 272 serialNumber : bytes, 273 issuer : { + int => bytes } / text, 274 validity_notBefore: uint, 275 validity_notAfter: uint, 276 subject : text / bytes 277 subjectPublicKey : bytes 278 extensions : [ *4 int, ? text / bytes ] / int, 279 signatureValue : bytes, 280 ? ( signatureAlgorithm : int, 281 subjectPublicKeyInfo_algorithm : int ) 282 ) 284 The signatureValue for native CBOR certificates is calculated over 285 the CBOR sequence: 287 ( 288 type : int, 289 serialNumber : bytes, 290 issuer : { + int => bytes } / text, 291 validity_notBefore: uint, 292 validity_notAfter: uint, 293 subject : text / bytes 294 subjectPublicKey : bytes 295 extensions : [ *4 int, ? text / bytes ] / int, 296 ? ( signatureAlgorithm : int, 297 subjectPublicKeyInfo_algorithm : int ) 298 ) 300 TODO - Specify exactly how issuer is encoded into a map / text and 301 back again. This is a compromise between compactness and complete 302 generality. 304 4. Deployment settings 306 CBOR certificates can be deployed with legacy X.509 certificates and 307 CA infrastructure. In order to verify the signature, the CBOR 308 certificate is used to recreate the original X.509 data structure to 309 be able to verify the signature. 311 For protocols like TLS/DTLS 1.2, where the handshake is sent 312 unencrypted, the actual encoding and compression can be done at 313 different locations depending on the deployment setting. For 314 example, the mapping between CBOR certificate and standard X.509 315 certificate can take place in a 6LoWPAN border gateway which allows 316 the server side to stay unmodified. This case gives the advantage of 317 the low overhead of a CBOR certificate over a constrained wireless 318 links. The conversion to X.509 within an IoT device will incur a 319 computational overhead, however, measured in energy this is 320 negligible compared to the reduced communication overhead. 322 For the setting with constrained server and server-only 323 authentication, the server only needs to be provisioned with the CBOR 324 certificate and does not perform the conversion to X.509. This 325 option is viable when client authentication can be asserted by other 326 means. 328 For protocols like IKEv2, TLS/DTLS 1.3, and EDHOC, where certificates 329 are encrypted, the proposed encoding needs to be done fully end-to- 330 end, through adding the encoding/decoding functionality to the 331 server. 333 5. Expected Certificate Sizes 335 The CBOR encoding of the sample certificate given in Appendix A 336 results in the numbers shown in Figure 1. After RFC 7925 profiling, 337 most duplicated information has been removed, and the remaining text 338 strings are minimal in size. Therefore the further size reduction 339 reached with general compression mechanisms will be small, mainly 340 corresponding to making the ASN.1 endcoding more compact. The zlib 341 number was calculated with zlib-flate. 343 zlib-flate -compress < cert.der > cert.compressed 345 +------------------+--------------+------------+--------------------+ 346 | | RFC 7925 | zlib | CBOR Certificate | 347 +------------------+---------------------------+--------------------+ 348 | Certificate Size | 314 | 295 | 136 | 349 +------------------+--------------+------------+--------------------+ 351 Figure 1: Comparing Sizes of Certificates (bytes) 353 6. Native CBOR Certificates 355 The difference between CBOR compressed X.509 certificate and native 356 CBOR certificate is that the signature is calculated over the CBOR 357 encoding rather than the DER encoded ASN.1 data. This removes 358 entirely the need for ASN.1 DER and base64 encoding which reduces the 359 processing in the authenticating devices, and avoids known 360 complexities with these encodings. 362 Native CBOR certificates can be applied in devices that are only 363 required to authenticate to native CBOR certificate compatible 364 servers. This is not a major restriction for many IoT deployments, 365 where the parties issuing and verifying certificates can be a 366 restricted ecosystem which not necessarily involves public CAs. 368 CBOR compressed X.509 certificates provides an intermediate step 369 between RFC 7925 profiled X.509 certificates and native CBOR 370 certificates: An implementation of CBOR compressed X.509 certificates 371 contains both the CBOR encoding of the X.509 certificate and the 372 signature operations sufficient for native CBOR certificates. 374 7. Security Considerations 376 The CBOR profiling of X.509 certificates does not change the security 377 assumptions needed when deploying standard X.509 certificates but 378 decreases the number of fields transmitted, which reduces the risk 379 for implementation errors. 381 Conversion between the certificate formats can be made in constant 382 time to reduce risk of information leakage through side channels. 384 The mechanism in this draft does not reveal any additional 385 information compared to X.509. Because of difference in size, it 386 will be possible to detect that this profile is used. The gateway 387 solution described in Section 4 requires unencrypted certificates and 388 is not recommended. 390 8. IANA Considerations 392 For all items, the 'Reference' field points to this document. 394 8.1. CBOR Certificate Types Registry 396 IANA has created a new registry titled "CBOR Certificate Types" under 397 the new heading "CBOR Certificate". The registration procedure is 398 "Expert Review". The columns of the registry are Value, Description, 399 and Reference, where Value is an integer and the other columns are 400 text strings. The initial contents of the registry are: 402 +-------+---------------------------------------+ 403 | Value | Description | 404 +=======+=======================================+ 405 | 0 | Native CBOR Certificate. | 406 | 1 | CBOR Compressed X.509 Certificate | 407 +-------+---------------------------------------+ 409 Figure 2: CBOR Certificate Types 411 8.2. CBOR Certificate Signature Algorithms Registry 413 IANA has created a new registry titled "CBOR Certificate Signature 414 Algorithms" under the new heading "CBOR Certificate". The 415 registration procedure is "Expert Review". The columns of the 416 registry are Value, X.509 Algorithm, and Reference, where Value is an 417 integer and the other columns are text strings. The initial contents 418 of the registry are: 420 +-------+---------------------------------------+ 421 | Value | X.509 Signature Algorithm | 422 +=======+=======================================+ 423 | 0 | ecdsa-with-SHA384 | 424 | 1 | ecdsa-with-SHA512 | 425 | 2 | id-ecdsa-with-shake128 | 426 | 3 | id-ecdsa-with-shake256 | 427 | 4 | id-Ed25519 | 428 | 5 | id-Ed448 | 429 +-------+---------------------------------------+ 431 Figure 3: CBOR Certificate Signature Algorithms 433 8.3. CBOR Certificate Public Key Algorithms Registry 435 IANA has created a new registry titled "CBOR Certificate Public Key 436 Algorithms" under the new heading "CBOR Certificate". The 437 registration procedure is "Expert Review". The columns of the 438 registry are Value, X.509 Algorithm, and Reference, where Value is an 439 integer and the other columns are text strings. The initial contents 440 of the registry are: 442 +-------+---------------------------------------+ 443 | Value | X.509 Public Key Algorithm | 444 +=======+=======================================+ 445 | 0 | id-ecPublicKey + prime384v1 | 446 | 1 | id-ecPublicKey + prime512v1 | 447 | 2 | id-X25519 | 448 | 3 | id-X448 | 449 | 4 | id-Ed25519 | 450 | 5 | id-Ed448 | 451 +-------+---------------------------------------+ 453 Figure 4: CBOR Certificate Public Key Algorithms 455 8.4. COSE Header Parameters Registry 457 This document registers the following entries in the "COSE Header 458 Parameters" registry under the "CBOR Object Signing and Encryption 459 (COSE)" heading. The formatting and processing are the same as the 460 corresponding x5chain and x5u defined in [I-D.ietf-cose-x509] except 461 that the certificates are CBOR encoded instead of DER encoded. 463 +-----------+-------+----------------+---------------------+ 464 | Name | Label | Value Type | Description | 465 +===========+=======+================+=====================+ 466 | CBORchain | TBD1 | COSE_CBOR_Cert | An ordered chain of | 467 | | | | CBOR certificates | 468 +-----------+-------+----------------+---------------------+ 469 | CBORu | TBD2 | uri | URI pointing to a | 470 | | | | CBOR certificate | 471 +-----------+-------+----------------+---------------------+ 473 8.5. TLS Certificate Compression Algorithm IDs Registry 475 This document registers the following entry in the "Certificate 476 Compression Algorithm IDs" registry under the "Transport Layer 477 Security (TLS) Extensions" heading. 479 +------------------+------------------------------+ 480 | Algorithm Number | Description | 481 +==================+==============================+ 482 | TBD3 | CBOR Certificate | 483 +------------------+------------------------------+ 485 9. References 487 9.1. Normative References 489 [I-D.ietf-tls-certificate-compression] 490 Ghedini, A. and V. Vasiliev, "TLS Certificate 491 Compression", draft-ietf-tls-certificate-compression-10 492 (work in progress), January 2020. 494 [I-D.ietf-tls-dtls13] 495 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 496 Datagram Transport Layer Security (DTLS) Protocol Version 497 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 498 2020. 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, 502 DOI 10.17487/RFC2119, March 1997, 503 . 505 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 506 Housley, R., and W. Polk, "Internet X.509 Public Key 507 Infrastructure Certificate and Certificate Revocation List 508 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 509 . 511 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 512 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 513 October 2013, . 515 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 516 Security (TLS) / Datagram Transport Layer Security (DTLS) 517 Profiles for the Internet of Things", RFC 7925, 518 DOI 10.17487/RFC7925, July 2016, 519 . 521 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 522 RFC 8152, DOI 10.17487/RFC8152, July 2017, 523 . 525 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 526 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 527 May 2017, . 529 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 530 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 531 . 533 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 534 Definition Language (CDDL): A Notational Convention to 535 Express Concise Binary Object Representation (CBOR) and 536 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 537 June 2019, . 539 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 540 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 541 . 543 9.2. Informative References 545 [I-D.ietf-cose-x509] 546 Schaad, J., "CBOR Object Signing and Encryption (COSE): 547 Header parameters for carrying and referencing X.509 548 certificates", draft-ietf-cose-x509-06 (work in progress), 549 March 2020. 551 [I-D.ietf-lake-edhoc] 552 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 553 Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- 554 edhoc-00 (work in progress), July 2020. 556 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 557 Constrained-Node Networks", RFC 7228, 558 DOI 10.17487/RFC7228, May 2014, 559 . 561 [SECG] "Elliptic Curve Cryptography, Standards for Efficient 562 Cryptography Group, ver. 2", 2009, 563 . 565 [X.509-IoT] 566 Forsby, F., Furuhed, M., Papadimitratos, P., and S. Raza, 567 "Lightweight X.509 Digital Certificates for the Internet 568 of Things.", Springer, Cham. Lecture Notes of the 569 Institute for Computer Sciences, Social Informatics and 570 Telecommunications Engineering, vol 242., July 2018, 571 . 573 Appendix A. Example CBOR Certificates 575 A.1. Example X.509 Certificate 577 Example of RFC 7925 profiled X.509 certificate parsed with OpenSSL. 579 Certificate: 580 Data: 581 Version: 3 (0x2) 582 Serial Number: 128269 (0x1f50d) 583 Signature Algorithm: ecdsa-with-SHA256 584 Issuer: CN=RFC test CA 585 Validity 586 Not Before: Jan 1 00:00:00 2020 GMT 587 Not After : Feb 2 00:00:00 2021 GMT 588 Subject: CN=01-23-45-FF-FE-67-89-AB 589 Subject Public Key Info: 590 Public Key Algorithm: id-ecPublicKey 591 Public-Key: (256 bit) 592 pub: 593 04:ae:4c:db:01:f6:14:de:fc:71:21:28:5f:dc:7f: 594 5c:6d:1d:42:c9:56:47:f0:61:ba:00:80:df:67:88: 595 67:84:5e:e9:a6:9f:d4:89:31:49:da:e3:d3:b1:54: 596 16:d7:53:2c:38:71:52:b8:0b:0d:f3:e1:af:40:8a: 597 95:d3:07:1e:58 598 ASN1 OID: prime256v1 599 NIST CURVE: P-256 600 X509v3 extensions: 601 X509v3 Key Usage: 602 Digital Signature 603 Signature Algorithm: ecdsa-with-SHA256 604 30:44:02:20:37:38:73:ef:87:81:b8:82:97:ef:23:5c:1f:ac: 605 cf:62:da:4e:44:74:0d:c2:a2:e6:a3:c6:c8:82:a3:23:8d:9c: 606 02:20:3a:d9:35:3b:a7:88:68:3b:06:bb:48:fe:ca:16:ea:71: 607 17:17:34:c6:75:c5:33:2b:2a:f1:cb:73:38:10:a1:fc 609 The DER encoding of the above certificate is 314 bytes. 611 308201363081DEA003020102020301F50D300A06082A8648CE3D040302301631 612 14301206035504030C0B5246432074657374204341301E170D32303031303130 613 30303030305A170D3231303230323030303030305A30223120301E0603550403 614 0C1730312D32332D34352D46462D46452D36372D38392D41423059301306072A 615 8648CE3D020106082A8648CE3D03010703420004AE4CDB01F614DEFC7121285F 616 DC7F5C6D1D42C95647F061BA0080DF678867845EE9A69FD4893149DAE3D3B154 617 16D7532C387152B80B0DF3E1AF408A95D3071E58A30F300D300B0603551D0F04 618 0403020780300A06082A8648CE3D04030203470030440220373873EF8781B882 619 97EF235C1FACCF62DA4E44740DC2A2E6A3C6C882A3238D9C02203AD9353BA788 620 683B06BB48FECA16EA71171734C675C5332B2AF1CB733810A1FC 622 A.2. Example CBOR Certificate Compression 624 The CBOR certificate compression of the X.509 in CBOR diagnostic 625 format is: 627 ( 628 1, 629 h'01f50d', 630 "RFC test CA", 631 721699200, 632 760492800, 633 h'0123456789AB', 634 h'02ae4cdb01f614defc7121285fdc7f5c6d1d42c95647f061ba 635 0080df678867845e', 636 5, 637 h'373873EF8781B88297EF235C1FACCF62DA4E44740DC2A2E6A3 638 C6C882A3238D9C3AD9353BA788683B06BB48FECA16EA711717 639 34C675C5332B2AF1CB733810A1FC' 640 ) 642 The CBOR encoding (CBOR sequence) of the CBOR certificate is 136 643 bytes. 645 014301F50D6B52464320746573742043411A2B0441801A2D5433004601234567 646 89AB582102AE4CDB01F614DEFC7121285FDC7F5C6D1D42C95647F061BA0080DF 647 678867845E055840373873EF8781B88297EF235C1FACCF62DA4E44740DC2A2E6 648 A3C6C882A3238D9C3AD9353BA788683B06BB48FECA16EA71171734C675C5332B 649 2AF1CB733810A1FC 651 A.3. Example Native CBOR Certificate 653 The corresponding native CBOR certificate in CBOR diagnostic format 654 is identical except for type and signatureValue. 656 ( 657 0, 658 h'01f50d', 659 "RFC test CA", 660 721699200, 661 760492800, 662 h'0123456789AB', 663 h'02ae4cdb01f614defc7121285fdc7f5c6d1d42c95647f061 664 ba0080df678867845e', 665 5, 666 h'7F10A063DA8DB2FD49414440CDF85070AC22A266C7F1DFB1 667 577D9A35A295A8742E794258B76968C097F85542322A0796 668 0199C13CC0220A9BC729EF2ECA638CFE' 669 ) 670 The CBOR encoding (CBOR sequence) of the CBOR certificate is 136 671 bytes. 673 004301F50D6B52464320746573742043411A2B0441801A2D5433004601234567 674 89AB582102AE4CDB01F614DEFC7121285FDC7F5C6D1D42C95647F061BA0080DF 675 678867845E0558407F10A063DA8DB2FD49414440CDF85070AC22A266C7F1DFB1 676 577D9A35A295A8742E794258B76968C097F85542322A07960199C13CC0220A9B 677 C729EF2ECA638CFE 679 Appendix B. X.509 Certificate Profile, ASN.1 681 TODO - This ASN.1 profile should probably be in a document that 682 updates RFC 7925. 684 IOTCertificate DEFINITIONS EXPLICIT TAGS ::= BEGIN 686 Certificate ::= SEQUENCE { 687 tbsCertificate TBSCertificate, 688 signatureAlgorithm AlgorithmIdentifier, 689 signatureValue BIT STRING 690 } 692 TBSCertificate ::= SEQUENCE { 693 version [0] INTEGER {v3(2)}, 694 serialNumber INTEGER (1..MAX), 695 signature AlgorithmIdentifier, 696 issuer Name, 697 validity Validity, 698 subject Name, 699 subjectPublicKeyInfo SubjectPublicKeyInfo, 700 extensions [3] Extensions OPTIONAL 701 } 703 Name ::= SEQUENCE SIZE (1) OF DistinguishedName 705 DistinguishedName ::= SET SIZE (1) OF CommonName 707 CommonName ::= SEQUENCE { 708 type OBJECT IDENTIFIER (id-at-commonName), 709 value UTF8String 710 } 712 Validity ::= SEQUENCE { 713 notBefore UTCTime, 714 notAfter UTCTime 715 } 717 SubjectPublicKeyInfo ::= SEQUENCE { 718 algorithm AlgorithmIdentifier, 719 subjectPublicKey BIT STRING 720 } 722 AlgorithmIdentifier ::= SEQUENCE { 723 algorithm OBJECT IDENTIFIER, 724 parameters ANY DEFINED BY algorithm OPTIONAL } 725 } 727 Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension 729 Extension ::= SEQUENCE { 730 extnId OBJECT IDENTIFIER, 731 critical BOOLEAN DEFAULT FALSE, 732 extnValue OCTET STRING 733 } 735 id-at-commonName OBJECT IDENTIFIER ::= 736 {joint-iso-itu-t(2) ds(5) attributeType(4) 3} 738 END 740 Authors' Addresses 742 Shahid Raza 743 RISE AB 745 Email: shahid.raza@ri.se 747 Joel Hoeglund 748 RISE AB 750 Email: joel.hoglund@ri.se 752 Goeran Selander 753 Ericsson AB 755 Email: goran.selander@ericsson.com 757 John Preuss Mattsson 758 Ericsson AB 760 Email: john.mattsson@ericsson.com 761 Martin Furuhed 762 Nexus Group 764 Email: martin.furuhed@nexusgroup.com