draft-ietf-cose-rfc8152bis-struct-13.txt   draft-ietf-cose-rfc8152bis-struct-14.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) September 4, 2020 Obsoletes: 8152 (if approved) 24 September 2020
Intended status: Standards Track Intended status: Standards Track
Expires: March 8, 2021 Expires: 28 March 2021
CBOR Object Signing and Encryption (COSE): Structures and Process CBOR Object Signing and Encryption (COSE): Structures and Process
draft-ietf-cose-rfc8152bis-struct-13 draft-ietf-cose-rfc8152bis-struct-14
Abstract Abstract
Concise Binary Object Representation (CBOR) is a data format designed Concise Binary Object Representation (CBOR) is a data format designed
for small code size and small message size. There is a need for the for small code size and small message size. There is a need for the
ability to have basic security services defined for this data format. ability to have basic security services defined for this data format.
This document defines the CBOR Object Signing and Encryption (COSE) This document defines the CBOR Object Signing and Encryption (COSE)
protocol. This specification describes how to create and process protocol. This specification describes how to create and process
signatures, message authentication codes, and encryption using CBOR signatures, message authentication codes, and encryption using CBOR
for serialization. This specification additionally describes how to for serialization. This specification additionally describes how to
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 8, 2021. This Internet-Draft will expire on 28 March 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 51 skipping to change at page 2, line 51
5.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 27 5.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 27
5.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 29 5.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 29
6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 30 6. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. MACed Message with Recipients . . . . . . . . . . . . . . 31 6.1. MACed Message with Recipients . . . . . . . . . . . . . . 31
6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 32 6.2. MACed Messages with Implicit Key . . . . . . . . . . . . 32
6.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 33 6.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 33
7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 34 7. Key Objects . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 35 7.1. COSE Key Common Parameters . . . . . . . . . . . . . . . 35
8. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 37 8. Taxonomy of Algorithms used by COSE . . . . . . . . . . . . . 37
8.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 38 8.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 38
8.2. Message Authentication Code (MAC) Algorithms . . . . . . 39 8.2. Message Authentication Code (MAC) Algorithms . . . . . . 40
8.3. Content Encryption Algorithms . . . . . . . . . . . . . . 39 8.3. Content Encryption Algorithms . . . . . . . . . . . . . . 40
8.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 40 8.4. Key Derivation Functions (KDFs) . . . . . . . . . . . . . 41
8.5. Content Key Distribution Methods . . . . . . . . . . . . 41 8.5. Content Key Distribution Methods . . . . . . . . . . . . 42
8.5.1. Direct Encryption . . . . . . . . . . . . . . . . . . 41 8.5.1. Direct Encryption . . . . . . . . . . . . . . . . . . 42
8.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 41 8.5.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . 42
8.5.3. Key Transport . . . . . . . . . . . . . . . . . . . . 42 8.5.3. Key Transport . . . . . . . . . . . . . . . . . . . . 43
8.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 42 8.5.4. Direct Key Agreement . . . . . . . . . . . . . . . . 43
8.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . . 43 8.5.5. Key Agreement with Key Wrap . . . . . . . . . . . . . 44
9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 44 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 45
10. Application Profiling Considerations . . . . . . . . . . . . 44 10. Application Profiling Considerations . . . . . . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.1. COSE Header Parameters Registry . . . . . . . . . . . . 46 11.1. COSE Header Parameters Registry . . . . . . . . . . . . 47
11.2. COSE Key Common Parameters Registry . . . . . . . . . . 46 11.2. COSE Key Common Parameters Registry . . . . . . . . . . 47
11.3. Media Type Registrations . . . . . . . . . . . . . . . . 46 11.3. Media Type Registrations . . . . . . . . . . . . . . . . 47
11.3.1. COSE Security Message . . . . . . . . . . . . . . . 46 11.3.1. COSE Security Message . . . . . . . . . . . . . . . 47
11.3.2. COSE Key Media Type . . . . . . . . . . . . . . . . 47 11.3.2. COSE Key Media Type . . . . . . . . . . . . . . . . 48
11.4. CoAP Content-Formats Registry . . . . . . . . . . . . . 49 11.4. CoAP Content-Formats Registry . . . . . . . . . . . . . 50
11.5. Expert Review Instructions . . . . . . . . . . . . . . . 49 11.5. CBOR Tags Registry . . . . . . . . . . . . . . . . . . . 50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 50 11.6. Expert Review Instructions . . . . . . . . . . . . . . . 50
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 52 12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
13.1. Author's Versions . . . . . . . . . . . . . . . . . . . 53 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 53
13.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 53 13.1. Author's Versions . . . . . . . . . . . . . . . . . . . 54
13.3. Python Version . . . . . . . . . . . . . . . . . . . . . 54 13.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 54
13.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 54 13.3. Python Version . . . . . . . . . . . . . . . . . . . . . 55
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 55
14.1. Normative References . . . . . . . . . . . . . . . . . . 54 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.2. Informative References . . . . . . . . . . . . . . . . . 55 14.1. Normative References . . . . . . . . . . . . . . . . . . 55
14.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Guidelines for External Data Authentication of Appendix A. Guidelines for External Data Authentication of
Algorithms . . . . . . . . . . . . . . . . . . . . . . . 59 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 60
Appendix B. Two Layers of Recipient Information . . . . . . . . 62 Appendix B. Two Layers of Recipient Information . . . . . . . . 63
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 64 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 65
C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 64 C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 65
C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 64 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 65
C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 65 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 66
C.1.3. Signature with Criticality . . . . . . . . . . . . . 66 C.1.3. Signature with Criticality . . . . . . . . . . . . . 67
C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 67 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 68
C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 67 C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 68
C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 68 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 69
C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 68 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 69
C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 69 C.3.2. Direct Plus Key Derivation . . . . . . . . . . . . . 70
C.3.3. Encrypted Content with External Data . . . . . . . . 70 C.3.3. Encrypted Content with External Data . . . . . . . . 71
C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 71 C.4. Examples of Encrypted Messages . . . . . . . . . . . . . 72
C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 71 C.4.1. Simple Encrypted Message . . . . . . . . . . . . . . 72
C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 72 C.4.2. Encrypted Message with a Partial IV . . . . . . . . . 73
C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 72 C.5. Examples of MACed Messages . . . . . . . . . . . . . . . 73
C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 72 C.5.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 73
C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 73 C.5.2. ECDH Direct MAC . . . . . . . . . . . . . . . . . . . 74
C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 74 C.5.3. Wrapped MAC . . . . . . . . . . . . . . . . . . . . . 75
C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 75 C.5.4. Multi-Recipient MACed Message . . . . . . . . . . . . 76
C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 76 C.6. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 77
C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 76 C.6.1. Shared Secret Direct MAC . . . . . . . . . . . . . . 77
C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 77 C.7. COSE Keys . . . . . . . . . . . . . . . . . . . . . . . . 78
C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 77 C.7.1. Public Keys . . . . . . . . . . . . . . . . . . . . . 78
C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 78 C.7.2. Private Keys . . . . . . . . . . . . . . . . . . . . 79
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 81
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
There has been an increased focus on small, constrained devices that There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT). One of the standards that has make up the Internet of Things (IoT). One of the standards that has
come out of this process is "Concise Binary Object Representation come out of this process is "Concise Binary Object Representation
(CBOR)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the (CBOR)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the
JavaScript Object Notation (JSON) [STD90] by allowing for binary JavaScript Object Notation (JSON) [STD90] by allowing for binary
data, among other changes. CBOR has been adopted by several of the data, among other changes. CBOR has been adopted by several of the
IETF working groups dealing with the IoT world as their encoding of IETF working groups dealing with the IoT world as their encoding of
skipping to change at page 38, line 13 skipping to change at page 38, line 13
into this taxonomy. into this taxonomy.
8.1. Signature Algorithms 8.1. Signature Algorithms
Signature algorithms provide data origination and data integrity Signature algorithms provide data origination and data integrity
services. Data origination provides the ability to infer who services. Data origination provides the ability to infer who
originated the data based on who signed the data. Data integrity originated the data based on who signed the data. Data integrity
provides the ability to verify that the data has not been modified provides the ability to verify that the data has not been modified
since it was signed. since it was signed.
There are two signature algorithm schemes. The first is signature There are two general signature algorithm schemes. The first is
with appendix. In this scheme, the message content is processed and signature with appendix. In this scheme, the message content is
a signature is produced; the signature is called the appendix. This processed and a signature is produced; the signature is called the
is the scheme used by algorithms such as ECDSA and the RSA appendix. This is the scheme used by algorithms such as ECDSA and
Probabilistic Signature Scheme (RSASSA-PSS). (In fact, the SSA in the RSA Probabilistic Signature Scheme (RSASSA-PSS). (In fact, the
RSASSA-PSS stands for Signature Scheme with Appendix.) SSA in RSASSA-PSS stands for Signature Scheme with Appendix.)
The signature functions for this scheme are: The signature functions for this scheme are:
signature = Sign(message content, key) signature = Sign(message content, key)
valid = Verification(message content, key, signature) valid = Verification(message content, key, signature)
The second scheme is signature with message recovery (an example of The second scheme is signature with message recovery (an example of
such an algorithm is [PVSig]). In this scheme, the message content such an algorithm is [PVSig]). In this scheme, the message content
is processed, but part of it is included in the signature. Moving is processed, but part of it is included in the signature. Moving
bytes of the message content into the signature allows for smaller bytes of the message content into the signature allows for smaller
signatures; the signature size is still potentially large, but the signatures; the signature size is still potentially large, but the
message content has shrunk. This has implications for systems message content has shrunk. This has implications for systems
implementing these algorithms and for applications that use them. implementing these algorithms and for applications that use them.
The first is that the message content is not fully available until The first is that the message content is not fully available until
after a signature has been validated. Until that point, the part of after a signature has been validated. Until that point, the part of
the message contained inside of the signature is unrecoverable. The the message contained inside of the signature is unrecoverable. The
second is that the security analysis of the strength of the signature second is that the security analysis of the strength of the signature
is very much based on the structure of the message content. Messages can be very much dependent on the structure of the message content.
that are highly predictable require additional randomness to be Finally, in the event that multiple signatures are applied to a
supplied as part of the signature process. In the worst case, it message, all of the signature algorithms are going to be required to
becomes the same as doing a signature with appendix. Finally, in the consume the same bytes of message content. This means that the
event that multiple signatures are applied to a message, all of the mixing of the signature with message recovery and signature with
signature algorithms are going to be required to consume the same appendix schemes in a single message is not supported, and if a
number of bytes of message content. This means that the mixing of recovery signature scheme is used.
the different schemes in a single message is not supported, and if a
recovery signature scheme is used, then the same amount of content
needs to be consumed by all of the signatures.
The signature functions for this scheme are: The signature functions for this scheme are:
signature, message sent = Sign(message content, key) signature, message sent = Sign(message content, key)
valid, message content = Verification(message sent, key, signature) valid, message content = Verification(message sent, key, signature)
No message recovery signature algorithms have been formally defined
for COSE yet, and given the new constraints arising from this
schemes, while some of these issues have already been identified
there is a high probability that additional issues will arise when
integrating message recovery signature algorithms. The first
algorithm defined is going to need to make decisions about these
issues and those decisions re likely to be binding on any further
algorithms defined.
We use the following terms below:
message content bytes: The byte provided by the application to be
signed.
to-be-signed bytes: The byte string passed into the signature
algorithm.
recovered bytes: The bytes recovered during the signature
verification process.
Some of the issue2 that have already been identified are:
* The to-be-signed bytes are not the same as the message content
bytes. This is because we build a larger to-be-signed message
during the signature processing. The recovered bytes length may
exceed the message content length, but not the length of the to-
be-signed bytes. This may lead to privacy considerations if, for
example, the externally supplied data contains confidential
information.
* There may be difficulties in determining where the recovered bytes
match up with the to-be-signed bytes, because the recovered bytes
contains data not in the message content bytes. One possible
option would be to create a padding scheme to prevent that.
* Not all message recovery signature algorithms take the recovered
bytes from the end of the to-be-signed bytes. This is a problem
because the message content bytes are at the end of the to-be-
signed bytes. If the bytes to be recovered are taken from the
start of the to-be-signed bytes then, by default, none of the
message content bytes may be included in the recovered bytes. One
possible option to deal with this is to reverse the to-be-signed
data in the event that recovered bytes are taken from the start
rather than end of the to-be-signed bytes.
Signature algorithms are used with the COSE_Signature and COSE_Sign1 Signature algorithms are used with the COSE_Signature and COSE_Sign1
structures. At this time, only signatures with appendixes are structures. At the time of this writing, only signatures with
defined for use with COSE; however, considerable interest has been appendixes are defined for use with COSE; however, considerable
expressed in using a signature with message recovery algorithm due to interest has been expressed in using a signature with message
the effective size reduction that is possible. Implementations will recovery algorithm due to the effective size reduction that is
need to keep this in mind for later possible integration. possible.
8.2. Message Authentication Code (MAC) Algorithms 8.2. Message Authentication Code (MAC) Algorithms
Message Authentication Codes (MACs) provide data authentication and Message Authentication Codes (MACs) provide data authentication and
integrity protection. They provide either no or very limited data integrity protection. They provide either no or very limited data
origination. A MAC, for example, cannot be used to prove the origination. A MAC, for example, cannot be used to prove the
identity of the sender to a third party. identity of the sender to a third party.
MACs use the same scheme as signature with appendix algorithms. The MACs use the same scheme as signature with appendix algorithms. The
message content is processed and an authentication code is produced. message content is processed and an authentication code is produced.
skipping to change at page 46, line 19 skipping to change at page 47, line 19
update the references to point to this document. update the references to point to this document.
11.1. COSE Header Parameters Registry 11.1. COSE Header Parameters Registry
IANA created a registry titled "COSE Header Parameters" as part of IANA created a registry titled "COSE Header Parameters" as part of
processing [RFC8152]. IANA is requested to update the reference for processing [RFC8152]. IANA is requested to update the reference for
all entries, except "counter signature" and "CounterSignature0", in all entries, except "counter signature" and "CounterSignature0", in
the table from [RFC8152] to this document. The reference for the table from [RFC8152] to this document. The reference for
"counter signature" and "CounterSignature0" are to be left alone. "counter signature" and "CounterSignature0" are to be left alone.
IANA is requested to update the pointer for expert rview to [[this
document]].
11.2. COSE Key Common Parameters Registry 11.2. COSE Key Common Parameters Registry
IANA created a registry titled "COSE Key Common Parameters" as part IANA created a registry titled "COSE Key Common Parameters" as part
of the processing of [RFC8152]. IANA is requested to update the of the processing of [RFC8152]. IANA is requested to update the
reference for entries in the table from [RFC8152] to this document. reference for entries in the table from [RFC8152] to this document.
IANA is requested to update the pointer for expert rview to [[this
document]].
11.3. Media Type Registrations 11.3. Media Type Registrations
11.3.1. COSE Security Message 11.3.1. COSE Security Message
This section registers the 'application/cose' media type in the This section registers the 'application/cose' media type in the
"Media Types" registry. These media types are used to indicate that "Media Types" registry. These media types are used to indicate that
the content is a COSE message. the content is a COSE message.
Type name: application Type name: application
skipping to change at page 49, line 45 skipping to change at page 50, line 38
Change Controller: IESG Change Controller: IESG
Provisional registration? No Provisional registration? No
11.4. CoAP Content-Formats Registry 11.4. CoAP Content-Formats Registry
IANA added entries to the "CoAP Content-Formats" registry while IANA added entries to the "CoAP Content-Formats" registry while
processing [RFC8152]. IANA is requested to update the reference processing [RFC8152]. IANA is requested to update the reference
value from [RFC8152] to [[This Document]]. value from [RFC8152] to [[This Document]].
11.5. Expert Review Instructions 11.5. CBOR Tags Registry
IANA is requested to update the references from [RFC8152] to [[This
Document]].
11.6. Expert Review Instructions
All of the IANA registries established by [RFC8152] are, at least in All of the IANA registries established by [RFC8152] are, at least in
part, defined as expert review. This section gives some general part, defined as expert review. This section gives some general
guidelines for what the experts should be looking for, but they are guidelines for what the experts should be looking for, but they are
being designated as experts for a reason, so they should be given being designated as experts for a reason, so they should be given
substantial latitude. substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
* Point squatting should be discouraged. Reviewers are encouraged * Point squatting should be discouraged. Reviewers are encouraged
skipping to change at page 55, line 8 skipping to change at page 56, line 8
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[I-D.ietf-cbor-7049bis] [I-D.ietf-cbor-7049bis]
Bormann, C. and P. Hoffman, "Concise Binary Object Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", Work in Progress, Internet-Draft, Representation (CBOR)", Work in Progress, Internet-Draft,
draft-ietf-cbor-7049bis-14, June 16, 2020, draft-ietf-cbor-7049bis-14, 16 June 2020,
<https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14>. <https://tools.ietf.org/html/draft-ietf-cbor-7049bis-14>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-11, July 1, 2020, draft-ietf-cose-rfc8152bis-algs-11, 1 July 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
algs-11>. algs-11>.
14.2. Informative References 14.2. Informative References
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
skipping to change at page 57, line 50 skipping to change at page 58, line 50
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <https://www.rfc-editor.org/info/rfc3394>. September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[I-D.ietf-cose-hash-algs] [I-D.ietf-cose-hash-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Hash Algorithms", Work in Progress, Internet-Draft, draft- Hash Algorithms", Work in Progress, Internet-Draft, draft-
ietf-cose-hash-algs-08, July 29, 2020, ietf-cose-hash-algs-09, 14 September 2020,
<https://tools.ietf.org/html/draft-ietf-cose-hash-algs- <https://tools.ietf.org/html/draft-ietf-cose-hash-algs-
08>. 09>.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
01, July 13, 2020, <https://tools.ietf.org/html/draft- 01, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-
ietf-core-groupcomm-bis-01>. core-groupcomm-bis-01>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[I-D.irtf-cfrg-argon2] [I-D.irtf-cfrg-argon2]
Biryukov, A., Dinu, D., Khovratovich, D., and S. Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "The memory-hard Argon2 password hash and Josefsson, "The memory-hard Argon2 password hash and
proof-of-work function", Work in Progress, Internet-Draft, proof-of-work function", Work in Progress, Internet-Draft,
draft-irtf-cfrg-argon2-11, July 9, 2020, draft-irtf-cfrg-argon2-12, 8 September 2020,
<https://tools.ietf.org/html/draft-irtf-cfrg-argon2-11>. <https://tools.ietf.org/html/draft-irtf-cfrg-argon2-12>.
[COAP.Formats] [COAP.Formats]
IANA, "CoAP Content-Formats", IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters/core- <https://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#content-formats>. parameters.xhtml#content-formats>.
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>. cose.xhtml#algorithms>.
 End of changes. 19 change blocks. 
96 lines changed or deleted 138 lines changed or added

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