]> 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 Algorithms Split Algorithms Split Signing ARKG 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. 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 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 , PKCS #11 , and PIV . 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. Security considerations for this split may also differ between 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 . 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 , 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, 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. For example, this specification defines Ed25519ph-split () as a split variant of Ed25519ph . Note that Ed25519 and Ed25519ph have distinct verification algorithms, but Ed25519ph and Ed25519ph-split use the same verification algorithm.

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.

Prior Art Split signing is a common technique used in existing smart card standards. The following subsections expand on how the technique is applied in OpenPGP , PKCS #11 , and PIV .

OpenPGP The OpenPGP smart card protocol defines the format of signing commands in section "7.2.10 PSO: COMPUTE DIGITAL SIGNATURE":

• 7.2.10 PSO: COMPUTE DIGITAL SIGNATURE The command for digital signature computation is shown in the table below. The hash value (ECDSA) or the DigestInfo is delivered in the data field of the command. [...]

The "Data field" parameter is subsequently defined as "Data to be integrated in the DSI: hash value (ELC) or DigestInfo (RSA)". Thus both ECDSA and RSA signatures are computed jointly by the host computing the digest of the signed data and the smart card finalizing the signature on the digest; the host acts as digester and the smart card acts as signer. TODO: Spec 3.4.1 only covers ECDSA and RSA, but some implementations also support Ed25519. Identify and include good references for how OpenPGP smart cards handle Ed25519.

PKCS #11 PKCS #11 defines signing commands in sections "5.13 Signing and MACing functions" and "5.14 Message-based signing and MACing functions". These sections define C_SignInit and C_MessageSignInit functions that both take a pMechanism parameter indicating the signature mechanism. Mechanisms are defined in section "6 Mechanisms", which notably includes the subsections "6.3.12 ECDSA without hashing" and "6.3.13 ECDSA with hashing":

• 6.3.12 ECDSA without hashing [...] The ECDSA without hashing mechanism, denoted CKM_ECDSA, is a mechanism for single-part signatures and verification for ECDSA. (This mechanism corresponds only to the part of ECDSA that processes the hash value, which should not be longer than 1024 bits; it does not compute the hash value.) [...]

• 6.3.13 ECDSA with hashing [...] The ECDSA with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512 mechanism, denoted CKM_ECDSA_[SHA1|SHA224|SHA256|SHA384|SHA512|SHA3_224|SHA3_256|SHA3_384|SHA3_512] respectively, is a mechanism for single- and multiple-part signatures and verification for ECDSA. This mechanism computes the entire ECDSA specification, including the hashing with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512 respectively. [...]

Thus PKCS #11 supports both split signing using the CKM_ECDSA mechanism and "non-split" signing using the CKM_ECDSA_SHA* mechanisms; when using CKM_ECDSA, the PKCS #11 caller acts as host and the Cryptoki implementation acts as signer.

PIV: FIPS-201, NIST SP 800 NIST Special Publication 800 contains technical specifications for the Personal Identity Verification (PIV) standard , and defines the format of signing commands in section "3.2.4. GENERAL AUTHENTICATE Card Command":

• 3.2.4. GENERAL AUTHENTICATE Card Command [...] The GENERAL AUTHENTICATE command SHALL be used with the digital signature key ('9C') to realize the signing functionality on the PIV client application programming interface. Data to be signed is expected to be hashed off-card. Appendix A.4 illustrates the use of the GENERAL AUTHENTICATE command for signature generation. [...]

Appendix A.4 gives examples of RSA and ECDSA signature generation commands. For RSA the command needs to be sent in two parts, giving the "Data Field" argument first as "'7C' – L1 { '82' '00' '81' L2 {first part of the PKCS #1 v1.5 or PSS padded message hash value }}" and then "{second and last part of the PKCS #1 v1.5 or PSS padded message hash value}"; for ECDSA the "Data Field" argument is given as "'7C' – L1 { '82' '00' '81' L2 {hash value of message}}". Thus both ECDSA and RSA signatures are computed jointly by the host computing the digest of the signed data and the smart card finalizing the signature on the digest; the host acts as digester and the smart card acts as signer.

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 , this message formatting is also performed by the signer. How the digest, and any related COSE_Sign_Args structure (see ), are transported from digester to signer is out of scope for this specification, but it is expected that the digest will usually be transmitted as the "data to be signed" argument. The algorithm identifiers defined in this specification with "-split" in their names 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. The following subsections define an initial set of split signing algorithm identifiers. The last subsection provides guidance for defining additional identifiers beyond this initial set.

ECDSA ECDSA split signing 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: ECDSA split signing algorithm values.

