| Internet-Draft | Split signing algorithms for COSE | November 2025 |
| Lundberg & Jones | Expires 7 May 2026 | [Page] |
This specification defines COSE algorithm identifiers for negotiating how to split a signature algorithm between two cooperating parties. Typically the first party hashes the data to be signed and the second party finishes the signature over the hashed data. This is a common technique, useful for example when the signing private key is held in a smart card or similar hardware component with limited processing power and communication bandwidth. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification algorithm without additional steps to preprocess the signed data.¶
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.¶
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 7 May 2026.¶
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.¶
CBOR Object Signing and Encryption (COSE) [RFC9052] algorithm identifiers are used for algorithm negotiation and to annotate cryptographic objects with how to interpret them, for example which algorithm to use to verify a signature or decapsulate a shared key. Existing COSE algorithm identifiers omit some internal details of how the object was constructed, since those details are typically irrelevant for the recipient.¶
The algorithm identifiers defined in this specification are meant for a complementary use case: to divide responsibilities during construction of a cryptographic object, instead of describing how to consume the object. Specifically, they provide an interoperable way to negotiate how a signing operation is split between two cooperating parties, for example, a smart card and a software application, while the verification algorithm for the resulting signature remains the same as if the signature was created by a single party. These split algorithm identifiers are therefore not meant for annotating signature objects, since the verification algorithm is better indicated using already existing algorithm identifiers.¶
As mentioned above, a primary use case for this is for algorithm negotiation between a software application and a smart card or other hardware security module (HSM) holding the signing private key. Since the HSM may have limited processing power and communication 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 performs the rest of the signature algorithm on the digest. This is a common technique used in standards such as OpenPGP [OPENPGPCARD], PKCS #11 [PKCS11-Spec-v3.1], and PIV [FIPS-201].¶
Since different signature algorithms digest the message in different ways and at different stages of the algorithm, it is not possible for a cryptographic API to specify that, for example, "the hash digest is computed by the caller" generically for all algorithms. Instead, the algorithm identifiers defined in this specification enable the parties of that cryptographic API to signal precisely, for each signature algorithm individually, which steps of the algorithm are performed by which party. We thus define two roles: the digester (e.g., a software application) that initializes the signing procedure, and the signer (e.g., an HSM) that 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 denote existing signature algorithms that would typically be executed by a single party, but split into two stages.¶
Some signature algorithms, such as PureEdDSA [RFC8032], by their design, 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 be assigned a split signing algorithm identifier, enabling the pre-hashing step to be performed by the digester and the remaining steps by the signer.¶
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.¶
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.¶
ECDSA [FIPS-186-5] split signing 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].¶
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 | Verification algorithm | Description |
|---|---|---|---|
| ESP256-split | TBD | ESP256 | ESP256 split signing as defined in Section 2.1 |
| ESP384-split | TBD | ESP384 | ESP384 split signing as defined in Section 2.1 |
| ESP512-split | TBD | ESP512 | ESP512 split signing as defined in Section 2.1 |
Note: This is distinct from the similarly named Split-ECDSA (SECDSA) [SECDSA], although SECDSA can be implemented using this split procedure as a component.¶
Split 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.¶
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 Value | Verification algorithm | Description |
|---|---|---|---|
| Ed25519ph | TBD | Ed25519ph | EdDSA using the Ed25519ph parameter set in Section 5.1 of [RFC8032] |
| Ed25519ph-split | TBD | Ed25519ph | EdDSA using the Ed25519ph parameter set in Section 5.1 of [RFC8032] and split as defined in Section 2.2 |
| Ed448ph | TBD | Ed448ph | EdDSA using the Ed448ph parameter set in Section 5.2 of [RFC8032] |
| Ed448ph-split | TBD | Ed448ph | EdDSA using the Ed448ph parameter set in Section 5.2 of [RFC8032] and split as defined in Section 2.2 |
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 ctx 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,
}
¶
This document defines a set of common parameters for a COSE Signing Arguments object. Table 3 provides a summary of the parameters defined in this section.¶
| Name | Label | CBOR Type | Value Registry | Description |
|---|---|---|---|---|
| alg | 3 | tstr / int | COSE Algorithms | Signing algorithm to use |
alg: This parameter identifies the signing algorithm the additional arguments apply to. The signer MUST verify that this algorithm matches any key usage restrictions set on the key to be used. If the algorithms do not match, then the signature operation MUST be aborted with an error.¶
Definitions of COSE algorithms MAY define additional algorithm-specific parameters for COSE_Sign_Args.¶
The following CDDL example conveys additional arguments for signing data
using the ESP256-split algorithm (see Section 2.1)
and a key derived using ARKG-P256 [I-D.bradleylundberg-ARKG]:¶
{
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',
; ctx argument to ARKG-Derive-Private-Key
-2: 'ARKG-P256.test vectors',
}
¶
This specification assumes that both the digester and signer roles described in Section 2 are trusted and cooperate honestly. This is because these split signing procedures concern details that are considered implementation details from a verifier's perspective. When a signature is generated by a single party, that single party takes on both the digester and the signer roles, and obviously trusts itself to perform the digester role honestly. This assumption is carried forward for the split signing use case: the digester is assumed trusted, since it is part of the overall procedure of generating a signature over some input data. From the verifier's perspective, a malicious digester in the split signing model would have the same powers as a malicious signature generator in a single-party signing model. Thus, on the application or protocol level, assuming an honest digester is no more restrictive than assuming an honest signature generator.¶
The reasoning in Section 4.1 does not hold on the component level. A signer implementation MUST NOT assume that the digester implementation it interoperates with is necessarily honest. Split signing algorithms MUST NOT be defined in a way that enables a malicious digester with access to an honest signer to produce forgeries or extract secrets from the signer.¶
For example, for ECDSA (Section 2.1), a malicious digester can choose H in such a way that the signer will derive any digester-chosen value of e, including zero or other potentially problematic values. Fortunately, in this case, this does not enable the digester to extract the signature nonce or private key. It also does not enable forgeries, since the digester still needs to find a preimage of e for the relevant hash function. Definitions of other algorithms need to ensure that similar chosen-input attacks do not enable extracting secrets or forging protocol-level messages.¶
This section registers the following values in the IANA "COSE Algorithms" registry [IANA.COSE]:¶
Name: ESP256-split¶
Name: ESP384-split¶
Name: ESP512-split¶
Name: Ed25519ph¶
Value: TBD¶
Description: EdDSA using the Ed25519ph parameter set in Section 5.1 of [RFC8032]¶
Capabilities: [kty]¶
Change Controller: IETF¶
Reference: Section 5.1 of [RFC8032]¶
Recommended: Yes¶
Name: Ed25519ph-split¶
Value: TBD (Requested Assignment -303)¶
Description: Ed25519ph split as defined in Section 2.2¶
Capabilities: [kty]¶
Change Controller: IETF¶
Reference: Section 2.2 of this specification¶
Recommended: Yes¶
Name: Ed448ph¶
Value: TBD¶
Description: EdDSA using the Ed448ph parameter set in Section 5.2 of [RFC8032]¶
Capabilities: [kty]¶
Change Controller: IETF¶
Reference: Section 5.2 of [RFC8032]¶
Recommended: Yes¶
Name: Ed448ph-split¶
Value: TBD (Requested Assignment -304)¶
Description: Ed448ph split as defined in Section 2.2¶
Capabilities: [kty]¶
Change Controller: IETF¶
Reference: Section 2.2 of this specification¶
Recommended: Yes¶
-03¶
Updated reference to ARKG parameter info renamed to ctx.¶
Refined abstract and introduction to emphasize that the central novelty is not split algorithms as a concept, but providing COSE algorithm identifiers for use cases that benefit from such splitting.¶
Replaced reference to draft-ietf-jose-fully-specified-algorithms with RFC 9864.¶
Added inline definitions of Ed25519ph and Ed448ph registrations, replacing speculative references to registrations that do not exist elsewhere.¶
Added missing captions to Tables 1 and 2.¶
Added Security Considerations section.¶
-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¶