draft-ietf-cose-rfc8152bis-algs-02.txt   draft-ietf-cose-rfc8152bis-algs-03.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) March 11, 2019 Obsoletes: 8152 (if approved) June 10, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: September 12, 2019 Expires: December 12, 2019
CBOR Object Signing and Encryption (COSE): Initial Algorithms CBOR Object Signing and Encryption (COSE): Initial Algorithms
draft-ietf-cose-rfc8152bis-algs-02 draft-ietf-cose-rfc8152bis-algs-03
Abstract Abstract
Concise Binary Object Representation (CBOR) is a data format designed Concise Binary Object Representation (CBOR) is a data format designed
for small code size and small message size. There is a need for the for small code size and small message size. There is a need for the
ability to have basic security services defined for this data format. ability to have basic security services defined for this data format.
This document defines the CBOR Object Signing and Encryption (COSE) This document defines the CBOR Object Signing and Encryption (COSE)
protocol. This specification describes how to create and process protocol. This specification describes how to create and process
signatures, message authentication codes, and encryption using CBOR signatures, message authentication codes, and encryption using CBOR
for serialization. COSE additionally describes how to represent for serialization. COSE additionally describes how to represent
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on December 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
(HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 18 (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Context Information Structure . . . . . . . . . . . . . . 19 5.2. Context Information Structure . . . . . . . . . . . . . . 19
6. Content Key Distribution Methods . . . . . . . . . . . . . . 24 6. Content Key Distribution Methods . . . . . . . . . . . . . . 24
6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 24 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 24
6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 24 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 24
6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 25 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 25
6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 27 6.2. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1. Security Considerations for AES-KW . . . . . . . . . 28 6.2.1. Security Considerations for AES-KW . . . . . . . . . 28
6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. Direct ECDH . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.1. Security Considerations . . . . . . . . . . . . . . . 30 6.3.1. Security Considerations . . . . . . . . . . . . . . . 31
6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 31 6.4. ECDH with Key Wrap . . . . . . . . . . . . . . . . . . . 31
7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 33 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 33
7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 33 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 33
7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 34 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 34
7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 35 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 35
7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 36 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
There has been an increased focus on small, constrained devices that There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT). One of the standards that has make up the Internet of Things (IoT). One of the standards that has
come out of this process is "Concise Binary Object Representation come out of this process is "Concise Binary Object Representation
(CBOR)" [RFC7049]. CBOR extended the data model of the JavaScript (CBOR)" [RFC7049]. CBOR extended the data model of the JavaScript
Object Notation (JSON) [RFC8259] by allowing for binary data, among Object Notation (JSON) [RFC8259] by allowing for binary data, among
skipping to change at page 4, line 47 skipping to change at page 4, line 47
1.4. CBOR Grammar 1.4. CBOR Grammar
At the time that [RFC8152] was initially published, the CBOR Data At the time that [RFC8152] was initially published, the CBOR Data
Definition Language (CDDL) [I-D.ietf-cbor-cddl] had not yet been Definition Language (CDDL) [I-D.ietf-cbor-cddl] had not yet been
published. This document uses a variant of CDDL which is described published. This document uses a variant of CDDL which is described
in [I-D.ietf-cose-rfc8152bis-struct] in [I-D.ietf-cose-rfc8152bis-struct]
1.5. Examples 1.5. Examples
A GitHub project has been created at <https://github.com/cose-wg/ A GitHub project has been created at <https://github.com/cose-wg/
Examples> that contains not only the examples presented in this Examples> that contains a set of testing examples as well. Each
document, but a more complete set of testing examples as well. Each
example is found in a JSON file that contains the inputs used to 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 create the example, some of the intermediate values that can be used
in debugging the example and the output of the example presented in in debugging the example and the output of the example presented in
both a hex and a CBOR diagnostic notation format. Some of the both a hex and a CBOR diagnostic notation format. Some of the
examples at the site are designed failure testing cases; these are examples at the site are designed failure testing cases; these are
clearly marked as such in the JSON file. If errors in the examples clearly marked as such in the JSON file. If errors in the examples
in this document are found, the examples on GitHub will be updated, in this document are found, the examples on GitHub will be updated,
and a note to that effect will be placed in the JSON file. and a note to that effect will be placed in the JSON file.
2. Signature Algorithms 2. Signature Algorithms
Section X.X of [I-D.ietf-cose-rfc8152bis-struct] Section 9 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
signature algorithms. The document defines signature algorithm signature algorithms. The document defines signature algorithm
identifiers for two signature algorithms. identifiers for two signature algorithms.
2.1. ECDSA 2.1. ECDSA
ECDSA [DSS] defines a signature algorithm using ECC. Implementations ECDSA [DSS] defines a signature algorithm using ECC. Implementations
SHOULD use a deterministic version of ECDSA such as the one defined SHOULD use a deterministic version of ECDSA such as the one defined
in [RFC6979]. The use of a deterministic signature algorithm allows in [RFC6979]. The use of a deterministic signature algorithm allows
for systems to avoid relying on random number generators in order to for systems to avoid relying on random number generators in order to
skipping to change at page 6, line 13 skipping to change at page 6, line 13
it to work with other curves and points in the future. it to work with other curves and points in the future.
In order to promote interoperability, it is suggested that SHA-256 be In order to promote interoperability, it is suggested that SHA-256 be
used only with curve P-256, SHA-384 be used only with curve P-384, 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 and SHA-512 be used with curve P-521. This is aligned with the
recommendation in Section 4 of [RFC5480]. recommendation in Section 4 of [RFC5480].
The signature algorithm results in a pair of integers (R, S). These The signature algorithm results in a pair of integers (R, S). These
integers will be the same length as the length of the key used for integers will be the same length as the length of the key used for
the signature process. The signature is encoded by converting the the signature process. The signature is encoded by converting the
integers into byte strings of the same length as the key size. The integers into bit strings of the same length as the key size. The
length is rounded up to the nearest byte and is left padded with zero length is rounded up to the nearest byte and is left padded with zero
bits to get to the correct length. The two integers are then bits to get to the correct length. The two integers are then
concatenated together to form a byte string that is the resulting concatenated together to form a byte string that is the resulting
signature. signature.
Using the function defined in [RFC8017], the signature is: Using the function defined in [RFC8017], the signature is:
Signature = I2OSP(R, n) | I2OSP(S, n) Signature = I2OSP(R, n) | I2OSP(S, n)
where n = ceiling(key_length / 8) where n = ceiling(key_length / 8)
skipping to change at page 8, line 45 skipping to change at page 8, line 45
and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they
should not be used with the other algorithm. should not be used with the other algorithm.
If batch signature verification is performed, a well-seeded If batch signature verification is performed, a well-seeded
cryptographic random number generator is REQUIRED. Signing and non- cryptographic random number generator is REQUIRED. Signing and non-
batch signature verification are deterministic operations and do not batch signature verification are deterministic operations and do not
need random numbers of any kind. need random numbers of any kind.
3. Message Authentication Code (MAC) Algorithms 3. Message Authentication Code (MAC) Algorithms
Section X.X of [I-D.ietf-cose-rfc8152bis-struct] Section 10 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
MAC algorithms. This section defines the conventions for two MAC MAC algorithms. This section defines the conventions for two MAC
algorithms. algorithms.
3.1. Hash-Based Message Authentication Codes (HMACs) 3.1. Hash-Based Message Authentication Codes (HMACs)
HMAC [RFC2104] [RFC4231] was designed to deal with length extension HMAC [RFC2104] [RFC4231] was designed to deal with length extension
attacks. The algorithm was also designed to allow for new hash attacks. The algorithm was also designed to allow for new hash
algorithms to be directly plugged in without changes to the hash algorithms to be directly plugged in without changes to the hash
function. The HMAC design process has been shown as solid since, function. The HMAC design process has been shown as solid since,
skipping to change at page 12, line 14 skipping to change at page 12, line 14
o Cipher Block Chaining (CBC) mode, if the same key is used for both o Cipher Block Chaining (CBC) mode, if the same key is used for both
encryption and authentication operations, an attacker can produce encryption and authentication operations, an attacker can produce
messages with a valid authentication code. messages with a valid authentication code.
o If the IV can be modified, then messages can be forged. This is o If the IV can be modified, then messages can be forged. This is
addressed by fixing the IV to all zeros. addressed by fixing the IV to all zeros.
4. Content Encryption Algorithms 4. Content Encryption Algorithms
Section X.X of [I-D.ietf-cose-rfc8152bis-struct] Section 11 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
Content Encryption algorithms. This document defines the identifier Content Encryption algorithms. This document defines the identifier
and usages for three content encryption algorithms. and usages for three content encryption algorithms.
4.1. AES GCM 4.1. AES GCM
The Galois/Counter Mode (GCM) mode is a generic authenticated The Galois/Counter Mode (GCM) mode is a generic authenticated
encryption block cipher mode defined in [AES-GCM]. The GCM mode is encryption block cipher mode defined in [AES-GCM]. The GCM mode is
combined with the AES block encryption algorithm to define an AEAD combined with the AES block encryption algorithm to define an AEAD
cipher. cipher.
skipping to change at page 14, line 19 skipping to change at page 14, line 19
where they use short messages and want to avoid doing recipient- where they use short messages and want to avoid doing recipient-
specific cryptographic operations. This favors smaller values of specific cryptographic operations. This favors smaller values of
both L and M. Less-constrained devices will want to be able to use both L and M. Less-constrained devices will want to be able to use
larger messages and are more willing to generate new keys for every larger messages and are more willing to generate new keys for every
operation. This favors larger values of L and M. operation. This favors larger values of L and M.
The following values are used for L: The following values are used for L:
16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length. 16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length.
This is sufficiently long for messages in the constrained world. This is sufficiently long for messages in the constrained world.
The nonce length is 13 bytes allowing for 2^(13*8) possible values The nonce length is 13 bytes allowing for 2^104 possible values of
of the nonce without repeating. the nonce without repeating.
64 bits (8): This limits messages to 2^64 bytes in length. The 64 bits (8): This limits messages to 2^64 bytes in length. The
nonce length is 7 bytes allowing for 2^56 possible values of the nonce length is 7 bytes allowing for 2^56 possible values of the
nonce without repeating. nonce without repeating.
The following values are used for M: The following values are used for M:
64 bits (8): This produces a 64-bit authentication tag. This 64 bits (8): This produces a 64-bit authentication tag. This
implies that there is a 1 in 2^64 chance that a modified message implies that there is a 1 in 2^64 chance that a modified message
will authenticate. will authenticate.
skipping to change at page 17, line 41 skipping to change at page 17, line 41
'unwrap key' when decrypting. 'unwrap key' when decrypting.
4.3.1. Security Considerations 4.3.1. Security Considerations
The key and nounce values MUST be a unique pair for every invocation The key and nounce values MUST be a unique pair for every invocation
of the algorithm. Nonce counters are considered to be an acceptable of the algorithm. Nonce counters are considered to be an acceptable
way of ensuring that they are unique. way of ensuring that they are unique.
5. Key Derivation Functions (KDFs) 5. Key Derivation Functions (KDFs)
Section X.X of [I-D.ietf-cose-rfc8152bis-struct] Section 12 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
Key Derivation Functions. This document defines a single context Key Derivation Functions. This document defines a single context
structure and a single KDF. These elements are used for all of the structure and a single KDF. These elements are used for all of the
recipient algorithms defined in this document that require a KDF recipient algorithms defined in this document that require a KDF
process. These algorithms are defined in Sections 6.1.2, 6.3, and process. These algorithms are defined in Sections 6.1.2, 6.3, and
6.4. 6.4.
5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) 5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF)
The HKDF key derivation algorithm is defined in [RFC5869]. The HKDF key derivation algorithm is defined in [RFC5869].
skipping to change at page 24, line 33 skipping to change at page 24, line 33
SuppPubInfo : [ SuppPubInfo : [
keyDataLength : uint, keyDataLength : uint,
protected : empty_or_serialized_map, protected : empty_or_serialized_map,
? other : bstr ? other : bstr
], ],
? SuppPrivInfo : bstr ? SuppPrivInfo : bstr
] ]
6. Content Key Distribution Methods 6. Content Key Distribution Methods
Section X.X of [I-D.ietf-cose-rfc8152bis-struct] Section 13 of [I-D.ietf-cose-rfc8152bis-struct]
[I-D.ietf-cose-rfc8152bis-struct] contains a generic description of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of
content key distribution methods. This document defines the content key distribution methods. This document defines the
identifiers and usage for a number of content key distribution identifiers and usage for a number of content key distribution
methods. methods.
6.1. Direct Encryption 6.1. Direct Encryption
Direct encryption algorithm is defined in Section X.X of [I-D.ietf- Direct encryption algorithm is defined in Section 13.1 of [I-D.ietf-
cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]. cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct].
Information about how to fill in the COSE_Recipient structure are Information about how to fill in the COSE_Recipient structure are
detailed there. detailed there.
6.1.1. Direct Key 6.1.1. Direct Key
This recipient algorithm is the simplest; the identified key is This recipient algorithm is the simplest; the identified key is
directly used as the key for the next layer down in the message. directly used as the key for the next layer down in the message.
There are no algorithm parameters defined for this algorithm. The There are no algorithm parameters defined for this algorithm. The
algorithm identifier value is assigned in Table 11. algorithm identifier value is assigned in Table 11.
skipping to change at page 29, line 21 skipping to change at page 29, line 21
introduction of context material: how the key is going to be used introduction of context material: how the key is going to be used
and one-time material for static-static key agreement. All of the and one-time material for static-static key agreement. All of the
algorithms defined in this document use one of the HKDF algorithms algorithms defined in this document use one of the HKDF algorithms
defined in Section 5.1 with the context structure defined in defined in Section 5.1 with the context structure defined in
Section 5.2. Section 5.2.
o Key Wrap Algorithm: No key wrap algorithm is used. This is o Key Wrap Algorithm: No key wrap algorithm is used. This is
represented in Table 14 as 'none'. The key size for the context represented in Table 14 as 'none'. The key size for the context
structure is the content layer encryption algorithm size. structure is the content layer encryption algorithm size.
COSE does not have an Ephemeral-Ephemeral version defined. The
reason for this is that COSE is not an an online protocol by itself
and thus does not have a method to establish ephemeral secrets on
both sides. The expectation is that a protocol would establish the
secrets for both 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 would be used.
The set of direct ECDH algorithms defined in this document are found The set of direct ECDH algorithms defined in this document are found
in Table 14. in Table 14.
+-----------+-------+---------+------------+--------+---------------+ +-----------+-------+---------+------------+--------+---------------+
| Name | Value | KDF | Ephemeral- | Key | Description | | Name | Value | KDF | Ephemeral- | Key | Description |
| | | | Static | Wrap | | | | | | Static | Wrap | |
+-----------+-------+---------+------------+--------+---------------+ +-----------+-------+---------+------------+--------+---------------+
| ECDH-ES + | -25 | HKDF - | yes | none | ECDH ES w/ | | ECDH-ES + | -25 | HKDF - | yes | none | ECDH ES w/ |
| HKDF-256 | | SHA-256 | | | HKDF - | | HKDF-256 | | SHA-256 | | | HKDF - |
| | | | | | generate key | | | | | | | generate key |
skipping to change at page 36, line 43 skipping to change at page 36, line 47
'k' be present in the structure. 'k' be present in the structure.
+------+----------+-------+------+-------------+ +------+----------+-------+------+-------------+
| Name | Key Type | Label | Type | Description | | Name | Key Type | Label | Type | Description |
+------+----------+-------+------+-------------+ +------+----------+-------+------+-------------+
| k | 4 | -1 | bstr | Key Value | | k | 4 | -1 | bstr | Key Value |
+------+----------+-------+------+-------------+ +------+----------+-------+------+-------------+
Table 21: Symmetric Key Parameters Table 21: Symmetric Key Parameters
8. IANA Considerations 8. CBOR Encoding Restrictions
There are no IANA actions. There has been an attempt to limit the number of places where the
document needs to impose restrictions on how the CBOR Encoder needs
to work. We have managed to narrow it down to the following
restrictions:
9. Security Considerations o The restriction applies to the encoding of the COSE_KDF_Context.
o Encoding MUST be done using definite lengths and the length of the
MUST be the minimum possible length. This means that the integer
1 is encoded as "0x01" and not "0x1801".
o Applications MUST NOT generate messages with the same label used
twice as a key in a single map. Applications MUST NOT parse and
process messages with the same label used twice as a key in a
single map. Applications can enforce the parse and process
requirement by using parsers that will fail the parse step or by
using parsers that will pass all keys to the application, and the
application can perform the check for duplicate keys.
9. IANA Considerations
There are no IANA actions. The required actions are in
[I-D.ietf-cose-rfc8152bis-struct].
10. Security Considerations
There are a number of security considerations that need to be taken There are a number of security considerations that need to be taken
into account by implementers of this specification. The security into account by implementers of this specification. The security
considerations that are specific to an individual algorithm are considerations that are specific to an individual algorithm are
placed next to the description of the algorithm. While some placed next to the description of the algorithm. While some
considerations have been highlighted here, additional considerations considerations have been highlighted here, additional considerations
may be found in the documents listed in the references. may be found in the documents listed in the references.
Implementations need to protect the private key material for any Implementations need to protect the private key material for any
individuals. There are some cases in this document that need to be individuals. There are some cases in this document that need to be
skipping to change at page 38, line 44 skipping to change at page 39, line 20
analysis of encrypted messages based on the length of the message. analysis of encrypted messages based on the length of the message.
This specification does not provide for a uniform method of providing This specification does not provide for a uniform method of providing
padding as part of the message structure. An observer can padding as part of the message structure. An observer can
distinguish between two different strings (for example, 'YES' and distinguish between two different strings (for example, 'YES' and
'NO') based on the length for all of the content encryption 'NO') based on the length for all of the content encryption
algorithms that are defined in this document. This means that it is algorithms that are defined in this document. This means that it is
up to the applications to document how content padding is to be done up to the applications to document how content padding is to be done
in order to prevent or discourage such analysis. (For example, the in order to prevent or discourage such analysis. (For example, the
strings could be defined as 'YES' and 'NO '.) strings could be defined as 'YES' and 'NO '.)
10. References 11. References
10.1. Normative References 11.1. Normative References
[AES-GCM] National Institute of Standards and Technology, [AES-GCM] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: "Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC", NIST Special Galois/Counter Mode (GCM) and GMAC", NIST Special
Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November
2007, <https://csrc.nist.gov/publications/nistpubs/800- 2007, <https://csrc.nist.gov/publications/nistpubs/800-
38D/SP-800-38D.pdf>. 38D/SP-800-38D.pdf>.
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4, Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013, DOI 10.6028/NIST.FIPS.186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE) - Schaad, J., "CBOR CBOR Object Signing and Encryption
Structures and Process", draft-ietf-cose-rfc8152bis- (COSE): Structures and Process", draft-ietf-cose-
struct-01 (work in progress), February 2019. rfc8152bis-struct-02 (work in progress), March 2019.
[MAC] National Institute of Standards and Technology, "Computer [MAC] National Institute of Standards and Technology, "Computer
Data Authentication", FIPS PUB 113, May 1985, Data Authentication", FIPS PUB 113, May 1985,
<http://csrc.nist.gov/publications/fips/fips113/ <http://csrc.nist.gov/publications/fips/fips113/
fips113.html>. fips113.html>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 40, line 40 skipping to change at page 41, line 9
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
Standards for Efficient Cryptography, Version 2.0, May Standards for Efficient Cryptography, Version 2.0, May
2009, <http://www.secg.org/sec1-v2.pdf>. 2009, <http://www.secg.org/sec1-v2.pdf>.
10.2. Informative References 11.2. Informative References
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor- express CBOR and JSON data structures", draft-ietf-cbor-
cddl-07 (work in progress), February 2019. cddl-08 (work in progress), March 2019.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, DOI 10.17487/RFC4231, December 2005, RFC 4231, DOI 10.17487/RFC4231, December 2005,
<https://www.rfc-editor.org/info/rfc4231>. <https://www.rfc-editor.org/info/rfc4231>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <https://www.rfc-editor.org/info/rfc4493>. 2006, <https://www.rfc-editor.org/info/rfc4493>.
 End of changes. 24 change blocks. 
31 lines changed or deleted 61 lines changed or added

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