idnits 2.17.1 draft-schaad-cose-x509-03.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 (December 26, 2018) is 1947 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.schaad-cose-rfc8152bis-struct' is defined on line 388, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-schaad-cose-rfc8152bis-struct-00 == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-06 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-10 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 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 J. Schaad 3 Internet-Draft August Cellars 4 Intended status: Informational December 26, 2018 5 Expires: June 29, 2019 7 CBOR Object Signing and Encryption (COSE): Headers for carrying and 8 referencing X.509 certificates 9 draft-schaad-cose-x509-03 11 Abstract 13 The CBOR Encoded Message (COSE) structure syntax uses the COSE Key 14 structure for placing keys in a message. This document extends the 15 way that keys can be identified and transported by providing 16 parameters that refer to or contain X.509 certificates in messages 17 and in the COSE Key structure. 19 This document defines a set of hash algorithms for COSE. These 20 algorithms are needed in order to have X.509 certificates referred to 21 by a thumbprint. 23 Contributing to this document 25 The source for this draft is being maintained in GitHub. Suggested 26 changes should be submitted as pull requests at . Instructions are on that page as well. Editorial 28 changes can be managed in GitHub, but any substantial issues need to 29 be discussed on the COSE mailing list. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 29, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 67 1.2. Open Questions . . . . . . . . . . . . . . . . . . . . . 3 68 2. X.509 COSE Headers . . . . . . . . . . . . . . . . . . . . . 3 69 3. X.509 certificates and static-static ECDH . . . . . . . . . . 6 70 4. Hash Algorithm Identifiers . . . . . . . . . . . . . . . . . 7 71 4.1. SHA-2 256-bit Hash . . . . . . . . . . . . . . . . . . . 7 72 4.2. SHA-2 256-bit Hash trucated to 64 bits . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. COSE Header Parameter Registry . . . . . . . . . . . . . 8 75 5.2. COSE Header Algorithm Parameter Registry . . . . . . . . 8 76 5.3. COSE Algorithm Registry . . . . . . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 7.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 In the process of writing [RFC8152] discussions where held on the 86 question of X.509 certificates [RFC5280] and if there was a needed to 87 provide for them. At the time there were no use cases presented that 88 appeared to have a sufficient set of support to include these 89 headers. Since that time a number of cases where X.509 certificate 90 support is necessary have been defined. This document provides a set 91 of headers that will allow applications to transport and refer to 92 X.509 certificates in a consistent manner. 94 Some of the constrained device situations are being used where an 95 X.509 PKI is already installed. One of these situations is the 6tish 96 environment for enrollment of devices where the certificates are 97 installed at the factory. The [I-D.selander-ace-cose-ecdhe] draft 98 was also written with the idea that long term certificates could be 99 used to provide for authentication of devices and uses them to 100 establish session keys. A final scenario is the use of COSE as a 101 messaging application where long term existence of keys can be used 102 along with a central authentication authority. The use of 103 certificates in this scenario allows for key management to be used 104 which is well understood. 106 When [RFC8152] was written, there were no requirements for hash 107 algorithms to be included in the algorithm registry. The use of 108 thumbprints to refer to X.509 certificates is defined in this 109 document which requires the use of hash algorithms. There have also 110 been other working groups in the IETF that have expressed a 111 requirement for hash algorithms to do have sections of content be 112 provided by reference rather than including it in the main message. 113 This document defines a set of hash algorithms for both of these 114 purposes. 116 1.1. Requirements Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 1.2. Open Questions 126 Should we define an extended key usage? 128 Are there any special certificate valiation text to be added? 130 List of other hash algorithms to be added. 132 Specific security considerations issues. 134 2. X.509 COSE Headers 136 The use of X.509 certificates allows for an existing trust 137 infrastructure to be used with COSE. This includes the full suite of 138 enrollment protocols, trust anchors, trust chaining and revocation 139 checking that have been defined over time by the IETF and other 140 organizations. The key structures that have been defined in COSE 141 currently do not support all of these properties although some may be 142 found in COSE Web Tokens (CWT) [RFC8392]. 144 It is not necessarily expected that constrained devices will fully 145 support the evaluation and processing of X.509 certificates, it is 146 perfectly reasonable for a certificate to be assigned to a device 147 which it can then provide to a relying party along with a signature 148 or encrypted message, the relying party not being a constrained 149 device. 151 Certificates obtained from any of these methods MUST still be 152 validated. This validation can be done via the PKIX rules in 153 [RFC5280] or by using a different trust structure, such as a trusted 154 certificate distributer for self-signed certificates. The PKIX 155 validation includes matching against the trust anchors configured for 156 the application. These rules apply to certificates of a chain length 157 of one as well as longer chains. If the application cannot establish 158 a trust in the certificate, then it cannot be used. 160 The header parameters defined in this document are: 162 x5bag: This header parameters contains a bag of X.509 certificates. 163 The set of certificates in this header are unordered and may 164 contain self-signed certificates. The certificate bag can contain 165 certificates which are completely extraneous to the message. (An 166 example of this would be to carry a certificate with a key 167 agreement key usage in a signed message.) As the certificates are 168 unordered, the party evaluating the signature will need to do the 169 necessary path building. Certificates needed for any particular 170 chain to be built may be absent from the bag. 172 As this header element does not provide any trust, the header 173 parameter can be in either a protected or unprotected header bag. 175 This header parameter allows for a single or a bag of X.509 176 certificates to be carried in the message. 178 * If a single certificate is conveyed, it is placed in a CBOR 179 bstr. 181 * If multiple certificates are conveyed, a CBOR array of bstrs is 182 used. Each certificate being in it's own slot. 184 x5chain: This header parameter contains an ordered array of X.509 185 certificates. The certificates are to be ordered starting with 186 the certificate containing the end-entity key followed by the 187 certificate which signed it and so on. There is no requirement 188 for the entire chain to be present in the element if there is 189 reason to believe that the relying party will already have it. 191 As this header element does not provide any trust, the header 192 parameter can be in either a protected or unprotected header bag. 194 This header parameter allows for a single or a bag of X.509 195 certificates to be carried in the message. 197 * If a single certificate is conveyed, it is placed in a CBOR 198 bstr. 200 * If multiple certificates are conveyed, a CBOR array of bstrs is 201 used. Each certificate being in it's own slot. 203 x5t: This header parameter provides the ability to identify an X.509 204 certificate by a hash value. The parameter is an array of two 205 elements. The first element is an algorithm identifier which is a 206 signed integer or a string containing the hash algorithm 207 identifier. The second element is a binary string containing the 208 hash value. 210 As this header element does not provide any trust, the header 211 parameter can be in either a protected or unprotected header bag. 212 For interoperability, applications which use this header parameter 213 MUST support the hash algorithm 'sha256', but can use other hash 214 algorithms. 216 x5u: This header parameter provides the ability to identify an X.509 217 certificate by a URL. The referenced resource can be any of the 218 following media types: 220 * application/pkix-cert [RFC2585] 222 * application/pkcs7-mime; smime-type="certs-only" 223 [I-D.ietf-lamps-rfc5751-bis] 225 * application/x-pem-file [RFC7468] Should we support a PEM type? 226 I cannot find a registered media type for one 228 As this header element implies a trust relationship, the header 229 parameter MUST be in the protected header bag. 230 The URL provided MUST provide integrity protection and server 231 authentication. For example, an HTTP or CoAP GET request to 232 retrieve a certificate MUST use TLS [RFC5246] or DTLS. If the 233 certificate does not chain to an existing trust anchor, the 234 certificate MUST NOT be trusted unless the server is configured as 235 trusted to provide new trust anchors. This will normally be the 236 situation when self-signed certificates are used. 238 The header parameters used in the following locations: 240 o COSE_Signature and COSE_Sign0 objects, in these objects they 241 identify the key that was used for generating signature. 243 o COSE_recipient objects, in this location they may be used to 244 identify the certificate for the recipient of the message. 246 +---------+-------+---------------+---------------------------------+ 247 | Name | Value | value type | description | 248 +---------+-------+---------------+---------------------------------+ 249 | x5bag | TBD4 | COSE_X509 | An unordered bag of X.509 | 250 | | | | certificates | 251 | | | | | 252 | x5chain | TBD3 | COSE_X509 | An ordered chain of X.509 | 253 | | | | certificates | 254 | | | | | 255 | x5t | TBD1 | COSE_CertHash | Hash of an X.509 certificate | 256 | | | | | 257 | x5u | TBD2 | uri | URL pointing to an X.509 | 258 | | | | certificate | 259 +---------+-------+---------------+---------------------------------+ 261 Table 1: X.509 COSE Headers 263 Below is an equivalent CDDL [I-D.ietf-cbor-cddl] description of the 264 text above. 266 COSE_X509 = bstr / [ 2*certs: bstr ] 267 COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] 269 3. X.509 certificates and static-static ECDH 271 The header parameters defined in the previous section are used to 272 identify the recipient certificates for the ECDH key agreement 273 algorithms. In this section we define the algorithm specific 274 parameters that are used for identifying or transporting the senders 275 key for static-static key agreement algorithms. 277 +-----------+------+--------------+------------------+--------------+ 278 | Name | Valu | Type | Algorithm | Description> | 279 | | e | | | | 280 +-----------+------+--------------+------------------+--------------+ 281 | static | TBD | COSE_CertHas | ECDH- | Thumbprint | 282 | key X.509 | | h | SS+HKDF-256, | for the | 283 | thumbprin | | | ECDH- | senders | 284 | t | | | SS+HKDF-512, | X.509 | 285 | | | | ECDH-SS+A128KW, | certificate | 286 | | | | ECDH- | | 287 | | | | SS+AES192KW, | | 288 | | | | ECDH-SS+AES256KW | | 289 | | | | | | 290 | static | TBD | uri | ECDH- | URL for the | 291 | key X.509 | | | SS+HKDF-256, | senders | 292 | URL | | | ECDH- | X.509 | 293 | | | | SS+HKDF-512, | certificate | 294 | | | | ECDH-SS+A128KW, | | 295 | | | | ECDH- | | 296 | | | | SS+AES192KW, | | 297 | | | | ECDH-SS+AES256KW | | 298 | | | | | | 299 | static | TBD | COSE_X509 | ECDH- | static key | 300 | key X.509 | | | SS+HKDF-256, | X.509 | 301 | cert | | | ECDH- | certificate | 302 | chain | | | SS+HKDF-512, | chain | 303 | | | | ECDH-SS+A128KW, | | 304 | | | | ECDH- | | 305 | | | | SS+AES192KW, | | 306 | | | | ECDH-SS+AES256KW | | 307 +-----------+------+--------------+------------------+--------------+ 309 Table 2: Static ECDH Algorithm Values 311 4. Hash Algorithm Identifiers 313 The core COSE document did have a need for a standalone hash 314 algorithm, and thus did not define any. In this document, two hash 315 algorithms are defined for use with the 'x5t' header parameter. 317 4.1. SHA-2 256-bit Hash 319 Define an algorithm identifier for SHA-256. 321 4.2. SHA-2 256-bit Hash trucated to 64 bits 323 This hash function uses the SHA-2 256-bit hash function as in the 324 previous section, however it truncates the result to 64-bits for 325 transmission. The fact that it is a truncated hash means that there 326 is now a high likelihood that collisions will occur, thus this hash 327 function cannot be used in situations where a unique items is 328 required to be identified. Luckily for the case of identifying a 329 certificate that is not a requirement, the only requirement is that 330 the number of potential certificates (and thus keys) to be tried is 331 reduced to a small number. (Hopefully that number is one, but it can 332 not be assumed to be.) After the set of certificates has been 333 filtered down, the public key in each certificate will need to be 334 tried for the operation in question. The certificate can be 335 validated either before or after it has been checked as working. The 336 trade-offs involved are: 338 o Certificate validation before using the key will imply that more 339 network traffic may be required in order to fetch certificates and 340 do revocation checking. 342 o Certificate validation after using the key means that bad keys can 343 be used and, if not carefully checked, the result may be used 344 prior to completing the certificate validation. Using unvalidated 345 keys can expose the device to more timing and oracle attacks as 346 the attacker would be able to see if the key operation succeeded 347 or failed as no network traffic to validate the certificate would 348 ensue. 350 5. IANA Considerations 352 5.1. COSE Header Parameter Registry 354 IANA is requested to register the new COSE Header items in Table 1 in 355 the "COSE Header Parameters" registry. 357 5.2. COSE Header Algorithm Parameter Registry 359 IANA is requested to register the new COSE Header items in Table 2 in 360 the "COSE Header Algorithm Parameters" registry. 362 5.3. COSE Algorithm Registry 364 IANA is requested to register the following algorithms in the "COSE 365 Algorithms" registry. 367 +------------+-------+--------------------+-----------+-------------+ 368 | Name | Value | Description | Reference | Recommended | 369 +------------+-------+--------------------+-----------+-------------+ 370 | SHA-256 | TBD | SHA-2 256-bit Hash | [This | Yes | 371 | | | | Document] | | 372 | | | | | | 373 | SHA-256/64 | TBD | SHA-2 256-bit Hash | [This | No | 374 | | | trucated to | Document] | | 375 | | | 64-bits | | | 376 +------------+-------+--------------------+-----------+-------------+ 378 6. Security Considerations 380 There are security considerations: 382 Self-signed certificates and Trust Anchors 384 7. References 386 7.1. Normative References 388 [I-D.schaad-cose-rfc8152bis-struct] 389 Schaad, J., "CBOR Object Signing and Encryption (COSE) - 390 Structures and Process", draft-schaad-cose-rfc8152bis- 391 struct-00 (work in progress), August 2018. 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, 395 DOI 10.17487/RFC2119, March 1997, 396 . 398 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 399 Housley, R., and W. Polk, "Internet X.509 Public Key 400 Infrastructure Certificate and Certificate Revocation List 401 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 402 . 404 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 405 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 406 May 2017, . 408 7.2. Informative References 410 [I-D.ietf-cbor-cddl] 411 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 412 definition language (CDDL): a notational convention to 413 express CBOR and JSON data structures", draft-ietf-cbor- 414 cddl-06 (work in progress), November 2018. 416 [I-D.ietf-lamps-rfc5751-bis] 417 Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 418 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 419 Message Specification", draft-ietf-lamps-rfc5751-bis-12 420 (work in progress), September 2018. 422 [I-D.selander-ace-cose-ecdhe] 423 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 424 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 425 cose-ecdhe-10 (work in progress), September 2018. 427 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 428 Infrastructure Operational Protocols: FTP and HTTP", 429 RFC 2585, DOI 10.17487/RFC2585, May 1999, 430 . 432 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 433 (TLS) Protocol Version 1.2", RFC 5246, 434 DOI 10.17487/RFC5246, August 2008, 435 . 437 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 438 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 439 April 2015, . 441 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 442 RFC 8152, DOI 10.17487/RFC8152, July 2017, 443 . 445 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 446 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 447 May 2018, . 449 Author's Address 451 Jim Schaad 452 August Cellars 454 Email: ietf@augustcellars.com