draft-ietf-cose-rfc8152bis-struct-08.txt   draft-ietf-cose-rfc8152bis-struct-09.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) 9 March 2020 Obsoletes: 8152 (if approved) 14 May 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 10 September 2020 Expires: 15 November 2020
CBOR Object Signing and Encryption (COSE): Structures and Process CBOR Object Signing and Encryption (COSE): Structures and Process
draft-ietf-cose-rfc8152bis-struct-08 draft-ietf-cose-rfc8152bis-struct-09
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 10 September 2020. This Internet-Draft will expire on 15 November 2020.
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 38 skipping to change at page 2, line 38
1.6. Document Terminology . . . . . . . . . . . . . . . . . . 8 1.6. Document Terminology . . . . . . . . . . . . . . . . . . 8
2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 9 2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 9
3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 13 3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Common COSE Header Parameters . . . . . . . . . . . . . . 15 3.1. Common COSE Header Parameters . . . . . . . . . . . . . . 15
4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 18 4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Signing with One or More Signers . . . . . . . . . . . . 18 4.1. Signing with One or More Signers . . . . . . . . . . . . 18
4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 20 4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 20
4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 21 4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 21
4.4. Signing and Verification Process . . . . . . . . . . . . 22 4.4. Signing and Verification Process . . . . . . . . . . . . 22
5. Counter Signatures . . . . . . . . . . . . . . . . . . . . . 24 5. Counter Signatures . . . . . . . . . . . . . . . . . . . . . 24
5.1. Full Countersignatures . . . . . . . . . . . . . . . . . 24 5.1. Full Counter Signatures . . . . . . . . . . . . . . . . . 25
5.2. Abbreviated Countersignatures . . . . . . . . . . . . . . 25 5.2. Abbreviated Counter Signatures . . . . . . . . . . . . . 25
6. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 26 6. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 26
6.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 26 6.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 26
6.1.1. Content Key Distribution Methods . . . . . . . . . . 28 6.1.1. Content Key Distribution Methods . . . . . . . . . . 28
6.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 28 6.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 29
6.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 29 6.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 29
6.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 31 6.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 32
7. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. MACed Message with Recipients . . . . . . . . . . . . . . 33 7.1. MACed Message with Recipients . . . . . . . . . . . . . . 34
7.2. MACed Messages with Implicit Key . . . . . . . . . . . . 34 7.2. MACed Messages with Implicit Key . . . . . . . . . . . . 35
7.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 35 7.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 35
8. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 37 8.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 37
9. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 39 9. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 40
9.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 40 9.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 41
9.2. Message Authentication Code (MAC) Algorithms . . . . . . 41 9.2. Message Authentication Code (MAC) Algorithms . . . . . . 42
9.3. Content Encryption Algorithms . . . . . . . . . . . . . . 41 9.3. Content Encryption Algorithms . . . . . . . . . . . . . . 42
9.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 42 9.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 43
9.5. Content Key Distribution Methods . . . . . . . . . . . . 43 9.5. Content Key Distribution Methods . . . . . . . . . . . . 44
9.5.1. Direct Encryption . . . . . . . . . . . . . . . . . . 43 9.5.1. Direct Encryption . . . . . . . . . . . . . . . . . . 44
9.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 43 9.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 44
9.5.3. Key Transport . . . . . . . . . . . . . . . . . . . . 44 9.5.3. Key Transport . . . . . . . . . . . . . . . . . . . . 45
9.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 44 9.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 45
9.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . . 45 9.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . . 46
10. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 46 10. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 47
11. Application Profiling Considerations . . . . . . . . . . . . 46 11. Application Profiling Considerations . . . . . . . . . . . . 47
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . 48 12.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . 49
12.2. COSE Header Parameters Registry . . . . . . . . . . . . 48 12.2. COSE Header Parameters Registry . . . . . . . . . . . . 49
12.3. COSE Header Algorithm Parameters Registry . . . . . . . 48 12.3. COSE Header Algorithm Parameters Registry . . . . . . . 49
12.4. COSE Key Common Parameters Registry . . . . . . . . . . 48 12.4. COSE Key Common Parameters Registry . . . . . . . . . . 49
12.5. Media Type Registrations . . . . . . . . . . . . . . . . 49 12.5. Media Type Registrations . . . . . . . . . . . . . . . . 50
12.5.1. COSE Security Message . . . . . . . . . . . . . . . 49 12.5.1. COSE Security Message . . . . . . . . . . . . . . . 50
12.5.2. COSE Key Media Type . . . . . . . . . . . . . . . . 50 12.5.2. COSE Key Media Type . . . . . . . . . . . . . . . . 51
12.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 52 12.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 53
13. Security Considerations . . . . . . . . . . . . . . . . . . . 52 13. Security Considerations . . . . . . . . . . . . . . . . . . . 53
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 54 14. Implementation Status . . . . . . . . . . . . . . . . . . . . 55
14.1. Author's Versions . . . . . . . . . . . . . . . . . . . 54 14.1. Author's Versions . . . . . . . . . . . . . . . . . . . 55
14.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 55 14.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 56
14.3. Python Version . . . . . . . . . . . . . . . . . . . . . 55 14.3. Python Version . . . . . . . . . . . . . . . . . . . . . 56
14.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 56 14.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 57
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
15.1. Normative References . . . . . . . . . . . . . . . . . . 56 15.1. Normative References . . . . . . . . . . . . . . . . . . 57
15.2. Informative References . . . . . . . . . . . . . . . . . 57 15.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Guidelines for External Data Authentication of Appendix A. Guidelines for External Data Authentication of
Algorithms . . . . . . . . . . . . . . . . . . . . . . . 60 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 61
Appendix B. Two Layers of Recipient Information . . . . . . . . 63 Appendix B. Two Layers of Recipient Information . . . . . . . . 64
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 65 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 66
C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 66 C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 67
C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 66 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 67
C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 67 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 68
C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 68 C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 69
C.1.4. Signature with Criticality . . . . . . . . . . . . . 69 C.1.4. Signature with Criticality . . . . . . . . . . . . . 70
C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 70 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 71
C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 70 C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 71
C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 71 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 72
C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 71 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 72
C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 72 C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 73
C.3.3. Counter Signature on Encrypted Content . . . . . . . 73 C.3.3. Counter Signature on Encrypted Content . . . . . . . 74
C.3.4. Encrypted Content with External Data . . . . . . . . 74 C.3.4. Encrypted Content with External Data . . . . . . . . 75
C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 75 C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 76
C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 75 C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 76
C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 76 C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 77
C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 76 C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 77
C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 76 C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 77
C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 77 C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 78
C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 78 C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 79
C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 79 C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 80
C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 80 C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 81
C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 80 C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 81
C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 81 C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 82
C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 81 C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 82
C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 82 C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 83
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 85
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
There has been an increased focus on small, constrained devices that There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT). One of the standards that has make up the Internet of Things (IoT). One of the standards that has
come out of this process is "Concise Binary Object Representation come out of this process is "Concise Binary Object Representation
(CBOR)" [RFC7049]. CBOR extended the data model of the JavaScript (CBOR)" [RFC7049]. CBOR extended the data model of the JavaScript
Object Notation (JSON) [RFC8259] by allowing for binary data, among Object Notation (JSON) [RFC8259] by allowing for binary data, among
other changes. CBOR has been adopted by several of the IETF working other changes. CBOR has been adopted by several of the IETF working
groups dealing with the IoT world as their encoding of data groups dealing with the IoT world as their encoding of data
structures. CBOR was designed specifically to be both small in terms structures. CBOR was designed specifically both to be small in terms
of messages transport and implementation size and be a schema-free of messages transported and implementation size and be a schema-free
decoder. A need exists to provide message security services for IoT, decoder. A need exists to provide message security services for IoT,
and using CBOR as the message-encoding format makes sense. and using CBOR as the message-encoding format makes sense.
The JOSE working group produced a set of documents [RFC7515] The JOSE working group produced a set of documents [RFC7515]
[RFC7516] [RFC7517] [RFC7518] using JSON that specified how to [RFC7516] [RFC7517] [RFC7518] that specified how to process
process encryption, signatures, and Message Authentication Code (MAC) encryption, signatures, and Message Authentication Code (MAC)
operations and how to encode keys using JSON. This document along operations and how to encode keys using JSON. This document along
with [I-D.ietf-cose-rfc8152bis-algs] defines the CBOR Object Signing with [I-D.ietf-cose-rfc8152bis-algs] defines the CBOR Object Signing
and Encryption (COSE) standard, which does the same thing for the and Encryption (COSE) standard, which does the same thing for the
CBOR encoding format. While there is a strong attempt to keep the CBOR encoding format. While there is a strong attempt to keep the
flavor of the original JSON Object Signing and Encryption (JOSE) flavor of the original JSON Object Signing and Encryption (JOSE)
documents, two considerations are taken into account: documents, two considerations are taken into account:
* CBOR has capabilities that are not present in JSON and are * CBOR has capabilities that are not present in JSON and are
appropriate to use. One example of this is the fact that CBOR has appropriate to use. One example of this is the fact that CBOR has
a method of encoding binary directly without first converting it a method of encoding binary directly without first converting it
skipping to change at page 5, line 35 skipping to change at page 5, line 35
One feature that is present in CMS [RFC5652] that is not present in One feature that is present in CMS [RFC5652] that is not present in
this standard is a digest structure. This omission is deliberate. this standard is a digest structure. This omission is deliberate.
It is better for the structure to be defined in each document as It is better for the structure to be defined in each document as
different protocols will want to include a different set of fields as different protocols will want to include a different set of fields as
part of the structure. While an algorithm identifier and the digest part of the structure. While an algorithm identifier and the digest
value are going to be common to all applications, the two values may value are going to be common to all applications, the two values may
not always be adjacent as the algorithm could be defined once with not 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 common structure additional data fields as part of the structure. A common structure
is going to include a URI or other pointer to where the data that is is going to include a URI or other pointer to where the data that is
being hashed is kept, allowing this to be application specific. being hashed is kept, allowing this to be application-specific.
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 counter signatures and define a CBOR Tag * Rearrange the text around counter signatures and define a CBOR Tag
for a standalone countersignature. for a standalone counter signature.
* Text clarifications and changes in terminology. * Text clarifications and changes in terminology.
1.3. Design Changes from JOSE 1.3. Design Changes from JOSE
* Define a single top message structure so that encrypted, signed, * Define a single top message structure so that encrypted, signed,
and MACed messages can easily be identified and still have a and MACed messages can easily be identified and still have a
consistent view. 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 from those that header parameters that relate to the content from those that
relate to the signature. relate to the signature.
* MACed messages are separated from signed messages. * MACed messages are separated from signed messages.
* MACed messages have the ability to use the same set of recipient * MACed messages have the ability to use the same set of recipient
algorithms as enveloped messages for obtaining the MAC algorithms as enveloped messages for obtaining the MAC
authentication key. authentication key.
* Use binary encodings for binary data rather than base64url * Use binary encodings, rather than base64url encodings, to encode
encodings. binary data.
* Combine the authentication tag for encryption algorithms with the * Combine the authentication tag for encryption algorithms with the
ciphertext. ciphertext.
* The set of cryptographic algorithms has been expanded in some * The set of cryptographic algorithms has been expanded in some
directions and trimmed in others. directions and trimmed in others.
1.4. CBOR Grammar 1.4. CBOR Grammar
There was not a standard CBOR grammar available when COSE was There was not a standard CBOR grammar available when COSE was
skipping to change at page 8, line 26 skipping to change at page 8, line 26
In JSON, maps are called objects and only have one kind of map key: a In JSON, maps are called objects and only have one kind of map key: a
text string. In COSE, we use text strings, negative integers, and text string. In COSE, we use text strings, negative integers, and
unsigned integers as map keys. The integers are used for compactness unsigned integers as map keys. The integers are used for compactness
of encoding and easy comparison. The inclusion of text strings of encoding and easy comparison. The inclusion of text strings
allows for an additional range of short encoded values to be used as allows for an additional range of short encoded values to be used as
well. Since the word "key" is mainly used in its other meaning, as a well. Since the word "key" is mainly used in its other meaning, as a
cryptographic key, we use the term "label" for this usage as a map cryptographic key, we use the term "label" for this usage as a map
key. key.
The presence of a label in a CBOR map that is not a text string or an The presence in a CBOR map of a label that is not a text string or an
integer is an error. Applications can either fail processing or integer is an error. Applications can either fail processing or
process messages by ignoring incorrect labels; however, they MUST NOT process messages by ignoring incorrect labels; however, they MUST NOT
create messages with incorrect labels. create messages with incorrect labels.
A CDDL grammar fragment defines the non-terminal 'label', as in the A CDDL grammar fragment defines the non-terminal 'label', as in the
previous paragraph, and 'values', which permits any value to be used. previous paragraph, and 'values', which permits any value to be used.
label = int / tstr label = int / tstr
values = any values = any
skipping to change at page 9, line 13 skipping to change at page 9, line 16
algorithms provide the same content authentication service as AE algorithms provide the same content authentication service as AE
algorithms, but they additionally provide for authentication of non- algorithms, but they additionally provide for authentication of non-
encrypted data as well. encrypted data as well.
Context is used throughout the document to represent information that Context is used throughout the document to represent information that
is not part of the COSE message. Information which is part of the is not part of the COSE message. Information which is part of the
context can come from several different sources including: Protocol context can come from several different sources including: Protocol
interactions, associated key structures and program configuration. interactions, associated key structures and program configuration.
The context to use can be implicit, identified using the 'kid The context to use can be implicit, identified using the 'kid
context' header parameter defined in [RFC8613], or identified by a context' header parameter defined in [RFC8613], or identified by a
protocol specific identifier. Context should generally be included protocol-specific identifier. Context should generally be included
in the cryptographic configuration, for more details see Section 4.3. in the cryptographic configuration; for more details see Section 4.3.
The term 'byte string' is used for sequences of bytes, while the term The term 'byte string' is used for sequences of bytes, while the term
'text string' is used for sequences of characters. 'text string' is used for sequences of characters.
2. Basic COSE Structure 2. Basic COSE Structure
The COSE object structure is designed so that there can be a large The COSE object structure is designed so that there can be a large
amount of common code when parsing and processing the different types amount of common code when parsing and processing the different types
of security messages. All of the message structures are built on the of security messages. All of the message structures are built on the
CBOR array type. The first three elements of the array always CBOR array type. The first three elements of the array always
skipping to change at page 13, line 40 skipping to change at page 13, line 40
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
h'a0'). The zero-length binary encoding is preferred because it h'a0'). The zero-length binary encoding is preferred because it
is both shorter and the version used in the serialization is both shorter and the version used in the serialization
structures for cryptographic computation. After encoding the map, structures for cryptographic computation. After encoding the map,
the value is wrapped in the binary object. Recipients MUST accept the value is wrapped in the binary object. Recipients MUST accept
both a zero-length binary value and a zero-length map encoded in both a zero-length byte string and a zero-length map encoded in
the binary value. The wrapping allows for the encoding of the the binary value. The wrapping allows for the encoding of the
protected map to be transported with a greater chance that it will protected map to be transported with a greater chance that it will
not be altered in transit. (Badly behaved intermediates could not be altered in transit. (Badly behaved intermediates could
decode and re-encode, but this will result in a failure to verify decode and re-encode, but this will result in a failure to verify
unless the re-encoded byte string is identical to the decoded byte unless the re-encoded byte string is identical to the decoded byte
string.) This avoids the problem of all parties needing to be string.) This avoids the problem of all parties needing to be
able to do a common canonical encoding. able to do a common canonical encoding.
unprotected: Contains parameters about the current layer that are unprotected: Contains parameters about the current layer that are
not cryptographically protected. not cryptographically protected.
skipping to change at page 18, line 34 skipping to change at page 18, line 38
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 authenticated by the signature, or just present. An example of
header a parameter about the content is the content type. Examples header a parameter about the content is the content type. Examples
of a header parameters about the signature would be the algorithm and of header parameters about the signature would be the algorithm and
key used to create the signature and counter signatures. key used to create the signature and counter signatures.
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
skipping to change at page 21, line 40 skipping to change at page 21, line 52
is not carried as part of the COSE object. The primary reason for is not carried as part of the COSE object. The primary reason for
supporting this can be seen by looking at the CoAP message structure supporting this can be seen by looking at the CoAP message structure
[RFC7252], where the facility exists for options to be carried before [RFC7252], where the facility exists for options to be carried before
the payload. Examples of data that can be placed in this location the payload. Examples of data that can be placed in this location
would be the CoAP code or CoAP options. If the data is in the would be the CoAP code or CoAP options. If the data is in the
headers of the CoAP message, then it is available for proxies to help headers of the CoAP message, then it is available for proxies to help
in performing its operations. For example, the Accept Option can be in performing its operations. For example, the Accept Option can be
used by a proxy to determine if an appropriate value is in the used by a proxy to determine if an appropriate value is in the
proxy's cache. But the sender can cause a failure at the server if a proxy's cache. But the sender can cause a failure at the server if a
proxy, or an attacker, changes the set of accept values by including proxy, or an attacker, changes the set of accept values by including
the field in the application supplied data. the field in the application-supplied data.
This document describes the process for using a byte array of This document describes the process for using a byte array of
externally supplied authenticated data; the method of constructing externally supplied authenticated data; the method of constructing
the byte array is a function of the application. Applications that the byte array is a function of the application. Applications that
use this feature need to define how the externally supplied use this feature need to define how the externally supplied
authenticated data is to be constructed. Such a construction needs authenticated data is to be constructed. Such a construction needs
to take into account the following issues: to take into account the following issues:
* If multiple items are included, applications need to ensure that * If multiple items are included, applications need to ensure that
the same byte string cannot produced if there are different the same byte string cannot be produced if there are different
inputs. This would occur by appending the text strings 'AB' and inputs. This would occur by appending the text strings 'AB' and
'CDE' or by appending the text strings 'ABC' and 'DE'. This is 'CDE' or by appending the text strings 'ABC' and 'DE'. This is
usually addressed by making fields a fixed width and/or encoding usually addressed by making fields a fixed width and/or encoding
the length of the field as part of the output. Using options from the length of the field as part of the output. Using options from
CoAP [RFC7252] as an example, these fields use a TLV structure so CoAP [RFC7252] as an example, these fields use a TLV structure so
they can be concatenated without any problems. they can be concatenated without any problems.
* If multiple items are included, an order for the items needs to be * If multiple items are included, an order for the items needs to be
defined. Using options from CoAP as an example, an application defined. Using options from CoAP as an example, an application
could state that the fields are to be ordered by the option could state that the fields are to be ordered by the option
skipping to change at page 22, line 45 skipping to change at page 23, line 9
"Signature1" for signatures using the COSE_Sign1 structure. "Signature1" for signatures using the COSE_Sign1 structure.
"CounterSignature" for signatures used as counter signature "CounterSignature" for signatures used as counter signature
attributes. attributes.
"CounterSignature0" for signatures used as CounterSignature0 "CounterSignature0" for signatures used as CounterSignature0
attributes. attributes.
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 bstr of bstr type. If there are no protected attributes, a zero-length
length zero 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 bstr of bstr type. If there are no protected attributes, a zero-length
length zero is used. This field is omitted for the COSE_Sign1 byte string is used. This field is omitted for the COSE_Sign1
signature structure and CounterSignature0 attributes. signature structure and CounterSignature0 attributes.
4. The protected attributes from the application encoded in a bstr 4. The protected attributes from the application encoded in a bstr
type. If this field is not supplied, it defaults to a zero- 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.
skipping to change at page 24, line 13 skipping to change at page 24, line 25
(the value to sign), and sig (the signature to be verified). (the value to sign), and sig (the signature to be verified).
In addition to performing the signature verification, the application In addition to performing the signature verification, the application
performs the appropriate checks to ensure that the key is correctly performs the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the signing identity is paired with the signing identity and that the signing identity is
authorized before performing actions. authorized before performing actions.
5. Counter Signatures 5. Counter Signatures
COSE supports two different forms for counter signatures. Full COSE supports two different forms for counter signatures. Full
countersignatures use the structure COSE_Countersign. This is same counter signatures use the structure COSE_Countersign. This is same
structure as COSE_Signature and thus it can have protected structure as COSE_Signature and thus it can have protected
attributes, chained countersignatures and information about attributes, chained counter signatures and information about
identifying the key. Abbreviated countersignatures use the structure identifying the key. Abbreviated counter signatures use the
COSE_Countersign1. This structure only contains the signature value structure COSE_Countersign1. This structure only contains the
and nothing else. The structures cannot be converted between each signature value and nothing else. The structures cannot be converted
other; as the signature computation includes a parameter identifying between each other; as the signature computation includes a parameter
which structure is being used, the converted structure will fail identifying which structure is being used, the converted structure
signature validation. will fail signature validation.
COSE was designed for uniformity in how the data structures are COSE was designed for uniformity in how the data structures are
specified. One result of this is that for COSE one can expand the specified. One result of this is that for COSE one can expand the
concept of countersignatures beyond just the idea of signing a concept of counter signatures beyond just the idea of signing a
signature to being able to sign most of the structures without having signature to being able to sign most of the structures without having
to create a new signing layer. When creating a countersignature, one to create a new signing layer. When creating a counter signature,
needs to be clear about the security properties that result. When one needs to be clear about the security properties that result.
done on a COSE_Signature, the normal countersignature semantics are When done on a COSE_Signature, the normal counter signature semantics
preserved. That is the countersignature makes a statement about the are preserved. That is the counter signature makes a statement about
existence of a signature and, when used as a timestamp, a time point the existence of a signature and, when used as a timestamp, a time
at which the signature exists. When done on a COSE_Mac or a 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 COSE_Mac0, one effectively upgrades the MAC operation to a signature
operation. When done on a COSE_Encrypt or COSE_Encrypt0, the operation. When done on a COSE_Encrypt or COSE_Encrypt0, the
existence of the encrypted data is attested to. It should be noted existence of the encrypted data is attested to. It should be noted
that there is a big difference between attesting to the encrypted that there is a big difference between attesting to the encrypted
data as opposed to attesting to the unencrypted data. If the latter 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 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 and then encrypt that. It is always possible to construct cases
where the decryption is successful, while providing completely where the use of two different keys will appear to result in a
different answers by using a different key. This situation is not successful decryption (the tag check success), but which produce two
detectable by a countersignature on the encrypted data. completely different plaintexts. This situation is not detectable by
a counter signature on the encrypted data.
5.1. Full Countersignatures 5.1. Full Counter Signatures
The COSE_Countersignature structure allows for the same set of The COSE_Countersignature structure allows for the same set of
capabilities of a COSE_Signature. This means that all of the capabilities of a COSE_Signature. This means that all of the
capabilities of a signature are duplicated with this structure. capabilities of a signature are duplicated with this structure.
Specifically, the countersigner does not need to be related to the Specifically, the counter signer does not need to be related to the
producer of what is being counter signed as key and algorithm producer of what is being counter signed as key and algorithm
identification can be placed in the countersignature attributes. identification can be placed in the counter signature attributes.
This also means that the countersignature can itself be This also means that the counter signature can itself be counter
countersigned. This is a feature required by protocols such as long- signed. This is a feature required by protocols such as long-term
term archiving services. More information on how this is used can be archiving services. More information on how this is used can be
found in the evidence record syntax described in [RFC4998]. found in the evidence record syntax described in [RFC4998].
The full countersignature structure can be encoded as either a tagged The full counter signature structure can be encoded as either tagged
or untagged depending on the context it is used in. A tagged or untagged depending on the context it is used in. A tagged
COSE_Countersign structure is identified by the CBOR tag TBD0. The COSE_Countersign structure is identified by the CBOR tag TBD0. The
CDDL fragment for full countersignatures is: CDDL fragment for full counter signatures is:
COSE_CounterSignature_Tagged = #6.98(COSE_CounterSignature) COSE_CounterSignature_Tagged = #6.98(COSE_CounterSignature)
COSE_CounterSignature = COSE_Signature COSE_CounterSignature = COSE_Signature
The details of the fields of a countersignature can be found in The details of the fields of a counter signature can be found in
Section 4.1. The process of creating and validating abbreviated Section 4.1. The process of creating and validating abbreviated
countersignatures is defined in Section 4.4. counter signatures is defined in Section 4.4.
An example of a counter signature on a signature can be found in An example of a counter signature on a signature can be found in
Appendix C.1.3. An example of a counter signature in an encryption Appendix C.1.3. An example of a counter signature in an encryption
object can be found in Appendix C.3.3. object can be found in Appendix C.3.3.
It should be noted that only a signature algorithm with appendix (see It should be noted that only a signature algorithm with appendix (see
Section 9.1) can be used for counter signatures. This is because the Section 9.1) can be used for counter signatures. This is because the
body should be able to be processed without having to evaluate the body should be able to be processed without having to evaluate the
counter signature, and this is not possible for signature schemes counter signature, and this is not possible for signature schemes
with message recovery. with message recovery.
5.2. Abbreviated Countersignatures 5.2. Abbreviated Counter Signatures
Abbreviated countersignatures were designed primarily to deal with Abbreviated counter signatures were designed primarily to deal with
the problem of having group encrypted messaging, but still needing to the problem of having encrypted group messaging, but still needing to
know who originated the message. The objective was to keep the know who originated the message. The objective was to keep the
countersignature as small as possible while still providing the counter signature as small as possible while still providing the
needed security. For abbreviated countersignatures, there is no needed security. For abbreviated counter signatures, there is no
provision for any protected attributes related to the signing provision for any protected attributes related to the signing
operation. Instead, the parameters for computing or verifying the operation. Instead, the parameters for computing or verifying the
abbreviated countersignature are inferred from the same context used abbreviated counter signature are inferred from the same context used
to describe the encryption, signature, or MAC processing. to describe the encryption, signature, or MAC processing.
The byte string representing the signature value is placed in the The byte string representing the signature value is placed in the
CounterSignature0 attribute. This attribute is then encoded as an CounterSignature0 attribute. This attribute is then encoded as an
unprotected header parameter. The attribute is defined below. unprotected header parameter. The attribute is defined below.
The process of creating and validating abbreviated countersignatures The process of creating and validating abbreviated counter signatures
is defined in Section 4.4. is defined in Section 4.4.
+-------------------+-------+------------+-------+------------------+ +-------------------+-------+-------+-------+-------------------+
| Name | Label | Value | Value | Description | | Name | Label | Value | Value | Description |
| | | Type | | | | | | Type | | |
+===================+=======+============+=======+==================+ +===================+=======+=======+=======+===================+
| CounterSignature0 | 9 | bstr | | Abbreviated | | CounterSignature0 | 9 | bstr | | Abbreviated |
| | | | | Countersignature | | | | | | Counter Signature |
+-------------------+-------+------------+-------+------------------+ +-------------------+-------+-------+-------+-------------------+
Table 4: Header Parameter for CounterSignature0 Table 4: Header Parameter for CounterSignature0
6. Encryption Objects 6. 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
skipping to change at page 26, line 38 skipping to change at page 26, line 47
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
algorithm. Examples of header parameters about the recipient are the algorithm. Examples of header parameters about the recipient are the
recipient's key identifier and the recipient's encryption algorithm. recipient's key identifier and the recipient's encryption algorithm.
The same techniques and nearly the same structure is used for The same techniques and nearly the same structure are used for
encrypting both the plaintext and the keys. This is different from encrypting both the plaintext and the keys. This is different from
the approach used by both "Cryptographic Message Syntax (CMS)" the approach used by both "Cryptographic Message Syntax (CMS)"
[RFC5652] and "JSON Web Encryption (JWE)" [RFC7516] where different [RFC5652] and "JSON Web Encryption (JWE)" [RFC7516] where different
structures are used for the content layer and for the recipient structures are used for the content layer and for the recipient
layer. Two structures are defined: COSE_Encrypt to hold the layer. Two structures are defined: COSE_Encrypt to hold the
encrypted content and COSE_recipient to hold the encrypted keys for encrypted content and COSE_recipient to hold the encrypted keys for
recipients. Examples of encrypted messages can be found in recipients. Examples of encrypted messages can be found in
Appendix C.3. Appendix C.3.
The COSE_Encrypt structure can be encoded as either tagged or The COSE_Encrypt structure can be encoded as either tagged or
skipping to change at page 30, line 6 skipping to change at page 30, line 18
"Enc_Recipient" for a recipient encoding to be placed in an "Enc_Recipient" for a recipient encoding to be placed in an
COSE_Encrypt data structure. COSE_Encrypt data structure.
"Mac_Recipient" for a recipient encoding to be placed in a "Mac_Recipient" for a recipient encoding to be placed in a
MACed message structure. MACed message structure.
"Rec_Recipient" for a recipient encoding to be placed in a "Rec_Recipient" for a recipient encoding to be placed in a
recipient structure. recipient 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 bstr of bstr type. If there are no protected attributes, a zero-length
length zero is used. byte string is used.
3. The protected attributes from the application encoded in a bstr 3. The protected attributes from the application encoded in a bstr
type. If this field is not supplied, it defaults to a zero- type. If this field is not supplied, it defaults to a zero-
length bstr. (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.)
The CDDL fragment that describes the above text is: The CDDL fragment that describes the above text is:
Enc_structure = [ Enc_structure = [
context : "Encrypt" / "Encrypt0" / "Enc_Recipient" / context : "Encrypt" / "Encrypt0" / "Enc_Recipient" /
"Mac_Recipient" / "Rec_Recipient", "Mac_Recipient" / "Rec_Recipient",
protected : empty_or_serialized_map, protected : empty_or_serialized_map,
external_aad : bstr external_aad : bstr
] ]
skipping to change at page 39, line 49 skipping to change at page 40, line 45
| MAC | 10 | The key is used for validating MACs. | | MAC | 10 | The key is used for validating MACs. |
| verify | | | | verify | | |
+---------+-------+----------------------------------------------+ +---------+-------+----------------------------------------------+
Table 6: Key Operation Values Table 6: Key Operation Values
9. Taxonomy of Algorithms used by COSE 9. 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 as there are new algorithm structures that could be to be exhaustive. New algorithms will be created which will not fit
found or are not known to the author. into this taxonomy. If this occurs, then new documents addressing
this new algorithms are going to be needed.
9.1. Signature Algorithms 9.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
skipping to change at page 43, line 25 skipping to change at page 44, line 25
9.5.1. Direct Encryption 9.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 item unless it is used * The 'protected' field MUST be a zero-length byte string unless it
in the computation of the content key. is used in the computation of the content key.
* 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 item. * The 'ciphertext' field MUST be a zero-length byte string.
* The 'recipients' field MUST be absent. * The 'recipients' field MUST be absent.
9.5.2. Key Wrap 9.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
skipping to change at page 46, line 16 skipping to change at page 47, line 16
(usually the content layer). (usually the content layer).
* The 'alg' header parameter MUST be present in the layer. * The 'alg' header parameter MUST be present in the layer.
* A header parameter identifying the recipient's key SHOULD be * A header parameter identifying the recipient's key SHOULD be
present. A header parameter identifying the sender's key SHOULD present. A header parameter identifying the sender's key SHOULD
be present. be present.
10. CBOR Encoding Restrictions 10. CBOR Encoding Restrictions
There has been an attempt to limit the number of places where the The document limits the restrictions it imposes on the CBOR Encoder
document needs to impose restrictions on how the CBOR Encoder needs needs to work. We have managed to narrow it down to the following
to work. We have managed to narrow it 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
skipping to change at page 55, line 16 skipping to change at page 56, line 16
* 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.0 for the cryptography. Version 1.0 for the cryptography.
* Coverage: The C version currently does not have full countersign * Coverage: The C version currently does not have full counter sign
support. The other two versions do. They do have support to support. The other two versions do. They do have support to
allow for implicit algorithm support as they allow for the allow for implicit algorithm support as they allow for the
application to set attributes that are not to be sent in the application to set attributes that are not to be sent in the
message. message.
* Testing: All of the examples in the example library are generated * Testing: All of the examples in the example library are generated
by the C# library and then validated using the Java and C by the C# library and then validated using the Java and C
libraries. All three libraries have tests to allow for the libraries. All three libraries have tests to allow for the
creating of the same messages that are in the example library creating of the same messages that are in the example library
followed by validating them. These are not compared against the followed by validating them. These are not compared against the
skipping to change at page 57, line 42 skipping to change at page 58, line 42
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[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-06, 4 November 2019, draft-ietf-cose-rfc8152bis-algs-07, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
algs-06>. algs-07>.
15.2. Informative References 15.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
skipping to change at page 60, line 41 skipping to change at page 61, line 44
(the message itself, an application statement, the key structure that (the message itself, an application statement, the key structure that
the sender possesses, and the key structure the recipient possesses). the sender possesses, and the key structure the recipient possesses).
This appendix lays out how such a change can be made and the details This appendix lays out how such a change can be made and the details
that an application needs to specify in order to use this option. that an application needs to specify in order to use this option.
Two different sets of details are specified: those needed to omit an Two different sets of details are specified: those needed to omit an
algorithm identifier and those needed to use a variant on the counter algorithm identifier and those needed to use a variant on the counter
signature attribute that contains no attributes about itself. signature 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 apply to having an implicit algorithm identified for recommendations applies to having an implicit algorithm identified
a single layer of a COSE object. The second set of recommendations for a single layer of a COSE object. The second set of
apply to having multiple implicit algorithms identified for multiple recommendations applies to having multiple implicit algorithms
layers of a COSE object. The third set of recommendations apply to identified for multiple layers of a COSE object. The third set of
having implicit algorithms for multiple COSE object constructs. recommendations applies to having implicit algorithms for multiple
COSE object constructs.
The key words from [RFC2119] are deliberately not used here. This The key words from [RFC2119] are deliberately not used here. This
specification can provide recommendations, but it cannot enforce specification can provide recommendations, but it cannot enforce
them. them.
This set of recommendations applies to the case where an application This set of recommendations applies to the case where an application
is distributing a fixed algorithm along with the key information for is distributing a fixed algorithm along with the key information for
use in a single COSE object. This normally applies to the smallest use in a single COSE object. This normally applies to the smallest
of the COSE objects, specifically COSE_Sign1, COSE_Mac0, and of the COSE objects, specifically COSE_Sign1, COSE_Mac0, and
COSE_Encrypt0, but could apply to the other structures as well. COSE_Encrypt0, but could apply to the other structures as well.
 End of changes. 53 change blocks. 
153 lines changed or deleted 155 lines changed or added

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