draft-ietf-cose-msg-04.txt   draft-ietf-cose-msg-05.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Intended status: Informational B. Campbell Intended status: Informational B. Campbell
Expires: February 29, 2016 Ping Identity Expires: March 24, 2016 Ping Identity
August 28, 2015 September 21, 2015
CBOR Encoded Message Syntax CBOR Encoded Message Syntax
draft-ietf-cose-msg-04 draft-ietf-cose-msg-05
Abstract Abstract
Concise Binary Object Representation (CBOR) is data format designed Concise Binary Object Representation (CBOR) is 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 the basic security services defined for this data ability to have the basic security services defined for this data
format. This document specifies how to do signatures, message format. This document specifies how to do signatures, message
authentication codes and encryption using this data format. authentication codes and encryption using this data format.
Contributing to this document Contributing to this document
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 29, 2016. This Internet-Draft will expire on March 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Design changes from JOSE . . . . . . . . . . . . . . . . 5 1.1. Design changes from JOSE . . . . . . . . . . . . . . . . 5
1.2. Requirements Terminology . . . . . . . . . . . . . . . . 5 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 5
1.3. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 5 1.3. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 6
1.4. CBOR Related Terminology . . . . . . . . . . . . . . . . 6 1.4. CBOR Related Terminology . . . . . . . . . . . . . . . . 6
1.5. Document Terminology . . . . . . . . . . . . . . . . . . 6 1.5. Document Terminology . . . . . . . . . . . . . . . . . . 7
1.6. Mandatory to Implement Algorithms . . . . . . . . . . . . 7 1.6. Mandatory to Implement Algorithms . . . . . . . . . . . . 7
2. The COSE_MSG structure . . . . . . . . . . . . . . . . . . . 7 2. The COSE_MSG structure . . . . . . . . . . . . . . . . . . . 8
3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 9 3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Common COSE Headers Parameters . . . . . . . . . . . . . 10 3.1. Common COSE Headers Parameters . . . . . . . . . . . . . 11
4. Signing Structure . . . . . . . . . . . . . . . . . . . . . . 13 4. Signing Structure . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Externally Supplied Data . . . . . . . . . . . . . . . . 14 4.1. Externally Supplied Data . . . . . . . . . . . . . . . . 16
4.2. Signing and Verification Process . . . . . . . . . . . . 15 4.2. Signing and Verification Process . . . . . . . . . . . . 16
5. Encryption object . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Computing Counter Signatures . . . . . . . . . . . . . . 18
5.1. Recipient Algorithm Classes . . . . . . . . . . . . . . . 17 5. Encryption objects . . . . . . . . . . . . . . . . . . . . . 19
5.2. Encryption Algorithm for AEAD algorithms . . . . . . . . 18 5.1. Enveloped COSE structure . . . . . . . . . . . . . . . . 19
5.3. Encryption algorithm for AE algorithms . . . . . . . . . 19 5.1.1. Recipient Algorithm Classes . . . . . . . . . . . . . 20
6. MAC objects . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Encrypted COSE structure . . . . . . . . . . . . . . . . 21
7. Key Structure . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3. Encryption Algorithm for AEAD algorithms . . . . . . . . 21
7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 22 5.4. Encryption algorithm for AE algorithms . . . . . . . . . 22
8. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 24 6. MAC objects . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. How to compute a MAC . . . . . . . . . . . . . . . . . . 24
8.1.1. Security Considerations . . . . . . . . . . . . . . . 26 7. Key Structure . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 27 7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 25
8.2.1. Security Considerations . . . . . . . . . . . . . . . 27 8. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 28
9. Message Authentication (MAC) Algorithms . . . . . . . . . . . 28 8.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Hash-based Message Authentication Codes (HMAC) . . . . . 28 8.1.1. Security Considerations . . . . . . . . . . . . . . . 30
9.1.1. Security Considerations . . . . . . . . . . . . . . . 29 8.2. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 31
9.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 29 8.2.1. Security Considerations . . . . . . . . . . . . . . . 31
9.2.1. Security Considerations . . . . . . . . . . . . . . . 30 9. Message Authentication (MAC) Algorithms . . . . . . . . . . . 32
10. Content Encryption Algorithms . . . . . . . . . . . . . . . . 30 9.1. Hash-based Message Authentication Codes (HMAC) . . . . . 32
10.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1.1. Security Considerations . . . . . . . . . . . . . . . 33
10.1.1. Security Considerations . . . . . . . . . . . . . . 31 9.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 34
10.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . 32 9.2.1. Security Considerations . . . . . . . . . . . . . . . 34
10.2.1. Security Considerations . . . . . . . . . . . . . . 34 10. Content Encryption Algorithms . . . . . . . . . . . . . . . . 35
10.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . 35 10.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . 35
10.3.1. Security Considerations . . . . . . . . . . . . . . 35 10.1.1. Security Considerations . . . . . . . . . . . . . . 36
11. Key Derivation Functions (KDF) . . . . . . . . . . . . . . . 36 10.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . 36
10.2.1. Security Considerations . . . . . . . . . . . . . . 39
10.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . 39
10.3.1. Security Considerations . . . . . . . . . . . . . . 40
11. Key Derivation Functions (KDF) . . . . . . . . . . . . . . . 40
11.1. HMAC-based Extract-and-Expand Key Derivation Function 11.1. HMAC-based Extract-and-Expand Key Derivation Function
(HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 36 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Context Information Structure . . . . . . . . . . . . . 38 11.2. Context Information Structure . . . . . . . . . . . . . 42
12. Recipient Algorithm Classes . . . . . . . . . . . . . . . . . 42 12. Recipient Algorithm Classes . . . . . . . . . . . . . . . . . 46
12.1. Direct Encryption . . . . . . . . . . . . . . . . . . . 42 12.1. Direct Encryption . . . . . . . . . . . . . . . . . . . 46
12.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 42 12.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 47
12.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . 43 12.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . 47
12.2. Key Wrapping . . . . . . . . . . . . . . . . . . . . . . 44 12.2. Key Wrapping . . . . . . . . . . . . . . . . . . . . . . 49
12.2.1. AES Key Wrapping . . . . . . . . . . . . . . . . . . 45 12.2.1. AES Key Wrapping . . . . . . . . . . . . . . . . . . 49
12.3. Key Encryption . . . . . . . . . . . . . . . . . . . . . 45 12.3. Key Encryption . . . . . . . . . . . . . . . . . . . . . 50
12.3.1. RSAES-OAEP . . . . . . . . . . . . . . . . . . . . . 46 12.3.1. RSAES-OAEP . . . . . . . . . . . . . . . . . . . . . 50
12.4. Direct Key Agreement . . . . . . . . . . . . . . . . . . 46 12.4. Direct Key Agreement . . . . . . . . . . . . . . . . . . 51
12.4.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 48 12.4.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 52
12.5. Key Agreement with KDF . . . . . . . . . . . . . . . . . 51 12.5. Key Agreement with KDF . . . . . . . . . . . . . . . . . 56
12.5.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 51 12.5.1. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 56
13. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 13. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 52 13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 57
13.1.1. Single Coordinate Curves . . . . . . . . . . . . . . 53 13.1.1. Single Coordinate Curves . . . . . . . . . . . . . . 58
13.1.2. Double Coordinate Curves . . . . . . . . . . . . . . 54 13.1.2. Double Coordinate Curves . . . . . . . . . . . . . . 58
13.2. RSA Keys . . . . . . . . . . . . . . . . . . . . . . . . 55 13.2. RSA Keys . . . . . . . . . . . . . . . . . . . . . . . . 60
13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 56 13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 61
14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 57 14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 62
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
15.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 57 15.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 62
15.2. COSE Header Parameter Registry . . . . . . . . . . . . . 58 15.2. COSE Header Parameter Registry . . . . . . . . . . . . . 62
15.3. COSE Header Algorithm Label Table . . . . . . . . . . . 58 15.3. COSE Header Algorithm Label Table . . . . . . . . . . . 63
15.4. COSE Algorithm Registry . . . . . . . . . . . . . . . . 59 15.4. COSE Algorithm Registry . . . . . . . . . . . . . . . . 64
15.5. COSE Key Common Parameter Registry . . . . . . . . . . . 60 15.5. COSE Key Common Parameter Registry . . . . . . . . . . . 65
15.6. COSE Key Type Parameter Registry . . . . . . . . . . . . 61 15.6. COSE Key Type Parameter Registry . . . . . . . . . . . . 65
15.7. COSE Elliptic Curve Registry . . . . . . . . . . . . . . 61 15.7. COSE Elliptic Curve Registry . . . . . . . . . . . . . . 66
15.8. Media Type Registration . . . . . . . . . . . . . . . . 62 15.8. Media Type Registration . . . . . . . . . . . . . . . . 67
15.8.1. COSE Security Message . . . . . . . . . . . . . . . 62 15.8.1. COSE Security Message . . . . . . . . . . . . . . . 67
15.8.2. COSE Key media type . . . . . . . . . . . . . . . . 64 15.8.2. COSE Key media type . . . . . . . . . . . . . . . . 69
16. Security Considerations . . . . . . . . . . . . . . . . . . . 66 16. Security Considerations . . . . . . . . . . . . . . . . . . . 70
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
17.1. Normative References . . . . . . . . . . . . . . . . . . 66 17.1. Normative References . . . . . . . . . . . . . . . . . . 71
17.2. Informative References . . . . . . . . . . . . . . . . . 66 17.2. Informative References . . . . . . . . . . . . . . . . . 71
Appendix A. Three Levels of Recipient Information . . . . . . . 69 Appendix A. CDDL Grammar . . . . . . . . . . . . . . . . . . . . 74
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 70 Appendix B. Three Levels of Recipient Information . . . . . . . 74
B.1. Examples of MAC messages . . . . . . . . . . . . . . . . 71 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 76
B.1.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 71 C.1. Examples of MAC messages . . . . . . . . . . . . . . . . 76
B.1.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 72 C.1.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 76
B.1.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 73 C.1.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 77
B.1.4. Multi-recipient MAC message . . . . . . . . . . . . . 74 C.1.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 78
B.2. Examples of Encrypted Messages . . . . . . . . . . . . . 76 C.1.4. Multi-recipient MAC message . . . . . . . . . . . . . 79
B.2.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 76 C.2. Examples of Encrypted Messages . . . . . . . . . . . . . 81
B.2.2. Direct plus Key Derivation . . . . . . . . . . . . . 76 C.2.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 81
B.3. Examples of Signed Message . . . . . . . . . . . . . . . 77 C.2.2. Direct plus Key Derivation . . . . . . . . . . . . . 81
B.3.1. Single Signature . . . . . . . . . . . . . . . . . . 77 C.3. Examples of Signed Message . . . . . . . . . . . . . . . 82
B.3.2. Multiple Signers . . . . . . . . . . . . . . . . . . 78 C.3.1. Single Signature . . . . . . . . . . . . . . . . . . 82
B.4. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 79 C.3.2. Multiple Signers . . . . . . . . . . . . . . . . . . 83
B.4.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 79 C.4. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 84
B.4.2. Private Keys . . . . . . . . . . . . . . . . . . . . 81 C.4.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 84
Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 83 C.4.2. Private Keys . . . . . . . . . . . . . . . . . . . . 86
C.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 84 Appendix D. Document Updates . . . . . . . . . . . . . . . . . . 88
C.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 84 D.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 89
C.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 84 D.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 89
C.4. Version -01 to -2 . . . . . . . . . . . . . . . . . . . . 84 D.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 89
C.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 85 D.4. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 D.5. Version -01 to -2 . . . . . . . . . . . . . . . . . . . . 90
D.6. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
1. Introduction 1. Introduction
There has been an increased focus on the small, constrained devices There has been an increased focus on the small, constrained devices
that make up the Internet of Things (IOT). One of the standards that that make up the Internet of Things (IOT). One of the standards that
has come of of this process is the Concise Binary Object has come of of this process is the Concise Binary Object
Representation (CBOR). CBOR extended the data model of the Representation (CBOR). CBOR extended the data model of the
JavaScript Object Notation (JSON) by allowing for binary data among JavaScript Object Notation (JSON) by allowing for binary data among
other changes. CBOR is being adopted by several of the IETF working other changes. CBOR is being 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
skipping to change at page 5, line 47 skipping to change at page 6, line 8
"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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
When the words appear in lower case, their natural language meaning When the words appear in lower case, their natural language meaning
is used. is used.
1.3. CBOR Grammar 1.3. CBOR Grammar
There currently is no standard CBOR grammar available for use by There currently is no standard CBOR grammar available for use by
specifications. While we describe the CBOR structures in prose, they specifications. We therefore describe the CBOR structures in prose.
are agumented in the text by the use of the CBOR Data Definition There is a version of a CBOR grammar in the CBOR Data Definition
Language (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. The use of Language (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. An
CDDL is intended to be explanitory. In the event of a conflict informational version of the CBOR grammar that reflects what is in
between the text and the CDDL grammar, the text is authorative. the prose can be found in Appendix A. CDDL has not been fixed, so
this grammar may will only work with the version of CDDL at the time
of publishing.
(Problems may be introduced at a later point because the CDDL grammar The document was developed by first working on the grammar and then
is not yet fixed.) developing the prose to go with it. An artifact of this is that the
prose was written using the primitive type strings defined by early
versions CDDL. In this specification the following primitive types
are used:
CDDL productions that together define the grammar are interspersed in bstr - byte string (major type 2).
the document like this:
start = COSE_MSG / COSE_Key / COSE_KeySet int - an unsigned integer or a negative integer.
The collected CDDL can be extracted from the XML version of this nil - a null value (tag 7.22).
document via the following XPath expression below. (Depending on the
XPath evaluator one is using, it may be necessary to deal with >
as an entity.)
//artwork[@type='CDDL']/text() nint - a negative integer (major type 1).
tstr - a UTF-8 text string (major type 3).
uint - an unsigned integer (major type 0).
Text from here to start of next section to be removed
NOTE: For the purposes of review, we are currently interlacing the
CDLL grammar into the text of document. This is being done for
simplicity of comparision of the grammar againist the prose. The
grammar will be removed to an appendix during WGLC.
start = COSE_MSG / COSE_Tagged_MSG / COSE_Key / COSE_KeySet
1.4. CBOR Related Terminology 1.4. CBOR Related Terminology
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
string. In COSE, we use both strings and integers (both negative and string. In COSE, we use both strings and integers (both negative and
non-negative integers) as map keys, as well as data items to identify non-negative integers) as map keys, as well as data items to identify
specific choices. The integers (both positive and negative) are used specific choices. The integers (both positive and negative) are used
for compactness of encoding and easy comparison. (Generally, in this for compactness of encoding and easy comparison. (Generally, in this
document the value zero is going to be reserved and not used.) Since document the value zero is going to be reserved and not used.) Since
the work "key" is mainly used in its other meaning, as a the work "key" is mainly used in its other meaning, as a
cryptographic key, we use the term "label" for this usage of either cryptographic key, we use the term "label" for this usage of either
an integer or a string to identify map keys and choose data items. an integer or a string to identify map keys and choose data items.
The CDLL grammar that defines a type that represents a label is given Text from here to start of next section to be removed
below:
label = int / tstr label = int / tstr
values = any values = any
1.5. Document Terminology 1.5. Document Terminology
In this document we use the following terminology: [CREF2] In this document we use the following terminology: [CREF2]
Byte is a synonym for octet. Byte is a synonym for octet.
skipping to change at page 8, line 11 skipping to change at page 8, line 29
The tagged version allows for a method of placing the COSE_MSG The tagged version allows for a method of placing the COSE_MSG
structure into a choice, using a consistent tag value to determine structure into a choice, using a consistent tag value to determine
that this is a COSE object. that this is a COSE object.
The existence of the COSE_MSG and COSE_Tagged_MSG CBOR data types are The existence of the COSE_MSG and COSE_Tagged_MSG CBOR data types are
not intended to prevent protocols from using the individual security not intended to prevent protocols from using the individual security
primitives directly. Where only a single service is required, that primitives directly. Where only a single service is required, that
structure can be used directly. structure can be used directly.
Each of the top-level security objects use a CBOR array as the base Each of the top-level security objects use a CBOR array as the base
structure. structure. For each of the top-level security objects, the first
field is a 'msg_type'. The CBOR type for a 'msg_type' is 'int'. The
'msg_type' is defined to distinguish between the different structures
when they appear as part of a COSE_MSG object. [CREF5] [CREF6]
[CREF7]
A field 'msg_type' is defined to distinguish between the different The message types defined in this document are:
structures when they appear as part of a COSE_MSG object. [CREF5]
[CREF6]
0 - Reserved. 0 - Reserved.
1 - Signed Message. 1 - Signed Message.
2 - Encrypted Message 2 - Enveloped Message
3 - Authenticated Message (MACed message) 3 - Authenticated Message (MACed message)
4 - Encrypted Message
Implementations MUST be prepared to find an integer in this field Implementations MUST be prepared to find an integer in this field
that does not correspond to the values 1 to 3. If this is found then that does not correspond to the values 1 to 3. If a message type is
the client MUST stop attempting to process the structure and fail. found then the client does not support the associated security
The value of 0 is reserved and not to be used. If the value of 0 is object, the client MUST stop attempting to process the structure and
found, then clients MUST fail processing the structure. fail. The value of 0 is reserved and not assigned to a security
Implementations need to recognize that the set of values might be object. If the value of 0 is found, then clients MUST fail
extended at a later date, but they should not provide a security processing the structure. Implementations need to recognize that the
service based on guesses of what is there. set of values might be extended at a later date, but they should not
provide a security service based on guesses of what the security
object might be.
The CDDL grammar that corresponds to the above is: Text from here to start of next section to be removed
COSE_MSG = COSE_Sign / COSE_MSG = COSE_Sign /
COSE_encrypt / COSE_enveloped /
COSE_encryptData /
COSE_mac COSE_mac
COSE_Tagged_MSG = #6.999(COSE_MSG) ; Replace 999 with TBD1 COSE_Tagged_MSG = #6.999(COSE_MSG) ; Replace 999 with TBD1
; msg_type values ; msg_type values
msg_type_reserved=0 msg_type_reserved=0
msg_type_signed=1 msg_type_signed=1
msg_type_encrypted=2 msg_type_enveloped=2
msg_type_mac=3 msg_type_mac=3
msg_type_encryptData=4
The top level of each of the COSE message structures are encoded as
arrays.
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 in this buckets are available for use in all of the structures in this
document except for keys. While these buckets can be present, they document except for keys. While these buckets can be present, they
may not all be usable in all instances. For example, while the may not all be usable in all instances. For example, while the
skipping to change at page 9, line 27 skipping to change at page 9, line 48
bucket should not be used. bucket should not be used.
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.4). The value portion is dependent on the definition for (Section 1.4). 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 string values for labels has been divided into several integer and string values for labels has been divided into several
sections with a standard range, a private range, and a range that is sections with a standard range, a private range, and a range that is
dependent on the algorithm selected. The defined labels can be found dependent on the algorithm selected. The defined labels can be found
in the 'COSE Header Parameters' IANA registry (Section 15.2). in the 'COSE Header Parameters' IANA registry (Section 15.2).
Two buckets are provided for each layer: [CREF7] Two buckets are provided for each layer:
protected contains parameters about the current layer that are to be protected contains parameters about the current layer that are to be
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 an empty protected map as a a bstr object. Senders SHOULD encode an empty protected map as a
zero length binary object (it is shorter). Recipients MUST accept zero length binary object (it is shorter). Recipients MUST accept
both a zero length binary value and a zero length map encoded in both a zero length binary value 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
skipping to change at page 10, line 8 skipping to change at page 10, line 30
Only parameters that deal with the current layer are to be placed at Only parameters that deal with the current layer are to be placed at
that layer. As an example of this, the parameter 'content type' that layer. As an example of this, the parameter 'content type'
describes the content of the message being carried in the message. describes the content of the message being carried in the message.
As such this parameter is placed only the the content layer and is As such this parameter is placed only the the content layer and is
not placed in the recipient or signature layers. In principle, one not placed in the recipient or signature layers. In principle, one
should be able to process any given layer without reference to any should be able to process any given layer without reference to any
other layer. (The only data that should need to cross layers is the other layer. (The only data that should need to cross layers is the
cryptographic key.) cryptographic key.)
The presence of both buckets is required. The parameters that go The buckets are present in all of the security objects defined in
into the buckets come from the IANA "COSE Header Parameters" this document. The fields in order are the 'protected' bucket (as a
CBOR 'bstr' type) and then the 'unprotected' bucket (as a CBOR 'map'
type). The presence of both buckets is required. The parameters
that go into the buckets come from the IANA "COSE Header Parameters"
(Section 15.2). Some common parameters are defined in the next (Section 15.2). Some common parameters are defined in the next
section, but a number of parameters are defined throughout this section, but a number of parameters are defined throughout this
document. document.
The CDDL fragment that describes the two buckets is: Text from here to start of next section to be removed [CREF8]
header_map = {+ label => any } header_map = {+ label => any }
Headers = ( Headers = (
protected : bstr, ; Contains a header_map protected : bstr, ; Contains a header_map
unprotected : header_map unprotected : header_map
) )
3.1. Common COSE Headers Parameters 3.1. Common COSE Headers Parameters
This section defines a set of common header parameters. A summary of This section defines a set of common header parameters. A summary of
those parameters can be found in Table 1. This table should be those parameters can be found in Table 1. This table should be
consulted to determine the value of label used as well as the type of consulted to determine the value of label used as well as the type of
the value. the value.
The set of header parameters defined in this section are: The set of header parameters defined in this section are:
alg This parameter is used to indicate the algorithm used for the alg This parameter is used to indicate the algorithm used for the
security processing. This parameter MUST be present at each level security processing. This parameter MUST be present at each level
of a signed, encrypted or authenticated message. The value is of a signed, encrypted or authenticated message. The value is
taken from the 'COSE Algorithm Registry' (see Section 15.3). taken from the 'COSE Algorithm Registry' (see Section 15.4).
crit This parameter is used to ensure that applications will take crit This parameter is used to ensure that applications will take
appropriate action based on the values found. The parameter is appropriate action based on the values found. The parameter is
used to indicate which protected header labels an application that used to indicate which protected header labels an application that
is processing a message is required to understand. The value is is processing a message is required to understand. The value is
an array of COSE Header Labels. When present, this parameter MUST an array of COSE Header Labels. When present, this parameter MUST
be placed in the protected header bucket. be placed in the protected header bucket.
* Integer labels in the range of 0 to 10 SHOULD be omitted. * Integer labels in the range of 0 to 10 SHOULD be omitted.
skipping to change at page 11, line 36 skipping to change at page 12, line 17
structure of 'kid' values is not defined and generally cannot be structure of 'kid' values is not defined and generally cannot be
relied on by applications. Key identifier values are hints about relied on by applications. Key identifier values are hints about
which key to use, they are not directly a security critical field, which key to use, they are not directly a security critical field,
for this reason they can be placed in the unprotected headers for this reason they can be placed in the unprotected headers
bucket. bucket.
nonce This parameter holds either a nonce or Initialization Vector nonce This parameter holds either a nonce or Initialization Vector
value. The value can be used either as a counter value for a value. The value can be used either as a counter value for a
protocol or as an IV for an algorithm. protocol or as an IV for an algorithm.
+----------+-------+----------+-----------------+-------------------+ counter signature This parameter holds a counter signature value.
| name | label | value | value registry | description | Counter signatures provide a method of having a second party sign
| | | type | | | some data, the counter signature can occur as an unprotected
+----------+-------+----------+-----------------+-------------------+ attribute in any of the following structures: COSE_Sign,
| alg | 1 | int / | COSE Algorithm | Integers are | COSE_signature, COSE_enveloped, COSE_recipient,
| | | tstr | Registry | taken from table | COSE_encryptedData, COSE_mac. These structures all have the same
| | | | | --POINT TO | basic structure so that a consistent calculation of the counter
| | | | | REGISTRY-- | signature can be computed. Details on computing counter
| | | | | | signatures are found in Section 4.3.
| crit | 2 | [+ | COSE Header | integer values |
| | | label] | Label Registry | are from -- | +----------+-------+---------------+----------------+---------------+
| | | | | POINT TO REGISTRY | | name | label | value type | value registry | description |
| | | | | -- | +----------+-------+---------------+----------------+---------------+
| | | | | | | alg | 1 | int / tstr | COSE Algorithm | Integers are |
| content | 3 | tstr / | CoAP Content- | Value is either a | | | | | Registry | taken from |
| type | | int | Formats or | Media Type or an | | | | | | table --POINT |
| | | | Media Types | integer from the | | | | | | TO REGISTRY-- |
| | | | registry | CoAP Content | | | | | | |
| | | | | Format registry | | crit | 2 | [+ label] | COSE Header | integer |
| | | | | | | | | | Label Registry | values are |
| jku | * | tstr | | URL to COSE key | | | | | | from -- |
| | | | | object | | | | | | POINT TO |
| | | | | | | | | | | REGISTRY -- |
| jwk | * | COSE_Key | | contains a COSE | | | | | | |
| | | | | key not a JWK key | | content | 3 | tstr / int | CoAP Content- | Value is |
| | | | | | | type | | | Formats or | either a |
| kid | 4 | bstr | | key identifier | | | | | Media Types | Media Type or |
| | | | | | | | | | registry | an integer |
| nonce | 5 | bstr | | Nonce or | | | | | | from the CoAP |
| | | | | Initialization | | | | | | Content |
| | | | | Vector (IV) | | | | | | Format |
| | | | | | | | | | | registry |
| x5c | * | bstr* | | X.509 Certificate | | | | | | |
| | | | | Chain | | kid | 4 | bstr | | key |
| | | | | | | | | | | identifier |
| x5t | * | bstr | | SHA-1 thumbprint | | | | | | |
| | | | | of key | | nonce | 5 | bstr | | Nonce or Init |
| | | | | | | | | | | ialization |
| x5t#S256 | * | bstr | | SHA-256 | | | | | | Vector (IV) |
| | | | | thumbprint of key | | | | | | |
| | | | | | | counter | 6 | COSE_signatur | | CBOR encoded |
| x5u | * | tstr | | URL for X.509 | | signatur | | e | | signature |
| | | | | certificate | | e | | | | structure |
| | | | | | | | | | | |
| zip | * | int / | | Integers are | | zip | * | int / tstr | | Integers are |
| | | tstr | | taken from the | | | | | | taken from |
| | | | | table --POINT TO | | | | | | the table |
| | | | | REGISTRY-- | | | | | | --POINT TO |
+----------+-------+----------+-----------------+-------------------+ | | | | | REGISTRY-- |
+----------+-------+---------------+----------------+---------------+
Table 1: Common Header Parameters Table 1: Common Header Parameters
OPEN ISSUES: OPEN ISSUES:
1. Which of the following items do we want to have standardized in 1. Do we want to have a zip/compression header standardized in this
this document: jku, jwk, x5c, x5t, x5t#S256, x5u, zip document?
2. I am currently torn on the question "Should epk and iv/nonce be 2. I am currently torn on the question "Should epk and iv/nonce be
algorithm specific or generic headers?" They are really specific algorithm specific or generic headers?" They are really specific
to an algorithm and can potentially be defined in different ways to an algorithm and can potentially be defined in different ways
for different algorithms. As an example, it would make sense to for different algorithms. As an example, it would make sense to
defined nonce for CCM and GCM modes that can have the leading defined nonce for CCM and GCM modes that can have the leading
zero bytes stripped, while for other algorithms this might be zero bytes stripped, while for other algorithms this might be
undesirable. undesirable.
3. We might want to define some additional items. What are they? A 3. We might want to define some additional items. What are they? A
skipping to change at page 13, line 44 skipping to change at page 15, line 5
generated by the same signer. Support of different communities of generated by the same signer. Support of different communities of
recipients is the primary reason that signers choose to include more recipients is the primary reason that signers choose to include more
than one signature. For example, the COSE_Sign structure might than one signature. For example, the COSE_Sign structure might
include signatures generated with the RSA signature algorithm and include signatures generated with the RSA signature algorithm and
with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature
algorithm. This allows recipients to verify the signature associated algorithm. This allows recipients to verify the signature associated
with one algorithm or the other. (The original source of this text with one algorithm or the other. (The original source of this text
is [RFC5652].) More detailed information on multiple signature is [RFC5652].) More detailed information on multiple signature
evaluation can be found in [RFC5752]. evaluation can be found in [RFC5752].
The CDDL grammar for a signature message is: The COSE_Sign structure is a CBOR array. The fields of the array in
order are:
COSE_Sign = [
msg_type: msg_type_signed,
Headers,
payload : bstr,
signatures : [+ COSE_signature]
]
The fields in the array have the following semantics:
msg_type identifies this as providing the signed security service. msg_type identifies this as providing the signed security service.
The value MUST be msg_type_signed (1). The value MUST be msg_type_signed (1).
protected is described in Section 3. protected is described in Section 3.
unprotected is described in Section 3. unprotected is described in Section 3.
payload contains the serialized content to be signed. If the payload contains the serialized content to be signed. If the
payload is not present in the message, the application is required payload is not present in the message, the application is required
to supply the payload separately. The payload is wrapped in a to supply the payload separately. The payload is wrapped in a
bstr to ensure that it is transported without changes. If the bstr to ensure that it is transported without changes. If the
payload is transported separately, it is the responsibility of the payload is transported separately, then a nil CBOR object is
placed in this location and it is the responsibility of the
application to ensure that it will be transported without changes. application to ensure that it will be transported without changes.
signatures is an array of signature items. Each of these items uses signatures is an array of signature items. Each of these items uses
the COSE_signature structure for its representation. the COSE_signature structure for its representation.
The CDDL grammar structure for a signature is: The COSE_signature structure is a CBOR array. The fields of the
array in order are:
COSE_signature = [
Headers,
signature : bstr
]
The fields in the array have the following semantics:
protected is described in Section 3. protected is described in Section 3.
unprotected is described in Section 3. unprotected is described in Section 3.
signature contains the computed signature value. signature contains the computed signature value. The type of the
field is a bstr.
Text from here to start of next section to be removed
COSE_Sign = [
msg_type: msg_type_signed,
Headers,
payload : bstr / nil,
signatures : [+ COSE_signature]
]
COSE_signature = [
Headers,
signature : bstr
]
4.1. Externally Supplied Data 4.1. Externally Supplied Data
One of the features that we supply in the COSE document is the One of the features that we supply in the COSE document is the
ability for applications to provide additional data to be ability for applications to provide additional data to be
authenticated as part of the security, but that is not carried as authenticated as part of the security, but that is not carried as
part of the COSE object. The primary reason for supporting this can part of the COSE object. The primary reason for supporting this can
be seen by looking at the CoAP message struture [RFC7252] where the be seen by looking at the CoAP message struture [RFC7252] where the
facility exists for options to be carried before the payload. An facility exists for options to be carried before the payload. An
example of data that can be placed in this location would be example of data that can be placed in this location would be
skipping to change at page 15, line 27 skipping to change at page 16, line 41
Using options from CoAP as an example, these fields use a TLV Using options from CoAP as an example, these fields use a TLV
structure so they can be concatenated without any problems. structure so they can be concatenated without any problems.
o If multiple items are included, a defined order for the items o If multiple items are included, a defined order for the items
needs to be defined. Using options from CoAP as an example, an needs to be defined. Using options from CoAP as an example, an
application could state that the fields are to be ordered by the application could state that the fields are to be ordered by the
option number. option number.
4.2. Signing and Verification Process 4.2. Signing and Verification Process
The COSE structure used to create the byte stream to be signed uses In order to create a signature, a consistent byte stream is needed in
the following CDDL grammar structure: order to process. This document uses a CBOR array to construct the
byte stream to be processed. The fields of the array in order are:
Sig_structure = [ 1. The body protected attributes. This is a bstr type containing
body_protected: bstr, the protected attributes of the body.
sign_protected: bstr,
external_aad: bstr, 2. The signature protected attributes. This is a bstr type
payload: bstr containing the protected attributes of the signature.
]
3. The external protected attributes. This is a bstr type
containing the protected attributes external to the
COSE_Signature structure.
4. The payload to be signed. The payload is encoded in a bstr. 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 object and populate it with the 1. Create a CBOR array and populate it with the appropriate fields.
appropriate fields. For body_protected and sign_protected, if For body_protected and sign_protected, if the fields are not
the fields are not present in their corresponding maps, an bstr present in their corresponding maps, an bstr of length zero is
of length zero is used. used.
2. If the application has supplied external additional authenticated 2. If the application has supplied external additional authenticated
data to be included in the computation, then it is placed in the data to be included in the computation, then it is placed in the
'external_aad' field. If no data was supplied, then a zero third field. If no data was supplied, then a zero length binary
length binary value is used. value is used.
3. Create the value ToBeSigned by encoding the Sig_structure to a 3. Create the value ToBeSigned by encoding the Sig_structure to a
byte string. byte string.
4. Call the signature creation algorithm passing in K (the key to 4. 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).
5. Place the resulting signature value in the 'signature' field of 5. Place the resulting signature value in the 'signature' field of
the map. the map.
How to verify a signature: How to verify a signature:
1. Create a Sig_structure object and populate it with the 1. Create a Sig_structure object and populate it with the
appropriate fields. For body_protected and sign_protected, if appropriate fields. For body_protected and sign_protected, if
the fields are not present in their corresponding maps, an bstr the fields are not present in their corresponding maps, an bstr
of length zero is used. of length zero is used.
2. If the application has supplied external additional authenticated 2. If the application has supplied external additional authenticated
data to be included in the computation, then it is placed in the data to be included in the computation, then it is placed in the
'external_aad' field. If no data was supplied, then a zero third field. If no data was supplied, then a zero length binary
length binary value is used. value is used.
3. Create the value ToBeSigned by encoding the Sig_structure to a 3. Create the value ToBeSigned by encoding the Sig_structure to a
byte string. byte string.
4. Call the signature verification algorithm passing in K (the key 4. Call the signature verification algorithm passing in K (the key
to verify with), alg (the algorithm to sign with), ToBeSigned to verify with), alg (the algorithm to 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, one must also In addition to performing the signature verification, one must also
perform the appropriate checks to ensure that the key is correctly perform the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the appropriate paired with the signing identity and that the appropriate
authorization is done. authorization is done.
5. Encryption object Text from here to start of next section to be removed
The encryption structure allows for one or more recipients of a The COSE structure used to create the byte stream to be signed uses
the following CDDL grammar structure:
Sig_structure = [
body_protected: bstr,
sign_protected: bstr,
external_aad: bstr,
payload: bstr
]
4.3. Computing Counter Signatures
Counter signatures provide a method of having a different signature
occur on some piece of content. This is normally used to provide a
signature on a signature allowing for a proof that a signature
existed at a given time. In this document we allow for counter
signatures to exist in a greater number of environments. A counter
signature can exist, for example, on a COSE_encyptedData object and
allow for a signature to be present on the encrypted content of a
message.
The creation and validation of counter signatures over the different
items relies on the fact that the structure all of our objects have
the same structure. The first element may be a message type, this is
followed by a set of protected attributes, a set of unprotected
attributes and a body in that order. This means that the
Sig_structure can be used for in a uniform manner to get the byte
stream for processing a signature. If the counter signature is going
to be computed over a COSE_encryptedData structure, the
body_protected and payload items can be mapped into the Sig_structure
in the same manner as from the COSE_Sign structure.
While one can create a counter signature for a COSE_Sign structure,
there is not much of a point to doing so. It is equivalent to create
a new COSE_signature structure and placing it in the signatures
array. It is strongly suggested that it not be done, but it is not
banned.
5. Encryption objects
COSE supports two different encryption structures. OOSE_enveloped is
used when the key needs to be explicilty identified. This structure
supports the use of recipient structures to allow for random content
encryption keys to be used.. COSE_encrypted is used when the a
recipient structure is not needed because the key to be used is known
implicitly.
5.1. Enveloped COSE structure
The enveloped structure allows for one or more recipients of a
message. There are provisions for parameters about the content and message. There are provisions for parameters about the content and
parameters about the recipient information to be carried in the parameters about the recipient information to be carried in the
message. The parameters associated with the content can be message. The parameters associated with the content can be
authenticated by the content encryption algorithm. The parameters authenticated by the content encryption algorithm. The parameters
associated with the recipient can be authenticated by the recipient associated with the recipient can be authenticated by the recipient
algorithm (when the algorithm supports it). Examples of parameters algorithm (when the algorithm supports it). Examples of parameters
about the content are the type of the content, when the content was about the content are the type of the content, when the content was
created, and the content encryption algorithm. Examples of created, and the content encryption algorithm. Examples of
parameters about the recipient are the recipients key identifier, the parameters about the recipient are the recipients key identifier, the
recipient encryption algorithm. recipient encryption algorithm.
In COSE, the same techniques and structures for encrypting both the In COSE, the same techniques and structures for encrypting both the
plain text and the keys used to protect the text. This is different plain text and the keys used to protect the text. This is different
from the approach used by both [RFC5652] and [RFC7516] where from the approach used by both [RFC5652] and [RFC7516] where
different structures are used for the content layer and for the different structures are used for the content layer and for the
recipient layer. recipient layer.
The CDDL grammar structure for encryption is: The COSE_encrypt structure is a CBOR array. The fields of the array
in order are:
COSE_encrypt = [ msg_type identifies this as providing the encrypted security
msg_type: msg_type_encrypted, service. The value MUST be msg_type_encrypted (2).
COSE_encrypt_fields
]
COSE_encrypt_fields = ( protected is described in Section 3.
Headers,
ciphertext: bstr,
? recipients: [+[COSE_encrypt_fields]]
)
Description of the fields: unprotected is described in Section 3.
msg_type identifies this as providing the encrypted security ciphertext contains the encrypted plain text encoded as a bstr. If
service. The value MUST be msg_type_encrypted (2). the ciphertext is to be transported independently of the control
information about the encryption process (i.e. detached content)
then the field is encoded as a null object.
recipients contains an array of recipient information structures.
The type for the recipient information structure is a
COSE_recipient.
The COSE_recipient structure is a CBOR array. The fields of the
array in order are:
protected is described in Section 3. protected is described in Section 3.
unprotected is described in Section 3. unprotected is described in Section 3.
ciphertext contains the encrypted plain text. If the ciphertext is ciphertext contains the encrypted key encoded as a bstr. If there
to be transported independently of the control information about is not an encrypted key, then this field is encoded as a nil type.
the encryption process (i.e. detached content) then the field is
omitted.
recipients contains the recipient information. It is required that recipients contains an array of recipient information structures.
at least one recipient MUST be present for the content encryption The type for the recipient information structure is a
layer. COSE_recipient. If there are no recipient information structures,
this element is absent.
5.1. Recipient Algorithm Classes Text from here to start of next section to be removed
COSE_enveloped = [
msg_type: msg_type_enveloped,
COSE_encrypt_fields
recipients: [+COSE_recipient]
]
COSE_encrypt_fields = (
Headers,
ciphertext: bstr / nil,
)
COSE_recipient = [
COSE_encrypt_fields
? recipients: [+COSE_recipient]
]
5.1.1. Recipient Algorithm Classes
A typical encrypted message consists of an encrypted content and an A typical encrypted message consists of an encrypted content and an
encrypted CEK for one or more recipients. The content-encryption key encrypted CEK for one or more recipients. The content-encryption key
is encrypted for each recipient, using a key specific to that is encrypted for each recipient, using a key specific to that
recipient. The details of this encryption depends on which class the recipient. The details of this encryption depends on which class the
recipient algorithm falls into. Specific details on each of the recipient algorithm falls into. Specific details on each of the
classes can be found in Section 12. A short summary of the six classes can be found in Section 12. A short summary of the six
recipient algorithm classes is: recipient algorithm classes is:
none: The CEK is the same as as the identified previously none: The CEK is the same as as the identified previously
skipping to change at page 18, line 18 skipping to change at page 21, line 18
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 KDF is applied to derive are used to generate a pairwise secret, a KDF is applied to derive
a key, and then the CEK is either the derived key or encrypted by a key, and then the CEK is either the derived key or encrypted by
the derived key. the derived key.
key transport: the CEK is encrypted in the recipient's public key key transport: the CEK is encrypted in the recipient's public key
passwords: the CEK is encrypted in a key-encryption key that is passwords: the CEK is encrypted in a key-encryption key that is
derived from a password. derived from a password.
5.2. Encryption Algorithm for AEAD algorithms 5.2. Encrypted COSE structure
The encrypted structure does not have the ability to specify
recipients of the message. The structure assumes that the 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 identified to the
recipient, the enveloped structure is used.
The CDDL grammar structure for encrypted data is:
COSE_encryptData = [
msg_type: msg_type_encryptData,
COSE_encrypt_fields
]
The COSE_encryptedData structure is a CBOR array. The fields of the
array in order are:
msg_type identifies this as providing the encrypted data security
service. This value MUST be mg_type_encrypted (4).
protected is described in Section 3.
unprotected is described in Section 3.
ciphertext contains the encrypted plain text. If the ciphertext is
to be transported independently of the control information about
the encryption process (i.e. detached content) then the field is
encoded as a null object.
5.3. Encryption Algorithm for AEAD algorithms
The encryption algorithm for AEAD algorithms is fairly simple. In The encryption algorithm for AEAD algorithms is fairly simple. In
order to get a consistent encoding of the data to be authenticated, order to get a consistent encoding of the data to be authenticated,
the Enc_structure is used to have canonical form of the AAD. the Enc_structure is used to have canonical form of the AAD.
Enc_structure = [
protected: bstr,
external_aad: bstr
]
1. Copy the protected header field from the message to be sent. 1. Copy the protected header field from the message to be sent.
2. If the application has supplied external additional authenticated 2. If the application has supplied external additional authenticated
data to be included in the computation, then it is placed in the data to be included in the computation, then it is placed in the
'external_aad' field. If no data was supplied, then a zero 'external_aad' field. If no data was supplied, then a zero
length binary value is used. (See Section 4.1 for application length binary value is used. (See Section 4.1 for application
guidance on constructing this field.) guidance on constructing this field.)
3. Encode the Enc_structure using a CBOR Canonical encoding 3. Encode the Enc_structure using a CBOR Canonical encoding
Section 14 to get the AAD value. Section 14 to get the AAD value.
skipping to change at page 19, line 16 skipping to change at page 22, line 39
5. Call the encryption algorithm with K (the encryption key to use), 5. Call the encryption algorithm with K (the encryption key to use),
P (the plain text) and AAD (the additional authenticated data). P (the plain text) and AAD (the additional authenticated data).
Place the returned cipher text into the 'ciphertext' field of the Place the returned cipher text into the 'ciphertext' field of the
structure. structure.
6. For recipients of the message, recursively perform the encryption 6. For recipients of the message, recursively perform the encryption
algorithm for that recipient using the encryption key as the algorithm for that recipient using the encryption key as the
plain text. plain text.
5.3. Encryption algorithm for AE algorithms Text from here to start of next section to be removed
Enc_structure = [
protected: bstr,
external_aad: bstr
]
5.4. Encryption algorithm for AE algorithms
1. Verify that the 'protected' field is absent. 1. Verify that the 'protected' field is absent.
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
skipping to change at page 20, line 18 skipping to change at page 23, line 47
can be used for this purpose. The second mode is to both check that can be used for this purpose. The second mode is to both check that
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 recipient algorithm to verify who sent it. The classes of use 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 key agreement (without the key wrap shared secret or do static-static key agreement (without the key wrap
step). In both of these cases the entity MACing the message can be step). In both of these cases the entity MACing the message can be
validated by a key binding. (The binding of identity assumes that validated by a key binding. (The binding of identity assumes that
there are only two parties involved and you did not send the message there are only two parties involved and you did not send the message
yourself.) yourself.)
COSE_mac = [ The COSE_encrypt structure is a CBOR array. The fields of the array
msg_type: msg_type_mac, in order are:
Headers,
payload: bstr,
tag: bstr,
recipients: [+[COSE_encrypt_fields]]
]
Field descriptions:
msg_type identifies this as providing the encrypted security msg_type identifies this as providing the encrypted security
service. The value MUST be msg_type_mac (3). service. The value MUST be msg_type_mac (3).
protected is described in Section 3. protected is described in Section 3.
unprotected is described in Section 3. unprotected is described in Section 3.
payload contains the serialized content to be MACed. If the payload payload contains the serialized content to be MACed. If the payload
is not present in the message, the application is required to is not present in the message, the application is required to
supply the payload separately. The payload is wrapped in a bstr supply the payload separately. The payload is wrapped in a bstr
to ensure that it is transported without changes, if the payload to ensure that it is transported without changes. If the payload
is transported separately it is the responsibility of the is transported separately, then a null CBOR object is placed in
application to ensure that it will be transported without changes. this location and it is the responsibility of the application to
ensure that it will be transported without changes.
tag contains the MAC value. tag contains the MAC value.
recipients contains the recipient information. See the description recipients contains the recipient information. See the description
under COSE_Encryption for more info. under COSE_Encryption for more info.
MAC_structure = [ Text from here to start of next section to be removed
protected: bstr,
external_aad: bstr, COSE_mac = [
payload: bstr msg_type: msg_type_mac,
Headers,
payload: bstr / nil,
tag: bstr,
recipients: [+COSE_recipient]
] ]
6.1. How to compute a MAC
How to compute a MAC: How to compute a MAC:
1. Create a MAC_structure and copy the protected and payload fields 1. Create a MAC_structure and copy the protected and payload fields
from the COSE_mac structure. from the COSE_mac structure.
2. If the application has supplied external authenticated data, 2. If the application has supplied external authenticated data,
encode it as a binary value and place in the MAC_structure. If encode it as a binary value and place in the MAC_structure. If
there is no external authenticated data, then use a zero length there is no external authenticated data, then use a zero length
'bstr'. (See Section 4.1 for application guidance on 'bstr'. (See Section 4.1 for application guidance on
constructing this field.) constructing this field.)
3. Encode the MAC_structure using a canonical CBOR encoder. The 3. Encode the MAC_structure using a canonical CBOR encoder. The
resulting bytes is the value to compute the MAC on. resulting bytes is the value to compute the MAC on.
4. Compute the MAC and place the result in the 'tag' field of the 4. Compute the MAC and place the result in the 'tag' field of the
COSE_mac structure. COSE_mac structure.
5. Encrypt and encode the MAC key for each recipient of the message. 5. Encrypt and encode the MAC key for each recipient of the message.
Text from here to start of next section to be removed
MAC_structure = [
protected: bstr,
external_aad: bstr,
payload: bstr
]
7. Key Structure 7. Key Structure
A COSE Key structure is built on a CBOR map object. The set of A COSE Key structure is built on a CBOR map object. The set of
common parameters that can appear in a COSE Key can be found in the common parameters that can appear in a COSE Key can be found in the
IANA registry 'COSE Key Common Parameter Registry' (Section 15.5). IANA registry 'COSE Key Common Parameter Registry' (Section 15.5).
Additional parameters defined for specific key types can be found in Additional parameters defined for specific key types can be found in
the IANA registry 'COSE Key Type Parameters' (Section 15.6). the IANA registry 'COSE Key Type Parameters' (Section 15.6).
A COSE Key Set uses a CBOR array object as it's underlying type. The A COSE Key Set uses a CBOR array object as it's underlying type. The
values of the array elements are COSE Keys. A Key Set MUST have at values of the array elements are COSE Keys. A Key Set MUST have at
least one element in the array. [CREF8] least one element in the array. [CREF9]
The CDDL grammar describing a COSE_Key and COSE_KeySet is: [CREF9] The element "kty" is a required element in a COSE_Key map.
Text from here to start of next section to be removed
The CDDL grammar describing a COSE_Key and COSE_KeySet is: [CREF10]
COSE_Key = { COSE_Key = {
key_kty => tstr / int, key_kty => tstr / int,
? key_ops => [+ (tstr / int) ], ? key_ops => [+ (tstr / int) ],
? key_alg => tstr / int, ? key_alg => tstr / int,
? key_kid => bstr, ? key_kid => bstr,
* label => values * label => values
} }
COSE_KeySet = [+COSE_Key] COSE_KeySet = [+COSE_Key]
The element "kty" is a required element in a COSE_Key map.
7.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 2 provides a summary of the parameters defined in this object. Table 2 provides a summary of the parameters defined in this
section. There are also a set of parameters that are defined for a section. There are also a set of parameters that are defined for a
specific key type. Key type specific parameters can be found in specific key type. Key type specific parameters can be found in
Section 13. Section 13.
+----------+-------+-------------+------------+---------------------+ +---------+-------+-------------+-------------+---------------------+
| name | label | CBOR type | registry | description | | name | label | CBOR type | registry | description |
+----------+-------+-------------+------------+---------------------+ +---------+-------+-------------+-------------+---------------------+
| kty | 1 | tstr / int | COSE | Identification of | | kty | 1 | tstr / int | COSE | Identification of |
| | | | General | the key type | | | | | General | the key type |
| | | | Values | | | | | | Values | |
| | | | | | | | | | | |
| key_ops | 4 | [* | | Restrict set of | | key_ops | 4 | [* | | Restrict set of |
| | | (tstr/int)] | | permissible | | | | (tstr/int)] | | permissible |
| | | | | operations | | | | | | operations |
| | | | | | | | | | | |
| alg | 3 | tstr / int | COSE | Key usage | | alg | 3 | tstr / int | COSE | Key usage |
| | | | Algorithm | restriction to this | | | | | Algorithm | restriction to this |
| | | | Values | algorithm | | | | | Values | algorithm |
| | | | | | | | | | | |
| kid | 2 | bstr | | Key Identification | | kid | 2 | bstr | | Key Identification |
| | | | | value - match to | | | | | | value - match to |
| | | | | kid in message | | | | | | kid in message |
| | | | | | | | | | | |
| x5u | * | tstr | | | | use | * | tstr | | deprecated - don't |
| | | | | | | | | | | use |
| x5c | * | bstr* | | | +---------+-------+-------------+-------------+---------------------+
| | | | | |
| x5t | * | bstr | | |
| | | | | |
| x5t#S256 | * | bstr | | |
| | | | | |
| use | * | tstr | | deprecated - don't |
| | | | | use |
+----------+-------+-------------+------------+---------------------+
Table 2: Key Map Labels Table 2: 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 can be found in Table 20. This found. The set of values can be found in Table 20. This
parameter MUST be present in a key object. parameter MUST be present in a key object. Implementations MUST
verify that the key type is appropriate for the algorithm being
processed. The key type MUST be included as part of a trust
decision process.
alg: This parameter is used to restrict the algorithms that are to alg: This parameter is used to restrict the algorithms that are to
be used with this key. If this parameter is present in the key be used with this key. If this parameter is present in the key
structure, the application MUST verify that this algorithm matches structure, the application MUST verify that this algorithm matches
the algorithm for which the key is being used. If the algorthms the algorithm for which the key is being used. If the algorthms
do not match, then this key object MUST NOT be used to perform the do not match, then this key object MUST NOT be used to perform the
cryptographic operation. Note that the same key can be in a cryptographic operation. Note that the same key can be in a
different key structure with a different or no algorithm different key structure with a different or no algorithm
specified, however this is considered to be a poor security specified, however this is considered to be a poor security
practice. practice.
skipping to change at page 23, line 48 skipping to change at page 27, line 36
| | | | | | | |
| unwrap | 6 | The key is used for key unwrapping. Requires | | unwrap | 6 | The key is used for key unwrapping. Requires |
| key | | private key fields. | | key | | private key fields. |
| | | | | | | |
| key | 7 | The key is used for key agreement. | | key | 7 | The key is used for key agreement. |
| agree | | | | agree | | |
+---------+-------+-------------------------------------------------+ +---------+-------+-------------------------------------------------+
Table 3: Key Operation Values Table 3: Key Operation Values
Text from here to start of next section to be removed
The following provides a CDDL fragment which duplicates the The following provides a CDDL fragment which duplicates the
assignment labels from Table 2 and Table 3. assignment labels from Table 2 and Table 3.
;key_labels ;key_labels
key_kty=1 key_kty=1
key_kid=2 key_kid=2
key_alg=3 key_alg=3
key_ops=4 key_ops=4
;key_ops values ;key_ops values
skipping to change at page 25, line 40 skipping to change at page 29, line 40
+-------+-------+---------+------------------+ +-------+-------+---------+------------------+
| ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 | | ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 |
| | | | | | | | | |
| ES384 | -8 | SHA-384 | ECDSA w/ SHA-384 | | ES384 | -8 | SHA-384 | ECDSA w/ SHA-384 |
| | | | | | | | | |
| ES512 | -9 | SHA-512 | ECDSA w/ SHA-512 | | ES512 | -9 | SHA-512 | ECDSA w/ SHA-512 |
+-------+-------+---------+------------------+ +-------+-------+---------+------------------+
Table 4: ECDSA Algorithm Values Table 4: ECDSA Algorithm Values
This document defines ECDSA to work only with the curves P-256, P-384
and P-521. This document requires that the curves be encoded using
the 'EC2' key type. Implementations need to check that the key type
and curve are correct when creating and verifying a signature. Other
documents can defined it to work with other curves and points in the
future.
In order to promote interoperability, it is suggested that SHA-256 be In order to promote interoperability, it is suggested that SHA-256 be
used only with keys of length 256, SHA-384 be used only with keys of used only with curve P-256, SHA-384 be used only with curve P-384 and
length 384 and SHA-512 be used only with keys of length 521. This is SHA-512 be used with curve P-521. This is aligned with the
aligned with the recommendation in Section 4 of [RFC5480]. recommendation in Section 4 of [RFC5480].
The signature algorithm results in a pair of integers (R, S). These The signature algorithm results in a pair of integers (R, S). These
integers will be of the same order as length of the key used for the integers will be of the same order as length of the key used for the
signature process. The signature is encoded by converting the signature process. The signature is encoded by converting the
integers into byte strings of the same length as the key size. The integers into byte strings of the same length as the key size. The
length is rounded up to the nearest byte and is left padded with zero length is rounded up to the nearest byte and is left padded with zero
bits to get to the correct length. The two integers are then bits to get to the correct length. The two integers are then
concatenated together to form a byte string that is the resulting concatenated together to form a byte string that is the resulting
signature. signature.
skipping to change at page 26, line 39 skipping to change at page 30, line 47
There are two substitution that can theoretically be mounted against There are two substitution that can theoretically be mounted against
the ECDSA signature algorithm. the ECDSA signature algorithm.
o Changing the curve used to validate the signature: If one changes o Changing the curve used to validate the signature: If one changes
the curve used to validate the signature, then potentially one the curve used to validate the signature, then potentially one
could have a two messages with the same signature each computed could have a two messages with the same signature each computed
under a different curve. The only requirement on the new curve is under a different curve. The only requirement on the new curve is
that it's order be the same as the old one and it be acceptable to that it's order be the same as the old one and it be acceptable to
the client. An example would be to change from using the curve the client. An example would be to change from using the curve
P-256 to using Curve25519. (Both are 256 bit curves.) We current secp256r1 (aka P-256) to using secp256k1. (Both are 256 bit
do not have any way to deal with this version of the attack except curves.) We current do not have any way to deal with this version
to restrict the overall set of curves that can be used. of the attack except to restrict the overall set of curves that
can be used.
o Change the hash function used to validate the signature: If one o Change the hash function used to validate the signature: If one
has either two different hash functions of the same length, or one has either two different hash functions of the same length, or one
can truncate a hash function down, then one could potentially find can truncate a hash function down, then one could potentially find
collisions between the hash functions rather than within a single collisions between the hash functions rather than within a single
hash function. (For example, truncating SHA-512 to 256 bits might hash function. (For example, truncating SHA-512 to 256 bits might
collide with a SHA-256 bit hash value.) This attack can be collide with a SHA-256 bit hash value.) This attack can be
mitigated by including the signature algorithm identifier in the mitigated by including the signature algorithm identifier in the
data to be signed. data to be signed.
skipping to change at page 27, line 18 skipping to change at page 31, line 27
The RSASSA-PSS signature algorithm is parametized with a hash The RSASSA-PSS signature algorithm is parametized with a hash
function (h), a mask generation function (mgf) and a salt length function (h), a mask generation function (mgf) and a salt length
(sLen). For this specification, the mask generation function is (sLen). For this specification, the mask generation function is
fixed to be MGF1 as defined in [RFC3447]. It has been recommended fixed to be MGF1 as defined in [RFC3447]. It has been recommended
that the same hash function be used for hashing the data as well as that the same hash function be used for hashing the data as well as
in the mask generation function, for this specification we following in the mask generation function, for this specification we following
this recommendation. The salt length is the same length as the hash this recommendation. The salt length is the same length as the hash
function output. function output.
Implementations need to check that the key type is 'RSA' when
creating or verifying a signature.
The algorithms defined in this document can be found in Table 5. The algorithms defined in this document can be found in Table 5.
+-------+-------+---------+-------------+-----------------------+ +-------+-------+---------+-------------+-----------------------+
| name | value | hash | salt length | description | | name | value | hash | salt length | description |
+-------+-------+---------+-------------+-----------------------+ +-------+-------+---------+-------------+-----------------------+
| PS256 | -26 | SHA-256 | 32 | RSASSA-PSS w/ SHA-256 | | PS256 | -26 | SHA-256 | 32 | RSASSA-PSS w/ SHA-256 |
| | | | | | | | | | | |
| PS384 | -27 | SHA-384 | 48 | RSASSA-PSS w/ SHA-384 | | PS384 | -27 | SHA-384 | 48 | RSASSA-PSS w/ SHA-384 |
| | | | | | | | | | | |
| PS512 | -28 | SHA-512 | 64 | RSASSA-PSS w/ SHA-512 | | PS512 | -28 | SHA-512 | 64 | RSASSA-PSS w/ SHA-512 |
skipping to change at page 29, line 32 skipping to change at page 33, line 43
Table 6: HMAC Algorithm Values Table 6: HMAC Algorithm Values
Some recipient algorithms carry the key while others derive a key Some recipient algorithms carry the key while others derive a key
from secret data. For those algorithms which carry the key (i.e. from secret data. For those algorithms which carry the key (i.e.
RSA-OAEP and AES-KeyWrap), the size of the HMAC key SHOULD be the RSA-OAEP and AES-KeyWrap), the size of the HMAC key SHOULD be the
same size as the underlying hash function. For those algorithms same size as the underlying hash function. For those algorithms
which derive the key, the derived key MUST be the same size as the which derive the key, the derived key MUST be the same size as the
underlying hash function. underlying hash function.
If the key obtained from a key structure, the key type MUST be
'Symmetric'. Implementations creating and validating MAC values MUST
validate that the key type, key length and algorithm are correct and
appropriate for the entities involved.
9.1.1. Security Considerations 9.1.1. Security Considerations
HMAC has proved to be resistant even when used with weakening hash HMAC has proved to be resistant even when used with weakening hash
algorithms. The current best method appears to be a brute force algorithms. The current best method appears to be a brute force
attack on the key. This means that key size is going to be directly attack on the key. This means that key size is going to be directly
related to the security of an HMAC operation. related to the security of an HMAC operation.
9.2. AES Message Authentication Code (AES-CBC-MAC) 9.2. AES Message Authentication Code (AES-CBC-MAC)
AES-CBC-MAC is defined in [MAC]. AES-CBC-MAC is defined in [MAC].
skipping to change at page 30, line 24 skipping to change at page 34, line 36
| | | | | | | | | | | |
| AES-MAC | * | 128 | 128 | AES-MAC 128 bit key, | | AES-MAC | * | 128 | 128 | AES-MAC 128 bit key, |
| 128/128 | | | | 128-bit tag | | 128/128 | | | | 128-bit tag |
| | | | | | | | | | | |
| AES-MAC | * | 256 | 128 | AES-MAC 256 bit key, | | AES-MAC | * | 256 | 128 | AES-MAC 256 bit key, |
| 256/128 | | | | 128-bit tag | | 256/128 | | | | 128-bit tag |
+-------------+-------+----------+----------+-----------------------+ +-------------+-------+----------+----------+-----------------------+
Table 7: AES-MAC Algorithm Values Table 7: AES-MAC Algorithm Values
Keys may be obtained either from a key structure or from a recipient
structure. If the key obtained from a key structure, the key type
MUST be 'Symmetric'. Implementations creating and validating MAC
values MUST validate that the key type, key length and algorithm are
correct and appropriate for the entities involved.
9.2.1. Security Considerations 9.2.1. Security Considerations
A number of attacks exist against CBC-MAC that need to be considered. A number of attacks exist against CBC-MAC that need to be considered.
o A single key must only be used for messages of a fixed and known o A single key must only be used for messages of a fixed and known
length. If this is not the case, an attacker will be able to length. If this is not the case, an attacker will be able to
generated a message with a valid tag given two message, tag pairs. generated a message with a valid tag given two message, tag pairs.
This can be addressed by using different keys for different length This can be addressed by using different keys for different length
messages. (CMAC mode also addresses this issue.) messages. (CMAC mode also addresses this issue.)
skipping to change at page 31, line 43 skipping to change at page 36, line 17
+---------+-------+-----------------------------+ +---------+-------+-----------------------------+
| A128GCM | 1 | AES-GCM mode w/ 128-bit key | | A128GCM | 1 | AES-GCM mode w/ 128-bit key |
| | | | | | | |
| A192GCM | 2 | AES-GCM mode w/ 192-bit key | | A192GCM | 2 | AES-GCM mode w/ 192-bit key |
| | | | | | | |
| A256GCM | 3 | AES-GCM mode w/ 256-bit key | | A256GCM | 3 | AES-GCM mode w/ 256-bit key |
+---------+-------+-----------------------------+ +---------+-------+-----------------------------+
Table 8: Algorithm Value for AES-GCM Table 8: Algorithm Value for AES-GCM
Keys may be obtained either from a key structure or from a recipient
structure. If the key obtained from a key structure, the key type
MUST be 'Symmetric'. Implementations creating and validating MAC
values MUST validate that the key type, key length and algorithm are
correct and appropriate for the entities involved.
10.1.1. Security Considerations 10.1.1. Security Considerations
When using AES-CCM the following restrictions MUST be enforced: When using AES-CCM the following restrictions MUST be enforced:
o The key and nonce pair MUST be unique for every message encrypted. o The key and nonce pair MUST be unique for every message encrypted.
o The total amount of data encrypted MUST NOT exceed 2^39 - 256 bits o The total amount of data encrypted MUST NOT exceed 2^39 - 256 bits
. An explicit check is required only in environments where it is . An explicit check is required only in environments where it is
expected that it might be exceeded. expected that it might be exceeded.
skipping to change at page 34, line 47 skipping to change at page 38, line 47
| | | | | | nonce | | | | | | | nonce |
| | | | | | | | | | | | | |
| AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode | | AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode |
| | | | | | 256-bit key, | | | | | | | 256-bit key, |
| | | | | | 128-bit tag, 7-byte | | | | | | | 128-bit tag, 7-byte |
| | | | | | nonce | | | | | | | nonce |
+--------------------+-------+----+-----+-----+---------------------+ +--------------------+-------+----+-----+-----+---------------------+
Table 9: Algorithm Values for AES-CCM Table 9: Algorithm Values for AES-CCM
Keys may be obtained either from a key structure or from a recipient
structure. If the key obtained from a key structure, the key type
MUST be 'Symmetric'. Implementations creating and validating MAC
values MUST validate that the key type, key length and algorithm are
correct and appropriate for the entities involved.
10.2.1. Security Considerations 10.2.1. Security Considerations
When using AES-CCM the following restrictions MUST be enforced: When using AES-CCM the following restrictions MUST be enforced:
o The key and nonce pair MUST be unique for every message encrypted. o The key and nonce pair MUST be unique for every message encrypted.
o The total number of times the AES block cipher is used MUST NOT o The total number of times the AES block cipher is used MUST NOT
exceed 2^61 operations. This limitation is the sum of times the exceed 2^61 operations. This limitation is the sum of times the
block cipher is used in computing the MAC value and in performing block cipher is used in computing the MAC value and in performing
stream encryption operations. An explicit check is required only stream encryption operations. An explicit check is required only
skipping to change at page 35, line 44 skipping to change at page 39, line 50
this algorithm in Table 10. this algorithm in Table 10.
+-------------------+-------+----------------------------------+ +-------------------+-------+----------------------------------+
| name | value | description | | name | value | description |
+-------------------+-------+----------------------------------+ +-------------------+-------+----------------------------------+
| ChaCha20/Poly1305 | 11 | ChaCha20/Poly1305 w/ 256-bit key | | ChaCha20/Poly1305 | 11 | ChaCha20/Poly1305 w/ 256-bit key |
+-------------------+-------+----------------------------------+ +-------------------+-------+----------------------------------+
Table 10: Algorithm Value for AES-GCM Table 10: Algorithm Value for AES-GCM
Keys may be obtained either from a key structure or from a recipient
structure. If the key obtained from a key structure, the key type
MUST be 'Symmetric'. Implementations creating and validating MAC
values MUST validate that the key type, key length and algorithm are
correct and appropriate for the entities involved.
10.3.1. Security Considerations 10.3.1. Security Considerations
The pair of key, nonce MUST be unique for every invocation of the The pair of key, nonce MUST be unique for every invocation of the
algorithm. Nonce counters are considered to be an acceptable way of algorithm. Nonce counters are considered to be an acceptable way of
ensuring that they are unique. ensuring that they are unique.
11. Key Derivation Functions (KDF) 11. Key Derivation Functions (KDF)
Key Derivation Functions (KDFs) are used to take some secret value Key Derivation Functions (KDFs) are used to take some secret value
and generate a different one. The original secret values come in and generate a different one. The original secret values come in
skipping to change at page 38, line 40 skipping to change at page 42, line 40
11.2. Context Information Structure 11.2. Context Information Structure
The context information structure is used to ensure that the derived The context information structure is used to ensure that the derived
keying material is "bound" to the context of the transaction. The keying material is "bound" to the context of the transaction. The
context information structure used here is based on that defined in context information structure used here is based on that defined in
[SP800-56A]. By using CBOR for the encoding of the context [SP800-56A]. By using CBOR for the encoding of the context
information structure, we automatically get the same type of type and information structure, we automatically get the same type of type and
length separation of fields that is obtained by the use of ASN.1. length separation of fields that is obtained by the use of ASN.1.
This means that there is no need to encode the lengths for the base This means that there is no need to encode the lengths for the base
elements as it is done by the CBOR encoding. elements as it is done by the JOSE encoding. [CREF11]
The context information structure refers to PartyU and PartyV as the The context information structure refers to PartyU and PartyV as the
two parties which are doing the key derivation. Unless the two parties which are doing the key derivation. Unless the
application protocol defines differently, we assign PartyU to the application protocol defines differently, we assign PartyU to the
entity that is creating the message and PartyV to the entity that is entity that is creating the message and PartyV to the entity that is
receiving the message. This is because we are assuming a set of receiving the message. By doing this association, different keys
standalone store and forward messaging processes. In [SP800-56A], will be derived for each direction as the context information is
PartyU is the initiator and PartyV is the responder. The different in each direction.
specification is written with the idea of on-line protocols rather
than store and forward protocols as the main consumer.
Application protocols are free to define the roles differently. For Application protocols are free to define the roles differently. For
example, they could assign the PartyU role to the entity that example, they could assign the PartyU role to the entity that
initiates the connection and allow directly sending multiple messages initiates the connection and allow directly sending multiple messages
over the connection in both directions without changing the role over the connection in both directions without changing the role
information. information.
Using the PartyU and PartyV fields is the easiest way to get The use of a transaction identifier, either in one of the
different keys in each direction. The use of a transaction supplemental fields or as the salt if one is using HKDF, ensures that
identifier, either in one of the supplemental fields or as the salt a unique key is generated for each set of transactions. Combining
if one is using HKDF, ensures that a unique key is generated for each nonce fields with the transaction identifier provides a method so
set of transactions. Combining nonce fields with the transaction that a different key is used for each message in each direction.
identifier provides a method so that a different key is used for each
message in each direction. The context structure is built from information that is known to both
entities. Some of the information is known only to the two entities,
some is implied based on the application and some is explicitly
transported as part of the message. The information that can be
carried in the message, parameters have been defined and can be found
in Table 13. These parameters are designed to be placed in the
unprotected bucket of the recipient structure. (They do not need to
be in the protected bucket since they already are included in the
cryptographic computation by virtue of being included in the context
structure.)
We encode the context specific information using a CBOR array type. We encode the context specific information using a CBOR array type.
For the fields that we define an algorithm parameter, the details of The fields in the array are:
the parameters can be found in Table 13. The fields in the array
are:
AlgorithmID This field indicates the algorithm for which the key AlgorithmID This field indicates the algorithm for which the key
material will be used. This field is required to be present and material will be used. This field is required to be present and
is a copy of the algorithm identifier in the message. The field is a copy of the algorithm identifier in the message. The field
exists in the context information so that if the same environment exists in the context information so that if the same environment
is used for different algorithms, then completely different keys is used for different algorithms, then completely different keys
will be generated each of those algorithms. (This practice means will be generated each of those algorithms. (This practice means
if algorithm A is broken and thus can is easier to find, the key if algorithm A is broken and thus can is easier to find, the key
derived for algorithm B will not be the same as the key for derived for algorithm B will not be the same as the key for
algorithm B.) algorithm B.)
PartyUInfo This field holds information about party U. The PartyUInfo This field holds information about party U. The
ParytUInfo structure is divided into three pieces: PartyUInfo is encoded as a CBOR struture. The elements of
PartyUInfo are encoded in the order presented, however if the
element does not exist no element is placed in the array. The
elements of the PartyUInfo array are:
identity This contains the identity information for party U. The identity This contains the identity information for party U. The
identities can be assigned in one of two manners. Firstly, a identities can be assigned in one of two manners. Firstly, a
protocol can assign identities based on roles. For example, protocol can assign identities based on roles. For example,
the roles of "client" and "server" may be assigned to different the roles of "client" and "server" may be assigned to different
entities in the protocol. Each entity would then use the entities in the protocol. Each entity would then use the
correct label for the data they they send or receive. The correct label for the data they they send or receive. The
second way is for a protocol to assign identities is to use a second way is for a protocol to assign identities is to use a
name based on a naming system (i.e. DNS, X.509 names). name based on a naming system (i.e. DNS, X.509 names).
We define an algorithm parameter 'PartyU identity' that can be We define an algorithm parameter 'PartyU identity' that can be
used to carry identity information in the message. However, used to carry identity information in the message. However,
identity information is often known as part of the protocol and identity information is often known as part of the protocol and
can thus be inferred rather than made explicit. If identity can thus be inferred rather than made explicit. If identity
information is carried in the message, applications SHOULD have information is carried in the message, applications SHOULD have
a way of validating the supplied identity information. The a way of validating the supplied identity information. The
identity information does not need to be specified and can be identity information does not need to be specified and can be
left as absent. left as absent.
The identity value supplied will be integrity checked as part The identity value supplied will be integrity checked as part
of the key derivation process. If the identity string is of the key derivation process. If the identity string is
wrong, then the wrong key will be created. wrong, then the wrong key will be created.
nonce This contains a one time nonce value. The nonce can either nonce This contains a one time nonce value. The nonce can either
be implicit from the protocol or carried as a value in the be implicit from the protocol or carried as a value in the
unprotected headers. unprotected headers.
We define an algorithm parameter 'PartyU nonce' that can be We define an algorithm parameter 'PartyU nonce' that can be
used to carry this value in the message However, the nonce used to carry this value in the message However, the nonce
value could be determined by the application and the value value could be determined by the application and the value
skipping to change at page 41, line 5 skipping to change at page 45, line 12
SHOULD use CBOR to encode the data so that types and lengths SHOULD use CBOR to encode the data so that types and lengths
are correctly include. are correctly include.
SuppPrivInfo This field contains private information that is SuppPrivInfo This field contains private information that is
mutually known information. An example of this information would mutually known information. An example of this information would
be a pre-existing shared secret. The field is optional and will be a pre-existing shared secret. The field is optional and will
only be present if the application defines a structure for this only be present if the application defines a structure for this
information. Applications that define this SHOULD use CBOR to information. Applications that define this SHOULD use CBOR to
encode the data so that types and lengths are correctly include. encode the data so that types and lengths are correctly include.
COSE_KDF_Context = [
AlgorithmID : int / tstr,
PartyUInfo : [
? nonce : bstr / int,
? identity : bstr,
? other : bstr
],
PartyVInfo : [
? nonce : bstr,
? identity : bstr / tstr,
? other : bstr
],
SuppPubInfo : [
keyDataLength : uint,
protected : bstr,
? other : bstr
],
? SuppPrivInfo : bstr
]
+---------------+-------+-----------+-------------------------------+ +---------------+-------+-----------+-------------------------------+
| name | label | type | description | | name | label | type | description |
+---------------+-------+-----------+-------------------------------+ +---------------+-------+-----------+-------------------------------+
| PartyU | -21 | bstr | Party U identity Information | | PartyU | -21 | bstr | Party U identity Information |
| identity | | | | | identity | | | |
| | | | | | | | | |
| PartyU nonce | -22 | bstr / | Party U provided nonce | | PartyU nonce | -22 | bstr / | Party U provided nonce |
| | | int | | | | | int | |
| | | | | | | | | |
| PartyU other | -23 | bstr | Party U other provided | | PartyU other | -23 | bstr | Party U other provided |
skipping to change at page 42, line 5 skipping to change at page 45, line 36
| | | | | | | | | |
| PartyV nonce | -25 | bstr / | Party V provided nonce | | PartyV nonce | -25 | bstr / | Party V provided nonce |
| | | int | | | | | int | |
| | | | | | | | | |
| PartyV other | -26 | bstr | Party V other provided | | PartyV other | -26 | bstr | Party V other provided |
| | | | information | | | | | information |
+---------------+-------+-----------+-------------------------------+ +---------------+-------+-----------+-------------------------------+
Table 13: Context Algorithm Parameters Table 13: Context Algorithm Parameters
Text from here to start of next section to be removed
COSE_KDF_Context = [
AlgorithmID : int / tstr,
PartyUInfo : [
? nonce : bstr / int,
? identity : bstr,
? other : bstr
],
PartyVInfo : [
? nonce : bstr,
? identity : bstr / tstr,
? other : bstr
],
SuppPubInfo : [
keyDataLength : uint,
protected : bstr,
? other : bstr
],
? SuppPrivInfo : bstr
]
12. Recipient Algorithm Classes 12. Recipient Algorithm Classes
Recipient algorithms can be defined into a number of different Recipient algorithms can be defined into a number of different
classes. COSE has the ability to support many classes of recipient classes. COSE has the ability to support many classes of recipient
algorithms. In this section, a number of classes are listed and then algorithms. In this section, a number of classes are listed and then
a set of algorithms are specified for each of the classes. The names a set of algorithms are specified for each of the classes. The names
of the recipient algorithm classes used here are the same as are of the recipient algorithm classes used here are the same as are
defined in [RFC7517]. Other specifications use different terms for defined in [RFC7517]. Other specifications use different terms for
the recipient algorithm classes or do not support some of our the recipient algorithm classes or do not support some of our
recipient algorithm classes. recipient algorithm classes.
skipping to change at page 42, line 44 skipping to change at page 47, line 15
o The 'recipients' field MUST be absent. o The 'recipients' field MUST be absent.
12.1.1. Direct Key 12.1.1. Direct Key
This recipient algorithm is the simplest, the supplied key is This recipient algorithm is the simplest, the supplied key is
directly used as the key for the next layer down in the message. directly used as the key for the next layer down in the message.
There are no algorithm parameters defined for this algorithm. The There are no algorithm parameters defined for this algorithm. The
algorithm identifier value is assigned in Table 14. algorithm identifier value is assigned in Table 14.
When this algorithm is used, the protected field MUST be zero length. When this algorithm is used, the protected field MUST be zero length.
The key type MUST be 'Symmetric'.
+--------+-------+-------------------+ +--------+-------+-------------------+
| name | value | description | | name | value | description |
+--------+-------+-------------------+ +--------+-------+-------------------+
| direct | -6 | Direct use of CEK | | direct | -6 | Direct use of CEK |
+--------+-------+-------------------+ +--------+-------+-------------------+
Table 14: Direct Key Table 14: Direct Key
12.1.1.1. Security Considerations 12.1.1.1. Security Considerations
skipping to change at page 43, line 50 skipping to change at page 48, line 21
If the salt/nonce value is generated deterministically, it can be If the salt/nonce value is generated deterministically, it can be
guaranteed to be unique and thus there is no length requirement. guaranteed to be unique and thus there is no length requirement.
A new IV must be used if the same key is used in more than one A new IV must be used if the same key is used in more than one
message. The IV can be modified in a predictable manner, a random message. The IV can be modified in a predictable manner, a random
manner or an unpredictable manner. One unpredictable manner that can manner or an unpredictable manner. One unpredictable manner that can
be used is to use the HKDF function to generate the IV. If HKDF is be used is to use the HKDF function to generate the IV. If HKDF is
used for generating the IV, the algorithm identifier is set to "IV- used for generating the IV, the algorithm identifier is set to "IV-
GENERATION". GENERATION".
When these algorithms are used, the key type MUST be 'symmetric'.
The set of algorithms defined in this document can be found in The set of algorithms defined in this document can be found in
Table 15. Table 15.
+---------------------+-------+-------------+-----------------------+ +---------------------+-------+-------------+-----------------------+
| name | value | KDF | description | | name | value | KDF | description |
+---------------------+-------+-------------+-----------------------+ +---------------------+-------+-------------+-----------------------+
| direct+HKDF-SHA-256 | * | HKDF | Shared secret w/ HKDF | | direct+HKDF-SHA-256 | * | HKDF | Shared secret w/ HKDF |
| | | SHA-256 | and SHA-256 | | | | SHA-256 | and SHA-256 |
| | | | | | | | | |
| direct+HKDF-SHA-512 | * | HKDF | Shared secret w/ HKDF | | direct+HKDF-SHA-512 | * | HKDF | Shared secret w/ HKDF |
skipping to change at page 45, line 19 skipping to change at page 49, line 44
12.2.1. AES Key Wrapping 12.2.1. AES Key Wrapping
The AES Key Wrapping algorithm is defined in [RFC3394]. This The AES Key Wrapping algorithm is defined in [RFC3394]. This
algorithm uses an AES key to wrap a value that is a multiple of algorithm uses an AES key to wrap a value that is a multiple of
64-bits, as such it can be used to wrap a key for any of the content 64-bits, as such it can be used to wrap a key for any of the content
encryption algorithms defined in this document. The algorithm encryption algorithms defined in this document. The algorithm
requires a single fixed parameter, the initial value. This is fixed requires a single fixed parameter, the initial value. This is fixed
to the value specified in Section 2.2.3.1 of [RFC3394]. There are no to the value specified in Section 2.2.3.1 of [RFC3394]. There are no
public parameters that vary on a per invocation basis. public parameters that vary on a per invocation basis.
Keys may be obtained either from a key structure or from a recipient
structure. If the key obtained from a key structure, the key type
MUST be 'Symmetric'. Implementations creating and validating MAC
values MUST validate that the key type, key length and algorithm are
correct and appropriate for the entities involved.
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
| name | value | key size | description | | name | value | key size | description |
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
| A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key | | A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key |
| | | | | | | | | |
| A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key | | A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key |
| | | | | | | | | |
| A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key | | A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key |
+--------+-------+----------+-----------------------------+ +--------+-------+----------+-----------------------------+
skipping to change at page 46, line 34 skipping to change at page 51, line 19
+----------------------+-------+---------+-----------------------+ +----------------------+-------+---------+-----------------------+
| name | value | hash | description | | name | value | hash | description |
+----------------------+-------+---------+-----------------------+ +----------------------+-------+---------+-----------------------+
| RSAES-OAEP w/SHA-256 | -25 | SHA-256 | RSAES OAEP w/ SHA-256 | | RSAES-OAEP w/SHA-256 | -25 | SHA-256 | RSAES OAEP w/ SHA-256 |
| | | | | | | | | |
| RSAES-OAEP w/SHA-512 | -26 | SHA-512 | RSAES OAEP w/ SHA-512 | | RSAES-OAEP w/SHA-512 | -26 | SHA-512 | RSAES OAEP w/ SHA-512 |
+----------------------+-------+---------+-----------------------+ +----------------------+-------+---------+-----------------------+
Table 17: RSAES-OAEP Algorithm Values Table 17: RSAES-OAEP Algorithm Values
The key type MUST be 'RSA'.
12.3.1.1. Security Considerations for RSAES-OAEP 12.3.1.1. Security Considerations for RSAES-OAEP
A key size of 2048 bits or larger MUST be used with these algorithms. A key size of 2048 bits or larger MUST be used with these algorithms.
This key size corresponds roughly to the same strength as provided by This key size corresponds roughly to the same strength as provided by
a 128-bit symmetric encryption algorithm. a 128-bit symmetric encryption algorithm.
It is highly recommended that checks on the key length be done before It is highly recommended that checks on the key length be done before
starting a decryption operation. One potential denial of service starting a decryption operation. One potential denial of service
operation is to provide encrypted objects using either abnormally operation is to provide encrypted objects using either abnormally
long or oddly sized RSA modulus values. Implementations SHOULD be long or oddly sized RSA modulus values. Implementations SHOULD be
skipping to change at page 47, line 4 skipping to change at page 51, line 40
long or oddly sized RSA modulus values. Implementations SHOULD be long or oddly sized RSA modulus values. Implementations SHOULD be
able to encrypt and decrypt with modulus between 2048 and 16K bits in able to encrypt and decrypt with modulus between 2048 and 16K bits in
length. Applications can impose additional restrictions on the length. Applications can impose additional restrictions on the
length of the modulus. length of the modulus.
12.4. Direct Key Agreement 12.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 A). other purposes if more than two layers are in use (see Appendix B).
The most commonly used key agreement algorithm used is Diffie- The most commonly used key agreement algorithm used is Diffie-
Hellman, but other variants exist. Since COSE is designed for a Hellman, but other variants exist. Since COSE is designed for a
store and forward environment rather than an on-line environment, store and forward environment rather than an on-line environment,
many of the DH variants cannot be used as the receiver of the message many of the DH variants cannot be used as the receiver of the message
cannot provide any key material. One side-effect of this is that cannot provide any key material. One side-effect of this is that
perfect forward security is not achievable, a static key will always perfect forward security is not achievable, a static key will always
be used for the receiver of the COSE message. be used for the receiver of the COSE message.
Two variants of DH that are easily supported are: Two variants of DH that are easily supported are:
skipping to change at page 51, line 21 skipping to change at page 55, line 42
| static | -2 | COSE_Key | ECDH-ES | Static Public key for | | static | -2 | COSE_Key | ECDH-ES | Static Public key for |
| key | | | | the sender | | key | | | | the sender |
| | | | | | | | | | | |
| static | -3 | bstr | ECDH-SS | Static Public key | | static | -3 | bstr | ECDH-SS | Static Public key |
| key id | | | | identifier for the | | key id | | | | identifier for the |
| | | | | sender | | | | | | sender |
+-----------+-------+----------+-----------+------------------------+ +-----------+-------+----------+-----------+------------------------+
Table 19: ECDH Algorithm Parameters Table 19: ECDH Algorithm Parameters
This document defines these algorithms to be used with the curves
P-256, P-384, P-521, X25519 and X448. Implementations MUST verify
that the key type and curve are correct, different curves are
restricted to different key types. Implementations MUST verify that
the curve and algorithm are appropriate for the entities involved.
12.5. Key Agreement with KDF 12.5. Key Agreement with KDF
Key Agreement with Key Wrapping uses a randomly generated CEK. The Key Agreement with Key Wrapping uses a randomly generated CEK. The
CEK is then encrypted using a Key Wrapping algorithm and a key CEK is then encrypted using a Key Wrapping algorithm and a key
derived from the shared secret computed by the key agreement derived from the shared secret computed by the key agreement
algorithm. algorithm.
The COSE_encrypt structure for the recipient is organized as follows: The COSE_encrypt structure for the recipient is organized as follows:
o The 'protected' field is fed into the KDF context structure. o The 'protected' field is fed into the KDF context structure.
skipping to change at page 52, line 40 skipping to change at page 57, line 29
Table 20: Key Type Values Table 20: Key Type Values
13.1. Elliptic Curve Keys 13.1. Elliptic Curve Keys
Two different key structures are being defined for Elliptic Curve Two different key structures are being defined for Elliptic Curve
keys. One version uses both an x and a y coordinate, potentially keys. One version uses both an x and a y coordinate, potentially
with point compression. This is the traditional EC point with point compression. This is the traditional EC point
representation that is used in [RFC5480]. The other version uses representation that is used in [RFC5480]. The other version uses
only the x coordinate as the y coordinate is either to be recomputed only the x coordinate as the y coordinate is either to be recomputed
or not needed for the key agreement operation. An example of this is or not needed for the key agreement operation. An example of this is
Curve25519 [I-D.irtf-cfrg-curves]. Curve25519 [I-D.irtf-cfrg-curves]. [CREF12]
+------------+----------+-------+-----------------------------------+ +------------+----------+-------+-----------------------------------+
| name | key type | value | description | | name | key type | value | description |
+------------+----------+-------+-----------------------------------+ +------------+----------+-------+-----------------------------------+
| P-256 | EC2 | 1 | NIST P-256 also known as | | P-256 | EC2 | 1 | NIST P-256 also known as |
| | | | secp256r1 | | | | | secp256r1 |
| | | | | | | | | |
| P-384 | EC2 | 2 | NIST P-384 also known as | | P-384 | EC2 | 2 | NIST P-384 also known as |
| | | | secp384r1 | | | | | secp384r1 |
| | | | | | | | | |
skipping to change at page 53, line 37 skipping to change at page 58, line 18
completely defined using the curve and the x coordinate of the point completely defined using the curve and the x coordinate of the point
on the curve. The two curves that are initially setup to use is on the curve. The two curves that are initially setup to use is
point format are Curve 25519 and Curve 448 which are defined in point format are Curve 25519 and Curve 448 which are defined in
[I-D.irtf-cfrg-curves]. [I-D.irtf-cfrg-curves].
For EC keys with only the x coordinates, the 'kty' member is set to 1 For EC keys with only the x coordinates, the 'kty' member is set to 1
(EC1). The key parameters defined in this section are summarized in (EC1). The key parameters defined in this section are summarized in
Table 22. The members that are defined for this key type are: Table 22. The members that are defined for this key type are:
crv contains an identifier of the curve to be used with the key. crv contains an identifier of the curve to be used with the key.
[CREF10] The curves defined in this document for this key type can [CREF13] The curves defined in this document for this key type can
be found in Table 21. Other curves may be registered in the be found in Table 21. Other curves may be registered in the
future and private curves can be used as well. future and private curves can be used as well.
x contains the x coordinate for the EC point. The octet string x contains the x coordinate for the EC point. The octet string
represents a little-endian encoding of x. represents a little-endian encoding of x.
d contains the private key. d contains the private key.
For public keys, it is REQUIRED that 'crv' and 'x' be present in the For public keys, it is REQUIRED that 'crv' and 'x' be present in the
structure. For private keys, it is REQUIRED that 'crv' and 'd' be structure. For private keys, it is REQUIRED that 'crv' and 'd' be
skipping to change at page 54, line 39 skipping to change at page 59, line 18
(EC2). The key parameters defined in this section are summarized in (EC2). The key parameters defined in this section are summarized in
Table 23. The members that are defined for this key type are: Table 23. The members that are defined for this key type are:
crv contains an identifier of the curve to be used with the key. crv contains an identifier of the curve to be used with the key.
The curves defined in this document for this key type can be found The curves defined in this document for this key type can be found
in Table 21. Other curves may be registered in the future and in Table 21. Other curves may be registered in the future and
private curves can be used as well. private curves can be used as well.
x contains the x coordinate for the EC point. The integer is x contains the x coordinate for the EC point. The integer is
converted to an octet string as defined in [SEC1]. Zero octets converted to an octet string as defined in [SEC1]. Zero octets
MUST NOT be removed from the front of the octet string. [CREF11] MUST NOT be removed from the front of the octet string. [CREF14]
y contains either the sign bit or the value of y coordinate for the y contains either the sign bit or the value of y coordinate for the
EC point. For the value, the integer is converted to an octet EC point. For the value, the integer is converted to an octet
string as defined in [SEC1]. Zero octets MUST NOT be removed from string as defined in [SEC1]. Zero octets MUST NOT be removed from
the front of the octet string. For the sign bit, the value is the front of the octet string. For the sign bit, the value is
true if the value of y is positive. true if the value of y is positive.
d contains the private key. d contains the private key.
For public keys, it is REQUIRED that 'crv', 'x' and 'y' be present in For public keys, it is REQUIRED that 'crv', 'x' and 'y' be present in
skipping to change at page 55, line 28 skipping to change at page 60, line 9
| | | | | | | | | | | |
| d | 2 | -4 | bstr | Private key | | d | 2 | -4 | bstr | Private key |
+------+-------+-------+---------+----------------------------------+ +------+-------+-------+---------+----------------------------------+
Table 23: EC Key Parameters Table 23: EC Key Parameters
13.2. RSA Keys 13.2. RSA Keys
This document defines a key structure for both the public and private This document defines a key structure for both the public and private
halves of RSA keys. Together, an RSA public key and an RSA private halves of RSA keys. Together, an RSA public key and an RSA private
key form an RSA key pair. [CREF12] key form an RSA key pair. [CREF15]
The document also provides support for the so-called "multi-prime" The document also provides support for the so-called "multi-prime"
RSA where the modulus may have more than two prime factors. The RSA where the modulus may have more than two prime factors. The
benefit of multi-prime RSA is lower computational cost for the benefit of multi-prime RSA is lower computational cost for the
decryption and signature primitives. For a discussion on how multi- decryption and signature primitives. For a discussion on how multi-
prime affects the security of RSA crypto-systems, the reader is prime affects the security of RSA crypto-systems, the reader is
referred to [MultiPrimeRSA]. referred to [MultiPrimeRSA].
This document follows the naming convention of [RFC3447] for the This document follows the naming convention of [RFC3447] for the
naming of the fields of an RSA public or private key. The table naming of the fields of an RSA public or private key. The table
skipping to change at page 62, line 22 skipping to change at page 67, line 10
This registry will be initially populated by the values in Table 20. This registry will be initially populated by the values in Table 20.
The specification column for all of these entries will be this The specification column for all of these entries will be this
document. document.
15.8. Media Type Registration 15.8. Media Type Registration
15.8.1. COSE Security Message 15.8.1. COSE Security Message
This section registers the "application/cose" and "application/ This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry. [CREF13] These cose+cbor" media types in the "Media Types" registry. [CREF16] These
media types are used to indicate that the content is a COSE_MSG. media types are used to indicate that the content is a COSE_MSG.
Type name: application Type name: application
Subtype name: cose Subtype name: cose
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
skipping to change at page 66, line 22 skipping to change at page 71, line 15
out who sent the message out who sent the message
3. Use of direct key with other recipient structures hands the key 3. Use of direct key with other recipient structures hands the key
to other recipients. to other recipients.
4. Use of direct ECDH direct encryption is easy for people to leak 4. Use of direct ECDH direct encryption is easy for people to leak
information on if there are other recipients in the message. information on if there are other recipients in the message.
5. Considerations about protected vs unprotected header fields. 5. Considerations about protected vs unprotected header fields.
6. Need to verify that: 1) the kty field of the key matches the key
and algorithm being used. 2) that the kty field needs to be
included in the trust decision as well as the other key fields.
3) that the algorithm be included in the trust decision.
17. References 17. References
17.1. Normative References 17.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, October 2013. Representation (CBOR)", RFC 7049, October 2013.
skipping to change at page 67, line 5 skipping to change at page 71, line 49
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Vigano, C., Birkholz, H., and R. Sun, "CBOR data Vigano, C., Birkholz, H., and R. Sun, "CBOR data
definition language: a notational convention to express definition language: a notational convention to express
CBOR data structures.", draft-greevenbosch-appsawg-cbor- CBOR data structures.", draft-greevenbosch-appsawg-cbor-
cddl-05 (work in progress), March 2015. cddl-05 (work in progress), March 2015.
[I-D.irtf-cfrg-curves] [I-D.irtf-cfrg-curves]
Langley, A. and R. Salz, "Elliptic Curves for Security", Langley, A. and R. Salz, "Elliptic Curves for Security",
draft-irtf-cfrg-curves-02 (work in progress), March 2015. draft-irtf-cfrg-curves-02 (work in progress), March 2015.
[I-D.mcgrew-aead-aes-cbc-hmac-sha2]
McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead-
aes-cbc-hmac-sha2-05 (work in progress), July 2014.
[MAC] NiST, N., "FIPS PUB 113: Computer Data Authentication", [MAC] NiST, N., "FIPS PUB 113: Computer Data Authentication",
May 1985. May 1985.
[MultiPrimeRSA] [MultiPrimeRSA]
Hinek, M. and D. Cheriton, "On the Security of Multi-prime Hinek, M. and D. Cheriton, "On the Security of Multi-prime
RSA", June 2006. RSA", June 2006.
[PVSig] Brown, D. and D. Johnson, "Formal Security Proofs for a [PVSig] Brown, D. and D. Johnson, "Formal Security Proofs for a
Signature Scheme with Partial Message Recover", February Signature Scheme with Partial Message Recover", February
2000. 2000.
skipping to change at page 69, line 23 skipping to change at page 74, line 14
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: [SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", May 2009. Elliptic Curve Cryptography", May 2009.
[SP800-56A] [SP800-56A]
Barker, E., Chen, L., Roginsky, A., and M. Smid, "NIST Barker, E., Chen, L., Roginsky, A., and M. Smid, "NIST
Special Publication 800-56A: Recommendation for Pair-Wise Special Publication 800-56A: Recommendation for Pair-Wise
Key Establishment Schemes Using Discrete Logarithm Key Establishment Schemes Using Discrete Logarithm
Cryptography", May 2013. Cryptography", May 2013.
Appendix A. Three Levels of Recipient Information Appendix A. CDDL Grammar
For people who prefer using a formal language to describe the syntax
of the CBOR, in this section a CDDL grammar is given that corresponds
to [I-D.greevenbosch-appsawg-cbor-cddl]. This grammar is
informational, in the event of differences between this grammar and
the prose, the prose is considered to be authorative.
The collected CDDL can be extracted from the XML version of this
document via the following XPath expression below. (Depending on the
XPath evaluator one is using, it may be necessary to deal with >
as an entity.)
//artwork[@type='CDDL']/text()
Appendix B. Three Levels of Recipient Information
All of the currently defined recipient algorithms classes only use All of the currently defined recipient algorithms classes only use
two levels of the COSE_Encrypt structure. The first level is the two levels of the COSE_Encrypt structure. The first level is the
message content and the second level is the content key encryption. message content and the second level is the content key encryption.
However, if one uses a recipient algorithm such as RSA-KEM (see However, if one uses a recipient algorithm such as RSA-KEM (see
Appendix A of RSA-KEM [RFC5990], then it make sense to have three Appendix A of RSA-KEM [RFC5990], then it make sense to have three
levels of the COSE_Encrypt structure. levels of the COSE_Encrypt structure.
These levels would be: These levels would be:
skipping to change at page 70, line 48 skipping to change at page 76, line 5
31ef6019c0c56d33de0' 31ef6019c0c56d33de0'
} }
}, },
h'' h''
] ]
] ]
] ]
] ]
] ]
Appendix B. Examples Appendix C. Examples
The examples can be found at https://github.com/cose-wg/Examples. The examples can be found at https://github.com/cose-wg/Examples.
The file names in each section correspond the the same file names in The file names in each section correspond the the same file names in
the repository. I am currently still in the process of getting the the repository. I am currently still in the process of getting the
examples up there along with some control information for people to examples up there along with some control information for people to
be able to check and reproduce the examples. be able to check and reproduce the examples.
Examples may have some features that are in questions but not yet Examples may have some features that are in questions but not yet
incorporated in the document. incorporated in the document.
skipping to change at page 71, line 26 skipping to change at page 76, line 32
The diagnostic notation can be converted into binary files using the The diagnostic notation can be converted into binary files using the
following command line: following command line:
diag2cbor < inputfile > outputfile diag2cbor < inputfile > outputfile
The examples can be extracted from the XML version of this docuent The examples can be extracted from the XML version of this docuent
via an XPath expression as all of the artwork is tagged with the via an XPath expression as all of the artwork is tagged with the
attribute type='CBORdiag'. attribute type='CBORdiag'.
B.1. Examples of MAC messages C.1. Examples of MAC messages
B.1.1. Shared Secret Direct MAC C.1.1. Shared Secret Direct MAC
This example users the following: This example users the following:
o MAC: AES-CMAC, 256-bit key, trucated to 64 bits o MAC: AES-CMAC, 256-bit key, trucated to 64 bits
o Recipient class: direct shared secret o Recipient class: direct shared secret
o File name: Mac-04 o File name: Mac-04
Size of binary file is 71 bytes Size of binary file is 71 bytes
skipping to change at page 72, line 24 skipping to change at page 77, line 24
h'', h'',
{ {
1: -6, 1: -6,
4: h'6f75722d736563726574' 4: h'6f75722d736563726574'
}, },
h'' h''
] ]
] ]
] ]
B.1.2. ECDH Direct MAC C.1.2. ECDH Direct MAC
This example uses the following: This example uses the following:
o MAC: HMAC w/SHA-256, 256-bit key o MAC: HMAC w/SHA-256, 256-bit key
o Recipient class: ECDH key agreement, two static keys, HKDF w/ o Recipient class: ECDH key agreement, two static keys, HKDF w/
context structure context structure
Size of binary file is 215 bytes Size of binary file is 215 bytes
skipping to change at page 73, line 31 skipping to change at page 78, line 31
e6578616d706c65', e6578616d706c65',
"apu": h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d19558ccf "apu": h'4d8553e7e74f3c6a3a9dd3ef286a8195cbf8a23d19558ccf
ec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a58368b01 ec7d34b824f42d92bd06bd2c7f0271f0214e141fb779ae2856abf585a58368b01
7e7f2a9e5ce4db5' 7e7f2a9e5ce4db5'
}, },
h'' h''
] ]
] ]
] ]
B.1.3. Wrapped MAC C.1.3. Wrapped MAC
This example uses the following: This example uses the following:
o MAC: AES-MAC, 128-bit key, truncated to 64 bits o MAC: AES-MAC, 128-bit key, truncated to 64 bits
o Recipient class: AES keywrap w/ a pre-shared 256-bit key o Recipient class: AES keywrap w/ a pre-shared 256-bit key
Size of binary file is 122 bytes Size of binary file is 122 bytes
[ [
skipping to change at page 74, line 25 skipping to change at page 79, line 25
{ {
1: -5, 1: -5,
4: h'30313863306165352d346439622d343731622d626664362d6565 4: h'30313863306165352d346439622d343731622d626664362d6565
66333134626337303337' 66333134626337303337'
}, },
h'711ab0dc2fc4585dce27effa6781c8093eba906f227b6eb0' h'711ab0dc2fc4585dce27effa6781c8093eba906f227b6eb0'
] ]
] ]
] ]
B.1.4. Multi-recipient MAC message C.1.4. Multi-recipient MAC message
This example uses the following: This example uses the following:
o MAC: HMAC w/ SHA-256, 128-bit key o MAC: HMAC w/ SHA-256, 128-bit key
o Recipient class: Uses three different methods o Recipient class: Uses three different methods
1. ECDH Ephemeral-Static, Curve P-521, AES-Key Wrap w/ 128-bit 1. ECDH Ephemeral-Static, Curve P-521, AES-Key Wrap w/ 128-bit
key key
skipping to change at page 76, line 5 skipping to change at page 81, line 5
1: -5, 1: -5,
4: h'30313863306165352d346439622d343731622d626664362d6565 4: h'30313863306165352d346439622d343731622d626664362d6565
66333134626337303337' 66333134626337303337'
}, },
h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a518e7736549e99 h'0b2c7cfce04e98276342d6476a7723c090dfdd15f9a518e7736549e99
8370695e6d6a83b4ae507bb' 8370695e6d6a83b4ae507bb'
] ]
] ]
] ]
B.2. Examples of Encrypted Messages C.2. Examples of Encrypted Messages
B.2.1. Direct ECDH C.2.1. Direct ECDH
This example uses the following: This example uses the following:
o CEK: AES-GCM w/ 128-bit key o CEK: AES-GCM w/ 128-bit key
o Recipient class: ECDH Ephemeral-Static, Curve P-256 o Recipient class: ECDH Ephemeral-Static, Curve P-256
Size of binary file is 182 bytes Size of binary file is 182 bytes
[ [
skipping to change at page 76, line 46 skipping to change at page 81, line 46
4e1c7b4d91d6280', 4e1c7b4d91d6280',
-3: h'f01400b089867804b8e9fc96c3932161f1934f4223069170d -3: h'f01400b089867804b8e9fc96c3932161f1934f4223069170d
924b7e03bf822bb' 924b7e03bf822bb'
} }
}, },
h'' h''
] ]
] ]
] ]
B.2.2. Direct plus Key Derivation C.2.2. Direct plus Key Derivation
This example uses the following: This example uses the following:
o CEK: AES-CCM w/128-bit key, trucate the tag to 64-bits o CEK: AES-CCM w/128-bit key, trucate the tag to 64-bits
o Recipient class: Use HKDF on a shared secret with the following o Recipient class: Use HKDF on a shared secret with the following
implicit fields as part of the context. implicit fields as part of the context.
* APU identity: "lighting-client" * APU identity: "lighting-client"
* APV identity: "lighting-server" * APV identity: "lighting-server"
skipping to change at page 77, line 35 skipping to change at page 82, line 35
{ {
1: "dir+kdf", 1: "dir+kdf",
4: h'6f75722d736563726574', 4: h'6f75722d736563726574',
-20: h'61616262636364646565666667676868' -20: h'61616262636364646565666667676868'
}, },
h'' h''
] ]
] ]
] ]
B.3. Examples of Signed Message C.3. Examples of Signed Message
B.3.1. Single Signature C.3.1. Single Signature
This example uses the following: This example uses the following:
o Signature Algorithm: RSA-PSS w/ SHA-384, MGF-1 o Signature Algorithm: RSA-PSS w/ SHA-384, MGF-1
Size of binary file is 330 bytes Size of binary file is 330 bytes
[ [
1, 1,
h'', h'',
skipping to change at page 78, line 30 skipping to change at page 83, line 30
3f9067891b17fe752674b80437da02e9928ab7a155fef707b11d2bd38a71f224f 3f9067891b17fe752674b80437da02e9928ab7a155fef707b11d2bd38a71f224f
53170480116d96cc3f7266487b268679a13cdedffa93252a550371acc19971369 53170480116d96cc3f7266487b268679a13cdedffa93252a550371acc19971369
b58039056b308cc4e158bebe7c55db7874442d4321fd27f17dbb820ef19f43dcc b58039056b308cc4e158bebe7c55db7874442d4321fd27f17dbb820ef19f43dcc
16cd50ccdd1b7dfd7cdde239a9245af41d949cdbbf1337ca254af20eeb167a62d 16cd50ccdd1b7dfd7cdde239a9245af41d949cdbbf1337ca254af20eeb167a62d
a5a51c83899c6f6e7c7e01dc3db21a250092a69fc635b74a2e54f5c98cb955d83 a5a51c83899c6f6e7c7e01dc3db21a250092a69fc635b74a2e54f5c98cb955d83
' '
] ]
] ]
] ]
B.3.2. Multiple Signers C.3.2. Multiple Signers
This example uses the following: This example uses the following:
o Signature Algorithm: RSA-PSS w/ SHA-256, MGF-1 o Signature Algorithm: RSA-PSS w/ SHA-256, MGF-1
o Signature Algorithm: ECDSA w/ SHA-512, Curve P-521 o Signature Algorithm: ECDSA w/ SHA-512, Curve P-521
Size of binary file is 496 bytes Size of binary file is 496 bytes
[ [
skipping to change at page 79, line 44 skipping to change at page 84, line 44
}, },
h'0118eaa7d62778b5a9525a583f06b115d80cd246bc930f0c2850588ee h'0118eaa7d62778b5a9525a583f06b115d80cd246bc930f0c2850588ee
c85186b427026e096a076bfab738215f354be59f57643a7f6b2c92535cf3c37ee c85186b427026e096a076bfab738215f354be59f57643a7f6b2c92535cf3c37ee
2746a908ab1dcc673a63f327d9eff852b874f7a98b6638c7054fdeeaa3dce6542 2746a908ab1dcc673a63f327d9eff852b874f7a98b6638c7054fdeeaa3dce6542
4a21bd5dc728acedda7fcae6df6fc3298ff51ac911603a0f26d066935dccb85ea 4a21bd5dc728acedda7fcae6df6fc3298ff51ac911603a0f26d066935dccb85ea
eb0ae6d0e6' eb0ae6d0e6'
] ]
] ]
] ]
B.4. COSE Keys C.4. COSE Keys
B.4.1. Public Keys C.4.1. Public Keys
This is an example of a COSE Key set. This example includes the This is an example of a COSE Key set. This example includes the
public keys for all of the previous examples. public keys for all of the previous examples.
In order the keys are: In order the keys are:
o An EC key with a kid of "meriadoc.brandybuck@buckland.example" o An EC key with a kid of "meriadoc.brandybuck@buckland.example"
o An EC key with a kid of "peregrin.took@tuckborough.example" o An EC key with a kid of "peregrin.took@tuckborough.example"
skipping to change at page 81, line 16 skipping to change at page 86, line 16
d937fad5535387e0ff72ffbe78941402b0b822ea2a74b6058c1dabf9b34a76cb6 d937fad5535387e0ff72ffbe78941402b0b822ea2a74b6058c1dabf9b34a76cb6
3b87faa2c6847b8e2837fff91186e6b1c14911cf989a89092a81ce601ddacd3f9 3b87faa2c6847b8e2837fff91186e6b1c14911cf989a89092a81ce601ddacd3f9
cf', cf',
-1: h'010001', -1: h'010001',
1: 3, 1: 3,
2: h'62696c626f2e62616767696e7340686f626269746f6e2e6578616d70 2: h'62696c626f2e62616767696e7340686f626269746f6e2e6578616d70
6c65' 6c65'
} }
] ]
B.4.2. Private Keys C.4.2. Private Keys
This is an example of a COSE Key set. This example includes the This is an example of a COSE Key set. This example includes the
private keys for all of the previous examples. private keys for all of the previous examples.
In order the keys are: In order the keys are:
o An EC key with a kid of "meriadoc.brandybuck@buckland.example" o An EC key with a kid of "meriadoc.brandybuck@buckland.example"
o A shared-secret key with a kid of "our-secret" o A shared-secret key with a kid of "our-secret"
skipping to change at page 83, line 46 skipping to change at page 88, line 46
03da5f63e7bcffb3c84903111b9ffabcb873f675d42abd02a0b6c9e2fa91d293d 03da5f63e7bcffb3c84903111b9ffabcb873f675d42abd02a0b6c9e2fa91d293d
5c605f', 5c605f',
-8: h'dcf8aabd740dd33c0c784fac06f6608b6f3d5cff57090177556a8fc -8: h'dcf8aabd740dd33c0c784fac06f6608b6f3d5cff57090177556a8fc
cc2a7220429eff4ee828ebe35904a090b0c7f71da1060634d526cfe370af3e4d1 cc2a7220429eff4ee828ebe35904a090b0c7f71da1060634d526cfe370af3e4d1
5ef68a7beed931a423f157c175892cb1bbb434a0c386327e1ad8ac79a0d55aded 5ef68a7beed931a423f157c175892cb1bbb434a0c386327e1ad8ac79a0d55aded
d707d1c7f0c601541e9421ec5a02ae3149ea1e99129305eb19ae8ece2a3293f3f d707d1c7f0c601541e9421ec5a02ae3149ea1e99129305eb19ae8ece2a3293f3f
1a688e' 1a688e'
} }
] ]
Appendix C. Document Updates Appendix D. Document Updates
C.1. Version -03 to -04 D.1. Version -04 to -05
o Removed the jku, x5c, x5t, x5t#S256, x5u, and jwk headers.
o Add enveloped data vs encrypted data structures.
o Add counter signature parameter.
D.2. Version -03 to -04
o Change top level from map to array. o Change top level from map to array.
o Eliminate the term "key managment" from the document. o Eliminate the term "key managment" from the document.
o Point to content registries for the 'content type' attribute o Point to content registries for the 'content type' attribute
o Push protected field into the KDF functions for recipients. o Push protected field into the KDF functions for recipients.
o Remove password based recipient information. o Remove password based recipient information.
o Create EC Curve Registry. o Create EC Curve Registry.
C.2. Version -02 to -03 D.3. Version -02 to -03
o Make a pass over all of the algorithm text. o Make a pass over all of the algorithm text.
o Alter the CDDL so that Keys and KeySets are top level items and o Alter the CDDL so that Keys and KeySets are top level items and
the key examples validate. the key examples validate.
o Add sample key structures. o Add sample key structures.
o Expand text on dealing with Externally Supplied Data. o Expand text on dealing with Externally Supplied Data.
o Update the examples to match some of the renumbering of fields. o Update the examples to match some of the renumbering of fields.
C.3. Version -02 to -03 D.4. Version -02 to -03
o Add a set of straw man proposals for algorithms. It is possible/ o Add a set of straw man proposals for algorithms. It is possible/
expected that this text will be moved to a new document. expected that this text will be moved to a new document.
o Add a set of straw man proposals for key structures. It is o Add a set of straw man proposals for key structures. It is
possible/expected that this text will be moved to a new document. possible/expected that this text will be moved to a new document.
o Provide guidance on use of externally supplied authenticated data. o Provide guidance on use of externally supplied authenticated data.
o Add external authenticated data to signing structure. o Add external authenticated data to signing structure.
C.4. Version -01 to -2 D.5. Version -01 to -2
o Add first pass of algorithm information o Add first pass of algorithm information
o Add direct key derivation example. o Add direct key derivation example.
C.5. Version -00 to -01 D.6. Version -00 to -01
o Add note on where the document is being maintained and o Add note on where the document is being maintained and
contributing notes. contributing notes.
o Put in proposal on MTI algorithms. o Put in proposal on MTI algorithms.
o Changed to use labels rather than keys when talking about what o Changed to use labels rather than keys when talking about what
indexes a map. indexes a map.
o Moved nonce/IV to be a common header item. o Moved nonce/IV to be a common header item.
skipping to change at page 86, line 5 skipping to change at page 91, line 10
appearing if used in a COSE_MSG rather than on the individual appearing if used in a COSE_MSG rather than on the individual
structure? This would make things shorter if one was using just structure? This would make things shorter if one was using just
a signed message because the msg_type field can be omitted as a signed message because the msg_type field can be omitted as
well as the COSE_Tagged_MSG tag field. One the other hand, it well as the COSE_Tagged_MSG tag field. One the other hand, it
will complicated the code if one is doing general purpose will complicated the code if one is doing general purpose
library type things. library type things.
[CREF6] JLS: Should we create an IANA registries for the values of [CREF6] JLS: Should we create an IANA registries for the values of
msg_type? msg_type?
[CREF7] JLS: A completest version of this grammar would list the options [CREF7] CB: I would like to make msg_type go away
[CREF8] JLS: A completest version of this grammar would list the options
available in the protected and unprotected headers. Do we want available in the protected and unprotected headers. Do we want
to head that direction? to head that direction?
[CREF8] JLS: Is there a reason to assign a CBOR tag to identify keys [CREF9] JLS: Is there a reason to assign a CBOR tag to identify keys
and/or key sets? and/or key sets?
[CREF9] JLS: We can really simplify the grammar for COSE_Key to be just [CREF10] JLS: We can really simplify the grammar for COSE_Key to be just
the kty (the one required field) and the generic item. The the kty (the one required field) and the generic item. The
reason to do this is that it makes things simpler. The reason reason to do this is that it makes things simpler. The reason
not to do this says that we really need to add a lot more items not to do this says that we really need to add a lot more items
so that a grammar check can be done that is more tightly so that a grammar check can be done that is more tightly
enforced. enforced.
[CREF10] JLS: Do we create a registry for curves? Is is the same [CREF11] Ilari: Look to see if we need to be clearer about how the
fields defined in the table are transported and thus why they
have labels.
[CREF12] Ilari: Check to see what the curves are renamed to during final
publishing. It appears to be X25519 now.
[CREF13] JLS: Do we create a registry for curves? Is is the same
registry for both EC1 and EC2? registry for both EC1 and EC2?
[CREF11] JLS: Should we use the bignum encoding for x, y and d instead [CREF14] JLS: Should we use the bignum encoding for x, y and d instead
of bstr? of bstr?
[CREF12] JLS: Looking at the CBOR specification, the bstr that we are [CREF15] JLS: Looking at the CBOR specification, the bstr that we are
looking in our table below should most likely be specified as looking in our table below should most likely be specified as
big numbers rather than as binary strings. This means that we big numbers rather than as binary strings. This means that we
would use the tag 6.2 instead. From my reading of the would use the tag 6.2 instead. From my reading of the
specification, there is no difference in the encoded size of specification, there is no difference in the encoded size of
the resulting output. The specification of bignum does the resulting output. The specification of bignum does
explicitly allow for integers encoded with leading zeros. explicitly allow for integers encoded with leading zeros.
[CREF13] JLS: Should we register both or just the cose+cbor one? [CREF16] JLS: Should we register both or just the cose+cbor one?
Authors' Addresses Authors' Addresses
Jim Schaad Jim Schaad
August Cellars August Cellars
Email: ietf@augustcellars.com Email: ietf@augustcellars.com
Brian Campbell Brian Campbell
Ping Identity Ping Identity
 End of changes. 123 change blocks. 
393 lines changed or deleted 637 lines changed or added

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