draft-ietf-cose-rfc8152bis-struct-11.txt   draft-ietf-cose-rfc8152bis-struct-12.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) 1 July 2020 Obsoletes: 8152 (if approved) 24 August 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 2 January 2021 Expires: 25 February 2021
CBOR Object Signing and Encryption (COSE): Structures and Process CBOR Object Signing and Encryption (COSE): Structures and Process
draft-ietf-cose-rfc8152bis-struct-11 draft-ietf-cose-rfc8152bis-struct-12
Abstract Abstract
Concise Binary Object Representation (CBOR) is a data format designed Concise Binary Object Representation (CBOR) is a data format designed
for small code size and small message size. There is a need for the 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. ability to have basic security services defined for this data format.
This document defines the CBOR Object Signing and Encryption (COSE) This document defines the CBOR Object Signing and Encryption (COSE)
protocol. This specification describes how to create and process protocol. This specification describes how to create and process
signatures, message authentication codes, and encryption using CBOR signatures, message authentication codes, and encryption using CBOR
for serialization. This specification additionally describes how to for serialization. This specification additionally describes how to
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 January 2021. This Internet-Draft will expire on 25 February 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 27
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 6 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 6
1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 6 1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 6
1.3. Design Changes from JOSE . . . . . . . . . . . . . . . . 6 1.3. Design Changes from JOSE . . . . . . . . . . . . . . . . 6
1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 7 1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 7
1.5. CBOR-Related Terminology . . . . . . . . . . . . . . . . 8 1.5. CBOR-Related Terminology . . . . . . . . . . . . . . . . 9
1.6. Document Terminology . . . . . . . . . . . . . . . . . . 9 1.6. Document Terminology . . . . . . . . . . . . . . . . . . 9
2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 9 2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 10
3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 13 3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Common COSE Header Parameters . . . . . . . . . . . . . . 15 3.1. Common COSE Header Parameters . . . . . . . . . . . . . . 16
4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 18 4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Signing with One or More Signers . . . . . . . . . . . . 18 4.1. Signing with One or More Signers . . . . . . . . . . . . 20
4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 20 4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 22
4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 21 4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 23
4.4. Signing and Verification Process . . . . . . . . . . . . 22 4.4. Signing and Verification Process . . . . . . . . . . . . 24
5. Counter Signatures . . . . . . . . . . . . . . . . . . . . . 25 5. Version 2 Countersignatures . . . . . . . . . . . . . . . . . 27
5.1. Full Counter Signatures . . . . . . . . . . . . . . . . . 26 5.1. Full Countersignatures . . . . . . . . . . . . . . . . . 28
5.2. Abbreviated Counter Signatures . . . . . . . . . . . . . 26 5.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 29
6. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 27 5.3. Signing and Verification Process . . . . . . . . . . . . 29
6.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 27 6. Countersignatures . . . . . . . . . . . . . . . . . . . . . . 32
6.1.1. Content Key Distribution Methods . . . . . . . . . . 29 6.1. Full Countersignatures . . . . . . . . . . . . . . . . . 33
6.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 30 6.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 34
6.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 30 7. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 35
6.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 33 7.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 35
7. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1.1. Content Key Distribution Methods . . . . . . . . . . 37
7.1. MACed Message with Recipients . . . . . . . . . . . . . . 35 7.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 37
7.2. MACed Messages with Implicit Key . . . . . . . . . . . . 36 7.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 38
7.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 36 7.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 40
8. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 38 8.1. MACed Message with Recipients . . . . . . . . . . . . . . 42
8.2. MACed Messages with Implicit Key . . . . . . . . . . . . 43
9. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 41 8.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 44
9.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 42 9. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.2. Message Authentication Code (MAC) Algorithms . . . . . . 43 9.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 46
9.3. Content Encryption Algorithms . . . . . . . . . . . . . . 43 10. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 49
9.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 44 10.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 50
9.5. Content Key Distribution Methods . . . . . . . . . . . . 45 10.2. Message Authentication Code (MAC) Algorithms . . . . . . 51
9.5.1. Direct Encryption . . . . . . . . . . . . . . . . . . 45 10.3. Content Encryption Algorithms . . . . . . . . . . . . . 51
9.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 45 10.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . 52
9.5.3. Key Transport . . . . . . . . . . . . . . . . . . . . 46 10.5. Content Key Distribution Methods . . . . . . . . . . . . 53
9.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 46 10.5.1. Direct Encryption . . . . . . . . . . . . . . . . . 53
9.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . . 47 10.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 53
10. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 48 10.5.3. Key Transport . . . . . . . . . . . . . . . . . . . 54
11. Application Profiling Considerations . . . . . . . . . . . . 48 10.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 54
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 10.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . 55
12.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . 50 11. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 56
12.2. COSE Header Parameters Registry . . . . . . . . . . . . 50 12. Application Profiling Considerations . . . . . . . . . . . . 56
12.3. COSE Key Common Parameters Registry . . . . . . . . . . 50 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
12.4. Media Type Registrations . . . . . . . . . . . . . . . . 50 13.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . 58
12.4.1. COSE Security Message . . . . . . . . . . . . . . . 51 13.2. COSE Header Parameters Registry . . . . . . . . . . . . 58
12.4.2. COSE Key Media Type . . . . . . . . . . . . . . . . 52 13.3. COSE Key Common Parameters Registry . . . . . . . . . . 59
12.5. CoAP Content-Formats Registry . . . . . . . . . . . . . 54 13.4. Media Type Registrations . . . . . . . . . . . . . . . . 59
12.6. Expert Review Instructions . . . . . . . . . . . . . . . 54 13.4.1. COSE Security Message . . . . . . . . . . . . . . . 59
13. Security Considerations . . . . . . . . . . . . . . . . . . . 55 13.4.2. COSE Key Media Type . . . . . . . . . . . . . . . . 60
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 56 13.5. CoAP Content-Formats Registry . . . . . . . . . . . . . 62
14.1. Author's Versions . . . . . . . . . . . . . . . . . . . 57 13.6. Expert Review Instructions . . . . . . . . . . . . . . . 62
14.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 58 14. Security Considerations . . . . . . . . . . . . . . . . . . . 63
14.3. Python Version . . . . . . . . . . . . . . . . . . . . . 58 15. Implementation Status . . . . . . . . . . . . . . . . . . . . 65
14.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 58 15.1. Author's Versions . . . . . . . . . . . . . . . . . . . 65
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 15.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 66
15.1. Normative References . . . . . . . . . . . . . . . . . . 59 15.3. Python Version . . . . . . . . . . . . . . . . . . . . . 66
15.2. Informative References . . . . . . . . . . . . . . . . . 59 15.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 67
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
16.1. Normative References . . . . . . . . . . . . . . . . . . 67
16.2. Informative References . . . . . . . . . . . . . . . . . 68
Appendix A. Guidelines for External Data Authentication of Appendix A. Guidelines for External Data Authentication of
Algorithms . . . . . . . . . . . . . . . . . . . . . . . 63 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 71
Appendix B. Two Layers of Recipient Information . . . . . . . . 66 Appendix B. Two Layers of Recipient Information . . . . . . . . 75
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 68 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 76
C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 69 C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 77
C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 69 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 77
C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 70 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 78
C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 71 C.1.3. Countersignature . . . . . . . . . . . . . . . . . . 79
C.1.4. Signature with Criticality . . . . . . . . . . . . . 72 C.1.4. Signature with Criticality . . . . . . . . . . . . . 80
C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 73 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 81
C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 73 C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 81
C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 74 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 82
C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 74 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 82
C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 75 C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 83
C.3.3. Counter Signature on Encrypted Content . . . . . . . 76 C.3.3. Countersignature on Encrypted Content . . . . . . . . 84
C.3.4. Encrypted Content with External Data . . . . . . . . 77 C.3.4. Encrypted Content with External Data . . . . . . . . 85
C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 78 C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 86
C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 78 C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 86
C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 79 C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 87
C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 79 C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 87
C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 79 C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 87
C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 80 C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 88
C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 81 C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 89
C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 82 C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 90
C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 83 C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 91
C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 83 C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 91
C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 84 C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 92
C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 84 C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 92
C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 85 C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 93
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 95
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
There has been an increased focus on small, constrained devices that There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT). One of the standards that has make up the Internet of Things (IoT). One of the standards that has
come out of this process is "Concise Binary Object Representation come out of this process is "Concise Binary Object Representation
(CBOR)" [RFC7049]. CBOR extended the data model of the JavaScript (CBOR)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the
Object Notation (JSON) [STD90] by allowing for binary data, among JavaScript Object Notation (JSON) [STD90] by allowing for binary
other changes. CBOR has been adopted by several of the IETF working data, among other changes. CBOR has been adopted by several of the
groups dealing with the IoT world as their encoding of data IETF working groups dealing with the IoT world as their encoding of
structures. CBOR was designed specifically both to be small in terms data structures. CBOR was designed specifically both to be small in
of messages transported and implementation size and to be a schema- terms of messages transported and implementation size and to be a
free decoder. A need exists to provide message security services for schema-free decoder. A need exists to provide message security
IoT, and using CBOR as the message-encoding format makes sense. services for IoT, and using CBOR as the message-encoding format makes
sense.
The JOSE working group produced a set of documents [RFC7515] The JOSE working group produced a set of documents [RFC7515]
[RFC7516] [RFC7517] [RFC7518] that specified how to process [RFC7516] [RFC7517] [RFC7518] that specified how to process
encryption, signatures, and Message Authentication Code (MAC) encryption, signatures, and Message Authentication Code (MAC)
operations and how to encode keys using JSON. This document along operations and how to encode keys using JSON. This document defines
with [I-D.ietf-cose-rfc8152bis-algs] defines the CBOR Object Signing the CBOR Object Signing and Encryption (COSE) standard, which does
and Encryption (COSE) standard, which does the same thing for the the same thing for the CBOR encoding format. This document is
CBOR encoding format. While there is a strong attempt to keep the combined with [I-D.ietf-cose-rfc8152bis-algs] which provides an
flavor of the original JSON Object Signing and Encryption (JOSE) initial set of algorithms. While there is a strong attempt to keep
the flavor of the original JSON Object Signing and Encryption (JOSE)
documents, two considerations are taken into account: documents, two considerations are taken into account:
* CBOR has capabilities that are not present in JSON and are * CBOR has capabilities that are not present in JSON and are
appropriate to use. One example of this is the fact that CBOR has appropriate to use. One example of this is the fact that CBOR has
a method of encoding binary directly without first converting it a method of encoding binary directly without first converting it
into a base64-encoded text string. into a base64-encoded text string.
* COSE is not a direct copy of the JOSE specification. In the * COSE is not a direct copy of the JOSE specification. In the
process of creating COSE, decisions that were made for JOSE were process of creating COSE, decisions that were made for JOSE were
re-examined. In many cases, different results were decided on as re-examined. In many cases, different results were decided on as
skipping to change at page 5, line 36 skipping to change at page 5, line 46
[RFC8613] and [I-D.ietf-core-groupcomm-bis]. However, COSE is not [RFC8613] and [I-D.ietf-core-groupcomm-bis]. However, COSE is not
restricted to just these cases and can be used in any place where one restricted to just these cases and can be used in any place where one
would consider either JOSE or CMS [RFC5652] for the purpose of would consider either JOSE or CMS [RFC5652] for the purpose of
providing security services. The use of COSE, like JOSE and CMS, is providing security services. The use of COSE, like JOSE and CMS, is
only for use in store and forward or offline protocols. The use of only for use in store and forward or offline protocols. The use of
COSE in online protocols needing encryption, require that an online COSE in online protocols needing encryption, require that an online
key establishment process be done before sending objects back and key establishment process be done before sending objects back and
forth. Any application which uses COSE for security services first forth. Any application which uses COSE for security services first
needs to determine what security services are required and then needs to determine what security services are required and then
select the appropriate COSE structures and cryptographic algorithms select the appropriate COSE structures and cryptographic algorithms
based on those needs. Section 11 provides additional information on based on those needs. Section 12 provides additional information on
what applications need to specify when using COSE. what applications need to specify when using COSE.
One feature that is present in CMS that is not present in this One feature that is present in CMS that is not present in this
standard is a digest structure. This omission is deliberate. It is standard is a digest structure. This omission is deliberate. It is
better for the structure to be defined in each protocol as different better for the structure to be defined in each protocol as different
protocols will want to include a different set of fields as part of protocols will want to include a different set of fields as part of
the structure. While an algorithm identifier and the digest value the structure. While an algorithm identifier and the digest value
are going to be common to all applications, the two values may not are going to be common to all applications, the two values may not
always be adjacent as the algorithm could be defined once with always be adjacent as the algorithm could be defined once with
multiple values. Applications may additionally want to define multiple values. Applications may additionally want to define
skipping to change at page 6, line 21 skipping to change at page 6, line 30
capitals, as shown here. capitals, as shown here.
1.2. Changes from RFC8152 1.2. Changes from RFC8152
* Split the original document into this document and * Split the original document into this document and
[I-D.ietf-cose-rfc8152bis-algs]. [I-D.ietf-cose-rfc8152bis-algs].
* Add some text describing why there is no digest structure defined * Add some text describing why there is no digest structure defined
by COSE. by COSE.
* Rearrange the text around counter signatures and define a CBOR Tag * Rearrange the text around countersignatures and define a CBOR Tag
for a standalone counter signature. for a standalone countersignature.
* Text clarifications and changes in terminology. * Text clarifications and changes in terminology.
* A new countersignature computation algorithm has been defined and
the old one deprecrated. This includes defining new header
parameters for the new countersignature values.
1.3. Design Changes from JOSE 1.3. Design Changes from JOSE
* Define a single overall message structure so that encrypted, * Define a single overall message structure so that encrypted,
signed, and MACed messages can easily be identified and still have signed, and MACed messages can easily be identified and still have
a consistent view. a consistent view.
* Signed messages distinguish between the protected and unprotected * Signed messages distinguish between the protected and unprotected
header parameters that relate to the content and those that relate header parameters that relate to the content and those that relate
to the signature. to the signature.
skipping to change at page 8, line 44 skipping to change at page 9, line 16
In JSON, maps are called objects and only have one kind of map key: a In JSON, maps are called objects and only have one kind of map key: a
text string. In COSE, we use text strings, negative integers, and text string. In COSE, we use text strings, negative integers, and
unsigned integers as map keys. The integers are used for compactness unsigned integers as map keys. The integers are used for compactness
of encoding and easy comparison. The inclusion of text strings of encoding and easy comparison. The inclusion of text strings
allows for an additional range of short encoded values to be used as allows for an additional range of short encoded values to be used as
well. Since the word "key" is mainly used in its other meaning, as a well. Since the word "key" is mainly used in its other meaning, as a
cryptographic key, we use the term "label" for this usage as a map cryptographic key, we use the term "label" for this usage as a map
key. key.
The presence a label that is neither a a text string bor an integer, The presence a label that is neither a a text string or an integer,
in a CBOR map, is an error. Applications can either fail processing in a CBOR map, is an error. Applications can either fail processing
or process messages by ignoring incorrect labels; however, they MUST or process messages by ignoring incorrect labels; however, they MUST
NOT create messages with incorrect labels. NOT create messages with incorrect labels.
A CDDL grammar fragment defines the non-terminal 'label', as in the A CDDL grammar fragment defines the non-terminal 'label', as in the
previous paragraph, and 'values', which permits any value to be used. previous paragraph, and 'values', which permits any value to be used.
label = int / tstr label = int / tstr
values = any values = any
skipping to change at page 10, line 17 skipping to change at page 10, line 35
3. The content of the message. The content is either the plaintext 3. The content of the message. The content is either the plaintext
or the ciphertext as appropriate. The content may be detached or the ciphertext as appropriate. The content may be detached
(i.e. transported separately from the COSE structure), but the (i.e. transported separately from the COSE structure), but the
location is still used. The content is wrapped in a bstr when location is still used. The content is wrapped in a bstr when
present and is a nil value when detached. present and is a nil value when detached.
Elements after this point are dependent on the specific message type. Elements after this point are dependent on the specific message type.
COSE messages are built using the concept of layers to separate COSE messages are built using the concept of layers to separate
different types of cryptographic concepts. As an example of how this different types of cryptographic concepts. As an example of how this
works, consider the COSE_Encrypt message (Section 6.1). This message works, consider the COSE_Encrypt message (Section 7.1). This message
type is broken into two layers: the content layer and the recipient type is broken into two layers: the content layer and the recipient
layer. The content layer contains the plaintext is encrypted and layer. The content layer contains the plaintext is encrypted and
information about the encrypted message. The recipient layer contins information about the encrypted message. The recipient layer contins
the content encryption key (CEK) is encrypted and information about the content encryption key (CEK) is encrypted and information about
how it is encrypted for each recipient. A single layer version of how it is encrypted for each recipient. A single layer version of
the encryption message COSE_Encrypt0 (Section 6.2) is provided for the encryption message COSE_Encrypt0 (Section 7.2) is provided for
cases where the CEK is pre-shared. cases where the CEK is pre-shared.
Identification of which type of message has been presented is done by Identification of which type of message has been presented is done by
the following methods: the following methods:
1. The specific message type is known from the context. This may be 1. The specific message type is known from the context. This may be
defined by a marker in the containing structure or by defined by a marker in the containing structure or by
restrictions specified by the application protocol. restrictions specified by the application protocol.
2. The message type is identified by a CBOR tag. Messages with a 2. The message type is identified by a CBOR tag. Messages with a
skipping to change at page 10, line 46 skipping to change at page 11, line 18
This document defines a CBOR tag for each of the message This document defines a CBOR tag for each of the message
structures. These tags can be found in Table 1. structures. These tags can be found in Table 1.
3. When a COSE object is carried in a media type of 'application/ 3. When a COSE object is carried in a media type of 'application/
cose', the optional parameter 'cose-type' can be used to identify cose', the optional parameter 'cose-type' can be used to identify
the embedded object. The parameter is OPTIONAL if the tagged the embedded object. The parameter is OPTIONAL if the tagged
version of the structure is used. The parameter is REQUIRED if version of the structure is used. The parameter is REQUIRED if
the untagged version of the structure is used. The value to use the untagged version of the structure is used. The value to use
with the parameter for each of the structures can be found in with the parameter for each of the structures can be found in
Table 1. Table 1.
// QUESTION: Given that V1 countersign is deprecated, do we need
a
// tag for that purpose?
//
// -- JLS
4. When a COSE object is carried as a CoAP payload, the CoAP 4. When a COSE object is carried as a CoAP payload, the CoAP
Content-Format Option can be used to identify the message Content-Format Option can be used to identify the message
content. The CoAP Content-Format values can be found in Table 2. content. The CoAP Content-Format values can be found in Table 2.
The CBOR tag for the message structure is not required as each The CBOR tag for the message structure is not required as each
security message is uniquely identified. security message is uniquely identified.
+=======+==================+=======================+=============+ +=====+==================+=======================+==================+
| CBOR | cose-type | Data Item | Semantics | |CBOR | cose-type | Data Item | Semantics |
| Tag | | | | | Tag | | | |
+=======+==================+=======================+=============+ +=====+==================+=======================+==================+
| 98 | cose-sign | COSE_Sign | COSE Signed | | 98 | cose-sign | COSE_Sign | COSE Signed Data |
| | | | Data Object | | | | | Object |
+-------+------------------+-----------------------+-------------+ +-----+------------------+-----------------------+------------------+
| 18 | cose-sign1 | COSE_Sign1 | COSE Single | | 18 | cose-sign1 | COSE_Sign1 |COSE Single Signer|
| | | | Signer Data | | | | | Data Object |
| | | | Object | +-----+------------------+-----------------------+------------------+
+-------+------------------+-----------------------+-------------+ | 96 | cose-encrypt | COSE_Encrypt | COSE Encrypted |
| 96 | cose-encrypt | COSE_Encrypt | COSE | | | | | Data Object |
| | | | Encrypted | +-----+------------------+-----------------------+------------------+
| | | | Data Object | | 16 | cose-encrypt0 | COSE_Encrypt0 | COSE Single |
+-------+------------------+-----------------------+-------------+ | | | | Recipient |
| 16 | cose-encrypt0 | COSE_Encrypt0 | COSE Single | | | | | Encrypted Data |
| | | | Recipient | | | | | Object |
| | | | Encrypted | +-----+------------------+-----------------------+------------------+
| | | | Data Object | | 97 | cose-mac | COSE_Mac | COSE MACed Data |
+-------+------------------+-----------------------+-------------+ | | | | Object |
| 97 | cose-mac | COSE_Mac | COSE MACed | +-----+------------------+-----------------------+------------------+
| | | | Data Object | | 17 | cose-mac0 | COSE_Mac0 | COSE Mac w/o |
+-------+------------------+-----------------------+-------------+ | | | |Recipients Object |
| 17 | cose-mac0 | COSE_Mac0 | COSE Mac w/ | +-----+------------------+-----------------------+------------------+
| | | | o | |TBD00| cose-countersign | COSE_Countersignature |COSE standalone V2|
| | | | Recipients | | | | | countersignature |
| | | | Object | +-----+------------------+-----------------------+------------------+
+-------+------------------+-----------------------+-------------+
| TBD00 | cose-countersign | COSE_Countersignature | COSE |
| | | | standalone |
| | | | counter |
| | | | signature |
+-------+------------------+-----------------------+-------------+
Table 1: COSE Message Identification Table 1: COSE Message Identification
+===========================+==========+=====+============+ +===========================+==========+=====+============+
| Media Type | Encoding | ID | Reference | | Media Type | Encoding | ID | Reference |
+===========================+==========+=====+============+ +===========================+==========+=====+============+
| application/cose; cose- | | 98 | [[THIS | | application/cose; cose- | | 98 | [[THIS |
| type="cose-sign" | | | DOCUMENT]] | | type="cose-sign" | | | DOCUMENT]] |
+---------------------------+----------+-----+------------+ +---------------------------+----------+-----+------------+
| application/cose; cose- | | 18 | [[THIS | | application/cose; cose- | | 18 | [[THIS |
| type="cose-sign1" | | | DOCUMENT]] | | type="cose-sign1" | | | DOCUMENT]] |
+---------------------------+----------+-----+------------+ +---------------------------+----------+-----+------------+
skipping to change at page 13, line 25 skipping to change at page 14, line 25
recipient structures do not provide for authenticated data. If this recipient structures do not provide for authenticated data. If this
is the case, the protected bucket is left empty. is the case, the protected bucket is left empty.
Both buckets are implemented as CBOR maps. The map key is a 'label' Both buckets are implemented as CBOR maps. The map key is a 'label'
(Section 1.5). The value portion is dependent on the definition for (Section 1.5). The value portion is dependent on the definition for
the label. Both maps use the same set of label/value pairs. The the label. Both maps use the same set of label/value pairs. The
integer and text string values for labels have been divided into integer and text string values for labels have been divided into
several sections including a standard range, a private range, and a several sections including a standard range, a private range, and a
range that is dependent on the algorithm selected. The defined range that is dependent on the algorithm selected. The defined
labels can be found in the "COSE Header Parameters" IANA registry labels can be found in the "COSE Header Parameters" IANA registry
(Section 12.2). (Section 13.2).
The two buckets are: The two buckets are:
protected: Contains parameters about the current layer that are protected: Contains parameters about the current layer that are
cryptographically protected. This bucket MUST be empty if it is cryptographically protected. This bucket MUST be empty if it is
not going to be included in a cryptographic computation. This not going to be included in a cryptographic computation. This
bucket is encoded in the message as a binary object. This value bucket is encoded in the message as a binary object. This value
is obtained by CBOR encoding the protected map and wrapping it in is obtained by CBOR encoding the protected map and wrapping it in
a bstr object. Senders SHOULD encode a zero-length map as a zero- a bstr object. Senders SHOULD encode a zero-length map as a zero-
length byte string rather than as a zero-length map (encoded as length byte string rather than as a zero-length map (encoded as
skipping to change at page 14, line 20 skipping to change at page 15, line 20
In principle, one should be able to process any given layer without In principle, one should be able to process any given layer without
reference to any other layer. With the exception of the COSE_Sign reference to any other layer. With the exception of the COSE_Sign
structure, the only data that needs to cross layers is the structure, the only data that needs to cross layers is the
cryptographic key. cryptographic key.
The buckets are present in all of the security objects defined in The buckets are present in all of the security objects defined in
this document. The fields in order are the 'protected' bucket (as a this document. The fields in order are the 'protected' bucket (as a
CBOR 'bstr' type) and then the 'unprotected' bucket (as a CBOR 'map' CBOR 'bstr' type) and then the 'unprotected' bucket (as a CBOR 'map'
type). The presence of both buckets is required. The header type). The presence of both buckets is required. The header
parameters that go into the buckets come from the IANA "COSE Header parameters that go into the buckets come from the IANA "COSE Header
Parameters" registry (Section 12.2). Some header parameters are Parameters" registry (Section 13.2). Some header parameters are
defined in the next section. defined in the next section.
Labels in each of the maps MUST be unique. When processing messages, Labels in each of the maps MUST be unique. When processing messages,
if a label appears multiple times, the message MUST be rejected as if a label appears multiple times, the message MUST be rejected as
malformed. Applications SHOULD verify that the same label does not malformed. Applications SHOULD verify that the same label does not
occur in both the protected and unprotected header parameters. If occur in both the protected and unprotected header parameters. If
the message is not rejected as malformed, attributes MUST be obtained the message is not rejected as malformed, attributes MUST be obtained
from the protected bucket, and only if not found are attributes from the protected bucket, and only if not found are attributes
obtained from the unprotected bucket. obtained from the unprotected bucket.
skipping to change at page 17, line 12 skipping to change at page 18, line 12
'Initialization Vector' and 'Partial Initialization Vector' header 'Initialization Vector' and 'Partial Initialization Vector' header
parameters MUST NOT both be present in the same security layer. parameters MUST NOT both be present in the same security layer.
The message IV is generated by the following steps: The message IV is generated by the following steps:
1. Left-pad the Partial IV with zeros to the length of IV 1. Left-pad the Partial IV with zeros to the length of IV
(determined by the algorithm). (determined by the algorithm).
2. XOR the padded Partial IV with the context IV. 2. XOR the padded Partial IV with the context IV.
counter signature: This header parameter holds one or more counter countersignature: This header parameter holds one or more
signature values. Counter signatures provide a method of having a countersignature values. Countersignatures provide a method of
second party sign some data. The counter signature header having a second party sign some data. The countersignature header
parameter can occur as an unprotected attribute in any of the parameter can occur as an unprotected attribute in any of the
following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt,
COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. These COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. These
structures all have the same beginning elements, so that a structures all have the same beginning elements, so that a
consistent calculation of the counter signature can be computed. consistent calculation of the countersignature can be computed.
Details on counter signatures are found in Section 5. Details on countersignatures are found in Section 6. This header
parameter has been deprecated in favor of the V2 countersignature.
+=========+=====+================+=================+================+ V2 countersignature: This header parameter holds one or more
| Name |Label| Value Type | Value Registry | Description | countersignature values. Countersignatures provide a method of
+=========+=====+================+=================+================+ having a second party sign some data. The countersignature header
| alg | 1 | int / tstr | COSE Algorithms | Cryptographic | parameter can occur as an unprotected attribute in any of the
| | | | registry |algorithm to use| following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt,
+---------+-----+----------------+-----------------+----------------+ COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. Details
| crit | 2 | [+ label] | COSE Header |Critical header | on version 2 countersignatures are found in Section 5.
| | | | Parameters |parameters to be|
| | | | registry | understood | +=========+=====+========================+==========+===============+
+---------+-----+----------------+-----------------+----------------+ | Name |Label| Value Type | Value | Description |
| content | 3 | tstr / uint | CoAP Content- |Content type of | | | | | Registry | |
| type | | |Formats or Media | the payload | +=========+=====+========================+==========+===============+
| | | |Types registries | | | alg | 1 | int / tstr | COSE | Cryptographic |
+---------+-----+----------------+-----------------+----------------+ | | | |Algorithms| algorithm to |
| kid | 4 | bstr | | Key identifier | | | | | registry | use |
+---------+-----+----------------+-----------------+----------------+ +---------+-----+------------------------+----------+---------------+
| IV | 5 | bstr | | Full | | crit | 2 | [+ label] | COSE |Critical header|
| | | | | Initialization | | | | | Header | parameters to |
| | | | | Vector | | | | |Parameters| be understood |
+---------+-----+----------------+-----------------+----------------+ | | | | registry | |
| Partial | 6 | bstr | | Partial | +---------+-----+------------------------+----------+---------------+
| IV | | | | Initialization | | content | 3 | tstr / uint | CoAP |Content type of|
| | | | | Vector | | type | | | Content- | the payload |
+---------+-----+----------------+-----------------+----------------+ | | | |Formats or| |
| counter | 7 |COSE_Signature /| | CBOR-encoded | | | | | Media | |
|signature| | [+ | | signature | | | | | Types | |
| | |COSE_Signature ]| | structure | | | | |registries| |
+---------+-----+----------------+-----------------+----------------+ +---------+-----+------------------------+----------+---------------+
| kid | 4 | bstr | |Key identifier |
+---------+-----+------------------------+----------+---------------+
| IV | 5 | bstr | | Full |
| | | | |Initialization |
| | | | | Vector |
+---------+-----+------------------------+----------+---------------+
| Partial | 6 | bstr | | Partial |
| IV | | | |Initialization |
| | | | | Vector |
+---------+-----+------------------------+----------+---------------+
| counter | 7 | COSE_Signature / [+ | | CBOR-encoded |
|signature| | COSE_Signature ] | | signature |
| | | | | structure |
| | | | | (Deprecated) |
+---------+-----+------------------------+----------+---------------+
| counter |TBD10|COSE_Countersignature / | | V2 counter |
|signature| |[+ COSE_Countersignature| | signature |
|version 2| | ] | | attribute |
+---------+-----+------------------------+----------+---------------+
| counter |TBD11| COSE_Countersignature0 | | Abbreviated |
|signature| | | | Counter |
|0 version| | | | signature |
| 2 | | | | vesion 2 |
+---------+-----+------------------------+----------+---------------+
Table 3: Common Header Parameters Table 3: Common Header Parameters
The CDDL fragment that represents the set of header parameters The CDDL fragment that represents the set of header parameters
defined in this section is given below. Each of the header defined in this section is given below. Each of the header
parameters is tagged as optional because they do not need to be in parameters is tagged as optional because they do not need to be in
every map; header parameters required in specific maps are discussed every map; header parameters required in specific maps are discussed
above. above.
Generic_Headers = ( Generic_Headers = (
? 1 => int / tstr, ; algorithm identifier ? 1 => int / tstr, ; algorithm identifier
? 2 => [+label], ; criticality ? 2 => [+label], ; criticality
? 3 => tstr / int, ; content type ? 3 => tstr / int, ; content type
? 4 => bstr, ; key identifier ? 4 => bstr, ; key identifier
? 5 => bstr, ; IV ? 5 => bstr, ; IV
? 6 => bstr, ; Partial IV ? 6 => bstr, ; Partial IV
? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature ? 7 => COSE_Signature / [+COSE_Signature] ; Countersignature
? TBD10 => COSE_Countersignature / [+COSE_Countersignature]
; V2 Countersignature
? TBD11 => COSE_Countersignature0 ; V2 Countersignature0
) )
4. Signing Objects 4. Signing Objects
COSE supports two different signature structures. COSE_Sign allows COSE supports two different signature structures. COSE_Sign allows
for one or more signatures to be applied to the same content. for one or more signatures to be applied to the same content.
COSE_Sign1 is restricted to a single signer. The structures cannot COSE_Sign1 is restricted to a single signer. The structures cannot
be converted between each other; as the signature computation be converted between each other; as the signature computation
includes a parameter identifying which structure is being used, the includes a parameter identifying which structure is being used, the
converted structure will fail signature validation. converted structure will fail signature validation.
4.1. Signing with One or More Signers 4.1. Signing with One or More Signers
The COSE_Sign structure allows for one or more signatures to be The COSE_Sign structure allows for one or more signatures to be
applied to a message payload. Header parameters relating to the applied to a message payload. Header parameters relating to the
content and header parameters relating to the signature are carried content and header parameters relating to the signature are carried
along with the signature itself. These header parameters may be along with the signature itself. These header parameters may be
authenticated by the signature, or just present. An example of a authenticated by the signature, or just present. An example of a
header parameter about the content is the content type header header parameter about the content is the content type header
parameter. Examples of header parameters about the signature would parameter. Examples of header parameters about the signature would
be the algorithm and key used to create the signature and counter be the algorithm and key used to create the signature and
signatures. countersignatures.
RFC 5652 indicates that: RFC 5652 indicates that:
| When more than one signature is present, the successful validation | When more than one signature is present, the successful validation
| of one signature associated with a given signer is usually treated | of one signature associated with a given signer is usually treated
| as a successful signature by that signer. However, there are some | as a successful signature by that signer. However, there are some
| application environments where other rules are needed. An | application environments where other rules are needed. An
| application that employs a rule other than one valid signature for | application that employs a rule other than one valid signature for
| each signer must specify those rules. Also, where simple matching | each signer must specify those rules. Also, where simple matching
| of the signer identifier is not sufficient to determine whether | of the signer identifier is not sufficient to determine whether
skipping to change at page 20, line 6 skipping to change at page 21, line 50
payload: This field contains the serialized content to be signed. payload: This field contains the serialized content to be signed.
If the payload is not present in the message, the application is If the payload is not present in the message, the application is
required to supply the payload separately. The payload is wrapped required to supply the payload separately. The payload is wrapped
in a bstr to ensure that it is transported without changes. If in a bstr to ensure that it is transported without changes. If
the payload is transported separately ("detached content"), then a the payload is transported separately ("detached content"), then a
nil CBOR object is placed in this location, and it is the nil CBOR object is placed in this location, and it is the
responsibility of the application to ensure that it will be responsibility of the application to ensure that it will be
transported without changes. transported without changes.
Note: When a signature with a message recovery algorithm is used Note: When a signature with a message recovery algorithm is used
(Section 9.1), the maximum number of bytes that can be recovered (Section 10.1), the maximum number of bytes that can be recovered
is the length of the original payload. The size of the encoded is the length of the original payload. The size of the encoded
payload is reduced by the number of bytes that will be recovered. payload is reduced by the number of bytes that will be recovered.
If all of the bytes of the original payload are consumed, then the If all of the bytes of the original payload are consumed, then the
transmitted payload is encoded as a zero-length byte string rather transmitted payload is encoded as a zero-length byte string rather
than as being absent. than as being absent.
signatures: This field is an array of signatures. Each signature is signatures: This field is an array of signatures. Each signature is
represented as a COSE_Signature structure. represented as a COSE_Signature structure.
The CDDL fragment that represents the above text for COSE_Sign The CDDL fragment that represents the above text for COSE_Sign
skipping to change at page 22, line 36 skipping to change at page 24, line 36
* Applications need to ensure that the byte string is going to be * Applications need to ensure that the byte string is going to be
the same on both sides. Using options from CoAP might give a the same on both sides. Using options from CoAP might give a
problem if the same relative numbering is kept. An intermediate problem if the same relative numbering is kept. An intermediate
node could insert or remove an option, changing how the relative node could insert or remove an option, changing how the relative
number is done. An application would need to specify that the number is done. An application would need to specify that the
relative number must be re-encoded to be relative only to the relative number must be re-encoded to be relative only to the
options that are in the external data. options that are in the external data.
4.4. Signing and Verification Process 4.4. Signing and Verification Process
| QUESTION: It might make sense to strip the countersignature
| description from here and have section 6 point to section 5 for
| the description.
In order to create a signature, a well-defined byte string is needed. In order to create a signature, a well-defined byte string is needed.
The Sig_structure is used to create the canonical form. This signing The Sig_structure is used to create the canonical form. This signing
and verification process takes in the body information (COSE_Sign or and verification process takes in the body information (COSE_Sign or
COSE_Sign1), the signer information (COSE_Signature), and the COSE_Sign1), the signer information (COSE_Signature), and the
application data (external source). A Sig_structure is a CBOR array. application data (external source). A Sig_structure is a CBOR array.
The fields of the Sig_structure in order are: The fields of the Sig_structure in order are:
1. A context text string identifying the context of the signature. 1. A context text string identifying the context of the signature.
The context text string is: The context text string is:
skipping to change at page 23, line 15 skipping to change at page 25, line 18
"CounterSignature0" for signatures used as "CounterSignature0" for signatures used as
COSE_Countersignature0 structure. COSE_Countersignature0 structure.
2. The protected attributes from the body structure encoded in a 2. The protected attributes from the body structure encoded in a
bstr type. If there are no protected attributes, a zero-length bstr type. If there are no protected attributes, a zero-length
byte string is used. byte string is used.
3. The protected attributes from the signer structure encoded in a 3. The protected attributes from the signer structure encoded in a
bstr type. If there are no protected attributes, a zero-length bstr type. If there are no protected attributes, a zero-length
byte string is used. This field is omitted for the COSE_Sign1 byte string is used. This field is omitted for the COSE_Sign1
signature structure and CounterSignature0 attributes. signature structure and Countersignature0 attributes.
4. The externally supplied data from the application encoded in a 4. The externally supplied data from the application encoded in a
bstr type. If this field is not supplied, it defaults to a zero- bstr type. If this field is not supplied, it defaults to a zero-
length byte string. (See Section 4.3 for application guidance on length byte string. (See Section 4.3 for application guidance on
constructing this field.) constructing this field.)
5. The payload to be signed encoded in a bstr type. The payload is 5. The payload to be signed encoded in a bstr type. The payload is
placed here independent of how it is transported. placed here independent of how it is transported.
The CDDL fragment that describes the above text is: The CDDL fragment that describes the above text is:
skipping to change at page 24, line 8 skipping to change at page 26, line 12
1. A context string identifing the context of the signature as 1. A context string identifing the context of the signature as
above. above.
2. The protected attributes from the target structure encoded in a 2. The protected attributes from the target structure encoded in a
bstr type. If there are no protected attributes, a zero-length bstr type. If there are no protected attributes, a zero-length
byte string is used. byte string is used.
3. The protected attributes from the countersignture structure 3. The protected attributes from the countersignture structure
encoded in a bstr type. If there are no protected attributes, a encoded in a bstr type. If there are no protected attributes, a
zero-length byte string is used. This field is omitted when zero-length byte string is used. This field is omitted when
computing the CounterSignature0 attributes. computing the Countersignature0 attributes.
4. The externally supplied data from the application encoded in a 4. The externally supplied data from the application encoded in a
bstr type. If this field is not supplied, it defaults to a zero- bstr type. If this field is not supplied, it defaults to a zero-
length byte string. (See Section 4.3 for application guidance on length byte string. (See Section 4.3 for application guidance on
constructing this field.) constructing this field.)
5. The payload from the target structure encoded in a bstr type. 5. The payload from the target structure encoded in a bstr type.
The payload is placed here independent of how it is transported. The payload is placed here independent of how it is transported.
How to compute a signature: How to compute a signature:
1. Create a Sig_structure and populate it with the appropriate 1. Create a Sig_structure and populate it with the appropriate
fields. fields.
2. Create the value ToBeSigned by encoding the Sig_structure to a 2. Create the value ToBeSigned by encoding the Sig_structure to a
byte string, using the encoding described in Section 10. byte string, using the encoding described in Section 11.
3. Call the signature creation algorithm passing in K (the key to 3. Call the signature creation algorithm passing in K (the key to
sign with), alg (the algorithm to sign with), and ToBeSigned (the sign with), alg (the algorithm to sign with), and ToBeSigned (the
value to sign). value to sign).
4. Place the resulting signature value in the correct location. 4. Place the resulting signature value in the correct location.
This is the 'signature' field of the COSE_Signature, COSE_Sign1 This is the 'signature' field of the COSE_Signature, COSE_Sign1
or COSE_Countersignature structures. This is the value of the or COSE_Countersignature structures. This is the value of the
Countersignature0 attribute. Countersignature0 attribute.
The steps for verifying a signature are: The steps for verifying a signature are:
1. Create a Sig_structure and populate it with the appropriate 1. Create a Sig_structure and populate it with the appropriate
fields. fields.
2. Create the value ToBeSigned by encoding the Sig_structure to a 2. Create the value ToBeSigned by encoding the Sig_structure to a
byte string, using the encoding described in Section 10. byte string, using the encoding described in Section 11.
3. Call the signature verification algorithm passing in K (the key 3. Call the signature verification algorithm passing in K (the key
to verify with), alg (the algorithm used sign with), ToBeSigned to verify with), alg (the algorithm used sign with), ToBeSigned
(the value to sign), and sig (the signature to be verified). (the value to sign), and sig (the signature to be verified).
In addition to performing the signature verification, the application In addition to performing the signature verification, the application
performs the appropriate checks to ensure that the key is correctly performs the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the signing identity is paired with the signing identity and that the signing identity is
authorized before performing actions. authorized before performing actions.
5. Counter Signatures 5. Version 2 Countersignatures
A counter signature is normally defined as a second signature that A countersignature is normally defined as a second signature that
confirms a primary signature. A normal example of a counter confirms a primary signature. A normal example of a countersignature
signature is the signature that a notary public places on a document is the signature that a notary public places on a document as
as witnessing that you have signed the document. Thus applying a witnessing that you have signed the document. Thus applying a
counter signature to either the COSE_Signature or COSE_Sign1 objects countersignature to either the COSE_Signature or COSE_Sign1 objects
match this traditional definition. This document extends the context match this traditional definition. This document extends the context
of a counter signature to allow it to be applied to all of the of a countersignature to allow it to be applied to all of the
security structures defined. It needs to be noted that the counter security structures defined. It needs to be noted that the
signature needs to be treated as a separate operation from the countersignature needs to be treated as a separate operation from the
initial operation even if it is applied by the same user as is done initial operation even if it is applied by the same user as is done
in [I-D.ietf-core-groupcomm-bis]. in [I-D.ietf-core-groupcomm-bis].
COSE supports two different forms for counter signatures. Full COSE supports two different forms for countersignatures. Full
counter signatures use the structure COSE_Countersignature. This is countersignatures use the structure COSE_Countersignature. This is
same structure as COSE_Signature and thus it can have protected and same structure as COSE_Signature and thus it can have protected and
unprotected attributes, including chained counter signatures. unprotected attributes, including chained countersignatures.
Abbreviated counter signatures use the structure Abbreviated countersignatures use the structure
COSE_Countersignature0. This structure only contains the signature COSE_Countersignature0. This structure only contains the signature
value and nothing else. The structures cannot be converted between value and nothing else. The structures cannot be converted between
each other; as the signature computation includes a parameter each other; as the signature computation includes a parameter
identifying which structure is being used, the converted structure identifying which structure is being used, the converted structure
will fail signature validation. will fail signature validation.
The version 2 countersignature changes the algorithm used for
computing the signature from the original version Section 6. The new
version now includes the cryptographic material generated for all of
the structures rather than just for a subset.
COSE was designed for uniformity in how the data structures are COSE was designed for uniformity in how the data structures are
specified. One result of this is that for COSE one can expand the specified. One result of this is that for COSE one can expand the
concept of counter signatures beyond just the idea of signing a concept of countersignatures beyond just the idea of signing a
signature to being able to sign most of the structures without having signature to being able to sign most of the structures without having
to create a new signing layer. When creating a counter signature, to create a new signing layer. When creating a countersignature, one
one needs to be clear about the security properties that result. needs to be clear about the security properties that result. When
When done on a COSE_Signature, the normal counter signature semantics done on a COSE_Signature or COSE_Sign0, the normal countersignature
are preserved. That is the counter signature makes a statement about semantics are preserved. That is the countersignature makes a
the existence of a signature and, when used as a timestamp, a time statement about the existence of a signature and, when used as a
point at which the signature exists. When done on a COSE_Mac or a timestamp, a time point at which the signature exists. When done on
COSE_Mac0, one effectively upgrades the MAC operation to a signature a COSE_Sign, this is the same as applying a second signature to the
operation. When done on a COSE_Encrypt or COSE_Encrypt0, the payload and adding a parallel signature as a new COSE_Signature is
existence of the encrypted data is attested to. It should be noted the preferred method. When done on a COSE_Mac or COSE_Mac0, the
that there is a big difference between attesting to the encrypted payload is included as well as the MAC value. When done on a
data as opposed to attesting to the unencrypted data. If the latter COSE_Encrypt or COSE_Encrypt0, the existence of the encrypted data is
is what is desired, then one needs to apply a signature to the data attested to. It should be noted that there is a big difference
and then encrypt that. It is always possible to construct cases between attesting to the encrypted data as opposed to attesting to
where the use of two different keys will appear to result in a the unencrypted data. If the latter is what is desired, then one
successful decryption (the tag check success), but which produce two needs to apply a signature to the data and then encrypt that. It is
completely different plaintexts. This situation is not detectable by always possible to construct cases where the use of two different
a counter signature on the encrypted data. keys will appear to result in a successful decryption (the tag check
success), but which produce two completely different plaintexts.
This situation is not detectable by a countersignature on the
encrypted data.
5.1. Full Counter Signatures 5.1. Full Countersignatures
The COSE_Countersignature structure allows for the same set of The COSE_Countersignature structure allows for the same set of
capabilities as a COSE_Signature. This means that all of the capabilities as a COSE_Signature. This means that all of the
capabilities of a signature are duplicated with this structure. capabilities of a signature are duplicated with this structure.
Specifically, the counter signer does not need to be related to the Specifically, the countersigner does not need to be related to the
producer of what is being counter signed as key and algorithm producer of what is being countersigned as key and algorithm
identification can be placed in the counter signature attributes. identification can be placed in the countersignature attributes.
This also means that the counter signature can itself be counter This also means that the countersignature can itself be
signed. This is a feature required by protocols such as long-term countersigned. This is a feature required by protocols such as long-
archiving services. More information on how counter signatures is term archiving services. More information on how countersignatures
used can be found in the evidence record syntax described in is used can be found in the evidence record syntax described in
[RFC4998]. [RFC4998].
The full counter signature structure can be encoded as either tagged The full countersignature structure can be encoded as either tagged
or untagged depending on the context it is used in. A tagged or untagged depending on the context it is used in. A tagged
COSE_Countersignature structure is identified by the CBOR tag TBD0. COSE_Countersignature structure is identified by the CBOR tag TBD0.
The CDDL fragment for full counter signatures is: 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_Tagged = #6.9999(COSE_Countersignature)
COSE_Countersignature = COSE_Signature COSE_Countersignature = COSE_Signature
COSE_CounterSignature = COSE_Countersignature COSE_CounterSignature = COSE_Countersignature
The details of the fields of a counter signature can be found in The details of the fields of a countersignature can be found in
Section 4.1. The process of creating and validating abbreviated Section 4.1. The process of creating and validating abbreviated
counter signatures is defined in Section 4.4. countersignatures is defined in Section 4.4.
An example of a counter signature on a signature can be found in An example of a countersignature on a signature can be found in
Appendix C.1.3. An example of a counter signature in an encryption Appendix C.1.3. An example of a countersignature in an encryption
object can be found in Appendix C.3.3. object can be found in Appendix C.3.3.
It should be noted that only a signature algorithm with appendix (see It should be noted that only a signature algorithm with appendix (see
Section 9.1) can be used for counter signatures. This is because the Section 10.1) can be used for countersignatures. This is because the
body should be able to be processed without having to evaluate the body should be able to be processed without having to evaluate the
counter signature, and this is not possible for signature schemes countersignature, and this is not possible for signature schemes with
with message recovery. message recovery.
5.2. Abbreviated Counter Signatures 5.2. Abbreviated Countersignatures
Abbreviated counter signatures were designed primarily to deal with Abbreviated countersignatures were designed primarily to deal with
the problem of having encrypted group messaging, but still needing to the problem of having encrypted group messaging, but still needing to
know who originated the message. The objective was to keep the know who originated the message. The objective was to keep the
counter signature as small as possible while still providing the countersignature as small as possible while still providing the
needed security. For abbreviated counter signatures, there is no needed security. For abbreviated countersignatures, there is no
provision for any protected attributes related to the signing provision for any protected attributes related to the signing
operation. Instead, the parameters for computing or verifying the operation. Instead, the parameters for computing or verifying the
abbreviated counter signature are inferred from the same context used abbreviated countersignature are inferred from the same context used
to describe the encryption, signature, or MAC processing. to describe the encryption, signature, or MAC processing.
The CDDL fragment for the abbreviated counter signatures is: The CDDL fragment for the abbreviated countersignatures is:
COSE_Countersignature0 = bstr COSE_Countersignature0 = bstr
The byte string representing the signature value is placed in the The byte string representing the signature value is placed in the
CounterSignature0 attribute. This attribute is then encoded as an Countersignature0 attribute. This attribute is then encoded as an
unprotected header parameter. The attribute is defined below. unprotected header parameter. The attribute is defined below.
The process of creating and validating abbreviated counter signatures The process of creating and validating abbreviated countersignatures
is defined in Section 4.4.
5.3. Signing and Verification Process
In order to create a signature, a well-defined byte string is needed.
The Countersign_structure is used to create the canonical form. This
signing and verification process takes in countersignature target
structure, the signer information (COSE_Signature), and the
application data (external source). A Countersign_structure is a
CBOR array. The target structure of the countersignature needs to
have all of it's cryptographic functions finalized before the
computing the signature. The fields of the Countersign_structure in
order are:
1. A context text string identifying the context of the signature.
The context text string is:
"CounterSignature" for signatures using the
COSE_Countersignature structure when other_fields is absent.
"CounterSignature0" for signatures using the
COSE_Countersignature0 structure when other_fields is absent.
"CounterSignatureV2" for signatures using the
COSE_Countersignature structure when other_fields is present.
"CounterSignature0V2" for signatures using the
COSE_Countersignature0 structure when other_fields is present.
2. The protected attributes from the target structure encoded in a
bstr type. If there are no protected attributes, a zero-length
byte string is used.
3. The protected attributes from the signer structure encoded in a
bstr type. If there are no protected attributes, a zero-length
byte string is used. This field is omitted for the
Countersignature0V2 attribute.
4. The externally supplied data from the application encoded in a
bstr type. If this field is not supplied, it defaults to a zero-
length byte string. (See Section 4.3 for application guidance on
constructing this field.)
5. The payload to be signed encoded in a bstr type. The payload is
placed here independent of how it is transported.
6. If there are only two bstr fields in the target structure, this
field is omitted. The field is an array of all bstr fields after
the second. As an example, this would be an array of one element
for the COSE_Sign0 structure containing the signature value.
The CDDL fragment that describes the above text is:
Countersign_structure = [
context : "CounterSignature" / "CounterSignature0" /
"CounterSignatureV2" / "CounterSignature0V2" /,
body_protected : empty_or_serialized_map,
? sign_protected : empty_or_serialized_map,
external_aad : bstr,
payload : bstr,
? other_fields : [ + bstr ]
]
The fields of the Countersign_stucture in order are:
1. A context string identifing the context of the signature as
above.
2. The protected attributes from the target structure encoded in a
bstr type. If there are no protected attributes, a zero-length
byte string is used.
3. The protected attributes from the countersignture structure
encoded in a bstr type. If there are no protected attributes, a
zero-length byte string is used. This field is omitted when
computing the Countersignature0 attributes.
4. The externally supplied data from the application encoded in a
bstr type. If this field is not supplied, it defaults to a zero-
length byte string. (See Section 4.3 for application guidance on
constructing this field.)
5. The payload from the target structure encoded in a bstr type.
The payload is placed here independent of how it is transported.
6. An array of bstr types. The other_fields field is placed here
only if there are more than two bstr elements in the target
structure.
How to compute a countersignature:
1. Create a Countersign_structure and populate it with the
appropriate fields.
2. Create the value ToBeSigned by encoding the Countersign_structure
to a byte string, using the encoding described in Section 11.
3. Call the signature creation algorithm passing in K (the key to
sign with), alg (the algorithm to sign with), and ToBeSigned (the
value to sign).
4. Place the resulting signature value in the correct location.
This is the 'signature' field of the COSE_Countersignature
structure. This is the value of the Countersignature0 attribute.
The steps for verifying a countersignature are:
1. Create a Countersign_structure and populate it with the
appropriate fields.
2. Create the value ToBeSigned by encoding the Countersign_structure
to a byte string, using the encoding described in Section 11.
3. Call the signature verification algorithm passing in K (the key
to verify with), alg (the algorithm used sign with), ToBeSigned
(the value to sign), and sig (the signature to be verified).
In addition to performing the signature verification, the application
performs the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the signing identity is
authorized before performing actions.
6. Countersignatures
| QUESTION: Should we move this to an appendix?
| NOTE: This version of the countersignature has been deprecated and
| replaced by the version of countersigning in Section 5. Care was
| taking in designing the replacement version so that
| countersignatures on COSE_Sign, COSE_Signature, COSE_Encrypt,
| COSE_Encrypt0, COSE_Countersignature will generate the same
| cryptographic value. This means that when appearing as an
| unprotected attribute, the label can simply be changed from 7 to
| TBD10. The replacement version was done so that the cryptographic
| components of the COSE_Sign0, COSE_Mac and COSE_Mac0 are included
| in the countersignature value.
| QUESTION: Much of this descriptive text can be whacked if the
| V2 version is in this document as it just duplicates what is
| there.
A countersignature is normally defined as a second signature that
confirms a primary signature. A normal example of a countersignature
is the signature that a notary public places on a document as
witnessing that you have signed the document. Thus applying a
countersignature to the COSE_Signature object match this traditional
definition. This document extends the context of a countersignature
to allow it to be applied to all of the security structures defined.
It needs to be noted that the countersignature needs to be treated as
a separate operation from the initial operation even if it is applied
by the same user as is done in [I-D.ietf-core-groupcomm-bis].
COSE supports two different forms for countersignatures. Full
countersignatures use the structure COSE_Countersignature. This is
same structure as COSE_Signature and thus it can have protected and
unprotected attributes, including chained countersignatures.
Abbreviated countersignatures use the structure
COSE_Countersignature0. This structure only contains the signature
value and nothing else. The structures cannot be converted between
each other; as the signature computation includes a parameter
identifying which structure is being used, the converted structure
will fail signature validation.
COSE was designed for uniformity in how the data structures are
specified. One result of this is that for COSE one can expand the
concept of countersignatures beyond just the idea of signing a
signature to being able to sign most of the structures without having
to create a new signing layer. When creating a countersignature, one
needs to be clear about the security properties that result. When
done on a COSE_Signature, the normal countersignature semantics are
preserved. That is the countersignature makes a statement about the
existence of a signature and, when used as a timestamp, a time point
at which the signature exists. When done on a COSE_Mac or a
COSE_Mac0, one effectively upgrades the MAC operation to a signature
operation. When done on a COSE_Sign or a COSE_Sign0, the
countersignature degrades to just being a signature on the payload.
When done on a COSE_Encrypt or COSE_Encrypt0, the existence of the
encrypted data is attested to. It should be noted that there is a
big difference between attesting to the encrypted data as opposed to
attesting to the unencrypted data. If the latter is what is desired,
then one needs to apply a signature to the data and then encrypt
that. It is always possible to construct cases where the use of two
different keys will appear to result in a successful decryption (the
tag check success), but which produce two completely different
plaintexts. This situation is not detectable by a countersignature
on the encrypted data.
6.1. Full Countersignatures
The COSE_Countersignature structure allows for the same set of
capabilities as a COSE_Signature. This means that all of the
capabilities of a signature are duplicated with this structure.
Specifically, the countersigner does not need to be related to the
producer of what is being countersigned as key and algorithm
identification can be placed in the countersignature attributes.
This also means that the countersignature can itself be
countersigned. This is a feature required by protocols such as long-
term archiving services. More information on how countersignatures
is used can be found in the evidence record syntax described in
[RFC4998].
| QUESTION: Remove the definition of COSE_Countersignature_tagged
| and COSE_Countersignature from here an point to section 5.
| Alternatively, we decide that we need to have a new structure
| name for exactly the same thing. In any event the tagged
| version is removed.
The full countersignature structure can be encoded as either tagged
or untagged depending on the context it is used in. A tagged
COSE_Countersignature structure is identified by the CBOR tag TBD0.
The CDDL fragment for full countersignatures is:
COSE_Countersignature_Tagged = #6.9999(COSE_Countersignature)
COSE_Countersignature = COSE_Signature
COSE_CounterSignature = COSE_Countersignature
The details of the fields of a countersignature can be found in
Section 4.1. The process of creating and validating abbreviated
countersignatures is defined in Section 4.4.
| QUESTION: Should we remove these examples and only have
| Countersignature V2 examples?
An example of a countersignature on a signature can be found in
Appendix C.1.3. An example of a countersignature in an encryption
object can be found in Appendix C.3.3.
It should be noted that only a signature algorithm with appendix (see
Section 10.1) 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.
6.2. Abbreviated Countersignatures
Abbreviated countersignatures were designed primarily to deal with
the problem of having encrypted group messaging, but still needing to
know who originated the message. The objective is to keep the
countersignature as small as possible while still providing the
needed security. For abbreviated countersignatures, there is no
provision for any protected attributes related to the signing
operation. Instead, the parameters for computing or verifying the
abbreviated countersignature are inferred from the same context used
to describe the encryption, signature, or MAC processing.
| QUESTION: Remove the definition of COSE_Countersignature0 from
| here an point to section 5. Alternatively, we decide that we
| need to have a new structure name for exactly the same thing.
The CDDL fragment for the abbreviated countersignatures is:
COSE_Countersignature0 = bstr
The byte string representing the signature value is placed in the
Countersignature0 attribute. This attribute is then encoded as an
unprotected header parameter. The attribute is defined below.
The process of creating and validating abbreviated countersignatures
is defined in Section 4.4. is defined in Section 4.4.
| QUESTION: It has been requested to have examples of abbreviated
| countersignatures added to the document. Do we add V1
| abbreviated countersignature as examples or only go with the V2
| versions?
+==================+=====+========================+=====+===========+ +==================+=====+========================+=====+===========+
| Name |Label| Value Type |Value|Description| | Name |Label| Value Type |Value|Description|
+==================+=====+========================+=====+===========+ +==================+=====+========================+=====+===========+
|CounterSignature0 | 9 | COSE_Countersignature0 | |Abbreviated| |Countersignature0 | 9 | COSE_Countersignature0 | |Abbreviated|
| | | | | Counter | | | | | | Counter |
| | | | | Signature | | | | | | signature |
+------------------+-----+------------------------+-----+-----------+ +------------------+-----+------------------------+-----+-----------+
Table 4: Header Parameter for CounterSignature0 Table 4: Header Parameter for Countersignature0
6. Encryption Objects 7. Encryption Objects
COSE supports two different encryption structures. COSE_Encrypt0 is COSE supports two different encryption structures. COSE_Encrypt0 is
used when a recipient structure is not needed because the key to be used when a recipient structure is not needed because the key to be
used is known implicitly. COSE_Encrypt is used the rest of the time. used is known implicitly. COSE_Encrypt is used the rest of the time.
This includes cases where there are multiple recipients or a This includes cases where there are multiple recipients or a
recipient algorithm other than direct (i.e. pre-shared secret) is recipient algorithm other than direct (i.e. pre-shared secret) is
used. used.
6.1. Enveloped COSE Structure 7.1. Enveloped COSE Structure
The enveloped structure allows for one or more recipients of a The enveloped structure allows for one or more recipients of a
message. There are provisions for header parameters about the message. There are provisions for header parameters about the
content and header parameters about the recipient information to be content and header parameters about the recipient information to be
carried in the message. The protected header parameters associated carried in the message. The protected header parameters associated
with the content are authenticated by the content encryption with the content are authenticated by the content encryption
algorithm. The protected header parameters associated with the algorithm. The protected header parameters associated with the
recipient are authenticated by the recipient algorithm (when the recipient are authenticated by the recipient algorithm (when the
algorithm supports it). Examples of header parameters about the algorithm supports it). Examples of header parameters about the
content are the type of the content and the content encryption content are the type of the content and the content encryption
skipping to change at page 29, line 20 skipping to change at page 37, line 14
The CDDL fragment that corresponds to the above text for The CDDL fragment that corresponds to the above text for
COSE_recipient is: COSE_recipient is:
COSE_recipient = [ COSE_recipient = [
Headers, Headers,
ciphertext : bstr / nil, ciphertext : bstr / nil,
? recipients : [+COSE_recipient] ? recipients : [+COSE_recipient]
] ]
6.1.1. Content Key Distribution Methods 7.1.1. Content Key Distribution Methods
An encrypted message consists of an encrypted content and an An encrypted message consists of an encrypted content and an
encrypted CEK for one or more recipients. The CEK is encrypted for encrypted CEK for one or more recipients. The CEK is encrypted for
each recipient, using a key specific to that recipient. The details each recipient, using a key specific to that recipient. The details
of this encryption depend on which class the recipient algorithm of this encryption depend on which class the recipient algorithm
falls into. Specific details on each of the classes can be found in falls into. Specific details on each of the classes can be found in
Section 9.5. A short summary of the five content key distribution Section 10.5. A short summary of the five content key distribution
methods is: methods is:
direct: The CEK is the same as the identified previously distributed direct: The CEK is the same as the identified previously distributed
symmetric key or is derived from a previously distributed secret. symmetric key or is derived from a previously distributed secret.
No CEK is transported in the message. No CEK is transported in the message.
symmetric key-encryption keys (KEK): The CEK is encrypted using a symmetric key-encryption keys (KEK): The CEK is encrypted using a
previously distributed symmetric KEK. Also known as key wrap. previously distributed symmetric KEK. Also known as key wrap.
key agreement: The recipient's public key and a sender's private key key agreement: The recipient's public key and a sender's private key
are used to generate a pairwise secret, a Key Derivation Function are used to generate a pairwise secret, a Key Derivation Function
(KDF) is applied to derive a key, and then the CEK is either the (KDF) is applied to derive a key, and then the CEK is either the
derived key or encrypted by the derived key. derived key or encrypted by the derived key.
key transport: The CEK is encrypted with the recipient's public key. key transport: The CEK is encrypted with the recipient's public key.
passwords: The CEK is encrypted in a KEK that is derived from a passwords: The CEK is encrypted in a KEK that is derived from a
password. As of when this document was published, no password password. As of when this document was published, no password
algorithms have been defined. algorithms have been defined.
6.2. Single Recipient Encrypted 7.2. Single Recipient Encrypted
The COSE_Encrypt0 encrypted structure does not have the ability to The COSE_Encrypt0 encrypted structure does not have the ability to
specify recipients of the message. The structure assumes that the specify recipients of the message. The structure assumes that the
recipient of the object will already know the identity of the key to recipient of the object will already know the identity of the key to
be used in order to decrypt the message. If a key needs to be be used in order to decrypt the message. If a key needs to be
identified to the recipient, the enveloped structure ought to be identified to the recipient, the enveloped structure ought to be
used. used.
Examples of encrypted messages can be found in Appendix C.3. Examples of encrypted messages can be found in Appendix C.3.
skipping to change at page 30, line 30 skipping to change at page 38, line 19
COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0) COSE_Encrypt0_Tagged = #6.16(COSE_Encrypt0)
The COSE_Encrypt0 structure is a CBOR array. The fields of the array The COSE_Encrypt0 structure is a CBOR array. The fields of the array
in order are: in order are:
protected: This is as described in Section 3. protected: This is as described in Section 3.
unprotected: This is as described in Section 3. unprotected: This is as described in Section 3.
ciphertext: This is as described in Section 6.1. ciphertext: This is as described in Section 7.1.
The CDDL fragment for COSE_Encrypt0 that corresponds to the above The CDDL fragment for COSE_Encrypt0 that corresponds to the above
text is: text is:
COSE_Encrypt0 = [ COSE_Encrypt0 = [
Headers, Headers,
ciphertext : bstr / nil, ciphertext : bstr / nil,
] ]
6.3. How to Encrypt and Decrypt for AEAD Algorithms 7.3. How to Encrypt and Decrypt for AEAD Algorithms
The encryption algorithm for AEAD algorithms is fairly simple. The The encryption algorithm for AEAD algorithms is fairly simple. The
first step is to create a consistent byte string for the first step is to create a consistent byte string for the
authenticated data structure. For this purpose, we use an authenticated data structure. For this purpose, we use an
Enc_structure. The Enc_structure is a CBOR array. The fields of the Enc_structure. The Enc_structure is a CBOR array. The fields of the
Enc_structure in order are: Enc_structure in order are:
1. A context text string identifying the context of the 1. A context text string identifying the context of the
authenticated data structure. The context text string is: authenticated data structure. The context text string is:
skipping to change at page 31, line 42 skipping to change at page 39, line 33
external_aad : bstr external_aad : bstr
] ]
How to encrypt a message: How to encrypt a message:
1. Create an Enc_structure and populate it with the appropriate 1. Create an Enc_structure and populate it with the appropriate
fields. fields.
2. Encode the Enc_structure to a byte string (Additional 2. Encode the Enc_structure to a byte string (Additional
Authenticated Data (AAD)), using the encoding described in Authenticated Data (AAD)), using the encoding described in
Section 10. Section 11.
3. Determine the encryption key (K). This step is dependent on the 3. Determine the encryption key (K). This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
(Section 9.5.3), key wrap keys (Section 9.5.2), or pre-shared (Section 10.5.3), key wrap keys (Section 10.5.2), or pre-
secrets. shared secrets.
Direct Encryption and Direct Key Agreement: The key is Direct Encryption and Direct Key Agreement: The key is
determined by the key and algorithm in the recipient determined by the key and algorithm in the recipient
structure. The encryption algorithm and size of the key to be structure. The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient. (For used are inputs into the KDF used for the recipient. (For
direct, the KDF can be thought of as the identity operation.) direct, the KDF can be thought of as the identity operation.)
Examples of these algorithms are found in Sections 6.1.2 and Examples of these algorithms are found in Sections 6.1.2 and
6.3 of [I-D.ietf-cose-rfc8152bis-algs]. 6.3 of [I-D.ietf-cose-rfc8152bis-algs].
Other: The key is randomly or pseudo-randomly generated. Other: The key is randomly or pseudo-randomly generated.
skipping to change at page 32, line 27 skipping to change at page 40, line 19
5. For recipients of the message, recursively perform the encryption 5. For recipients of the message, recursively perform the encryption
algorithm for that recipient, using K (the encryption key) as the algorithm for that recipient, using K (the encryption key) as the
plaintext. plaintext.
How to decrypt a message: How to decrypt a message:
1. Create an Enc_structure and populate it with the appropriate 1. Create an Enc_structure and populate it with the appropriate
fields. fields.
2. Encode the Enc_structure to a byte string (AAD), using the 2. Encode the Enc_structure to a byte string (AAD), using the
encoding described in Section 10. encoding described in Section 11.
3. Determine the decryption key. This step is dependent on the 3. Determine the decryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
(Section 9.5.3), key wrap keys (Section 9.5.2), or pre-shared (Section 10.5.3), key wrap keys (Section 10.5.2), or pre-
secrets. shared secrets.
Direct Encryption and Direct Key Agreement: The key is Direct Encryption and Direct Key Agreement: The key is
determined by the key and algorithm in the recipient determined by the key and algorithm in the recipient
structure. The encryption algorithm and size of the key to be structure. The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient. (For used are inputs into the KDF used for the recipient. (For
direct, the KDF can be thought of as the identity operation.) direct, the KDF can be thought of as the identity operation.)
Other: The key is determined by decoding and decrypting one of Other: The key is determined by decoding and decrypting one of
the recipient structures. the recipient structures.
4. Call the decryption algorithm with K (the decryption key to use), 4. Call the decryption algorithm with K (the decryption key to use),
C (the ciphertext), and AAD. C (the ciphertext), and AAD.
6.4. How to Encrypt and Decrypt for AE Algorithms 7.4. How to Encrypt and Decrypt for AE Algorithms
How to encrypt a message: How to encrypt a message:
1. Verify that the 'protected' field is empty. 1. Verify that the 'protected' field is empty.
2. Verify that there was no external additional authenticated data 2. Verify that there was no external additional authenticated data
supplied for this operation. supplied for this operation.
3. Determine the encryption key. This step is dependent on the 3. Determine the encryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
(Section 9.5.3), key wrap keys (Section 9.5.2), or pre-shared (Section 10.5.3), key wrap keys (Section 10.5.2), or pre-
secrets. shared secrets.
Direct Encryption and Direct Key Agreement: The key is Direct Encryption and Direct Key Agreement: The key is
determined by the key and algorithm in the recipient determined by the key and algorithm in the recipient
structure. The encryption algorithm and size of the key to be structure. The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient. (For used are inputs into the KDF used for the recipient. (For
direct, the KDF can be thought of as the identity operation.) direct, the KDF can be thought of as the identity operation.)
Examples of these algorithms are found in Sections 6.1.2 and Examples of these algorithms are found in Sections 6.1.2 and
6.3 of [I-D.ietf-cose-rfc8152bis-algs]. 6.3 of [I-D.ietf-cose-rfc8152bis-algs].
Other: The key is randomly generated. Other: The key is randomly generated.
skipping to change at page 34, line 5 skipping to change at page 41, line 40
1. Verify that the 'protected' field is empty. 1. Verify that the 'protected' field is empty.
2. Verify that there was no external additional authenticated data 2. Verify that there was no external additional authenticated data
supplied for this operation. supplied for this operation.
3. Determine the decryption key. This step is dependent on the 3. Determine the decryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
(Section 9.5.3), key wrap keys (Section 9.5.2), or pre-shared (Section 10.5.3), key wrap keys (Section 10.5.2), or pre-
secrets. shared secrets.
Direct Encryption and Direct Key Agreement: The key is Direct Encryption and Direct Key Agreement: The key is
determined by the key and algorithm in the recipient determined by the key and algorithm in the recipient
structure. The encryption algorithm and size of the key to be structure. The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient. (For used are inputs into the KDF used for the recipient. (For
direct, the KDF can be thought of as the identity operation.) direct, the KDF can be thought of as the identity operation.)
Examples of these algorithms are found in Sections 6.1.2 and Examples of these algorithms are found in Sections 6.1.2 and
6.3 of [I-D.ietf-cose-rfc8152bis-algs]. 6.3 of [I-D.ietf-cose-rfc8152bis-algs].
Other: The key is determined by decoding and decrypting one of Other: The key is determined by decoding and decrypting one of
the recipient structures. the recipient structures.
4. Call the decryption algorithm with K (the decryption key to use) 4. Call the decryption algorithm with K (the decryption key to use)
and C (the ciphertext). and C (the ciphertext).
7. MAC Objects 8. MAC Objects
COSE supports two different MAC structures. COSE_MAC0 is used when a COSE supports two different MAC structures. COSE_MAC0 is used when a
recipient structure is not needed because the key to be used is recipient structure is not needed because the key to be used is
implicitly known. COSE_MAC is used for all other cases. These implicitly known. COSE_MAC is used for all other cases. These
include a requirement for multiple recipients, the key being unknown, include a requirement for multiple recipients, the key being unknown,
or a recipient algorithm of other than direct. or a recipient algorithm of other than direct.
In this section, we describe the structure and methods to be used In this section, we describe the structure and methods to be used
when doing MAC authentication in COSE. This document allows for the when doing MAC authentication in COSE. This document allows for the
use of all of the same classes of recipient algorithms as are allowed use of all of the same classes of recipient algorithms as are allowed
skipping to change at page 35, line 5 skipping to change at page 42, line 35
the content has not been changed since the MAC was computed and to the content has not been changed since the MAC was computed and to
use the recipient algorithm to verify who sent it. The classes of use the recipient algorithm to verify who sent it. The classes of
recipient algorithms that support this are those that use a pre- recipient algorithms that support this are those that use a pre-
shared secret or do static-static (SS) key agreement (without the key shared secret or do static-static (SS) key agreement (without the key
wrap step). In both of these cases, the entity that created and sent wrap step). In both of these cases, the entity that created and sent
the message MAC can be validated. (This knowledge of the sender the message MAC can be validated. (This knowledge of the sender
assumes that there are only two parties involved and that you did not assumes that there are only two parties involved and that you did not
send the message to yourself.) The origination property can be send the message to yourself.) The origination property can be
obtained with both of the MAC message structures. obtained with both of the MAC message structures.
7.1. MACed Message with Recipients 8.1. MACed Message with Recipients
The multiple recipient MACed message uses two structures: the The multiple recipient MACed message uses two structures: the
COSE_Mac structure defined in this section for carrying the body and COSE_Mac structure defined in this section for carrying the body and
the COSE_recipient structure (Section 6.1) to hold the key used for the COSE_recipient structure (Section 7.1) to hold the key used for
the MAC computation. Examples of MACed messages can be found in the MAC computation. Examples of MACed messages can be found in
Appendix C.5. Appendix C.5.
The MAC structure can be encoded as either tagged or untagged The MAC structure can be encoded as either tagged or untagged
depending on the context it will be used in. A tagged COSE_Mac depending on the context it will be used in. A tagged COSE_Mac
structure is identified by the CBOR tag 97. The CDDL fragment that structure is identified by the CBOR tag 97. The CDDL fragment that
represents this is: represents this is:
COSE_Mac_Tagged = #6.97(COSE_Mac) COSE_Mac_Tagged = #6.97(COSE_Mac)
skipping to change at page 35, line 38 skipping to change at page 43, line 20
the payload is not present in the message, the application is the payload is not present in the message, the application is
required to supply the payload separately. The payload is wrapped required to supply the payload separately. The payload is wrapped
in a bstr to ensure that it is transported without changes. If in a bstr to ensure that it is transported without changes. If
the payload is transported separately (i.e., detached content), the payload is transported separately (i.e., detached content),
then a nil CBOR value is placed in this location, and it is the then a nil CBOR value is placed in this location, and it is the
responsibility of the application to ensure that it will be responsibility of the application to ensure that it will be
transported without changes. transported without changes.
tag: This field contains the MAC value. tag: This field contains the MAC value.
recipients: This is as described in Section 6.1. recipients: This is as described in Section 7.1.
The CDDL fragment that represents the above text for COSE_Mac The CDDL fragment that represents the above text for COSE_Mac
follows. follows.
COSE_Mac = [ COSE_Mac = [
Headers, Headers,
payload : bstr / nil, payload : bstr / nil,
tag : bstr, tag : bstr,
recipients :[+COSE_recipient] recipients :[+COSE_recipient]
] ]
7.2. MACed Messages with Implicit Key 8.2. MACed Messages with Implicit Key
In this section, we describe the structure and methods to be used In this section, we describe the structure and methods to be used
when doing MAC authentication for those cases where the recipient is when doing MAC authentication for those cases where the recipient is
implicitly known. implicitly known.
The MACed message uses the COSE_Mac0 structure defined in this The MACed message uses the COSE_Mac0 structure defined in this
section for carrying the body. Examples of MACed messages with an section for carrying the body. Examples of MACed messages with an
implicit key can be found in Appendix C.6. implicit key can be found in Appendix C.6.
The MAC structure can be encoded as either tagged or untagged The MAC structure can be encoded as either tagged or untagged
skipping to change at page 36, line 29 skipping to change at page 44, line 7
COSE_Mac0_Tagged = #6.17(COSE_Mac0) COSE_Mac0_Tagged = #6.17(COSE_Mac0)
The COSE_Mac0 structure is a CBOR array. The fields of the array in The COSE_Mac0 structure is a CBOR array. The fields of the array in
order are: order are:
protected: This is as described in Section 3. protected: This is as described in Section 3.
unprotected: This is as described in Section 3. unprotected: This is as described in Section 3.
payload: This is as described in Section 7.1. payload: This is as described in Section 8.1.
tag: This field contains the MAC value. tag: This field contains the MAC value.
The CDDL fragment that corresponds to the above text is: The CDDL fragment that corresponds to the above text is:
COSE_Mac0 = [ COSE_Mac0 = [
Headers, Headers,
payload : bstr / nil, payload : bstr / nil,
tag : bstr, tag : bstr,
] ]
7.3. How to Compute and Verify a MAC 8.3. How to Compute and Verify a MAC
In order to get a consistent encoding of the data to be In order to get a consistent encoding of the data to be
authenticated, the MAC_structure is used to have a canonical form. authenticated, the MAC_structure is used to have a canonical form.
The MAC_structure is a CBOR array. The fields of the MAC_structure The MAC_structure is a CBOR array. The fields of the MAC_structure
in order are: in order are:
1. A context text string that identifies the structure that is being 1. A context text string that identifies the structure that is being
encoded. This context text string is "MAC" for the COSE_Mac encoded. This context text string is "MAC" for the COSE_Mac
structure. This context text string is "MAC0" for the COSE_Mac0 structure. This context text string is "MAC0" for the COSE_Mac0
structure. structure.
skipping to change at page 37, line 31 skipping to change at page 45, line 9
external_aad : bstr, external_aad : bstr,
payload : bstr payload : bstr
] ]
The steps to compute a MAC are: The steps to compute a MAC are:
1. Create a MAC_structure and populate it with the appropriate 1. Create a MAC_structure and populate it with the appropriate
fields. fields.
2. Create the value ToBeMaced by encoding the MAC_structure to a 2. Create the value ToBeMaced by encoding the MAC_structure to a
byte string, using the encoding described in Section 10. byte string, using the encoding described in Section 11.
3. Call the MAC creation algorithm passing in K (the key to use), 3. Call the MAC creation algorithm passing in K (the key to use),
alg (the algorithm to MAC with), and ToBeMaced (the value to alg (the algorithm to MAC with), and ToBeMaced (the value to
compute the MAC on). compute the MAC on).
4. Place the resulting MAC in the 'tag' field of the COSE_Mac or 4. Place the resulting MAC in the 'tag' field of the COSE_Mac or
COSE_Mac0 structure. COSE_Mac0 structure.
5. For COSE_Mac structures, encrypt and encode the MAC key for each 5. For COSE_Mac structures, encrypt and encode the MAC key for each
recipient of the message. recipient of the message.
The steps to verify a MAC are: The steps to verify a MAC are:
1. Create a MAC_structure and populate it with the appropriate 1. Create a MAC_structure and populate it with the appropriate
fields. fields.
2. Create the value ToBeMaced by encoding the MAC_structure to a 2. Create the value ToBeMaced by encoding the MAC_structure to a
byte string, using the encoding described in Section 10. byte string, using the encoding described in Section 11.
3. For COSE_Mac structures, obtain the cryptographic key from one of 3. For COSE_Mac structures, obtain the cryptographic key from one of
the recipients of the message. the recipients of the message.
4. Call the MAC creation algorithm passing in K (the key to use), 4. Call the MAC creation algorithm passing in K (the key to use),
alg (the algorithm to MAC with), and ToBeMaced (the value to alg (the algorithm to MAC with), and ToBeMaced (the value to
compute the MAC on). compute the MAC on).
5. Compare the MAC value to the 'tag' field of the COSE_Mac or 5. Compare the MAC value to the 'tag' field of the COSE_Mac or
COSE_Mac0 structure. COSE_Mac0 structure.
8. Key Objects 9. Key Objects
A COSE Key structure is built on a CBOR map. The set of common A COSE Key structure is built on a CBOR map. The set of common
parameters that can appear in a COSE Key can be found in the IANA parameters that can appear in a COSE Key can be found in the IANA
"COSE Key Common Parameters" registry (Section 12.3). Additional "COSE Key Common Parameters" registry (Section 13.3). Additional
parameters defined for specific key types can be found in the IANA parameters defined for specific key types can be found in the IANA
"COSE Key Type Parameters" registry ([COSE.KeyParameters]). "COSE Key Type Parameters" registry ([COSE.KeyParameters]).
A COSE Key Set uses a CBOR array object as its underlying type. The A COSE Key Set uses a CBOR array object as its underlying type. The
values of the array elements are COSE Keys. A COSE Key Set MUST have values of the array elements are COSE Keys. A COSE Key Set MUST have
at least one element in the array. Examples of COSE Key Sets can be at least one element in the array. Examples of COSE Key Sets can be
found in Appendix C.7. found in Appendix C.7.
Each element in a COSE Key Set MUST be processed independently. If Each element in a COSE Key Set MUST be processed independently. If
one element in a COSE Key Set is either malformed or uses a key that one element in a COSE Key Set is either malformed or uses a key that
skipping to change at page 38, line 45 skipping to change at page 46, line 25
1 => tstr / int, ; kty 1 => tstr / int, ; kty
? 2 => bstr, ; kid ? 2 => bstr, ; kid
? 3 => tstr / int, ; alg ? 3 => tstr / int, ; alg
? 4 => [+ (tstr / int) ], ; key_ops ? 4 => [+ (tstr / int) ], ; key_ops
? 5 => bstr, ; Base IV ? 5 => bstr, ; Base IV
* label => values * label => values
} }
COSE_KeySet = [+COSE_Key] COSE_KeySet = [+COSE_Key]
8.1. COSE Key Common Parameters 9.1. COSE Key Common Parameters
This document defines a set of common parameters for a COSE Key This document defines a set of common parameters for a COSE Key
object. Table 5 provides a summary of the parameters defined in this object. Table 5 provides a summary of the parameters defined in this
section. There are also parameters that are defined for specific key section. There are also parameters that are defined for specific key
types. Key-type-specific parameters can be found in types. Key-type-specific parameters can be found in
[I-D.ietf-cose-rfc8152bis-algs]. [I-D.ietf-cose-rfc8152bis-algs].
+=========+=======+========+============+====================+ +=========+=======+========+============+====================+
| Name | Label | CBOR | Value | Description | | Name | Label | CBOR | Value | Description |
| | | Type | Registry | | | | | Type | Registry | |
skipping to change at page 41, line 41 skipping to change at page 49, line 41
+---------+-------+----------------------------------------------+ +---------+-------+----------------------------------------------+
| MAC | 9 | The key is used for creating MACs. | | MAC | 9 | The key is used for creating MACs. |
| create | | | | create | | |
+---------+-------+----------------------------------------------+ +---------+-------+----------------------------------------------+
| MAC | 10 | The key is used for validating MACs. | | MAC | 10 | The key is used for validating MACs. |
| verify | | | | verify | | |
+---------+-------+----------------------------------------------+ +---------+-------+----------------------------------------------+
Table 6: Key Operation Values Table 6: Key Operation Values
9. Taxonomy of Algorithms used by COSE 10. Taxonomy of Algorithms used by COSE
In this section, a taxonomy of the different algorithm types that can In this section, a taxonomy of the different algorithm types that can
be used in COSE is laid out. This taxonomy should not be considered be used in COSE is laid out. This taxonomy should not be considered
to be exhaustive. New algorithms will be created which will not fit to be exhaustive. New algorithms will be created which will not fit
into this taxonomy. into this taxonomy.
9.1. Signature Algorithms 10.1. Signature Algorithms
Signature algorithms provide data origination and data integrity Signature algorithms provide data origination and data integrity
services. Data origination provides the ability to infer who services. Data origination provides the ability to infer who
originated the data based on who signed the data. Data integrity originated the data based on who signed the data. Data integrity
provides the ability to verify that the data has not been modified provides the ability to verify that the data has not been modified
since it was signed. since it was signed.
There are two signature algorithm schemes. The first is signature There are two signature algorithm schemes. The first is signature
with appendix. In this scheme, the message content is processed and with appendix. In this scheme, the message content is processed and
a signature is produced; the signature is called the appendix. This a signature is produced; the signature is called the appendix. This
skipping to change at page 43, line 11 skipping to change at page 51, line 11
signature, message sent = Sign(message content, key) signature, message sent = Sign(message content, key)
valid, message content = Verification(message sent, key, signature) valid, message content = Verification(message sent, key, signature)
Signature algorithms are used with the COSE_Signature and COSE_Sign1 Signature algorithms are used with the COSE_Signature and COSE_Sign1
structures. At this time, only signatures with appendixes are structures. At this time, only signatures with appendixes are
defined for use with COSE; however, considerable interest has been defined for use with COSE; however, considerable interest has been
expressed in using a signature with message recovery algorithm due to expressed in using a signature with message recovery algorithm due to
the effective size reduction that is possible. Implementations will the effective size reduction that is possible. Implementations will
need to keep this in mind for later possible integration. need to keep this in mind for later possible integration.
9.2. Message Authentication Code (MAC) Algorithms 10.2. Message Authentication Code (MAC) Algorithms
Message Authentication Codes (MACs) provide data authentication and Message Authentication Codes (MACs) provide data authentication and
integrity protection. They provide either no or very limited data integrity protection. They provide either no or very limited data
origination. A MAC, for example, cannot be used to prove the origination. A MAC, for example, cannot be used to prove the
identity of the sender to a third party. identity of the sender to a third party.
MACs use the same scheme as signature with appendix algorithms. The MACs use the same scheme as signature with appendix algorithms. The
message content is processed and an authentication code is produced. message content is processed and an authentication code is produced.
The authentication code is frequently called a tag. The authentication code is frequently called a tag.
skipping to change at page 43, line 35 skipping to change at page 51, line 35
valid = MAC_Verify(message content, key, tag) valid = MAC_Verify(message content, key, tag)
MAC algorithms can be based on either a block cipher algorithm (i.e., MAC algorithms can be based on either a block cipher algorithm (i.e.,
AES-MAC) or a hash algorithm (i.e., a Hash-based Message AES-MAC) or a hash algorithm (i.e., a Hash-based Message
Authentication Code (HMAC)). [I-D.ietf-cose-rfc8152bis-algs] defines Authentication Code (HMAC)). [I-D.ietf-cose-rfc8152bis-algs] defines
a MAC algorithm using each of these constructions. a MAC algorithm using each of these constructions.
MAC algorithms are used in the COSE_Mac and COSE_Mac0 structures. MAC algorithms are used in the COSE_Mac and COSE_Mac0 structures.
9.3. Content Encryption Algorithms 10.3. Content Encryption Algorithms
Content encryption algorithms provide data confidentiality for Content encryption algorithms provide data confidentiality for
potentially large blocks of data using a symmetric key. They provide potentially large blocks of data using a symmetric key. They provide
integrity on the data that was encrypted; however, they provide integrity on the data that was encrypted; however, they provide
either no or very limited data origination. (One cannot, for either no or very limited data origination. (One cannot, for
example, be used to prove the identity of the sender to a third example, be used to prove the identity of the sender to a third
party.) The ability to provide data origination is linked to how the party.) The ability to provide data origination is linked to how the
CEK is obtained. CEK is obtained.
COSE restricts the set of legal content encryption algorithms to COSE restricts the set of legal content encryption algorithms to
skipping to change at page 44, line 16 skipping to change at page 52, line 16
valid, message content = Decrypt(ciphertext, key, additional data) valid, message content = Decrypt(ciphertext, key, additional data)
Most AEAD algorithms are logically defined as returning the message Most AEAD algorithms are logically defined as returning the message
content only if the decryption is valid. Many but not all content only if the decryption is valid. Many but not all
implementations will follow this convention. The message content implementations will follow this convention. The message content
MUST NOT be used if the decryption does not validate. MUST NOT be used if the decryption does not validate.
These algorithms are used in COSE_Encrypt and COSE_Encrypt0. These algorithms are used in COSE_Encrypt and COSE_Encrypt0.
9.4. Key Derivation Functions (KDFs) 10.4. Key Derivation Functions (KDFs)
KDFs are used to take some secret value and generate a different one. KDFs are used to take some secret value and generate a different one.
The secret value comes in three flavors: The secret value comes in three flavors:
* Secrets that are uniformly random: This is the type of secret that * Secrets that are uniformly random: This is the type of secret that
is created by a good random number generator. is created by a good random number generator.
* Secrets that are not uniformly random: This is type of secret that * Secrets that are not uniformly random: This is type of secret that
is created by operations like key agreement. is created by operations like key agreement.
skipping to change at page 45, line 5 skipping to change at page 53, line 5
[I-D.ietf-cose-rfc8152bis-algs] is such a function. This is [I-D.ietf-cose-rfc8152bis-algs] is such a function. This is
reflected in the set of algorithms defined around the HMAC-based reflected in the set of algorithms defined around the HMAC-based
Extract-and-Expand Key Derivation Function (HKDF). Extract-and-Expand Key Derivation Function (HKDF).
When using KDFs, one component that is included is context When using KDFs, one component that is included is context
information. Context information is used to allow for different information. Context information is used to allow for different
keying information to be derived from the same secret. The use of keying information to be derived from the same secret. The use of
context-based keying material is considered to be a good security context-based keying material is considered to be a good security
practice. practice.
9.5. Content Key Distribution Methods 10.5. Content Key Distribution Methods
Content key distribution methods (recipient algorithms) can be Content key distribution methods (recipient algorithms) can be
defined into a number of different classes. COSE has the ability to defined into a number of different classes. COSE has the ability to
support many classes of recipient algorithms. In this section, a support many classes of recipient algorithms. In this section, a
number of classes are listed. The names of the recipient algorithm number of classes are listed. The names of the recipient algorithm
classes used here are the same as those defined in [RFC7516]. Other classes used here are the same as those defined in [RFC7516]. Other
specifications use different terms for the recipient algorithm specifications use different terms for the recipient algorithm
classes or do not support some of the recipient algorithm classes. classes or do not support some of the recipient algorithm classes.
9.5.1. Direct Encryption 10.5.1. Direct Encryption
The direct encryption class algorithms share a secret between the The direct encryption class algorithms share a secret between the
sender and the recipient that is used either directly or after sender and the recipient that is used either directly or after
manipulation as the CEK. When direct encryption mode is used, it manipulation as the CEK. When direct encryption mode is used, it
MUST be the only mode used on the message. MUST be the only mode used on the message.
The COSE_Recipient structure for the recipient is organized as The COSE_Recipient structure for the recipient is organized as
follows: follows:
* The 'protected' field MUST be a zero-length byte string unless it * The 'protected' field MUST be a zero-length byte string unless it
skipping to change at page 45, line 37 skipping to change at page 53, line 37
* The 'alg' header parameter MUST be present. * The 'alg' header parameter MUST be present.
* A header parameter identifying the shared secret SHOULD be * A header parameter identifying the shared secret SHOULD be
present. present.
* The 'ciphertext' field MUST be a zero-length byte string. * The 'ciphertext' field MUST be a zero-length byte string.
* The 'recipients' field MUST be absent. * The 'recipients' field MUST be absent.
9.5.2. Key Wrap 10.5.2. Key Wrap
In key wrap mode, the CEK is randomly generated and that key is then In key wrap mode, the CEK is randomly generated and that key is then
encrypted by a shared secret between the sender and the recipient. encrypted by a shared secret between the sender and the recipient.
All of the currently defined key wrap algorithms for COSE are AE All of the currently defined key wrap algorithms for COSE are AE
algorithms. Key wrap mode is considered to be superior to direct algorithms. Key wrap mode is considered to be superior to direct
encryption if the system has any capability for doing random key encryption if the system has any capability for doing random key
generation. This is because the shared key is used to wrap random generation. This is because the shared key is used to wrap random
data rather than data that has some degree of organization and may in data rather than data that has some degree of organization and may in
fact be repeating the same content. The use of key wrap loses the fact be repeating the same content. The use of key wrap loses the
weak data origination that is provided by the direct encryption weak data origination that is provided by the direct encryption
skipping to change at page 46, line 21 skipping to change at page 54, line 21
recipient is an acceptable way of dealing with it. Failing to recipient is an acceptable way of dealing with it. Failing to
process the message is not an acceptable way of dealing with it. process the message is not an acceptable way of dealing with it.
* The plaintext to be encrypted is the key from next layer down * The plaintext to be encrypted is the key from next layer down
(usually the content layer). (usually the content layer).
* At a minimum, the 'unprotected' field MUST contain the 'alg' * At a minimum, the 'unprotected' field MUST contain the 'alg'
header parameter and SHOULD contain a header parameter identifying header parameter and SHOULD contain a header parameter identifying
the shared secret. the shared secret.
9.5.3. Key Transport 10.5.3. Key Transport
Key transport mode is also called key encryption mode in some Key transport mode is also called key encryption mode in some
standards. Key transport mode differs from key wrap mode in that it standards. Key transport mode differs from key wrap mode in that it
uses an asymmetric encryption algorithm rather than a symmetric uses an asymmetric encryption algorithm rather than a symmetric
encryption algorithm to protect the key. A set of key transport encryption algorithm to protect the key. A set of key transport
algorithms are defined in [RFC8230]. algorithms are defined in [RFC8230].
When using a key transport algorithm, the COSE_Recipient structure When using a key transport algorithm, the COSE_Recipient structure
for the recipient is organized as follows: for the recipient is organized as follows:
* The 'protected' field MUST be absent. * The 'protected' field MUST be absent.
* The plaintext to be encrypted is the key from the next layer down * The plaintext to be encrypted is the key from the next layer down
(usually the content layer). (usually the content layer).
* At a minimum, the 'unprotected' field MUST contain the 'alg' * At a minimum, the 'unprotected' field MUST contain the 'alg'
header parameter and SHOULD contain a parameter identifying the header parameter and SHOULD contain a parameter identifying the
asymmetric key. asymmetric key.
9.5.4. Direct Key Agreement 10.5.4. Direct Key Agreement
The 'direct key agreement' class of recipient algorithms uses a key The 'direct key agreement' class of recipient algorithms uses a key
agreement method to create a shared secret. A KDF is then applied to agreement method to create a shared secret. A KDF is then applied to
the shared secret to derive a key to be used in protecting the data. the shared secret to derive a key to be used in protecting the data.
This key is normally used as a CEK or MAC key, but could be used for This key is normally used as a CEK or MAC key, but could be used for
other purposes if more than two layers are in use (see Appendix B). other purposes if more than two layers are in use (see Appendix B).
The most commonly used key agreement algorithm is Diffie-Hellman, but The most commonly used key agreement algorithm is Diffie-Hellman, but
other variants exist. Since COSE is designed for a store and forward other variants exist. Since COSE is designed for a store and forward
environment rather than an online environment, many of the DH environment rather than an online environment, many of the DH
skipping to change at page 47, line 39 skipping to change at page 55, line 39
follows: follows:
* At a minimum, headers MUST contain the 'alg' header parameter and * At a minimum, headers MUST contain the 'alg' header parameter and
SHOULD contain a header parameter identifying the recipient's SHOULD contain a header parameter identifying the recipient's
asymmetric key. asymmetric key.
* The headers SHOULD identify the sender's key for the static-static * The headers SHOULD identify the sender's key for the static-static
versions and MUST contain the sender's ephemeral key for the versions and MUST contain the sender's ephemeral key for the
ephemeral-static versions. ephemeral-static versions.
9.5.5. Key Agreement with Key Wrap 10.5.5. Key Agreement with Key Wrap
Key Agreement with Key Wrap uses a randomly generated CEK. The CEK Key Agreement with Key Wrap uses a randomly generated CEK. The CEK
is then encrypted using a key wrap algorithm and a key derived from is then encrypted using a key wrap algorithm and a key derived from
the shared secret computed by the key agreement algorithm. The the shared secret computed by the key agreement algorithm. The
function for this would be: function for this would be:
encryptedKey = KeyWrap(KDF(DH-Shared, context), CEK) encryptedKey = KeyWrap(KDF(DH-Shared, context), CEK)
The COSE_Recipient structure for the recipient is organized as The COSE_Recipient structure for the recipient is organized as
follows: follows:
skipping to change at page 48, line 14 skipping to change at page 56, line 14
* The plaintext to be encrypted is the key from the next layer down * The plaintext to be encrypted is the key from the next layer down
(usually the content layer). (usually the content layer).
* The 'alg' header parameter MUST be present in the layer. * The 'alg' header parameter MUST be present in the layer.
* A header parameter identifying the recipient's key SHOULD be * A header parameter identifying the recipient's key SHOULD be
present. A header parameter identifying the sender's key SHOULD present. A header parameter identifying the sender's key SHOULD
be present. be present.
10. CBOR Encoding Restrictions 11. CBOR Encoding Restrictions
This document limits the restrictions it imposes on how the CBOR This document limits the restrictions it imposes on how the CBOR
Encoder needs to work. It has been narrowed down to the following Encoder needs to work. It has been narrowed down to the following
restrictions: restrictions:
* The restriction applies to the encoding of the Sig_structure, the * The restriction applies to the encoding of the Sig_structure, the
Enc_structure, and the MAC_structure. Enc_structure, and the MAC_structure.
* Encoding MUST be done using definite lengths and values MUST be * Encoding MUST be done using definite lengths and values MUST be
the minimum possible length. This means that the integer 1 is the minimum possible length. This means that the integer 1 is
encoded as "0x01" and not "0x1801". encoded as "0x01" and not "0x1801".
* Applications MUST NOT generate messages with the same label used * Applications MUST NOT generate messages with the same label used
twice as a key in a single map. Applications MUST NOT parse and 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 process messages with the same label used twice as a key in a
single map. Applications can enforce the parse and process single map. Applications can enforce the parse and process
requirement by using parsers that will fail the parse step or by requirement by using parsers that will fail the parse step or by
using parsers that will pass all keys to the application, and the using parsers that will pass all keys to the application, and the
application can perform the check for duplicate keys. application can perform the check for duplicate keys.
11. Application Profiling Considerations 12. Application Profiling Considerations
This document is designed to provide a set of security services, but This document is designed to provide a set of security services, but
not impose algorithm implementation requirements for specific usage. not impose algorithm implementation requirements for specific usage.
The interoperability requirements are provided for how each of the The interoperability requirements are provided for how each of the
individual services are used and how the algorithms are to be used individual services are used and how the algorithms are to be used
for interoperability. The requirements about which algorithms and for interoperability. The requirements about which algorithms and
which services are needed are deferred to each application. which services are needed are deferred to each application.
An example of a profile can be found in [RFC8613] where one was An example of a profile can be found in [RFC8613] where one was
developed for carrying content in combination with CoAP headers. developed for carrying content in combination with CoAP headers.
skipping to change at page 50, line 5 skipping to change at page 58, line 5
- Advertising in the message (S/MIME capabilities) [RFC5751]. - Advertising in the message (S/MIME capabilities) [RFC5751].
- Advertising in the certificate (capabilities extension) - Advertising in the certificate (capabilities extension)
[RFC4262]. [RFC4262].
- Minimum requirements for the S/MIME, which have been updated - Minimum requirements for the S/MIME, which have been updated
over time [RFC2633] [RFC5751] (note that [RFC2633] has been over time [RFC2633] [RFC5751] (note that [RFC2633] has been
obsoleted by [RFC5751]). obsoleted by [RFC5751]).
12. IANA Considerations 13. IANA Considerations
The registries and registrations listed below were created during The registries and registrations listed below were created during
processing of RFC 8152 [RFC8152]. The majority of the actions are to processing of RFC 8152 [RFC8152]. The majority of the actions are to
update the references to point to this document. update the references to point to this document.
12.1. CBOR Tag Assignment 13.1. CBOR Tag Assignment
IANA assigned tags in the "CBOR Tags" registry as part of processing IANA assigned tags in the "CBOR Tags" registry as part of processing
[RFC8152]. IANA is requested to update the references from [RFC8152] [RFC8152]. IANA is requested to update the references from [RFC8152]
to this document. to this document.
IANA is requested to register a new tag for the CounterSignature IANA is requested to register a new tag for the CounterSignature
type. type.
* Tag: TBD0 * Tag: TBD0
* Data Item: COSE_Countersignature * Data Item: COSE_Countersignature
* Semantics: COSE standalone counter signature * Semantics: COSE standalone V2 countersignature
* Reference: [[this document]] * Reference: [[this document]]
12.2. COSE Header Parameters Registry 13.2. COSE Header Parameters Registry
IANA created a registry titled "COSE Header Parameters" as part of IANA created a registry titled "COSE Header Parameters" as part of
processing [RFC8152]. IANA is requested to update the reference for processing [RFC8152]. IANA is requested to update the reference for
entries in the table from [RFC8152] to this document. entries in the table from [RFC8152] to this document.
Additionally, the type for the attribute CounterSignature0 is to be IANA is requested to register the following new items in the
registry.
+=================+=====+======================+========+================+
| 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 |
+-----------------+-----+----------------------+--------+----------------+
Table 7: New Common Header Parameters
Additionally, the type for the attribute Countersignature0 is to be
updated from 'bstr' to 'COSE_Countersignature0'. updated from 'bstr' to 'COSE_Countersignature0'.
IANA is requested to update the pointer for expert rview to [[this IANA is requested to update the pointer for expert rview to [[this
document]]. document]].
12.3. COSE Key Common Parameters Registry 13.3. COSE Key Common Parameters Registry
IANA created a registry titled "COSE Key Common Parameters" as part IANA created a registry titled "COSE Key Common Parameters" as part
of the processing of [RFC8152]. IANA is requested to update the of the processing of [RFC8152]. IANA is requested to update the
reference for entries in the table from [RFC8152] to this document. reference for entries in the table from [RFC8152] to this document.
IANA is requested to update the pointer for expert rview to [[this IANA is requested to update the pointer for expert rview to [[this
document]]. document]].
12.4. Media Type Registrations 13.4. Media Type Registrations
12.4.1. COSE Security Message
13.4.1. COSE Security Message
This section registers the 'application/cose' media type in the This section registers the 'application/cose' media type in the
"Media Types" registry. These media types are used to indicate that "Media Types" registry. These media types are used to indicate that
the content is a COSE message. the content is a COSE message.
Type name: application Type name: application
Subtype name: cose Subtype name: cose
Required parameters: N/A Required parameters: N/A
skipping to change at page 52, line 4 skipping to change at page 60, line 20
Person & email address to contact for further information: Person & email address to contact for further information:
iesg@ietf.org iesg@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Jim Schaad, ietf@augustcellars.com Author: Jim Schaad, ietf@augustcellars.com
Change Controller: IESG Change Controller: IESG
Provisional registration? No Provisional registration? No
12.4.2. COSE Key Media Type 13.4.2. COSE Key Media Type
This section registers the 'application/cose-key' and 'application/ This section registers the 'application/cose-key' and 'application/
cose-key-set' media types in the "Media Types" registry. These media cose-key-set' media types in the "Media Types" registry. These media
types are used to indicate, respectively, that content is a COSE_Key types are used to indicate, respectively, that content is a COSE_Key
or COSE_KeySet object. or COSE_KeySet object.
The template for registering 'application/cose-key' is: The template for registering 'application/cose-key' is:
Type name: application Type name: application
skipping to change at page 54, line 4 skipping to change at page 62, line 20
- File extension(s): cbor - File extension(s): cbor
- Macintosh file type code(s): N/A - Macintosh file type code(s): N/A
Person & email address to contact for further information: Person & email address to contact for further information:
iesg@ietf.org iesg@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Jim Schaad, ietf@augustcellars.com Author: Jim Schaad, ietf@augustcellars.com
Change Controller: IESG Change Controller: IESG
Provisional registration? No Provisional registration? No
12.5. CoAP Content-Formats Registry 13.5. CoAP Content-Formats Registry
IANA added entries to the "CoAP Content-Formats" registry while IANA added entries to the "CoAP Content-Formats" registry while
processing [RFC8152]. IANA is requested to update the reference processing [RFC8152]. IANA is requested to update the reference
value from [RFC8152] to [[This Document]]. value from [RFC8152] to [[This Document]].
12.6. Expert Review Instructions 13.6. Expert Review Instructions
All of the IANA registries established by [RFC8152] are, at least in All of the IANA registries established by [RFC8152] are, at least in
part, defined as expert review. This section gives some general part, defined as expert review. This section gives some general
guidelines for what the experts should be looking for, but they are guidelines for what the experts should be looking for, but they are
being designated as experts for a reason, so they should be given being designated as experts for a reason, so they should be given
substantial latitude. substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
* Point squatting should be discouraged. Reviewers are encouraged * Point squatting should be discouraged. Reviewers are encouraged
skipping to change at page 55, line 14 skipping to change at page 63, line 33
* When algorithms are registered, vanity registrations should be * When algorithms are registered, vanity registrations should be
discouraged. One way to do this is to require registrations to discouraged. One way to do this is to require registrations to
provide additional documentation on security analysis of the provide additional documentation on security analysis of the
algorithm. Another thing that should be considered is requesting algorithm. Another thing that should be considered is requesting
an opinion on the algorithm from the Crypto Forum Research Group an opinion on the algorithm from the Crypto Forum Research Group
(CFRG). Algorithms that do not meet the security requirements of (CFRG). Algorithms that do not meet the security requirements of
the community and the messages structures should not be the community and the messages structures should not be
registered. registered.
13. Security Considerations 14. Security Considerations
There are a number of security considerations that need to be taken There are a number of security considerations that need to be taken
into account by implementers of this specification. While some into account by implementers of this specification. While some
considerations have been highlighted here, additional considerations considerations have been highlighted here, additional considerations
may be found in the documents listed in the references. may be found in the documents listed in the references.
Implementations need to protect the private key material for any Implementations need to protect the private key material for any
individuals. There are some cases that need to be highlighted on individuals. There are some cases that need to be highlighted on
this issue. this issue.
skipping to change at page 56, line 47 skipping to change at page 65, line 21
specification does not provide for a uniform method of providing specification does not provide for a uniform method of providing
padding as part of the message structure. An observer can padding as part of the message structure. An observer can
distinguish between two different messages (for example, 'YES' and distinguish between two different messages (for example, 'YES' and
'NO') based on the length for all of the content encryption 'NO') based on the length for all of the content encryption
algorithms that are defined in [I-D.ietf-cose-rfc8152bis-algs] algorithms that are defined in [I-D.ietf-cose-rfc8152bis-algs]
document. This means that it is up to the applications to document 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 how content padding is to be done in order to prevent or discourage
such analysis. (For example, the text strings could be defined as such analysis. (For example, the text strings could be defined as
'YES' and 'NO '.) 'YES' and 'NO '.)
14. Implementation Status 15. Implementation Status
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
skipping to change at page 57, line 25 skipping to change at page 65, line 45
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to [RFC7942], "this will allow reviewers and working groups According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
14.1. Author's Versions 15.1. Author's Versions
There are three different implementations that have been created by There are three different implementations that have been created by
the author of the document both to create the examples that are the author of the document both to create the examples that are
included in the document and to validate the structures and included in the document and to validate the structures and
methodology used in the design of COSE. methodology used in the design of COSE.
* Implementation Location: https://github.com/cose-wg * Implementation Location: https://github.com/cose-wg
* Primary Maintainer: Jim Schaad * Primary Maintainer: Jim Schaad
* Languages: There are three different languages that are currently * Languages: There are three different languages that are currently
supported: Java, C# and C. supported: Java, C# and C.
* Cryptography: The Java and C# libraries use Bouncy Castle to * Cryptography: The Java and C# libraries use Bouncy Castle to
provide the required cryptography. The C version uses OPENSSL provide the required cryptography. The C version uses OPENSSL
Version 1.1 for the cryptography. Version 1.1 for the cryptography.
* Coverage: The C version currently does not have full counter sign * Coverage: The C version currently does not have full countersign
support. The other two versions do. They do have support to support. The other two versions do. They do have support to
allow for implicit algorithm support as they allow for the allow for implicit algorithm support as they allow for the
application to set attributes that are not to be sent in the application to set attributes that are not to be sent in the
message. message.
* Testing: All of the examples in the example library are generated * Testing: All of the examples in the example library are generated
by the C# library and then validated using the Java and C by the C# library and then validated using the Java and C
libraries. All three libraries have tests to allow for the libraries. All three libraries have tests to allow for the
creating of the same messages that are in the example library creating of the same messages that are in the example library
followed by validating them. These are not compared against the followed by validating them. These are not compared against the
example library. The Java and C# libraries have unit testing example library. The Java and C# libraries have unit testing
included. Not all of the MUST statements in the document have included. Not all of the MUST statements in the document have
been implemented as part of the libraries. One such statement is been implemented as part of the libraries. One such statement is
the requirement that unique labels be present. the requirement that unique labels be present.
* Licensing: Revised BSD License * Licensing: Revised BSD License
14.2. JavaScript Version 15.2. JavaScript Version
* Implementation Location: https://github.com/erdtman/cose-js * Implementation Location: https://github.com/erdtman/cose-js
* Primary Maintainer: Samuel Erdtman * Primary Maintainer: Samuel Erdtman
* Languages: JavaScript * Languages: JavaScript
* Cryptography: TBD * Cryptography: TBD
* Coverage: Full Encrypt, Signature and MAC objects are supported. * Coverage: Full Encrypt, Signature and MAC objects are supported.
* Testing: Basic testing against the common example library. * Testing: Basic testing against the common example library.
* Licensing: Apache License 2.0 * Licensing: Apache License 2.0
14.3. Python Version 15.3. Python Version
* Implementation Location: https://github.com/TimothyClaeys/COSE- * Implementation Location: https://github.com/TimothyClaeys/COSE-
PYTHON PYTHON
* Primary Maintainer: Timothy Claeys * Primary Maintainer: Timothy Claeys
* Languages: Python * Languages: Python
* Cryptography: pyecdsak, crypto python libraries * Cryptography: pyecdsak, crypto python libraries
* Coverage: TBD * Coverage: TBD
* Testing: Basic testing plus running against the common example * Testing: Basic testing plus running against the common example
library. library.
* Licensing: BSD 3-Clause License * Licensing: BSD 3-Clause License
14.4. COSE Testing Library 15.4. COSE Testing Library
* Implementation Location: https://github.com/cose-wg/Examples * Implementation Location: https://github.com/cose-wg/Examples
* Primary Maintainer: Jim Schaad * Primary Maintainer: Jim Schaad
* Description: A set of tests for the COSE library is provided as * Description: A set of tests for the COSE library is provided as
part of the implementation effort. Both success and fail tests part of the implementation effort. Both success and fail tests
have been provided. All of the examples in this document are part have been provided. All of the examples in this document are part
of this example set. of this example set.
* Coverage: An attempt has been made to have test cases for every * Coverage: An attempt has been made to have test cases for every
message type and algorithm in the document. Currently examples message type and algorithm in the document. Currently examples
dealing with counter signatures, and ECDH with Curve25519 and dealing with countersignatures, and ECDH with Curve25519 and
Goldilocks are missing. Goldilocks are missing.
* Licensing: Public Domain * Licensing: Public Domain
15. References 16. References
15.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [I-D.ietf-cbor-7049bis]
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Bormann, C. and P. Hoffman, "Concise Binary Object
October 2013, <https://www.rfc-editor.org/info/rfc7049>. Representation (CBOR)", Work in Progress, Internet-Draft,
draft-ietf-cbor-7049bis-14, 16 June 2020,
<https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-10, 26 June 2020, draft-ietf-cose-rfc8152bis-algs-11, 1 July 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
algs-10>. algs-11>.
15.2. Informative References 16.2. Informative References
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
Password-Based Cryptography Specification Version 2.1",
RFC 8018, DOI 10.17487/RFC8018, January 2017,
<https://www.rfc-editor.org/info/rfc8018>.
[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message
Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999,
<https://www.rfc-editor.org/info/rfc2633>. <https://www.rfc-editor.org/info/rfc2633>.
[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/ [RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/
Multipurpose Internet Mail Extensions (S/MIME) Multipurpose Internet Mail Extensions (S/MIME)
Capabilities", RFC 4262, DOI 10.17487/RFC4262, December Capabilities", RFC 4262, DOI 10.17487/RFC4262, December
2005, <https://www.rfc-editor.org/info/rfc4262>. 2005, <https://www.rfc-editor.org/info/rfc4262>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
skipping to change at page 62, line 30 skipping to change at page 70, line 46
Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998,
August 2007, <https://www.rfc-editor.org/info/rfc4998>. August 2007, <https://www.rfc-editor.org/info/rfc4998>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <https://www.rfc-editor.org/info/rfc3394>. September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[I-D.ietf-cose-hash-algs] [I-D.ietf-cose-hash-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Hash Algorithms", Work in Progress, Internet-Draft, draft- Hash Algorithms", Work in Progress, Internet-Draft, draft-
ietf-cose-hash-algs-04, 29 May 2020, ietf-cose-hash-algs-08, 29 July 2020,
<https://tools.ietf.org/html/draft-ietf-cose-hash-algs- <https://tools.ietf.org/html/draft-ietf-cose-hash-algs-
04>. 08>.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
00, 30 March 2020, <https://tools.ietf.org/html/draft- 01, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-
ietf-core-groupcomm-bis-00>. core-groupcomm-bis-01>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[I-D.irtf-cfrg-argon2] [I-D.irtf-cfrg-argon2]
Biryukov, A., Dinu, D., Khovratovich, D., and S. Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "The memory-hard Argon2 password hash and Josefsson, "The memory-hard Argon2 password hash and
proof-of-work function", Work in Progress, Internet-Draft, proof-of-work function", Work in Progress, Internet-Draft,
draft-irtf-cfrg-argon2-10, 25 March 2020, draft-irtf-cfrg-argon2-11, 9 July 2020,
<https://tools.ietf.org/html/draft-irtf-cfrg-argon2-10>. <https://tools.ietf.org/html/draft-irtf-cfrg-argon2-11>.
[COAP.Formats] [COAP.Formats]
IANA, "CoAP Content-Formats", IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters/core- <https://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#content-formats>. parameters.xhtml#content-formats>.
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>. cose.xhtml#algorithms>.
skipping to change at page 63, line 41 skipping to change at page 72, line 8
be smaller if the algorithm identifier is omitted from the most be smaller if the algorithm identifier is omitted from the most
common messages in a CoAP environment. Second, there is a potential common messages in a CoAP environment. Second, there is a potential
bug that will arise if full checking is not done correctly between bug that will arise if full checking is not done correctly between
the different places that an algorithm identifier could be placed the different places that an algorithm identifier could be placed
(the message itself, an application statement, the key structure that (the message itself, an application statement, the key structure that
the sender possesses, and the key structure the recipient possesses). the sender possesses, and the key structure the recipient possesses).
This appendix lays out how such a change can be made and the details This appendix lays out how such a change can be made and the details
that an application needs to specify in order to use this option. that an application needs to specify in order to use this option.
Two different sets of details are specified: those needed to omit an Two different sets of details are specified: those needed to omit an
algorithm identifier and those needed to use a variant on the counter algorithm identifier and those needed to use a variant on the
signature attribute that contains no attributes about itself. countersignature attribute that contains no attributes about itself.
Three sets of recommendations are laid out. The first set of Three sets of recommendations are laid out. The first set of
recommendations applies to having an implicit algorithm identified recommendations applies to having an implicit algorithm identified
for a single layer of a COSE object. The second set of for a single layer of a COSE object. The second set of
recommendations applies to having multiple implicit algorithms recommendations applies to having multiple implicit algorithms
identified for multiple layers of a COSE object. The third set of identified for multiple layers of a COSE object. The third set of
recommendations applies to having implicit algorithms for multiple recommendations applies to having implicit algorithms for multiple
COSE object constructs. COSE object constructs.
The key words from [RFC2119] are deliberately not used here. This The key words from [RFC2119] are deliberately not used here. This
skipping to change at page 66, line 17 skipping to change at page 74, line 39
distinct secret keys and IVs and potentially even different distinct secret keys and IVs and potentially even different
algorithms. One context is for sending messages from party A to algorithms. One context is for sending messages from party A to
party B, and the second context is for sending messages from party party B, and the second context is for sending messages from party
B to party A. This means that there is no chance for a reflection B to party A. This means that there is no chance for a reflection
attack to occur as each party uses different secret keys to send attack to occur as each party uses different secret keys to send
its messages; a message that is reflected back to it would fail to its messages; a message that is reflected back to it would fail to
decrypt. decrypt.
* Two contexts are distributed as a pair. The first context is used * Two contexts are distributed as a pair. The first context is used
for encryption of the message, and the second context is used to for encryption of the message, and the second context is used to
place a counter signature on the message. The intention is that place a countersignature on the message. The intention is that
the second context can be distributed to other entities the second context can be distributed to other entities
independently of the first context. This allows these entities to independently of the first context. This allows these entities to
validate that the message came from an individual without being validate that the message came from an individual without being
able to decrypt the message and see the content. able to decrypt the message and see the content.
* Two contexts are distributed as a pair. The first context * Two contexts are distributed as a pair. The first context
contains a key for dealing with MACed messages, and the second contains a key for dealing with MACed messages, and the second
context contains a different key for dealing with encrypted context contains a different key for dealing with encrypted
messages. This allows for a unified distribution of keys to messages. This allows for a unified distribution of keys to
participants for different types of messages that have different participants for different types of messages that have different
skipping to change at page 71, line 38 skipping to change at page 79, line 38
/ signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1 / signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1
de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024 de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024
7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030 7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030
c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f
83ab87bb4f7a0297' 83ab87bb4f7a0297'
] ]
] ]
] ]
) )
C.1.3. Counter Signature C.1.3. Countersignature
This example uses the following: This example uses the following:
* Signature Algorithm: ECDSA w/ SHA-256, Curve P-256 * Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
* The same header parameters are used for both the signature and the * The same header parameters are used for both the signature and the
counter signature. countersignature.
Size of binary file is 180 bytes Size of binary file is 180 bytes
98( 98(
[ [
/ protected / h'', / protected / h'',
/ unprotected / { / unprotected / {
/ countersign / 7:[ / countersign / 7:[
/ protected h'a10126' / << { / protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 / / alg / 1:-7 / ECDSA 256 /
} >>, } >>,
skipping to change at page 76, line 32 skipping to change at page 84, line 32
/ unprotected / { / unprotected / {
/ salt / -20:'aabbccddeeffgghh', / salt / -20:'aabbccddeeffgghh',
/ kid / 4:'our-secret' / kid / 4:'our-secret'
}, },
/ ciphertext / h'' / ciphertext / h''
] ]
] ]
] ]
) )
C.3.3. Counter Signature on Encrypted Content C.3.3. Countersignature on Encrypted Content
This example uses the following: This example uses the following:
* CEK: AES-GCM w/ 128-bit key * CEK: AES-GCM w/ 128-bit key
* Recipient class: ECDH Ephemeral-Static, Curve P-256 * Recipient class: ECDH Ephemeral-Static, Curve P-256
Size of binary file is 326 bytes Size of binary file is 326 bytes
96( 96(
[ [
 End of changes. 136 change blocks. 
333 lines changed or deleted 665 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/