idnits 2.17.1 draft-ietf-cose-x509-08.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 (13 December 2020) is 1229 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) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-39 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: Standards Track 13 December 2020 5 Expires: 16 June 2021 7 CBOR Object Signing and Encryption (COSE): Header parameters for 8 carrying and referencing X.509 certificates 9 draft-ietf-cose-x509-08 11 Abstract 13 The CBOR Signing And Encrypted Message (COSE) structure uses 14 references to keys in general. For some algorithms, additional 15 properties are defined which carry parameters relating to keys as 16 needed. The COSE Key structure is used for transporting keys outside 17 of COSE messages. This document extends the way that keys can be 18 identified and transported by providing attributes that refer to or 19 contain X.509 certificates. 21 Contributing to this document 23 This note is to be removed before publishing as an RFC. 25 The source for this draft is being maintained in GitHub. Suggested 26 changes should be submitted as pull requests at https://github.com/ 27 cose-wg/X509. 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 16 June 2021. 48 Copyright Notice 50 Copyright (c) 2020 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 (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 66 2. X.509 COSE Header Parameters . . . . . . . . . . . . . . . . 3 67 3. X.509 certificates and static-static ECDH . . . . . . . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. COSE Header Parameter Registry . . . . . . . . . . . . . 8 70 4.2. COSE Header Algorithm Parameter Registry . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 6.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 In the process of writing [RFC8152], the working group discussed 80 X.509 certificates [RFC5280] and decided that no use cases were 81 presented that showed a need to support certificates. Since that 82 time, a number of cases have been defined in which X.509 certificate 83 support is necessary, and by implication, applications will need a 84 documented and consistent way to handle such certificates. This 85 document defines a set of attributes that will allow applications to 86 transport and refer to X.509 certificates in a consistent manner. 88 In some of these cases, a constrained device is being deployed in the 89 context of an existing X.509 PKI: for example, in the 6TiSCH 90 environment, [I-D.richardson-enrollment-roadmap] describes a device 91 enrollment solution that relies on the presence of a factory- 92 installed certificate on the device. The [I-D.ietf-lake-edhoc] draft 93 was also written with the idea that long term certificates could be 94 used to provide for authentication of devices, and uses them to 95 establish session keys. Another possible scenario is the use of COSE 96 as the basis for a secure messaging application. This scenario 97 assumes the presence of long term keys and a central authentication 98 authority. Basing such an application on public key certificates 99 allows it to make use of well established key management disciplines. 101 1.1. Requirements Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. X.509 COSE Header Parameters 111 The use of X.509 certificates allows for an existing trust 112 infrastructure to be used with COSE. This includes the full suite of 113 enrollment protocols, trust anchors, trust chaining and revocation 114 checking that have been defined over time by the IETF and other 115 organizations. The key structures that have been defined in COSE 116 currently do not support all of these properties although some may be 117 found in COSE Web Tokens (CWT) [RFC8392]. 119 It is not necessarily expected that constrained devices themselves 120 will evaluate and process X.509 certificates: it is perfectly 121 reasonable for a constrained device to be provisioned with a 122 certificate that it subsequently provides to a relying party - along 123 with a signature or encrypted message - on the assumption that the 124 relying party is not a constrained device, and is capable of 125 performing the required certificate evaluation and processing. It is 126 also reasonable that a constrained device would have the hash of a 127 certificate associated with a public key and be configured to use a 128 public key for that thumbprint, but without performing the 129 certificate evaluation or even having the entire certificate. In any 130 case, there still needs to be an entity that is responsible for 131 handling the possible certificate revocation. 133 Parties that intend to rely on the assertions made by a certificate 134 obtained from any of these methods still need to validate it. This 135 validation can be done according to the PKIX rules in [RFC5280] or by 136 using a different trust structure, such as a trusted certificate 137 distributor for self-signed certificates. The PKIX validation 138 includes matching against the trust anchors configured for the 139 application. These rules apply when the validation succeeds in a 140 single step as well as when certificate chains need to be built. If 141 the application cannot establish trust in the certificate, the public 142 key contained in the certificate cannot be used for cryptographic 143 operations. 145 The header parameters defined in this document are: 147 x5bag: This header parameter contains a bag of X.509 certificates. 148 The set of certificates in this header parameter is unordered and 149 may contain self-signed certificates. Note that there could be 150 duplicating certificates. The certificate bag can contain 151 certificates which are completely extraneous to the message. (An 152 example of this would be where a signed message is being used to 153 transport a certificate containing a key agreement key.) As the 154 certificates are unordered, the party evaluating the signature 155 will need to be capable of building the certificate path as 156 necessary. That party will also have to take into account that 157 the bag may not contain the full set of certificates needed to 158 build any particular chain. 160 The trust mechanism MUST process any certificates in this 161 parameter as untrusted input. The presence of a self-signed 162 certificate in the parameter MUST NOT cause the update of the set 163 of trust anchors without some out-of-band confirmation. As the 164 contents of this header parameter are untrusted input, the header 165 parameter can be in either the protected or unprotected header 166 bucket. 168 This header parameter allows for a single X.509 certificate or a 169 bag of X.509 certificates to be carried in the message. 171 * If a single certificate is conveyed, it is placed in a CBOR 172 byte string. 174 * If multiple certificates are conveyed, a CBOR array of byte 175 strings is used, with each certificate being in its own byte 176 string. 178 x5chain: This header parameter contains an ordered array of X.509 179 certificates. The certificates are to be ordered starting with 180 the certificate containing the end-entity key followed by the 181 certificate which signed it and so on. There is no requirement 182 for the entire chain to be present in the element if there is 183 reason to believe that the relying party already has, or can 184 locate the missing certificates. This means that the relying 185 party is still required to do path building, but that a candidate 186 path is proposed in this header parameter. 188 The trust mechanism MUST process any certificates in this 189 parameter as untrusted input. The presence of a self-signed 190 certificate in the parameter MUST NOT cause the update of the set 191 of trust anchors without some out-of-band confirmation. As the 192 contents of this header parameter are untrusted input, the header 193 parameter can be in either the protected or unprotected header 194 bucket. 196 This header parameter allows for a single X.509 certificate or a 197 chain of X.509 certificates to be carried in the message. 199 * If a single certificate is conveyed, it is placed in a CBOR 200 byte string. 202 * If multiple certificates are conveyed, a CBOR array of byte 203 strings is used, with each certificate being in its own byte 204 string. 206 x5t: This header parameter provides the ability to identify an X.509 207 certificate by a hash value (a thumbprint). The 'x5t' header 208 parameter can be represented as an array of two elements. The 209 first element is an algorithm identifier which is an integer or a 210 string containing the hash algorithm identifier corresponding to 211 either the Value (integer) or Name (string) column of the 212 algorithm registered in the "COSE Algorithms" registry. The 213 second element is a binary string containing the hash value 214 computed over the DER encoded certificate. 216 As this header parameter does not provide any trust, the header 217 parameter can be in either a protected or unprotected header 218 bucket. 220 For interoperability, applications which use this header parameter 221 MUST support the hash algorithm 'SHA-256', but can use other hash 222 algorithms. This requirement allows for different implementations 223 to be configured to use an interoperable algorithm, but does not 224 preclude the use (by prior agreement) of other algorithms. 226 RFC Editor please remove the following two paragraphs: 228 During AD review, a question was raised about how effective the 229 previous statement is in terms of dealing with a MTI algorithm. 230 There needs to be some type of arrangement between the parties to 231 agree that a specific hash algorithm is going to be used in 232 computing the thumbprint. Making it a MUST use would make that 233 true, but it then means that agility is going to be very 234 difficult. 236 The worry is that while SHA-256 may be mandatory, if a sender 237 supports SHA-256 but only sends SHA-512 then the recipient which 238 only does SHA-256 would not be able to use the thumbprint. In 239 that case both applications would conform to the specification, 240 but still not be able to inter-operate. 242 x5u: This header parameter provides the ability to identify an X.509 243 certificate by a URI [RFC3986]. It contains a CBOR text string. 244 The referenced resource can be any of the following media types: 246 * application/pkix-cert [RFC2585] 248 * application/pkcs7-mime; smime-type="certs-only" [RFC8551] 250 As this header parameter implies a trust relationship between the 251 party generating the x5u parameter and the party hosting the 252 referred-to resource, this header parameter MUST be in the 253 protected attribute bucket. 255 The URI provided MUST provide integrity protection and server 256 authentication. For example, an HTTP or CoAP GET request to 257 retrieve a certificate MUST use TLS [RFC8446] or DTLS 258 [I-D.ietf-tls-dtls13]. If the retrieved certificate does not 259 chain to an existing trust anchor, the certificate MUST NOT be 260 trusted unless the server is configured as trusted to provide new 261 trust anchors or if an out-of-band confirmation can be received 262 for trusting the retrieved certificate. 264 The header parameters are used in the following locations: 266 * COSE_Signature and COSE_Sign1 objects: in these objects they 267 identify the certificate to be used for validating the signature. 269 * COSE_recipient objects: in this location they identify the 270 certificate for the recipient of the message. 272 The labels assigned to each header parameter can be found in the 273 following table. 275 +=========+=======+===============+=====================+ 276 | Name | Label | Value Type | Description | 277 +=========+=======+===============+=====================+ 278 | x5bag | TBD4 | COSE_X509 | An unordered bag of | 279 | | | | X.509 certificates | 280 +---------+-------+---------------+---------------------+ 281 | x5chain | TBD3 | COSE_X509 | An ordered chain of | 282 | | | | X.509 certificates | 283 +---------+-------+---------------+---------------------+ 284 | x5t | TBD1 | COSE_CertHash | Hash of an X.509 | 285 | | | | certificate | 286 +---------+-------+---------------+---------------------+ 287 | x5u | TBD2 | uri | URI pointing to an | 288 | | | | X.509 certificate | 289 +---------+-------+---------------+---------------------+ 291 Table 1: X.509 COSE Header Parameters 293 Below is an equivalent CDDL [RFC8610] description of the text above. 295 COSE_X509 = bstr / [ 2*certs: bstr ] 296 COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ] 298 The content of the bstr are the bytes of a DER encoded certificate. 300 3. X.509 certificates and static-static ECDH 302 The header parameters defined in the previous section are used to 303 identify the recipient certificates for the ECDH key agreement 304 algorithms. In this section we define the algorithm specific 305 parameters that are used for identifying or transporting the sender's 306 key for static-static key agreement algorithms. 308 These attributes are defined analogously to those in the previous 309 section. There is no definition for the certificate bag, as the same 310 attribute would be used for both the sender and recipient 311 certificates. 313 x5chain-sender: This header parameter contains the chain of 314 certificates starting with the sender's key exchange certificate. 315 The structure is the same as 'x5chain'. 317 x5t-sender: This header parameter contains the hash value for the 318 sender's key exchange certificate. The structure is the same as 319 'x5t'. 321 x5u-sender: This header parameter contains a URI for the sender's 322 key exchange certificate. The structure and processing are the 323 same as 'x5u'. 325 +===============+=====+=============+===================+===========+ 326 |Name |Label|Type | Algorithm |Description| 327 +===============+=====+=============+===================+===========+ 328 |x5t-sender |TBD |COSE_CertHash| ECDH-SS+HKDF-256, |Thumbprint | 329 | | | | ECDH-SS+HKDF-512, |for the | 330 | | | | ECDH-SS+A128KW, |senders | 331 | | | | ECDH-SS+A192KW, |X.509 | 332 | | | | ECDH-SS+A256KW |certificate| 333 +---------------+-----+-------------+-------------------+-----------+ 334 |x5u-sender |TBD |uri | ECDH-SS+HKDF-256, |URI for the| 335 | | | | ECDH-SS+HKDF-512, |senders | 336 | | | | ECDH-SS+A128KW, |X.509 | 337 | | | | ECDH-SS+A192KW, |certificate| 338 | | | | ECDH-SS+A256KW | | 339 +---------------+-----+-------------+-------------------+-----------+ 340 |x5chain-sender |TBD |COSE_X509 | ECDH-SS+HKDF-256, |static key | 341 | | | | ECDH-SS+HKDF-512, |X.509 | 342 | | | | ECDH-SS+A128KW, |certificate| 343 | | | | ECDH-SS+A192KW, |chain | 344 | | | | ECDH-SS+A256KW | | 345 +---------------+-----+-------------+-------------------+-----------+ 347 Table 2: Static ECDH Algorithm Values 349 4. IANA Considerations 351 4.1. COSE Header Parameter Registry 353 IANA is requested to register the new COSE Header parameters in 354 Table 1 in the "COSE Header Parameters" registry. The "Value 355 Registry" field is empty for all of the items. For each item, the 356 'Reference' field points to this document. 358 4.2. COSE Header Algorithm Parameter Registry 360 IANA is requested to register the new COSE Header Algorithm 361 parameters in Table 2 in the "COSE Header Algorithm Parameters" 362 registry. For each item, the 'Reference' field points to this 363 document. 365 5. Security Considerations 367 Establishing trust in a certificate is a vital part of processing. A 368 major component of establishing trust is determining what the set of 369 trust anchors are for the process. A new self-signed certificate 370 appearing on the client cannot be a trigger to modify the set of 371 trust anchors, because a well defined trust-establishment process is 372 required. One common way for a new trust anchor to be added (or 373 removed) from a device is by doing a new firmware upgrade. 375 In constrained systems, there is a trade-off between the order of 376 checking the signature and checking the certificate for validity. 377 Validating certificates can require that network resources be 378 accessed in order to get revocation information or retrieve 379 certificates during path building. The resulting network access can 380 consume power and network bandwidth. On the other hand, if the 381 certificates are validated after the signature is validated, an 382 oracle can potentially be built based on detecting the network 383 resources which is only done if the signature validation passes. In 384 any event, both the signature and certificate validation MUST be 385 completed successfully before acting on any requests. 387 Before using the key in a certificate, the key MUST be checked 388 against the algorithm to be used and any algorithm specific checks 389 need to be made. These checks can include validating that points are 390 on curves for elliptical curve algorithms, and that sizes of RSA keys 391 are of an acceptable size. The use of unvalidated keys can lead 392 either to loss of security or excessive consumption of resources (for 393 example using a 200K RSA key). 395 When processing x5u header parameter the security considerations of 396 [RFC3986] and specifically those defined in Section 7.1 also apply. 398 Regardless of the source, certification path validation is an 399 important part of establishing trust in a certificate. Section 6 of 400 [RFC5280] provides guidence for the path validation. The security 401 considerations of [RFC5280] are also important for the correct usage 402 of this document. 404 The security of the algorithm used for 'x5t' does not affect the 405 security of the system as this header parameter selects which 406 certificate that is already present on the system should be used, but 407 it does not provide any trust. 409 6. References 411 6.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 419 Housley, R., and W. Polk, "Internet X.509 Public Key 420 Infrastructure Certificate and Certificate Revocation List 421 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 422 . 424 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 425 RFC 8152, DOI 10.17487/RFC8152, July 2017, 426 . 428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 430 May 2017, . 432 6.2. Informative References 434 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 435 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 436 . 438 [I-D.ietf-tls-dtls13] 439 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 440 Datagram Transport Layer Security (DTLS) Protocol Version 441 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 442 dtls13-39, 2 November 2020, 443 . 445 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 446 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 447 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 448 April 2019, . 450 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 451 Infrastructure Operational Protocols: FTP and HTTP", 452 RFC 2585, DOI 10.17487/RFC2585, May 1999, 453 . 455 [I-D.ietf-lake-edhoc] 456 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 457 Diffie-Hellman Over COSE (EDHOC)", Work in Progress, 458 Internet-Draft, draft-ietf-lake-edhoc-02, 2 November 2020, 459 . 461 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 462 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 463 May 2018, . 465 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 466 Definition Language (CDDL): A Notational Convention to 467 Express Concise Binary Object Representation (CBOR) and 468 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 469 June 2019, . 471 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 472 Resource Identifier (URI): Generic Syntax", STD 66, 473 RFC 3986, DOI 10.17487/RFC3986, January 2005, 474 . 476 [I-D.richardson-enrollment-roadmap] 477 Richardson, M., "Device Enrollment in IETF protocols -- A 478 Roadmap", Work in Progress, Internet-Draft, draft- 479 richardson-enrollment-roadmap-03, 7 October 2020, 480 . 483 Author's Address 485 Jim Schaad 486 August Cellars 488 Email: ietf@augustcellars.com