draft-ietf-cose-msg-17.txt   draft-ietf-cose-msg-18.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Intended status: Standards Track August 14, 2016 Intended status: Standards Track September 10, 2016
Expires: February 15, 2017 Expires: March 14, 2017
CBOR Object Signing and Encryption (COSE) CBOR Object Signing and Encryption (COSE)
draft-ietf-cose-msg-17 draft-ietf-cose-msg-18
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 basic security services defined for this data format.
format. This document defines the CBOR Object Signing and Encryption This document defines the CBOR Object Signing and Encryption (COSE)
(COSE) specification. This specification describes how to create and specification. This specification describes how to create and
process signature, message authentication codes and encryption using process signature, message authentication codes and encryption using
CBOR for serialization. This specification additionally specifies CBOR for serialization. This specification additionally specifies
how to represent cryptographic keys using CBOR. how to represent cryptographic keys using CBOR.
Contributing to this document Contributing to this document
The source for this draft is being maintained in GitHub. Suggested The source for this draft is being maintained in GitHub. Suggested
changes should be submitted as pull requests at <https://github.com/ changes should be submitted as pull requests at <https://github.com/
cose-wg/cose-spec>. Instructions are on that page as well. cose-wg/cose-spec>. Instructions are on that page as well.
Editorial changes can be managed in GitHub, but any substantial Editorial changes can be managed in GitHub, but any substantial
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 15, 2017. This Internet-Draft will expire on March 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 44 skipping to change at page 2, line 44
4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 19 4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 19
4.4. Signing and Verification Process . . . . . . . . . . . . 20 4.4. Signing and Verification Process . . . . . . . . . . . . 20
4.5. Computing Counter Signatures . . . . . . . . . . . . . . 21 4.5. Computing Counter Signatures . . . . . . . . . . . . . . 21
5. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 22 5. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 22
5.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 22 5.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 22
5.1.1. Recipient Algorithm Classes . . . . . . . . . . . . . 24 5.1.1. Recipient Algorithm Classes . . . . . . . . . . . . . 24
5.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 25 5.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 25
5.3. How to encrypt and decrypt for AEAD Algorithms . . . . . 25 5.3. How to encrypt and decrypt for AEAD Algorithms . . . . . 25
5.4. How to encrypt and decrypt for AE Algorithms . . . . . . 28 5.4. How to encrypt and decrypt for AE Algorithms . . . . . . 28
6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. MACed Message with Recipients . . . . . . . . . . . . . . 29 6.1. MACed Message with Recipients . . . . . . . . . . . . . . 30
6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 30 6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 31
6.3. How to compute and verify a MAC . . . . . . . . . . . . . 31 6.3. How to compute and verify a MAC . . . . . . . . . . . . . 31
7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 33 7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 33
8. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 36 8. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 36
8.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1.1. Security Considerations . . . . . . . . . . . . . . . 39 8.1.1. Security Considerations . . . . . . . . . . . . . . . 39
8.2. Edwards-curve Digital Signature Algorithms (EdDSA) . . . 40 8.2. Edwards-curve Digital Signature Algorithms (EdDSA) . . . 40
8.2.1. Security Considerations . . . . . . . . . . . . . . . 41 8.2.1. Security Considerations . . . . . . . . . . . . . . . 41
9. Message Authentication (MAC) Algorithms . . . . . . . . . . . 41 9. Message Authentication (MAC) Algorithms . . . . . . . . . . . 41
9.1. Hash-based Message Authentication Codes (HMAC) . . . . . 41 9.1. Hash-based Message Authentication Codes (HMAC) . . . . . 41
skipping to change at page 3, line 44 skipping to change at page 3, line 44
13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 69 13.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . 69
13.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 70 13.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 70
13.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 71 13.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 71
13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 72 13.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 72
14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 73 14. CBOR Encoder Restrictions . . . . . . . . . . . . . . . . . . 73
15. Application Profiling Considerations . . . . . . . . . . . . 73 15. Application Profiling Considerations . . . . . . . . . . . . 73
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
16.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 75 16.1. CBOR Tag assignment . . . . . . . . . . . . . . . . . . 75
16.2. COSE Header Parameters Registry . . . . . . . . . . . . 75 16.2. COSE Header Parameters Registry . . . . . . . . . . . . 75
16.3. COSE Header Algorithm Parameters Registry . . . . . . . 76 16.3. COSE Header Algorithm Parameters Registry . . . . . . . 76
16.4. COSE Algorithms Registry . . . . . . . . . . . . . . . . 76 16.4. COSE Algorithms Registry . . . . . . . . . . . . . . . . 77
16.5. COSE Key Common Parameters Registry . . . . . . . . . . 77 16.5. COSE Key Common Parameters Registry . . . . . . . . . . 77
16.6. COSE Key Type Parameters Registry . . . . . . . . . . . 78 16.6. COSE Key Type Parameters Registry . . . . . . . . . . . 78
16.7. COSE Key Type Registry . . . . . . . . . . . . . . . . . 79 16.7. COSE Key Type Registry . . . . . . . . . . . . . . . . . 79
16.8. COSE Elliptic Curve Parameters Registry . . . . . . . . 79 16.8. COSE Elliptic Curve Parameters Registry . . . . . . . . 79
16.9. Media Type Registrations . . . . . . . . . . . . . . . . 80 16.9. Media Type Registrations . . . . . . . . . . . . . . . . 80
16.9.1. COSE Security Message . . . . . . . . . . . . . . . 80 16.9.1. COSE Security Message . . . . . . . . . . . . . . . 80
16.9.2. COSE Key media type . . . . . . . . . . . . . . . . 81 16.9.2. COSE Key media type . . . . . . . . . . . . . . . . 81
16.10. CoAP Content-Format Registrations . . . . . . . . . . . 83 16.10. CoAP Content-Format Registrations . . . . . . . . . . . 83
16.11. Expert Review Instructions . . . . . . . . . . . . . . . 83 16.11. Expert Review Instructions . . . . . . . . . . . . . . . 84
17. Implementation Status . . . . . . . . . . . . . . . . . . . . 84 17. Implementation Status . . . . . . . . . . . . . . . . . . . . 85
17.1. Author's Versions . . . . . . . . . . . . . . . . . . . 85 17.1. Author's Versions . . . . . . . . . . . . . . . . . . . 86
17.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 86 17.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 86
18. Security Considerations . . . . . . . . . . . . . . . . . . . 86 18. Security Considerations . . . . . . . . . . . . . . . . . . . 87
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 89
19.1. Normative References . . . . . . . . . . . . . . . . . . 88 19.1. Normative References . . . . . . . . . . . . . . . . . . 89
19.2. Informative References . . . . . . . . . . . . . . . . . 89 19.2. Informative References . . . . . . . . . . . . . . . . . 90
Appendix A. Making Mandatory Algorithm Header Optional . . . . . 92 Appendix A. Making Mandatory Algorithm Header Optional . . . . . 93
A.1. Algorithm Identification . . . . . . . . . . . . . . . . 92 A.1. Algorithm Identification . . . . . . . . . . . . . . . . 93
A.2. Counter Signature Without Headers . . . . . . . . . . . . 95 A.2. Counter Signature Without Headers . . . . . . . . . . . . 96
Appendix B. Two Layers of Recipient Information . . . . . . . . 96 Appendix B. Two Layers of Recipient Information . . . . . . . . 97
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 97 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 98
C.1. Examples of Signed Message . . . . . . . . . . . . . . . 98 C.1. Examples of Signed Message . . . . . . . . . . . . . . . 99
C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 98 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 99
C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 99 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 100
C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 100 C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 101
C.1.4. Signature w/ Criticality . . . . . . . . . . . . . . 101 C.1.4. Signature w/ Criticality . . . . . . . . . . . . . . 102
C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 102 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 103
C.2.1. Single ECDSA signature . . . . . . . . . . . . . . . 102 C.2.1. Single ECDSA signature . . . . . . . . . . . . . . . 103
C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 103 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 104
C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 103 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 104
C.3.2. Direct plus Key Derivation . . . . . . . . . . . . . 104 C.3.2. Direct plus Key Derivation . . . . . . . . . . . . . 105
C.3.3. Counter Signature on Encrypted Content . . . . . . . 105 C.3.3. Counter Signature on Encrypted Content . . . . . . . 106
C.3.4. Encrypted Content with External Data . . . . . . . . 107 C.3.4. Encrypted Content with External Data . . . . . . . . 108
C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 107 C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 108
C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 107 C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 108
C.4.2. Encrypted Message w/ a Partial IV . . . . . . . . . . 108 C.4.2. Encrypted Message w/ a Partial IV . . . . . . . . . . 109
C.5. Examples of MACed messages . . . . . . . . . . . . . . . 108 C.5. Examples of MACed messages . . . . . . . . . . . . . . . 109
C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 108 C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 109
C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 109 C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 110
C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 110 C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 111
C.5.4. Multi-recipient MACed message . . . . . . . . . . . . 111 C.5.4. Multi-recipient MACed message . . . . . . . . . . . . 112
C.6. Examples of MAC0 messages . . . . . . . . . . . . . . . . 112 C.6. Examples of MAC0 messages . . . . . . . . . . . . . . . . 113
C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 112 C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 113
C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 113 C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 114
C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 113 C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 114
C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 114 C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 115
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 116 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 117
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 117 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 118
1. Introduction 1. Introduction
There has been an increased focus on the small, constrained devices There has been an increased focus on small, constrained devices that
that make up the Internet of Things (IoT). One of the standards that make up the Internet of Things (IoT). One of the standards that has
has come out of this process is the Concise Binary Object come out of this process is the Concise Binary Object Representation
Representation (CBOR) [RFC7049]. CBOR extended the data model of the (CBOR) [RFC7049]. CBOR extended the data model of the JavaScript
JavaScript Object Notation (JSON) [RFC7159] by allowing for binary Object Notation (JSON) [RFC7159] by allowing for binary data, among
data, among other changes. CBOR is being adopted by several of the other changes. CBOR is being adopted by several of the IETF working
IETF working groups dealing with the IoT world as their encoding of groups dealing with the IoT world as their encoding of data
data structures. CBOR was designed specifically to be both small in structures. CBOR was designed specifically to be both small in terms
terms of messages transport and implementation size, as well having a of messages transport and implementation size, as well having a
schema free decoder. A need exists to provide message security schema free decoder. A need exists to provide message security
services for IoT and using CBOR as the message encoding format makes services for IoT, using CBOR as the message encoding format makes
sense. sense.
The JOSE working group produced a set of documents The JOSE working group produced a set of documents
[RFC7515][RFC7516][RFC7517][RFC7518] using JSON that specified how to [RFC7515][RFC7516][RFC7517][RFC7518] using JSON that specified how to
process encryption, signatures and message authentication (MAC) process encryption, signatures and message authentication (MAC)
operations, and how to encode keys using JSON. This document defines operations, and how to encode keys using JSON. This document defines
the CBOR Object Encryption and Signing (COSE) standard which does the the CBOR Object Encryption and Signing (COSE) standard which does the
same thing for the CBOR encoding format. While there is a strong same thing for the CBOR encoding format. While there is a strong
attempt to keep the flavor of the original JOSE documents, two attempt to keep the flavor of the original JOSE documents, two
considerations are taken into account: considerations are taken into account:
skipping to change at page 5, line 35 skipping to change at page 5, line 35
into a base64 encoded string. into a base64 encoded string.
o COSE is not a direct copy of the JOSE specification. In the o COSE is not a direct copy of the JOSE specification. In the
process of creating COSE, decisions that were made for JOSE were process of creating COSE, decisions that were made for JOSE were
re-examined. In many cases different results were decided on as re-examined. In many cases different results were decided on as
the criteria was not always the same. the criteria was not always the same.
1.1. Design changes from JOSE 1.1. Design changes from JOSE
o Define a single top message structure so that encrypted, signed o Define a single top message structure so that encrypted, signed
and MACed messages can easily identified and still have a and MACed messages can easily be identified and still have a
consistent view. consistent view.
o Signed messages separate the concept of protected and unprotected o Signed messages distinguish between the protected and unprotected
parameters that are for the content and the signature. parameters that relate to the content from those that relate to
the signature.
o MACed messages are separated from signed messages. o MACed messages are separated from signed messages.
o MACed messages have the ability to use the same set of recipient o MACed messages have the ability to use the same set of recipient
algorithms as enveloped messages for obtaining the MAC algorithms as enveloped messages for obtaining the MAC
authentication key. authentication key.
o Use binary encodings for binary data rather than base64url o Use binary encodings for binary data rather than base64url
encodings. encodings.
skipping to change at page 11, line 22 skipping to change at page 11, line 22
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 16.2). in the "COSE Header Parameters" IANA registry (Section 16.2).
Two buckets are provided for each layer: Two buckets are provided for each layer:
protected: Contains parameters about the current layer that are to protected: Contains parameters about the current layer that are to
be cryptographically protected. This bucket MUST be empty if it be cryptographically protected. This bucket MUST be empty if it
is not going to be included in a cryptographic computation. This is 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 zero length map as a zero a bstr object. Senders SHOULD encode a zero length map as a zero
length string rather than as a zero length map (encoded as h'a0'). length string rather than as a zero length map (encoded as h'a0').
The zero length binary encoding is preferred because it is both The zero length binary encoding is preferred because it is both
shorter and the version used in the serialization structures for shorter and the version used in the serialization structures for
cryptographic computation. After encoding the map the value is cryptographic computation. After encoding the map, the value is
wrapped in the binary object. Recipients MUST accept both a zero wrapped in the binary object. Recipients MUST accept both a zero
length binary value and a zero length map encoded in the binary length binary value and a zero length map encoded in the binary
value. The wrapping allows for the encoding of the protected map value. The wrapping allows for the encoding of the protected map
to be transported with a greater chance that it will not be to be transported with a greater chance that it will not be
altered in transit. (Badly behaved intermediates could decode and altered in transit. (Badly behaved intermediates could decode and
re-encode, but this will result in a failure to verify unless the re-encode, but this will result in a failure to verify unless the
re-encoded byte string is identical to the decoded byte string.) re-encoded byte string is identical to the decoded byte string.)
This avoids the problem of all parties needing to be able to do a This avoids the problem of all parties needing to be able to do a
common canonical encoding. common canonical encoding.
skipping to change at page 16, line 18 skipping to change at page 16, line 18
? 3 => tstr / int, ; content type ? 3 => tstr / int, ; content type
? 4 => bstr, ; key identifier ? 4 => bstr, ; key identifier
? 5 => bstr, ; IV ? 5 => bstr, ; IV
? 6 => bstr, ; Partial IV ? 6 => bstr, ; Partial IV
? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature ? 7 => COSE_Signature / [+COSE_Signature] ; Counter signature
) )
4. Signing Objects 4. Signing Objects
COSE supports two different signature structures. COSE_Sign allows COSE supports two different signature structures. COSE_Sign allows
for one or more signers to be applied to a single content. for one or more signatures to be applied to the same content.
COSE_Sign1 is restricted to a single signer. The structures cannot COSE_Sign1 is restricted to a single signer. The structures cannot
be converted between each other; as the signature computation be converted between each other; as the signature computation
includes a parameter identifying which structure is being used, the includes a parameter identifying which structure is being used, the
converted structure will fail signature validation. converted structure will fail signature validation.
4.1. Signing with One or More Signers 4.1. Signing with One or More Signers
The COSE_Sign structure allows for one or more signatures to be The COSE_Sign structure allows for one or more signatures to be
applied to a message payload. There are provisions for parameters applied to a message payload. Parameters relating to the content and
about the content and parameters about the signature to be carried parameters relating to the signature are carried along with the
along with the signature itself. These parameters may be signature itself. These parameters may be authenticated by the
authenticated by the signature, or just present. An example of a signature, or just present. An example of a parameter about the
parameter about the content is the content type. Examples of content is the content type. Examples of parameters about the
parameters about the signature would be the algorithm and key used to signature would be the algorithm and key used to create the signature
create the signature and counter signatures. and counter signatures.
When more than one signature is present, the successful validation of When more than one signature is present, the successful validation of
one signature associated with a given signer is usually treated as a one signature associated with a given signer is usually treated as a
successful signature by that signer. However, there are some successful signature by that signer. However, there are some
application environments where other rules are needed. An application environments where other rules are needed. An
application that employs a rule other than one valid signature for application that employs a rule other than one valid signature for
each signer must specify those rules. Also, where simple matching of each signer must specify those rules. Also, where simple matching of
the signer identifier is not sufficient to determine whether the the signer identifier is not sufficient to determine whether the
signatures were generated by the same signer, the application signatures were generated by the same signer, the application
specification must describe how to determine which signatures were specification must describe how to determine which signatures were
generated by the same signer. Support of different communities of generated by the same signer. Support for 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 Edwards Digital Signature include signatures generated with the Edwards Digital Signature
Algorithm (EdDSA) signature algorithm and with the Elliptic Curve Algorithm (EdDSA) signature algorithm and with the Elliptic Curve
Digital Signature Algorithm (ECDSA) signature algorithm. This allows Digital Signature Algorithm (ECDSA) signature algorithm. This allows
recipients to verify the signature associated with one algorithm or recipients to verify the signature associated with one algorithm or
the other. (The original source of this text is [RFC5652].) More the other. (The original source of this text is [RFC5652].) More
detailed information on multiple signature evaluation can be found in detailed information on multiple signature evaluation can be found in
[RFC5752]. [RFC5752].
skipping to change at page 21, line 28 skipping to change at page 21, line 28
2. Create the value ToBeSigned by encoding the Sig_structure to a 2. Create the value ToBeSigned by encoding the Sig_structure to a
byte string, using the encoding described in Section 14. byte string, using the encoding described in Section 14.
3. Call the signature creation algorithm passing in K (the key to 3. Call the signature creation algorithm passing in K (the key to
sign with), alg (the algorithm to sign with), and ToBeSigned (the sign with), alg (the algorithm to sign with), and ToBeSigned (the
value to sign). value to sign).
4. Place the resulting signature value in the 'signature' field of 4. Place the resulting signature value in the 'signature' field of
the array. the array.
How to verify a signature: The steps for verifying a signature are:
1. Create a Sig_structure object and populate it with the 1. Create a Sig_structure object and populate it with the
appropriate fields. appropriate fields.
2. Create the value ToBeSigned by encoding the Sig_structure to a 2. Create the value ToBeSigned by encoding the Sig_structure to a
byte string, using the encoding described in Section 14. byte string, using the encoding described in Section 14.
3. Call the signature verification algorithm passing in K (the key 3. Call the signature verification algorithm passing in K (the key
to verify with), alg (the algorithm used sign with), ToBeSigned to verify with), alg (the algorithm used sign with), ToBeSigned
(the value to sign), and sig (the signature to be verified). (the value to sign), and sig (the signature to be verified).
skipping to change at page 26, line 51 skipping to change at page 26, line 51
encoding described in Section 14. encoding described in Section 14.
3. Determine the encryption key (K). This step is dependent on the 3. Determine the encryption key (K). This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
Section 12.3, key wrap keys Section 12.2.1 or pre-shared Section 12.3, key wrap keys Section 12.2.1 or pre-shared
secrets. secrets.
Direct and Direct Key Agreement: The key is determined by the Direct Encryption and Direct Key Agreement: The key is
key and algorithm in the recipient structure. The encryption determined by the key and algorithm in the recipient
algorithm and size of the key to be used are inputs into the structure. The encryption algorithm and size of the key to be
KDF used for the recipient. (For direct, the KDF can be used are inputs into the KDF used for the recipient. (For
thought of as the identity operation.) Examples of these direct, the KDF can be thought of as the identity operation.)
algorithms are found in Section 12.1.2 and Section 12.4.1. Examples of these algorithms are found in Section 12.1.2 and
Section 12.4.1.
Other: The key is randomly generated. Other: The key is randomly generated.
4. Call the encryption algorithm with K (the encryption key), P (the 4. Call the encryption algorithm with K (the encryption key), P (the
plain text) and AAD. Place the returned cipher text into the plain text) and AAD. Place the returned cipher text into the
'ciphertext' field of the structure. 'ciphertext' field of the structure.
5. For recipients of the message, recursively perform the encryption 5. For recipients of the message, recursively perform the encryption
algorithm for that recipient, using K (the encryption key) as the algorithm for that recipient, using K (the encryption key) as the
plain text. plain text.
skipping to change at page 27, line 35 skipping to change at page 27, line 36
encoding described in Section 14. encoding described in Section 14.
3. Determine the decryption key. This step is dependent on the 3. Determine the decryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
Section 12.3, key wrap keys Section 12.2.1 or pre-shared Section 12.3, key wrap keys Section 12.2.1 or pre-shared
secrets. secrets.
Direct and Direct Key Agreement: The key is determined by the Direct Encryption and Direct Key Agreement: The key is
key and algorithm in the recipient structure. The encryption determined by the key and algorithm in the recipient
algorithm and size of the key to be used are inputs into the structure. The encryption algorithm and size of the key to be
KDF used for the recipient. (For direct, the KDF can be used are inputs into the KDF used for the recipient. (For
thought of as the identity operation.) Examples of these direct, the KDF can be thought of as the identity operation.)
algorithms are found in Section 12.1.2 and Section 12.4.1. Examples of these algorithms are found in Section 12.1.2 and
Section 12.4.1.
Other: The key is determined by decoding and decrypting one of Other: The key is determined by decoding and decrypting one of
the recipient structures. the recipient structures.
4. Call the decryption algorithm with K (the decryption key to use), 4. Call the decryption algorithm with K (the decryption key to use),
C (the cipher text) and AAD. C (the cipher text) and AAD.
5.4. How to encrypt and decrypt for AE Algorithms 5.4. How to encrypt and decrypt for AE Algorithms
How to encrypt a message: How to encrypt a message:
skipping to change at page 28, line 22 skipping to change at page 28, line 22
supplied for this operation. supplied for this operation.
3. Determine the encryption key. This step is dependent on the 3. Determine the encryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
Section 12.3, key wrap keys Section 12.2.1 or pre-shared Section 12.3, key wrap keys Section 12.2.1 or pre-shared
secrets. secrets.
Direct and Direct Key Agreement: The key is determined by the Direct Encryption and Direct Key Agreement: The key is
key and algorithm in the recipient structure. The encryption determined by the key and algorithm in the recipient
algorithm and size of the key to be used are inputs into the structure. The encryption algorithm and size of the key to be
KDF used for the recipient. (For direct, the KDF can be used are inputs into the KDF used for the recipient. (For
thought of as the identity operation.) Examples of these direct, the KDF can be thought of as the identity operation.)
algorithms are found in Section 12.1.2 and Section 12.4.1. Examples of these algorithms are found in Section 12.1.2 and
Section 12.4.1.
Other: The key is randomly generated. Other: The key is randomly generated.
4. Call the encryption algorithm with K (the encryption key to use) 4. Call the encryption algorithm with K (the encryption key to use)
and the P (the plain text). Place the returned cipher text into and the P (the plain text). Place the returned cipher text into
the 'ciphertext' field of the structure. the 'ciphertext' field of the structure.
5. For recipients of the message, recursively perform the encryption 5. For recipients of the message, recursively perform the encryption
algorithm for that recipient, using K (the encryption key) as the algorithm for that recipient, using K (the encryption key) as the
plain text. plain text.
skipping to change at page 29, line 5 skipping to change at page 29, line 7
supplied for this operation. supplied for this operation.
3. Determine the decryption key. This step is dependent on the 3. Determine the decryption key. This step is dependent on the
class of recipient algorithm being used. For: class of recipient algorithm being used. For:
No Recipients: The key to be used is determined by the algorithm No Recipients: The key to be used is determined by the algorithm
and key at the current layer. Examples are key transport keys and key at the current layer. Examples are key transport keys
Section 12.3, key wrap keys Section 12.2.1 or pre-shared Section 12.3, key wrap keys Section 12.2.1 or pre-shared
secrets. secrets.
Direct and Direct Key Agreement: The key is determined by the Direct Encryption and Direct Key Agreement: The key is
key and algorithm in the recipient structure. The encryption determined by the key and algorithm in the recipient
algorithm and size of the key to be used are inputs into the structure. The encryption algorithm and size of the key to be
KDF used for the recipient. (For direct, the KDF can be used are inputs into the KDF used for the recipient. (For
thought of as the identity operation.) Examples of these direct, the KDF can be thought of as the identity operation.)
algorithms are found in Section 12.1.2 and Section 12.4.1. Examples of these algorithms are found in Section 12.1.2 and
Section 12.4.1.
Other: The key is determined by decoding and decrypting one of Other: The key is determined by decoding and decrypting one of
the recipient structures. the recipient structures.
4. Call the decryption algorithm with K (the decryption key to use), 4. Call the decryption algorithm with K (the decryption key to use),
and C (the cipher text). and C (the cipher text).
6. MAC Objects 6. MAC Objects
COSE supports two different MAC structures. COSE_MAC0 is used when a COSE supports two different MAC structures. COSE_MAC0 is used when a
skipping to change at page 32, line 31 skipping to change at page 32, line 42
3. Call the MAC creation algorithm passing in K (the key to use), 3. Call the MAC creation algorithm passing in K (the key to use),
alg (the algorithm to MAC with) and ToBeMaced (the value to alg (the algorithm to MAC with) and ToBeMaced (the value to
compute the MAC on). compute the MAC on).
4. Place the resulting MAC in the 'tag' field of the COSE_Mac or 4. Place the resulting MAC in the 'tag' field of the COSE_Mac or
COSE_Mac0 structure. COSE_Mac0 structure.
5. 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.
How to verify a MAC are: The steps to verify a MAC are:
1. Create a MAC_structure object and populate it with the 1. Create a MAC_structure object and populate it with the
appropriate fields. appropriate fields.
2. Create the value ToBeMaced by encoding the MAC_structure to a 2. Create the value ToBeMaced by encoding the MAC_structure to a
byte stream, using the encoding described in Section 14. byte stream, using the encoding described in Section 14.
3. Obtain the cryptographic key from one of the recipients of the 3. Obtain the cryptographic key from one of the recipients of the
message. message.
skipping to change at page 41, line 25 skipping to change at page 41, line 25
If batch signature verification is performed, a well-seeded If batch signature verification is performed, a well-seeded
cryptographic random number generator is REQUIRED. Signing and non- cryptographic random number generator is REQUIRED. Signing and non-
batch signature verification are deterministic operations and do not batch signature verification are deterministic operations and do not
need random numbers of any kind. need random numbers of any kind.
9. Message Authentication (MAC) Algorithms 9. Message Authentication (MAC) Algorithms
Message Authentication Codes (MACs) provide data authentication and Message Authentication Codes (MACs) provide data authentication and
integrity protection. They provide either no or very limited data integrity protection. They provide either no or very limited data
origination. (One cannot, for example, be used to prove the identity origination. A MAC, for example, be used to prove the identity of
of the sender to a third party.) the sender to a third party.
MACs use the same scheme as signature with appendix algorithms. The MACs use the same scheme as signature with appendix algorithms. The
message content is processed and an authentication code is produced. message content is processed and an authentication code is produced.
The authentication code is frequently called a tag. The authentication code is frequently called a tag.
The MAC functions are: The MAC functions are:
tag = MAC_Create(message content, key) tag = MAC_Create(message content, key)
valid = MAC_Verify(message content, key, tag) valid = MAC_Verify(message content, key, tag)
skipping to change at page 43, line 5 skipping to change at page 43, line 5
AES-KeyWrap), the size of the HMAC key SHOULD be the same size as the AES-KeyWrap), the size of the HMAC key SHOULD be the same size as the
underlying hash function. For those algorithms that derive the key underlying hash function. For those algorithms that derive the key
(such as ECDH), the derived key MUST be the same size as the (such as ECDH), the derived key MUST be the same size as the
underlying hash function. underlying hash function.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the HMAC algorithm being o If the 'alg' field is present, it MUST match the HMAC algorithm
used. being used.
o If the 'key_ops' field is present, it MUST include 'MAC create' o If the 'key_ops' field is present, it MUST include 'MAC create'
when creating an HMAC authentication tag. when creating an HMAC authentication tag.
o If the 'key_ops' field is present, it MUST include 'MAC verify' o If the 'key_ops' field is present, it MUST include 'MAC verify'
when verifying an HMAC authentication tag. when verifying an HMAC authentication tag.
Implementations creating and validating MAC values MUST validate that Implementations creating and validating MAC values MUST validate that
the key type, key length, and algorithm are correct and appropriate the key type, key length, and algorithm are correct and appropriate
for the entities involved. for the entities involved.
9.1.1. Security Considerations 9.1.1. Security Considerations
HMAC has proved to be resistant to attack even when used with HMAC has proved to be resistant to attack even when used with
weakened hash algorithms. The current best method appears to be a weakened hash algorithms. The current best known attack appears is
brute force attack on the key. This means that key size is going to to brute force the key. This means that key size is going to be
be directly related to the security of an HMAC operation. directly 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]. (Note this is not the same AES-CBC-MAC is defined in [MAC]. (Note this is not the same
algorithm as AES-CMAC [RFC4493]). algorithm as AES-CMAC [RFC4493]).
AES-CBC-MAC is parameterized by the key length, the authentication AES-CBC-MAC is parameterized by the key length, the authentication
tag length and the IV used. For all of these algorithms, the IV is tag length and the IV used. For all of these algorithms, the IV is
fixed to all zeros. We provide an array of algorithms for various fixed to all zeros. We provide an array of algorithms for various
key lengths and tag lengths. The algorithms defined in this document key lengths and tag lengths. The algorithms defined in this document
skipping to change at page 44, line 34 skipping to change at page 44, line 34
Keys may be obtained either from a key structure or from a recipient Keys may be obtained either from a key structure or from a recipient
structure. Implementations creating and validating MAC values MUST structure. Implementations creating and validating MAC values MUST
validate that the key type, key length and algorithm are correct and validate that the key type, key length and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the AES-MAC algorithm o If the 'alg' field is present, it MUST match the AES-MAC algorithm
being used. being used.
o If the 'key_ops' field is present, it MUST include 'MAC create' o If the 'key_ops' field is present, it MUST include 'MAC create'
when creating an AES-MAC authentication tag. when creating an AES-MAC authentication tag.
o If the 'key_ops' field is present, it MUST include 'MAC verify' o If the 'key_ops' field is present, it MUST include 'MAC verify'
when verifying an AES-MAC authentication tag. when verifying an AES-MAC authentication tag.
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
generate a message with a valid tag given two message, tag pairs. generate a message with a valid tag given two message and tag
This can be addressed by using different keys for different length pairs. This can be addressed by using different keys for
messages. The current structure mitigates this problem, as a different length messages. The current structure mitigates this
specific encoding structure that includes lengths is built and problem, as a specific encoding structure that includes lengths is
signed. (CMAC also addresses this issue.) built and signed. (CMAC also addresses this issue.)
o If the same key is used for both encryption and authentication o When using CBC mode, if the same key is used for both encryption
operations, using CBC modes an attacker can produce messages with and authentication operations, an attacker can produce messages
a valid authentication code. with a valid authentication code.
o If the IV can be modified, then messages can be forged. This is o If the IV can be modified, then messages can be forged. This is
addressed by fixing the IV to all zeros. addressed by fixing the IV to all zeros.
10. Content Encryption Algorithms 10. Content Encryption Algorithms
Content Encryption Algorithms provide data confidentiality for Content Encryption Algorithms provide data confidentiality for
potentially large blocks of data using a symmetric key. They provide potentially large blocks of data using a symmetric key. They provide
integrity on the data that was encrypted, however they provide either integrity on the data that was encrypted, however they provide either
no or very limited data origination. (One cannot, for example, be no or very limited data origination. (One cannot, for example, be
skipping to change at page 46, line 31 skipping to change at page 46, line 31
Keys may be obtained either from a key structure or from a recipient Keys may be obtained either from a key structure or from a recipient
structure. Implementations encrypting and decrypting MUST validate structure. Implementations encrypting and decrypting MUST validate
that the key type, key length and algorithm are correct and that the key type, key length and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the AES-GCM algorithm o If the 'alg' field is present, it MUST match the AES-GCM algorithm
being used. being used.
o If the 'key_ops' field is present, it MUST include 'encrypt' or o If the 'key_ops' field is present, it MUST include 'encrypt' or
'wrap key' when encrypting. 'wrap key' when encrypting.
o If the 'key_ops' field is present, it MUST include 'decrypt' or o If the 'key_ops' field is present, it MUST include 'decrypt' or
'unwrap key' when decrypting. 'unwrap key' when decrypting.
10.1.1. Security Considerations 10.1.1. Security Considerations
skipping to change at page 47, line 38 skipping to change at page 47, line 38
version of CCM mode where the size of the authentication is 64 bits version of CCM mode where the size of the authentication is 64 bits
and not 8 bits. These values have traditionally been specified as and not 8 bits. These values have traditionally been specified as
bit counts rather than byte counts. This document will follow the bit counts rather than byte counts. This document will follow the
convention of using bit counts so that it is easier to compare the convention of using bit counts so that it is easier to compare the
different algorithms presented in this document. different algorithms presented in this document.
We define a matrix of algorithms in this document over the values of We define a matrix of algorithms in this document over the values of
L and M. Constrained devices are usually operating in situations L and M. Constrained devices are usually operating in situations
where they use short messages and want to avoid doing recipient where they use short messages and want to avoid doing recipient
specific cryptographic operations. This favors smaller values of specific cryptographic operations. This favors smaller values of
both L and M. Less constrained devices will want to be able to user both L and M. Less constrained devices will want to be able to use
larger messages and are more willing to generate new keys for every larger messages and are more willing to generate new keys for every
operation. This favors larger values of L and M. operation. This favors larger values of L and M.
The following values are used for L: The following values are used for L:
16 bits (2) limits messages to 2^16 bytes (64 KiB) in length. This 16 bits (2) limits messages to 2^16 bytes (64 KiB) in length. This
is sufficiently long for messages in the constrained world. The is sufficiently long for messages in the constrained world. The
nonce length is 13 bytes allowing for 2^(13*8) possible values of nonce length is 13 bytes allowing for 2^(13*8) possible values of
the nonce without repeating. the nonce without repeating.
skipping to change at page 50, line 10 skipping to change at page 50, line 10
Keys may be obtained either from a key structure or from a recipient Keys may be obtained either from a key structure or from a recipient
structure. Implementations encrypting and decrypting MUST validate structure. Implementations encrypting and decrypting MUST validate
that the key type, key length and algorithm are correct and that the key type, key length and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the AES-CCM algorithm o If the 'alg' field is present, it MUST match the AES-CCM algorithm
being used. being used.
o If the 'key_ops' field is present, it MUST include 'encrypt' or o If the 'key_ops' field is present, it MUST include 'encrypt' or
'wrap key' when encrypting. 'wrap key' when encrypting.
o If the 'key_ops' field is present, it MUST include 'decrypt' or o If the 'key_ops' field is present, it MUST include 'decrypt' or
'unwrap key' when decrypting. 'unwrap key' when decrypting.
10.2.1. Security Considerations 10.2.1. Security Considerations
skipping to change at page 51, line 27 skipping to change at page 51, line 27
Keys may be obtained either from a key structure or from a recipient Keys may be obtained either from a key structure or from a recipient
structure. Implementations encrypting and decrypting MUST validate structure. Implementations encrypting and decrypting MUST validate
that the key type, key length and algorithm are correct and that the key type, key length and algorithm are correct and
appropriate for the entities involved. appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the ChaCha20/Poly1305 o If the 'alg' field is present, it MUST match the ChaCha20/Poly1305
algorithm being used. algorithm being used.
o If the 'key_ops' field is present, it MUST include 'encrypt' or o If the 'key_ops' field is present, it MUST include 'encrypt' or
'wrap key' when encrypting. 'wrap key' when encrypting.
o If the 'key_ops' field is present, it MUST include 'decrypt' or o If the 'key_ops' field is present, it MUST include 'decrypt' or
'unwrap key' when decrypting. 'unwrap key' when decrypting.
10.3.1. Security Considerations 10.3.1. Security Considerations
skipping to change at page 60, line 28 skipping to change at page 60, line 28
| | | MAC-256 | MAC 256-bit key | | | | MAC-256 | MAC 256-bit key |
+---------------------+-------+-------------+-----------------------+ +---------------------+-------+-------------+-----------------------+
Table 16: Direct Key with KDF Table 16: Direct Key with KDF
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'Symmetric'. o The 'kty' field MUST be present and it MUST be 'Symmetric'.
o If the 'alg' field present, it MUST match the algorithm being o If the 'alg' field is present, it MUST match the algorithm being
used. used.
o If the 'key_ops' field is present, it MUST include 'deriveKey' or o If the 'key_ops' field is present, it MUST include 'deriveKey' or
'deriveBits'. 'deriveBits'.
12.1.2.1. Security Considerations 12.1.2.1. Security Considerations
The shared secret needs to have some method to be regularly updated The shared secret needs to have some method to be regularly updated
over time. The shared secret forms the basis of trust. Although not over time. The shared secret forms the basis of trust. Although not
used directly, it should still be subject to scheduled rotation. used directly, it should still be subject to scheduled rotation.
While these methods do not provide for PFS, as the same shared secret While these methods do not provide for perfect forward secrecy, as
is used for all of the keys generated, if the key for any single the same shared secret is used for all of the keys generated, if the
message is discovered only the message (or series of messages) using key for any single message is discovered only the message (or series
that derived key are compromised. A new key derivation step will of messages) using that derived key are compromised. A new key
generate a new key which requires the same amount of work to get the derivation step will generate a new key which requires the same
key. amount of work to get the key.
12.2. Key Wrapping 12.2. Key Wrapping
In key wrapping mode, the CEK is randomly generated and that key is In key wrapping mode, the CEK is randomly generated and that key is
then encrypted by a shared secret between the sender and the then encrypted by a shared secret between the sender and the
recipient. All of the currently defined key wrapping algorithms for recipient. All of the currently defined key wrapping algorithms for
COSE are AE algorithms. Key wrapping mode is considered to be COSE are AE algorithms. Key wrapping mode is considered to be
superior to direct encryption if the system has any capability for superior to direct encryption if the system has any capability for
doing random key generation. This is because the shared key is used doing random key generation. This is because the shared key is used
to wrap random data rather than data that has some degree of to wrap random data rather than data that has some degree of
organization and may in fact be repeating the same content. The use organization and may in fact be repeating the same content. The use
of Key Wrapping loses the weak data origination that is provided by of Key Wrapping loses the weak data origination that is provided by
the direct encryption algorithms. the direct encryption algorithms.
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 MUST be absent if the key wrap algorithm is o The 'protected' field MUST be absent if the key wrap algorithm is
an AE algorithm. an AE algorithm.
o The 'recipients' field is normally absent, but can be used. o The 'recipients' field is normally absent, but can be used.
Applications MUST deal with a recipient field present, not being Applications MUST deal with a recipient field being present, not
able to decrypt that recipient is an acceptable way of dealing being able to decrypt that recipient is an acceptable way of
with it. Failing to process the message is not an acceptable way dealing with it. Failing to process the message is not an
of dealing with it. acceptable way of dealing with it.
o The plain text to be encrypted is the key from next layer down o The plain text to be encrypted is the key from next layer down
(usually the content layer). (usually the content layer).
o At a minimum, the 'unprotected' field MUST contain the 'alg' o At a minimum, the 'unprotected' field MUST contain the 'alg'
parameter and SHOULD contain a parameter identifying the shared parameter and SHOULD contain a parameter identifying the shared
secret. secret.
12.2.1. AES Key Wrapping 12.2.1. AES Key Wrapping
skipping to change at page 66, line 32 skipping to change at page 66, line 32
P-256, P-384, P-521, X25519, and X448. Implementations MUST verify P-256, P-384, P-521, X25519, and X448. Implementations MUST verify
that the key type and curve are correct. Different curves are that the key type and curve are correct. Different curves are
restricted to different key types. Implementations MUST verify that restricted to different key types. Implementations MUST verify that
the curve and algorithm are appropriate for the entities involved. the curve and algorithm are appropriate for the entities involved.
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'. o The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'.
o If the 'alg' field present, it MUST match the Key Agreement o If the 'alg' field is present, it MUST match the Key Agreement
algorithm being used. algorithm being used.
o If the 'key_ops' field is present, it MUST include 'derive key' or o If the 'key_ops' field is present, it MUST include 'derive key' or
'derive bits' for the private key. 'derive bits' for the private key.
o If the 'key_ops' field is present, it MUST be empty for the public o If the 'key_ops' field is present, it MUST be empty for the public
key. key.
12.4.2. Security Considerations 12.4.2. Security Considerations
skipping to change at page 69, line 5 skipping to change at page 69, line 5
| | | | | | bit key | | | | | | | bit key |
+-----------+-------+---------+------------+--------+---------------+ +-----------+-------+---------+------------+--------+---------------+
Table 20: ECDH Algorithm Values with Key Wrap Table 20: ECDH Algorithm Values with Key Wrap
When using a COSE key for this algorithm, the following checks are When using a COSE key for this algorithm, the following checks are
made: made:
o The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'. o The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'.
o If the 'alg' field present, it MUST match the Key Agreement o If the 'alg' field is present, it MUST match the Key Agreement
algorithm being used. algorithm being used.
o If the 'key_ops' field is present, it MUST include 'derive key' or o If the 'key_ops' field is present, it MUST include 'derive key' or
'derive bits' for the private key. 'derive bits' for the private key.
o If the 'key_ops' field is present, it MUST be empty for the public o If the 'key_ops' field is present, it MUST be empty for the public
key. key.
13. Key Object Parameters 13. Key Object Parameters
skipping to change at page 73, line 46 skipping to change at page 73, line 46
15. Application Profiling Considerations 15. Application Profiling Considerations
This document is designed to provide a set of security services, but This document is designed to provide a set of security services, but
not to provide implementation requirements for specific usage. The not to provide implementation requirements for specific usage. The
interoperability requirements are provided for how each of the interoperability requirements are provided for how each of the
individual services are used and how the algorithms are to be used individual services are used and how the algorithms are to be used
for interoperability. The requirements about which algorithms and for interoperability. The requirements about which algorithms and
which services are needed are deferred to each application. which services are needed are deferred to each application.
Applications are therefore intended to profile the usage of this It is intended that a profile of this document be created that
document. This section provides a set of guidelines and topics that defines the interopability requirements for that specific
applications need to consider when using this document. application. This section provides a set of guidelines and topics
that need to be considered when profiling this document.
o Applications need to determine the set of messages defined in this o Applications need to determine the set of messages defined in this
document that they will be using. The set of messages corresponds document that they will be using. The set of messages corresponds
fairly directly to the set of security services that are needed fairly directly to the set of security services that are needed
and to the security levels needed. and to the security levels needed.
o Applications may define new header parameters for a specific o Applications may define new header parameters for a specific
purpose. Applications will often times select specific header purpose. Applications will often times select specific header
parameters to use or not to use. For example, an application parameters to use or not to use. For example, an application
would normally state a preference for using either the IV or the would normally state a preference for using either the IV or the
skipping to change at page 75, line 21 skipping to change at page 75, line 21
COSE_Encrypt0, and COSE_Mac0 be assigned in the 1 to 23 value range COSE_Encrypt0, and COSE_Mac0 be assigned in the 1 to 23 value range
(one byte long when encoded). It is requested that the tags for (one byte long when encoded). It is requested that the tags for
COSE_Sign, COSE_Encrypt and COSE_MAC be assigned in the 24 to 255 COSE_Sign, COSE_Encrypt and COSE_MAC be assigned in the 24 to 255
value range (two bytes long when encoded). value range (two bytes long when encoded).
The tags to be assigned are in Table 1. The tags to be assigned are in Table 1.
16.2. COSE Header Parameters Registry 16.2. COSE Header Parameters Registry
It is requested that IANA create a new registry entitled "COSE Header It is requested that IANA create a new registry entitled "COSE Header
Parameters". The registry is to be created as Expert Review Parameters". The registry should be created as Expert Review
Required. Expert review guidelines are provided in Section 16.11. Required. Guidelines for the experts is provided Section 16.11. It
should be noted that in additional to the expert review, some
portions of the registry require a specification, potentially on
standards track, be supplied as well.
The columns of the registry are: The columns of the registry are:
name The name is present to make it easier to refer to and discuss name The name is present to make it easier to refer to and discuss
the registration entry. The value is not used in the protocol. the registration entry. The value is not used in the protocol.
Names are to be unique in the table. Names are to be unique in the table.
label This is the value used for the label. The label can be either label This is the value used for the label. The label can be either
an integer or a string. Registration in the table is based on the an integer or a string. Registration in the table is based on the
value of the label requested. Integer values between 1 and 255 value of the label requested. Integer values between 1 and 255
skipping to change at page 76, line 50 skipping to change at page 77, line 9
the header field (where public). the header field (where public).
The initial contents of the registry can be found in Table 13, The initial contents of the registry can be found in Table 13,
Table 14, and Table 19. The specification column for all rows in Table 14, and Table 19. The specification column for all rows in
that table should be this document. that table should be this document.
16.4. COSE Algorithms Registry 16.4. COSE Algorithms Registry
It is requested that IANA create a new registry entitled "COSE It is requested that IANA create a new registry entitled "COSE
Algorithms Registry". The registry is to be created as Expert Review Algorithms Registry". The registry is to be created as Expert Review
Required. Expert review guidelines are provided in Section 16.11. Required. Guidelines for the experts is provided Section 16.11. It
should be noted that in additional to the expert review, some
portions of the registry require a specification, potentially on
standards track, be supplied as well.
The columns of the registry are: The columns of the registry are:
value The value to be used to identify this algorithm. Algorithm value The value to be used to identify this algorithm. Algorithm
values MUST be unique. The value can be a positive integer, a values MUST be unique. The value can be a positive integer, a
negative integer or a string. Integer values between -256 and 255 negative integer or a string. Integer values between -256 and 255
and strings of length 1 are designated as Standards Track Document and strings of length 1 are designated as Standards Track Document
required. Integer values from -65536 to 65535 and strings of required. Integer values from -65536 to 65535 and strings of
length 2 are designated as Specification Required. Integer values length 2 are designated as Specification Required. Integer values
of greater than 65535 and strings of length greater than 2 are of greater than 65535 and strings of length greater than 2 are
skipping to change at page 77, line 37 skipping to change at page 77, line 48
(COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and (COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and
COSE_Mac0). Negative numbers were used for second layer objects COSE_Mac0). Negative numbers were used for second layer objects
(COSE_Signature and COSE_recipient). Expert reviewers should (COSE_Signature and COSE_recipient). Expert reviewers should
consider this practice, but are not expected to be restricted by this consider this practice, but are not expected to be restricted by this
precedent. precedent.
16.5. COSE Key Common Parameters Registry 16.5. COSE Key Common Parameters Registry
It is requested that IANA create a new registry entitled "COSE Key It is requested that IANA create a new registry entitled "COSE Key
Common Parameters" registry. The registry is to be created as Expert Common Parameters" registry. The registry is to be created as Expert
Review Required. Expert review guidelines are provided in Review Required. Guidelines for the experts is provided
Section 16.11. Section 16.11. It should be noted that in additional to the expert
review, some portions of the registry require a specification,
potentially on standards track, be supplied as well.
The columns of the registry are: The columns of the registry are:
name This is a descriptive name that enables easier reference to the name This is a descriptive name that enables easier reference to the
item. It is not used in the encoding. item. It is not used in the encoding.
label The value to be used to identify this algorithm. Key map label The value to be used to identify this algorithm. Key map
labels MUST be unique. The label can be a positive integer, a labels MUST be unique. The label can be a positive integer, a
negative integer or a string. Integer values between 0 and 255 negative integer or a string. Integer values between 0 and 255
and strings of length 1 are designated as Standards Track Document and strings of length 1 are designated as Standards Track Document
skipping to change at page 79, line 8 skipping to change at page 79, line 23
specification This contains a pointer to the public specification specification This contains a pointer to the public specification
for the field if one exists. for the field if one exists.
This registry will be initially populated by the values in Table 23, This registry will be initially populated by the values in Table 23,
Table 24, and Table 25. The specification column for all of these Table 24, and Table 25. The specification column for all of these
entries will be this document. entries will be this document.
16.7. COSE Key Type Registry 16.7. COSE Key Type Registry
It is requested that IANA create a new registry "COSE Key Type It is requested that IANA create a new registry "COSE Key Type
Registry"> The registry is to be created as Expert Review Required. Registry". The registry is to be created as Expert Review Required.
Expert review guidelines are provided in Section 16.11. Expert review guidelines are provided in Section 16.11.
The columns of this table are: The columns of this table are:
name This is a descriptive name that enables easier reference to the name This is a descriptive name that enables easier reference to the
item. The name MUST be unique. It is not used in the encoding. item. The name MUST be unique. It is not used in the encoding.
value This is the value used to identify the curve. These values value This is the value used to identify the curve. These values
MUST be unique. The value can be a positive integer, a negative MUST be unique. The value can be a positive integer, a negative
integer or a string. integer or a string.
skipping to change at page 79, line 33 skipping to change at page 79, line 48
for the curve if one exists. for the curve if one exists.
This registry will be initially populated by the values in Table 21. This registry will be initially populated by the values in Table 21.
The specification column for all of these entries will be this The specification column for all of these entries will be this
document. document.
16.8. COSE Elliptic Curve Parameters Registry 16.8. COSE Elliptic Curve Parameters Registry
It is requested that IANA create a new registry "COSE Elliptic Curve It is requested that IANA create a new registry "COSE Elliptic Curve
Parameters". The registry is to be created as Expert Review Parameters". The registry is to be created as Expert Review
Required. Expert review guidelines are provided in Section 16.11. Required. Guidelines for the experts is provided Section 16.11. It
should be noted that in additional to the expert review, some
portions of the registry require a specification, potentially on
standards track, be supplied as well.
The columns of the table are: The columns of the table are:
name This is a descriptive name that enables easier reference to the name This is a descriptive name that enables easier reference to the
item. It is not used in the encoding. item. It is not used in the encoding.
value This is the value used to identify the curve. These values value This is the value used to identify the curve. These values
MUST be unique. The integer values from -256 to 255 are MUST be unique. The integer values from -256 to 255 are
designated as Standards Track Document Required. The integer designated as Standards Track Document Required. The integer
values from 256 to 65535 and -65536 to -257 are designated as values from 256 to 65535 and -65536 to -257 are designated as
skipping to change at page 84, line 28 skipping to change at page 85, line 18
available is considered to be permissible. Specifications are available is considered to be permissible. Specifications are
needed for the first-come, first-serve range if they are expected needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way. to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is needs to have sufficient information to identify what the point is
being used for. being used for.
o Experts should take into account the expected usage of fields when o Experts should take into account the expected usage of fields when
approving point assignment. The fact that there is a range for approving point assignment. The fact that there is a range for
standards track documents does not mean that a standards track standards track documents does not mean that a standards track
document cannot have points assigned outside of that range. Some document cannot have points assigned outside of that range. The
of the ranges are restricted in range, items that are not expected length of the encoded value should be weighed against how many
to be common or are not expected to be used in constrained code points of that length are left, the size of device it will be
environments should be assigned to values which will encode to used on, and the number of code points left that encode to that
longer byte strings. size.
o When algorithms are registered, vanity registrations should be o When algorithms are registered, vanity registrations should be
discouraged. One way to do this is to require registrations to discouraged. One way to do this is to require registrations to
provide additional documentation on security analysis of the provide additional documentation on security analysis of the
algorithm. Another thing that should be considered is to request algorithm. Another thing that should be considered is to request
for an opinion on the algorithm from the Crypto Forum Research for an opinion on the algorithm from the Crypto Forum Research
Group (CFRG). Algorithms that do not meet the security Group (CFRG). Algorithms that do not meet the security
requirements of the community and the messages structures should requirements of the community and the messages structures should
not be registered. not be registered.
skipping to change at page 86, line 41 skipping to change at page 87, line 32
Implementations need to protect the private key material for any Implementations need to protect the private key material for any
individuals. There are some cases in this document that need to be individuals. There are some cases in this document that need to be
highlighted on this issue. highlighted on this issue.
o Using the same key for two different algorithms can leak o Using the same key for two different algorithms can leak
information about the key. It is therefore recommended that keys information about the key. It is therefore recommended that keys
be restricted to a single algorithm. be restricted to a single algorithm.
o Use of 'direct' as a recipient algorithm combined with a second o Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm, either directly in a separate message, recipient algorithm, exposes the direct key to the second
exposes the direct key to the second recipient. recipient.
o Several of the algorithms in this document have limits on the o Several of the algorithms in this document have limits on the
number of times that a key can be used without leaking information number of times that a key can be used without leaking information
about the key. about the key.
The use of ECDH and direct plus KDF (with no key wrap) will not The use of ECDH and direct plus KDF (with no key wrap) will not
directly lead to the private key being leaked; the one way function directly lead to the private key being leaked; the one way function
of the KDF will prevent that. There is however, a different issue of the KDF will prevent that. There is however, a different issue
that needs to be addressed. Having two recipients requires that the that needs to be addressed. Having two recipients requires that the
CEK be shared between two recipients. The second recipient therefore CEK be shared between two recipients. The second recipient therefore
skipping to change at page 89, line 36 skipping to change at page 90, line 26
19.2. Informative References 19.2. Informative References
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Vigano, C. and H. Birkholz, "CBOR data definition language Vigano, C. and H. Birkholz, "CBOR data definition language
(CDDL): a notational convention to express CBOR data (CDDL): a notational convention to express CBOR data
structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work
in progress), March 2016. in progress), March 2016.
[I-D.irtf-cfrg-eddsa] [I-D.irtf-cfrg-eddsa]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-06 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08
(work in progress), August 2016. (work in progress), August 2016.
[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.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>. <http://www.rfc-editor.org/info/rfc2045>.
 End of changes. 48 change blocks. 
150 lines changed or deleted 168 lines changed or added

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