COSE Algorithms for Two-Party Signing
draft-lundberg-cose-two-party-signing-algs-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Emil Lundberg , Michael B. Jones | ||
| Last updated | 2025-03-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lundberg-cose-two-party-signing-algs-01
COSE E. Lundberg, Ed.
Internet-Draft Yubico
Intended status: Standards Track M. B. Jones
Expires: 4 September 2025 Self-Issued Consulting
3 March 2025
COSE Algorithms for Two-Party Signing
draft-lundberg-cose-two-party-signing-algs-01
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 4 September 2025 [Page 1]
Internet-Draft COSE Algs for Two-Party Signing March 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 4 September 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 Algorithms Registrations . . . . . . . . . . . . . . 9
4.2. COSE Key Types Registrations . . . . . . . . . . . . . . 12
4.3. COSE Key Type Parameters Registrations . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . 13
5.2. Informative References . . . . . . . . . . . . . . . . . 14
Document History . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Lundberg & Jones Expires 4 September 2025 [Page 2]
Internet-Draft COSE Algs for Two-Party Signing March 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 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 procedures without additional
special steps to process the signed data.
Lundberg & Jones Expires 4 September 2025 [Page 3]
Internet-Draft COSE Algs for Two-Party Signing March 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 specification 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 4 September 2025 [Page 4]
Internet-Draft COSE Algs for Two-Party Signing March 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 |
| | | | [I-D.jose-fully-spec-algs] |
| | | | divided for two-party |
| | | | signing as defined here |
+-----------+-------+-----------+-----------------------------------+
| ESP384-2p | TBD | ESP384 | ESP384 |
| | | | [I-D.jose-fully-spec-algs] |
| | | | divided for two-party |
| | | | signing as defined here |
+-----------+-------+-----------+-----------------------------------+
| ESP512-2p | TBD | ESP512 | ESP512 |
| | | | [I-D.jose-fully-spec-algs] |
| | | | divided for two-party |
| | | | signing as defined here |
+-----------+-------+-----------+-----------------------------------+
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.
Lundberg & Jones Expires 4 September 2025 [Page 5]
Internet-Draft COSE Algs for Two-Party Signing March 2025
* 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 | Base | Description |
| | Value | algorithm | |
+==============+=======+===========+===============================+
| Ed25519ph-2p | TBD | Ed25519ph | Ed25519ph |
| | | | [I-D.jose-fully-spec-algs] |
| | | | divided for two-party signing |
| | | | as defined here (NOTE: |
| | | | Ed25519ph not yet registered) |
+--------------+-------+-----------+-------------------------------+
| Ed448ph-2p | TBD | Ed448ph | Ed448ph |
| | | | [I-D.jose-fully-spec-algs] |
| | | | divided for two-party signing |
| | | | as defined here (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.
Lundberg & Jones Expires 4 September 2025 [Page 6]
Internet-Draft COSE Algs for Two-Party Signing March 2025
* 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.2 and Section 4.3).
* 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 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) |
+------------------+-------+---------------+-----------------------+
Table 3
Lundberg & Jones Expires 4 September 2025 [Page 7]
Internet-Draft COSE Algs for Two-Party Signing March 2025
3. 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 [FIPS-204] has the additional parameter _ctx_ and
ARKG-Derive-Private-Key [I-D.bradleylundberg-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 [I-D.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 4 September 2025 [Page 8]
Internet-Draft COSE Algs for Two-Party Signing March 2025
The following CDDL example represents a reference to a key derived by
ARKG-P256ADD-ECDH [I-D.bradleylundberg-ARKG] and restricted for use
with the ESP256 [I-D.jose-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 Algorithms Registrations
This section registers the following values in the IANA "COSE
Algorithms" registry [IANA.COSE]:
* Name: ESP256-2p
- Value: TBD (Requested Assignment -300)
- Description: ESP256 [I-D.jose-fully-spec-algs] divided for two-
party signing
- Capabilities: [kty]
- Change Controller: IETF
- Reference: Section 2.1 of this specification
- Recommended: Yes
* Name: ESP384-2p
Lundberg & Jones Expires 4 September 2025 [Page 9]
Internet-Draft COSE Algs for Two-Party Signing March 2025
- Value: TBD (Requested Assignment -301)
- Description: ESP384 [I-D.jose-fully-spec-algs] divided for two-
party signing
- Capabilities: [kty]
- Change Controller: IETF
- Reference: Section 2.1 of this specification
- Recommended: Yes
* Name: ESP512-2p
- Value: TBD (Requested Assignment -302)
- Description: ESP512 [I-D.jose-fully-spec-algs] divided for two-
party signing
- Capabilities: [kty]
- Change Controller: IETF
- Reference: Section 2.1 of this specification
- Recommended: Yes
* Name: Ed25519ph-2p
- Value: TBD (Requested Assignment -303)
- Description: Ed25519ph [I-D.jose-fully-spec-algs] divided for
two-party signing
- Capabilities: [kty]
- Change Controller: IETF
- Reference: Section 2.2 of this specification
- Recommended: Yes
* Name: Ed448ph-2p
- Value: TBD (Requested Assignment -304)
Lundberg & Jones Expires 4 September 2025 [Page 10]
Internet-Draft COSE Algs for Two-Party Signing March 2025
- Description: Ed448ph [I-D.jose-fully-spec-algs] divided for
two-party signing
- Capabilities: [kty]
- Change Controller: IETF
- Reference: Section 2.2 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: Section 2.3 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: Section 2.3 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
Lundberg & Jones Expires 4 September 2025 [Page 11]
Internet-Draft COSE Algs for Two-Party Signing March 2025
- Reference: Section 2.3 of this specification
- Recommended: Yes
4.2. 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]
- 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 /= -7 ; Value TBD
Lundberg & Jones Expires 4 September 2025 [Page 12]
Internet-Draft COSE Algs for Two-Party Signing March 2025
4.3. 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
[I-D.bradleylundberg-ARKG]
Lundberg, E. and J. Bradley, "The Asynchronous Remote Key
Generation (ARKG) algorithm", Work in Progress, Internet-
Draft, draft-bradleylundberg-cfrg-arkg-03, 27 November
2024, <https://datatracker.ietf.org/doc/html/draft-
bradleylundberg-cfrg-arkg-03>.
[I-D.COSE-ML-DSA]
Prorock, M., Steele, O., Misoczki, R., Osborne, M., and C.
Cloostermans, "ML-DSA for JOSE and COSE", Work in
Progress, Internet-Draft, draft-ietf-cose-dilithium-05, 18
December 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-cose-dilithium-05>.
[I-D.jose-fully-spec-algs]
Jones, M. B. and O. Steele, "Fully-Specified Algorithms
for JOSE and COSE", Work in Progress, Internet-Draft,
draft-ietf-jose-fully-specified-algorithms-07, 20 February
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
jose-fully-specified-algorithms-07>.
[IANA.COSE]
IANA, "CBOR Object Signing and Encryption (COSE)", n.d.,
<https://www.iana.org/assignments/cose/>.
Lundberg & Jones Expires 4 September 2025 [Page 13]
Internet-Draft COSE Algs for Two-Party Signing March 2025
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
May 2009, <https://www.secg.org/sec1-v2.pdf>.
5.2. Informative References
[FIPS-186-5]
National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", February 2023,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-5.pdf>.
[FIPS-204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.204.pdf>.
[I-D.COSE-Hash-Envelope]
Steele, O., Lasker, S., and H. Birkholz, "COSE Hash
Envelope", Work in Progress, Internet-Draft, draft-ietf-
cose-hash-envelope-02, 21 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
hash-envelope-02>.
Lundberg & Jones Expires 4 September 2025 [Page 14]
Internet-Draft COSE Algs for Two-Party Signing March 2025
[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,
<https://www.rfc-editor.org/rfc/rfc9380>.
Document History
-01
* Added IANA registration requests for algorithms defined.
* Updated references and other editorial tweaks.
-00
* Initial individual draft
Authors' Addresses
Emil Lundberg (editor)
Yubico
Gävlegatan 22
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 4 September 2025 [Page 15]