--- 1/draft-ietf-cose-rfc8152bis-struct-13.txt 2020-09-24 11:13:11.001772599 -0700 +++ 2/draft-ietf-cose-rfc8152bis-struct-14.txt 2020-09-24 11:13:11.145776242 -0700 @@ -1,19 +1,19 @@ COSE Working Group J. Schaad Internet-Draft August Cellars -Obsoletes: 8152 (if approved) September 4, 2020 +Obsoletes: 8152 (if approved) 24 September 2020 Intended status: Standards Track -Expires: March 8, 2021 +Expires: 28 March 2021 CBOR Object Signing and Encryption (COSE): Structures and Process - draft-ietf-cose-rfc8152bis-struct-13 + draft-ietf-cose-rfc8152bis-struct-14 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. This specification additionally describes how to @@ -39,21 +39,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 March 8, 2021. + This Internet-Draft will expire on 28 March 2021. Copyright Notice Copyright (c) 2020 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 @@ -86,77 +86,78 @@ 5.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 27 5.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 29 6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. MACed Message with Recipients . . . . . . . . . . . . . . 31 6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 32 6.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 33 7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 35 8. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 37 8.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 38 - 8.2. Message Authentication Code (MAC) Algorithms . . . . . . 39 - 8.3. Content Encryption Algorithms . . . . . . . . . . . . . . 39 - 8.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 40 - 8.5. Content Key Distribution Methods . . . . . . . . . . . . 41 - 8.5.1. Direct Encryption . . . . . . . . . . . . . . . . . . 41 - 8.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 41 - 8.5.3. Key Transport . . . . . . . . . . . . . . . . . . . . 42 - 8.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 42 - 8.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . . 43 - 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 44 - 10. Application Profiling Considerations . . . . . . . . . . . . 44 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 - 11.1. COSE Header Parameters Registry . . . . . . . . . . . . 46 - 11.2. COSE Key Common Parameters Registry . . . . . . . . . . 46 - 11.3. Media Type Registrations . . . . . . . . . . . . . . . . 46 - 11.3.1. COSE Security Message . . . . . . . . . . . . . . . 46 - 11.3.2. COSE Key Media Type . . . . . . . . . . . . . . . . 47 - 11.4. CoAP Content-Formats Registry . . . . . . . . . . . . . 49 - 11.5. Expert Review Instructions . . . . . . . . . . . . . . . 49 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50 - 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 52 - 13.1. Author's Versions . . . . . . . . . . . . . . . . . . . 53 - 13.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 53 - 13.3. Python Version . . . . . . . . . . . . . . . . . . . . . 54 - 13.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 54 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 54 - 14.2. Informative References . . . . . . . . . . . . . . . . . 55 + 8.2. Message Authentication Code (MAC) Algorithms . . . . . . 40 + 8.3. Content Encryption Algorithms . . . . . . . . . . . . . . 40 + 8.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 41 + 8.5. Content Key Distribution Methods . . . . . . . . . . . . 42 + 8.5.1. Direct Encryption . . . . . . . . . . . . . . . . . . 42 + 8.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 42 + 8.5.3. Key Transport . . . . . . . . . . . . . . . . . . . . 43 + 8.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 43 + 8.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . . 44 + 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 45 + 10. Application Profiling Considerations . . . . . . . . . . . . 45 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 + 11.1. COSE Header Parameters Registry . . . . . . . . . . . . 47 + 11.2. COSE Key Common Parameters Registry . . . . . . . . . . 47 + 11.3. Media Type Registrations . . . . . . . . . . . . . . . . 47 + 11.3.1. COSE Security Message . . . . . . . . . . . . . . . 47 + 11.3.2. COSE Key Media Type . . . . . . . . . . . . . . . . 48 + 11.4. CoAP Content-Formats Registry . . . . . . . . . . . . . 50 + 11.5. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 50 + 11.6. Expert Review Instructions . . . . . . . . . . . . . . . 50 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 51 + 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 53 + 13.1. Author's Versions . . . . . . . . . . . . . . . . . . . 54 + 13.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 54 + 13.3. Python Version . . . . . . . . . . . . . . . . . . . . . 55 + 13.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 55 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 55 + 14.2. Informative References . . . . . . . . . . . . . . . . . 56 Appendix A. Guidelines for External Data Authentication of - Algorithms . . . . . . . . . . . . . . . . . . . . . . . 59 - Appendix B. Two Layers of Recipient Information . . . . . . . . 62 - Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 64 - C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 64 - C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 64 - C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 65 - C.1.3. Signature with Criticality . . . . . . . . . . . . . 66 - C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 67 - C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 67 - C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 68 - C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 68 - C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 69 - C.3.3. Encrypted Content with External Data . . . . . . . . 70 - C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 71 - C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 71 - C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 72 - C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 72 - C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 72 - C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 73 - C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 74 - C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 75 - C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 76 - C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 76 - C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 77 - C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 77 - C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 78 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 80 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81 + Algorithms . . . . . . . . . . . . . . . . . . . . . . . 60 + Appendix B. Two Layers of Recipient Information . . . . . . . . 63 + Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 65 + C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 65 + C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 65 + C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 66 + C.1.3. Signature with Criticality . . . . . . . . . . . . . 67 + C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 68 + C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 68 + C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 69 + C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 69 + C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 70 + C.3.3. Encrypted Content with External Data . . . . . . . . 71 + C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 72 + C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 72 + C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 73 + C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 73 + C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 73 + C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 74 + C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 75 + C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 76 + C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 77 + C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 77 + C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 78 + C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 78 + C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 79 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 81 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 82 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)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the JavaScript Object Notation (JSON) [STD90] by allowing for binary data, among other changes. CBOR has been adopted by several of the IETF working groups dealing with the IoT world as their encoding of @@ -1728,66 +1729,108 @@ into this taxonomy. 8.1. Signature Algorithms Signature algorithms provide data origination and data integrity services. Data origination provides the ability to infer who originated the data based on who signed the data. Data integrity provides the ability to verify that the data has not been modified since it was signed. - There are two signature algorithm schemes. The first is signature - with appendix. In this scheme, the message content is processed and - a signature is produced; the signature is called the appendix. This - is the scheme used by algorithms such as ECDSA and the RSA - Probabilistic Signature Scheme (RSASSA-PSS). (In fact, the SSA in - RSASSA-PSS stands for Signature Scheme with Appendix.) + There are two general signature algorithm schemes. The first is + signature with appendix. In this scheme, the message content is + processed and a signature is produced; the signature is called the + appendix. This is the scheme used by algorithms such as ECDSA and + the RSA Probabilistic Signature Scheme (RSASSA-PSS). (In fact, the + SSA in RSASSA-PSS stands for Signature Scheme with Appendix.) The signature functions for this scheme are: signature = Sign(message content, key) valid = Verification(message content, key, signature) The second scheme is signature with message recovery (an example of such an algorithm is [PVSig]). In this scheme, the message content is processed, but part of it is included in the signature. Moving bytes of the message content into the signature allows for smaller signatures; the signature size is still potentially large, but the message content has shrunk. This has implications for systems implementing these algorithms and for applications that use them. The first is that the message content is not fully available until after a signature has been validated. Until that point, the part of the message contained inside of the signature is unrecoverable. The second is that the security analysis of the strength of the signature - is very much based on the structure of the message content. Messages - that are highly predictable require additional randomness to be - supplied as part of the signature process. In the worst case, it - becomes the same as doing a signature with appendix. Finally, in the - event that multiple signatures are applied to a message, all of the - signature algorithms are going to be required to consume the same - number of bytes of message content. This means that the mixing of - the different schemes in a single message is not supported, and if a - recovery signature scheme is used, then the same amount of content - needs to be consumed by all of the signatures. + can be very much dependent on the structure of the message content. + Finally, in the event that multiple signatures are applied to a + message, all of the signature algorithms are going to be required to + consume the same bytes of message content. This means that the + mixing of the signature with message recovery and signature with + appendix schemes in a single message is not supported, and if a + recovery signature scheme is used. The signature functions for this scheme are: signature, message sent = Sign(message content, key) valid, message content = Verification(message sent, key, signature) + No message recovery signature algorithms have been formally defined + for COSE yet, and given the new constraints arising from this + schemes, while some of these issues have already been identified + there is a high probability that additional issues will arise when + integrating message recovery signature algorithms. The first + algorithm defined is going to need to make decisions about these + issues and those decisions re likely to be binding on any further + algorithms defined. + + We use the following terms below: + + message content bytes: The byte provided by the application to be + signed. + + to-be-signed bytes: The byte string passed into the signature + algorithm. + + recovered bytes: The bytes recovered during the signature + verification process. + + Some of the issue2 that have already been identified are: + + * The to-be-signed bytes are not the same as the message content + bytes. This is because we build a larger to-be-signed message + during the signature processing. The recovered bytes length may + exceed the message content length, but not the length of the to- + be-signed bytes. This may lead to privacy considerations if, for + example, the externally supplied data contains confidential + information. + + * There may be difficulties in determining where the recovered bytes + match up with the to-be-signed bytes, because the recovered bytes + contains data not in the message content bytes. One possible + option would be to create a padding scheme to prevent that. + + * Not all message recovery signature algorithms take the recovered + bytes from the end of the to-be-signed bytes. This is a problem + because the message content bytes are at the end of the to-be- + signed bytes. If the bytes to be recovered are taken from the + start of the to-be-signed bytes then, by default, none of the + message content bytes may be included in the recovered bytes. One + possible option to deal with this is to reverse the to-be-signed + data in the event that recovered bytes are taken from the start + rather than end of the to-be-signed bytes. + Signature algorithms are used with the COSE_Signature and COSE_Sign1 - structures. At this time, only signatures with appendixes are - defined for use with COSE; however, considerable interest has been - expressed in using a signature with message recovery algorithm due to - the effective size reduction that is possible. Implementations will - need to keep this in mind for later possible integration. + structures. At the time of this writing, only signatures with + appendixes are defined for use with COSE; however, considerable + interest has been expressed in using a signature with message + recovery algorithm due to the effective size reduction that is + possible. 8.2. Message Authentication Code (MAC) Algorithms Message Authentication Codes (MACs) provide data authentication and integrity protection. They provide either no or very limited data origination. A MAC, for example, cannot be used to prove the identity of the sender to a third party. MACs use the same scheme as signature with appendix algorithms. The message content is processed and an authentication code is produced. @@ -2113,32 +2156,26 @@ update the references to point to this document. 11.1. COSE Header Parameters Registry IANA created a registry titled "COSE Header Parameters" as part of processing [RFC8152]. IANA is requested to update the reference for all entries, except "counter signature" and "CounterSignature0", in the table from [RFC8152] to this document. The reference for "counter signature" and "CounterSignature0" are to be left alone. - IANA is requested to update the pointer for expert rview to [[this - document]]. - 11.2. COSE Key Common Parameters Registry IANA created a registry titled "COSE Key Common Parameters" as part of the processing of [RFC8152]. IANA is requested to update the reference for entries in the table from [RFC8152] to this document. - IANA is requested to update the pointer for expert rview to [[this - document]]. - 11.3. Media Type Registrations 11.3.1. COSE Security Message This section registers the 'application/cose' media type in the "Media Types" registry. These media types are used to indicate that the content is a COSE message. Type name: application @@ -2282,21 +2320,26 @@ Change Controller: IESG Provisional registration? No 11.4. CoAP Content-Formats Registry IANA added entries to the "CoAP Content-Formats" registry while processing [RFC8152]. IANA is requested to update the reference value from [RFC8152] to [[This Document]]. -11.5. Expert Review Instructions +11.5. CBOR Tags Registry + + IANA is requested to update the references from [RFC8152] to [[This + Document]]. + +11.6. Expert Review Instructions All of the IANA registries established by [RFC8152] are, at least in part, defined as expert review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude. Expert reviewers should take into consideration the following points: * Point squatting should be discouraged. Reviewers are encouraged @@ -2530,31 +2573,31 @@ 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [I-D.ietf-cbor-7049bis] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", Work in Progress, Internet-Draft, - draft-ietf-cbor-7049bis-14, June 16, 2020, + draft-ietf-cbor-7049bis-14, 16 June 2020, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ietf-cose-rfc8152bis-algs] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", Work in Progress, Internet-Draft, - draft-ietf-cose-rfc8152bis-algs-11, July 1, 2020, + draft-ietf-cose-rfc8152bis-algs-11, 1 July 2020, . 14.2. Informative References [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data @@ -2667,42 +2710,42 @@ RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, . [I-D.ietf-cose-hash-algs] Schaad, J., "CBOR Object Signing and Encryption (COSE): Hash Algorithms", Work in Progress, Internet-Draft, draft- - ietf-cose-hash-algs-08, July 29, 2020, + ietf-cose-hash-algs-09, 14 September 2020, . + 09>. [I-D.ietf-core-groupcomm-bis] Dijk, E., Wang, C., and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- - 01, July 13, 2020, . + 01, 13 July 2020, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . [I-D.irtf-cfrg-argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "The memory-hard Argon2 password hash and proof-of-work function", Work in Progress, Internet-Draft, - draft-irtf-cfrg-argon2-11, July 9, 2020, - . + draft-irtf-cfrg-argon2-12, 8 September 2020, + . [COAP.Formats] IANA, "CoAP Content-Formats", . [COSE.Algorithms] IANA, "COSE Algorithms", .