]> Yubico

Gävlegatan 22 Stockholm SE emil@emlun.se

Self-Issued Consulting

United States michael_b_jones@hotmail.com https://self-issued.info/

Security COSE COSE Signing Two-Party Algorithms This specification defines COSE algorithm identifiers used when the signing operation is performed cooperatively between two parties. When performing two-party signing, the first party typically hashes the data to be signed and the second party signs the hashed data computed by the first party. This can be useful when communication with the party holding the signing private key occurs over a limited-bandwidth channel, such as NFC or Bluetooth Low Energy (BLE), in which it is infeasible to send the complete set of data to be signed. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification procedure without additional steps to preprocess the signed data. About This Document Status information for this document may be found at . Discussion of this document takes place on the COSE Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction CBOR Object Signing and Encryption (COSE) algorithm identifiers are used to specify the cryptographic operations performed when creating cryptographic data structures, but do not record all the details of how the cryptography was performed, since those details are typically irrelevant for the recipient. The algorithm identifiers defined by this specification facilitate the cooperation of two parties to perform COSE signing operations together. They are used to specify the division of responsibilities between the two parties. Consumers of the cryptographic data structures thus cooperatively produced do not use these algorithm identifiers; rather, consumers use the normal COSE algorithm identifiers that correspond to the cryptographic operation cooperatively performed together by the two parties. A use case for this is performing a signature operation split between two parties, such as a software application and a discrete hardware security module (HSM) holding the private key. In particular, since the data link between them may have limited bandwidth, it may not be practical to send the entire original message to the HSM. Instead, since most signature algorithms begin with digesting the message into a fixed-length intermediate input, this initial digest can be computed by the software application while the HSM computes the rest of the signature algorithm on the digest. Since different signature algorithms digest the message in different ways and at different stages of the algorithm, there is no one generally-applicable way to define such a division point for every possible signature algorithm. Therefore, this specification defines algorithm identifiers encoding, for a specific set of signature algorithms, which steps of the signature algorithm are performed by the digester (e.g., software application) and which are performed by the signer (e.g., HSM). In general, the signer holds exclusive control of the signing private key. Note that these algorithm identifiers do not define new "pre-hashed" variants of the base signature algorithm, nor an intermediate "hash envelope" data structure, such as that defined in . Rather, these identifiers correspond to existing signature algorithms that would typically be executed by a single party, but split into two stages. The resulting signatures are identical to those computed by a single party, and can be verified using the same verification procedures without additional special steps to process the signed data. However some signature algorithms, for example, PureEdDSA and ML-DSA , cannot be split in this way and therefore cannot be assigned two-party signing algorithm identifiers. However, if such a signature algorithm defines a "pre-hashed" variant, such as Ed25519ph or HashML-DSA , that "pre-hashed" algorithm can also be assigned a two-party signing algorithm identifier, enabling the hashing step to be performed by the digester and the signing step to be executed by the signer.

Requirements Notation and Conventions 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 BCP 14 RFC2119 when, and only when, they appear in all capitals, as shown here.

Two-Party Signing Algorithms This section defines divisions of signing algorithm steps between a digester and a signer in a two-party signing protocol, and assigns algorithm identifiers to these algorithm divisions. The digester performs the first part of the divided algorithm and does not have access to the signing private key, while the signer performs the second part of the divided algorithm and has access to the signing private key. For signing algorithms that format the message to insert domain separation tags, as described in , this message formatting is also performed by the signer. The algorithm identifiers defined in this specification MUST NOT appear in COSE structures other than COSE_Key_Ref (see ). They are meant only for coordination between the digester and the signer in a two-party signing protocol. Representations of the keys used and the resulting signatures MUST use the corresponding conventional algorithm identifiers instead. These are listed in the "Base algorithm" column in the tables defining two-party signing algorithm identifiers.

ECDSA Two-party ECDSA uses the following division between the digester and the signer of the steps of the ECDSA signature generation algorithm :

