idnits 2.17.1 draft-schaad-cose-x509-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TRUNCATE' is defined on line 416, but no explicit reference was found in the text ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-02 == Outdated reference: A later version (-12) exists of draft-ietf-lamps-rfc5751-bis-10 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-08 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 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 July 2, 2018 5 Expires: January 3, 2019 7 CBOR Object Signing and Encryption (COSE): Headers for carrying and 8 referencing X.509 certificates 9 draft-schaad-cose-x509-02 11 Abstract 13 This document defines a set of headers to identify and transport 14 X.509 certificates in the CBOR Encoded Message (COSE) syntax. The 15 document additionally defines a set of digest algorithms that are 16 used in identifying certificates, as well as being available for 17 other uses. 19 Contributing to this document 21 The source for this draft is being maintained in GitHub. Suggested 22 changes should be submitted as pull requests at . Instructions are on that page as well. Editorial 24 changes can be managed in GitHub, but any substantial issues need to 25 be discussed on the COSE mailing list. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 3, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 63 2. X.509 COSE Headers . . . . . . . . . . . . . . . . . . . . . 3 64 3. Hash Algorithm Identifiers . . . . . . . . . . . . . . . . . 6 65 3.1. SHA-2 256-bit Hash . . . . . . . . . . . . . . . . . . . 6 66 3.2. SHA-2 256-bit Hash trucated to 64 bits . . . . . . . . . 6 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. COSE Header Parameter Registry . . . . . . . . . . . . . 7 69 4.2. COSE Algorithm Registry . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 6.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 In the process of writing [RFC8152] discussions where held on the 79 question of X.509 certificates [RFC5280] and if there were needed. 80 At the time there were no use cases presented that appeared to have a 81 sufficient set of support to include these headers. Since that time 82 a number of cases where X.509 certificate support is necessary have 83 been defined. This document provides a set of headers that will 84 allow applications to transport and refer to X.509 certificates in a 85 consistent manner. 87 Some of the constrainted device situations are being used where an 88 X.509 PKI is already installed. One of these situations is the 6tish 89 environment for enrollment of devices where the certificates are 90 installed at the factory. The [I-D.selander-ace-cose-ecdhe] draft 91 was also written with the idea that long term certificates could be 92 used to provide for authentication of devices and uses them to 93 establish session keys. A final scenario is the use of COSE as a 94 messaging application where long term existence of keys can be used 95 along with a central authentication authority. The use of 96 certificates in this scenario allows for key managment to be used 97 which is well understood. 99 Additionally, there has been an increasing need to have a set of 100 standardized set of identifies for digest algorithms. Many cases one 101 needs to sign a manifest which contains a pointer to a data 102 structure, a digest algorithm and the digest value. This structure 103 means that one is not required to include a document in order to have 104 it correctly identified. As digest algoithms are also used in 105 identification of certificates, an initial set of digest algorithms 106 is defined in this document. 108 1.1. Requirements Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 2. X.509 COSE Headers 118 The use of X.509 certificates allows for an existing trust 119 infrastructure to be used with COSE. This includes the full suite of 120 enrollment protocols, trust anchors, trust chaining and revocation 121 checking that have been defined over time by the IETF and other 122 organizations. The key structures that have been defined in COSE 123 currently do not support all of these properties although some may be 124 found in COSE Web Tokens (CWT) [I-D.ietf-ace-cbor-web-token]. 126 It is not necessarily expected that constrainted devices will fully 127 support the evalaluation and processing of X.509 certificates, it is 128 perfectly reasonable for a certificate to be assigned to a device 129 which it can then provide to a relying party along with a signature 130 or encrypted message, the relying party not being a constrained 131 device. 133 Certificates obtained from any of these methods MUST still be 134 validated. This validation can be done via the PKIX rules in 135 [RFC5280] or by using a different trust structure, such as a trusted 136 certificate distributer for self-signed certificates. The PKIX 137 validation includes matching against the trust anchors configured for 138 the application. These rules apply to certificates of a chain length 139 of one as well as longer chains. If the application cannot establish 140 a trust in the certificate, then it cannot be used. 142 The header parameters defined in this document are: 144 x5bag: This header parameters contains a bag of X.509 certificates. 145 The set of certificates in this header are unordered and may 146 contain self-signed certificates. The certificate bag can contain 147 certificates which are completely extraneous to the message. An 148 example of this would be to carry a certificate with a key 149 agreement key usage in a signed message. As the certificates are 150 unordered, the party evaluating the signature will need to do the 151 necessary path building. Certificates needed for any particular 152 chain to be built may be absent from the bag. 154 As this header element does not provide any trust, the header 155 parameter can be in either a protected or unprotected header bag. 157 This header parameter allows for a single or a bag of X.509 158 certificates to be carried in the message. 160 * If a single certificate is conveyed, it is placed in a CBOR 161 bstr. 163 * If multiple certificates are conveyed, a CBOR array of bstrs is 164 used. Each certificate being in it's own slot. 166 x5chain: This header parameter contains an ordered array of X.509 167 certificates. The certificates are to be ordered starting with 168 the certificate containing the end-entity key followed by the 169 certificate which signed it and so on. The chain of certificates 170 can be truncated if there is reason to believe that the relying 171 party will already have it. 173 As this header element does not provide any trust, the header 174 parameter can be in either a protected or unprotected header bag. 176 This header parameter allows for a single or a bag of X.509 177 certificates to be carried in the message. 179 * If a single certificate is conveyed, it is placed in a CBOR 180 bstr. 182 * If multiple certificates are conveyed, a CBOR array of bstr is 183 used. Each certificate being in it's own slot. 185 x5t: This header parameter provides the ability to identify an X.509 186 certificate by a hash value. The parameter is an array of two 187 elements. The first element is an algorithm identifier which is a 188 signed integer or a string containing the hash algorithm 189 identifier. The second element is a binary string containing the 190 hash value. 192 As this header element does not provide any trust, the header 193 parameter can be in either a protected or unprotected header bag. 194 For interoperability, applications which use this header parameter 195 MUST support the hash algorithm 'sha256', but can use other hash 196 algorithms. 198 x5u: This header parameter provides the ability to identify an X.509 199 certificate by a URL. The referenced resource can be any of the 200 following media types: 202 * application/pkix-cert [RFC2585] 204 * application/pkcs7-mime; smime-type="certs-only" 205 [I-D.ietf-lamps-rfc5751-bis] 207 * application/x-pem-file [RFC7468] 209 As this header element implies a trust relationship, the header 210 parameter MUST be in the protected header bag. 211 The URL provided MUST provide integrity protection. For example, 212 an HTTP or CoAP GET request to retrieve a certificate MUST use TLS 213 [RFC5246] or DTLS. If the certificate does not chain to an 214 existing trust anchor, the identity of the server MUST be 215 configured as trusted to provide new trust anchors. This will 216 normally be the situation when self-signed certificates are used. 218 The header paramters used in the following locations: 220 o COSE_Signature and COSE_Sign0 objects, in these objects they 221 identify the key that was used for generating signature. 223 o COSE_recipient object, in this object they identify the key used 224 by the sender for static-static key agreement algorithms. 226 +---------+-------+---------------+---------------------------------+ 227 | name | label | value type | description | 228 +---------+-------+---------------+---------------------------------+ 229 | x5bag | TBD4 | COSE_X509 | An unordered bag of X.509 | 230 | | | | certificates | 231 | | | | | 232 | x5chain | TBD3 | COSE_X509 | An ordered chain of X.509 | 233 | | | | certificates | 234 | | | | | 235 | x5t | TBD1 | COSE_CertHash | Hash of an X.509 certificate | 236 | | | | | 237 | x5u | TBD2 | tstr | URL pointing to an X.509 | 238 | | | | certificate | 239 +---------+-------+---------------+---------------------------------+ 241 Table 1: X.509 COSE Headers 243 Below is an equivalent CDDL [I-D.ietf-cbor-cddl] description of the 244 text above 246 COSE_X509 = bstr / [ *certs: bstr ] 247 COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] 249 3. Hash Algorithm Identifiers 251 The core COSE document did have a need for a standalone hash 252 algorithm, and thus did not define any. In this document, two hash 253 algorithms are defined for use with the 'x5t' header parameter. 254 Nothing restricts their use in other contexts. 256 3.1. SHA-2 256-bit Hash 258 The SHA-2 256-bit algorithm is defined in [SHA2]. Define an 259 algorithm identifier for SHA-256. 261 3.2. SHA-2 256-bit Hash trucated to 64 bits 263 This hash function uses the SHA-2 256-bit hash function as in the 264 previous section, however it truncates the result to 64-bits for 265 transmission. The fact that it is a trucated hash means that there 266 is now a high likelyhood that colisions will occur, thus this hash 267 function cannot be used in situations where a unique items is 268 required to be identified. Luckly for the case of identifying a 269 certificate that is not a requirement, the only requirement is that 270 the number of potential certificates (and thus keys) to be tried is 271 reduced to a small number. (Hopefully that number is one, but it can 272 not be assumed to be.) After the set of certificates has been 273 filtered down, the public key in each certificate will need to be 274 tried for the operation in question. The certificate can be 275 validated either before or after it has been checked as working. The 276 trade-offs involved are: 278 o Certificate validation before using the key will imply that more 279 network traffic may be required in order to fetch certificates and 280 do revocation checking. 282 o Certificate validation after using the key means that bad keys can 283 be used and, if not carefully checked, the result may be used 284 prior to completing the certificate validation. Using unvalidated 285 keys can expose the device to more timing and oracle attacks as 286 the attacker would be able to see if the key operation succeeded 287 or failed as no network traffic to validate the certificate would 288 ensue. 290 4. IANA Considerations 292 4.1. COSE Header Parameter Registry 294 It is requested that IANA create four new entries in the "COSE Header 295 Parameters" registry. The content of these entries is: 297 Name: x5bag 298 Label: TBD4 299 Value Type: bstr | [+bstr] 300 Value Registry: N/A 301 Description: X.509 certificate bag 302 Reference: [[This Document]] 304 Name: x5chain 305 Label: TBD3 306 Value Type: bstr | [+bstr] 307 Value Registry: N/A 308 Description: X.509 certificate chain 309 Reference: [[This Document] 311 Name: x5t 312 Label: TBD1 313 Value Type: COSE_CertHash 314 Value Registry: N/A 315 Description: X.509 certificate thumbprint 316 Reference: [[This Document]] 318 Name: x5u 319 Label: TBD2 320 Value Type: tstr 321 Value Registry: N/A 322 Description: URL pointing to an X.509 certificate 323 Reference: [[This Description]] 325 4.2. COSE Algorithm Registry 327 It is requested that IANA create two new entries in the "COSE 328 Algorithms" registry. The content of these entries is: 330 Name: SHA256 331 Value: TBD5 332 Description: SHA-256 Digest 333 Reference: [[This Document]] 334 Recommended: Yes 336 Name: SHA256/64 337 Value: TBD6 338 Description: SHA-256 Digest truncated to 64-bits 339 Reference: [[This Document]] 340 Recommended: No 342 Note to designated expert: It may be reasonable to use a single byte 343 entry for the truncated algorthm, but I think it should be in the two 344 byte range. There is no reason not to place the full SHA-256 345 algorithm in the three byte range, but I expect it to be in the 2 346 byte range. 348 5. Security Considerations 350 There are security considerations: 352 6. References 354 6.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 362 Housley, R., and W. Polk, "Internet X.509 Public Key 363 Infrastructure Certificate and Certificate Revocation List 364 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 365 . 367 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 368 RFC 8152, DOI 10.17487/RFC8152, July 2017, 369 . 371 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 372 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 373 May 2017, . 375 [SHA2] National Institute of Standards and Technology (NIST), 376 "Secure Hash Standard", FIPS 180-4, August 2015. 378 6.2. Informative References 380 [I-D.ietf-ace-cbor-web-token] 381 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 382 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 383 (work in progress), March 2018. 385 [I-D.ietf-cbor-cddl] 386 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 387 definition language (CDDL): a notational convention to 388 express CBOR data structures", draft-ietf-cbor-cddl-02 389 (work in progress), February 2018. 391 [I-D.ietf-lamps-rfc5751-bis] 392 Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 393 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 394 Message Specification", draft-ietf-lamps-rfc5751-bis-10 395 (work in progress), June 2018. 397 [I-D.selander-ace-cose-ecdhe] 398 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 399 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 400 cose-ecdhe-08 (work in progress), March 2018. 402 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 403 Infrastructure Operational Protocols: FTP and HTTP", 404 RFC 2585, DOI 10.17487/RFC2585, May 1999, 405 . 407 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 408 (TLS) Protocol Version 1.2", RFC 5246, 409 DOI 10.17487/RFC5246, August 2008, 410 . 412 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 413 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 414 April 2015, . 416 [TRUNCATE] 417 National Institute of Standards and Technology (NIST), 418 "Recommendation fro Applications Using Approved Hash 419 Algorithms", FIPS 800-107, August 2012. 421 Author's Address 423 Jim Schaad 424 August Cellars 426 Email: ietf@augustcellars.com