--- 1/draft-ietf-cose-countersign-01.txt 2020-12-16 09:13:18.187996429 -0800 +++ 2/draft-ietf-cose-countersign-02.txt 2020-12-16 09:13:18.231997543 -0800 @@ -1,19 +1,19 @@ COSE Working Group J. Schaad Internet-Draft August Cellars Intended status: Standards Track R. Housley, Ed. -Expires: 10 April 2021 Vigil Security - 7 October 2020 +Expires: 19 June 2021 Vigil Security + 16 December 2020 CBOR Object Signing and Encryption (COSE): Countersignatures - draft-ietf-cose-countersign-01 + draft-ietf-cose-countersign-02 Abstract Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. Contributing to this document @@ -34,68 +34,75 @@ 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 10 April 2021. + This Internet-Draft will expire on 19 June 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 and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text 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 . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 1.2. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4 2. Countersignature Header Parameters . . . . . . . . . . . . . 5 3. Version 2 Countersignatures . . . . . . . . . . . . . . . . . 6 3.1. Full Countersignatures . . . . . . . . . . . . . . . . . 7 3.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 8 3.3. Signing and Verification Process . . . . . . . . . . . . 8 4. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . . 10 5.2. COSE Header Parameters Registry . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 - 7.1. Author's Versions . . . . . . . . . . . . . . . . . . . . 14 + 7.1. Author's Versions . . . . . . . . . . . . . . . . . . . . 13 7.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 14 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16 - A.1. Examples of Signed Messages . . . . . . . . . . . . . . . 17 - A.1.1. Countersignature . . . . . . . . . . . . . . . . . . 17 - A.2. Examples of Enveloped Messages . . . . . . . . . . . . . 18 - A.2.1. Countersignature on Encrypted Content . . . . . . . . 18 - A.3. Examples of Encrypted Messages . . . . . . . . . . . . . 19 - A.4. Examples of MACed Messages . . . . . . . . . . . . . . . 19 - A.5. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 20 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + A.1. Use of Early Code Points . . . . . . . . . . . . . . . . 17 + A.2. Examples of Signed Messages . . . . . . . . . . . . . . . 17 + A.2.1. Countersignature . . . . . . . . . . . . . . . . . . 17 + A.3. Examples of Signed1 Messages . . . . . . . . . . . . . . 18 + A.3.1. Countersignature . . . . . . . . . . . . . . . . . . 18 + A.4. Examples of Enveloped Messages . . . . . . . . . . . . . 19 + A.4.1. Countersignature on Encrypted Content . . . . . . . . 19 + A.5. Examples of Encrypted Messages . . . . . . . . . . . . . 20 + A.5.1. Countersignature on Encrypted Content . . . . . . . . 21 + A.6. Examples of MACed Messages . . . . . . . . . . . . . . . 21 + A.6.1. Countersignature on MAC Content . . . . . . . . . . . 21 + + A.7. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 22 + A.7.1. Countersignature on MAC0 Content . . . . . . . . . . 22 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 @@ -307,22 +314,22 @@ The countersignature structure is the same as that used for a signer on a signed object. The CDDL fragment for full countersignatures is: COSE_Countersignature_Tagged = #6.9999(COSE_Countersignature) COSE_Countersignature = COSE_Signature The details of the fields of a countersignature can be found in Section 4.1 of [I-D.ietf-cose-rfc8152bis-struct]. An example of a countersignature on a signature can be found in - Appendix A.1.1. An example of a countersignature in an encryption - object can be found in Appendix A.2.1. + Appendix A.2.1. An example of a countersignature in an encryption + object can be found in Appendix A.4.1. It should be noted that only a signature algorithm with appendix (see Section 8 of [I-D.ietf-cose-rfc8152bis-struct]) can be used for countersignatures. This is because the body should be able to be processed without having to evaluate the countersignature, and this is not possible for signature schemes with message recovery. 3.2. Abbreviated Countersignatures Abbreviated countersignatures were designed primarily to deal with @@ -463,47 +470,44 @@ * Semantics: COSE standalone V2 countersignature * Reference: [[this document]] 5.2. COSE Header Parameters Registry IANA created a registry titled "COSE Header Parameters" as part of processing [RFC8152]. IANA is requested to register the following new items in the - registry. + registry. For these entries, the Value Registry column will be blank + and the Reference column will be [[This Document]]. - +=================+=====+======================+========+================+ - |Name |Label|Value Type |Value |Description | - | | | |Registry| | - +=================+=====+======================+========+================+ - |counter signature|TBD10|COSE_Countersignature | |V2 | - |version 2 | |/ [+ | |countersignature| - | | |COSE_Countersignature | |attribute | - | | |] | | | - +-----------------+-----+----------------------+--------+----------------+ - |Countersignature0|TBD11|COSE_Countersignature0| |Abbreviated | - |version 2 | | | |Counter | - | | | | |signature vesion| - | | | | |2 | - +-----------------+-----+----------------------+--------+----------------+ + +===================+=====+========================+================+ + | Name |Label|Value Type |Description | + +===================+=====+========================+================+ + | counter signature |TBD10|COSE_Countersignature / |V2 | + | version 2 | |[+ COSE_Countersignature|countersignature| + | | |] |attribute | + +-------------------+-----+------------------------+----------------+ + | Countersignature0 |TBD11|COSE_Countersignature0 |Abbreviated | + | version 2 | | |Counter | + | | | |signature vesion| + | | | |2 | + +-------------------+-----+------------------------+----------------+ Table 2: New Common Header Parameters IANA is requested to modify the Description field for "counter signature" and "CounterSignature0" to include the words "(Deprecated by [[This Document]]". 6. Security Considerations - TODO - review and trim as needed. - There are a number of security considerations that need to be taken into account by implementers of this specification. 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 that need to be highlighted on this issue. * Using the same key for two different algorithms can leak @@ -528,28 +532,29 @@ using the same CEK and send it to the first recipient; the first recipient would, for either static-static ECDH or direct plus KDF, make an assumption that the CEK could be used for proof of origin even though it is from the wrong entity. If the key wrap step is added, then no proof of origin is implied and this is not an issue. Although it has been mentioned before, the use of a single key for multiple algorithms has been demonstrated in some cases to leak information about that key, provide the opportunity for attackers to forge integrity tags, or gain information about encrypted content. - Binding a key to a single algorithm prevents these problems. Key - creators and key consumers are strongly encouraged not only to create - new keys for each different algorithm, but to include that selection - of algorithm in any distribution of key material and strictly enforce - the matching of algorithms in the key structure to algorithms in the - message structure. In addition to checking that algorithms are - correct, the key form needs to be checked as well. Do not use an - 'EC2' key where an 'OKP' key is expected. + Binding a key to a single algorithm prevents these problems. + + Key creators and key consumers are strongly encouraged not only to + create new keys for each different algorithm, but to include that + selection of algorithm in any distribution of key material and + strictly enforce the matching of algorithms in the key structure to + algorithms in the message structure. In addition to checking that + algorithms are correct, the key form needs to be checked as well. Do + not use an 'EC2' key where an 'OKP' key is expected. Before using a key for transmission, or before acting on information received, a trust decision on a key needs to be made. Is the data or action something that the entity associated with the key has a right to see or a right to request? A number of factors are associated with this trust decision. Some of the ones that are highlighted here are: * What are the permissions associated with the key owner? @@ -558,31 +563,29 @@ * Have the restrictions associated with the key, such as algorithm or freshness, been checked and are they correct? * Is the request something that is reasonable, given the current state of the application? * Have any security considerations that are part of the message been enforced (as specified by the application or 'crit' header parameter)? - One area that has been getting exposure is traffic 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 messages (for example, 'YES' and - 'NO') based on the length for all of the content encryption - algorithms that are defined in [I-D.ietf-cose-rfc8152bis-algs] - 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 text strings could be defined as - 'YES' and 'NO '.) + Analysis of the size of encrypted messages can provide information + about the plaintext messages. This specification does not provide a + uniform method for padding messages prior to encryption. An observer + can distinguish between two different messages (for example, 'YES' + and 'NO') based on the length for all of the content encryption + algorithms that are defined in [I-D.ietf-cose-rfc8152bis-algs]. This + means that it is up to the applications to specify how content + padding is to be done to prevent or discourage such analysis. (For + example, the text strings could be defined as 'YES' and 'NO '.) 7. Implementation Status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to @@ -705,91 +707,87 @@ . [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, August 2007, . [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, 13 July 2020, . + 02, 2 November 2020, . [I-D.ietf-cose-rfc8152bis-struct] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", Work in Progress, Internet-Draft, - draft-ietf-cose-rfc8152bis-struct-13, 4 September 2020, + draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020, . + struct-14>. [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, . Appendix A. Examples This appendix includes a set of examples that show the different features and message types that have been defined in this document. To make the examples easier to read, they are presented using the extended CBOR diagnostic notation (defined in [RFC8610]) rather than as a binary dump. - A GitHub project has been created at that contains not only the examples presented in this - document, but a more complete set of testing examples as well. Each - example is found in a JSON file that contains the inputs used to - create the example, some of the intermediate values that can be used - in debugging the example and the output of the example presented both - as a hex dump and in CBOR diagnostic notation format. Some of the - examples at the site are designed failure testing cases; these are - clearly marked as such in the JSON file. If errors in the examples - in this document are found, the examples on GitHub will be updated, - and a note to that effect will be placed in the JSON file. - - As noted, the examples are presented using the CBOR's diagnostic - notation. A Ruby-based tool exists that can convert between the - diagnostic notation and binary. This tool can be installed with the - command line: + The examples are presented using the CBOR's diagnostic notation. A + Ruby-based tool exists that can convert between the diagnostic + notation and binary. This tool can be installed with the command + line: gem install cbor-diag The diagnostic notation can be converted into binary files using the following command line: diag2cbor.rb < inputfile > outputfile The examples can be extracted from the XML version of this document via an XPath expression as all of the sourcecode is tagged with the attribute type='CBORdiag'. (Depending on the XPath evaluator one is using, it may be necessary to deal with > as an entity.) //sourcecode[@type='CDDL']/text() -A.1. Examples of Signed Messages +A.1. Use of Early Code Points -A.1.1. Countersignature + This section is to be removed before publishing as an RFC. + + The examples in this Appendix use code points proposed for early + allocation by IANA. When IANA makes the allocation, these examples + will be updated as needed. + +A.2. Examples of Signed Messages + +A.2.1. Countersignature This example uses the following: * Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 * The same header parameters are used for both the signature and the countersignature. Size of binary file is 180 bytes 98( [ / protected / h'', / unprotected / { - / countersign / 7:[ + / countersign / 11:[ / protected h'a10126' / << { / alg / 1:-7 / ECDSA 256 / } >>, / unprotected / { / kid / 4:'11' }, / signature / h'5ac05e289d5d0e1b0a7f048a5d2b643813ded50bc9e4 9220f4f7278f85f19d4a77d655c9d3b51e805a74b099e1e085aacd97fc29d72f887e 8802bb6650cceb2c' ] @@ -804,42 +802,84 @@ / kid / 4:'11' }, / signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb 5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b 98f53afd2fa0f30a' ] ] ] ) -A.2. Examples of Enveloped Messages +A.3. Examples of Signed1 Messages -A.2.1. Countersignature on Encrypted Content +A.3.1. Countersignature + + This example uses the following: + + * Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 + + * Countersignature Algorithm: ECDSA w/ SHA-512, Curve P-521 + + Size of binary file is 275 bytes + 18( + [ + / protected h'A201260300' / << { + / alg / 1:-7, / ECDSA 256 / + / ctyp / 3:0 + } >>, + / unprotected / { + / kid / 4: "11", + / countersign / 11: [ + / protected h'A1013823' / << { + / alg / 1:-36 / ECDSA 512 / + } >>, + / unprotected / { + / kid / 4: "bilbo.baggins@hobbiton.example" + }, + / signature / h'01B1291B0E60A79C459A4A9184A0D393E034B34AF069 + A1CCA34F5A913AFFFF698002295FA9F8FCBFB6FDFF59132FC0C406E98754A98F1FBF + E81C03095F481856BC470170227206FA5BEE3C0431C56A66824E7AAF692985952E31 + 271434B2BA2E47A335C658B5E995AEB5D63CF2D0CED367D3E4CC8FFFD53B70D115BA + A9E86961FBD1A5CF' + ] + }, + / payload / 'This is the content.', + / signature / h'BB587D6B15F47BFD54D2CBFCECEF75451E92B08A514BD439 + FA3AA65C6AC92DF0D7328C4A47529B32ADD3DD1B4E940071C021E9A8F2641F1D8E3B + 053DDD65AE52' + ] + ) + +A.4. Examples of Enveloped Messages + +A.4.1. Countersignature on Encrypted Content This example uses the following: * CEK: AES-GCM w/ 128-bit key * Recipient class: ECDH Ephemeral-Static, Curve P-256 + * Countersignature Algorithm: ECDSA w/ SHA-512, Curve P-521 + Size of binary file is 326 bytes 96( [ / protected h'a10101' / << { / alg / 1:1 / AES-GCM 128 / } >>, / unprotected / { / iv / 5:h'c9cf4df2fe6c632bf7886413', - / countersign / 7:[ - / protected / h'a1013823' / { - \ alg \ 1:-36 - } / , + / countersign / 11:[ + / protected h'a1013823' / << { + / alg / 1:-36 / ES512 / + } >> , / unprotected / { / kid / 4:'bilbo.baggins@hobbiton.example' }, / signature / h'00929663c8789bb28177ae28467e66377da12302d7f9 594d2999afa5dfa531294f8896f2b6cdf1740014f4c7f1a358e3a6cf57f4ed6fb02f cf8f7aa989f5dfd07f0700a3a7d8f3c604ba70fa9411bd10c2591b483e1d2c31de00 3183e434d8fba18f17a4c7e3dfa003ac1cf3d30d44d2533c4989d3ac38c38b71481c c3430c9d65e7ddff' ] }, @@ -859,42 +899,154 @@ / y / -3:true }, / kid / 4:'meriadoc.brandybuck@buckland.example' }, / ciphertext / h'' ] ] ] ) -A.3. Examples of Encrypted Messages +A.5. Examples of Encrypted Messages +A.5.1. Countersignature on Encrypted Content -A.4. Examples of MACed Messages -A.5. Examples of MAC0 Messages + This example uses the following: + + * CEK: AES-GCM w/ 128-bit key + + * Countersignature algorithm: EdDSA with Curve Ed25519 + + Size of binary file is 136 bytes + + 16( + [ + / protected h'A10101' / << { + / alg / 1:1 / AES-GCM 128 / + } >>, + / unprotected / { + / iv / 5: h'02D1F7E6F26C43D4868D87CE', + / countersign / 11: [ + / protected h'A10127' / << { + / alg / 1:-8 / EdDSA with Ed25519 / + } >>, + / unprotected / { + / kid / 4: '11' + }, + / signature / h'E10439154CC75C7A3A5391491F88651E0292FD0FE0E0 + 2CF740547EAF6677B4A4040B8ECA16DB592881262F77B14C1A086C02268B17171CA1 + 6BE4B8595F8C0A08' + ] + }, + / ciphertext / h'60973A94BB2898009EE52ECFD9AB1DD25867374B162E2C0 + 3568B41F57C3CC16F9166250A' + ] + ) + +A.6. Examples of MACed Messages + +A.6.1. Countersignature on MAC Content + + This example uses the following: + + * MAC algorithm: HMAC/SHA-256 with 256-bit key + + * Countersignature algorithm: EdDSA with Curve Ed25519 + + Size of binary file is 159 bytes + 97( + [ + / protected h'A10105' / << { + / alg / 1:5 / HS256 / + } >>, + / unprotected / { + / countersign / 11: [ + / protected h'A10127' / << { + / alg / 1:-8 / EdDSA / + } >>, + / unprotected / { + / kid / 4: '11' + }, + / signature / h'602566F4A311DC860740D2DF54D4864555E85BC036EA + 5A6CF7905B96E499C5F66B01C4997F6A20C37C37543ADEA1D705347D38A5B13594B2 + 9583DD741F455101' + ] + }, + / payload / 'This is the content.', + / tag / h'2BDCC89F058216B8A208DDC6D8B54AA91F48BD63484986565105C9 + AD5A6682F6', + / recipients / [ + [ + / protected / h'', + / unprotected / { + / alg / 1: -6, / direct / + / kid / 4: 'our-secret' + }, + / ciphertext / h'' + ] + ] + ] + ) + +A.7. Examples of MAC0 Messages + +A.7.1. Countersignature on MAC0 Content + + This example uses the following: + + * MAC algorithm: HMAC/SHA-256 with 256-bit key + + * Countersignature algorithm: EdDSA with Curve Ed25519 + + Size of binary file is 159 bytes + 17( + [ + / protected h'A10105' / << { + / alg / 1:5 / HS256 / + } >>, + / unprotected / { + / countersign / 11: [ + / protected h'A10127' / << { + / alg / 1:-8 / EdDSA / + } >>, + / unprotected / { + / kid / 4: '11' + }, + / signature / h'968A315DF6B4F26362E11F4CFD2F2F4E76232F39657B + F1598837FF9332CDDD7581E248116549451F81EF823DA5974F885B681D3D6E38FC41 + 42D8F8E9E7DC8F0D' + ] + }, + / payload / 'This is the content.', + / tag / h'A1A848D3471F9D61EE49018D244C824772F223AD4F935293F1789F + C3A08D8C58' + ] + ) Acknowledgments This document is a product of the COSE working group of the IETF. The initial version of the specification was based to some degree on the outputs of the JOSE and S/MIME working groups. Jim Schaad passed on 3 October 2020. This document is primarily his work. Russ Housley served as the document editor after Jim's untimely death, mostly helping with the approval and publication processes. Jim deserves all credit for the technical content. + Jim Schaad and Jonathan Hammell provided the examples in the + Appendix. + {{{ RFC EDITOR: Please remove Russ Housley as an author of this document at publication. Jim Schaad should be listed as the sole author. }}} Authors' Addresses Jim Schaad August Cellars - Email: ietf@augustcellars.com Russ Housley (editor) Vigil Security, LLC Email: housley@vigilsec.com