--- 1/draft-ietf-cose-rfc8152bis-algs-05.txt 2019-11-04 15:13:22.104461319 -0800 +++ 2/draft-ietf-cose-rfc8152bis-algs-06.txt 2019-11-04 15:13:22.200463749 -0800 @@ -1,19 +1,19 @@ COSE Working Group J. Schaad Internet-Draft August Cellars -Obsoletes: 8152 (if approved) September 11, 2019 +Obsoletes: 8152 (if approved) 4 November 2019 Intended status: Standards Track -Expires: March 14, 2020 +Expires: 7 May 2020 CBOR Object Signing and Encryption (COSE): Initial Algorithms - draft-ietf-cose-rfc8152bis-algs-05 + draft-ietf-cose-rfc8152bis-algs-06 Abstract Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. COSE additionally describes how to represent @@ -44,21 +44,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 14 March 2020. + This Internet-Draft will expire on 7 May 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -67,65 +67,70 @@ as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 4 1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4 1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 4 - 1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1.1. Security Considerations . . . . . . . . . . . . . . . 6 + 2.1.1. Security Considerations . . . . . . . . . . . . . . . 7 2.2. Edwards-Curve Digital Signature Algorithms - (EdDSAs) . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.2.1. Security Considerations . . . . . . . . . . . . . . . 8 - 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 8 + (EdDSAs) . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.2.1. Security Considerations . . . . . . . . . . . . . . . 9 + 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9 3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9 - 3.1.1. Security Considerations . . . . . . . . . . . . . . . 10 - 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 10 - 3.2.1. Security Considerations . . . . . . . . . . . . . . . 11 + 3.1.1. Security Considerations . . . . . . . . . . . . . . . 11 + 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11 + 3.2.1. Security Considerations . . . . . . . . . . . . . . . 12 4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Security Considerations . . . . . . . . . . . . . . . 13 - 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.2.1. Security Considerations . . . . . . . . . . . . . . . 16 - 4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 16 - 4.3.1. Security Considerations . . . . . . . . . . . . . . . 17 - 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 17 + 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2.1. Security Considerations . . . . . . . . . . . . . . . 17 + 4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 17 + 4.3.1. Security Considerations . . . . . . . . . . . . . . . 18 + 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 18 5.1. HMAC-Based Extract-and-Expand Key Derivation Function - (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.2. Context Information Structure . . . . . . . . . . . . . . 19 - 6. Content Key Distribution Methods . . . . . . . . . . . . . . 24 - 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 25 - 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 25 - 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 26 - 6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 28 - 6.2.1. Security Considerations for AES-KW . . . . . . . . . 28 - 6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 29 - 6.3.1. Security Considerations . . . . . . . . . . . . . . . 32 - 6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 32 - 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 34 - 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 34 - 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 35 - 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 36 - 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 37 - 8. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 38 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 - 11.2. Informative References . . . . . . . . . . . . . . . . . 42 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 + (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2. Context Information Structure . . . . . . . . . . . . . . 20 + 6. Content Key Distribution Methods . . . . . . . . . . . . . . 25 + 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 26 + 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 26 + 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 27 + 6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 29 + 6.2.1. Security Considerations for AES-KW . . . . . . . . . 29 + 6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 30 + 6.3.1. Security Considerations . . . . . . . . . . . . . . . 33 + 6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 33 + 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 35 + 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 35 + 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 36 + 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 37 + 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 38 + 8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 39 + 8.1. Assignments for Existing Key Types . . . . . . . . . . . 39 + 8.2. Assignments for Existing Algorithms . . . . . . . . . . . 40 + 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 40 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 + 10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 40 + 10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 41 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 43 + 12.2. Informative References . . . . . . . . . . . . . . . . . 45 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction There has been an increased focus on small, constrained devices that make up the Internet of Things (IoT). One of the standards that has come out of this process is "Concise Binary Object Representation (CBOR)" [RFC7049]. CBOR extended the data model of the JavaScript Object Notation (JSON) [RFC8259] by allowing for binary data, among other changes. CBOR is being adopted by several of the IETF working groups dealing with the IoT world as their encoding of data @@ -1695,47 +1700,141 @@ 'k' be present in the structure. +------+----------+-------+------+-------------+ | Name | Key Type | Label | Type | Description | +======+==========+=======+======+=============+ | k | 4 | -1 | bstr | Key Value | +------+----------+-------+------+-------------+ Table 21: Symmetric Key Parameters -8. CBOR Encoding Restrictions +8. COSE Capabilities + + There are some situations that have been identified where + identification of capabilities of an algorithm need to be specified. + One example of this is in [I-D.ietf-core-oscore-groupcomm] where the + capabilities of the counter signature algorithm are mixed into the + traffic key derivation process. This has a counterpart in the S/MIME + specifications where SMIMECapabilities is defined in Section 2.5.2 of + [RFC8551]. The concept is being pulled forward and defined now for + COSE. + + Two different types of capabilities are defined: Capabilities for + algorithms and capabilities for key structures. Once defined by + registration with IANA, the list capabilities is immutable. As a + general rule, the capabilities are going to correspond to algorithm + or key fields, but they do not need to do so. An example of this is + the HSS-LMS key capabilities defined below where the hash algorithm + used is included. + + The capability structure is an array of values, the order being + dependent on the specific algorithm or key. For an algorithm, the + first element should always be a key type value, but the items that + are specific to a key should not be included in the algorithm + capabilities. This means that if one wishes to enumerate all of the + capabilities for a device which implements ECDH, it requires multiple + pairs of capability structures (algorithm, key) to deal with the + different key types and curves that are supported. For a key, the + first element should also be a key type value, while this means that + this value will be duplicated if both an algorithm and key capability + are used, the key type is needed in order to understand the rest of + the values. + +8.1. Assignments for Existing Key Types + + There are a number of pre-existing key types, the following deals + with creating the capability definition for those structures: + + * OKP, EC2: The list of capabilities is: + + - The key type value, + + - One curve for that key type. + + * RSA: The list of capabilities is: + + - The key type value. + + * Symmetric: The list of capabilities is: + + - The key type value. + + * HSS-LMS: The list of capabilities is: + + - The key type value, + + - Algorithm identifier for the underlying hash function. + +8.2. Assignments for Existing Algorithms + + For the current set of algorithms in the registry, those in this + document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig], + the capabilities is set to the single entry of the key type that will + be accepted. It is expected other algorithms will have no items or + multiple items. + +9. CBOR Encoding Restrictions There has been an attempt to limit the number of places where the document needs to impose restrictions on how the CBOR Encoder needs to work. We have managed to narrow it down to the following restrictions: * The restriction applies to the encoding of the COSE_KDF_Context. * Encoding MUST be done using definite lengths and the length of the MUST be the minimum possible length. This means that the integer 1 is encoded as "0x01" and not "0x1801". * Applications MUST NOT generate messages with the same label used twice as a key in a single map. Applications MUST NOT parse and process messages with the same label used twice as a key in a single map. Applications can enforce the parse and process requirement by using parsers that will fail the parse step or by using parsers that will pass all keys to the application, and the application can perform the check for duplicate keys. -9. IANA Considerations +10. IANA Considerations - There are no IANA actions. The required actions are in - [I-D.ietf-cose-rfc8152bis-struct]. +10.1. Changes to "COSE Key Types" registry. -10. Security Considerations + IANA is requested to create a new column in the "COSE Key Types" + registry. The new column is to be labeled "Capabilities". The new + column is to be populated according the the entries in Table 22. + + +------+-----------+---------------------+ + | Name | Value | Capabilities | + +======+===========+=====================+ + | 1 | OKP | kty, crv | + +------+-----------+---------------------+ + | 2 | EC2 | kty, crv | + +------+-----------+---------------------+ + | 3 | RSA | kty | + +------+-----------+---------------------+ + | 4 | Symmetric | kty | + +------+-----------+---------------------+ + | 5 | HSS-LMS | kty, hash algorithm | + +------+-----------+---------------------+ + + Table 22: Key Type Capabilities + +10.2. Changes to "COSE Algorithms" registry + + IANA is requested to create a new column in the "COSE Algorithms" + registry. The new column is to be labeled "Capabilities". The new + column is populated with "kty" for all current, non-provisional, + registrations. It is expected that the documents which define those + algorithms will be expanded to include this registration, if this is + not done then the DE should be consulted at the time of final + registration. + +11. Security Considerations There are a number of security considerations that need to be taken into account by implementers of this specification. The security considerations that are specific to an individual algorithm are placed next to the description of the algorithm. While some considerations have been highlighted here, additional considerations may be found in the documents listed in the references. Implementations need to protect the private key material for any individuals. There are some cases in this document that need to be @@ -1814,49 +1913,30 @@ analysis of encrypted messages based on the length of the message. This specification does not provide for a uniform method of providing padding as part of the message structure. An observer can distinguish between two different strings (for example, 'YES' and 'NO') based on the length for all of the content encryption algorithms that are defined in this document. This means that it is up to the applications to document how content padding is to be done in order to prevent or discourage such analysis. (For example, the strings could be defined as 'YES' and 'NO '.) -11. References - -11.1. Normative References - - [AES-GCM] National Institute of Standards and Technology, - "Recommendation for Block Cipher Modes of Operation: - Galois/Counter Mode (GCM) and GMAC", - DOI 10.6028/NIST.SP.800-38D, NIST Special - Publication 800-38D, November 2007, - . +12. References - [DSS] National Institute of Standards and Technology, "Digital - Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, - FIPS PUB 186-4, July 2013, - . +12.1. Normative References [I-D.ietf-cose-rfc8152bis-struct] Schaad, J., "CBOR Object Signing and Encryption (COSE): - Structures and Process", Internet Draft, draft-ietf-cose- - rfc8152bis-struct-05, August 18, 2019, - . - - [MAC] National Institute of Standards and Technology, "Computer - Data Authentication", FIPS PUB 113, May 1985, - . + Structures and Process", Work in Progress, Internet-Draft, + draft-ietf-cose-rfc8152bis-struct-06, 11 September 2019, + . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -1881,41 +1961,66 @@ [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . + [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF + Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, + . + [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . - [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital - Signature Algorithm (EdDSA)", RFC 8032, - DOI 10.17487/RFC8032, January 2017, - . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . - [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF - Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, - . + [AES-GCM] National Institute of Standards and Technology, + "Recommendation for Block Cipher Modes of Operation: + Galois/Counter Mode (GCM) and GMAC", + DOI 10.6028/NIST.SP.800-38D, NIST Special + Publication 800-38D, November 2007, + . + + [DSS] National Institute of Standards and Technology, "Digital + Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, + FIPS PUB 186-4, July 2013, + . + + [MAC] National Institute of Standards and Technology, "Computer + Data Authentication", FIPS PUB 113, May 1985, + . [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", May 2009, . -11.2. Informative References + [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital + Signature Algorithm (EdDSA)", RFC 8032, + DOI 10.17487/RFC8032, January 2017, + . + +12.2. Informative References + + [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data + Definition Language (CDDL): A Notational Convention to + Express Concise Binary Object Representation (CBOR) and + JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, + June 2019, . [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, . [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, . @@ -1926,48 +2031,66 @@ [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + . + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . - [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data - Interchange Format", STD 90, RFC 8259, - DOI 10.17487/RFC8259, December 2017, - . + [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ + Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 + Message Specification", RFC 8551, DOI 10.17487/RFC8551, + April 2019, . - [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data - Definition Language (CDDL): A Notational Convention to - Express Concise Binary Object Representation (CBOR) and - JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, - June 2019, . + [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing + and Encryption (COSE) Messages", RFC 8230, + DOI 10.17487/RFC8230, September 2017, + . + + [I-D.ietf-core-oscore-groupcomm] + Tiloca, M., Selander, G., Palombini, F., and J. Park, + "Group OSCORE - Secure Group Communication for CoAP", Work + in Progress, Internet-Draft, draft-ietf-core-oscore- + groupcomm-05, 5 July 2019, . + + [I-D.ietf-cose-hash-sig] + Housley, R., "Use of the HSS/LMS Hash-based Signature + Algorithm with CBOR Object Signing and Encryption (COSE)", + Work in Progress, Internet-Draft, draft-ietf-cose-hash- + sig-06, 1 November 2019, + . [SP800-56A] Barker, E., Chen, L., Roginsky, A., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", DOI 10.6028/NIST.SP.800-56Ar2, NIST Special Publication 800-56A, Revision 2, May 2013, .