CBOR Encoded Message Syntax: Additional Algorithms
August Cellars
ietf@augustcellars.com
Security
COSE Working Group
This document defines the identifiers and usage for a set of additional cryptographic algorithms in the CBOR Encoded Message (COSE) Syntax.
The algorithms setup in this docment are: RSA-PSS, RSA-OAEP, .... !!TBD!!
The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests at . Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantial issues need to be discussed on the COSE mailing list.
In the process of writing RFCXXXX several algorithms were removed from that document to be addressed at a later date. This document deals with a large set of the cryptographic algorithms which were removed at that time.
This document provides the necessary conventions needed to use the algorithms defined in this document. This document additionally provides the necessary registration in the appropriate IANA registry tables.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in .
When the words appear in lower case, their natural language meaning is used.
In this document we use the following terminology: I have not gone through the document to determine what needs to be here yet. We mostly want to grab terms which are used in unusual ways or are not generally understood.
This document defines two new signature algorithms: RSA-PSS and Edwards Curve Digital Signature Algorithm (EdDSA). Both of these signature algorithms are Signature Scheme with Appendix algorithms. (For a discussion on the difference between signature scheme with appendix and signature scheme with message recovery algorithms, see .)
The RSASSA-PSS signature algorithm is defined in .
The RSASSA-PSS signature algorithm is parametized with a hash function (h), a mask generation function (mgf) and a salt length (sLen). For this specification, the mask generation function is fixed to be MGF1 as defined in . It has been recommended that the same hash function be used for hashing the data as well as in the mask generation function, for this specification we following this recommendation. The salt length is the same length as the hash function output.
Implementations need to check that the key type is 'RSA' when creating or verifying a signature.
The algorithms defined in this document can be found in .
name
value
hash
salt length
description
PS256
TBD1
SHA-256
32
RSASSA-PSS w/ SHA-256
PS384
TBD2
SHA-384
48
RSASSA-PSS w/ SHA-384
PS512
TBD3
SHA-512
64
RSASSA-PSS w/ SHA-512
In addition to needing to worry about keys that are too small to provide the required security, there are issues with keys that are too large. Denial of service attacks have been mounted with overly large keys. This has the potential to consume resources with potentially bad keys. There are two reasonable ways to address this attack. First, a key should not be used for a cryptographic operation until it has been matched back to an authorized user. This approach means that no cryptography would be done except for authorized users. Second, applications can impose maximum as well as minimum length requirements on keys. This limits the resources consumed even if the matching is not performed until the cryptography has been done.
There is a theoretical hash substitution attack that can be mounted against RSASSA-PSS. However, the requirement that the same hash function be used consistently for all operations is an effective mitigation against it. Unlike ECDSA, hash functions are not truncated so that the full hash value is always signed. The internal padding structure of RSASSA-PSS means that one needs to have multiple collisions between the two hash functions in order to be successful in producing a forgery based on changing the hash function. This is highly unlikely.
describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves. The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing and, HashEdDSA where a hash function is applied to the content before signing and the result of that hash function is signed. For use with COSE, on the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. Thus, the use of an incremental update process would not be useful. Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE message and the content as separate items.
The algorithms defined in this document can be found in . A single signature algorithm is defined which can be used for multiple curves.
name
value
description
EdDSA
*
EdDSA
describes the method of encoding the signature value.
When using a COSE key for this algorithm the following checks are made: The 'kty' field MUST be present and it MUST be 'OKP'.The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm.If the 'alg' field is present, it MUST match 'EdDSA'.If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature.If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature.
This document defines no new Message Authentication Code algorithms.
This document defines no new content inception algorithms.
This document defines new new key derivation functions.
RSAES-OAEP is an asymmetric key encryption algorithm. The defintion of RSAEA-OAEP can be find in Section 7.1 of . The algorithm is parameterized using a masking generation function (mgf), a hash function (h) and encoding parameters (P). For the algorithm identifiers defined in this section: mgf is always set to MFG1 from and uses the same hash function as h.P is always set to the empty octet string.
summarizes the rest of the values.
name
value
hash
description
RSAES-OAEP w/SHA-256
-25
SHA-256
RSAES OAEP w/ SHA-256
RSAES-OAEP w/SHA-512
-26
SHA-512
RSAES OAEP w/ SHA-512
The key type MUST be 'RSA'.
A key size of 2048 bits or larger MUST be used with these algorithms. This key size corresponds roughly to the same strength as provided by a 128-bit symmetric encryption algorithm.
It is highly recommended that checks on the key length be done before starting a decryption operation. One potential denial of service operation is to provide encrypted objects using either abnormally long or oddly sized RSA modulus values. Implementations SHOULD be able to encrypt and decrypt with modulus between 2048 and 16K bits in length. Applications can impose additional restrictions on the length of the modulus.
The algorithm ECDH is defined for use in COSE in . In this document the algorithm is extended to be used with the two curves defined in .
The following updates sections 12.4.1 and 12.5.1. OLD: The 'kty' field MUST be present and it MUST be 'EC2'.NEW: The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'.
All the rest of the checks remain the same.
The COSE_Key object defines a way to hold a single key object, it is still 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 types.
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. We define private members mainly for the purpose of archival of keys by individuals. However, there are some circumstances where private keys may be distributed by various entities in a protocol. Examples include: Entities which have poor random number generation. Centralized key creation for multi-cast type operations. Protocols where a shared secret is used as a bearer token for authorization purposes.
Key types are identified by the 'kty' member of the COSE_Key object. In this document we define four values for the member.
name
value
description
OPK
TBDXX
Octet Key Pair
RSA
TBDXX1
RSA Keys
A new key type is defined for Octet Key Pairs (OKP). 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).
The key parameters defined in this section are summarized in . The members that are defined for this key type are: contains an identifier of the curve to be used with the key. Is is the same registry for both OKP and EC2? The curves defined in this document for this key type can be found in . Other curves may be registered in the future and private curves can be used as well. contains the x coordinate for the EC point. The octet string represents a little-endian encoding of x. contains the private key.
For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space.
name
key type
value
type
description
crv
1
-1
int / tstr
EC Curve identifier - Taken from the COSE General Registry
x
1
-2
bstr
X Coordinate
d
1
-4
bstr
Private key
name
key type
value
description
Curve25519
EC1
TBDYY1
Curve 25519
Curve448
EC1
TBDYY2
Curve 448
This document defines a key structure for both the public and private halves of RSA keys. Together, an RSA public key and an RSA private key form an RSA key pair. Looking at the CBOR specification, the bstr that we are looking in our table below should most likely be specified as big numbers rather than as binary strings. This means that we would use the tag 6.2 instead. From my reading of the specification, there is no difference in the encoded size of the resulting output. The specification of bignum does explicitly allow for integers encoded with leading zeros.
The document also provides support for the so-called "multi-prime" RSA where the modulus may have more than two prime factors. The benefit of multi-prime RSA is lower computational cost for the decryption and signature primitives. For a discussion on how multi-prime affects the security of RSA crypto-systems, the reader is referred to .
This document follows the naming convention of for the naming of the fields of an RSA public or private key. The table provides a summary of the label values and the types associated with each of those labels. The requirements for fields for RSA keys are as follows: For all keys, 'kty' MUST be present and MUST have a value of 3. For public keys, the fields 'n' and 'e' MUST be present. All other fields defined in MUST be absent. For private keys with two primes, the fields 'other', 'r_i', 'd_i' and 't_i' MUST be absent, all other fields MUST be present. For private keys with more than two primes, all fields MUST be present. For the third to nth primes, each of the primes is represented as a map containing the fields 'r_i', 'd_i' and 't_i'. The field 'other' is an array of those maps.
name
key type
value
type
description
n
3
-1
bstr
Modulus Parameter
e
3
-2
int
Exponent Parameter
d
3
-3
bstr
Private Exponent Parameter
p
3
-4
bstr
First Prime Factor
q
3
-5
bstr
Second Prime Factor
dP
3
-6
bstr
First Factor CRT Exponent
dQ
3
-7
bstr
Second Factor CRT Exponent
qInv
3
-8
bstr
First CRT Coefficient
other
3
-9
array
Other Primes Info
r_i
3
-10
bstr
i-th factor, Prime Factor
d_i
3
-11
bstr
i-th factor, Factor CRT Exponent
t_i
3
-12
bstr
i-th factor, Factor CRT Coefficient
There are currently no registration requests here
There are currently no registration tasks inthis section.
It is requested that IANA create a new registry “COSE Key Type Parameters”.
The columns of the table are:
This field contains a descriptive string of a key type. This should be a value that is in the COSE General Values table and is placed in the 'kty' field of a COSE Key structure. This is a descriptive name that enables easier reference to the item. It is not used in the encoding. The label is to be unique for every value of key type. The range of values is from -256 to -1. Labels are expected to be reused for different keys. This field contains the CBOR type for the field This field contains a brief description for the field This contains a pointer to the public specification for the field if one exists
This registry will be initially populated by the values in , and . The specification column for all of these entries will be this document.
It is requested that IANA create a new registry “COSE Elliptic Curve Parameters”.
The columns of the table are:
This is a descriptive name that enables easier reference to the item. It is not used in the encoding. This is the value used to identify the curve. These values MUST be unique. The integer values from -256 to 255 are designated as Standards Track Document Required. The the integer values from 256 to 65535 and -65536 to -257 are designated as Specification Required. Integer values over 65535 are designated as first come first serve. Integer values less than -65536 are marked as private use. This designates the key type(s) that can be used with this curve. This field contains a brief description of the curve. This contains a pointer to the public specification for the curve if one exists.
This registry will be initially populated by the values in . The specification column for all of these entries will be this document.
There are security considerations:
Protect private keys MAC messages with more than one recipient means one cannot figure out who sent the message Use of direct key with other recipient structures hands the key to other recipients. Use of direct ECDH direct encryption is easy for people to leak information on if there are other recipients in the message. Considerations about protected vs unprotected header fields. Need to verify that: 1) the kty field of the key matches the key and algorithm being used. 2) that the kty field needs to be included in the trust decision as well as the other key fields. 3) that the algorithm be included in the trust decision.
Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Concise Binary Object Representation (CBOR)The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.
CBOR data definition language (CDDL): a notational convention to express CBOR data structuresThis document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR. HMAC: Keyed-Hashing for Message AuthenticationThis document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind S/MIME Version 3 Message SpecificationThis document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK] PKCS #5: Password-Based Cryptography Specification Version 2.0This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community. Advanced Encryption Standard (AES) Key Wrap Algorithm Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community. Counter with CBC-MAC (CCM)Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES). Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK] X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) CapabilitiesThis document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS-TRACK] Elliptic Curve Cryptography Subject Public Key InformationThis document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] Cryptographic Message Syntax (CMS)This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message SpecificationThis document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK] Multiple Signatures in Cryptographic Message Syntax (CMS)Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK] HMAC-based Extract-and-Expand Key Derivation Function (HKDF)This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS)The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44. Fundamental Elliptic Curve Cryptography AlgorithmsThis note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes. Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 AlgorithmsThis document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes. Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. The JavaScript Object Notation (JSON) Data Interchange FormatJavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. JSON Web Signature (JWS)JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Encryption (JWE)JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. JSON Web Key (JWK)A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Algorithms (JWA)This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. ChaCha20 and Poly1305 for IETF ProtocolsThis document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG). Elliptic Curves for SecurityThis memo specifies two elliptic curves over prime fields that offer high practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. Edwards-curve Digital Signature Algorithm (EdDSA)The elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA) is described. The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. CBOR Encoded Message SyntaxConcise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document specifies processing for signatures, message authentication codes, and encryption using CBOR. This document also specifies a representation for cryptographic keys using CBOR. NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.U.S. National Institute of Standards and TechnologyFIPS PUB 113: Computer Data AuthenticationDigital Signature Standard (DSS)U.S. National Institute of Standards and TechnologyNIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm CryptographyU.S. National Institute of Standards and TechnologyU.S. National Institute of Standards and TechnologyU.S. National Institute of Standards and TechnologyOrion Security Solutions, Inc.SEC 1: Elliptic Curve CryptographyStandards for Efficient Cryptography GroupOn the Security of Multi-prime RSAUniversity of WaterlooUniversity of WaterlooFormal Security Proofs for a Signature Scheme with Partial Message Recover