COSE E. Lundberg, Ed. Internet-Draft Yubico Intended status: Standards Track M. B. Jones Expires: 22 August 2025 Self-Issued Consulting 18 February 2025 COSE Algorithms for Two-Party Signing draft-lundberg-cose-two-party-signing-algs-00 Abstract 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 This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-lundberg-cose-two-party- signing-algs/. Discussion of this document takes place on the COSE Working Group mailing list (mailto:cose@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/cose/. Subscribe at https://www.ietf.org/mailman/listinfo/cose/. Source for this draft and an issue tracker can be found at https://github.com/YubicoLabs/cose-two-party-signing-algs-rfc. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Lundberg & Jones Expires 22 August 2025 [Page 1] Internet-Draft COSE Algs for Two-Party Signing February 2025 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 August 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 4 2. Two-Party Signing Algorithms . . . . . . . . . . . . . . . . 4 2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. HashEdDSA . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. HashML-DSA . . . . . . . . . . . . . . . . . . . . . . . 6 3. COSE Key Reference Types . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.1. COSE Key Types Registrations . . . . . . . . . . . . . . 9 4.2. COSE Key Type Parameters Registrations . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 5.2. Informative References . . . . . . . . . . . . . . . . . 11 Document History . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Lundberg & Jones Expires 22 August 2025 [Page 2] Internet-Draft COSE Algs for Two-Party Signing February 2025 1. Introduction CBOR Object Signing and Encryption (COSE) [RFC9052] 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 generally- applicable way to define such a division point for every possible signature algorithm. Therefore, this document 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 [COSE-Hash-Envelope]. 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. Lundberg & Jones Expires 22 August 2025 [Page 3] Internet-Draft COSE Algs for Two-Party Signing February 2025 However some signature algorithms, for example, PureEdDSA [RFC8032] and ML-DSA [FIPS-204], 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 [RFC8032] or HashML-DSA [FIPS-204], 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_. 1.1. 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 [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. 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 Section 2.2.5 of [RFC9380], this message formatting is also performed by the _signer_. The algorithm identifiers defined in this document MUST NOT appear in COSE structures other than COSE_Key_Ref (see Section 3). 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. 2.1. ECDSA Two-party ECDSA [FIPS-186-5] uses the following division between the _digester_ and the _signer_ of the steps of the ECDSA signature generation algorithm [FIPS-186-5]: * The signing procedure is defined in Section 6.4.1 of [FIPS-186-5]. Lundberg & Jones Expires 22 August 2025 [Page 4] Internet-Draft COSE Algs for Two-Party Signing February 2025 * 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 | Base | Description | | | Value | algorithm | | +===========+=======+===========+==============================+ | ESP256-2p | TBD | ESP256 | ESP256 [fully-spec-algs] | | | | | divided as defined in | | | | | Section 2.1 of this document | +-----------+-------+-----------+------------------------------+ | ESP384-2p | TBD | ESP384 | ESP384 [fully-spec-algs] | | | | | divided as defined in | | | | | Section 2.1 of this document | +-----------+-------+-----------+------------------------------+ | ESP512-2p | TBD | ESP512 | ESP512 [fully-spec-algs] | | | | | divided as defined in | | | | | Section 2.1 of this document | +-----------+-------+-----------+------------------------------+ Table 1 2.2. HashEdDSA Two-party HashEdDSA [RFC8032] uses the following division between the _digester_ and the _signer_ of the steps of the HashEdDSA signing algorithm [RFC8032]: * 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 Section 3.3 of [RFC8032]. The PureEdDSA signing procedure is defined in the second paragraph of Section 3.3 of [RFC8032]. * 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. Lundberg & Jones Expires 22 August 2025 [Page 5] Internet-Draft COSE Algs for Two-Party Signing February 2025 * 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 [RFC8032] 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 | Base | Description | | | Value | algorithm | | +==============+=======+===========+=============================+ | Ed25519ph-2p | TBD | Ed25519ph | Ed25519ph [fully-spec-algs] | | | | | divided as defined in | | | | | Section 2.2 of this | | | | | document (NOTE: Ed25519ph | | | | | not yet registered) | +--------------+-------+-----------+-----------------------------+ | Ed448ph-2p | TBD | Ed448ph | Ed448ph [fully-spec-algs] | | | | | divided as defined in | | | | | Section 2.2 of this | | | | | document (NOTE: Ed448ph not | | | | | yet registered) | +--------------+-------+-----------+-----------------------------+ Table 2 2.3. HashML-DSA Two-party HashML-DSA [FIPS-204] 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 [FIPS-204]. * 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 Section 4.1 and Section 4.2). Lundberg & Jones Expires 22 August 2025 [Page 6] Internet-Draft COSE Algs for Two-Party Signing February 2025 * 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 [FIPS-204] 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 | Base | Description | | | Value | algorithm | | +==================+=======+===============+======================+ | HashML-DSA-44-2p | TBD | HashML-DSA-44 | HashML-DSA-44 TODO: | | | | | divided as defined | | | | | in Section 2.3 of | | | | | this document (NOTE: | | | | | HashML-DSA-44 not | | | | | yet registered) | +------------------+-------+---------------+----------------------+ | HashML-DSA-65-2p | TBD | HashML-DSA-65 | HashML-DSA-65 TODO: | | | | | divided as defined | | | | | in Section 2.3 of | | | | | this document (NOTE: | | | | | HashML-DSA-65 not | | | | | yet registered) | +------------------+-------+---------------+----------------------+ | HashML-DSA-87-2p | TBD | HashML-DSA-87 | HashML-DSA-87 TODO: | | | | | divided as defined | | | | | in Section 2.3 of | | | | | this document (NOTE: | | | | | HashML-DSA-87 not | | | | | yet registered) | +------------------+-------+---------------+----------------------+ Table 3 Lundberg & Jones Expires 22 August 2025 [Page 7] Internet-Draft COSE Algs for Two-Party Signing February 2025 3. COSE Key Reference Types While keys used by many other 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 [FIPS-204] has the additional parameter _ctx_ and ARKG-Derive-Secret-Key [ARKG] 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 [RFC8610] type COSE_Key_Ref: COSE_Key_Ref = COSE_Key .within { 1 ^ => $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 [COSE-ML-DSA], along with the value of the _ctx_ parameter to ML-DSA.Sign [FIPS-204]: { 1: TBD, ; kty: Ref-AKP ; kid: Opaque identifier of the AKP key 2: h'92bc2bfa738f5bb07803fb9c0c58020791acd29fbe253baa7a03ac84f4b26d44', 3: TBD, ; alg: ML-DSA-65 ; ctx argument to ML-DSA.Sign -1: 'Example application info', } Lundberg & Jones Expires 22 August 2025 [Page 8] Internet-Draft COSE Algs for Two-Party Signing February 2025 The following CDDL example represents a reference to a key derived by ARKG-P256ADD-ECDH [ARKG] and restricted for use with the ESP256 [fully-spec-algs] signature algorithm: { 1: -65538, ; kty: Ref-ARKG-derived ; kid: Opaque identifier of ARKG-pub 2: h'60b6dfddd31659598ae5de49acb220d8 704949e84d484b68344340e2565337d2', 3: -9, ; alg: ESP256 ; ARKG-P256ADD-ECDH key handle ; (HMAC-SHA-256-128 followed by SEC1 uncompressed ECDH public key) -1: h'ae079e9c52212860678a7cee25b6a6d4 048219d973768f8e1adb8eb84b220b0ee3 a2532828b9aa65254fe3717a29499e9b aee70cea75b5c8a2ec2eb737834f7467 e37b3254776f65f4cfc81e2bc4747a84', ; info argument to ARKG-Derive-Private-Key -2: 'Example application info', } 4. IANA Considerations 4.1. COSE Key Types Registrations This section registers the following values in the IANA "COSE Key Types" registry [IANA.COSE]: * Name: Ref-OKP - Value: TBD (Requested assignment -1) - Description: Reference to a key pair of key type "OKP" - Capabilities: [kty(-1), crv] - Reference: Section 3 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] Lundberg & Jones Expires 22 August 2025 [Page 9] Internet-Draft COSE Algs for Two-Party Signing February 2025 - Reference: Section 3 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: Section 3 of this specification These registrations add the following choices to the CDDL [RFC8610] type socket $COSE_kty_ref: $COSE_kty_ref /= -1 ; Value TBD $COSE_kty_ref /= -2 ; Value TBD $COSE_kty_ref /= TBD ; Value TBD 4.2. COSE Key Type Parameters Registrations This section registers the following values in the IANA "COSE Key Type Parameters" registry [IANA.COSE]: * Key Type: TBD (Ref-AKP) - Name: ctx - Label: -1 - CBOR Type: bstr - Description: ctx argument to ML-DSA.Sign or HashML-DSA.Sign - Reference: Section 3 of this specification 5. References 5.1. Normative References [COSE-ML-DSA] Prorock, M., Steele, O., Misoczki, R., Osborne, M., and C. Cloostermans, "ML-DSA for JOSE and COSE", 2024, . Lundberg & Jones Expires 22 August 2025 [Page 10] Internet-Draft COSE Algs for Two-Party Signing February 2025 [fully-spec-algs] Jones, M. B. and O. Steele, "Fully-Specified Algorithms for JOSE and COSE", 2024, . [IANA.COSE] IANA, "CBOR Object Signing and Encryption (COSE)", n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380, DOI 10.17487/RFC9380, August 2023, . [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", May 2009, . 5.2. Informative References Lundberg & Jones Expires 22 August 2025 [Page 11] Internet-Draft COSE Algs for Two-Party Signing February 2025 [ARKG] Lundberg, E. and J. Bradley, "The Asynchronous Remote Key Generation (ARKG) algorithm", 2024, . [COSE-Hash-Envelope] Steele, O., Lasker, S., and H. Birkholz, "COSE Hash Envelope", 2024, . [FIPS-186-5] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", February 2023, . [FIPS-204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", August 2024, . Document History -00 * Initial individual draft Authors' Addresses Emil Lundberg (editor) Yubico Kungsgatan 44 Stockholm Sweden Email: emil@emlun.se Michael B. Jones Self-Issued Consulting United States Email: michael_b_jones@hotmail.com URI: https://self-issued.info/ Lundberg & Jones Expires 22 August 2025 [Page 12]