draft-ietf-cose-rfc8152bis-struct-12.txt   draft-ietf-cose-rfc8152bis-struct-13.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) 24 August 2020 Obsoletes: 8152 (if approved) September 4, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 25 February 2021 Expires: March 8, 2021
CBOR Object Signing and Encryption (COSE): Structures and Process CBOR Object Signing and Encryption (COSE): Structures and Process
draft-ietf-cose-rfc8152bis-struct-12 draft-ietf-cose-rfc8152bis-struct-13
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 25 February 2021. This Internet-Draft will expire on March 8, 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 . . . . . . . . . . . . . . . . 9 1.5. CBOR-Related Terminology . . . . . . . . . . . . . . . . 8
1.6. Document Terminology . . . . . . . . . . . . . . . . . . 9 1.6. Document Terminology . . . . . . . . . . . . . . . . . . 9
2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 10 2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 10
3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 14 3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Common COSE Header Parameters . . . . . . . . . . . . . . 16 3.1. Common COSE Header Parameters . . . . . . . . . . . . . . 15
4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 20 4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Signing with One or More Signers . . . . . . . . . . . . 20 4.1. Signing with One or More Signers . . . . . . . . . . . . 18
4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 22 4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 20
4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 23 4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 21
4.4. Signing and Verification Process . . . . . . . . . . . . 24 4.4. Signing and Verification Process . . . . . . . . . . . . 22
5. Version 2 Countersignatures . . . . . . . . . . . . . . . . . 27 5. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 24
5.1. Full Countersignatures . . . . . . . . . . . . . . . . . 28 5.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 24
5.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 29 5.1.1. Content Key Distribution Methods . . . . . . . . . . 26
5.3. Signing and Verification Process . . . . . . . . . . . . 29 5.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 26
6. Countersignatures . . . . . . . . . . . . . . . . . . . . . . 32 5.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 27
6.1. Full Countersignatures . . . . . . . . . . . . . . . . . 33 5.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 29
6.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 34 6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 35 6.1. MACed Message with Recipients . . . . . . . . . . . . . . 31
7.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 35 6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 32
7.1.1. Content Key Distribution Methods . . . . . . . . . . 37 6.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 33
7.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 37 7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 38 7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 35
7.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 40 8. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 37
8. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 38
8.1. MACed Message with Recipients . . . . . . . . . . . . . . 42 8.2. Message Authentication Code (MAC) Algorithms . . . . . . 39
8.2. MACed Messages with Implicit Key . . . . . . . . . . . . 43 8.3. Content Encryption Algorithms . . . . . . . . . . . . . . 39
8.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 44 8.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 40
9. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.5. Content Key Distribution Methods . . . . . . . . . . . . 41
9.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 46 8.5.1. Direct Encryption . . . . . . . . . . . . . . . . . . 41
10. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 49 8.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 41
10.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 50 8.5.3. Key Transport . . . . . . . . . . . . . . . . . . . . 42
10.2. Message Authentication Code (MAC) Algorithms . . . . . . 51 8.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 42
10.3. Content Encryption Algorithms . . . . . . . . . . . . . 51 8.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . . 43
10.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . 52 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 44
10.5. Content Key Distribution Methods . . . . . . . . . . . . 53 10. Application Profiling Considerations . . . . . . . . . . . . 44
10.5.1. Direct Encryption . . . . . . . . . . . . . . . . . 53 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
10.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 53 11.1. COSE Header Parameters Registry . . . . . . . . . . . . 46
10.5.3. Key Transport . . . . . . . . . . . . . . . . . . . 54 11.2. COSE Key Common Parameters Registry . . . . . . . . . . 46
10.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 54 11.3. Media Type Registrations . . . . . . . . . . . . . . . . 46
10.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . 55 11.3.1. COSE Security Message . . . . . . . . . . . . . . . 46
11. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 56 11.3.2. COSE Key Media Type . . . . . . . . . . . . . . . . 47
12. Application Profiling Considerations . . . . . . . . . . . . 56 11.4. CoAP Content-Formats Registry . . . . . . . . . . . . . 49
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 11.5. Expert Review Instructions . . . . . . . . . . . . . . . 49
13.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . 58 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13.2. COSE Header Parameters Registry . . . . . . . . . . . . 58 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 52
13.3. COSE Key Common Parameters Registry . . . . . . . . . . 59 13.1. Author's Versions . . . . . . . . . . . . . . . . . . . 53
13.4. Media Type Registrations . . . . . . . . . . . . . . . . 59 13.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 53
13.4.1. COSE Security Message . . . . . . . . . . . . . . . 59 13.3. Python Version . . . . . . . . . . . . . . . . . . . . . 54
13.4.2. COSE Key Media Type . . . . . . . . . . . . . . . . 60 13.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 54
13.5. CoAP Content-Formats Registry . . . . . . . . . . . . . 62 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.6. Expert Review Instructions . . . . . . . . . . . . . . . 62 14.1. Normative References . . . . . . . . . . . . . . . . . . 54
14. Security Considerations . . . . . . . . . . . . . . . . . . . 63 14.2. Informative References . . . . . . . . . . . . . . . . . 55
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 65
15.1. Author's Versions . . . . . . . . . . . . . . . . . . . 65
15.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 66
15.3. Python Version . . . . . . . . . . . . . . . . . . . . . 66
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 . . . . . . . . . . . . . . . . . . . . . . . 71 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 59
Appendix B. Two Layers of Recipient Information . . . . . . . . 75 Appendix B. Two Layers of Recipient Information . . . . . . . . 62
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 76 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 64
C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 77 C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 64
C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 77 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 64
C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 78 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 65
C.1.3. Countersignature . . . . . . . . . . . . . . . . . . 79 C.1.3. Signature with Criticality . . . . . . . . . . . . . 66
C.1.4. Signature with Criticality . . . . . . . . . . . . . 80 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 67
C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 81 C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 67
C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 81 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 68
C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 82 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 68
C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 82 C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 69
C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 83 C.3.3. Encrypted Content with External Data . . . . . . . . 70
C.3.3. Countersignature on Encrypted Content . . . . . . . . 84 C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 71
C.3.4. Encrypted Content with External Data . . . . . . . . 85 C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 71
C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 86 C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 72
C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 86 C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 72
C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 87 C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 72
C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 87 C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 73
C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 87 C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 74
C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 88 C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 75
C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 89 C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 76
C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 90 C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 76
C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 91 C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 77
C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 91 C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 77
C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 92 C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 78
C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 92 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 80
C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 95
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)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the (CBOR)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the
JavaScript Object Notation (JSON) [STD90] by allowing for binary JavaScript Object Notation (JSON) [STD90] by allowing for binary
data, among other changes. CBOR has been adopted by several of the data, among other changes. CBOR has been adopted by several of the
IETF working groups dealing with the IoT world as their encoding of IETF working groups dealing with the IoT world as their encoding of
skipping to change at page 5, line 46 skipping to change at page 5, line 34
[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 12 provides additional information on based on those needs. Section 10 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
additional data fields as part of the structure. A one such additional data fields as part of the structure. A one such
application-specific element would be to include a URI or other application-specific element would be to include a URI or other
pointer to where the data that is being hashed can be obtained. pointer to where the data that is being hashed can be obtained.
[I-D.ietf-cose-hash-algs] contains one such possible structure along [I-D.ietf-cose-hash-algs] contains one such possible structure along
with defining a set of digest algorithms. with defining a set of digest algorithms.
During the process of advancing COSE to Internet Standard, it was
noticed the description of the security properties of
countersignatures was incorrect for the COSE_Sign1 structure. Since
the security properties that were described, those of a true
countersignature, were those that the working group desired, the
decision was made to remove all of the countersignature text from
this document and create a new document [I-D.ietf-cose-countersign]
to both deprecate the old countersignature algorithm and header
parameters and to define a new algorithm and header parameters with
the desired security properties.
1.1. Requirements Terminology 1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
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 countersignatures and define a CBOR Tag
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 * All of the details relating to countersignatures have been removed
the old one deprecrated. This includes defining new header and placed in [I-D.ietf-cose-countersign].
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 10, line 35 skipping to change at page 10, line 27
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 7.1). This message works, consider the COSE_Encrypt message (Section 5.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 7.2) is provided for the encryption message COSE_Encrypt0 (Section 5.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 11, line 18 skipping to change at page 11, line 7
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 Tag | cose-type | Data Item | Semantics |
| Tag | | | | +==========+===============+===============+=======================+
+=====+==================+=======================+==================+ | 98 | cose-sign | COSE_Sign | COSE Signed Data |
| 98 | cose-sign | COSE_Sign | COSE Signed Data | | | | | Object |
| | | | Object | +----------+---------------+---------------+-----------------------+
+-----+------------------+-----------------------+------------------+ | 18 | cose-sign1 | COSE_Sign1 | COSE Single Signer |
| 18 | cose-sign1 | COSE_Sign1 |COSE Single Signer| | | | | Data Object |
| | | | Data Object | +----------+---------------+---------------+-----------------------+
+-----+------------------+-----------------------+------------------+ | 96 | cose-encrypt | COSE_Encrypt | COSE Encrypted Data |
| 96 | cose-encrypt | COSE_Encrypt | COSE Encrypted | | | | | Object |
| | | | Data Object | +----------+---------------+---------------+-----------------------+
+-----+------------------+-----------------------+------------------+ | 16 | cose-encrypt0 | COSE_Encrypt0 | COSE Single Recipient |
| 16 | cose-encrypt0 | COSE_Encrypt0 | COSE Single | | | | | Encrypted Data Object |
| | | | Recipient | +----------+---------------+---------------+-----------------------+
| | | | Encrypted Data | | 97 | cose-mac | COSE_Mac | COSE MACed Data |
| | | | Object | | | | | Object |
+-----+------------------+-----------------------+------------------+ +----------+---------------+---------------+-----------------------+
| 97 | cose-mac | COSE_Mac | COSE MACed Data | | 17 | cose-mac0 | COSE_Mac0 | COSE Mac w/o |
| | | | Object | | | | | Recipients Object |
+-----+------------------+-----------------------+------------------+ +----------+---------------+---------------+-----------------------+
| 17 | cose-mac0 | COSE_Mac0 | COSE Mac w/o |
| | | |Recipients Object |
+-----+------------------+-----------------------+------------------+
|TBD00| cose-countersign | COSE_Countersignature |COSE standalone V2|
| | | | countersignature |
+-----+------------------+-----------------------+------------------+
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 43 skipping to change at page 12, line 43
Table 2: CoAP Content-Formats for COSE Table 2: CoAP Content-Formats for COSE
The following CDDL fragment identifies all of the top messages The following CDDL fragment identifies all of the top messages
defined in this document. Separate non-terminals are defined for the defined in this document. Separate non-terminals are defined for the
tagged and the untagged versions of the messages. tagged and the untagged versions of the messages.
COSE_Messages = COSE_Untagged_Message / COSE_Tagged_Message COSE_Messages = COSE_Untagged_Message / COSE_Tagged_Message
COSE_Untagged_Message = COSE_Sign / COSE_Sign1 / COSE_Untagged_Message = COSE_Sign / COSE_Sign1 /
COSE_Encrypt / COSE_Encrypt0 / COSE_Encrypt / COSE_Encrypt0 /
COSE_Mac / COSE_Mac0 / COSE_Countersignature COSE_Mac / COSE_Mac0
COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged / COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /
COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged / COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /
COSE_Mac_Tagged / COSE_Mac0_Tagged / COSE_Countersignature_Tagged COSE_Mac_Tagged / COSE_Mac0_Tagged
3. Header Parameters 3. Header Parameters
The structure of COSE has been designed to have two buckets of The structure of COSE has been designed to have two buckets of
information that are not considered to be part of the payload itself, information that are not considered to be part of the payload itself,
but are used for holding information about content, algorithms, keys, but are used for holding information about content, algorithms, keys,
or evaluation hints for the processing of the layer. These two or evaluation hints for the processing of the layer. These two
buckets are available for use in all of the structures except for buckets are available for use in all of the structures except for
keys. While these buckets are present, they may not always be usable keys. While these buckets are present, they may not always be usable
in all instances. For example, while the protected bucket is defined in all instances. For example, while the protected bucket is defined
skipping to change at page 14, line 25 skipping to change at page 13, 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 13.2). (Section 11.1).
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 15, line 20 skipping to change at page 14, 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 13.2). Some header parameters are Parameters" registry (Section 11.1). 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 18, line 12 skipping to change at page 17, 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.
countersignature: This header parameter holds one or more +=========+=======+========+=====================+==================+
countersignature values. Countersignatures provide a method of | Name | Label | Value | Value Registry | Description |
having a second party sign some data. The countersignature header | | | Type | | |
parameter can occur as an unprotected attribute in any of the +=========+=======+========+=====================+==================+
following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, | alg | 1 | int / | COSE Algorithms | Cryptographic |
COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. These | | | tstr | registry | algorithm to use |
structures all have the same beginning elements, so that a +---------+-------+--------+---------------------+------------------+
consistent calculation of the countersignature can be computed. | crit | 2 | [+ | COSE Header | Critical header |
Details on countersignatures are found in Section 6. This header | | | label] | Parameters | parameters to be |
parameter has been deprecated in favor of the V2 countersignature. | | | | registry | understood |
+---------+-------+--------+---------------------+------------------+
V2 countersignature: This header parameter holds one or more | content | 3 | tstr / | CoAP Content- | Content type of |
countersignature values. Countersignatures provide a method of | type | | uint | Formats or Media | the payload |
having a second party sign some data. The countersignature header | | | | Types registries | |
parameter can occur as an unprotected attribute in any of the +---------+-------+--------+---------------------+------------------+
following structures: COSE_Sign1, COSE_Signature, COSE_Encrypt, | kid | 4 | bstr | | Key identifier |
COSE_recipient, COSE_Encrypt0, COSE_Mac, and COSE_Mac0. Details +---------+-------+--------+---------------------+------------------+
on version 2 countersignatures are found in Section 5. | IV | 5 | bstr | | Full |
| | | | | Initialization |
+=========+=====+========================+==========+===============+ | | | | | Vector |
| Name |Label| Value Type | Value | Description | +---------+-------+--------+---------------------+------------------+
| | | | Registry | | | Partial | 6 | bstr | | Partial |
+=========+=====+========================+==========+===============+ | IV | | | | Initialization |
| alg | 1 | int / tstr | COSE | Cryptographic | | | | | | Vector |
| | | |Algorithms| algorithm to | +---------+-------+--------+---------------------+------------------+
| | | | registry | use |
+---------+-----+------------------------+----------+---------------+
| crit | 2 | [+ label] | COSE |Critical header|
| | | | Header | parameters to |
| | | |Parameters| be understood |
| | | | registry | |
+---------+-----+------------------------+----------+---------------+
| content | 3 | tstr / uint | CoAP |Content type of|
| type | | | Content- | the payload |
| | | |Formats or| |
| | | | Media | |
| | | | Types | |
| | | |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] ; 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. An examples of a header parameter about the signature
be the algorithm and key used to create the signature and would be the algorithm and key used to create the signature.
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 21, line 50 skipping to change at page 19, line 39
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 10.1), the maximum number of bytes that can be recovered (Section 8.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 24, line 36 skipping to change at page 22, line 20
* 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:
"Signature" for signatures using the COSE_Signature structure. "Signature" for signatures using the COSE_Signature structure.
"Signature1" for signatures using the COSE_Sign1 structure. "Signature1" for signatures using the COSE_Sign1 structure.
"CounterSignature" for signatures using the
COSE_Countersignature structure.
"CounterSignature0" for signatures used as
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.
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:
Sig_structure = [ Sig_structure = [
context : "Signature" / "Signature1" / "CounterSignature" / context : "Signature" / "Signature1",
"CounterSignature0",
body_protected : empty_or_serialized_map, body_protected : empty_or_serialized_map,
? sign_protected : empty_or_serialized_map, ? sign_protected : empty_or_serialized_map,
external_aad : bstr, external_aad : bstr,
payload : bstr payload : bstr
] ]
A countersignature, like a signature needs a well-defined byte
string. The process uses the same Sig_structure but fills it in
slightly differently. The signing and verification process takes in
the target information (COSE_Sign, COSE_Sign1, COSE_Mac, COSE_Mac0,
COSE_Encrypt, COSE_Encrypt0, COSE_Recipient, and
COSE_Countersignature), the signer information (COSE_Signature) and
the application data (external source). 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
Sig_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.
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 11. byte string, using the encoding described in Section 9.
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 or COSE_Sign1
or COSE_Countersignature structures. This is the value of the structure.
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 11. byte string, using the encoding described in Section 9.
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.
5. Version 2 Countersignatures
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 either the COSE_Signature or COSE_Sign1 objects
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.
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
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 or COSE_Sign0, 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_Sign, this is the same as applying a second signature to the
payload and adding a parallel signature as a new COSE_Signature is
the preferred method. When done on a COSE_Mac or COSE_Mac0, the
payload is included as well as the MAC value. 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.
5.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].
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 countersignature structure is the same as that used for a signer
on a signed object. The CDDL fragment for full countersignatures is:
COSE_Countersignature_Tagged = #6.9999(COSE_Countersignature)
COSE_Countersignature = COSE_Signature
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.
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.
5.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 was 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.
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.
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 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.
6. Countersignatures 5. Encryption Objects
| 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.
| 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|
+==================+=====+========================+=====+===========+
|Countersignature0 | 9 | COSE_Countersignature0 | |Abbreviated|
| | | | | Counter |
| | | | | signature |
+------------------+-----+------------------------+-----+-----------+
Table 4: Header Parameter for Countersignature0
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.
7.1. Enveloped COSE Structure 5.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 37, line 14 skipping to change at page 26, line 5
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]
] ]
7.1.1. Content Key Distribution Methods 5.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 10.5. A short summary of the five content key distribution Section 8.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.
7.2. Single Recipient Encrypted 5.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 38, line 19 skipping to change at page 27, line 9
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 7.1. ciphertext: This is as described in Section 5.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,
] ]
7.3. How to Encrypt and Decrypt for AEAD Algorithms 5.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 39, line 33 skipping to change at page 28, line 21
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 11. Section 9.
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 10.5.3), key wrap keys (Section 10.5.2), or pre- (Section 8.5.3), key wrap keys (Section 8.5.2), or pre-shared
shared secrets. 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 40, line 19 skipping to change at page 29, line 6
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 11. encoding described in Section 9.
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 10.5.3), key wrap keys (Section 10.5.2), or pre- (Section 8.5.3), key wrap keys (Section 8.5.2), or pre-shared
shared secrets. 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.
7.4. How to Encrypt and Decrypt for AE Algorithms 5.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 10.5.3), key wrap keys (Section 10.5.2), or pre- (Section 8.5.3), key wrap keys (Section 8.5.2), or pre-shared
shared secrets. 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 41, line 40 skipping to change at page 30, line 27
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 10.5.3), key wrap keys (Section 10.5.2), or pre- (Section 8.5.3), key wrap keys (Section 8.5.2), or pre-shared
shared secrets. 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).
8. MAC Objects 6. 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 42, line 35 skipping to change at page 31, line 24
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.
8.1. MACed Message with Recipients 6.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 7.1) to hold the key used for the COSE_recipient structure (Section 5.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 43, line 20 skipping to change at page 32, line 14
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 7.1. recipients: This is as described in Section 5.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]
] ]
8.2. MACed Messages with Implicit Key 6.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 44, line 7 skipping to change at page 32, line 50
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 8.1. payload: This is as described in Section 6.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,
] ]
8.3. How to Compute and Verify a MAC 6.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 45, line 9 skipping to change at page 34, line 6
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 11. byte string, using the encoding described in Section 9.
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 11. byte string, using the encoding described in Section 9.
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.
9. Key Objects 7. 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 13.3). Additional "COSE Key Common Parameters" registry (Section 11.2). 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 46, line 25 skipping to change at page 35, line 20
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]
9.1. COSE Key Common Parameters 7.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 4 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 | |
+=========+=======+========+============+====================+ +=========+=======+========+============+====================+
| kty | 1 | tstr / | COSE Key | Identification of | | kty | 1 | tstr / | COSE Key | Identification of |
| | | int | Types | the key type | | | | int | Types | the key type |
skipping to change at page 47, line 29 skipping to change at page 35, line 52
+---------+-------+--------+------------+--------------------+ +---------+-------+--------+------------+--------------------+
| key_ops | 4 | [+ | | Restrict set of | | key_ops | 4 | [+ | | Restrict set of |
| | | (tstr/ | | permissible | | | | (tstr/ | | permissible |
| | | int)] | | operations | | | | int)] | | operations |
+---------+-------+--------+------------+--------------------+ +---------+-------+--------+------------+--------------------+
| Base IV | 5 | bstr | | Base IV to be xor- | | Base IV | 5 | bstr | | Base IV to be xor- |
| | | | | ed with Partial | | | | | | ed with Partial |
| | | | | IVs | | | | | | IVs |
+---------+-------+--------+------------+--------------------+ +---------+-------+--------+------------+--------------------+
Table 5: Key Map Labels Table 4: Key Map Labels
kty: This parameter is used to identify the family of keys for this kty: This parameter is used to identify the family of keys for this
structure and, thus, the set of key-type-specific parameters to be structure and, thus, the set of key-type-specific parameters to be
found. The set of values defined in this document can be found in found. The set of values defined in this document can be found in
[COSE.KeyTypes]. This parameter MUST be present in a key object. [COSE.KeyTypes]. This parameter MUST be present in a key object.
Implementations MUST verify that the key type is appropriate for Implementations MUST verify that the key type is appropriate for
the algorithm being processed. The key type MUST be included as the algorithm being processed. The key type MUST be included as
part of the trust decision process. part of the trust decision process.
alg: This parameter is used to restrict the algorithm that is used alg: This parameter is used to restrict the algorithm that is used
skipping to change at page 48, line 11 skipping to change at page 36, line 34
identifier is not structured and can be anything from a user- identifier is not structured and can be anything from a user-
provided byte string to a value computed on the public portion of provided byte string to a value computed on the public portion of
the key. This field is intended for matching against a 'kid' the key. This field is intended for matching against a 'kid'
parameter in a message in order to filter down the set of keys parameter in a message in order to filter down the set of keys
that need to be checked. The value of the identifier is not a that need to be checked. The value of the identifier is not a
unique value and can occur in other key objects, even for unique value and can occur in other key objects, even for
different keys. different keys.
key_ops: This parameter is defined to restrict the set of operations key_ops: This parameter is defined to restrict the set of operations
that a key is to be used for. The value of the field is an array that a key is to be used for. The value of the field is an array
of values from Table 6. Algorithms define the values of key ops of values from Table 5. Algorithms define the values of key ops
that are permitted to appear and are required for specific that are permitted to appear and are required for specific
operations. The set of values matches that in [RFC7517] and operations. The set of values matches that in [RFC7517] and
[W3C.WebCrypto]. [W3C.WebCrypto].
Base IV: This parameter is defined to carry the base portion of an Base IV: This parameter is defined to carry the base portion of an
IV. It is designed to be used with the Partial IV header IV. It is designed to be used with the Partial IV header
parameter defined in Section 3.1. This field provides the ability parameter defined in Section 3.1. This field provides the ability
to associate a Base IV with a key that is then modified on a per to associate a Base IV with a key that is then modified on a per
message basis with the Partial IV. message basis with the Partial IV.
skipping to change at page 49, line 39 skipping to change at page 37, line 42
| derive | 8 | The key is used for deriving bits not to be | | derive | 8 | The key is used for deriving bits not to be |
| bits | | used as a key. Requires private key fields. | | bits | | used as a key. Requires private key fields. |
+---------+-------+----------------------------------------------+ +---------+-------+----------------------------------------------+
| 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 5: Key Operation Values
10. Taxonomy of Algorithms used by COSE 8. 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.
10.1. Signature Algorithms 8.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 51, line 11 skipping to change at page 39, 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.
10.2. Message Authentication Code (MAC) Algorithms 8.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 51, line 35 skipping to change at page 39, 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.
10.3. Content Encryption Algorithms 8.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 52, line 16 skipping to change at page 40, 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.
10.4. Key Derivation Functions (KDFs) 8.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 53, line 5 skipping to change at page 41, 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.
10.5. Content Key Distribution Methods 8.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.
10.5.1. Direct Encryption 8.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 53, line 37 skipping to change at page 41, 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.
10.5.2. Key Wrap 8.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 54, line 21 skipping to change at page 42, 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.
10.5.3. Key Transport 8.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.
10.5.4. Direct Key Agreement 8.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 55, line 39 skipping to change at page 43, 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.
10.5.5. Key Agreement with Key Wrap 8.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 56, line 14 skipping to change at page 44, 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.
11. CBOR Encoding Restrictions 9. 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.
12. Application Profiling Considerations 10. 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 58, line 5 skipping to change at page 46, 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]).
13. IANA Considerations 11. 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.
13.1. CBOR Tag Assignment 11.1. COSE Header Parameters Registry
IANA assigned tags in the "CBOR Tags" registry as part of processing
[RFC8152]. IANA is requested to update the references from [RFC8152]
to this document.
IANA is requested to register a new tag for the CounterSignature
type.
* Tag: TBD0
* Data Item: COSE_Countersignature
* Semantics: COSE standalone V2 countersignature
* Reference: [[this document]]
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. all entries, except "counter signature" and "CounterSignature0", in
the table from [RFC8152] to this document. The reference for
IANA is requested to register the following new items in the "counter signature" and "CounterSignature0" are to be left alone.
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'.
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]].
13.3. COSE Key Common Parameters Registry 11.2. 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]].
13.4. Media Type Registrations 11.3. Media Type Registrations
13.4.1. COSE Security Message 11.3.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 60, line 23 skipping to change at page 47, line 34
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
13.4.2. COSE Key Media Type 11.3.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 62, line 27 skipping to change at page 49, line 39
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
13.5. CoAP Content-Formats Registry 11.4. 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]].
13.6. Expert Review Instructions 11.5. 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 63, line 33 skipping to change at page 50, line 43
* 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.
14. Security Considerations 12. 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 65, line 21 skipping to change at page 52, line 26
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 '.)
15. Implementation Status 13. 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 65, line 45 skipping to change at page 53, line 5
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".
15.1. Author's Versions 13.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 countersign * Coverage: All versions have support to allow for implicit
support. The other two versions do. They do have support to algorithm support as they allow for the application to set
allow for implicit algorithm support as they allow for the attributes that are not to be sent in the message.
application to set attributes that are not to be sent in the
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
15.2. JavaScript Version 13.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
15.3. Python Version 13.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
15.4. COSE Testing Library 13.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 countersignatures, and ECDH with Curve25519 and dealing with ECDH with Goldilocks are missing.
Goldilocks are missing.
* Licensing: Public Domain * Licensing: Public Domain
16. References 14. References
16.1. Normative References 14.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>.
[I-D.ietf-cbor-7049bis] [I-D.ietf-cbor-7049bis]
Bormann, C. and P. Hoffman, "Concise Binary Object Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", Work in Progress, Internet-Draft, Representation (CBOR)", Work in Progress, Internet-Draft,
draft-ietf-cbor-7049bis-14, 16 June 2020, draft-ietf-cbor-7049bis-14, June 16, 2020,
<https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14>. <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-11, 1 July 2020, draft-ietf-cose-rfc8152bis-algs-11, July 1, 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
algs-11>. algs-11>.
16.2. Informative References 14.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>.
skipping to change at page 70, line 35 skipping to change at page 57, line 43
[RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
and Encryption (COSE) Messages", RFC 8230, and Encryption (COSE) Messages", RFC 8230,
DOI 10.17487/RFC8230, September 2017, DOI 10.17487/RFC8230, September 2017,
<https://www.rfc-editor.org/info/rfc8230>. <https://www.rfc-editor.org/info/rfc8230>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998, DOI 10.17487/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-08, 29 July 2020, ietf-cose-hash-algs-08, July 29, 2020,
<https://tools.ietf.org/html/draft-ietf-cose-hash-algs- <https://tools.ietf.org/html/draft-ietf-cose-hash-algs-
08>. 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-
01, 13 July 2020, <https://tools.ietf.org/html/draft-ietf- 01, July 13, 2020, <https://tools.ietf.org/html/draft-
core-groupcomm-bis-01>. ietf-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-11, 9 July 2020, draft-irtf-cfrg-argon2-11, July 9, 2020,
<https://tools.ietf.org/html/draft-irtf-cfrg-argon2-11>. <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/
skipping to change at page 71, line 40 skipping to change at page 58, line 44
[COSE.KeyParameters] [COSE.KeyParameters]
IANA, "COSE Key Parameters", IANA, "COSE Key Parameters",
<https://www.iana.org/assignments/cose/cose.xhtml#key- <https://www.iana.org/assignments/cose/cose.xhtml#key-
common-parameters>. common-parameters>.
[COSE.KeyTypes] [COSE.KeyTypes]
IANA, "COSE Key Types", IANA, "COSE Key Types",
<https://www.iana.org/assignments/cose/cose.xhtml#key- <https://www.iana.org/assignments/cose/cose.xhtml#key-
type>. type>.
[I-D.ietf-cose-countersign]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures".
Appendix A. Guidelines for External Data Authentication of Algorithms Appendix A. Guidelines for External Data Authentication of Algorithms
During development of COSE, the requirement that the algorithm During development of COSE, the requirement that the algorithm
identifier be located in the protected attributes was relaxed from a identifier be located in the protected attributes was relaxed from a
must to a should. There were two basic reasons that have been must to a should. There were two basic reasons that have been
advanced to support this position. First, the resulting message will advanced to support this position. First, the resulting message will
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 algorithm identifier and those needed to use the variant on the
countersignature 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.
skipping to change at page 79, line 38 skipping to change at page 66, line 38
/ signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1 / signature / h'00a2d28a7c2bdb1587877420f65adf7d0b9a06635dd1
de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024 de64bb62974c863f0b160dd2163734034e6ac003b01e8705524c5c4ca479a952f024
7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030 7ee8cb0b4fb7397ba08d009e0c8bf482270cc5771aa143966e5a469a09f613488030
c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f c5b07ec6d722e3835adb5b2d8c44e95ffb13877dd2582866883535de3bb03d01753f
83ab87bb4f7a0297' 83ab87bb4f7a0297'
] ]
] ]
] ]
) )
C.1.3. Countersignature C.1.3. Signature with Criticality
This example uses the following:
* Signature Algorithm: ECDSA w/ SHA-256, Curve P-256
* The same header parameters are used for both the signature and the
countersignature.
Size of binary file is 180 bytes
98(
[
/ protected / h'',
/ unprotected / {
/ countersign / 7:[
/ protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 /
} >>,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'5ac05e289d5d0e1b0a7f048a5d2b643813ded50bc9e4
9220f4f7278f85f19d4a77d655c9d3b51e805a74b099e1e085aacd97fc29d72f887e
8802bb6650cceb2c'
]
},
/ payload / 'This is the content.',
/ signatures / [
[
/ protected h'a10126' / << {
/ alg / 1:-7 / ECDSA 256 /
} >>,
/ unprotected / {
/ kid / 4:'11'
},
/ signature / h'e2aeafd40d69d19dfe6e52077c5d7ff4e408282cbefb
5d06cbf414af2e19d982ac45ac98b8544c908b4507de1e90b717c3d34816fe926a2b
98f53afd2fa0f30a'
]
]
]
)
C.1.4. Signature with Criticality
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
* There is a criticality marker on the "reserved" header parameter * There is a criticality marker on the "reserved" header parameter
Size of binary file is 125 bytes Size of binary file is 125 bytes
98( 98(
[ [
skipping to change at page 84, line 32 skipping to change at page 70, 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. Countersignature on Encrypted Content C.3.3. Encrypted Content with External Data
This example uses the following:
* CEK: AES-GCM w/ 128-bit key
* Recipient class: ECDH Ephemeral-Static, Curve P-256
Size of binary file is 326 bytes
96(
[
/ protected h'a10101' / << {
/ alg / 1:1 / AES-GCM 128 /
} >>,
/ unprotected / {
/ iv / 5:h'c9cf4df2fe6c632bf7886413',
/ countersign / 7:[
/ protected / h'a1013823' / {
\ alg \ 1:-36
} / ,
/ unprotected / {
/ kid / 4:'bilbo.baggins@hobbiton.example'
},
/ signature / h'00929663c8789bb28177ae28467e66377da12302d7f9
594d2999afa5dfa531294f8896f2b6cdf1740014f4c7f1a358e3a6cf57f4ed6fb02f
cf8f7aa989f5dfd07f0700a3a7d8f3c604ba70fa9411bd10c2591b483e1d2c31de00
3183e434d8fba18f17a4c7e3dfa003ac1cf3d30d44d2533c4989d3ac38c38b71481c
c3430c9d65e7ddff'
]
},
/ ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
/ recipients / [
[
/ protected h'a1013818' / << {
/ alg / 1:-25 / ECDH-ES + HKDF-256 /
} >> ,
/ unprotected / {
/ ephemeral / -1:{
/ kty / 1:2,
/ crv / -1:1,
/ x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
/ y / -3:true
},
/ kid / 4:'meriadoc.brandybuck@buckland.example'
},
/ ciphertext / h''
]
]
]
)
C.3.4. Encrypted Content with External Data
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 static-Static, Curve P-256 with AES Key Wrap * Recipient class: ECDH static-Static, Curve P-256 with AES Key Wrap
* Externally Supplied AAD: h'0011bbcc22dd44ee55ff660077' * Externally Supplied AAD: h'0011bbcc22dd44ee55ff660077'
Size of binary file is 173 bytes Size of binary file is 173 bytes
 End of changes. 106 change blocks. 
869 lines changed or deleted 244 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/