idnits 2.17.00 (12 Aug 2021) /tmp/idnits64563/draft-ietf-cose-hpke-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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 March 2022) is 68 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) == Outdated reference: draft-irtf-cfrg-hpke has been published as RFC 9180 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'I-D.irtf-cfrg-hpke') -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COSE H. Tschofenig 3 Internet-Draft Arm Limited 4 Intended status: Standards Track R. Housley 5 Expires: 8 September 2022 Vigil Security 6 B. Moran 7 Arm Limited 8 7 March 2022 10 Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and 11 Encryption (COSE) 12 draft-ietf-cose-hpke-01 14 Abstract 16 This specification defines hybrid public-key encryption (HPKE) for 17 use with CBOR Object Signing and Encryption (COSE). HPKE offers a 18 variant of public-key encryption of arbitrary-sized plaintexts for a 19 recipient public key. 21 HPKE works for any combination of an asymmetric key encapsulation 22 mechanism (KEM), key derivation function (KDF), and authenticated 23 encryption with additional data (AEAD) encryption function. 24 Authentication for HPKE in COSE is provided by COSE-native security 25 mechanisms. 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 8 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 74 3. HPKE for COSE . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3.2. HPKE Encryption with SealBase . . . . . . . . . . . . . . 4 77 3.3. HPKE Decryption with OpenBase . . . . . . . . . . . . . . 5 78 3.4. Info Structure . . . . . . . . . . . . . . . . . . . . . 5 79 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 6.1. HPKE/P-256+HKDF-256 and AES-128-GCM . . . . . . . . . . . 8 83 6.2. HPKE/P-512+HKDF-512 and AES-256-GCM . . . . . . . . . . . 8 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 7.2. Informative References . . . . . . . . . . . . . . . . . 9 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 90 1. Introduction 92 Hybrid public-key encryption (HPKE) [I-D.irtf-cfrg-hpke] is a scheme 93 that provides public key encryption of arbitrary-sized plaintexts 94 given a recipient's public key. HPKE utilizes a non-interactive 95 ephemeral-static Diffie-Hellman exchange to establish a shared 96 secret. The motivation for standardizing a public key encryption 97 scheme is explained in the introduction of [I-D.irtf-cfrg-hpke]. 99 The HPKE specification defines several features for use with public 100 key encryption and a subset of those features is applied to COSE 101 [RFC8152]. Since COSE provides constructs for authentication, those 102 are not re-used from the HPKE specification. This specification uses 103 the "base" mode, as it is called in HPKE specification language. 105 2. Conventions and Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 This specification uses the following abbreviations and terms: - 114 Content-encryption key (CEK), a term defined in CMS [RFC2630]. - 115 Hybrid Public Key Encryption (HPKE) is defined in 116 [I-D.irtf-cfrg-hpke]. - pkR is the public key of the recipient, as 117 defined in [I-D.irtf-cfrg-hpke]. - skR is the private key of the 118 recipient, as defined in [I-D.irtf-cfrg-hpke]. 120 3. HPKE for COSE 122 3.1. Overview 124 The CDDL for the COSE_Encrypt structure, as used with this 125 specification, is shown in Figure 1. 127 HPKE, when used with COSE, follows a two layer structure: 129 * Layer 0 (corresponding to the COSE_Encrypt structure) contains 130 content (plaintext) encrypted with the CEK. This ciphertext may 131 be detached. If not detached, then it is included in the 132 COSE_Encrypt structure. 134 * Layer 1 (corresponding to a recipient structure) contains 135 parameters needed for HPKE to generate a shared secret used to 136 encrypt the CEK. This layer includes the encrypted CEK. 138 This two-layer structure is used to encrypt content that can also be 139 shared with multiple parties at the expense of a single additional 140 encryption operation. As stated above, the specification uses a CEK 141 to encrypt the content at layer 0. 143 For example, the content encrypted at layer 0 is a firmware image. 144 The same ciphertext firmware image is processed by all of the 145 recipients; however, each recipient uses their own private key to 146 obtain the CEK. 148 COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) 150 HPKE_Encryption_Info = COSE_Encrypt_Tagged 152 ; Layer 0 153 COSE_Encrypt = [ 154 Headers, 155 ciphertext : bstr / nil, 156 recipients : + COSE_recipient 157 ] 159 ; Layer 1 160 COSE_recipient = [ 161 protected : bstr .cbor header_map, ; must contain alg parameter 162 unprotected : header_map, ; must contain kid and ephemeral public key 163 encCEK : bstr, ; CEK encrypted with HPKE-derived shared secret 164 ] 166 header_map = { 167 Generic_Headers, 168 * label =values, 169 } 171 Figure 1: CDDL for HPKE-based COSE_Encrypt Structure 173 The COSE_recipient structure shown in Figure 1 is repeated for each 174 recipient, and it includes the encrypted CEK as well as the sender- 175 generated ephemeral public key in the unprotected header structure. 177 3.2. HPKE Encryption with SealBase 179 The SealBase(pkR, info, aad, pt) function is used to encrypt a 180 plaintext pt to a recipient's public key (pkR). 182 IMPORTANT: For use in this specification, the plaintext "pt" passed 183 into the SealBase is the CEK. The CEK is a random byte sequence of 184 length appropriate for the encryption algorithm selected in layer 0. 185 For example, AES-128-GCM requires a 16 byte key and the CEK would 186 therefore be 16 bytes long. 188 The "info" parameter can be used to influence the generation of keys 189 and the "aad" parameter provides additional authenticated data to the 190 AEAD algorithm in use. This specification does not mandate the use 191 of the info and the aad parameters. 193 If SealBase() is successful, it will output a ciphertext "ct" and an 194 encapsulated key "enc". The content of enc is the ephemeral public 195 key. 197 The content of the info parameter is based on the 'COSE_KDF_Context' 198 structure, which is detailed in Figure 2. 200 3.3. HPKE Decryption with OpenBase 202 The recipient will use the OpenBase(enc, skR, info, aad, ct) function 203 with the enc and ct parameters received from the sender. The "aad" 204 and the "info" parameters are obtained via the context of the usage. 206 The OpenBase function will, if successful, decrypt "ct". When 207 decrypted, the result will be the CEK. The CK is the symmetric key 208 used to decrypt the ciphertext in layer 0 of the COSE_Encrypt 209 structure. 211 3.4. Info Structure 213 This section provides a suggestion for constructing the info 214 structure, when used with SealBase() and OpenBase(). Note that the 215 use of the aad and the info structures for these two functions is 216 optional. Profiles of this specification may require their use and 217 may define different info structure. 219 This specification re-uses the context information structure defined 220 in [RFC8152] as a foundation for the info structure. This payload 221 becomes the content of the info parameter for the HPKE functions, 222 when utilized. For better readability of this specification the 223 COSE_KDF_Context structure is repeated in Figure 2. 225 PartyInfo = ( 226 identity : bstr / nil, 227 nonce : bstr / int / nil, 228 other : bstr / nil 229 ) 231 COSE_KDF_Context = [ 232 AlgorithmID : int / tstr, 233 PartyUInfo : [ PartyInfo ], 234 PartyVInfo : [ PartyInfo ], 235 SuppPubInfo : [ 236 keyDataLength : uint, 237 protected : empty_or_serialized_map, 238 ? other : bstr 239 ], 240 ? SuppPrivInfo : bstr 241 ] 243 Figure 2: COSE_KDF_Context Data Structure for info parameter 245 The fields in Figure 2 are populated as follows: 247 * PartyUInfo.identity corresponds to the kid found in the 248 COSE_Sign_Tagged or COSE_Sign1_Tagged structure (when a digital 249 signature is used). When utilizing a MAC, then the kid is found 250 in the COSE_Mac_Tagged or COSE_Mac0_Tagged structure. 252 * PartyVInfo.identity corresponds to the kid used for the respective 253 recipient from the inner-most recipients array. 255 * The value in the AlgorithmID field corresponds to the alg 256 parameter in the unprotected header structure of the recipient 257 structure. 259 * keyDataLength is set to the number of bits of the desired output 260 value. 262 * protected refers to the protected structure of the inner-most 263 array. 265 4. Example 267 An example of the COSE_Encrypt structure using the HPKE scheme is 268 shown in Figure 3. Line breaks and comments have been inserted for 269 better readability. It uses the following algorithm combination: 271 * AES-GCM-128 for encryption of detached ciphertext in layer 0. 273 * AES-GCM-128 for encryption of the CEK in layer 1 as well as ECDH 274 with NIST P-256 and HKDF-SHA256 as a Key Encapsulation Mechanism 275 (KEM). 277 The algorithm selection is based on the registry of the values 278 offered by the alg parameters. 280 96_0([ 281 / protected header with alg=AES-GCM-128 / 282 h'a10101', 283 / unprotected header with nonce / 284 {5: h'938b528516193cc7123ff037809f4c2a'}, 285 / detached ciphertext / 286 null, 287 / recipient structure / 288 [ 289 / protected field with alg for HPKE / 290 h'a1013863', 291 / unprotected header / 292 { 293 / ephemeral public key with x / y coodinate / 294 -1: h'a401022001215820a596f2ca8d159c04942308ca90 295 cfbfca65b108ca127df8fe191a063d00d7c5172258 296 20aef47a45d6d6c572e7bd1b9f3e69b50ad3875c68 297 f6da0caaa90c675df4162c39', 298 / kid for recipient static ECDH public key / 299 4: h'6b69642d32', 300 }, 301 / encrypted CEK / 302 h'9aba6fa44e9b2cef9d646614dcda670dbdb31a3b9d37c7a 303 65b099a8152533062', 304 ], 305 ]) 307 Figure 3: COSE_Encrypt Example for HPKE 309 Note that the COSE_Sign1 wrapper outside the COSE_Encrypt structure 310 is not shown in the example above. 312 5. Security Considerations 314 This specification is based on HPKE and the security considerations 315 of HPKE [I-D.irtf-cfrg-hpke] are therefore applicable also to this 316 specification. 318 HPKE assumes the sender is in possession of the public key of the 319 recipient and HPKE COSE makes the same assumptions. Some form of 320 public key distribution mechanism is assumed to exist. 322 Since the CEK is randomly generated it must be ensured that the 323 guidelines for random number generations are followed, see [RFC8937]. 325 The COSE_Encrypt structure must be authenticated using COSE 326 constructs like COSE_Sign, or COSE_Sign1. 328 6. IANA Considerations 330 This document requests IANA to add new values to the COSE Algorithms 331 registry defined in [RFC8152] (in the Standards Action With Expert 332 Review category): 334 6.1. HPKE/P-256+HKDF-256 and AES-128-GCM 336 * Name: HPKE_P256_HKDF256_AES128_GCM 338 * Value: TBD1 340 * Description: HPKE/P-256+HKDF-256 and AES-128-GCM 342 * Capabilities: [kty] 344 * Change Controller: IESG 346 * Reference: [[TBD: This RFC]] 348 * Recommended: Yes 350 6.2. HPKE/P-512+HKDF-512 and AES-256-GCM 352 * Name: HPKE_P521_HKDF512_AES256_GCM 354 * Value: TBD2 356 * Description: HPKE/P-512+HKDF-512 and AES-256-GCM 358 * Capabilities: [kty] 360 * Change Controller: IESG 362 * Reference: [[TBD: This RFC]] 364 * Recommended: Yes 366 TBD: More values to be added. 368 7. References 369 7.1. Normative References 371 [I-D.irtf-cfrg-hpke] 372 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 373 "Hybrid Public Key Encryption", Work in Progress, 374 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 375 . 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, 380 DOI 10.17487/RFC2119, March 1997, 381 . 383 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 384 RFC 8152, DOI 10.17487/RFC8152, July 2017, 385 . 387 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 388 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 389 May 2017, . 391 7.2. Informative References 393 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 394 DOI 10.17487/RFC2630, June 1999, 395 . 397 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 398 and C. Wood, "Randomness Improvements for Security 399 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 400 . 402 Appendix A. Acknowledgements 404 We would like to thank Goeran Selander, John Mattsson and Ilari 405 Liusvaara for their review feedback. 407 Authors' Addresses 409 Hannes Tschofenig 410 Arm Limited 411 Email: hannes.tschofenig@arm.com 413 Russ Housley 414 Vigil Security, LLC 415 Email: housley@vigilsec.com 416 Brendan Moran 417 Arm Limited 418 Email: Brendan.Moran@arm.com