Name	COSE Value	Verification algorithm	Description
ESP256-split	TBD	ESP256	ESP256 split signing as defined in
ESP384-split	TBD	ESP384	ESP384 split signing as defined in
ESP512-split	TBD	ESP512	ESP512 split signing as defined in

Note: This is distinct from the similarly named Split-ECDSA (SECDSA) , although SECDSA can be implemented using this split procedure as a component.

HashEdDSA Split 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: HashEdDSA algorithm values.

Name	COSE Value	Verification algorithm	Description
Ed25519ph	TBD	Ed25519ph	EdDSA using the Ed25519ph parameter set in
Ed25519ph-split	TBD	Ed25519ph	EdDSA using the Ed25519ph parameter set in and split as defined in
Ed448ph	TBD	Ed448ph	EdDSA using the Ed448ph parameter set in
Ed448ph-split	TBD	Ed448ph	EdDSA using the Ed448ph parameter set in and split as defined in

ECDSA with ARKG TODO: Move to this document

Defining Split Signing Algorithms Future definitions of additional split signing algorithm identifiers SHOULD follow the conventions established in as far as possible. For example, if a signature algorithm prescribes insertion of domain separation tags in a way that requires processing the entirety of the data to be signed, it might be necessary to delegate the domain separation responsibility to the digester. Per the considerations in , split signing algorithm identifiers SHOULD be defined in ways that minimize how much responsibility is delegated to the digester. As a concrete example, consider ML-DSA and HashML-DSA . ML-DSA and HashML-DSA prefix the input data with a 0 octet and a 1 octet respectively, which enforces domain separation between ML-DSA and HashML-DSA signatures. describes a mode of ML-DSA that could be assigned a split signing algorithm identifier where the digester performs Computeμ and the signer performs Signμ. Note that this puts the digester in control of the domain separation tags; this is necessary if the hash step is not performed by the signer. Therefore with this construction, it is the digester that decides whether the signing protocol will produce an ML-DSA signature or a HashML-DSA signature. In contrast, HashML-DSA first hashes the input data alone and then another time with domain separation tags; therefore HashML-DSA can be assigned a split signing algorithm identifier that keeps the signer in control of the domain separation tags and ensures that the signing protocol can only produce HashML-DSA signatures.

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 , 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 established in . Additional parameters defined for specific signing algorithms can be found in the IANA "COSE Signing Arguments Algorithm Parameters" registry established in . The CDDL grammar describing COSE_Sign_Args, using the CDDL fragment defined in , is: tstr / int, ; alg * label => values, } ]]>

COSE Signing Arguments Common Parameters This document defines a set of common parameters for a COSE Signing Arguments object. provides a summary of the parameters defined in this section. Common parameters of the COSE_Sign_Args structure.

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 ) and a key derived using ARKG-P256 :

Security Considerations

Protocol-Level Trusted Roles This specification assumes that both the digester and signer roles described in are trusted and cooperate honestly. This is because a similar division between "application" and "secure element" typically exists already: even if all steps of the signing algorithm are executed in a trusted secure element, the inputs to the secure element are provided by some outside component such as a software application. If the application can provide any input to be signed, then for all practical purposes it is trusted with possession of any private keys for as long as it is authorized to exercise the secure element. The application can in practice obtain a signature over any chosen message without needing to perform a forgery attack. The same relationship exists between digester and signer. Applications that cannot trust an external digester - for example a hardware security device with an integrated secure display of what data is about to be signed - by definition have no use for split signing algorithm identifiers. Similarly from a verifier's perspective, these split signing procedures are implementation details. 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. 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.

Component-Level Trusted Roles The reasoning in 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 - any that could not be produced by simply requesting a signature over the desired message - or extract secrets from the signer. For example, for ECDSA (), 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 make forgeries easier, 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. For example, a naively prehashed version of FALCON would allow such a key compromise: A FALCON signature is a value s such that both s and s * h - hash(r || m) are short, where h is the public key and r a randomizer. If the digester gets to query the signer for signatures of arbitrary stand-ins for hash(r || m), they can extract the private key by for example asking for repeated signatures of 0. Therefore, definitions of split signing algorithms need to be reviewed and potentially have security proofs adjusted.

Incorrect Use of Split Signing Algorithm Identifiers recommends against exposing split signing algorithm identifiers - including those defined in this specification with "-split" in their names - to signature verifiers. For example, they should not appear as the "alg" parameter of a COSE_Key public key sent to a signature verifier. If a split signing algorithm identifier is encountered in an invalid context like this, the recipient SHOULD reject the message with a fatal error. This is because the purpose of these split signing algorithm identifiers is to enable more flexible production of signatures that can be verified by existing implementations of existing verification algorithms. A prevalence of these identifiers appearing outside the split signing context would defeat this purpose; we therefore recommend such use SHOULD NOT be tolerated. This recommendation is the opposite of the oft-cited "robustness principle" stated in paragraph 3.9 of . Implementations MAY choose to instead follow the robustness principle and tolerate incorrect use of split signing algorithm identifiers, instead interpreting the identifier as referencing the defined corresponding verification algorithm. Note however that this is no longer considered a best practice and is likely to harm interoperability . A verifier's choice to tolerate or not tolerate incorrect use of split signing algorithm identifiers is expected to not affect security, assuming a split algorithm identifier is interpreted as an alias representing the same verification algorithm as a non-split algorithm identifier.

