rfc9053.original.xml   rfc9053.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!ENTITY SigSection "9.1"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<!ENTITY MacSection "9.2"> docName="draft-ietf-cose-rfc8152bis-algs-12" number="9053"
<!ENTITY ContentSection "9.3"> obsoletes="8152" submissionType="IETF" category="info" consensus="true"
<!ENTITY KDFSection "9.4"> tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en"
<!ENTITY CKeyDistributeSection "9.5"> version="3">
<!ENTITY DirectDistribute "9.5.1">
<!ENTITY KeyWrap "9.5.2">
]>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info
" docName="draft-ietf-cose-rfc8152bis-algs-11" obsoletes="8152" submissionType="
IETF" version="3" consensus="true">
<!-- xml2rfc v2v3 conversion 2.24.0 --> <!-- xml2rfc v2v3 conversion 2.24.0 -->
<front> <front>
<title abbrev="COSE Algorithms"> <title abbrev="COSE Algorithms">
CBOR Object Signing&nbsp;and&nbsp;Encryption&nbsp;(COSE): Initial Algorith ms CBOR Object Signing and Encryption (COSE): Initial Algorithms
</title> </title>
<seriesInfo name="Internet-Draft" value="draft-ietf-cose-rfc8152bis-algs-11" /> <seriesInfo name="RFC" value="9053"/>
<author initials="J." surname="Schaad" fullname="Jim Schaad"> <author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization>August Cellars</organization> <organization>August Cellars</organization>
<address> <address>
<email>ietf@augustcellars.com</email> <email>ietf@augustcellars.com</email>
</address> </address>
</author> </author>
<date/> <date year="2021" month="July" />
<area>Security</area> <area>Security</area>
<workgroup>COSE Working Group</workgroup> <workgroup>COSE Working Group</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the title)
for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t> <t>
Concise Binary Object Representation (CBOR) is a data format designed fo r small code size and small message size. Concise Binary Object Representation (CBOR) is a data format designed fo r small code size and small message size.
There is a need for the ability to have basic security services defined There is a need to be able to define basic security services for this da
for this data format. ta format.
THis document defines a set of algorithms that can be used with the CBOR This document defines a set of algorithms that can be used with the
Object Signing and Encryption (COSE) protocol RFC XXXX. <!-- <xref target="I-D. CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).
ietf-cose-rfc8152bis-struct"/>.-->
</t> </t>
</abstract> <!-- [rfced] Should the abstract include mention that it obsoletes RFC 8152? -->
<note removeInRFC="true">
<name>Contributing to this document</name> </abstract>
<!-- RFC EDITOR - Please remove this note before publishing -->
<t>
The source for this draft is being maintained in GitHub.
Suggested changes should be submitted as pull requests at <eref target=
"https://github.com/cose-wg/cose-rfc8152bis"/>.
Instructions are on that page as well.
Editorial changes can be managed in GitHub, but any substantial issues n
eed to be discussed on the COSE mailing list.
</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
There has been an increased focus on small, constrained devices that mak e up the Internet of Things (IoT). There has been an increased focus on small, constrained devices that mak e up the Internet of Things (IoT).
One of the standards that has come out of this process is "Concise Binar One of the standards that has come out of this process is "Concise
y Object Representation (CBOR)" <xref target="RFC7049"/>. Binary Object Representation (CBOR)" <xref target="RFC8949"/>.
CBOR extended the data model of JavaScript Object Notation (JSON) <xref CBOR extended the data model of JavaScript Object Notation (JSON)
target="STD90"/> by allowing for binary data, among other changes. <xref target="STD90"/> by allowing for binary data, among other
CBOR is being adopted by several of the IETF working groups dealing with changes.
the IoT world as their encoding of data structures. CBOR is being adopted by several of the IETF working groups dealing
CBOR was designed specifically to be both small in terms of messages tra with the IoT world as their method of encoding data structures.
nsported and implementation size and be a schema-free decoder. CBOR was designed specifically to be small in terms of both messages
A need exists to provide message security services for IoT, and using CB transported and implementation size and be a schema-free decoder.
OR as the message-encoding format makes sense. A need exists to provide message security services for IoT, and using
CBOR as the message-encoding format makes sense.
</t> </t>
<t> <t>
The core COSE specification consists of two documents. The core COSE specification consists of two documents.
<xref target="I-D.ietf-cose-rfc8152bis-struct"/> contains the serializat ion structures and the procedures for using the different cryptographic algorith ms. <xref target="RFC9052"/> contains the serialization structures and the p rocedures for using the different cryptographic algorithms.
This document provides an initial set of algorithms for use with those s tructures. This document provides an initial set of algorithms for use with those s tructures.
</t> </t>
<section anchor="requirements-terminology"> <section anchor="requirements-terminology">
<name>Requirements Terminology</name> <name>Requirements Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp1
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 4>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<
bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document a
re to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section> <section>
<name>Changes from RFC8152</name> <name>Changes from RFC 8152</name>
<ul> <ul>
<li> <li>
Extract the sections dealing with specific algorithms into this do Extracted the sections dealing with specific algorithms and place
cument. them into this document.
The sections dealing with structure and general processing rules a The sections dealing with structure and general processing rules
re placed in <xref target="I-D.ietf-cose-rfc8152bis-struct"/>. are placed in <xref target="RFC9052"/>.
</li> </li>
<li>Text clarifications and changes in terminology.</li> <li>Made text clarifications and changes in terminology.</li>
</ul> </ul>
</section> </section>
<section> <section>
<name>Document Terminology</name> <name>Document Terminology</name>
<t>In this document, we use the following terminology: </t> <t>In this document, we use the following terminology: </t>
<t>Byte is a synonym for octet.</t> <dl>
<t>Constrained Application Protocol (CoAP) is a specialized web transfer <dt>Byte:</dt><dd>A synonym for octet.</dd>
protocol for use in constrained systems. It is defined in <xref target="RFC725 <dt>Constrained Application Protocol (CoAP):</dt><dd>A specialized
2"/>. </t> web transfer protocol for use in constrained systems. It is defined
<t> in <xref target="RFC7252"/>.</dd>
Authenticated Encryption (AE) <xref target="RFC5116"/> algorithms are <dt>Authenticated Encryption (AE) algorithms <xref target="RFC5116"/>:
encryption algorithms that provide an authentication check of the contents with </dt><dd>Encryption algorithms that provide an
the encryption service. authentication check of the contents with the encryption service.
An example of an AE algorithm used in COSE is AES Key Wrap <xref targe t="RFC3394"/>. An example of an AE algorithm used in COSE is AES Key Wrap <xref targe t="RFC3394"/>.
These algorithms are used for key encryption algorithms, but AEAD algo These algorithms are used for key encryption algorithms, but
rithms would be preferred. Authenticated Encryption with Associated Data (AEAD)
</t> algorithms would be preferred.
<t> </dd>
Authenticated Encryption with Associated Data (AEAD) <xref target="RFC <dt>AEAD algorithms <xref
5116"/> algorithms provide the same authentication service of the content as AE target="RFC5116"/>:</dt><dd>Provide the same authentication service of
algorithms do. the content as AE algorithms do. They also allow
They also allow for associated data to be included in the authenticati associated data that is not part of the encrypted body to be included
on service, but which is not part of the encrypted body. in the authentication service. An example of an AEAD
An example of an AEAD algorithm used in COSE is AES-GCM <xref target=" algorithm used in COSE is AES-GCM <xref target="RFC5116"/>. These
RFC5116"/>. algorithms are used for content encryption and can be used for key
These algorithms are used for content encryption and can be used for k encryption as well.
ey encryption as well. </dd>
</t> </dl>
<t>The term 'byte string' is used for sequences of bytes, while the term <t>The term "byte string" is used for sequences of bytes, while the term
'text string' is used for sequences of characters.</t> "text string" is used for sequences of characters.</t>
<t> <t>
The tables for algorithms contain the following columns: The tables for algorithms contain the following columns:
</t> </t>
<ul> <ul>
<li>A name for use in documents for the algorithms.</li> <li>A name for the algorithms for use in documents.</li>
<li> <li>
The value used on the wire for the algorithm. The value used on the wire for the algorithm.
One place this is used is the algorithm header parameter of a messag e. One place this is used is the algorithm header parameter of a messag e.
</li> </li>
<li>A short description so that the algorithm can be easily identified when scanning the IANA registry.</li> <li>A short description so that the algorithm can be easily identified when scanning the IANA registry.</li>
</ul> </ul>
<t> <t>
Additional columns may be present in the table depending on the algori Additional columns may be present in a table depending on the
thms. algorithms.
</t> </t>
</section> </section>
<section> <section>
<name>CBOR Grammar</name> <name>CBOR Grammar</name>
<t> <t>
At the time that <xref target="RFC8152"/> was initially published, the <!--[rfced] According to RFC 8610 (cited below), the correct expansion for
CBOR Data Definition Language (CDDL) <xref target="RFC8610"/> had not yet been CDDL is "Concise Data Definition Language"; we have updated the text accordingly
published. .
This document uses a variant of CDDL which is described in <xref targe
t="I-D.ietf-cose-rfc8152bis-struct"/>. Original:
At the time that [RFC8152] was initially published, the CBOR Data
Definition Language (CDDL) [RFC8610] had not yet been published.
-->
At the time that <xref target="RFC8152"/> was initially published,
the CBOR Data Definition Language (CDDL) <xref target="RFC8610"/>
had not yet been published.
This document uses a variant of CDDL that is described in <xref target
="RFC9052"/>.
</t> </t>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<t> <t>
A GitHub project has been created at <xref target="GitHub-Examples"/> A GitHub project has been created at <xref
that contains a set of testing examples as well. target="GitHub-Examples"/> that contains a set of testing examples
as well.
Each example is found in a JSON file that contains the inputs used to create the example, some of the intermediate values that can be used for debuggi ng, and the output of the example. Each example is found in a JSON file that contains the inputs used to create the example, some of the intermediate values that can be used for debuggi ng, and the output of the example.
The results are encoded using both hexadecimal and CBOR diagnostic not The results are encoded using both hexadecimal and
ation format. CBOR diagnostic notation format.
</t> </t>
<t> <t>
Some of the examples are designed to test failure case; these are clea Some of the examples are designed to test the failure case; these
rly marked as such in the JSON file. are clearly marked as such in the JSON file.
If errors in the examples in this document are found, the examples on If errors in the examples in this document are found, the examples
GitHub will be updated, and a note to that effect will be placed in the JSON fil on GitHub will be updated, and a note to that effect will be placed
e. in the JSON file.
</t> </t>
</section> </section>
</section> </section>
<section anchor="SigAlgs"> <section anchor="SigAlgs">
<name>Signature Algorithms</name> <name>Signature Algorithms</name>
<t> <t>
<relref section="&SigSection;" target="I-D.ietf-cose-rfc8152bis-struct"/ <!--[rfced] 1) The first sentence below cites a section that does not exist in
> contains a generic description of signature algorithms. the cited document. We have updated the text to refer to Section 8.1. Please l
et us know if this is incorrect.
2) In the second sentence, does "the document" refer to
ietf-cose-rfc8152bis-struct or this document?
Original:
Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic
description of signature algorithms. The document defines signature
algorithm identifiers for two signature algorithms.
-->
<xref section="8.1" target="RFC9052"/> contains a generic description of
signature algorithms.
The document defines signature algorithm identifiers for two signature a lgorithms. The document defines signature algorithm identifiers for two signature a lgorithms.
</t> </t>
<section anchor="ECDSA"> <section anchor="ECDSA">
<name>ECDSA</name> <name>ECDSA</name>
<t>ECDSA <xref target="DSS"/> defines a signature algorithm using ECC.
Implementations <bcp14>SHOULD</bcp14> use a deterministic version of ECDSA such <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) <xref
as the one defined in <xref target="RFC6979"/>. The use of a deterministic sign target="DSS"/> defines a signature algorithm using Elliptic Curve Cryptog
ature algorithm allows for systems to avoid relying on random number generators raphy (ECC).
in order to avoid generating the same value of 'k' (the per-message random value Implementations <bcp14>SHOULD</bcp14> use a deterministic version of
). Biased generation of the value 'k' can be attacked, and collisions of this va ECDSA such as the one defined in <xref target="RFC6979"/>. The use of
lue leads to leaked keys. It additionally allows for doing deterministic tests a deterministic signature algorithm allows systems to avoid relying on
for the signature algorithm. The use of deterministic ECDSA does not lessen the random number generators in order to avoid generating the same value
need to have good random number generation when creating the private key. </t> of "k" (the per-message random value). Biased generation of the value
<t>The ECDSA signature algorithm is parameterized with a hash function ( "k" can be attacked, and collisions of this value lead to leaked
h). In the event that the length of the hash function output is greater than th keys. It additionally allows performing deterministic tests for the
e group of the key, the leftmost bytes of the hash output are used. </t> signature algorithm. The use of deterministic ECDSA does not lessen
the need to have good random number generation when creating the
private key. </t>
<t>The ECDSA signature algorithm is parameterized with a hash function
(h). In the event that the length of the hash function output is
greater than the group of the key, the leftmost bytes of the hash
output are used. </t>
<t>The algorithms defined in this document can be found in <xref target= "x-table_ecdsa"/>. </t> <t>The algorithms defined in this document can be found in <xref target= "x-table_ecdsa"/>. </t>
<table anchor="x-table_ecdsa" align="center"> <table anchor="x-table_ecdsa" align="center">
<name>ECDSA Algorithm Values</name> <name>ECDSA Algorithm Values</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Hash</th> <th>Hash</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>ES256</td> <td>ES256</td>
<td>-7</td> <td align="center">-7</td>
<td>SHA-256</td> <td>SHA-256</td>
<td>ECDSA w/ SHA-256</td> <td>ECDSA w/ SHA-256</td>
</tr> </tr>
<tr> <tr>
<td>ES384</td> <td>ES384</td>
<td>-35</td> <td align="center">-35</td>
<td>SHA-384</td> <td>SHA-384</td>
<td>ECDSA w/ SHA-384</td> <td>ECDSA w/ SHA-384</td>
</tr> </tr>
<tr> <tr>
<td>ES512</td> <td>ES512</td>
<td>-36</td> <td align="center">-36</td>
<td>SHA-512</td> <td>SHA-512</td>
<td>ECDSA w/ SHA-512</td> <td>ECDSA w/ SHA-512</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>This document defines ECDSA to work only with the curves P-256, P-384 <!--[rfced] In the following sentence, should another "only" be inserted to
, and P-521. This document requires that the curves be encoded using the 'EC2' match the first two statements?
(two coordinate elliptic curve) key type. Implementations need to check that th
e key type and curve are correct when creating and verifying a signature. Futur Original:
e documents may define it to work with other curves and points in the future. < In order to promote interoperability, it is suggested that SHA-256 be
/t> used only with curve P-256, SHA-384 be used only with curve P-384,
<t>In order to promote interoperability, it is suggested that SHA-256 be and SHA-512 be used with curve P-521.
used only with curve P-256, SHA-384 be used only with curve P-384, and SHA-512
be used with curve P-521. This is aligned with the recommendation in Section 4 Perhaps:
of <xref target="RFC5480"/>. </t> ... and SHA-512 be used only with curve P-521.
-->
<t>This document defines ECDSA as working only with the curves P-256,
P-384, and P-521. This document requires that the curves be encoded
using the "EC2" (two coordinate elliptic curve) key type.
Implementations need to check that the key type and curve are correct
when creating and verifying a signature. Future documents may define
it to work with other curves and points in the future. </t>
<t>In order to promote interoperability, it is suggested that SHA-256 be
used only with curve P-256, SHA-384 be used only with curve P-384, and SHA-512
be used with curve P-521. This is aligned with the recommendation in <xref targ
et="RFC5480" section="4" sectionFormat="of"/>. </t>
<t> <t>
The signature algorithm results in a pair of integers (R, S). The signature algorithm results in a pair of integers (R, S).
These integers will be the same length as the length of the key used f or the signature process. These integers will be the same length as the length of the key used f or the signature process.
The signature is encoded by converting the integers into byte strings of the same length as the key size. The signature is encoded by converting the integers into byte strings of the same length as the key size.
The length is rounded up to the nearest byte and is left padded with z ero bits to get to the correct length. The length is rounded up to the nearest byte and is left padded with z ero bits to get to the correct length.
The two integers are then concatenated together to form a byte string that is the resulting signature. The two integers are then concatenated together to form a byte string that is the resulting signature.
</t> </t>
<t> <t>
Using the function defined in <xref target="RFC8017"/>, the signature is: Using the function defined in <xref target="RFC8017"/>, the signature is:
</t> </t>
skipping to change at line 218 skipping to change at line 284
Signature = I2OSP(R, n) | I2OSP(S, n) Signature = I2OSP(R, n) | I2OSP(S, n)
</t> </t>
<t> <t>
where n = ceiling(key_length / 8) where n = ceiling(key_length / 8)
</t> </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'EC2'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "EC2".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the EC DSA signature algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the EC DSA signature algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'sign' when creating an ECDSA signature.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "sign" when creating an ECDSA signature.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'verify' when verifying an ECDSA signature.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "verify" when verifying an ECDSA signature.</li>
</ul> </ul>
<section> <section>
<name>Security Considerations for ECDSA</name> <name>Security Considerations for ECDSA</name>
<t>The security strength of the signature is no greater than the minim um of the security strength associated with the bit length of the key and the se curity strength of the hash function. </t> <t>The security strength of the signature is no greater than the minim um of the security strength associated with the bit length of the key and the se curity strength of the hash function. </t>
<t> <t>
Note: Use of a deterministic signature technique is a good idea even Note: Use of a deterministic signature technique is a good idea
when good random number generation exists. even when good random number generation exists.
Doing so both reduces the possibility of having the same value of 'k Doing so both reduces the possibility of having the same value of
' in two signature operations and allows for reproducible signature values, whic "k" in two signature operations and allows for reproducible
h helps testing. signature values, which helps testing.
There have been recent attacks involving faulting the device in orde There have been recent attacks involving faulting the device in
r to extract the key. order to extract the key.
This can be addressed by combining both randomness and determinism This can be addressed by combining both randomness and determinism
<xref target="I-D.mattsson-cfrg-det-sigs-with-noise"/>. <xref target="I-D.mattsson-cfrg-det-sigs-with-noise"/>.
</t> </t>
<t>There are two substitution attacks that can theoretically be mounte d against the ECDSA signature algorithm. <t>There are two substitution attacks that can theoretically be mounte d against the ECDSA signature algorithm.
</t> </t>
<ul> <ul>
<li>Changing the curve used to validate the signature: If one change <li>Changing the curve used to validate the signature: If one
s the curve used to validate the signature, then potentially one could have two changes the curve used to validate the signature, then potentially
messages with the same signature, each computed under a different curve. The on one could have two messages with the same signature, each computed
ly requirement on the new curve is that its order be the same as the old one and under a different curve. The only requirements on the new curve are
it be acceptable to the client. An example would be to change from using the c that its order be the same as the old one and that it be acceptable t
urve secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit curves.) We cu o
rrently do not have any way to deal with this version of the attack except to re the client. An example would be to change from using the curve
strict the overall set of curves that can be used. </li> secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit
curves.) We currently do not have any way to deal with this
version of the attack except to restrict the overall set of curves
that can be used. </li>
<li>Change the hash function used to validate the signature: If one <li>Changing the hash function used to validate the signature: If
either has two different hash functions of the same length or can truncate a has one either has two different hash functions of the same length or
h function, then one could potentially find collisions between the hash function can truncate a hash function, then one could potentially find
s rather than within a single hash function (for example, truncating SHA-512 to collisions between the hash functions rather than within a single
256 bits might collide with a SHA-256 bit hash value). As the hash algorithm is hash function. For example, truncating SHA-512 to 256 bits might
part of the signature algorithm identifier, this attack is mitigated by includin collide with a SHA-256 bit hash value. As the hash algorithm is
g a signature algorithm identifier in the protected header bucket. </li> part of the signature algorithm identifier, this attack is
mitigated by including a signature algorithm identifier in the
protected-header bucket. </li>
</ul> </ul>
</section> </section>
</section> </section>
<section> <section>
<name>Edwards-Curve Digital Signature Algorithms (EdDSAs)</name> <name>Edwards-Curve Digital Signature Algorithms (EdDSAs)</name>
<t><xref target="RFC8032"/> describes the elliptic curve signature schem <t><xref target="RFC8032"/> describes the elliptic curve signature
e Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the sign scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that
ature algorithm is instantiated using parameters for edwards25519 and edwards448 document, the signature algorithm is instantiated using parameters for
curves. The document additionally describes two variants of the EdDSA algorith edwards25519 and edwards448 curves. The document additionally
m: Pure EdDSA, where no hash function is applied to the content before signing, describes two variants of the EdDSA algorithm: Pure EdDSA, where no
and HashEdDSA, where a hash function is applied to the content before signing an hash function is applied to the content before signing, and HashEdDSA,
d the result of that hash function is signed. For EdDSA, the content to be sign where a hash function is applied to the content before signing and the
ed (either the message or the pre-hash value) is processed twice inside of the s result of that hash function is signed. For EdDSA, the content to be
ignature algorithm. For use with COSE, only the pure EdDSA version is used. Th signed (either the message or the prehash value) is processed twice
is is because it is not expected that extremely large contents are going to be n inside of the signature algorithm. For use with COSE, only the pure
eeded and, based on the arrangement of the message structure, the entire message EdDSA version is used. This is because it is not expected that
is going to need to be held in memory in order to create or verify a signature. extremely large contents are going to be needed and, based on the
This means that there does not appear to be a need to be able to do block upda arrangement of the message structure, the entire message is going to
tes of the hash, followed by eliminating the message from memory. Applications need to be held in memory in order to create or verify a signature.
can provide the same features by defining the content of the message as a hash v Therefore, there does not appear to be a need to be able to do
alue and transporting the COSE object (with the hash value) and the content as s block updates of the hash, followed by eliminating the message from
eparate items. </t> memory. Applications can provide the same features by defining the
<t>The algorithms defined in this document can be found in <xref target= content of the message as a hash value and transporting the COSE
"x-table-eddsa-algs"/>. A single signature algorithm is defined, which can be u object (with the hash value) and the content as separate items. </t>
sed for multiple curves. </t> <t>The algorithm defined in this document can be found in <xref target="
x-table-eddsa-algs"/>. A single signature algorithm is defined, which can be us
ed for multiple curves. </t>
<table anchor="x-table-eddsa-algs" align="center"> <table anchor="x-table-eddsa-algs" align="center">
<name>EdDSA Algorithm Values</name> <name>EdDSA Algorithm Value</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>EdDSA</td> <td>EdDSA</td>
<td>-8</td> <td align="center">-8</td>
<td>EdDSA</td> <td>EdDSA</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t><xref target="RFC8032"/> describes the method of encoding the signatu re value. </t> <t><xref target="RFC8032"/> describes the method of encoding the signatu re value. </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'OKP' (Octet Key Pair). </li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "OKP" (Octet Key Pair). </li>
<li>The 'crv' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be a curve defined for this signature algorithm.</li> <li>The "crv" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be a curve defined for this signature algorithm.</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match 'EdDSA '.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match "EdDSA ".</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'sign' when creating an EdDSA signature.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "sign" when creating an EdDSA signature.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'verify' when verifying an EdDSA signature.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "verify" when verifying an EdDSA signature.</li>
</ul> </ul>
<section> <section>
<!--[rfced] What is "the other algorithm" mentioned in the following sentence?
Original:
How public values are computed is not the same when looking at EdDSA
and Elliptic Curve Diffie-Hellman (ECDH); for this reason, the public
key should not be used with the other algorithm.
-->
<name>Security Considerations for EdDSA</name> <name>Security Considerations for EdDSA</name>
<t>How public values are computed is not the same when looking at EdDS <t>Public values are computed differently in EdDSA and Elliptic Curve
A and Elliptic Curve Diffie-Hellman (ECDH); for this reason, the public key shou Diffie-Hellman (ECDH); for this reason, the public key should not be
ld not be used with the other algorithm. </t> used with the other algorithm. </t>
<t>If batch signature verification is performed, a well-seeded cryptog <t>If batch signature verification is performed, a well-seeded
raphic random number generator is <bcp14>REQUIRED</bcp14> (<relref target="RFC80 cryptographic random number generator is <bcp14>REQUIRED</bcp14>
32" section="8.2"/>). Signing and non-batch signature verification are determin (<xref target="RFC8032" section="8.2"/>). Signing and nonbatch
istic operations and do not need random numbers of any kind. </t> signature verification are deterministic operations and do not need
random numbers of any kind. </t>
</section> </section>
</section> </section>
</section> </section>
<section> <section>
<name>Message Authentication Code (MAC) Algorithms</name> <name>Message Authentication Code (MAC) Algorithms</name>
<t> <t>
<relref section="&MacSection;" target="I-D.ietf-cose-rfc8152bis-struct"/ <!--[rfced] The following sentence cites a section that does not exist in the
> contains a generic description of MAC algorithms. cited document. We have updated the text to refer to Section 8.2. Please let us
know if this is incorrect.
Original:
Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic
description of MAC algorithms.
-->
<xref section="9.2" target="RFC9052"/> contains a generic description
of MAC algorithms.
This section defines the conventions for two MAC algorithms. This section defines the conventions for two MAC algorithms.
</t> </t>
<section> <section>
<name>Hash-Based Message Authentication Codes (HMACs)</name> <name>Hash-Based Message Authentication Codes (HMACs)</name>
<t>HMAC <xref target="RFC2104"/> <xref target="RFC4231"/> was designed t <t>HMAC <xref target="RFC2104"/> <xref target="RFC4231"/> was designed
o deal with length extension attacks. The algorithm was also designed to allow to deal with length extension attacks. The algorithm was also
for new hash algorithms to be directly plugged in without changes to the hash fu designed to allow new hash algorithms to be directly plugged in
nction. The HMAC design process has been shown as solid since, while the securi without changes to the hash function. The HMAC design process has
ty of hash algorithms such as MD5 has decreased over time; the security of HMAC been shown to be solid; although the security of hash algorithms such
combined with MD5 has not yet been shown to be compromised <xref target="RFC6151 as MD5 has decreased over time, the security of HMAC combined with MD5
"/>. </t> has not yet been shown to be compromised <xref target="RFC6151"/>.
<t>The HMAC algorithm is parameterized by an inner and outer padding, a </t>
hash function (h), and an authentication tag value length. For this specificati <t>The HMAC algorithm is parameterized by an inner and outer padding,
on, the inner and outer padding are fixed to the values set in <xref target="RFC a hash function (h), and an authentication tag value length. For this
2104"/>. The length of the authentication tag corresponds to the difficulty of specification, the inner and outer padding are fixed to the values set
producing a forgery. For use in constrained environments, we define one HMAC al in <xref target="RFC2104"/>. The length of the authentication tag
gorithm that is truncated. There are currently no known issues with truncation; corresponds to the difficulty of producing a forgery. For use in
however, the security strength of the message tag is correspondingly reduced in constrained environments, we define one HMAC algorithm that is
strength. When truncating, the leftmost tag length bits are kept and transmitt truncated. There are currently no known issues with truncation;
ed. </t> however, the security strength of the message tag is correspondingly
reduced in strength. When truncating, the leftmost tag-length bits
are kept and transmitted. </t>
<t>The algorithms defined in this document can be found in <xref target= "x-table-hmac"/>. </t> <t>The algorithms defined in this document can be found in <xref target= "x-table-hmac"/>. </t>
<table anchor="x-table-hmac" align="center"> <table anchor="x-table-hmac" align="center">
<name>HMAC Algorithm Values</name> <name>HMAC Algorithm Values</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Hash</th> <th>Hash</th>
<th>Tag Length</th> <th align="center">Tag Length</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>HMAC 256/64</td> <td>HMAC 256/64</td>
<td>4</td> <td align="center">4</td>
<td>SHA-256</td> <td>SHA-256</td>
<td>64</td> <td align="center">64</td>
<td>HMAC w/ SHA-256 truncated to 64 bits</td> <td>HMAC w/ SHA-256 truncated to 64 bits</td>
</tr> </tr>
<tr> <tr>
<td>HMAC 256/256</td> <td>HMAC 256/256</td>
<td>5</td> <td align="center">5</td>
<td>SHA-256</td> <td>SHA-256</td>
<td>256</td> <td align="center">256</td>
<td>HMAC w/ SHA-256</td> <td>HMAC w/ SHA-256</td>
</tr> </tr>
<tr> <tr>
<td>HMAC 384/384</td> <td>HMAC 384/384</td>
<td>6</td> <td align="center">6</td>
<td>SHA-384</td> <td>SHA-384</td>
<td>384</td> <td align="center">384</td>
<td>HMAC w/ SHA-384</td> <td>HMAC w/ SHA-384</td>
</tr> </tr>
<tr> <tr>
<td>HMAC 512/512</td> <td>HMAC 512/512</td>
<td>7</td> <td align="center">7</td>
<td>SHA-512</td> <td>SHA-512</td>
<td>512</td> <td align="center">512</td>
<td>HMAC w/ SHA-512</td> <td>HMAC w/ SHA-512</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Some recipient algorithms transport the key, while others derive a ke y from secret data. For those algorithms that transport the key (such as AES Ke y Wrap), the size of the HMAC key <bcp14>SHOULD</bcp14> be the same size as the output of the underlying hash function. For those algorithms that derive the k ey (such as ECDH), the derived key <bcp14>MUST</bcp14> be the same size as the u nderlying hash function. </t> <t>Some recipient algorithms transport the key, while others derive a ke y from secret data. For those algorithms that transport the key (such as AES Ke y Wrap), the size of the HMAC key <bcp14>SHOULD</bcp14> be the same size as the output of the underlying hash function. For those algorithms that derive the k ey (such as ECDH), the derived key <bcp14>MUST</bcp14> be the same size as the u nderlying hash function. </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "Symmetric".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the HM AC algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the HM AC algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'MAC create' when creating an HMAC authentication tag.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "MAC create" when creating an HMAC authentication tag.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'MAC verify' when verifying an HMAC authentication tag.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "MAC verify" when verifying an HMAC authentication tag.</li>
</ul> </ul>
<t>Implementations creating and validating MAC values <bcp14>MUST</bcp14 > validate that the key type, key length, and algorithm are correct and appropri ate for the entities involved. </t> <t>Implementations creating and validating MAC values <bcp14>MUST</bcp14 > validate that the key type, key length, and algorithm are correct and appropri ate for the entities involved. </t>
<section> <section>
<name>Security Considerations for HMAC</name> <name>Security Considerations for HMAC</name>
<t>HMAC has proved to be resistant to attack even when used with weake ned hash algorithms. The current best known attack is to brute force the key. This means that key size is going to be directly related to the security of an H MAC operation. </t> <t>HMAC has proved to be resistant to attack even when used with weake ned hash algorithms. The current best known attack is to brute force the key. This means that key size is going to be directly related to the security of an H MAC operation. </t>
</section> </section>
</section> </section>
<section> <section>
<name>AES Message Authentication Code (AES-CBC-MAC)</name> <name>AES Message Authentication Code (AES-CBC-MAC)</name>
<t>AES-CBC-MAC is defined in <xref target="MAC"/>. (Note that this is n <!-- [rfced] Sections 3.2 and subsequent: Are "AES-CBC-MAC" and "AES-MAC"
ot the same algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC) interchangeable terms? (We also see "CBC-MAC" as defined in RFC 3610; is
<xref target="RFC4493"/>.) </t> this also interchangeable with the other terms?) Please let us know if any
<t>AES-CBC-MAC is parameterized by the key length, the authentication ta clarifications are needed for readers; if yes, maybe an update to the first
g length, and the Initialization Vector (IV) used. For all of these algorithms, paragraph of Section 3.2?
the IV is fixed to all zeros. We provide an array of algorithms for various ke
y lengths and tag lengths. The algorithms defined in this document are found in Original (Section 3.2):
<xref target="x-table-aes-mac"/>. </t> AES-CBC-MAC is defined in [MAC]. (Note that this is not the same
algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC)
[RFC4493].)
Possibly (assuming that the three terms are interchangeable):
AES-CBC-MAC (also referred to here as "AES-MAC" or CBC-MAC (Section 3.2.1))
is defined in [MAC]. (Note that this is not the same algorithm
as AES Cipher-Based Message Authentication Code (AES-CMAC)
[RFC4493].) -->
<t>AES-CBC-MAC is defined in <xref target="MAC"/>. (Note that this is
not the same algorithm as AES Cipher-Based Message Authentication Code
(AES-CMAC) <xref target="RFC4493"/>.) </t>
<t>AES-CBC-MAC is parameterized by the key length, the
authentication tag length, and the Initialization Vector (IV) used.
For all of these algorithms, the IV is fixed to all zeros. We provide
an array of algorithms for various key and tag lengths. The
algorithms defined in this document are found in <xref
target="x-table-aes-mac"/>. </t>
<table anchor="x-table-aes-mac" align="center"> <table anchor="x-table-aes-mac" align="center">
<name>AES-MAC Algorithm Values</name> <name>AES-MAC Algorithm Values</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Key Length</th> <th align="center">Key Length</th>
<th>Tag Length</th> <th align="center">Tag Length</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>AES-MAC 128/64</td> <td>AES-MAC 128/64</td>
<td>14</td> <td align="center">14</td>
<td>128</td> <td align="center">128</td>
<td>64</td> <td align="center">64</td>
<td>AES-MAC 128-bit key, 64-bit tag</td> <td>AES-MAC 128-bit key, 64-bit tag</td>
</tr> </tr>
<tr> <tr>
<td>AES-MAC 256/64</td> <td>AES-MAC 256/64</td>
<td>15</td> <td align="center">15</td>
<td>256</td> <td align="center">256</td>
<td>64</td> <td align="center">64</td>
<td>AES-MAC 256-bit key, 64-bit tag</td> <td>AES-MAC 256-bit key, 64-bit tag</td>
</tr> </tr>
<tr> <tr>
<td>AES-MAC 128/128</td> <td>AES-MAC 128/128</td>
<td>25</td> <td align="center">25</td>
<td>128</td> <td align="center">128</td>
<td>128</td> <td align="center">128</td>
<td>AES-MAC 128-bit key, 128-bit tag</td> <td>AES-MAC 128-bit key, 128-bit tag</td>
</tr> </tr>
<tr> <tr>
<td>AES-MAC 256/128</td> <td>AES-MAC 256/128</td>
<td>26</td> <td align="center">26</td>
<td>256</td> <td align="center">256</td>
<td>128</td> <td align="center">128</td>
<td>AES-MAC 256-bit key, 128-bit tag</td> <td>AES-MAC 256-bit key, 128-bit tag</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Keys may be obtained either from a key structure or from a recipient <t>Keys may be obtained from either a key structure or a
structure. Implementations creating and validating MAC values <bcp14>MUST</bcp1 recipient structure. Implementations creating and validating MAC
4> validate that the key type, key length, and algorithm are correct and appropr values <bcp14>MUST</bcp14> validate that the key type, key length, and
iate for the entities involved. </t> algorithm are correct and appropriate for the entities involved. </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "Symmetric".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the AE S-MAC algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the AE S-MAC algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'MAC create' when creating an AES-MAC authentication tag.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "MAC create" when creating an AES-MAC authentication tag.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'MAC verify' when verifying an AES-MAC authentication tag.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "MAC verify" when verifying an AES-MAC authentication tag.</li>
</ul> </ul>
<section> <section>
<name>Security Considerations AES-CBC_MAC </name> <name>Security Considerations for AES-CBC-MAC </name>
<!-- [rfced] We have updated the section title for 3.2.1 as shown below. Please
let us know if any corrections are needed.
Original (note the underscore):
3.2.1. Security Considerations AES-CBC_MAC
Current:
3.2.1. Security Considerations for AES-CBC-MAC
-->
<t>A number of attacks exist against Cipher Block Chaining Message Aut hentication Code (CBC-MAC) that need to be considered. <t>A number of attacks exist against Cipher Block Chaining Message Aut hentication Code (CBC-MAC) that need to be considered.
</t> </t>
<ul> <ul>
<li>A single key must only be used for messages of a fixed or known <li>A single key must only be used for messages of a fixed or
length. If this is not the case, an attacker will be able to generate a message known length. If this is not the case, an attacker will be able
with a valid tag given two message and tag pairs. This can be addressed by usi to generate a message with a valid tag given two
ng different keys for messages of different lengths. message and tag pairs. This can be addressed by using different
keys for
The current structure mitigates this problem, as a specific encoding structure messages of different lengths. The current structure mitigates
that includes lengths is built and signed. (CMAC also addresses this issue.) </ this problem, as a specific encoding structure that includes
li> lengths is built and signed. (CMAC also addresses this issue.)
</li>
<li>In cipher Block Chaining (CBC) mode, if the same key is used for <li>In Cipher Block Chaining (CBC) mode, if the same key is used
both encryption and authentication operations, an attacker can produce messages for both encryption and authentication operations, an attacker can
with a valid authentication code. </li> produce messages with a valid authentication code. </li>
<li>If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros. </li> <li>If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros. </li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<section> <section>
<name>Content Encryption Algorithms</name> <name>Content Encryption Algorithms</name>
<t> <t>
<relref section="&ContentSection;" target="I-D.ietf-cose-rfc8152bis-stru
ct"/> contains a generic description of Content Encryption algorithms. <!--[rfced] The following sentence cites a section that does not exist in the
This document defines the identifier and usages for three content encryp cited document. updated to refer to 8.3
tion algorithms.
Original:
Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic
description of Content Encryption algorithms.
-->
<xref section="9.3" target="RFC9052"/> contains a generic description
of content encryption algorithms.
This document defines the identifier and usages for three
content encryption algorithms.
</t> </t>
<section> <section>
<name>AES GCM</name> <name>AES-GCM</name>
<t>The Galois/Counter Mode (GCM) mode is a generic AEAD block cipher mod <!-- [rfced] Note that we have removed "mode" when it appeared after GCM because
e defined in <xref target="AES-GCM"/>. The GCM mode is combined with the AES bl M stands for mode (i.e., it reads as "Galois/Counter Mode mode"). Please let u
ock encryption algorithm to define an AEAD cipher. </t> s know any objections.
<t>The GCM mode is parameterized by the size of the authentication tag a -->
nd the size of the nonce. This document fixes the size of the nonce at 96 bits.
The size of the authentication tag is limited to a small set of values. For t <t>The Galois/Counter Mode (GCM) is a generic AEAD block cipher
his document however, the size of the authentication tag is fixed at 128 bits. mode defined in <xref target="AES-GCM"/>. The GCM is combined
</t> with the AES block encryption algorithm to define an AEAD cipher.
<t>The set of algorithms defined in this document are in <xref target="x </t>
-table-AES-GCM"/>. </t> <t>The GCM is parameterized by the size of the authentication tag
and the size of the nonce. This document fixes the size of the nonce
at 96 bits. The size of the authentication tag is limited to a small
set of values. For this document, however, the size of the
authentication tag is fixed at 128 bits. </t>
<t>The set of algorithms defined in this document is in <xref
target="x-table-AES-GCM"/>. </t>
<table anchor="x-table-AES-GCM" align="center"> <table anchor="x-table-AES-GCM" align="center">
<name>Algorithm Value for AES-GCM</name> <name>Algorithm Values for AES-GCM</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>A128GCM</td> <td>A128GCM</td>
<td>1</td> <td align="center">1</td>
<td>AES-GCM mode w/ 128-bit key, 128-bit tag</td> <td>AES-GCM w/ 128-bit key, 128-bit tag</td>
</tr> </tr>
<tr> <tr>
<td>A192GCM</td> <td>A192GCM</td>
<td>2</td> <td align="center">2</td>
<td>AES-GCM mode w/ 192-bit key, 128-bit tag</td> <td>AES-GCM w/ 192-bit key, 128-bit tag</td>
</tr> </tr>
<tr> <tr>
<td>A256GCM</td> <td>A256GCM</td>
<td>3</td> <td align="center">3</td>
<td>AES-GCM mode w/ 256-bit key, 128-bit tag</td> <td>AES-GCM w/ 256-bit key, 128-bit tag</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Keys may be obtained either from a key structure or from a recipient <t>Keys may be obtained from either a key structure or a recipient
structure. Implementations encrypting and decrypting <bcp14>MUST</bcp14> valida structure. Implementations that are encrypting and decrypting
te that the key type, key length, and algorithm are correct and appropriate for <bcp14>MUST</bcp14> validate that the key type, key length, and
the entities involved. </t> algorithm are correct and appropriate for the entities involved. </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "Symmetric".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the AE S-GCM algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the AE S-GCM algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'encrypt' or 'wrap key' when encrypting.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "encrypt" or "wrap key" when encrypting.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'decrypt' or 'unwrap key' when decrypting.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "decrypt" or "unwrap key" when decrypting.</li>
</ul> </ul>
<section> <section>
<name>Security Considerations for AES-GCM</name> <name>Security Considerations for AES-GCM</name>
<t>When using AES-GCM, the following restrictions <bcp14>MUST</bcp14> be enforced: <t>When using AES-GCM, the following restrictions <bcp14>MUST</bcp14> be enforced:
</t> </t>
<ul> <ul>
<li>The key and nonce pair <bcp14>MUST</bcp14> be unique for every m <li>The key and nonce pair <bcp14>MUST</bcp14> be unique for every
essage encrypted. </li> message encrypted. </li>
<!-- [rfced] For clarity, we suggest the following updates:
Original from Section 4.1.1:
* The total number of messages encrypted for a single key MUST NOT
exceed 2^32 [SP800-38d]. An explicit check is required only in
environments where it is expected that it might be exceeded.
Original from Section 4.2.1:
This limitation is the sum of times the
block cipher is used in computing the MAC value and in performing
stream encryption operations. An explicit check is required only
in environments where it is expected that it might be exceeded.
Perhaps:
... An explicit check is required only in
environments where this limitation might be exceeded.
-->
<li>The total number of messages encrypted for a single key
<bcp14>MUST NOT</bcp14> exceed 2<sup>32</sup> <xref target="SP800-38D
"/>.
An explicit check is required only in environments where it is expect
ed that it might be exceeded. </li>
<li>The total number of messages encrypted for a single key <bcp14>M UST NOT</bcp14> exceed 2^32 <xref target="SP800-38d"/>. An explicit check is re quired only in environments where it is expected that it might be exceeded. </l i>
<li> <li>
A more recent analysis in <xref target="ROBUST"/> indicates that t A more recent analysis in <xref target="ROBUST"/> indicates that
he the number of failed decryptions needs to be taken into account as part deter the number of failed decryptions needs to be taken into account
mining when a key roll-over is to be done. as part of determining when a key rollover is to be done.
Following the recommendation of for DTLS, the number of failed mes <!--[rfced] There seems to be a word missing in the sentence below. Whose
sage decryptions should be limited to 2^36. recommendation is being followed; should a reference be added? Note that this t
ext appears more than once.
Original:
Following the recommendation of for DTLS, the number of failed message
decryptions should be limited to 2^36.
-->
Following the recommendation of for DTLS, the number of failed
message decryptions should be limited to 2<sup>36</sup>.
</li> </li>
</ul> </ul>
<t>Consideration was given to supporting smaller tag values; the const <t>Consideration was given to supporting smaller tag values; the
rained community would desire tag sizes in the 64-bit range. Doing so drasticall constrained community would desire tag sizes in the 64-bit
y changes both the maximum messages size (generally not an issue) and the number range. Such use drastically changes both the maximum message size
of times that a key can be used. Given that Counter with CBC-MAC (CCM) is the (generally not an issue) and the number of times that a key can be
usual mode for constrained environments, restricted modes are not supported. </ used. Given that Counter with CBC-MAC (CCM) is the usual mode for
t> constrained environments, restricted modes are not supported. </t>
</section> </section>
</section> </section>
<section> <section>
<name>AES CCM</name> <name>AES-CCM</name>
<t>CCM is a generic authentication encryption block cipher mode defined <t>CCM is a generic authentication encryption block cipher mode
in <xref target="RFC3610"/>. The CCM mode is combined with the AES block encryp defined in <xref target="RFC3610"/>. The CCM mode is combined with
tion algorithm to define a commonly used content encryption algorithm used in co the AES block encryption algorithm to define a commonly used
nstrained devices. </t> content encryption algorithm used in constrained devices. </t>
<t>The CCM mode has two parameter choices. The first choice is M, the s <t>CCM mode has two parameter choices. The first choice is M, the
ize of the authentication field. The choice of the value for M involves a trade size of the authentication field. The choice of the value for M
-off between message growth (from the tag) and the probability that an attacker involves a trade-off between message growth (from the tag) and the
can undetectably modify a message. The second choice is L, the size of the leng probability that an attacker can undetectably modify a message. The
th field. This value requires a trade-off between the maximum message size and second choice is L, the size of the length field. This value requires
the size of the Nonce. </t> a trade-off between the maximum message size and the size of the
nonce. </t>
<t>It is unfortunate that the specification for CCM specified L and M as a count of bytes rather than a count of bits. This leads to possible misunders tandings where AES-CCM-8 is frequently used to refer to a version of CCM mode wh ere the size of the authentication is 64 bits and not 8 bits. These values have traditionally been specified as bit counts rather than byte counts. This docum ent will follow the convention of using bit counts so that it is easier to compa re the different algorithms presented in this document. </t> <t>It is unfortunate that the specification for CCM specified L and M as a count of bytes rather than a count of bits. This leads to possible misunders tandings where AES-CCM-8 is frequently used to refer to a version of CCM mode wh ere the size of the authentication is 64 bits and not 8 bits. These values have traditionally been specified as bit counts rather than byte counts. This docum ent will follow the convention of using bit counts so that it is easier to compa re the different algorithms presented in this document. </t>
<t>We define a matrix of algorithms in this document over the values of L and M. Constrained devices are usually operating in situations where they use short messages and want to avoid doing recipient-specific cryptographic operati ons. This favors smaller values of both L and M. Less-constrained devices will want to be able to use larger messages and are more willing to generate new key s for every operation. This favors larger values of L and M. </t> <t>We define a matrix of algorithms in this document over the values of L and M. Constrained devices are usually operating in situations where they use short messages and want to avoid doing recipient-specific cryptographic operati ons. This favors smaller values of both L and M. Less-constrained devices will want to be able to use larger messages and are more willing to generate new key s for every operation. This favors larger values of L and M. </t>
<t>The following values are used for L: <t>The following values are used for L:
</t> </t>
<dl newline="false"> <dl newline="false">
<dt>16 bits (2):</dt> <dt>16 bits (2):</dt>
<dd>This limits messages to 2<sup>16</sup> bytes (64 KiB) in length.
This is sufficiently long for messages in the constrained world.
The nonce length is 13 bytes allowing for 2<sup>104</sup> possible valu
es of
the nonce without repeating. </dd>
<dd>This limits messages to 2^16 bytes (64 KiB) in length. This is su fficiently long for messages in the constrained world. The nonce length is 13 b ytes allowing for 2^104 possible values of the nonce without repeating. </dd>
<dt>64 bits (8):</dt> <dt>64 bits (8):</dt>
<dd>This limits messages to 2<sup>64</sup> bytes in length. The
<dd>This limits messages to 2^64 bytes in length. The nonce length is nonce length is 7 bytes, allowing for 2<sup>56</sup> possible values of
7 bytes allowing for 2^56 possible values of the nonce without repeating. </dd the nonce without repeating. </dd>
>
</dl> </dl>
<t>The following values are used for M: <t>The following values are used for M:
</t> </t>
<dl newline="false"> <dl newline="false">
<dt>64 bits (8):</dt> <dt>64 bits (8):</dt>
<dd>This produces a 64-bit authentication tag. This implies that
there is a 1 in 2<sup>64</sup> chance that a modified message will
authenticate.</dd>
<dd>This produces a 64-bit authentication tag. This implies that ther e is a 1 in 2^64 chance that a modified message will authenticate. </dd>
<dt>128 bits (16):</dt> <dt>128 bits (16):</dt>
<dd>This produces a 128-bit authentication tag. This implies that
<dd>This produces a 128-bit authentication tag. This implies that the there is a 1 in 2<sup>128</sup> chance that a modified message will
re is a 1 in 2^128 chance that a modified message will authenticate. </dd> authenticate.</dd>
</dl> </dl>
<table anchor="x-table-AES-CCM" align="center"> <table anchor="x-table-AES-CCM" align="center">
<name>Algorithm Values for AES-CCM</name> <name>Algorithm Values for AES-CCM</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>L</th> <th>L</th>
<th>M</th> <th>M</th>
<th>Key Length</th> <th align="center">Key Length</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>AES-CCM-16-64-128</td> <td>AES-CCM-16-64-128</td>
<td>10</td> <td align="center">10</td>
<td>16</td> <td>16</td>
<td>64</td> <td>64</td>
<td>128</td> <td align="center">128</td>
<td>AES-CCM mode 128-bit key, 64-bit tag, 13-byte nonce</td> <td>AES-CCM mode 128-bit key, 64-bit tag, 13-byte nonce</td>
</tr> </tr>
<tr> <tr>
<td>AES-CCM-16-64-256</td> <td>AES-CCM-16-64-256</td>
<td>11</td> <td align="center">11</td>
<td>16</td> <td>16</td>
<td>64</td> <td>64</td>
<td>256</td> <td align="center">256</td>
<td>AES-CCM mode 256-bit key, 64-bit tag, 13-byte nonce</td> <td>AES-CCM mode 256-bit key, 64-bit tag, 13-byte nonce</td>
</tr> </tr>
<tr> <tr>
<td>AES-CCM-64-64-128</td> <td>AES-CCM-64-64-128</td>
<td>12</td> <td align="center">12</td>
<td>64</td> <td>64</td>
<td>64</td> <td>64</td>
<td>128</td> <td align="center">128</td>
<td>AES-CCM mode 128-bit key, 64-bit tag, 7-byte nonce</td> <td>AES-CCM mode 128-bit key, 64-bit tag, 7-byte nonce</td>
</tr> </tr>
<tr> <tr>
<td>AES-CCM-64-64-256</td> <td>AES-CCM-64-64-256</td>
<td>13</td> <td align="center">13</td>
<td>64</td> <td>64</td>
<td>64</td> <td>64</td>
<td>256</td> <td align="center">256</td>
<td>AES-CCM mode 256-bit key, 64-bit tag, 7-byte nonce</td> <td>AES-CCM mode 256-bit key, 64-bit tag, 7-byte nonce</td>
</tr> </tr>
<tr> <tr>
<td>AES-CCM-16-128-128</td> <td>AES-CCM-16-128-128</td>
<td>30</td> <td align="center">30</td>
<td>16</td> <td>16</td>
<td>128</td> <td>128</td>
<td>128</td> <td align="center">128</td>
<td>AES-CCM mode 128-bit key, 128-bit tag, 13-byte nonce</td> <td>AES-CCM mode 128-bit key, 128-bit tag, 13-byte nonce</td>
</tr> </tr>
<tr> <tr>
<td>AES-CCM-16-128-256</td> <td>AES-CCM-16-128-256</td>
<td>31</td> <td align="center">31</td>
<td>16</td> <td>16</td>
<td>128</td> <td>128</td>
<td>256</td> <td align="center">256</td>
<td>AES-CCM mode 256-bit key, 128-bit tag, 13-byte nonce</td> <td>AES-CCM mode 256-bit key, 128-bit tag, 13-byte nonce</td>
</tr> </tr>
<tr> <tr>
<td>AES-CCM-64-128-128</td> <td>AES-CCM-64-128-128</td>
<td>32</td> <td align="center">32</td>
<td>64</td> <td>64</td>
<td>128</td> <td>128</td>
<td>128</td> <td align="center">128</td>
<td>AES-CCM mode 128-bit key, 128-bit tag, 7-byte nonce</td> <td>AES-CCM mode 128-bit key, 128-bit tag, 7-byte nonce</td>
</tr> </tr>
<tr> <tr>
<td>AES-CCM-64-128-256</td> <td>AES-CCM-64-128-256</td>
<td>33</td> <td align="center">33</td>
<td>64</td> <td>64</td>
<td>128</td> <td>128</td>
<td>256</td> <td align="center">256</td>
<td>AES-CCM mode 256-bit key, 128-bit tag, 7-byte nonce</td> <td>AES-CCM mode 256-bit key, 128-bit tag, 7-byte nonce</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Keys may be obtained either from a key structure or from a recipient <t>Keys may be obtained from either a key structure or a recipient
structure. Implementations encrypting and decrypting <bcp14>MUST</bcp14> valida structure. Implementations that are encrypting and decrypting
te that the key type, key length, and algorithm are correct and appropriate for <bcp14>MUST</bcp14> validate that the key type, key length, and
the entities involved. </t> algorithm are correct and appropriate for the entities involved. </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "Symmetric".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the AE S-CCM algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the AE S-CCM algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'encrypt' or 'wrap key' when encrypting.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "encrypt" or "wrap key" when encrypting.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'decrypt' or 'unwrap key' when decrypting.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "decrypt" or "unwrap key" when decrypting.</li>
</ul> </ul>
<section> <section>
<name>Security Considerations for AES-CCM</name> <name>Security Considerations for AES-CCM</name>
<t>When using AES-CCM, the following restrictions <bcp14>MUST</bcp14> be enforced: <t>When using AES-CCM, the following restrictions <bcp14>MUST</bcp14> be enforced:
</t> </t>
<ul> <ul>
<li>The key and nonce pair <bcp14>MUST</bcp14> be unique for every m essage encrypted. Note that the value of L influences the number of unique nonce s. </li> <li>The key and nonce pair <bcp14>MUST</bcp14> be unique for every m essage encrypted. Note that the value of L influences the number of unique nonce s. </li>
<li>The total number of times the AES block cipher is used <bcp14>MU <li>The total number of times the AES block cipher is used
ST NOT</bcp14> exceed 2^61 operations. This limitation is the sum of times the <bcp14>MUST NOT</bcp14> exceed 2<sup>61</sup> operations. This
block cipher is used in computing the MAC value and in performing stream encrypt limitation is the sum of times the block cipher is used in
ion operations. An explicit check is required only in environments where it is computing the MAC value and performing stream encryption
expected that it might be exceeded. </li> operations. An explicit check is required only in environments
where it is expected that this number might be exceeded. </li>
<li> <li>
<xref target="I-D.ietf-quic-tls"/> contains an analysis on the use <xref target="RFC9001"/> contains an analysis on the
of AES-CCM in that environment. use of AES-CCM in that environment.
Based on that reommendation, one should restrict the number of mes Based on that recommendation, one should restrict the number of
sages encrypted to 2^23. messages encrypted to 2<sup>23</sup>.
If one is using the 64-bit tag, then the limits are signficantly s If one is using the 64-bit tag, then the limits are significantly
maller if one wants to keep the same integrity limits. smaller if one wants to keep the same integrity limits.
A protocol recommending this needs to analysis what level of integ A protocol recommending this needs to analyze what level of integr
rity is acceptable for the smaller tag size. ity is acceptable for the smaller tag size.
It may be that to keep the desired integrity one needs to re-key a It may be that, to keep the desired integrity, one needs to rekey
s often as every 2^7 messages. as often as every 2<sup>7</sup> messages.
</li> </li>
<li> <li>
In addition to the number of messages successfully decrypted, the number of failed decryptions needs to be kept as well. In addition to the number of messages successfully decrypted, the number of failed decryptions needs to be kept as well.
If the number of failed decryptions exceeds 2^23 then a rekeying o If the number of failed decryptions exceeds 2<sup>23</sup>, then
peration should occur. a rekeying operation should occur.
</li> </li>
</ul> </ul>
<t><xref target="RFC3610"/> additionally calls out one other considera <t><xref target="RFC3610"/> additionally calls out one other
tion of note. It is possible to do a pre-computation attack against the algorit consideration of note. It is possible to do a precomputation
hm in cases where portions of the plaintext are highly predictable. This reduc attack against the algorithm in cases where portions of the
es the security of the key size by half. Ways to deal with this attack include plaintext are highly predictable. This reduces the security of the
adding a random portion to the nonce value and/or increasing the key size used. key size by half. Ways to deal with this attack include adding a
Using a portion of the nonce for a random value will decrease the number of mes random portion to the nonce value and/or increasing the key size
sages that a single key can be used for. Increasing the key size may require mo used. Using a portion of the nonce for a random value will decrease
re resources in the constrained device. See Sections 5 and 10 of <xref target=" the number of messages that a single key can be used for.
RFC3610"/> for more information. </t> Increasing the key size may require more resources in the
constrained device. See Sections <xref target="RFC3610" section="5"
sectionFormat="bare"/> and <xref target="RFC3610" section="10"
sectionFormat="bare"/> of <xref target="RFC3610"/> for more
information. </t>
</section> </section>
</section> </section>
<section> <section>
<name>ChaCha20 and Poly1305</name> <name>ChaCha20 and Poly1305</name>
<t>ChaCha20 and Poly1305 combined together is an AEAD mode that is defin ed in <xref target="RFC8439"/>. This is an algorithm defined to be a cipher tha t is not AES and thus would not suffer from any future weaknesses found in AES. These cryptographic functions are designed to be fast in software-only implemen tations. </t> <t>ChaCha20 and Poly1305 combined together is an AEAD mode that is defin ed in <xref target="RFC8439"/>. This is an algorithm defined to be a cipher tha t is not AES and thus would not suffer from any future weaknesses found in AES. These cryptographic functions are designed to be fast in software-only implemen tations. </t>
<t>The ChaCha20/Poly1305 AEAD construction defined in <xref target="RFC8 <t>The ChaCha20/Poly1305 AEAD construction defined in <xref
439"/> has no parameterization. It takes a 256-bit key and a 96-bit nonce, as w target="RFC8439"/> has no parameterization. It takes as inputs a
ell as the plaintext and additional data as inputs and produces the ciphertext a 256-bit key and a 96-bit nonce, as well as the plaintext and
s an option. We define one algorithm identifier for this algorithm in <xref tar additional data, and produces the ciphertext as an option. We define
get="x-table-CHACHA"/>. </t> one algorithm identifier for this algorithm in <xref
target="x-table-CHACHA"/>. </t>
<table anchor="x-table-CHACHA" align="center"> <table anchor="x-table-CHACHA" align="center">
<name>Algorithm Value for ChaCha20/Poly1305</name> <name>Algorithm Value for ChaCha20/Poly1305</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>ChaCha20/Poly1305</td> <td>ChaCha20/Poly1305</td>
<td>24</td> <td align="center">24</td>
<td>ChaCha20/Poly1305 w/ 256-bit key, 128-bit tag</td> <td>ChaCha20/Poly1305 w/ 256-bit key, 128-bit tag</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Keys may be obtained either from a key structure or from a recipient <t>Keys may be obtained from either a key structure or a recipient
structure. Implementations encrypting and decrypting <bcp14>MUST</bcp14> valida structure. Implementations that are encrypting and decrypting
te that the key type, key length, and algorithm are correct and appropriate for <bcp14>MUST</bcp14> validate that the key type, key length, and
the entities involved. </t> algorithm are correct and appropriate for the entities involved. </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "Symmetric".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the Ch aCha20/Poly1305 algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the Ch aCha20/Poly1305 algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'encrypt' or 'wrap key' when encrypting.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "encrypt" or "wrap key" when encrypting.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'decrypt' or 'unwrap key' when decrypting.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "decrypt" or "unwrap key" when decrypting.</li>
</ul> </ul>
<section> <section>
<name>Security Considerations for ChaCha20/Poly1305</name> <name>Security Considerations for ChaCha20/Poly1305</name>
<t>The key and nonce values <bcp14>MUST</bcp14> be a unique pair for e very invocation of the algorithm. Nonce counters are considered to be an accept able way of ensuring that they are unique. </t> <t>The key and nonce values <bcp14>MUST</bcp14> be a unique pair for e very invocation of the algorithm. Nonce counters are considered to be an accept able way of ensuring that they are unique. </t>
<t>
A more recent analysis in <xref target="ROBUST"/> indicates that t <t>A more recent analysis in <xref target="ROBUST"/> indicates that
he the number of failed decryptions needs to be taken into account as part deter the number of failed decryptions needs to be taken into account as
mining when a key roll-over is to be done. part of determining when a key rollover is to be done. Following the
Following the recommendation of for DTLS, the number of failed mes recommendation of for DTLS, the number of failed message decryptions
sage decryptions should be limited to 2^36. should be limited to 2<sup>36</sup>.
</t> </t>
<t> <t>
<xref target="I-D.ietf-quic-tls"/> recommends that no more than 2^ <xref target="RFC9001"/> recommends that no more than
24.5 messages be encrypted under a single key. 2<sup>24.5</sup> messages be encrypted under a single key.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section> <section>
<name>Key Derivation Functions (KDFs)</name> <name>Key Derivation Functions (KDFs)</name>
<t> <t>
<relref section="&KDFSection;" target="I-D.ietf-cose-rfc8152bis-struct"/ <!--[rfced] The following sentence cites a section that does not exist in the
> contains a generic description of Key Derivation Functions. cited document. We have updated this section to point to 8.4. Please let us kno
w if this is incorrect.
Original:
Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic
description of Key Derivation Functions.
-->
<xref section="9.4" target="RFC9052"/> contains a generic description
of key derivation functions.
This document defines a single context structure and a single KDF. This document defines a single context structure and a single KDF.
These elements are used for all of the recipient algorithms defined in t These elements are used for all of the recipient algorithms defined in
his document that require a KDF process. this document that require a KDF process.
These algorithms are defined in Sections <xref target="direct-kdf" forma These algorithms are defined in Sections <xref target="direct-kdf"
t="counter"/>, <xref target="ECDH" format="counter"/>, and <xref target="ECDH-wr format="counter"/>, <xref target="ECDH" format="counter"/>, and <xref
ap" format="counter"/>. target="ECDH-wrap" format="counter"/>.
</t> </t>
<section anchor="HKDF-section"> <section anchor="HKDF-section">
<name>HMAC-Based Extract-and-Expand Key Derivation Function (HKDF)</name > <name>HMAC-Based Extract-and-Expand Key Derivation Function (HKDF)</name >
<t>The HKDF key derivation algorithm is defined in <xref target="RFC5869
"/><xref target="HKDF"/>. </t>
<t>The HKDF algorithm takes these inputs:
</t>
<ul empty="true"> <t>The HKDF key derivation algorithm is defined in <xref
target="RFC5869"/> and <xref target="HKDF"/>. </t>
<li>secret -- a shared value that is secret. Secrets may be either pr eviously shared or derived from operations like a Diffie-Hellman (DH) key agreem ent. </li> <t>The HKDF algorithm takes these inputs:</t>
<li>salt -- an optional value that is used to change the generation pr <dl>
ocess. The salt value can be either public or private. If the salt is public a <dt>secret:</dt><dd> A shared value that is secret. Secrets may be
nd carried in the message, then the 'salt' algorithm header parameter defined in either previously shared or derived from operations like a
<xref target="HKDF_Alg_Params"/> is used. While <xref target="RFC5869"/> sugge Diffie-Hellman (DH) key agreement. </dd>
sts that the length of the salt be the same as the length of the underlying hash
value, any positive salt length will improve the security as different key valu
es will be generated. This parameter is protected by being included in the key
computation and does not need to be separately authenticated. The salt value do
es not need to be unique for every message sent. </li>
<li>length -- the number of bytes of output that need to be generated. <dt>salt:</dt><dd> An optional value that is used to change the
</li> generation process. The salt value can be either public or private.
If the salt is public and carried in the message, then the "salt"
algorithm header parameter defined in <xref
target="HKDF_Alg_Params"/> is used. While <xref target="RFC5869"/>
suggests that the length of the salt be the same as the length of
the underlying hash value, any positive salt length will improve the
security, as different key values will be generated. This parameter
is protected by being included in the key computation and does not
need to be separately authenticated. The salt value does not need
to be unique for every message sent. </dd>
<li>context information -- Information that describes the context in w hich the resulting value will be used. Making this information specific to the context in which the material is going to be used ensures that the resulting mat erial will always be tied to that usage. The context structure defined in <xref target="context"/> is used by the KDFs in this document. </li> <dt>length:</dt><dd>The number of bytes of output that need to be gene rated. </dd>
<li>PRF -- The underlying pseudorandom function to be used in the HKDF <dt>context information:</dt><dd>Information that describes the
algorithm. The PRF is encoded into the HKDF algorithm selection. </li> context in which the resulting value will be used. Making this
</ul> information specific to the context in which the material is going
<t>HKDF is defined to use HMAC as the underlying PRF. However, it is po to be used ensures that the resulting material will always be tied
ssible to use other functions in the same construct to provide a different KDF t to that usage. The context structure defined in <xref
hat is more appropriate in the constrained world. Specifically, one can use AES target="context"/> is used by the KDFs in this document. </dd>
-CBC-MAC as the PRF for the expand step, but not for the extract step. When usi
ng a good random shared secret of the correct length, the extract step can be sk <dt>PRF:</dt><dd> The underlying pseudorandom function to be used in
ipped. For the AES algorithm versions, the extract step is always skipped. </t the HKDF algorithm. The PRF is encoded into the HKDF algorithm
> selection. </dd>
<t>The extract step cannot be skipped if the secret is not uniformly ran </dl>
dom, for example, if it is the result of an ECDH key agreement step. This implie
s that the AES HKDF version cannot be used with ECDH. If the extract step is ski <t>HKDF is defined to use HMAC as the underlying PRF. However, it is
pped, the 'salt' value is not used as part of the HKDF functionality. </t> possible to use other functions in the same construct to provide a
different KDF that is more appropriate in the constrained world.
Specifically, one can use AES-CBC-MAC as the PRF for the expand step,
but not for the extract step. When using a good random shared secret
of the correct length, the extract step can be skipped. For the AES
algorithm versions, the extract step is always skipped. </t>
<t>The extract step cannot be skipped if the secret is not uniformly
random -- for example, if it is the result of an ECDH key agreement
step. This implies that the AES HKDF version cannot be used with
ECDH. If the extract step is skipped, the "salt" value is not used as
part of the HKDF functionality. </t>
<t>The algorithms defined in this document are found in <xref target="x- table-hkdf"/>. </t> <t>The algorithms defined in this document are found in <xref target="x- table-hkdf"/>. </t>
<table anchor="x-table-hkdf" align="center"> <table anchor="x-table-hkdf" align="center">
<name>HKDF Algorithms</name> <name>HKDF Algorithms</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>PRF</th> <th>PRF</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
skipping to change at line 794 skipping to change at line 1135
</tr> </tr>
<tr> <tr>
<td>HKDF AES-MAC-256</td> <td>HKDF AES-MAC-256</td>
<td>AES-CBC-MAC-256</td> <td>AES-CBC-MAC-256</td>
<td>HKDF using AES-MAC as the PRF w/ 256-bit key</td> <td>HKDF using AES-MAC as the PRF w/ 256-bit key</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<table anchor="HKDF_Alg_Params" align="center"> <table anchor="HKDF_Alg_Params" align="center">
<name>HKDF Algorithm Parameters</name> <!-- [rfced] Table 9: Because this table deals with one algorithm
parameter - the "salt" parameter - we have updated the title so that
it does not indicate more than one parameter.
Original:
Table 9: HKDF Algorithm Parameters
Current:
Table 9: HKDF Algorithm Header Parameter -->
<name>HKDF Algorithm Parameter</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Label</th> <th>Label</th>
<th>Type</th> <th>Type</th>
<th>Algorithm</th> <th>Algorithm</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 818 skipping to change at line 1169
<td>bstr</td> <td>bstr</td>
<td>direct+HKDF-SHA-256, direct+HKDF-SHA-512, direct+HKDF-AES-128, direct+HKDF-AES-256, ECDH-ES+HKDF-256, ECDH-ES+HKDF-512, ECDH-SS+HKDF-256, ECDH -SS+HKDF-512, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW, ECDH-SS+A128KW, EC DH-SS+A192KW, ECDH-SS+A256KW </td> <td>direct+HKDF-SHA-256, direct+HKDF-SHA-512, direct+HKDF-AES-128, direct+HKDF-AES-256, ECDH-ES+HKDF-256, ECDH-ES+HKDF-512, ECDH-SS+HKDF-256, ECDH -SS+HKDF-512, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW, ECDH-SS+A128KW, EC DH-SS+A192KW, ECDH-SS+A256KW </td>
<td>Random salt</td> <td>Random salt</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="context"> <section anchor="context">
<name>Context Information Structure</name> <name>Context Information Structure</name>
<t>The context information structure is used to ensure that the derived <t>The context information structure is used to ensure that the
keying material is "bound" to the context of the transaction. The context infor derived keying material is "bound" to the context of the transaction.
mation structure used here is based on that defined in <xref target="SP800-56A"/ The context information structure used here is based on that defined
>. By using CBOR for the encoding of the context information structure, we auto in <xref target="SP800-56A"/>. By using CBOR for the encoding of the
matically get the same type and length separation of fields that is obtained by context information structure, we automatically get the same type and
the use of ASN.1. This means that there is no need to encode the lengths for th length separation of fields that is obtained by the use of ASN.1.
e base elements, as it is done by the encoding used in JOSE (Section 4.6.2 of <x <!--[rfced] JOSE doesn't seem to be discussed in the cited section. Please
ref target="RFC7518"/>). </t> review the citation for accuracy.
<t>The context information structure refers to PartyU and PartyV as the
two parties that are doing the key derivation. Unless the application protocol Original:
defines differently, we assign PartyU to the entity that is creating the message This means that there is no need to encode the lengths for the base
and PartyV to the entity that is receiving the message. By doing this associat elements, as it is done by the encoding used in JOSE (Section 4.6.2
ion, different keys will be derived for each direction as the context informatio of [RFC7518]).
n is different in each direction. </t> -->
This means that there is no need to encode the lengths for the base
elements, as it is done by the encoding used in JSON Object Signing
and Encryption (JOSE) (<xref target="RFC7518" section="4.6.2"
sectionFormat="of"/>).</t>
<!-- [rfced] Please consider whether instances of "Party U" and "Party V" should
be "PartyU" and "PartyV" thoughout. If the intent is to use "Party V" and "Par
ty U" (with spaces) in general text, some updates may be needed.
-->
<t>The context information structure refers to PartyU and PartyV as
the two parties that are doing the key derivation. Unless the
application protocol defines differently, we assign PartyU to the
entity that is creating the message and PartyV to the entity that is
receiving the message. By defining this association, different keys
will be derived for each direction, as the context information is
different in each direction.</t>
<t>The context structure is built from information that is known to both entities. This information can be obtained from a variety of sources: <t>The context structure is built from information that is known to both entities. This information can be obtained from a variety of sources:
</t> </t>
<ul> <ul>
<li>Fields can be defined by the application. This is commonly used t o assign fixed names to parties, but it can be used for other items such as nonc es. </li> <li>Fields can be defined by the application. This is commonly used t o assign fixed names to parties, but it can be used for other items such as nonc es. </li>
<li>Fields can be defined by usage of the output. Examples of this ar e the algorithm and key size that are being generated. </li> <li>Fields can be defined by usage of the output. Examples of this ar e the algorithm and key size that are being generated. </li>
<li>Fields can be defined by parameters from the message. We define a <li>Fields can be defined by parameters from the message. We define
set of header parameters in <xref target="KDF_Context_Alg_Params"/> that can be a set of header parameters in <xref
used to carry the values associated with the context structure. Examples of th target="KDF_Context_Alg_Params"/> that can be used to carry the
is are identities and nonce values. These header parameters are designed to be values associated with the context structure. Examples of this are
placed in the unprotected bucket of the recipient structure; they do not need to identities and nonce values. These header parameters are designed
be in the protected bucket since they already are included in the cryptographic to be placed in the unprotected bucket of the recipient structure;
computation by virtue of being included in the context structure. </li> they do not need to be in the protected bucket, since they are already
included in the cryptographic computation by virtue of being
included in the context structure. </li>
</ul> </ul>
<table anchor="KDF_Context_Alg_Params" align="center"> <table anchor="KDF_Context_Alg_Params" align="center">
<name>Context Algorithm Parameters</name> <name>Context Algorithm Parameters</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Label</th> <th>Label</th>
<th>Type</th> <th>Type</th>
<th>Algorithm</th> <th>Algorithm</th>
skipping to change at line 895 skipping to change at line 1280
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>We define a CBOR object to hold the context information. This object is referred to as COSE_KDF_Context. The object is based on a CBOR array type. The fields in the array are: <t>We define a CBOR object to hold the context information. This object is referred to as COSE_KDF_Context. The object is based on a CBOR array type. The fields in the array are:
</t> </t>
<dl newline="false"> <dl newline="false">
<dt>AlgorithmID:</dt> <dt>AlgorithmID:</dt>
<dd> <dd>
This field indicates the algorithm for which the key material will b e used. This field indicates the algorithm for which the key material will b e used.
This normally is either a key wrap algorithm identifier or a content This normally is either a key wrap algorithm identifier or a
encryption algorithm identifier. content encryption algorithm identifier.
The values are from the "COSE Algorithms" registry. The values are from the "COSE Algorithms" registry.
This field is required to be present. This field is required to be present.
The field exists in the context information so that a different key is generated for each algorithm even of all of the other context information is the same. The field exists in the context information so that a different key is generated for each algorithm even if all of the other context information is the same.
In practice, this means if algorithm A is broken and thus finding th e key is relatively easy, the key derived for algorithm B will not be the same a s the key derived for algorithm A. In practice, this means if algorithm A is broken and thus finding th e key is relatively easy, the key derived for algorithm B will not be the same a s the key derived for algorithm A.
</dd> </dd>
<dt>PartyUInfo:</dt> <dt>PartyUInfo:</dt>
<dd> <dd>
<t>This field holds information about party U. The PartyUInfo is en <t>This field holds information about PartyU. The PartyUInfo is
coded as a CBOR array. The elements of PartyUInfo are encoded in the order pres encoded as a CBOR array. The elements of PartyUInfo are encoded
ented below. The elements of the PartyUInfo array are: in the order presented below. The elements of the PartyUInfo
array are:
</t> </t>
<dl newline="false"> <dl newline="false">
<dt>identity:</dt> <dt>identity:</dt>
<dd> <dd>
<t>This contains the identity information for party U. The iden <t>This contains the identity information for PartyU. The
tities can be assigned in one of two manners. First, a protocol can assign iden identities can be assigned in one of two manners. First, a
tities based on roles. For example, the roles of "client" and "server" may be a protocol can assign identities based on roles. For example,
ssigned to different entities in the protocol. Each entity would then use the c the roles of "client" and "server" may be assigned to
orrect label for the data they send or receive. The second way for a protocol t different entities in the protocol. Each entity would then
o assign identities is to use a name based on a naming system (i.e., DNS, X.509 use the correct label for the data it sends or receives. The
names). second way for a protocol to assign identities is to use a
name based on a naming system (i.e., DNS or X.509 names).
</t> </t>
<t> We define an algorithm parameter 'PartyU identity' that can <t> We define an algorithm parameter, "PartyU identity", that
be used to carry identity information in the message. However, identity informa can be used to carry identity information in the message.
tion is often known as part of the protocol and can thus be inferred rather than However, identity information is often known to be part of the
made explicit. If identity information is carried in the message, applications protocol and can thus be inferred rather than made explicit.
<bcp14>SHOULD</bcp14> have a way of validating the supplied identity informatio If identity information is carried in the message,
n. The identity information does not need to be specified and is set to nil in applications <bcp14>SHOULD</bcp14> have a way of validating
that case. </t> the supplied identity information. The identity information
does not need to be specified and is set to nil in that case.
</t>
</dd> </dd>
<dt>nonce:</dt> <dt>nonce:</dt>
<dd> <dd>
<t>This contains a nonce value. The nonce can either be implici <t>This contains a nonce value. The nonce can be either
t from the protocol or be carried as a value in the unprotected header bucket. implicit from the protocol or carried as a value in the
unprotected header bucket.
</t> </t>
<t> We define an algorithm parameter 'PartyU nonce' that can be <!-- [rfced] Assuming that "the nonce value" and "the value" mean the same thing
used to carry this value in the message; however, the nonce value could be deter , should "and" be "or" here (i.e., the nonce value could be determined by the ap
mined by the application and the value determined from elsewhere. plication or the value determined from elsewhere)?
Original:
We define an algorithm parameter 'PartyU nonce' that can be
used to carry this value in the message; however, the nonce
value could be determined by the application and the value
determined from elsewhere.
-->
<t> We define an algorithm parameter, "PartyU nonce", that can b
e used to carry this value in the message; however, the nonce value could be det
ermined by the application and the value determined from elsewhere.
</t> </t>
<t> This option does not need to be specified and is set to nil <t> This option does not need to be specified; if not
in that case. </t> needed, it is set to nil. </t>
</dd> </dd>
<dt>other:</dt> <dt>other:</dt>
<dd>This contains other information that is defined by the protoco l. This option does not need to be specified and is set to nil in that case. </d d> <dd>This contains other information that is defined by the protoco l. This option does not need to be specified; if not needed, it is set to nil. < /dd>
</dl> </dl>
</dd> </dd>
<dt>PartyVInfo:</dt> <dt>PartyVInfo:</dt>
<dd>This field holds information about party V. The content of the st ructure is the same as for the PartyUInfo but for party V. </dd> <dd>This field holds information about party V. The content of the st ructure is the same as for the PartyUInfo but for party V. </dd>
<dt>SuppPubInfo:</dt> <dt>SuppPubInfo:</dt>
<dd> <dd>
<t>This field contains public information that is mutually known to both parties. <t>This field contains public information that is mutually known to both parties.
</t> </t>
<dl newline="false"> <dl newline="false">
<dt>keyDataLength:</dt> <dt>keyDataLength:</dt>
<dd>This is set to the number of bits of the desired output value. <dd>This is set to the number of bits of the desired output
This practice means if algorithm A can use two different key lengths, the key value. This practice means if algorithm A can use two different
derived for longer key size will not contain the key for shorter key size as a p key lengths, the key derived for the longer key size will not
refix. </dd> contain the key for the shorter key size as a prefix. </dd>
<dt>protected:</dt> <dt>protected:</dt>
<dd>This field contains the protected parameter field. If there a <dd>This field contains the protected parameter field. If there
re no elements in the protected field, then use a zero-length bstr. </dd> are no elements in the "protected" field, then use a zero-length
bstr. </dd>
<dt>other:</dt> <dt>other:</dt>
<dd>This field is for free form data defined by the application. <dd>This field is for free-form data defined by the application.
An example is that an application could define two different byte strings to be For example, an application could define two different
placed here to generate different keys for a data stream versus a control stream byte strings to be placed here to generate different keys for a
. This field is optional and will only be present if the application defines a data stream versus a control stream. This field is optional and
structure for this information. Applications that define this <bcp14>SHOULD</bc will only be present if the application defines a structure for
p14> use CBOR to encode the data so that types and lengths are correctly include this information. Applications that define this
d. </dd> <bcp14>SHOULD</bcp14> use CBOR to encode the data so that types
and lengths are correctly included. </dd>
</dl> </dl>
</dd> </dd>
<dt>SuppPrivInfo:</dt> <dt>SuppPrivInfo:</dt>
<dd>This field contains private information that is mutually known pri vate information. An example of this information would be a preexisting shared secret. (This could, for example, be used in combination with an ECDH key agree ment to provide a secondary proof of identity.) The field is optional and will o nly be present if the application defines a structure for this information. App lications that define this <bcp14>SHOULD</bcp14> use CBOR to encode the data so that types and lengths are correctly included. </dd> <dd>This field contains private information that is mutually known pri vate information. An example of this information would be a pre-existing shared secret. (This could, for example, be used in combination with an ECDH key agre ement to provide a secondary proof of identity.) The field is optional and will only be present if the application defines a structure for this information. Ap plications that define this <bcp14>SHOULD</bcp14> use CBOR to encode the data so that types and lengths are correctly included. </dd>
</dl> </dl>
<t>The following CDDL fragment corresponds to the text above. </t> <t>The following CDDL fragment corresponds to the text above. </t>
<artwork type="CDDL" name="" alt=""><![CDATA[
<sourcecode type="CDDL"><![CDATA[
PartyInfo = ( PartyInfo = (
identity : bstr / nil, identity : bstr / nil,
nonce : bstr / int / nil, nonce : bstr / int / nil,
other : bstr / nil other : bstr / nil
) )
COSE_KDF_Context = [ COSE_KDF_Context = [
AlgorithmID : int / tstr, AlgorithmID : int / tstr,
PartyUInfo : [ PartyInfo ], PartyUInfo : [ PartyInfo ],
PartyVInfo : [ PartyInfo ], PartyVInfo : [ PartyInfo ],
SuppPubInfo : [ SuppPubInfo : [
keyDataLength : uint, keyDataLength : uint,
protected : empty_or_serialized_map, protected : empty_or_serialized_map,
? other : bstr ? other : bstr
], ],
? SuppPrivInfo : bstr ? SuppPrivInfo : bstr
] ]
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="key-management-algs"> <section anchor="key-management-algs">
<name>Content Key Distribution Methods</name> <name>Content Key Distribution Methods</name>
<t> <t>
<relref section="&CKeyDistributeSection;" target="I-D.ietf-cose-rfc8152b <!--[rfced] The following sentence cites a section that does not exist in the
is-struct"/> contains a generic description of content key distribution methods. cited document. We have updated this to point to Section 8.5 of RFC 9052. Pleas
e review.
Original:
Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic
description of content key distribution methods.
-->
<xref section="8.5" target="RFC9052"/> contains a generic description of
content key distribution methods.
This document defines the identifiers and usage for a number of content key distribution methods. This document defines the identifiers and usage for a number of content key distribution methods.
</t> </t>
<section> <section>
<name>Direct Encryption</name> <name>Direct Encryption</name>
<t> <t>
Direct encryption algorithm is defined in <relref section="&DirectDist <!--[rfced] The following sentence cites a section that does not exist in the
ribute;" target="I-D.ietf-cose-rfc8152bis-struct"/>. cited document. We have updated the text to refer to Section 9.5.1. Please let
Information about how to fill in the COSE_Recipient structure are deta us know if any corrections are needed.
iled there.
Original:
Direct encryption algorithm is defined in Section 9.5.1 of
[I-D.ietf-cose-rfc8152bis-struct].
-->
A direct encryption algorithm is defined in <xref section="8.5.1"
target="RFC9052"/>.
Information about how to fill in the COSE_Recipient structure is detai
led there.
</t> </t>
<section> <section>
<name>Direct Key</name> <name>Direct Key</name>
<t> <t>
This recipient algorithm is the simplest; the identified key is direct ly used as the key for the next layer down in the message. This recipient algorithm is the simplest; the identified key is direct ly used as the key for the next layer down in the message.
There are no algorithm parameters defined for this algorithm. There are no algorithm parameters defined for this algorithm.
The algorithm identifier value is assigned in <xref target="x-table-d irect"/>. The algorithm identifier value is assigned in <xref target="x-table-d irect"/>.
</t> </t>
<t> <t>
When this algorithm is used, the protected field <bcp14>MUST</bcp14> b When this algorithm is used, the "protected" field
e zero length. <bcp14>MUST</bcp14> have zero length.
The key type <bcp14>MUST</bcp14> be 'Symmetric'. The key type <bcp14>MUST</bcp14> be "Symmetric".
</t> </t>
<table anchor="x-table-direct" align="center"> <table anchor="x-table-direct" align="center">
<name>Direct Key</name> <name>Direct Key</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>direct</td> <td>direct</td>
<td>-6</td> <td align="center">-6</td>
<td>Direct use of CEK</td>
<td>Direct use of content encryption key (CEK)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section> <section>
<name>Security Considerations for Direct Key</name> <name>Security Considerations for Direct Key</name>
<t>This recipient algorithm has several potential problems that need to be considered: <t>This recipient algorithm has several potential problems that need to be considered:
</t> </t>
<ul> <ul>
<li>These keys need to have some method to be regularly updated ov er time. All of the content encryption algorithms specified in this document ha ve limits on how many times a key can be used without significant loss of securi ty. </li> <li>These keys need to have some method of being regularly updated over time. All of the content encryption algorithms specified in this document have limits on how many times a key can be used without significant loss of sec urity. </li>
<li>These keys need to be dedicated to a single algorithm. There have been a number of attacks developed over time when a single key is used for multiple different algorithms. One example of this is the use of a single key f or both the CBC encryption mode and the CBC-MAC authentication mode. </li> <li>These keys need to be dedicated to a single algorithm. There have been a number of attacks developed over time when a single key is used for multiple different algorithms. One example of this is the use of a single key f or both the CBC encryption mode and the CBC-MAC authentication mode. </li>
<li>Breaking one message means all messages are broken. If an adv ersary succeeds in determining the key for a single message, then the key for al l messages is also determined. </li> <li>Breaking one message means all messages are broken. If an adv ersary succeeds in determining the key for a single message, then the key for al l messages is also determined. </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="direct-kdf"> <section anchor="direct-kdf">
<name>Direct Key with KDF</name> <name>Direct Key with KDF</name>
<t>These recipient algorithms take a common shared secret between the <t>These recipient algorithms take a common shared secret between
two parties and applies the HKDF function (<xref target="HKDF-section"/>), using the two parties and apply HKDF (<xref
the context structure defined in <xref target="context"/> to transform the shar target="HKDF-section"/>), using the context structure defined in
ed secret into the CEK. <xref target="context"/> to transform the shared secret into the
CEK. The "protected" field can be of nonzero length. Either the "salt
The 'protected' field can be of non-zero length. Either the 'salt' para "
meter of HKDF or the 'PartyU nonce' parameter of the context structure <bcp14>MU parameter of HKDF or the "PartyU nonce" parameter of the context
ST</bcp14> be present. The salt/nonce parameter can be generated either randoml structure <bcp14>MUST</bcp14> be present. The "salt"/"nonce" parameter
y or deterministically. The requirement is that it be a unique value for the sh can be generated either randomly or deterministically. The
ared secret in question. </t> requirement is that it be a unique value for the shared secret in
question. </t>
<t>If the salt/nonce value is generated randomly, then it is suggested that the length of the random value be the same length as the output of the has h function underlying HKDF. While there is no way to guarantee that it will be unique, there is a high probability that it will be unique. If the salt/nonce v alue is generated deterministically, it can be guaranteed to be unique, and thus there is no length requirement. </t> <t>If the salt/nonce value is generated randomly, then it is suggested that the length of the random value be the same length as the output of the has h function underlying HKDF. While there is no way to guarantee that it will be unique, there is a high probability that it will be unique. If the salt/nonce v alue is generated deterministically, it can be guaranteed to be unique, and thus there is no length requirement. </t>
<t>A new IV must be used for each message if the same key is used. Th e IV can be modified in a predictable manner, a random manner, or an unpredictab le manner (i.e., encrypting a counter). </t> <t>A new IV must be used for each message if the same key is used. Th e IV can be modified in a predictable manner, a random manner, or an unpredictab le manner (i.e., encrypting a counter). </t>
<t>The IV used for a key can also be generated from the same HKDF func <t>The IV used for a key can also be generated using the same HKDF
tionality as the key is generated. If HKDF is used for generating the IV, the a functionality used to generate the key. If HKDF is used for
lgorithm identifier is set to "IV-GENERATION". </t> generating the IV, the algorithm identifier is set to
"IV-GENERATION". </t>
<t>The set of algorithms defined in this document can be found in <xre f target="x-table-direct-kdf"/>. </t> <t>The set of algorithms defined in this document can be found in <xre f target="x-table-direct-kdf"/>. </t>
<table anchor="x-table-direct-kdf" align="center"> <table anchor="x-table-direct-kdf" align="center">
<name>Direct Key with KDF</name> <name>Direct Key with KDF</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>KDF</th> <th>KDF</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>direct+HKDF-SHA-256</td> <td>direct+HKDF-SHA-256</td>
<td>-10</td> <td align="center">-10</td>
<td>HKDF SHA-256</td> <td>HKDF SHA-256</td>
<td>Shared secret w/ HKDF and SHA-256</td> <td>Shared secret w/ HKDF and SHA-256</td>
</tr> </tr>
<tr> <tr>
<td>direct+HKDF-SHA-512</td> <td>direct+HKDF-SHA-512</td>
<td>-11</td> <td align="center">-11</td>
<td>HKDF SHA-512</td> <td>HKDF SHA-512</td>
<td>Shared secret w/ HKDF and SHA-512</td> <td>Shared secret w/ HKDF and SHA-512</td>
</tr> </tr>
<tr> <tr>
<td>direct+HKDF-AES-128</td> <td>direct+HKDF-AES-128</td>
<td>-12</td> <td align="center">-12</td>
<td>HKDF AES-MAC-128</td> <td>HKDF AES-MAC-128</td>
<td>Shared secret w/ AES-MAC 128-bit key</td> <td>Shared secret w/ AES-MAC 128-bit key</td>
</tr> </tr>
<tr> <tr>
<td>direct+HKDF-AES-256</td> <td>direct+HKDF-AES-256</td>
<td>-13</td> <td align="center">-13</td>
<td>HKDF AES-MAC-256</td> <td>HKDF AES-MAC-256</td>
<td>Shared secret w/ AES-MAC 256-bit key</td> <td>Shared secret w/ AES-MAC 256-bit key</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>When using a COSE key for this algorithm, the following checks are made: <t>When using a COSE key for this algorithm, the following checks are made:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MU ST</bcp14> be 'Symmetric'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MU ST</bcp14> be "Symmetric".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> includ e 'deriveKey' or 'deriveBits'.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> includ e "deriveKey" or "deriveBits".</li>
</ul> </ul>
<section> <section>
<name>Security Considerations for Direct Key with KDF</name> <name>Security Considerations for Direct Key with KDF</name>
<t>The shared secret needs to have some method to be regularly updat <t>The shared secret needs to have some method of being regularly
ed over time. The shared secret forms the basis of trust. Although not used di updated over time. The shared secret forms the basis of trust.
rectly, it should still be subject to scheduled rotation. </t> Although not used directly, it should still be subject to
<t>While these methods do not provide for perfect forward secrecy, a scheduled rotation. </t>
s the same shared secret is used for all of the keys generated, if the key for a <t>These methods do not provide for perfect forward secrecy, as
ny single message is discovered, only the message (or series of messages) using the same shared secret is used for all of the keys generated;
that derived key are compromised. A new key derivation step will generate a new however, if the key for any single message is discovered, only the
key that requires the same amount of work to get the key. </t> message or series of messages using that derived key are
compromised. A new key derivation step will generate a new key that
requires the same
amount of work to get the key. </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="key_wrap_algs"> <section anchor="key_wrap_algs">
<name>Key Wrap</name> <name>Key Wrap</name>
<t> <t>
Key wrap is defined in <relref section="&DirectDistribute;" target="I <!--[rfced] The following sentence cites a section that does not exist in the
-D.ietf-cose-rfc8152bis-struct"/>. cited document. We have updated the text to refer to Section 8.5.2. Please let
us know if any correctiosn are needed.
Original:
Key wrap is defined in Section 9.5.1 of [I-D.ietf-cose-rfc8152bis-struct].
-->
Key wrap is defined in <xref section="8.5.2" target="RFC9052"/>.
Information about how to fill in the COSE_Recipient structure is detai led there. Information about how to fill in the COSE_Recipient structure is detai led there.
</t> </t>
<section> <section>
<name>AES Key Wrap</name> <name>AES Key Wrap</name>
<t>The AES Key Wrap algorithm is defined in <xref target="RFC3394"/>. T <t>The AES Key Wrap algorithm is defined in <xref target="RFC3394"/>.
his algorithm uses an AES key to wrap a value that is a multiple of 64 bits. As This algorithm uses an AES key to wrap a value that is a multiple of
such, it can be used to wrap a key for any of the content encryption algorithms 64 bits. As such, it can be used to wrap a key for any of the
defined in this document. The algorithm requires a single fixed parameter, the content encryption algorithms defined in this document. The algorithm
initial value. This is fixed to the value specified in Section 2.2.3.1 of <xre requires a single fixed parameter, the initial value. This is fixed
f target="RFC3394"/>. There are no public key parameters that vary on a per-inv to the value specified in <xref target="RFC3394" section="2.2.3.1"
ocation basis. The protected header bucket <bcp14>MUST</bcp14> be empty. </t> sectionFormat="of"/>. There are no public key parameters that vary on
<t>Keys may be obtained either from a key structure or from a recipient a per-invocation basis. The protected header bucket
structure. Implementations encrypting and decrypting <bcp14>MUST</bcp14> valida <bcp14>MUST</bcp14> be empty. </t>
te that the key type, key length, and algorithm are correct and appropriate for <t>Keys may be obtained from either a key structure or a recipient
the entities involved. </t> structure. Implementations that are encrypting and decrypting
<bcp14>MUST</bcp14> validate that the key type, key length, and
algorithm are correct and appropriate for the entities involved. </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'Symmetric'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "Symmetric".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the AE S Key Wrap algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the AE S Key Wrap algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'encrypt' or 'wrap key' when encrypting.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "encrypt" or "wrap key" when encrypting.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'decrypt' or 'unwrap key' when decrypting.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "decrypt" or "unwrap key" when decrypting.</li>
</ul> </ul>
<table anchor="x-table_aes_keywrap" align="center"> <table anchor="x-table_aes_keywrap" align="center">
<name>AES Key Wrap Algorithm Values</name> <name>AES Key Wrap Algorithm Values</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Key Size</th> <th align="center">Key Size</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>A128KW</td> <td>A128KW</td>
<td>-3</td> <td align="center">-3</td>
<td>128</td> <td align="center">128</td>
<td>AES Key Wrap w/ 128-bit key</td> <td>AES Key Wrap w/ 128-bit key</td>
</tr> </tr>
<tr> <tr>
<td>A192KW</td> <td>A192KW</td>
<td>-4</td> <td align="center">-4</td>
<td>192</td> <td align="center">192</td>
<td>AES Key Wrap w/ 192-bit key</td> <td>AES Key Wrap w/ 192-bit key</td>
</tr> </tr>
<tr> <tr>
<td>A256KW</td> <td>A256KW</td>
<td>-5</td> <td align="center">-5</td>
<td>256</td> <td align="center">256</td>
<td>AES Key Wrap w/ 256-bit key</td> <td>AES Key Wrap w/ 256-bit key</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section> <section>
<name>Security Considerations for AES-KW</name> <name>Security Considerations for AES Key Wrap</name>
<t>The shared secret needs to have some method to be regularly updated <t>The shared secret needs to have some method of being regularly upda
over time. The shared secret is the basis of trust. </t> ted over time. The shared secret is the basis of trust. </t>
</section> </section>
</section> </section>
</section> </section>
<section> <section>
<name>Direct Key Agreement</name> <name>Direct Key Agreement</name>
<t> <t>
Key Transport is defined in <relref section="9.5.4" target="I-D.ietf-c <!--[rfced] The following sentence cites a section that does not exist in the
ose-rfc8152bis-struct"/>. cited document. We have updated the document to refer to Section 8.5.3. Please
let us know if any corretions are needed.
Original:
Key Transport is defined in Section 9.5.4 of [I-D.ietf-cose-rfc8152bis-struct].
-->
Key transport is defined in <xref section="8.5.3" target="RFC9052"/>.
Information about how to fill in the COSE_Recipient structure is detai led there. Information about how to fill in the COSE_Recipient structure is detai led there.
</t> </t>
<section anchor="ECDH"> <section anchor="ECDH">
<name>Direct ECDH</name> <name>Direct ECDH</name>
<t>The mathematics for ECDH can be found in <xref target="RFC6090"/>. I n this document, the algorithm is extended to be used with the two curves define d in <xref target="RFC7748"/>. </t> <t>The mathematics for ECDH can be found in <xref target="RFC6090"/>. I n this document, the algorithm is extended to be used with the two curves define d in <xref target="RFC7748"/>. </t>
<t>ECDH is parameterized by the following: <t>ECDH is parameterized by the following:
</t> </t>
<ul> <dl>
<li> <dt>Curve Type/Curve:</dt><dd> <t>The curve selected controls not only
<t>Curve Type/Curve: The curve selected controls not only the size o the size of the shared secret, but the mathematics for computing the shared secr
f the shared secret, but the mathematics for computing the shared secret. The c et. The curve selected also controls how a point in the curve is represented an
urve selected also controls how a point in the curve is represented and what hap d what happens for the identity points on the curve. In this specification, we
pens for the identity points on the curve. In this specification, we allow for allow for a number of different curves to be used. A set of curves is defined i
a number of different curves to be used. A set of curves are defined in <xref t n <xref target="x-table-ec-curves"/>.</t>
arget="x-table-ec-curves"/>.
</t> <t> The math used to obtain the computed secret is based on the curve selected
<t> The math used to obtain the computed secret is based on the curv and not on the ECDH algorithm. For this reason, a new algorithm does not need t
e selected and not on the ECDH algorithm. For this reason, a new algorithm does o be defined for each of the curves. </t>
not need to be defined for each of the curves. </t> </dd>
</li>
<li>Computed Secret to Shared Secret: Once the computed secret is know <dt>Computed Secret to Shared Secret:</dt><dd> Once the computed
n, the resulting value needs to be converted to a byte string to run the KDF. T secret is known, the resulting value needs to be converted to a byte
he x-coordinate is used for all of the curves defined in this document. For cur string to run the KDF. The x-coordinate is used for all of the
ves X25519 and X448, the resulting value is used directly as it is a byte string curves defined in this document. For curves X25519 and X448, the
of a known length. For the P-256, P-384, and P-521 curves, the x-coordinate is resulting value is used directly, as it is a byte string of a known
run through the I2OSP function defined in <xref target="RFC8017"/>, using the s length. For the P-256, P-384, and P-521 curves, the x-coordinate is
ame computation for n as is defined in <xref target="ECDSA"/>. </li> run through the Integer-to-Octet-String primitive (I2OSP) function
defined in <xref target="RFC8017"/>,
using the same computation for n as is defined in <xref
target="ECDSA"/>. </dd>
<li>Ephemeral-Static or Static-Static: The key agreement process may b <!-- [rfced] We asked this terminology question in RFC 9052. We will align the
e done using either a static or an ephemeral key for the sender's side. When us documents as needed.
ing ephemeral keys, the sender <bcp14>MUST</bcp14> generate a new ephemeral key
for every key agreement operation. The ephemeral key is placed in the 'ephemera
l key' parameter and <bcp14>MUST</bcp14> be present for all algorithm identifier
s that use ephemeral keys. When using static keys, the sender <bcp14>MUST</bcp1
4> either generate a new random value or create a unique value.
For the KDFs used, this means either the 'salt' parameter for HKDF (<xre
f target="HKDF_Alg_Params"/>) or the 'PartyU nonce' parameter for the context st
ructure (<xref target="KDF_Context_Alg_Params"/>) <bcp14>MUST</bcp14> be present
(both can be present if desired). The value in the parameter <bcp14>MUST</bcp14
> be unique for the pair of keys being used. It is acceptable to use a global c
ounter that is incremented for every static-static operation and use the resulti
ng value. Care must be taken that the counter is saved to permanent storage in
a way to avoid reuse of that counter value. When using static keys, the static k
ey should be identified to the recipient. The static key can be identified eith
er by providing the key ('static key') or by providing a key identifier for the
static key ('static key id'). Both of these header parameters are defined in <x
ref target="x-table-ecdh-es-parameter-table"/>.
</li>
<li>Key Derivation Algorithm: The result of an ECDH key agreement proc RFC-to-be 9052 mostly uses "static-static" (there is one instance of "static-Sta
ess does not provide a uniformly random secret. As such, it needs to be run thr tic"); "Ephemeral-Static" is consistently capped. In addition, this document (R
ough a KDF in order to produce a usable key. Processing the secret through a KD FC-to-be 9053) mostly uses "Ephemeral-Static" (there is one instance of ephemera
F also allows for the introduction of context material: how the key is going to l-static); "static-static" is consistent.
be used and one-time material for static-static key agreement. All of the algor
ithms defined in this document use one of the HKDF algorithms defined in <xref t Please review and let us know how/if these may be made consistent.
arget="HKDF-section"/> with the context structure defined in <xref target="conte -->
xt"/>. </li>
<dt>Ephemeral-Static or Static-Static:</dt><dd> The key agreement
process may be done using either a static or an ephemeral
key for the sender's side. When using ephemeral keys, the
sender <bcp14>MUST</bcp14> generate a new ephemeral key for
every key agreement operation. The ephemeral key is placed
in the "ephemeral key" parameter and <bcp14>MUST</bcp14> be
present for all algorithm identifiers that use ephemeral
keys. When using static keys, the sender
<bcp14>MUST</bcp14> either generate a new random value or
create a unique value. For the KDFs used, this means that either
the "salt" parameter for HKDF (<xref
target="HKDF_Alg_Params"/>) or the "PartyU nonce" parameter
for the context structure (<xref
target="KDF_Context_Alg_Params"/>) <bcp14>MUST</bcp14> be
present (both can be present if desired). The value in the
parameter <bcp14>MUST</bcp14> be unique for the pair of keys
being used. It is acceptable to use a global counter that
is incremented for every static-static operation and use the
resulting value. Care must be taken that the counter is
saved to permanent storage in a way that avoids reuse of that
counter value. When using static keys, the static key should
be identified to the recipient. The static key can be
identified by providing either the key ("static key") or
a key identifier for the static key ("static key
id"). Both of these header parameters are defined in <xref
target="x-table-ecdh-es-parameter-table"/>.
</dd>
<dt>Key Derivation Algorithm:</dt><dd>The result of an ECDH
key agreement process does not provide a uniformly random secret.
As such, it needs to be run through a KDF in order to produce a usable
key. Processing the secret through a KDF also allows for the
introduction of context material: how the key is going to be used
and one-time material for static-static key agreement. All of the
algorithms defined in this document use one of the HKDF algorithms
defined in <xref target="HKDF-section"/> with the context structure
defined in <xref target="context"/>. </dd>
<dt>Key Wrap Algorithm:</dt><dd> No key wrap algorithm is used.
This is represented in <xref target="x-table-ecdh-es-table"/> as
"none". The key size for the context structure is the
content layer encryption algorithm size. </dd>
</dl>
<li>Key Wrap Algorithm: No key wrap algorithm is used. This is repres
ented in <xref target="x-table-ecdh-es-table"/> as 'none'. The key size for the
context structure is the content layer encryption algorithm size. </li>
</ul>
<t> <t>
COSE does not have an Ephemeral-Ephemeral version defined. COSE does not have an Ephemeral-Ephemeral version defined.
The reason for this is that COSE is not an online protocol by itself a nd thus does not have a method to establish ephemeral secrets on both sides. The reason for this is that COSE is not an online protocol by itself a nd thus does not have a method of establishing ephemeral secrets on both sides.
The expectation is that a protocol would establish the secrets for bot h sides, and then they would be used as static-static for the purposes of COSE, or that the protocol would generate a shared secret and a direct encryption woul d be used. The expectation is that a protocol would establish the secrets for bot h sides, and then they would be used as static-static for the purposes of COSE, or that the protocol would generate a shared secret and a direct encryption woul d be used.
</t> </t>
<t>The set of direct ECDH algorithms defined in this document are found <t>The set of direct ECDH algorithms defined in this document is found
in <xref target="x-table-ecdh-es-table"/>. </t> in <xref target="x-table-ecdh-es-table"/>. </t>
<table anchor="x-table-ecdh-es-table" align="center"> <table anchor="x-table-ecdh-es-table" align="center">
<name>ECDH Algorithm Values</name> <name>ECDH Algorithm Values</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th>Value</th>
<th>KDF</th> <th>KDF</th>
<th>Ephemeral- Static</th> <th>Ephemeral-Static</th>
<th>Key Wrap</th> <th>Key Wrap</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>ECDH-ES + HKDF-256</td> <td>ECDH-ES + HKDF-256</td>
<td>-25</td> <td>-25</td>
<td>HKDF - SHA-256</td> <td>HKDF -- SHA-256</td>
<td>yes</td> <td>yes</td>
<td>none</td> <td>none</td>
<td>ECDH ES w/ HKDF - generate key directly</td> <td>ECDH ES w/ HKDF -- generate key directly</td>
</tr> </tr>
<tr> <tr>
<td>ECDH-ES + HKDF-512</td> <td>ECDH-ES + HKDF-512</td>
<td>-26</td> <td>-26</td>
<td>HKDF - SHA-512</td> <td>HKDF -- SHA-512</td>
<td>yes</td> <td>yes</td>
<td>none</td> <td>none</td>
<td>ECDH ES w/ HKDF - generate key directly</td> <td>ECDH ES w/ HKDF -- generate key directly</td>
</tr> </tr>
<tr> <tr>
<td>ECDH-SS + HKDF-256</td> <td>ECDH-SS + HKDF-256</td>
<td>-27</td> <td>-27</td>
<td>HKDF - SHA-256</td> <td>HKDF -- SHA-256</td>
<td>no</td> <td>no</td>
<td>none</td> <td>none</td>
<td>ECDH SS w/ HKDF - generate key directly</td> <td>ECDH SS w/ HKDF -- generate key directly</td>
</tr> </tr>
<tr> <tr>
<td>ECDH-SS + HKDF-512</td> <td>ECDH-SS + HKDF-512</td>
<td>-28</td> <td>-28</td>
<td>HKDF - SHA-512</td> <td>HKDF -- SHA-512</td>
<td>no</td> <td>no</td>
<td>none</td> <td>none</td>
<td>ECDH SS w/ HKDF - generate key directly</td> <td>ECDH SS w/ HKDF -- generate key directly</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<table anchor="x-table-ecdh-es-parameter-table" align="center"> <table anchor="x-table-ecdh-es-parameter-table" align="center">
<name>ECDH Algorithm Parameters</name> <name>ECDH Algorithm Parameters</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Label</th> <th>Label</th>
skipping to change at line 1305 skipping to change at line 1842
<td>Static public key identifier for the sender</td> <td>Static public key identifier for the sender</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>This document defines these algorithms to be used with the curves P-2 56, P-384, P-521, X25519, and X448. Implementations <bcp14>MUST</bcp14> verify that the key type and curve are correct. Different curves are restricted to dif ferent key types. Implementations <bcp14>MUST</bcp14> verify that the curve and algorithm are appropriate for the entities involved. </t> <t>This document defines these algorithms to be used with the curves P-2 56, P-384, P-521, X25519, and X448. Implementations <bcp14>MUST</bcp14> verify that the key type and curve are correct. Different curves are restricted to dif ferent key types. Implementations <bcp14>MUST</bcp14> verify that the curve and algorithm are appropriate for the entities involved. </t>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'EC2' or 'OKP'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "EC2" or "OKP".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the ke <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the
y agreement algorithm being used.</li> key agreement algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'derive key' or 'derive bits' for the private key.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "derive key" or "derive bits" for the private key.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> be empty for the public key.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> be empty for the public key.</li>
</ul> </ul>
<section> <section>
<name>Security Considerations for ECDH</name> <name>Security Considerations for ECDH</name>
<t> <t>
There is a method of checking that points provided from external ent ities are valid. There is a method of checking that points provided from external ent ities are valid.
For the 'EC2' key format, this can be done by checking that the x an For the "EC2" key format, this can be done by checking that the x an
d y values form a point on the curve. d y values form a point on the curve.
For the 'OKP' format, there is no simple way to do point validation. For the "OKP" format, there is no simple way to perform point valida
tion.
</t> </t>
<t> <t>
Consideration was given to requiring that the public keys of both en <!--[rfced] The following sentence cites a section that does not exist in the
tities be provided as part of the key derivation process (as recommended in <rel cited document. Please review.
ref target="RFC7748" section="6.4"/>).
This was not done as COSE is used in a store and forward format rath Original:
er than in online key exchange. Consideration was given to requiring that the public keys of both
entities be provided as part of the key derivation process (as
recommended in Section 6.4 of [RFC7748]).
-->
Consideration was given to requiring that the public keys of both
entities be provided as part of the key derivation process (as
recommended in <xref target="RFC7748" section="6.4"/>). This was
not done, because COSE is used in a store-and-forward
format rather than in online key exchange.
In order for this to be a problem, either the receiver public key ha s to be chosen maliciously or the sender has to be malicious. In order for this to be a problem, either the receiver public key ha s to be chosen maliciously or the sender has to be malicious.
In either case, all security evaporates anyway. In either case, all security evaporates anyway.
</t> </t>
<t>A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted (either by the end user or by the entity that is responsible for making trust statements on ke ys). </t> <t>A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted (either by the end user or by the entity that is responsible for making trust statements on ke ys). </t>
</section> </section>
</section> </section>
</section> </section>
<section> <section>
<name>Key Agreement with Key Wrap</name> <name>Key Agreement with Key Wrap</name>
<t> <t>
Key Agreement with Key Wrap is defined in <relref section="9.5.5" targ <!--[rfced] The following sentence cites a section that does not exist in the
et="I-D.ietf-cose-rfc8152bis-struct"/>. cited document. We have updated the text to refer to Section 8.5.5. Please let
Information about how to fill in the COSE_Recipient structure are deta us know if corrections are needed.
iled there.
Original:
Key Agreement with Key Wrap is defined in Section 9.5.5 of
[I-D.ietf-cose-rfc8152bis-struct].
-->
Key Agreement with Key Wrap is defined in <xref section="8.5.5" target
="RFC9052"/>.
Information about how to fill in the COSE_Recipient structure is detai
led there.
</t> </t>
<section anchor="ECDH-wrap"> <section anchor="ECDH-wrap">
<name>ECDH with Key Wrap</name> <name>ECDH with Key Wrap</name>
<t>These algorithms are defined in <xref target="x-table-ecdh-es-table-w rap"/>. </t> <t>These algorithms are defined in <xref target="x-table-ecdh-es-table-w rap"/>. </t>
<t>ECDH with Key Agreement is parameterized by the same header parameter s as for ECDH; see <xref target="ECDH"/>, with the following modifications: <t>ECDH with Key Agreement is parameterized by the same header parameter s as for ECDH; see <xref target="ECDH"/>, with the following modifications:
</t> </t>
<ul> <dl>
<li>Key Wrap Algorithm: Any of the key wrap algorithms defined in <xre <dt>Key Wrap Algorithm:</dt><dd> Any of the key wrap algorithms
f target="key_wrap_algs"/> are supported. The size of the key used for the key defined in <xref target="key_wrap_algs"/> are supported. The size
wrap algorithm is fed into the KDF. The set of identifiers are found in <xref t of the key used for the key wrap algorithm is fed into the KDF. The
arget="x-table-ecdh-es-table-wrap"/>. </li> set of identifiers is found in <xref
</ul> target="x-table-ecdh-es-table-wrap"/>. </dd>
</dl>
<table anchor="x-table-ecdh-es-table-wrap" align="center"> <table anchor="x-table-ecdh-es-table-wrap" align="center">
<name>ECDH Algorithm Values with Key Wrap</name> <name>ECDH Algorithm Values with Key Wrap</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th>Value</th>
<th>KDF</th> <th>KDF</th>
<th>Ephemeral- Static</th> <th>Ephemeral-Static</th>
<th>Key Wrap</th> <th>Key Wrap</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>ECDH-ES + A128KW</td> <td>ECDH-ES + A128KW</td>
<td>-29</td> <td>-29</td>
<td>HKDF - SHA-256</td> <td>HKDF -- SHA-256</td>
<td>yes</td> <td>yes</td>
<td>A128KW</td> <td>A128KW</td>
<td>ECDH ES w/ Concat KDF and AES Key Wrap w/ 128-bit key</td> <td>ECDH ES w/ Concat KDF and AES Key Wrap w/ 128-bit key</td>
</tr> </tr>
<tr> <tr>
<td>ECDH-ES + A192KW</td> <td>ECDH-ES + A192KW</td>
<td>-30</td> <td>-30</td>
<td>HKDF - SHA-256</td> <td>HKDF -- SHA-256</td>
<td>yes</td> <td>yes</td>
<td>A192KW</td> <td>A192KW</td>
<td>ECDH ES w/ Concat KDF and AES Key Wrap w/ 192-bit key</td> <td>ECDH ES w/ Concat KDF and AES Key Wrap w/ 192-bit key</td>
</tr> </tr>
<tr> <tr>
<td>ECDH-ES + A256KW</td> <td>ECDH-ES + A256KW</td>
<td>-31</td> <td>-31</td>
<td>HKDF - SHA-256</td> <td>HKDF -- SHA-256</td>
<td>yes</td> <td>yes</td>
<td>A256KW</td> <td>A256KW</td>
<td>ECDH ES w/ Concat KDF and AES Key Wrap w/ 256-bit key</td> <td>ECDH ES w/ Concat KDF and AES Key Wrap w/ 256-bit key</td>
</tr> </tr>
<tr> <tr>
<td>ECDH-SS + A128KW</td> <td>ECDH-SS + A128KW</td>
<td>-32</td> <td>-32</td>
<td>HKDF - SHA-256</td> <td>HKDF -- SHA-256</td>
<td>no</td> <td>no</td>
<td>A128KW</td> <td>A128KW</td>
<td>ECDH SS w/ Concat KDF and AES Key Wrap w/ 128-bit key</td> <td>ECDH SS w/ Concat KDF and AES Key Wrap w/ 128-bit key</td>
</tr> </tr>
<tr> <tr>
<td>ECDH-SS + A192KW</td> <td>ECDH-SS + A192KW</td>
<td>-33</td> <td>-33</td>
<td>HKDF - SHA-256</td> <td>HKDF -- SHA-256</td>
<td>no</td> <td>no</td>
<td>A192KW</td> <td>A192KW</td>
<td>ECDH SS w/ Concat KDF and AES Key Wrap w/ 192-bit key</td> <td>ECDH SS w/ Concat KDF and AES Key Wrap w/ 192-bit key</td>
</tr> </tr>
<tr> <tr>
<td>ECDH-SS + A256KW</td> <td>ECDH-SS + A256KW</td>
<td>-34</td> <td>-34</td>
<td>HKDF - SHA-256</td> <td>HKDF -- SHA-256</td>
<td>no</td> <td>no</td>
<td>A256KW</td> <td>A256KW</td>
<td>ECDH SS w/ Concat KDF and AES Key Wrap w/ 256-bit key</td> <td>ECDH SS w/ Concat KDF and AES Key Wrap w/ 256-bit key</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>When using a COSE key for this algorithm, the following checks are ma de: <t>When using a COSE key for this algorithm, the following checks are ma de:
</t> </t>
<ul> <ul>
<li>The 'kty' field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be 'EC2' or 'OKP'.</li> <li>The "kty" field <bcp14>MUST</bcp14> be present, and it <bcp14>MUST </bcp14> be "EC2" or "OKP".</li>
<li>If the 'alg' field is present, it <bcp14>MUST</bcp14> match the ke y agreement algorithm being used.</li> <li>If the "alg" field is present, it <bcp14>MUST</bcp14> match the ke y agreement algorithm being used.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> include 'derive key' or 'derive bits' for the private key.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> include "derive key" or "derive bits" for the private key.</li>
<li>If the 'key_ops' field is present, it <bcp14>MUST</bcp14> be empty for the public key.</li> <li>If the "key_ops" field is present, it <bcp14>MUST</bcp14> be empty for the public key.</li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Key-specific-labels"> <section anchor="Key-specific-labels">
<name>Key Object Parameters</name> <name>Key Object Parameters</name>
<t>The COSE_Key object defines a way to hold a single key object. It is s till required that the members of individual key types be defined. This section of the document is where we define an initial set of members for specific key t ypes. </t> <t>The COSE_Key object defines a way to hold a single key object. It is s till required that the members of individual key types be defined. This section of the document is where we define an initial set of members for specific key t ypes. </t>
<t>For each of the key types, we define both public and private members. <t>For each of the key types, we define both public and private members.
The public members are what is transmitted to others for their usage. Private m The public members are what is transmitted to others for their usage.
embers allow for the archival of keys by individuals. However, there are some c Private members allow individuals to archive keys. However,
ircumstances in which private keys may be distributed to entities in a protocol. there are some circumstances in which private keys may be distributed to
Examples include: entities that have poor random number generation, centraliz entities in a protocol. Examples include: entities that have poor
ed key creation for multi-cast type operations, and protocols in which a shared random number generation, centralized key creation for multicast-type
secret is used as a bearer token for authorization purposes. </t> operations, and protocols in which a shared secret is used as a bearer
<t>Key types are identified by the 'kty' member of the COSE_Key object. I token for authorization purposes. </t>
n this document, we define four values for the member: </t> <t>Key types are identified by the "kty" member of the COSE_Key object. I
n this document, we define four values for the member: </t>
<table anchor="x-table_key_types" align="center"> <table anchor="x-table_key_types" align="center">
<name>Key Type Values</name> <name>Key Type Values</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>OKP</td> <td>OKP</td>
<td>1</td> <td align="center">1</td>
<td>Octet Key Pair</td> <td>Octet Key Pair</td>
</tr> </tr>
<tr> <tr>
<td>EC2</td> <td>EC2</td>
<td>2</td> <td align="center">2</td>
<td>Elliptic Curve Keys w/ x- and y-coordinate pair</td> <td>Elliptic Curve Keys w/ x- and y-coordinate pair</td>
</tr> </tr>
<tr> <tr>
<td>Symmetric</td> <td>Symmetric</td>
<td>4</td> <td align="center">4</td>
<td>Symmetric Keys</td> <td>Symmetric Keys</td>
</tr> </tr>
<tr> <tr>
<td>Reserved</td> <td>Reserved</td>
<td>0</td> <td align="center">0</td>
<td>This value is reserved</td> <td>This value is reserved</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section> <section>
<name>Elliptic Curve Keys</name> <name>Elliptic Curve Keys</name>
<t>Two different key structures are defined for elliptic curve keys. On <t>Two different key structures are defined for elliptic curve keys.
e version uses both an x-coordinate and a y-coordinate, potentially with point c One version uses both an x-coordinate and a y-coordinate, potentially
ompression ('EC2'). This is the traditional EC point representation that is use with point compression ("EC2"). This is the traditional
d in <xref target="RFC5480"/>. The other version uses only the x-coordinate as elliptic curve (EC) point
the y-coordinate is either to be recomputed or not needed for the key agreement representation that is used in <xref target="RFC5480"/>. The other
operation ('OKP'). </t> version uses only the x-coordinate, as the y-coordinate is either to
be recomputed or not needed for the key agreement operation ("OKP").
</t>
<t>Applications <bcp14>MUST</bcp14> check that the curve and the key typ e are consistent and reject a key if they are not. </t> <t>Applications <bcp14>MUST</bcp14> check that the curve and the key typ e are consistent and reject a key if they are not. </t>
<table anchor="x-table-ec-curves" align="center"> <table anchor="x-table-ec-curves" align="center">
<name>Elliptic Curves</name> <name>Elliptic Curves</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th align="center">Value</th>
<th>Key Type</th> <th align="center">Key Type</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>P-256</td> <td>P-256</td>
<td>1</td> <td align="center">1</td>
<td>EC2</td> <td align="center">EC2</td>
<td>NIST P-256 also known as secp256r1</td> <td>NIST P-256, also known as secp256r1</td>
</tr> </tr>
<tr> <tr>
<td>P-384</td> <td>P-384</td>
<td>2</td> <td align="center">2</td>
<td>EC2</td> <td align="center">EC2</td>
<td>NIST P-384 also known as secp384r1</td> <td>NIST P-384, also known as secp384r1</td>
</tr> </tr>
<tr> <tr>
<td>P-521</td> <td>P-521</td>
<td>3</td> <td align="center">3</td>
<td>EC2</td> <td align="center">EC2</td>
<td>NIST P-521 also known as secp521r1</td> <td>NIST P-521, also known as secp521r1</td>
</tr> </tr>
<tr> <tr>
<td>X25519</td> <td>X25519</td>
<td>4</td> <td align="center">4</td>
<td>OKP</td> <td align="center">OKP</td>
<td>X25519 for use w/ ECDH only</td> <td>X25519 for use w/ ECDH only</td>
</tr> </tr>
<tr> <tr>
<td>X448</td> <td>X448</td>
<td>5</td> <td align="center">5</td>
<td>OKP</td> <td align="center">OKP</td>
<td>X448 for use w/ ECDH only</td> <td>X448 for use w/ ECDH only</td>
</tr> </tr>
<tr> <tr>
<td>Ed25519</td> <td>Ed25519</td>
<td>6</td> <td align="center">6</td>
<td>OKP</td> <td align="center">OKP</td>
<td>Ed25519 for use w/ EdDSA only</td> <td>Ed25519 for use w/ EdDSA only</td>
</tr> </tr>
<tr> <tr>
<td>Ed448</td> <td>Ed448</td>
<td>7</td> <td align="center">7</td>
<td>OKP</td> <td align="center">OKP</td>
<td>Ed448 for use w/ EdDSA only</td> <td>Ed448 for use w/ EdDSA only</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section anchor="EC2-Keys"> <section anchor="EC2-Keys">
<name>Double Coordinate Curves</name> <name>Double Coordinate Curves</name>
<t>The traditional way of sending ECs has been to send either both the <t>The traditional way of sending ECs has been to send either both
x-coordinate and y-coordinate or the x-coordinate and a sign bit for the y-coor the x-coordinate and y-coordinate or the x-coordinate and a sign bit
dinate. The latter encoding has not been recommended in the IETF due to potenti for the y-coordinate. The latter encoding has not been recommended
al IPR issues. However, for operations in constrained environments, the ability by the IETF due to potential IPR
to shrink a message by not sending the y-coordinate is potentially useful. </t issues. However, for operations in constrained environments, the
> ability to shrink a message by not sending the y-coordinate is
<t>For EC keys with both coordinates, the 'kty' member is set to 2 (EC potentially useful. </t>
2). The key parameters defined in this section are summarized in <xref target=" <t>For EC keys with both coordinates, the "kty" member is set to 2 (EC
x-table-ec2-keys"/>. The members that are defined for this key type are: 2). The key parameters defined in this section are summarized in <xref target="
x-table-ec2-keys"/>. The members that are defined for this key type are:
</t> </t>
<dl newline="false" indent="5"> <dl newline="false" indent="5">
<dt>crv:</dt> <dt>crv:</dt>
<dd>This contains an identifier of the curve to be used with the key . The curves defined in this document for this key type can be found in <xref ta rget="x-table-ec-curves"/>. Other curves may be registered in the future, and p rivate curves can be used as well. </dd> <dd>This contains an identifier of the curve to be used with the key . The curves defined in this document for this key type can be found in <xref ta rget="x-table-ec-curves"/>. Other curves may be registered in the future, and p rivate curves can be used as well. </dd>
<dt>x:</dt> <dt>x:</dt>
<!--[rfced] The cited document mentions bit strings, not byte strings. Please
review which term should be used here.
<dd>This contains the x-coordinate for the EC point. The integer is Original:
converted to a byte string as defined in <xref target="SEC1"/>. Leading zero o The integer is converted to a byte string as defined in [SEC1].
ctets <bcp14>MUST</bcp14> be preserved. -->
<dd>This contains the x-coordinate for the EC point. The integer
is converted to a byte string as defined in <xref target="SEC1"/>.
Leading-zero octets <bcp14>MUST</bcp14> be preserved.
</dd> </dd>
<dt>y:</dt> <dt>y:</dt>
<dd>This contains either the sign bit or the value of the y-coordina te for the EC point. When encoding the value y, the integer is converted to an byte string (as defined in <xref target="SEC1"/>) and encoded as a CBOR bstr. L eading zero octets <bcp14>MUST</bcp14> be preserved. The compressed point encod ing is also supported. Compute the sign bit as laid out in the Elliptic-Curve-P oint-to-Octet-String Conversion function of <xref target="SEC1"/>. If the sign bit is zero, then encode y as a CBOR false value; otherwise, encode y as a CBOR true value. The encoding of the infinity point is not supported. </dd> <dd>This contains either the sign bit or the value of the y-coordina te for the EC point. When encoding the value y, the integer is converted to a b yte string (as defined in <xref target="SEC1"/>) and encoded as a CBOR bstr. Le ading-zero octets <bcp14>MUST</bcp14> be preserved. Compressed point encoding i s also supported. Compute the sign bit as laid out in the Elliptic-Curve-Point- to-Octet-String Conversion function of <xref target="SEC1"/>. If the sign bit i s zero, then encode y as a CBOR false value; otherwise, encode y as a CBOR true value. The encoding of the infinity point is not supported. </dd>
<dt>d:</dt> <dt>d:</dt>
<dd>This contains the private key. </dd> <dd>This contains the private key. </dd>
</dl> </dl>
<t>For public keys, it is <bcp14>REQUIRED</bcp14> that 'crv', 'x', and 'y' be present in the structure. For private keys, it is <bcp14>REQUIRED</bcp1 4> that 'crv' and 'd' be present in the structure. For private keys, it is <bcp 14>RECOMMENDED</bcp14> that 'x' and 'y' also be present, but they can be recompu ted from the required elements and omitting them saves on space. </t> <t>For public keys, it is <bcp14>REQUIRED</bcp14> that "crv", "x", and "y" be present in the structure. For private keys, it is <bcp14>REQUIRED</bcp1 4> that "crv" and "d" be present in the structure. For private keys, it is <bcp 14>RECOMMENDED</bcp14> that "x" and "y" also be present, but they can be recompu ted from the required elements, and omitting them saves on space. </t>
<table anchor="x-table-ec2-keys" align="center"> <table anchor="x-table-ec2-keys" align="center">
<name>EC Key Parameters</name> <name>EC Key Parameters</name>
<thead> <thead>
<tr> <tr>
<th>Key Type</th> <th align="center">Key Type</th>
<th>Name</th> <th align="center">Name</th>
<th>Label</th> <th align="center">Label</th>
<th>CBOR Type</th> <th>CBOR Type</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>2</td> <td align="center">2</td>
<td>crv</td> <td align="center">crv</td>
<td>-1</td> <td align="center">-1</td>
<td>int / tstr</td> <td>int / tstr</td>
<td>EC identifier - Taken from the "COSE Elliptic Curves" regist ry</td> <td>EC identifier -- Taken from the "COSE Elliptic Curves" regis try</td>
</tr> </tr>
<tr> <tr>
<td>2</td> <td align="center">2</td>
<td>x</td> <td align="center">x</td>
<td>-2</td> <td align="center">-2</td>
<td>bstr</td> <td>bstr</td>
<td>x-coordinate</td> <td>x-coordinate</td>
</tr> </tr>
<tr> <tr>
<td>2</td> <td align="center">2</td>
<td>y</td> <td align="center">y</td>
<td>-3</td> <td align="center">-3</td>
<td>bstr / bool</td> <td>bstr / bool</td>
<td>y-coordinate</td> <td>y-coordinate</td>
</tr> </tr>
<tr> <tr>
<td>2</td> <td align="center">2</td>
<td>d</td> <td align="center">d</td>
<td>-4</td> <td align="center">-4</td>
<td>bstr</td> <td>bstr</td>
<td>Private key</td> <td>Private key</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section> <section>
<name>Octet Key Pair</name> <name>Octet Key Pair</name>
<t>A new key type is defined for Octet Key Pairs (OKP). Do not assume t hat keys using this type are elliptic curves. This key type could be used for o ther curve types (for example, mathematics based on hyper-elliptic surfaces). < /t> <t>A new key type is defined for Octet Key Pairs (OKPs). Do not assume that keys using this type are elliptic curves. This key type could be used for other curve types (for example, mathematics based on hyper-elliptic surfaces). </t>
<t>The key parameters defined in this section are summarized in <xref ta rget="x-table-ec1-keys"/>. The members that are defined for this key type are: <t>The key parameters defined in this section are summarized in <xref ta rget="x-table-ec1-keys"/>. The members that are defined for this key type are:
</t> </t>
<dl newline="false" indent="5"> <dl newline="false" indent="5">
<dt>crv:</dt> <dt>crv:</dt>
<dd>This contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in <xref targ et="x-table-ec-curves"/>. Other curves may be registered in the future and priv ate curves can be used as well. </dd> <dd>This contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in <xref targ et="x-table-ec-curves"/>. Other curves may be registered in the future, and pri vate curves can be used as well. </dd>
<dt>x:</dt> <dt>x:</dt>
<dd>This contains the public key. The byte string contains the public key as defined by the algorithm. (For X25519, internally it is a little-endian integer.) </dd> <dd>This contains the public key. The byte string contains the public key as defined by the algorithm. (For X25519, internally it is a little-endian integer.) </dd>
<dt>d:</dt> <dt>d:</dt>
<dd>This contains the private key. </dd> <dd>This contains the private key. </dd>
</dl> </dl>
<t>For public keys, it is <bcp14>REQUIRED</bcp14> that 'crv' and 'x' be present in the structure. For private keys, it is <bcp14>REQUIRED</bcp14> that 'crv' and 'd' be present in the structure. For private keys, it is <bcp14>RECO MMENDED</bcp14> that 'x' also be present, but it can be recomputed from the requ ired elements and omitting it saves on space. </t> <t>For public keys, it is <bcp14>REQUIRED</bcp14> that "crv" and "x" be present in the structure. For private keys, it is <bcp14>REQUIRED</bcp14> that "crv" and "d" be present in the structure. For private keys, it is <bcp14>RECO MMENDED</bcp14> that "x" also be present, but it can be recomputed from the requ ired elements, and omitting it saves on space. </t>
<table anchor="x-table-ec1-keys" align="center"> <table anchor="x-table-ec1-keys" align="center">
<name>Octet Key Pair Parameters</name> <name>Octet Key Pair Parameters</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Key Type</th> <th align="center">Key Type</th>
<th>Label</th> <th align="center">Label</th>
<th>Type</th> <th>Type</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>crv</td> <td>crv</td>
<td>1</td> <td align="center">1</td>
<td>-1</td> <td align="center">-1</td>
<td>int / tstr</td> <td>int / tstr</td>
<td>EC identifier - Taken from the "COSE Elliptic Curves" registry </td> <td>EC identifier -- Taken from the "COSE Elliptic Curves" registr y</td>
</tr> </tr>
<tr> <tr>
<td>x</td> <td>x</td>
<td>1</td> <td align="center">1</td>
<td>-2</td> <td align="center">-2</td>
<td>bstr</td> <td>bstr</td>
<td>Public Key</td> <td>Public Key</td>
</tr> </tr>
<tr> <tr>
<td>d</td> <td>d</td>
<td>1</td> <td align="center">1</td>
<td>-4</td> <td align="center">-4</td>
<td>bstr</td> <td>bstr</td>
<td>Private key</td> <td>Private key</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section> <section>
<name>Symmetric Keys</name> <name>Symmetric Keys</name>
<t>Occasionally it is required that a symmetric key be transported betwe <t>Occasionally, it is required that a symmetric key be transported betw
en entities. This key structure allows for that to happen. </t> een entities. This key structure allows for that to happen. </t>
<t>For symmetric keys, the 'kty' member is set to 4 ('Symmetric'). The <t>For symmetric keys, the "kty" member is set to 4 ("Symmetric"). The
member that is defined for this key type is: member that is defined for this key type is:
</t> </t>
<dl newline="false"> <dl newline="false">
<dt>k:</dt> <dt>k:</dt>
<dd>This contains the value of the key. </dd> <dd>This contains the value of the key. </dd>
</dl> </dl>
<t>This key structure does not have a form that contains only public mem bers. As it is expected that this key structure is going to be transmitted, car e must be taken that it is never transmitted accidentally or insecurely. For sy mmetric keys, it is <bcp14>REQUIRED</bcp14> that 'k' be present in the structure . </t> <t>This key structure does not have a form that contains only public mem bers. As it is expected that this key structure is going to be transmitted, car e must be taken that it is never transmitted accidentally or insecurely. For sy mmetric keys, it is <bcp14>REQUIRED</bcp14> that "k" be present in the structure . </t>
<table anchor="x-table-symmetric-keys" align="center"> <table anchor="x-table-symmetric-keys" align="center">
<name>Symmetric Key Parameters</name> <name>Symmetric Key Parameter</name>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th align="center">Name</th>
<th>Key Type</th> <th align="center">Key Type</th>
<th>Label</th> <th align="center">Label</th>
<th>Type</th> <th align="center">Type</th>
<th>Description</th> <th>Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>k</td> <td align="center">k</td>
<td>4</td> <td align="center">4</td>
<td>-1</td> <td align="center">-1</td>
<td>bstr</td> <td align="center">bstr</td>
<td>Key Value</td> <td>Key Value</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="COSE-Capabilities"> <section anchor="COSE-Capabilities">
<name>COSE Capabilities</name> <name>COSE Capabilities</name>
<t> <t>
There are some situations that have been identified where identification Some situations have been identified where identification of capabilitie
of capabilities of an algorithm or a key type need to be specified. s of an algorithm or a key type needs to be specified.
One example of this is in <xref target="I-D.ietf-core-oscore-groupcomm"/ One example of this is in <xref
> where the capabilities of the counter signature algorithm are mixed into the t target="I-D.ietf-core-oscore-groupcomm"/>, where the capabilities of
raffic key derivation process. the counter signature algorithm are mixed into the process of traffic-key
This has a counterpart in the S/MIME specifications where SMIMECapabilit derivation.
ies is defined in <xref target="RFC8551" section="2.5a.2"/>. This has a counterpart in the S/MIME specifications, where SMIMECapabili
ties is defined in <xref target="RFC8551" section="2.5.2"/>.
This document defines the same concept for COSE. This document defines the same concept for COSE.
</t> </t>
<t> <t>
The algorithm identifier is not included in the capabilities data as it The algorithm identifier is not included in the capabilities data, as
should be encoded elsewhere in the message. it should be encoded elsewhere in the message. The key type identifier
The key type identifier is included in the capabilities data as it is no is included in the capabilities data, as it is not expected to be
t expected to be encoded elsewhere. encoded elsewhere.
</t> </t>
<t> <t>
Two different types of capabilities are defined: capabilities for algori thms and capabilities for key type. Two different types of capabilities are defined: capabilities for algori thms and capabilities for key type.
Once defined by registration with IANA, the list of capabilities for an algorithm or key type is immutable. Once defined by registration with IANA, the list of capabilities for an algorithm or key type is immutable.
If it is later found that a new capability is needed for a key type or a n algorithm, it will require that a new code point be assigned to deal with that . If it is later found that a new capability is needed for a key type or a lgorithm, it will require that a new code point be assigned to deal with that.
As a general rule, the capabilities are going to map to algorithm-specif ic header parameters or key parameters, but they do not need to do so. As a general rule, the capabilities are going to map to algorithm-specif ic header parameters or key parameters, but they do not need to do so.
An example of this is the HSS-LMS key capabilities defined below where t he hash algorithm used is included. An example of this is the HSS-LMS key capabilities defined below, where the hash algorithm used is included.
</t> </t>
<t> <t>
The capability structure is an array of values, the values included in t The capability structure is an array of values; the values included in t
he structure are dependent on a specific algorithm or key type. he structure are dependent on a specific algorithm or key type.
For algorithm capabilities, the first element should always be a key typ For algorithm capabilities, the first element should always be a
e value if applicable, but the items that are specific to a key (for example a c key type value if applicable, but the items that are specific to a key
urve) should not be included in the algorithm capabilities. (for example, a curve) should not be included in the algorithm
This means that if one wishes to enumerate all of the capabilities for a capabilities.
device which implements ECDH, it requires that all of the combinations of algor This means that if one wishes to enumerate all of the capabilities for
ithms and key pairs to be specified. a device that implements ECDH, it requires that all of the
The last example of <xref target="cap-examples"/> provides a case where combinations of algorithms and key pairs be specified.
this is done by allowing for a cross product to be specified between an array of The last example of <xref target="cap-examples"/> provides a case
algorithm capabilities and key type capabilities (see ECDH-ES+A25KW element). where this is done by allowing for a cross product to be specified
between an array of algorithm capabilities and key type capabilities
(see the ECDH-ES+A25KW element).
For a key, the first element should be the key type value. For a key, the first element should be the key type value.
While this means that the key type value will be duplicated if both an a lgorithm and key capability are used, the key type is needed in order to underst and the rest of the values. While this means that the key type value will be duplicated if both an a lgorithm and key capability are used, the key type is needed in order to underst and the rest of the values.
</t> </t>
<section> <section>
<name>Assignments for Existing Algorithms</name> <name>Assignments for Existing Algorithms</name>
<!-- [rfced] Section 8.1: We had trouble parsing this sentence.
If the suggested text is not correct, please clarify how many items
are listed here.
Original:
For the current set of algorithms in the registry, those in this
document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig],
the capabilities list is an array with one element, the key type
(from the "COSE Key Types" Registry).
Suggested (noting that the "COSE Key Types" registry also cites RFC 9021,
which we assume does not apply to this document because it defines
kty(6)):
For the current set of algorithms in the "COSE Key Types"
registry - including those in this document as well as those in
[RFC8230] and [RFC8778] - the capabilities list is an array with
one element: the key type. -->
<t> <t>
For the current set of algorithms in the registry, those in this docum ent as well as those in <xref target="RFC8230"/> and <xref target="I-D.ietf-cose -hash-sig"/>, the capabilities list is an array with one element, the key type ( from the "COSE Key Types" Registry). For the current set of algorithms in the registry, those in this docum ent as well as those in <xref target="RFC8230"/> and <xref target="RFC8778"/>, t he capabilities list is an array with one element, the key type (from the "COSE Key Types" registry).
It is expected that future registered algorithms could have zero, one, or multiple elements. It is expected that future registered algorithms could have zero, one, or multiple elements.
</t> </t>
</section> </section>
<section> <section>
<name>Assignments for Existing Key Types</name> <name>Assignments for Existing Key Types</name>
<t> <t>
There are a number of pre-existing key types, the following deals with There are a number of pre-existing key types; the following deals with
creating the capability definition for those structures: creating the capability definition for those structures:
</t> </t>
<ul>
<li> <!-- FYI tried this as a dl but went with keeping the bullets to match the origi
<t>OKP, EC2: The list of capabilities is:</t> nal-->
<ul>
<li>The key type value. (1 for OKP or 2 for EC2.)</li> <ul>
<li>One curve for that key type from the "COSE Elliptic Curve" reg
istry.</li> <li>
</ul> <t>OKP, EC2: The list of capabilities is:</t>
</li> <ul>
<li> <li>The key type value. (1 for OKP or 2 for EC2.)</li>
<t>RSA: The list of capabilities is:</t> <li>One curve for that key type from the "COSE Elliptic Curves" registry.</li>
<ul> </ul>
<li>The key type value (3).</li> </li>
</ul>
</li> <li>
<li> <t>RSA: The list of capabilities is:</t>
<t>Symmetric: The list of capabilities is:</t> <ul>
<ul> <li>The key type value (3).</li>
<li>The key type value (4).</li> </ul>
</ul> </li>
</li>
<li> <li>
<t>HSS-LMS: The list of capabilities is:</t> <t>Symmetric: The list of capabilities is:</t>
<ul> <ul>
<li>The key type value (5),</li> <li>The key type value (4).</li>
<li>Algorithm identifier for the underlying hash function from the </ul>
"COSE Algorithms" registry.</li> </li>
</ul>
</li> <li>
</ul> <t>HSS-LMS: The list of capabilities is:</t>
<ul>
<li>The key type value (5).</li>
<li>Algorithm identifier for the underlying hash function from the "COSE
Algorithms" registry.</li>
</ul>
</li>
</ul>
</section> </section>
<section anchor="cap-examples"> <section anchor="cap-examples">
<name>Examples</name> <name>Examples</name>
<t> <t>
Capabilities can be use in a key derivation process to make sure that Capabilities can be used in a key derivation process to make sure
both sides are using the same parameters. that both sides are using the same parameters.
This is the approach that is being used by the group communication KDF This is the approach that is being used by the group communication
in <xref target="I-D.ietf-core-oscore-groupcomm"/>. KDF in <xref target="I-D.ietf-core-oscore-groupcomm"/>.
<!--[rfced] Can you clarify what is meant by "include things" in the last
sentence below? What are "things"?
Original:
Capabilities can be use in a key derivation process to make sure that
both sides are using the same parameters. ... The three examples below show
different ways that one might include things:
-->
The three examples below show different ways that one might include th ings: The three examples below show different ways that one might include th ings:
</t> </t>
<ul> <ul>
<li> <li>
Just an algorithm capability: This is useful if the protocol wants to Only an algorithm capability: This is useful if the protocol wants to
require a specific algorithm such as ECDSA, but it is agnostic about which curve require a specific algorithm, such as ECDSA, but it is agnostic about which curv
is being used. e is being used.
This does require that the algorithm identifier be specified in the pr This requires that the algorithm identifier be specified in the protoc
otocol. See the first example. ol. See the first example.
</li> </li>
<li> <li>
Just a key type capability: This is useful if the protccol wants to Only a key type capability: This is useful if the protocol wants
require a specific a specific key type and curve, such as P-256, but will accept to require a specific key type and curve, such as
any algorithm using that curve (e.g. both ECDSA and ECDH). P-256, but will accept any algorithm using that curve (e.g., both
ECDSA and ECDH).
See the second example. See the second example.
</li> </li>
<li> <li>
Both an algorithm and a key type capability: This is used if the pr Both algorithm and key type capabilities: This is used if the
otocol needs to nail down all of the options surrounding an algorithm E.g. EdDS protocol needs to nail down all of the options surrounding an
A with the curve X25519. algorithm -- e.g., EdDSA with the curve X25519.
As with the first example, the algorithm identifier needs to be spec As with the first example, the algorithm identifier needs to be spec
ified in the protocol. See the third example which just concatenates the two cap ified in the protocol. See the third example, which just concatenates the two ca
abilities together. pabilities together.
</li> </li>
</ul> </ul>
<artwork> <sourcecode type="CDDL">
Algorithm ECDSA Algorithm ECDSA
0x8102 / [2 \ EC2 \ ] / 0x8102 / [2 \ EC2 \ ] /
Key type EC2 with P-256 curve: Key type EC2 with P-256 curve:
0x820201 / [2 \ EC2 \, 1 \ P-256 \] / 0x820201 / [2 \ EC2 \, 1 \ P-256 \] /
ECDH-ES + A256KW with an X25519 curve: ECDH-ES + A256KW with an X25519 curve:
0x8101820104 / [1 \ OKP \],[1 \ OKP \, 4 \ X25519 \] / 0x8101820104 / [1 \ OKP \],[1 \ OKP \, 4 \ X25519 \] /
</artwork> </sourcecode>
<t> <t>
The capabilities can also be used by and entity to advertise what it i The capabilities can also be used by an entity to advertise what it is
s capabable of doing. capable of doing.
The decoded example below is one of many encoding that could be used f The decoded example below is one of many encodings that could be used
or that purpose. for that purpose.
Each array element includes three fields: the algorithm identifier, on e or more algorithm capabilities, and one or more key type capabilities. Each array element includes three fields: the algorithm identifier, on e or more algorithm capabilities, and one or more key type capabilities.
</t> </t>
<artwork> <sourcecode type="CDDL">
[ [
[-8 / EdDSA /, [-8 / EdDSA /,
[1 / OKP key type /], [1 / OKP key type /],
[ [
[1 / OKP /, 6 / Ed25519 / ], [1 / OKP /, 6 / Ed25519 / ],
[1 /OKP/, 7 /Ed448 /] [1 /OKP/, 7 /Ed448 /]
] ]
], ],
[-7 / ECDSA with SHA-256/, [-7 / ECDSA with SHA-256/,
[2 /EC2 key type/], [2 /EC2 key type/],
skipping to change at line 1844 skipping to change at line 2483
[ [
[2 /EC2/, 1 /P-256/], [2 /EC2/, 1 /P-256/],
[1 /OKP/, 4 / X25519/ ] [1 /OKP/, 4 / X25519/ ]
] ]
], ],
[ 1 / A128GCM /, [ 1 / A128GCM /,
[ 4 / Symmetric / ], [ 4 / Symmetric / ],
[ 4 / Symmetric /] [ 4 / Symmetric /]
] ]
] ]
</artwork> </sourcecode>
<t> <t>
Examining the above: Examining the above:
</t> </t>
<ul> <ul>
<li>The first element indicates that the entity supports EdDSA with cu rves Ed25519 and Ed448.</li> <li>The first element indicates that the entity supports EdDSA with cu rves Ed25519 and Ed448.</li>
<li>The second element indicates that the entity supports ECDSA with c urves P-256 and P-521.</li> <li>The second element indicates that the entity supports ECDSA with c urves P-256 and P-521.</li>
<li> <li>
The third element indicates that the entity support ephemeral-static ECDH using AES256 key wrap. The third element indicates that the entity supports ephemeral-stati c ECDH using AES256 key wrap.
The entity can support the P-256 curve with an EC2 key type and the X25519 curve with an OKP key type. The entity can support the P-256 curve with an EC2 key type and the X25519 curve with an OKP key type.
</li> </li>
<li>The last element indicates that the entity supports AES-GCM of 128 bits for content encryption.</li> <li>The last element indicates that the entity supports AES-GCM of 128 bits for content encryption.</li>
</ul> </ul>
<t> <t>
The entity does not advertise that it supports any MAC algorithms. The entity does not advertise that it supports any MAC algorithms.
</t> </t>
</section> </section>
</section> </section>
<section anchor="CBOR-Canonical"> <section anchor="CBOR-Canonical">
<name>CBOR Encoding Restrictions</name> <name>CBOR Encoding Restrictions</name>
<t>This document limits the restrictions it imposes on how the CBOR Encode <t>This document limits the restrictions it imposes on how the CBOR
r needs to work. encoder needs to work. It has been narrowed down to the following
It has been narrowed down to the following restrictions: </t> restrictions: </t>
<ul> <!--[rfced] Please check that erratum 5066 <https://www.rfc-editor.org/errata/ei
d5066> does not impact the
following sentence.
Current sentence:
The restriction applies to the encoding of the COSE_KDF_Context.
RFC 8152 erratum correction:
The restriction applies to the encoding of the COSE_KDF_Context,
Sig_structure, the Enc_structure, and the MAC_structure.
-->
<ul>
<li> <li>
The restriction applies to the encoding of the COSE_KDF_Context. The restriction applies to the encoding of the COSE_KDF_Context.
</li> </li>
<!--[rfced] There seems to be a word missing in the following sentence. The
length of what must be the minimum?
Original:
Encoding MUST be done using definite lengths and the length of the
MUST be the minimum possible length.
-->
<li> <li>
Encoding <bcp14>MUST</bcp14> be done using definite lengths and the le Encoding <bcp14>MUST</bcp14> be done using definite lengths, and the
ngth of the <bcp14>MUST</bcp14> be the minimum possible length. length of the <bcp14>MUST</bcp14> be the minimum possible length.
This means that the integer 1 is encoded as "0x01" and not "0x1801". This means that the integer 1 is encoded as "0x01" and not "0x1801".
</li> </li>
<li> <li>
Applications <bcp14>MUST NOT</bcp14> generate messages with the same l abel used twice as a key in a single map. Applications <bcp14>MUST NOT</bcp14> generate messages with the same l abel used twice as a key in a single map.
Applications <bcp14>MUST NOT</bcp14> parse and process messages with t Applications <bcp14>MUST NOT</bcp14> parse and process messages with
he same label used twice as a key in a single map. the same label used twice as a key in a single map.
Applications can enforce the parse and process requirement by using pa Applications can enforce the parse-and-process requirement by using
rsers that will fail the parse step or by using parsers that will pass all keys parsers that will either fail the parse step or pass all keys to the
to the application, and the application can perform the check for duplicate keys application, and the application can perform
. the check for duplicate keys.
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<!--[rfced] Please check whether RFC 8152 erratum 5545 <https://www.rfc-editor.o
rg/errata/eid5545> affects the following statement:
IANA is requested to update all COSE registeries except for "COSE
Header Parmeters" and "COSE Key Common Parameters" [RFC8152] to [[This
Document]].
The erratum changes Table 3: Key Map Labels. The note states:
The value registry for kty should be COSE Key Types, as indicated in the text
following Table 3. This change affects the IANA registry:
https://www.iana.org/assignments/cose/cose.xhtml#key-common-parameters
-->
<t>IANA has updated all COSE registries except for "COSE
Header Parameters" and "COSE Key Common Parameters" to point to this docum
ent instead of <xref target="RFC8152"/>.</t>
<section> <section>
<name>Changes to "COSE Key Types" registry.</name> <name>Changes to the "COSE Key Types" Registry</name>
<t> <t>
IANA is requested to create a new column in the "COSE Key Types" registr IANA has added a new column in the "COSE Key Types" registry.
y. The new column is labeled "Capabilities" and has been populated accordin
The new column is to be labeled "Capabilities". g to the entries in <xref target="initial-kty-caps"/>.
The new column is to be populated according the entries in <xref target=
"initial-kty-caps"/>.
</t> </t>
<table anchor="initial-kty-caps"> <table anchor="initial-kty-caps">
<name>Key Type Capabilities</name> <name>Key Type Capabilities</name>
<thead> <thead>
<tr> <tr>
<th>Value</th> <th>Value</th>
<th>Name</th> <th>Name</th>
<th>Capabilities</th> <th>Capabilities</th>
</tr> </tr>
skipping to change at line 1938 skipping to change at line 2610
<td>Symmetric</td> <td>Symmetric</td>
<td>[kty(4)]</td> <td>[kty(4)]</td>
</tr> </tr>
<tr> <tr>
<td>5</td> <td>5</td>
<td>HSS-LMS</td> <td>HSS-LMS</td>
<td>[kty(5), hash algorithm]</td> <td>[kty(5), hash algorithm]</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>
IANA is requested to update the pointer for expert review to [[this do
cument]].
</t>
</section> </section>
<section> <section>
<name>Changes to "COSE Algorithms" registry</name> <name>Changes to the "COSE Algorithms" Registry</name>
<t> <t>
IANA is requested to create a new column in the "COSE Algorithms" regi IANA has added a new column in the "COSE Algorithms" registry.
stry. The new column is labeled "Capabilities" and has been populated with "
The new column is to be labeled "Capabilities". [kty]" for all current,
The new column is populated with "[kty]" for all current, non-provisio nonprovisional registrations.
nal, registrations. It is expected that the documents that define those algorithms will
It is expected that the documents which define those algorithms will b be expanded to include this registration.
e expanded to include this registration. If this is not done, then the designated expert should be consulted
If this is not done then the Designated Expert should be consulted bef before final registration for this document is done.
ore final registration for this document is done.
</t> </t>
<t> <t>
IANA is requested to update all references from RFC 8152 to [[This Doc ument]]. IANA has updated the Reference column in the "COSE Algorithms" registr y to include this document as a reference for all rows where it was not already present.
</t> </t>
<t> <t>
IANA is requested to update the pointer for expert rview to [[this doc IANA has added a new row to the "COSE Algorithms" registry.
ument]].
</t>
<t>
IANA is requested to update the reference column in the "COSE Algorith
ms" registry to include [[This Document]] as a reference for all rows where it i
s not already present.
</t> </t>
<t> <!-- [rfced] Table 23 is the only table that doesn't have a title. Would you li
IANA is requested to add a new row to the "COSE Algorithms" registry. ke to give it a title?
</t>
Original:
Table 23
Possibly:
Table 23: IV-GENERATION Algorithm Identifier -->
<table> <table>
<thead> <thead>
<tr> <tr>
<th>Name</th> <th>Name</th>
<th>Value</th> <th>Value</th>
<th>Description</th> <th>Description</th>
<th>Reference</th> <th>Reference</th>
<th>Recommended</th> <th>Recommended</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>IV Generation</td> <td>IV Generation</td>
<td>IV-GENERATION</td> <td>IV-GENERATION</td>
<td>For doing IV generation for symmetric algorithms.</td> <td>For doing IV generation for symmetric algorithms.</td>
<td>[[THIS DOCUMENT]]</td> <td>RFC 9053</td>
<td>No</td> <td>No</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The capabilities column for this registration is to be empty. The Capabilities column for this registration is to be empty.
</t> </t>
</section> </section>
<section> <section>
<name>Changes to the "COSE Key Type Parameters" registry</name> <name>Changes to the "COSE Key Type Parameters" Registry</name>
<t>
IANA is requested to modify the description to "Public Key" for the li
ne with "Key Type" of 2 and the "Name" of "x".
See <xref target="x-table-ec1-keys"/> which has been modified with thi
s change.
</t>
<t>
IANA is requested to update the references in the table from RFC8152 t
o [[This Document]].
</t>
<t> <t>
IANA is requested to update the pointer for expert rview to [[this doc <!--[rfced] Table 20 does not have a line with "Key Type" of
ument]]. 2. Please review the instructions and the table.
</t>
</section>
<section anchor="IANA-Alg-Registry"> Original:
<name>COSE Header Algorithm Parameters Registry</name> IANA is requested to modify the description to "Public Key" for the
<t> line with "Key Type" of 2 and the "Name" of "x". See Table 20 which
IANA created a registry titled "COSE Header Algorithm Parameters" as has been modified with this change.
part of processing <xref target="RFC8152"/>.
The registry has been created to use the "Expert Review Required" regi Perhaps this row in Table should be updated as follows:
stration procedure <xref target="RFC8126"/>.
</t> Original:
<t> | x | 1 | -2 | bstr | Public Key |
IANA is requested to update the references from <xref target="RFC8152"
/> to this document. Perhaps:
</t> | x | 2 | -2 | bstr | Public Key |
<t>
IANA is requested to update the pointer for expert rview to [[this doc -->
ument]]. IANA is requested to modify the description to "Public Key" for the
line with "Key Type" of 2 and the "Name" of "x".
See <xref target="x-table-ec1-keys"/>, which has been modified with
this change.
</t> </t>
</section> </section>
<section title="Expert Review Instructions" anchor="review" > <section title="Expert Review Instructions" anchor="review" >
<t> <t>
All of the IANA registries established by <xref target="RFC8152"/> are , at least in part, defined as expert review. This section gives some general g uidelines for what the experts should be looking for, but they are being designa ted as experts for a reason, so they should be given substantial latitude. All of the IANA registries established by <xref target="RFC8152"/> are , at least in part, defined as Expert Review. This section gives some general g uidelines for what the experts should be looking for, but they are being designa ted as experts for a reason, so they should be given substantial latitude.
</t> </t>
<t>Expert reviewers should take into consideration the following points: <t>Expert reviewers should take into consideration the following points:
</t> </t>
<ul> <ul>
<li>Point squatting should be discouraged. Reviewers are encouraged to get suff icient information for registration requests to ensure that the usage is not goi ng to duplicate one that is already registered, and that the point is likely to be used in deployments. The zones tagged as private use are intended for testin g purposes and closed environments; code points in other ranges should not be as signed for testing. </li> <li>Point squatting should be discouraged. Reviewers are encouraged to get suff icient information for registration requests to ensure that the usage is not goi ng to duplicate one that is already registered, and that the point is likely to be used in deployments. The zones tagged as private use are intended for testin g purposes and closed environments; code points in other ranges should not be as signed for testing. </li>
<li>Specifications are required for the standards track range of point assignmen <!-- [rfced] Same question as in RFC-to-be 9052: RFC 8126 indicates that Standar
t. Specifications should exist for specification required ranges, but early ass ds Track or BCP RFCs are required to register something via Standards Action.
ignment before a specification is available is considered to be permissible. Sp Using "specifications" to refer to Standards Track documents could be confusing.
ecifications are needed for the first-come, first-serve range if they are expect For clarity, we suggest an update. Also, we suggest updating "before a
ed to be used outside of closed environments in an interoperable way. When spec specification is available" to "before an RFC is available".
ifications are not provided, the description provided needs to have sufficient i
nformation to identify what the point is being used for. </li>
<li>Experts should take into account the expected usage of fields when approving Original:
point assignment. The fact that there is a range for standards track documents * Specifications are required for the standards track range of point
does not mean that a standards track document cannot have points assigned outsi assignment. Specifications should exist for specification
de of that range. The length of the encoded value should be weighed against how required ranges, but early assignment before a specification is
many code points of that length are left, the size of device it will be used on available is considered to be permissible. Specifications are
, and the number of code points left that encode to that size. </li> needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is
being used for.
<li>When algorithms are registered, vanity registrations should be discouraged. Perhaps:
One way to do this is to require registrations to provide additional documentat * Standards Track or BCP RFCs are required to register a code point in
ion on security analysis of the algorithm. Another thing that should be conside the Standards Action range. Specifications should exist for Specification
red is requesting an opinion on the algorithm from the Crypto Forum Research Gro Required ranges, but early assignment before an RFC is
up (CFRG). Algorithms that do not meet the security requirements of the communi available is permissible. Specifications are
ty and the messages structures should not be registered. </li> needed for the first-come, first-serve range if the points are
expected to be used outside of closed environments in an
interoperable way. When specifications are not provided, the
description provided needs to have sufficient information to
identify what the point is being used for.
-->
<li>Specifications are required for the Standards Track range of point
assignments. Specifications should exist for Specification Required ranges,
but early assignment before a specification is available is considered to be
permissible. Specifications are needed for the first-come, first-serve range
if the points are expected to be used outside of closed environments in an
interoperable way. When specifications are not provided, the description
provided needs to have sufficient information to identify what the point is
being used for. </li>
<li>Experts should take into account the expected usage of fields when
approving point assignment.
<!-- [rfced] Same question as for RFC-to-be 9052: Should "range for standards tr
ack documents" be "Standards Action range"?
Original:
The fact that there is a range for
standards track documents does not mean that a standards track
document cannot have points assigned outside of that range.
-->
The fact that there is a range for Standards
Track documents does not mean that a Standards Track document cannot have
points assigned outside of that range. The length of the encoded value should
be weighed against how many code points of that length are left, the size of
device it will be used on, and the number of code points left that encode to
that size. </li>
<li>When algorithms are registered, vanity registrations should be discouraged.
One way to do this is to require registrations to provide additional documentat
ion on security analysis of the algorithm. Another thing that should be conside
red is requesting an opinion on the algorithm from the Crypto Forum Research Gro
up (CFRG).
<!-- [rfced] Same question as for RFC-to-be 9052: What does "community and the m
essage structures" refer to?
Original:
Algorithms that do not meet the security requirements of
the community and the messages structures should not be
registered.
-->
Algorithms that do not meet the security requirements of the community and the m
essage structures should not be registered. </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>There are a number of security considerations that need to be taken int o account by implementers of this specification. The security considerations th at are specific to an individual algorithm are placed next to the description of the algorithm. While some considerations have been highlighted here, additiona l considerations may be found in the documents listed in the references. </t> <t>There are a number of security considerations that need to be taken int o account by implementers of this specification. The security considerations th at are specific to an individual algorithm are placed next to the description of the algorithm. While some considerations have been highlighted here, additiona l considerations may be found in the documents listed in the references. </t>
<t>Implementations need to protect the private key material for any indivi <t>Implementations need to protect the private key material for any
duals. There are some cases in this document that need to be highlighted on thi individuals. Some cases in this document need to be highlighted with
s issue. regard to this issue.
</t> </t>
<ul> <ul>
<li>Using the same key for two different algorithms can leak information about the key. It is therefore recommended that keys be restricted to a single algorithm. </li> <li>Use of the same key for two different algorithms can leak informatio n about the key. It is therefore recommended that keys be restricted to a singl e algorithm. </li>
<li>Use of 'direct' as a recipient algorithm combined with a second reci pient algorithm exposes the direct key to the second recipient. </li> <li>Use of "direct" as a recipient algorithm combined with a second reci pient algorithm exposes the direct key to the second recipient. </li>
<li>Several of the algorithms in this document have limits on the number of times that a key can be used without leaking information about the key. </l i> <li>Several of the algorithms in this document have limits on the number of times that a key can be used without leaking information about the key. </l i>
</ul> </ul>
<t>The use of ECDH and direct plus KDF (with no key wrap) will not directl <t>The use of ECDH and direct plus KDF (with no key wrap) will not
y lead to the private key being leaked; the one way function of the KDF will pre directly lead to the private key being leaked; the one-way function of
vent that. There is, however, a different issue that needs to be addressed. Ha the KDF will prevent that. There is, however, a different issue that
ving two recipients requires that the CEK be shared between two recipients. The needs to be addressed. Having two recipients requires that the CEK be
second recipient therefore has a CEK that was derived from material that can be shared between two recipients. The second recipient therefore has a CEK
used for the weak proof of origin. The second recipient could create a message that was derived from material that can be used for the weak proof of
using the same CEK and send it to the first recipient; the first recipient woul origin. The second recipient could create a message using the same CEK
d, for either static-static ECDH or direct plus KDF, make an assumption that the and send it to the first recipient; the first recipient would, for
CEK could be used for proof of origin even though it is from the wrong entity. either static-static ECDH or direct plus KDF, make an assumption that
If the key wrap step is added, then no proof of origin is implied and this is n the CEK could be used for proof of origin even though it is from the
ot an issue. </t> wrong entity. If the key wrap step is added, then no proof of origin is
<t>Although it has been mentioned before, the use of a single key for mult implied and this is not an issue. </t>
iple algorithms has been demonstrated in some cases to leak information about a <t>Although it has been mentioned before, the use of a single key for
key, provide the opportunity for attackers to forge integrity tags, or gain info multiple algorithms has been demonstrated in some cases to leak
rmation about encrypted content. Binding a key to a single algorithm prevents t information about a key, providing the opportunity for attackers to forge
hese problems. Key creators and key consumers are strongly encouraged not only integrity tags or gain information about encrypted content. Binding a
to create new keys for each different algorithm, but to include that selection o key to a single algorithm prevents these problems. Key creators and key
f algorithm in any distribution of key material and strictly enforce the matchin consumers are strongly encouraged to not only create new keys for each
g of algorithms in the key structure to algorithms in the message structure. In different algorithm, but include that selection of algorithm in any
addition to checking that algorithms are correct, the key form needs to be chec distribution of key material and strictly enforce the matching of
ked as well. Do not use an 'EC2' key where an 'OKP' key is expected. </t> algorithms in the key structure to algorithms in the message structure.
<t>Before using a key for transmission, or before acting on information re In addition to checking that algorithms are correct, the key form needs
ceived, a trust decision on a key needs to be made. Is the data or action somet to be checked as well.
hing that the entity associated with the key has a right to see or a right to re <!--[rfced] Same question as for RFC-to-be 9052: Would it be helpful to include
quest? A number of factors are associated with this trust decision. Some of the expansions for EC2 and OKP?
ones that are highlighted here are: RFC 8152 included the following in the body of the docment:
- (2 coordinate elliptic curve)
- (Octet Key Pair)
Original:
Do not use an 'EC2' key where an 'OKP' key is expected.
-->
Do not use an "EC2" key where an "OKP" key is
expected. </t>
<t>Before using a key for transmission, or before acting on information
received, a trust decision on a key needs to be made. Is the data or
action something that the entity associated with the key has a right to
see or a right to request? A number of factors are associated with this
trust decision. Some highlighted here are:
</t> </t>
<ul> <ul>
<li>What are the permissions associated with the key owner?</li> <li>What are the permissions associated with the key owner?</li>
<li>Is the cryptographic algorithm acceptable in the current context?</l i> <li>Is the cryptographic algorithm acceptable in the current context?</l i>
<li>Have the restrictions associated with the key, such as algorithm or <li>Have the restrictions associated with the key, such as algorithm
freshness, been checked and are they correct?</li> or freshness, been checked, and are they correct?</li>
<li>Is the request something that is reasonable, given the current state of the application?</li> <li>Is the request something that is reasonable, given the current state of the application?</li>
<li>Have any security considerations that are part of the message been e nforced (as specified by the application or 'crit' parameter)?</li> <li>Have any security considerations that are part of the message been e nforced (as specified by the application or "crit" parameter)?</li>
</ul> </ul>
<t>There are a large number of algorithms presented in this document that <t>There are a large number of algorithms presented in this
use nonce values. For all of the nonces defined in this document, there is some document that use nonce values. For all of the nonces defined
type of restriction on the nonce being a unique value either for a key or for s in this document, there is some type of restriction on the nonce
ome other conditions. In all of these cases, there is no known requirement on t being a unique value for either a key or some other
he nonce being both unique and unpredictable; under these circumstances, it's re conditions. In all of these cases, there is no known
asonable to use a counter for creation of the nonce. In cases where one wants t requirement on the nonce being both unique and unpredictable;
he pattern of the nonce to be unpredictable as well as unique, one can use a key under these circumstances, it's reasonable to use a counter for
created for that purpose and encrypt the counter to produce the nonce value. < creation of the nonce. In cases where one wants the pattern of
/t> the nonce to be unpredictable as well as unique, one can use a
<t>One area that has been getting exposure is traffic analysis of encrypte key created for that purpose and encrypt the counter to produce
d messages based on the length of the message. This specification does not prov the nonce value. </t> <t>One area that has been getting
ide for a uniform method of providing padding as part of the message structure. exposure is traffic analysis of encrypted messages based on the
An observer can distinguish between two different messages (for example, 'YES' length of the message. This specification does not provide
and 'NO') based on the length for all of the content encryption algorithms that a uniform method of providing padding as part of the message
are defined in this document. This means that it is up to the applications to d structure. An observer can distinguish between two different
ocument how content padding is to be done in order to prevent or discourage such messages (for example, "YES" and "NO") based on the length for
analysis. (For example, the text strings could be defined as 'YES' and 'NO '.) all of the content encryption algorithms that are defined in
</t> this document. This means that it is up to the applications to
<t> document how content padding is to be done, in order to prevent
The analsys done in <xref target="I-D.ietf-quic-tls"/> is based on the n or discourage such analysis. (For example, the text strings
umber of records/packets that are sent. could be defined as "YES" and "NO".) </t> <t> The analysis done
This should map well to the number of messages sent when use COSE so tha in <xref target="RFC9001"/> is based on the number of
t analysis should hold here as well. records/packets that are sent. This should map well to the
It needs to be noted that the limits are based on the number of messages number of messages sent when using COSE, so that analysis should
, but QUIC and DTLS are always pair-wise based endpoints, <xref target="I-D.ietf hold here as well. It needs to be noted that the limits are
-core-oscore-groupcomm"/> use COSE in a group communication. based on the number of messages, but QUIC and DTLS are always
Under these circumstances it may be that no one single entity will see a pairwise-based endpoints <xref
ll of the messages that are encrypted an therefore no single entity can trigger target="I-D.ietf-core-oscore-groupcomm"/> and use COSE in a group
the rekey operation. communication. Under these circumstances, it may be that no one
</t> single entity will see all of the messages that are encrypted, and
</section> therefore no single entity can trigger the rekey operation.
</middle> </t> </section> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name> <displayreference target="I-D.ietf-core-oscore-groupcomm"
<xi:include href="reference.I-D.ietf-cose-rfc8152bis-struct.xml"/> to="OSCORE-GROUPCOMM"/>
<xi:include href="reference.RFC.2104.xml"/> <displayreference target="I-D.mattsson-cfrg-det-sigs-with-noise"
<xi:include href="reference.RFC.2119.xml"/> to="CFRG-DET-SIGS"/>
<xi:include href="reference.RFC.3394.xml"/>
<xi:include href="reference.RFC.3610.xml"/>
<xi:include href="reference.RFC.5869.xml"/>
<xi:include href="reference.RFC.6090.xml"/>
<xi:include href="reference.RFC.6979.xml"/>
<xi:include href="reference.RFC.7049.xml"/>
<xi:include href="reference.RFC.8439.xml"/>
<xi:include href="reference.RFC.7748.xml"/>
<xi:include href="reference.RFC.8174.xml"/>
<reference anchor="AES-GCM" target="https://csrc.nist.gov/publications/n
istpubs/800-38D/SP-800-38D.pdf">
<front>
<title>Recommendation for Block Cipher Modes of Operation: Galois/Co
unter Mode (GCM) and GMAC</title>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
<seriesInfo name="NIST Special Publication" value="800-38D"/>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date year="2007" month="November"/>
</front>
</reference>
<reference anchor="DSS" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NI
ST.FIPS.186-4.pdf">
<front>
<title>Digital Signature Standard (DSS)</title>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
<seriesInfo name="FIPS PUB" value="186-4"/>
<author>
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<date year="2013" month="July"/>
</front>
</reference>
<reference anchor="MAC">
<!--
RFC Editor - help
A. Menezes, P. van Oorschot, S. Vanstone, <references>
Handbook of Applied Cryptography, CRC Press, Inc., Boca Raton <name>References</name>
(1996). <references> <name>Normative References</name>
--> <!-- draft-ietf-cose-rfc8152bis-struct-13; RFC 9052 -->
<front>
<title>Handbook of Applied Cryptography</title>
<author initials="A." surname="Menees"/> <reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rfc9052">
<author initials="P." surname="van Oorschot"/>
<author initials="S." surname="Vanstone"/>
<date year="1996"/>
</front>
</reference>
<reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">
<front>
<title>SEC 1: Elliptic Curve Cryptography</title>
<author>
<organization>Certicom Research</organization>
</author>
<date year="2009" month="May"/>
</front>
</reference>
<xi:include href="reference.RFC.8032.xml"/>
<xi:include href="reference.RFC.8017.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="reference.RFC.8126.xml"/>
<xi:include href="reference.RFC.8610.xml"/>
<xi:include href="reference.RFC.4231.xml"/>
<xi:include href="reference.RFC.4493.xml"/>
<xi:include href="reference.RFC.5116.xml"/>
<xi:include href="reference.RFC.5480.xml"/>
<xi:include href="reference.RFC.6151.xml"/>
<!-- <xi:include href="bibxml9/reference.STD.0090.xml"/> -->
<referencegroup anchor="STD90" target="https://www.rfc-editor.org/info/std90">
<!-- reference.RFC.8259.xml -->
<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259">
<front> <front>
<title> <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
The JavaScript Object Notation (JSON) Data Interchange Format <author initials='J' surname='Schaad' >
</title> <organization/>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor">
<organization/>
</author> </author>
<date year="2017" month="December"/> <date month='July' year='2021'/>
<abstract>
<t>
JavaScript Object Notation (JSON) is a lightweight, text-based, language-indepen
dent data interchange format. It was derived from the ECMAScript Programming Lan
guage Standard. JSON defines a small set of formatting rules for the portable re
presentation of structured data.
</t>
<t>
This document removes inconsistencies with other specifications of JSON, repairs
specification errors, and offers experience-based interoperability guidance.
</t>
</abstract>
</front> </front>
<seriesInfo name="STD" value="90"/> <seriesInfo name="STD" value="96"/>
<seriesInfo name="RFC" value="8259"/> <seriesInfo name="RFC" value="9052"/>
<seriesInfo name="DOI" value="10.17487/RFC8259"/> <seriesInfo name="DOI" value="10.17487/RFC9052"/>
</reference> </reference>
</referencegroup>
<xi:include href="reference.RFC.7252.xml"/>
<xi:include href="reference.RFC.7518.xml"/>
<xi:include href="reference.RFC.8152.xml"/>
<xi:include href="reference.RFC.8551.xml"/>
<xi:include href="reference.RFC.8230.xml"/>
<xi:include href="reference.I-D.ietf-core-oscore-groupcomm.xml"/>
<xi:include href="reference.I-D.ietf-cose-hash-sig.xml"/>
<reference anchor="SP800-38d" target="https://nvlpubs.nist.gov/nistpubs/
Legacy/SP/nistspecialpublication800-38d.pdf">
<front>
<title>Recommendation for Block Cipher Modes of Operation: Galois/C
ounter Mode (GCM) and GMAC</title>
<seriesInfo name="NIST Special Publication 800-38D" value=""/>
<author initials="M." surname="Dworkin"/>
<date year="2007" month="Nov"/>
</front>
</reference>
<reference anchor="SP800-56A" target="http://nvlpubs.nist.gov/nistpubs/S <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.
pecialPublications/NIST.SP.800-56Ar2.pdf"> xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<title>Recommendation for Pair-Wise Key Establishment Schemes Using xml"/>
Discrete Logarithm Cryptography</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3394.
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar2"/> xml"/>
<seriesInfo name="NIST Special Publication 800-56A," value="Revision <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3610.
2"/> xml"/>
<author initials="E." surname="Barker"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5869.
<organization>U.S. National Institute of Standards and Technology< xml"/>
/organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6090.
</author> xml"/>
<author initials="L." surname="Chen"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6979.
<organization>U.S. National Institute of Standards and Technology< xml"/>
/organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.
</author> xml"/>
<author initials="A." surname="Roginsky"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8439.
<organization>U.S. National Institute of Standards and Technology< xml"/>
/organization> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7748.
</author> xml"/>
<author initials="M." surname="Smid"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<organization>Orion Security Solutions, Inc.</organization> xml"/>
</author>
<date year="2013" month="May"/> <reference anchor="AES-GCM"
</front> target="https://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
</reference> ">
<reference anchor="GitHub-Examples" target="https://github.com/cose-wg/E <front> <title>Recommendation for Block Cipher Modes of
xamples"> Operation: Galois/Counter Mode (GCM) and GMAC</title>
<front> <seriesInfo name="NIST Special Publication" value="800-38D"/>
<title>GitHub Examples of COSE</title> <author initials="M" surname="Dworkin" />
<author/> <date year="2007" month="November"/>
</front> </front>
</reference> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
<xi:include href="reference.I-D.mattsson-cfrg-det-sigs-with-noise.xml"/> </reference>
<reference anchor="HKDF" target="https://eprint.iacr.org/2010/264.pdf">
<front> <reference anchor="DSS"
<title>Cryptographic Extraction and Key Derivation: The HKDF Scheme</t target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">
itle> <front>
<author initials="H." surname="Krawczyk"> <title>Digital Signature Standard (DSS)</title>
<organization>IBM T.J. Watson Research Center</organization> <seriesInfo name="FIPS PUB" value="186-4"/>
</author> <author>
<date year="2010"/> <organization>National Institute of Standards and
</front> Technology</organization> </author>
<date year="2013" month="July"/> </front>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
</reference>
<reference anchor="MAC" target="https://cacr.uwaterloo.ca/hac/">
<front> <title>Handbook of Applied Cryptography</title>
<author initials="A." surname="Menezes"/>
<author initials="P." surname="van Oorschot"/>
<author initials="S." surname="Vanstone"/>
<date year="1996"/> </front>
<refcontent>CRC Press, Boca Raton</refcontent>
</reference> </reference>
<reference anchor="ROBUST" target="https://www.felixguenther.info/docs/QUI
P2020_RobustChannels.pdf"> <reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">
<front> <front>
<title>Robust Channels: Handling Unreliable Networks in the Record Lay <title>SEC 1: Elliptic Curve Cryptography</title>
ers of QUIC and DTLS</title> <author>
<author initials="M." surname="Fischlin"/> <organization>Certicom Research</organization> </author>
<author initials="F." surname="Günther"/> <date year="2009" month="May"/>
<author initials="C." surname="Janson"/> </front>
<date year="2020" month="Feb"/> <refcontent>Standards for Efficient Cryptography</refcontent>
</front>
</reference> </reference>
<xi:include href="reference.I-D.ietf-quic-tls.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8032.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.
xml"/>
</references> </references>
</references>
<section numbered="false">
<references> <name>Informative References</name>
<!--[rfced] RFC 8126 is provided as an informative reference, but there are
no citations for it in the document. Please let us know it should be cited.
-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4231.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4493.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5116.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5480.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6151.
xml"/>
<reference anchor="STD90" target="https://www.rfc-editor.org/info/std90">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</tit
le>
<author initials="T." surname="Bray" fullname="Tim Bray" role="editor">
<organization />
</author>
<date month="December" year="2017" />
</front>
<seriesInfo name="STD" value="90" />
<seriesInfo name="RFC" value="8259" />
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7518.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8230.
xml"/>
<!-- [I-D.ietf-core-oscore-groupcomm] IESG state I-D Exists -->
<xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-core-osc
ore-groupcomm.xml"/>
<!-- [I-D.ietf-cose-hash-sig] Published as RFC 8778 -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8778.
xml"/>
<reference anchor="SP800-38D"
target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication
800-38d.pdf">
<front>
<title>Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC</title>
<seriesInfo name="NIST Special Publication" value="800-38D"/>
<author initials="M." surname="Dworkin"/>
<date year="2007" month="November"/> </front> </reference>
<!-- [rfced] References: Per
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf>,
the May 2013 version of [SP800-56A] has been superseded. Please let us know
if we may make the following update, per the NIST page.
Original:
[SP800-56A]
Barker, E., Chen, L., Roginsky, A., and M. Smid,
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography",
DOI 10.6028/NIST.SP.800-56Ar2, NIST Special Publication
800-56A, Revision 2, May 2013,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar2.pdf>.
Suggested:
[SP800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography",
DOI 10.6028/NIST.SP.800-56Ar3, NIST Special Publication
800-56A, Revision 3, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-56Ar3.pdf>. -->
<reference anchor="SP800-56A"
target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-
56Ar2.pdf">
<front>
<title>Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography</title>
<author initials="E." surname="Barker">
<organization/> </author>
<author initials="L." surname="Chen">
<organization/> </author>
<author initials="A." surname="Roginsky">
<organization/> </author>
<author initials="M." surname="Smid">
<organization/></author>
<date year="2013" month="May"/>
</front>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar2"/>
<refcontent>NIST Special Publication 800-56A, Revision 2</refcontent>
</reference>
<reference anchor="GitHub-Examples"
target="https://github.com/cose-wg/Examples">
<front>
<title>GitHub Examples of COSE</title> <author/>
<date month="June" day="3" year="2020"/>
</front>
<refcontent>commit 3221310</refcontent>
</reference>
<!-- [I-D.mattsson-cfrg-det-sigs-with-noise] IESG state Expired -->
<xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.mattsson-cfrg
-det-sigs-with-noise.xml"/>
<reference anchor="HKDF" target="https://eprint.iacr.org/2010/264.pdf">
<front>
<title>Cryptographic Extraction and Key Derivation: The HKDF
Scheme</title>
<author initials="H." surname="Krawczyk">
<organization>IBM T.J. Watson Research Center</organization>
</author>
<date year="2010"/>
</front>
</reference>
<!-- [ROBUST] The URL below returns a "File Not Found" error. Please provide a
working and stable URL - perhaps <https://eprint.iacr.org/2020/718.pdf>?
Original:
[ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust
Channels: Handling Unreliable Networks in the Record
Layers of QUIC and DTLS", February 2020,
<https://www.felixguenther.info/docs/
QUIP2020_RobustChannels.pdf>.
-->
<reference anchor="ROBUST"
target="https://eprint.iacr.org/2020/718.pdf">
<front>
<title>Robust Channels: Handling Unreliable Networks in
the Record Layers of QUIC and DTLS</title>
<author initials="M." surname="Fischlin"/>
<author initials="F." surname="Günther"/>
<author initials="C." surname="Janson"/>
<date year="2020" month="Feb"/>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9001.
xml"/>
</references>
</references>
<section numbered="false">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document is a product of the COSE working group of the IETF. </t> <t>This document is a product of the COSE Working Group of the IETF. </t>
<t>The following individuals are to blame for getting me started on this p <t>The following individuals are to blame for getting me started on this
roject in the first place: Richard Barnes, Matt Miller, and Martin Thomson. </t project in the first place: <contact fullname="Richard Barnes"/>,
> <contact fullname="Matt Miller"/>, and <contact fullname="Martin
<t>The initial version of the specification was based to some degree on th Thomson"/>. </t>
e outputs of the JOSE and S/MIME working groups. </t> <t>The initial draft version of the specification was based to some degree
<t>The following individuals provided input into the final form of the doc on
ument: Carsten Bormann, John Bradley, Brain Campbell, Michael B. Jones, Ilari Li the outputs of the JOSE and S/MIME Working Groups. </t>
usvaara, Francesca Palombini, Ludwig Seitz, and Göran Selander. </t> <t>The following individuals provided input into the final form of the
document: <contact fullname="Carsten Bormann"/>, <contact fullname="John
Bradley"/>, <contact fullname="Brian Campbell"/>, <contact
fullname="Michael B. Jones"/>, <contact fullname="Ilari Liusvaara"/>,
<contact fullname="Francesca Palombini"/>, <contact fullname="Ludwig
Seitz"/>, and <contact fullname="Göran Selander"/>. </t>
</section> </section>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
In particular, please review the use of "tradition" and "traditionally" in this
document.
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
uthor-instructions#table1> includes the following:
Note: This term may (1) create an inequitable relationship; and
(2) introduce ambiguity (“traditional” is a subjective term). When possible,
precise language is preferred.
We agree that tradition* may be ambiguous and suggest updating for clarity (wher
e possible).
-->
</back> </back>
</rfc> </rfc>
 End of changes. 340 change blocks. 
1217 lines changed or deleted 1712 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/

mirror server hosted at Truenetwork, Russian Federation.