• The signing procedure is defined in Section 6.4.1 of .
• The digester performs Step 1 of the signing procedure - hashing the message, producing the value H.
• The message input to the signer is the value H defined in the signing procedure.
• The signer resumes the signing procedure from Step 2.

The following algorithm identifiers are defined:

Name	COSE Value	Base algorithm	Description
ESP256-2p	TBD	ESP256	ESP256 divided for two-party signing as defined here
ESP384-2p	TBD	ESP384	ESP384 divided for two-party signing as defined here
ESP512-2p	TBD	ESP512	ESP512 divided for two-party signing as defined here

HashEdDSA Two-party HashEdDSA uses the following division between the digester and the signer of the steps of the HashEdDSA signing algorithm :

• HashEdDSA is a combination of the EdDSA signing procedure and the PureEdDSA signing procedure. The EdDSA signing procedure is defined in the first paragraph of . The PureEdDSA signing procedure is defined in the second paragraph of .
• The digester computes the value PH(M) defined in the EdDSA signing procedure.
• The message input to the signer is the value PH(M) defined in the EdDSA signing procedure. This value is represented as M in the PureEdDSA signing procedure.
• The signer executes the PureEdDSA signing procedure, where the value denoted M in the PureEdDSA signing procedure takes the value denoted PH(M) in the EdDSA signing procedure.

PureEdDSA cannot be divided in this way since such a division would require that the digester has access to the private key. The following algorithm identifiers are defined:

Name	COSE Value	Base algorithm	Description
Ed25519ph-2p	TBD	Ed25519ph	Ed25519ph divided for two-party signing as defined here (NOTE: Ed25519ph not yet registered)
Ed448ph-2p	TBD	Ed448ph	Ed448ph divided for two-party signing as defined here (NOTE: Ed448ph not yet registered)

HashML-DSA Two-party HashML-DSA uses the following division between the digester and the signer of the steps of the HashML-DSA.Sign algorithm:

• The signing procedure is defined in Section 5.4.1 of .
• The digester computes the value PH_M defined in Steps 10 to 22 of the signing procedure.
• The message input to the signer is the value PH_M defined in the signing procedure. The additional ctx input must also be transmitted to the signer. This may, for example, be done using the ctx (-1) parameter of a COSE_Key_Ref with kty (1): Ref-ML-DSA (TBD) (see and ).
• The signer executes all steps of the signing procedure except the Steps 13, 16, 19 or similar that compute the value PH_M. Note in particular, that the signer generates the value rnd in Steps 5-8 and constructs the value M' in Step 23.

The "pure" ML-DSA version cannot be divided in this way because of how the embedding of the ctx and tr values is constructed in ML-DSA.Sign and ML-DSA.Sign_Internal. A division like the one above for HashML-DSA would move control of this embedding from the signer to the digester. This would break the domain separation enforced by the embedding and possibly enable signature malleability attacks or protocol confusion attacks. The following algorithm identifiers are defined:

Name	COSE Value	Base algorithm	Description
HashML-DSA-44-2p	TBD	HashML-DSA-44	HashML-DSA-44 divided for two-party signing as defined here (NOTE: HashML-DSA-44 not yet registered)
HashML-DSA-65-2p	TBD	HashML-DSA-65	HashML-DSA-65 divided for two-party signing as defined here (NOTE: HashML-DSA-65 not yet registered)
HashML-DSA-87-2p	TBD	HashML-DSA-87	HashML-DSA-87 divided for two-party signing as defined here (NOTE: HashML-DSA-87 not yet registered)