Implementation Considerations

Using Non-Split Signing Algorithm Identifiers in a Split Signing Protocol A protocol designed to use split signing algorithm identifiers such as those defined in this specification MAY also allow use of algorithm identifiers that do not represent split signing algorithms. In this case, the signer performs all steps of the signing procedure as usual. For example, if the signer receives a signature request with an the algorithm identifier "ESP256", then the digester passes the input data through unmodified and it is the signer that computes the SHA-256 digest of the input data as defined in the ESP256 definition .

IANA Considerations

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

• Name: ESP256-split
  • Value: TBD (Requested Assignment -300)
  • Description: ESP256 split signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: ESP384-split
  • Value: TBD (Requested Assignment -301)
  • Description: ESP384 split signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: ESP512-split
  • Value: TBD (Requested Assignment -302)
  • Description: ESP512 split signing
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: Ed25519ph
  • Value: TBD
  • Description: EdDSA using the Ed25519ph parameter set in
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference:
  • Recommended: Yes
• Name: Ed25519ph-split
  • Value: TBD (Requested Assignment -303)
  • Description: Ed25519ph split as defined in
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: Ed448ph
  • Value: TBD
  • Description: EdDSA using the Ed448ph parameter set in
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference:
  • Recommended: Yes
• Name: Ed448ph-split
  • Value: TBD (Requested Assignment -304)
  • Description: Ed448ph split as defined in
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: of this specification
  • Recommended: Yes
• Name: ESP256-ARKG
  • Value: TBD
  • Description: ESP256 using private key derived by ARKG-P256
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: ,
  • Recommended: TBD
• Name: ESP256-split-ARKG
  • Value: TBD (placeholder -65539)
  • Description: ESP256-split using private key derived by ARKG-P256
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: This document,
  • Recommended: TBD
• Name: ESP384-ARKG
  • Value: TBD
  • Description: ESP384 using private key derived by ARKG-P384
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: ,
  • Recommended: TBD
• Name: ESP384-split-ARKG
  • Value: TBD
  • Description: ESP384-split using private key derived by ARKG-P384
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: This document,
  • Recommended: TBD
• Name: ESP512-ARKG
  • Value: TBD
  • Description: ESP512 using private key derived by ARKG-P521
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: ,
  • Recommended: TBD
• Name: ESP512-split-ARKG
  • Value: TBD
  • Description: ESP512-split using private key derived by ARKG-P521
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: This document,
  • Recommended: TBD
• Name: ESP256K-ARKG
  • Value: TBD
  • Description: ESP256K using private key derived by ARKG-P256k
  • Capabilities: [kty]
  • Change Controller: IETF
  • Reference: [RFC8812],
  • Recommended: TBD

COSE Signing Arguments Common Parameters Registry This specification establishes the "COSE Signing Arguments Common Parameters" registry. The registry uses the "Expert Review Required" registration procedure. Guidelines for the experts are the same as those in . It should be noted that, in addition to the expert review, some portions of the registry require a specification, potentially a Standards Track RFC, be supplied as well. The columns of the registry are:

Name:

A descriptive name that enables easier reference to the item. It is not used in the encoding.

Label:

The value used as the CBOR map label for this parameter. Labels MUST be unique. The label can be a positive integer, a negative integer, or a string. Integer values between 0 and 255 and strings of length 1 are designated as "Standards Action". Integer values from 256 to 65535 and strings of length 2 are designated as "Specification Required". Integer values of greater than 65535 and strings of length greater than 2 are designated as "Expert Review". Integer values in the range -65536 to -1 are "used for signing arguments specific to a single algorithm delegated to the COSE Signing Arguments Algorithm Parameters registry". Integer values less than -65536 are marked as private use.

CBOR Type:

The CBOR type of the parameter's value.

Value Registry:

The registry that values come from, if one exists.

Description:

A brief description for the parameter.

Reference:

A pointer to the public specification for the parameter, if one exists.

Initial Contents The initial contents of this registry are the values in . All of the entries in the "References" column of this registry point to this document.

