idnits 2.17.00 (12 Aug 2021) /tmp/idnits41641/draft-ietf-cose-hpke-00.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 (10 January 2022) is 131 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: 14 July 2022 Vigil Security 6 B. Moran 7 Arm Limited 8 10 January 2022 10 Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and 11 Encryption (COSE) 12 draft-ietf-cose-hpke-00 14 Abstract 16 This specification defines hybrid public-key encryption (HPKE) for 17 use with CBOR Object Signing and Encryption (COSE). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 14 July 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 66 3. HPKE for COSE . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.2. HPKE Encryption with SealBase . . . . . . . . . . . . . . 4 69 3.3. HPKE Decryption with Open . . . . . . . . . . . . . . . . 5 70 3.4. Info Structure . . . . . . . . . . . . . . . . . . . . . 5 71 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 7.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Hybrid public-key encryption (HPKE) [I-D.irtf-cfrg-hpke] is a scheme 83 that provides public key encryption of arbitrary-sized plaintexts 84 given a recipient's public key. HPKE utilizes a non-interactive 85 ephemeral-static Diffie-Hellman exchange to establish a shared 86 secret, which is then used to encrypt plaintext. 88 The HPKE specification defines several features for use with public 89 key encryption and a subset of those features is applied to COSE 90 [RFC8152]. Since COSE provides constructs for authenticcation, those 91 are not re-used from the HPKE specification. This specification uses 92 the "base" mode (as it is called in HPKE specification language). 94 2. Conventions and Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in 99 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 This specification uses the following abbreviations and terms: - 103 Content-encryption key (CEK), a term defined in RFC 2630 [RFC2630]. - 104 Hybrid Public Key Encryption (HPKE) is defined in 105 [I-D.irtf-cfrg-hpke]. - pkR is the public key of the recipient, as 106 defined in [I-D.irtf-cfrg-hpke]. - skR is the private key of the 107 recipient, as defined in [I-D.irtf-cfrg-hpke]. 109 3. HPKE for COSE 111 3.1. Overview 113 The CDDL for the COSE_Encrypt structure, as used with this 114 specification, is shown in Figure 1. The structures referenced below 115 are found in the CDDL. 117 HPKE, when used with COSE, follows a three layer structure: 119 * Layer 0 (corresponding to the COSE_Encrypt structure) contains 120 content encrypted with the CEK. This ciphertext may be detached. 121 If not detached, then it is included in the COSE_Encrypt 122 structure. 124 * Layer 1 (see COSE_recipient_outer structure) includes the 125 encrypted CEK. 127 * Layer 2 (in the COSE_recipient_inner structure) contains 128 parameters needed for HPKE to generate a shared secret used to 129 encrypt the CEK from layer 1. 131 COSE_Encrypt_Tagged = #6.96(COSE_Encrypt) 133 SUIT_Encryption_Info = COSE_Encrypt_Tagged 135 ; Layer 0 136 COSE_Encrypt = [ 137 Headers, 138 ciphertext : bstr / nil, 139 recipients : [+COSE_recipient_outer] 140 ] 142 ; Layer 1 143 COSE_recipient_outer = [ 144 protected : bstr .size 0, 145 unprotected : header_map, ; must contain alg 146 encCEK : bstr, ; CEK encrypted with HPKE-derived shared secret 147 recipients : [ + COSE_recipient_inner ] 148 ] 150 ; Layer 2 151 COSE_recipient_inner = [ 152 protected : bstr .cbor header_map, ; must contain HPKE alg 153 unprotected : header_map, ; must contain kid and ephemeral public key 154 empty : null, 155 empty : null 156 ] 158 header_map = { 159 Generic_Headers, 160 * label =values, 161 } 163 Figure 1: CDDL for HPKE-based COSE_Encrypt Structure 165 The COSE_recipient_outer structure shown in Figure 1 includes the 166 encrypted CEK (in the encCEK structure) and the COSE_recipient_inner 167 structure, also shown in Figure 1, contains the ephemeral public key 168 (in the unprotected structure). 170 3.2. HPKE Encryption with SealBase 172 The SealBase(pkR, info, aad, pt) function is used to encrypt a 173 plaintext pt to a recipient's public key (pkR). For use in this 174 specification, the plaintext "pt" passed into the SealBase is the 175 CEK. The CEK is a random byte sequence of length appropriate for the 176 encryption algorithm selected in layer 0. For example, AES-128-GCM 177 requires a 16 byte key and the CEK would therefore be 16 bytes long. 179 The "info" parameter can be used to influence the generation of keys 180 and the "aad" parameter provides additional authenticated data to the 181 AEAD algorithm in use. If successful, SealBase() will output a 182 ciphertext "ct" and an encapsulated key "enc". The content of enc is 183 the ephemeral public key. 185 The content of the info parameter is based on the 'COSE_KDF_Context' 186 structure, which is detailed in Figure 2. 188 3.3. HPKE Decryption with Open 190 The recipient will use the OpenBase(enc, skR, info, aad, ct) function 191 with the enc and ct parameters received from the sender. The "aad" 192 and the "info" parameters are obtained via the context of the usage. 194 The OpenBase function will, if successful, decrypt "ct". When 195 decrypted, the result will be the CEK. The CK is the symmetric key 196 used to decrypt the ciphertext in the COSE_Encrypt structure. 198 3.4. Info Structure 200 This specification re-uses the context information structure defined 201 in [RFC8152] for use with the HPKE algorithm. This payload becomes 202 the content of the info parameter for the HPKE functions. For better 203 readability of this specification the COSE_KDF_Context structure is 204 repeated in Figure 2. 206 PartyInfo = ( 207 identity : bstr / nil, 208 nonce : bstr / int / nil, 209 other : bstr / nil 210 ) 212 COSE_KDF_Context = [ 213 AlgorithmID : int / tstr, 214 PartyUInfo : [ PartyInfo ], 215 PartyVInfo : [ PartyInfo ], 216 SuppPubInfo : [ 217 keyDataLength : uint, 218 protected : empty_or_serialized_map, 219 ? other : bstr 220 ], 221 ? SuppPrivInfo : bstr 222 ] 224 Figure 2: COSE_KDF_Context Data Structure for info parameter 226 Since this specification may be used in a number of different 227 deployment environments flexibility for populating the fields in the 228 COSE_KDF_Context structure is provided. 230 For better interoperability, the following recommended settings are 231 provided: 233 * PartyUInfo.identity corresponds to the kid found in the 234 COSE_Sign_Tagged or COSE_Sign1_Tagged structure (when a digital 235 signature is used). When utilizing a MAC, then the kid is found 236 in the COSE_Mac_Tagged or COSE_Mac0_Tagged structure. 238 * PartyVInfo.identity corresponds to the kid used for the respective 239 recipient from the inner-most recipients array. 241 * The value in the AlgorithmID field corresponds to the alg 242 parameter in the protected structure in the inner-most recipients 243 array. 245 * keyDataLength is set to the number of bits of the desired output 246 value. 248 * protected refers to the protected structure of the inner-most 249 array. 251 4. Example 253 An example of the COSE_Encrypt structure using the HPKE scheme is 254 shown in Figure 3. It uses the following algorithm combination: 256 * AES-GCM-128 for encryption of detached ciphertext. 258 * AES-GCM-128 for encryption of the CEK. 260 * Key Encapsulation Mechanism (KEM): NIST P-256 262 * Key Derivation Function (KDF): HKDF-SHA256 263 96( 264 [ 265 // protected field with alg=AES-GCM-128 266 h'A10101', 267 { // unprotected field with iv 268 5: h'26682306D4FB28CA01B43B80' 269 }, 270 // null because of detached ciphertext 271 null, 272 [ // COSE_recipient_outer 273 h'', // empty protected field 274 { // unprotected field with ... 275 1: 1 // alg=A128GCM 276 }, 277 // Encrypted CEK 278 h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A', 279 / recipients / [ // COSE_recipient_inner 280 [ 281 / protected / h'a1013818' / { 282 \ alg \ 1:TBD1 \ HPKE/P-256+HKDF-256 \ 283 } / , 284 / unprotected / { 285 // HPKE encapsulated key 286 / ephemeral / -1:{ 287 / kty / 1:2, 288 / crv / -1:1, 289 / x / -2:h'98f50a4ff6c05861c8...90bbf91d6280', 290 / y / -3:true 291 }, 292 // kid for recipient static ECDH public key 293 / kid / 4:'meriadoc.brandybuck@buckland.example' 294 }, 295 // empty ciphertext 296 / ciphertext / h'' 297 ] 298 ] 299 ] 300 ] 301 ) 303 Figure 3: COSE_Encrypt Example for HPKE 305 5. Security Considerations 307 This specification is based on HPKE and the security considerations 308 of HPKE [I-D.irtf-cfrg-hpke] are therefore applicable also to this 309 specification. 311 HPKE assumes that the sender is in possession of the public key of 312 the recipient. A system using HPKE COSE has to assume the same 313 assumptions and public key distribution mechanism is assumed to 314 exist. 316 Since the CEK is randomly generated it must be ensured that the 317 guidelines for random number generations are followed, see [RFC8937]. 319 The SUIT_Encryption_Info structure shown in this document does not 320 provide authentication. Hence, the SUIT_Encryption_Info structure 321 has to be used in combination with other COSE constructs, such as the 322 COSE_Sign or COSE_Sign1. 324 6. IANA Considerations 326 This document requests IANA to create new entries in the COSE 327 Algorithms registry established with [RFC8152]. 329 +-------------+-------+---------+------------+--------+---------------+ 330 | Name | Value | KDF | Ephemeral- | Key | Description | 331 | | | | Static | Wrap | | 332 +-------------+-------+---------+------------+--------+---------------+ 333 | HPKE/P-256+ | TBD1 | HKDF - | yes | none | HPKE with | 334 | HKDF-256 | | SHA-256 | | | ECDH-ES | 335 | | | | | | (P-256) + | 336 | | | | | | HKDF-256 | 337 +-------------+-------+---------+------------+--------+---------------+ 338 | HPKE/P-384+ | TBD2 | HKDF - | yes | none | HPKE with | 339 | HKDF-SHA384 | | SHA-384 | | | ECDH-ES | 340 | | | | | | (P-384) + | 341 | | | | | | HKDF-384 | 342 +-------------+-------+---------+------------+--------+---------------+ 343 | HPKE/P-521+ | TBD3 | HKDF - | yes | none | HPKE with | 344 | HKDF-SHA521 | | SHA-521 | | | ECDH-ES | 345 | | | | | | (P-521) + | 346 | | | | | | HKDF-521 | 347 +-------------+-------+---------+------------+--------+---------------+ 348 | HPKE | TBD4 | HKDF - | yes | none | HPKE with | 349 | X25519 + | | SHA-256 | | | ECDH-ES | 350 | HKDF-SHA256 | | | | | (X25519) + | 351 | | | | | | HKDF-256 | 352 +-------------+-------+---------+------------+--------+---------------+ 353 | HPKE | TBD4 | HKDF - | yes | none | HPKE with | 354 | X448 + | | SHA-512 | | | ECDH-ES | 355 | HKDF-SHA512 | | | | | (X448) + | 356 | | | | | | HKDF-512 | 357 +-------------+-------+---------+------------+--------+---------------+ 359 7. References 361 7.1. Normative References 363 [I-D.irtf-cfrg-hpke] 364 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 365 "Hybrid Public Key Encryption", Work in Progress, 366 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 367 . 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, 372 DOI 10.17487/RFC2119, March 1997, 373 . 375 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 376 RFC 8152, DOI 10.17487/RFC8152, July 2017, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 7.2. Informative References 385 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 386 DOI 10.17487/RFC2630, June 1999, 387 . 389 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 390 and C. Wood, "Randomness Improvements for Security 391 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 392 . 394 Appendix A. Acknowledgements 396 TBD: Add your name here. 398 Authors' Addresses 400 Hannes Tschofenig 401 Arm Limited 403 Email: hannes.tschofenig@arm.com 404 Russ Housley 405 Vigil Security, LLC 407 Email: housley@vigilsec.com 409 Brendan Moran 410 Arm Limited 412 Email: Brendan.Moran@arm.com