COSE Key Reference Types While keys used by many algorithms can usually be referenced by a single atomic identifier, such as that used in the kid parameter in a COSE_Key object or in the unprotected header of a COSE_Recipient, some signature algorithms use additional parameters to the signature generation beyond the signing private key and message to be signed. For example, ML-DSA has the additional parameter ctx and ARKG-Derive-Private-Key has the parameters kh and info, in addition to the private key. While these additional parameters are simple to provide to the API of the signing procedure in a single-party context, in a two-party context these additional parameters also need to be conveyed from the digester to the signer. For this purpose, we define new COSE key types, collectively called "COSE key reference types". This enables defining a unified, algorithm-agnostic protocol between the digester and the signer, rather than requiring a distinct protocol for each signature algorithm for the sake of conveying algorithm-specific parameters. A COSE key reference is a COSE_Key object whose kty value is defined to represent a reference to a key. The kid parameter MUST be present when kty is a key reference type. These requirements are encoded in the CDDL type COSE_Key_Ref: $COSE_kty_ref ; kty: Any reference type 2 ^ => any, ; kid is required any => any, ; Any other entries allowed by COSE_Key } ]]> The following CDDL example represents a reference to an ML-DSA-65 key, which uses the AKP key type , along with the value of the ctx parameter to ML-DSA.Sign : The following CDDL example represents a reference to a key derived by ARKG-P256ADD-ECDH and restricted for use with the ESP256 signature algorithm:

IANA Considerations

COSE Algorithms Registrations This section registers the following values in the IANA "COSE Algorithms" registry :

• Name: ESP256-2p
  • Value: TBD (Requested Assignment -300)
  • Description: ESP256 divided for two-party signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: ESP384-2p
  • Value: TBD (Requested Assignment -301)
  • Description: ESP384 divided for two-party signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: ESP512-2p
  • Value: TBD (Requested Assignment -302)
  • Description: ESP512 divided for two-party signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: Ed25519ph-2p
  • Value: TBD (Requested Assignment -303)
  • Description: Ed25519ph divided for two-party signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: Ed448ph-2p
  • Value: TBD (Requested Assignment -304)
  • Description: Ed448ph divided for two-party signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: HashML-DSA-44-2p
  • Value: TBD (Requested Assignment -305)
  • Description: HashML-DSA-44 divided for two-party signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: HashML-DSA-65-2p
  • Value: TBD (Requested Assignment -306)
  • Description: HashML-DSA-65 divided for two-party signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: HashML-DSA-87-2p
  • Value: TBD (Requested Assignment -307)
  • Description: HashML-DSA-87 divided for two-party signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes

COSE Key Types Registrations This section registers the following values in the IANA "COSE Key Types" registry :

• Name: Ref-OKP
  • Value: TBD (Requested assignment -1)
  • Description: Reference to a key pair of key type "OKP"
  • Capabilities: [kty(-1), crv]
  • Reference: of this specification
• Name: Ref-EC2
  • Value: TBD (Requested assignment -2)
  • Description: Reference to a key pair of key type "EC2"
  • Capabilities: [kty(-2), crv]
  • Reference: of this specification
• Name: Ref-AKP
  • Value: TBD (Requested assignment -7)
  • Description: Reference to a key pair of key type "AKP"
  • Capabilities: [kty(TBD), ctx]
  • Reference: of this specification

These registrations add the following choices to the CDDL type socket $COSE_kty_ref:

COSE Key Type Parameters Registrations This section registers the following values in the IANA "COSE Key Type Parameters" registry :

• Key Type: TBD (Ref-AKP)
  • Name: ctx
  • Label: -1
  • CBOR Type: bstr
  • Description: ctx argument to ML-DSA.Sign or HashML-DSA.Sign
  • Reference: of this specification

References Normative References Yubico Yubico Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. mesur.io Transmute Google IBM NXP This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. Self-Issued Consulting Transmute This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc., as being "fully specified". Whereas, it refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully- specified algorithm identifiers for registered JOSE and COSE polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. IANA n.d. In 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. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (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 or JSON. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Certicom Research Informative References National Institute of Standards and Technology National Institute of Standards and Technology Transmute DataTrails Fraunhofer SIT This document defines new COSE header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation as access to the original payload is not required for signature validation. Additionally, hints of the detached payload's content format and availability are defined providing references to optional discovery mechanisms that can help to find original payload content. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Document History -01

• Added IANA registration requests for algorithms defined.
• Updated references and other editorial tweaks.

-00

• Initial individual draft