COSE Signing Arguments Algorithm Parameters Registry This specification establishes the "COSE Signing Arguments Algorithm Parameters" registry. The registry uses the "Expert Review Required" registration procedure. Guidelines for the experts are the same as those in . The columns of the table are:

Name:

A descriptive name that enables easier reference to the item. It is not used in the encoding.

Algorithms:

The algorithm(s) that this registry entry is used for. Values are taken from the "COSE Algorithms" registry. Multiple algorithms can be specified in this entry. For the table, the algorithm/label pair MUST be unique.

Label:

The value used as the CBOR map label for this parameter. The label is a negative integer value in the range -65536 to -1. Labels are expected to be reused for multiple algorithms.

CBOR Type:

The CBOR type of the parameter's value.

Required:

"Required" if the parameter is required for this algorithm, otherwise "Optional".

Description:

A brief description for the parameter.

Reference:

A pointer to the public specification for the parameter, if one exists.

Initial Contents The initial contents of this registry are as follows. These values come from .

kh

Name:

kh

Algorithms:

ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-split-ARKG, ESP512-ARKG, ESP512-split-ARKG, ESP256K-ARKG

Label:

-1

Cbor Type:

bstr

Required:

Required

Description:

kh argument to ARKG-Derive-Private-Key.

Reference:

ctx

Name:

ctx

Algorithms:

ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-split-ARKG, ESP512-ARKG, ESP512-split-ARKG, ESP256K-ARKG

Label:

-2

Cbor Type:

bstr

Required:

Required

Description:

ctx argument to ARKG-Derive-Private-Key.

Reference:

Implementation Status This section is to be removed from the specification by the RFC Editor before publication as an RFC. There are currently two known implementations using features defined by this specification:

• wwWallet, an EU Digital Identity pilot project. wwWallet was entered into the "EUDI Wallet Prototypes" competition held by SprinD GmbH, and a branch of the wallet was submitted in the competition. The competition entry implements ARKG for efficiently generating single-use hardware-bound holder binding keys. The implementation uses the COSE_Key_Ref data structure defined in version 01 of this specification in order to send ARKG inputs to a WebAuthn authenticator, and uses the placeholder value for the experimental split algorithm identifier ESP256-split-ARKG defined in Section 5.2 of to negotiate creation and usage of ARKG-derived keys for signing operations. Thus wwWallet assumes the digester role while the WebAuthn authenticator assumes the signer role.
• Yubico, a hardware security key vendor, has produced limited-availability prototypes of their YubiKey product with an ARKG implementation interoperable with wwWallet. The YubiKey implementation uses the COSE_Key_Ref data structure defined in version 01 of this specification to receive ARKG inputs from a WebAuthn Relying Party, and uses the placeholder value for the experimental split algorithm identifier ESP256-split-ARKG defined in Section 5.2 of to negotiate creation and usage of ARKG-derived keys for signing operations. Thus the YubiKey assumes the signer role while the WebAuthn Relying Party assumes the digester role.

summarizes implementation status for individual features. Implementation status of individual features.

Feature	Defined by	Digester	Signer
ESP256-split	This specification	-	-
ESP384-split	This specification	-	-
ESP512-split	This specification	-	-
Ed25519ph-split	This specification	-	-
Ed448ph-split	This specification	-	-
ESP256-split-ARKG		wwWallet	Yubico
ESP384-split-ARKG		-	-
ESP512-split-ARKG		-	-
COSE_Sign_Args	This specification	wwWallet	Yubico

Dependent Specifications This specification is mutually dependent on :

• duplicates the definitions of the COSE algorithm identifiers ESP256-ARKG, ESP256-split-ARKG, ESP384-ARKG, ESP384-split-ARKG, ESP512-ARKG and ESP512-split-ARKG registered in of this specification.
• The initial contents of the COSE Signing Arguments Algorithm Parameters Registry registered in are defined in .

These sections of will likely be moved to in a future revision 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. 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. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". 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 JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. Certicom Research Informative References National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology 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 hashed payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find original payload content. National Institute of Standards and Technology, Gaithersburg, MD National Institute of Standards and Technology, Gaithersburg, MD National Institute of Standards and Technology, Gaithersburg, MD National Institute of Standards and Technology, Gaithersburg, MD National Institute of Standards and Technology, Gaithersburg, MD NIST Special Publication (SP) NIST SP 800-73pt2-5 Latest stage: https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/pkcs11-spec-v3.1.html. OASIS Standard Version 3.4.1 The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. 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. The main goal of the networking standards process is to enable the long-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem. The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described.

Acknowledgements We would like to thank David Dong, Ilari Liusvaara, Lucas Prabel, Sophie Schmieg, and Falko Strenzke for their reviews of and contributions to this specification.

Document History -00

• Created initial working group draft from draft-lundberg-cose-two-party-signing-algs-07