Split signing algorithms for COSE

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

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 8 January 2026.¶

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

CBOR Object Signing and Encryption (COSE) [RFC9052] algorithm identifiers are used to specify the cryptographic operations used to create cryptographic data structures, but do not record internal details of how the cryptography was performed, since those details are typically irrelevant for the recipient. The algorithm identifiers defined by this specification facilitate splitting a signing operation between two cooperating parties, by specifying the division of responsibilities between the two parties. The resulting signature can be verified by the same verification algorithm as if it had been created by a single party, so this division of responsibilities is an implementation detail of the signer. Verifiers therefore do not use these split algorithm identifiers, and instead use the corresponding non-split algorithm identifier which identifies the same verification algorithm as the split algorithm identifier would.¶

A primary use case for this is splitting a signature operation between 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 [I-D.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 algorithms without additional special steps to process the signed data.¶

However some signature algorithms, such as PureEdDSA [RFC8032], cannot be split in this way and therefore cannot be assigned split signing algorithm identifiers. However, if such a signature algorithm defines a "pre-hashed" variant, such as Ed25519ph [RFC8032], that "pre-hashed" algorithm can also be assigned a split signing algorithm identifier, enabling the hashing step to be performed by the digester and the signing step to be executed by the signer.¶

2. Split Signing Algorithms

This section defines divisions of signing algorithm steps between a digester and a signer in a split signing protocol, and assigns algorithm identifiers to these algorithm divisions. The digester performs the first part of the split algorithm and does not have access to the signing private key, while the signer performs the second part of the split 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 specification MAY appear in COSE structures used internally between the digester and the signer in a split signing protocol, but SHOULD NOT appear in COSE structures consumed by signature verifiers. COSE structures consumed by signature verifiers SHOULD instead use the corresponding conventional algorithm identifiers for the verification algorithm. These are listed in the "Verification algorithm" column in the tables defining split signing algorithm identifiers.¶

3. COSE Signing Arguments

While many signature algorithms take the private key and data to be signed as the only two parameters, some signature algorithms have additional parameters that must also be set. For example, to sign using a key derived by ARKG [I-D.bradleylundberg-ARKG], two additional arguments kh and info are needed in ARKG-Derive-Private-Key to derive the signing private key.¶

While such additional arguments are simple to provide to the API of the signing procedure in a single-party context, in a split signing context these additional arguments also need to be conveyed from the digester to the signer. For this purpose, we define a new COSE structure COSE_Sign_Args for "COSE signing arguments". 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.¶

COSE_Sign_Args is built on a CBOR map. The set of common parameters that can appear in a COSE_Sign_Args can be found in the IANA "COSE Signing Arguments Common Parameters" registry (TODO). Additional parameters defined for specific signing algorithms can be found in the IANA "COSE Signing Arguments Algorithm Parameters" registry (TODO).¶

The CDDL grammar describing COSE_Sign_Args, using the CDDL fragment defined in Section 1.5 of [RFC9052], is:¶

COSE_Sign_Args = {
    3 ^ => tstr / int,  ; alg
    * label => values,
}

{
  3: -65539,   ; alg: ESP256-split with ARKG-P256 (placeholder value)

               ; ARKG-P256 key handle
               ; (HMAC-SHA-256-128 followed by
                  SEC1 uncompressed ECDH public key)
  -1: h'27987995f184a44cfa548d104b0a461d
        0487fc739dbcdabc293ac5469221da91b220e04c681074ec4692a76ffacb9043de
          c2847ea9060fd42da267f66852e63589f0c00dc88f290d660c65a65a50c86361',

               ; info argument to ARKG-Derive-Private-Key
  -2: 'ARKG-P256.test vectors',
}

4. IANA Considerations

5. References

Document History

-02¶

• Renamed document from "COSE Algorithms for Two-Party Signing" to "Split signing algorithms for COSE" and updated introduction and terminology accordingly.¶

• Dropped definitions for HashML-DSA, as split variants of ML-DSA are being actively discussed in other IETF groups.¶

• Changed "Base algorithm" heading in definition tables to "Verification algorithm".¶

• Remodeled COSE_Key_Ref as COSE_Sign_Args.¶

  • Dropped definitions of reference types for COSE Key Types registry.¶

-01¶

• Added IANA registration requests for algorithms defined.¶

• Updated references and other editorial tweaks.¶

-00¶

• Initial individual draft¶

Authors' Addresses