Skip to main content

PQ/T Hybrid Composite Signatures for JOSE and COSE
draft-prabel-jose-pq-composite-sigs-00

Document Type Active Internet-Draft (individual)
Authors Lucas Prabel , Sun Shuzhou
Last updated 2024-10-14
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-prabel-jose-pq-composite-sigs-00
JOSE                                                           L. Prabel
Internet-Draft                                                    S. Sun
Intended status: Standards Track                                  Huawei
Expires: 17 April 2025                                   14 October 2024

           PQ/T Hybrid Composite Signatures for JOSE and COSE
                 draft-prabel-jose-pq-composite-sigs-00

Abstract

   This document describes JSON Object Signing and Encryption (JOSE) and
   CBOR Object Signing and Encryption (COSE) serializations for PQ/T
   hybrid composite signatures.  The composite algorithms described
   combine ML-DSA as the post-quantum component and ECDSA as the
   traditional component.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://example.com/LATEST.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-prabel-jose-pq-
   composite-sigs/.

   Discussion of this document takes place on the Javascript Object
   Signing and Encryption Working Group mailing list
   (mailto:jose@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/jose/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/jose/.

   Source for this draft and an issue tracker can be found at
   https://github.com/USER/REPO.

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/.

Prabel & Sun              Expires 17 April 2025                 [Page 1]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   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 17 April 2025.

Copyright Notice

   Copyright (c) 2024 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
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Composite Keys and Signatures Structures  . . . . . . . . . .   5
     3.1.  Composite Key Structures  . . . . . . . . . . . . . . . .   5
     3.2.  Composite Signature Structures  . . . . . . . . . . . . .   5
     3.3.  Encoding Rules  . . . . . . . . . . . . . . . . . . . . .   6
   4.  Composite Signature Algorithms  . . . . . . . . . . . . . . .   7
     4.1.  JOSE algorithms . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  COSE algorithms . . . . . . . . . . . . . . . . . . . . .   8
   5.  Composite Signature Key Types . . . . . . . . . . . . . . . .   9
     5.1.  JOSE Key Type . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  COSE Key type . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Composite Signature Web Key and Key Type Parameters . . . . .  10
     6.1.  JSON Web Key Parameters . . . . . . . . . . . . . . . . .  10
     6.2.  COSE Key Type Parameters  . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  JOSE Algorithms . . . . . . . . . . . . . . . . . . . . .  12
       8.1.1.  MLDSA44-ES256 . . . . . . . . . . . . . . . . . . . .  12
       8.1.2.  MLDSA65-ES512 . . . . . . . . . . . . . . . . . . . .  12
       8.1.3.  MLDSA87-ES512 . . . . . . . . . . . . . . . . . . . .  13
     8.2.  JOSE Key Types  . . . . . . . . . . . . . . . . . . . . .  13
       8.2.1.  AKP-EC  . . . . . . . . . . . . . . . . . . . . . . .  13
     8.3.  JOSE Web Key Parameters . . . . . . . . . . . . . . . . .  13
       8.3.1.  Public Key  . . . . . . . . . . . . . . . . . . . . .  14

Prabel & Sun              Expires 17 April 2025                 [Page 2]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

       8.3.2.  Private Key . . . . . . . . . . . . . . . . . . . . .  14
       8.3.3.  Others  . . . . . . . . . . . . . . . . . . . . . . .  14
     8.4.  COSE Algorithms . . . . . . . . . . . . . . . . . . . . .  14
       8.4.1.  MLDSA44-ES256 . . . . . . . . . . . . . . . . . . . .  14
       8.4.2.  MLDSA65-ES512 . . . . . . . . . . . . . . . . . . . .  15
       8.4.3.  MLDSA87-ES512 . . . . . . . . . . . . . . . . . . . .  15
     8.5.  COSE Key Types  . . . . . . . . . . . . . . . . . . . . .  15
       8.5.1.  AKP-EC2 . . . . . . . . . . . . . . . . . . . . . . .  15
     8.6.  COSE Key Type Parameters  . . . . . . . . . . . . . . . .  16
       8.6.1.  Public Key  . . . . . . . . . . . . . . . . . . . . .  16
       8.6.2.  Private Key . . . . . . . . . . . . . . . . . . . . .  16
       8.6.3.  Others  . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   The impact of a potential Cryptographically Relevant Quantum Computer
   (CRQC) on algorithms whose security is based on mathematical problems
   such as integer factorisation or discrete logarithms over finite
   fields or elliptic curves raises the need for new algorithms that are
   perceived to be secure against CRQC as well as classical computers.
   Such algorithms are called post-quantum, while algorithms based on
   integer factorisation or discrete logarithms are called traditional.

   While switching from a traditional algorithm to a post-quantum one
   intends to strengthen the security against an adversary possessing a
   quantum computer, the lack of maturing time of post-quantum
   algorithms compared to traditional algorithms raises uncertainty
   about their security.

   Thus, the joint use of a traditional algorithm and a post-quantum
   algorithm in protocols represents a solution to this problem by
   providing security as long as at least one of the traditional or
   post-quantum components remains secure.

   This document describes JSON Object Signing and Encryption (JOSE) and
   CBOR Object Signing and Encryption (COSE) serializations for hybrid
   composite signatures.  The composite algorithms described combine ML-
   DSA as the post-quantum component and ECDSA as the traditional
   component.

Prabel & Sun              Expires 17 April 2025                 [Page 3]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

2.  Conventions and Definitions

   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 document follows the terminology for post-quantum hybrid schemes
   defined in [I-D.draft-ietf-pquip-pqt-hybrid-terminology-04].

   This section recalls some of this terminology, but also adds other
   definitions used throughout the whole document:

   "Asymmetric Traditional Cryptographic Algorithm": An asymmetric
   cryptographic algorithm based on integer factorisation, finite field
   discrete logarithms, elliptic curve discrete logarithms, or related
   mathematical problems.  A related mathematical problem is one that
   can be solved by solving the integer factorisation, finite field
   discrete logarithm or elliptic curve discrete logarithm problem.
   Where there is little risk of confusion asymmetric traditional
   cryptographic algorithms can also be referred to as traditional
   algorithms for brevity.

   "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that
   is intended to be secure against attacks using quantum computers as
   well as classical computers.  As with all cryptography, it always
   remains the case that attacks, either quantum or classical, may be
   found against post-quantum algorithms.  Therefore it should not be
   assumed that just because an algorithm is designed to provide post-
   quantum security it will not be compromised.

   "Component Algorithm": Each cryptographic algorithm that forms part
   of a cryptographic scheme.

   "Post-Quantum Traditional (PQ/T) Hybrid Scheme": A multi-algorithm
   scheme where at least one component algorithm is a post-quantum
   algorithm and at least one is a traditional algorithm.

   "PQ/T Hybrid Digital Signature": A multi-algorithm digital signature
   scheme made up of two or more component digital signature algorithms
   where at least one is a post-quantum algorithm and at least one is a
   traditional algorithm.

   "Composite Algorithm": An algorithm which is a sequence of two
   component algorithms, as defined in
   [I-D.draft-ietf-lamps-pq-composite-sigs-02].

Prabel & Sun              Expires 17 April 2025                 [Page 4]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

3.  Composite Keys and Signatures Structures

   The structures of the composite keys and composite signatures follow
   the approach of [I-D.draft-ietf-lamps-pq-composite-sigs-02].  This
   design was chosen so that composite keys and signatures can be used
   as a drop-in replacement in JOSE / COSE object formats.  This section
   gives some details about their construction.

3.1.  Composite Key Structures

   Composite public and private keys are generated by calling the key
   generation functions of the two component algorithms and
   concatenating the keys in an order given by the registered composite
   algorithm.

   Composite Public Key <- Public Key of the 1st Algorithm || Public Key
   of the 2nd Algorithm

   and

   Composite Private Key <- Private Key of the 1st Algorithm || Private
   Key of the 2nd Algorithm

   For the composite algorithms described in this document (ML-DSA with
   ECDSA), the Key Generation process is as follows:

   (pk_1, sk_1) <- MLDSA.KeyGen()
   (pk_2 = (x,y), sk_2 = d) <- ECDSA.KeyGen()

   Composite Public Key <- pk_1 || pk_2 = pk_1 || x || y
   Composite Private Key <- sk_1 || sk_2 = sk_1 || d

   Point compression for ECDSA is not performed for the "AKP-EC" JSON
   Web Key Type but can be performed for the "AKP-EC2" COSE Key Type.
   Both key types are defined in Section 5.

   In this document, as it is specified in [FIPS.204], the ML-DSA
   private key is stored as a 32-byte seed, which is sufficient to
   generate the full expanded private key.

3.2.  Composite Signature Structures

   Composite signatures are generated by:

   *  pre-hashing the message to be signed;

   *  concatenating it with a domain separator;

Prabel & Sun              Expires 17 April 2025                 [Page 5]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   *  encoding the resulting message;

   *  calling the two signature component algorithms on this new
      message;

   *  concatenating the two output signatures.

   For the composite algorithms described in this document (ML-DSA with
   ECDSA), the signature process of a message M is as follows:

   M' <- Domain || HASH(M)
   M' <- Encode(M')

   sig_1 <- MLDSA.Sign(sk_1, M')
   sig_2 <- ECDSA.Sign(sk_2, M')

   Composite Signature <- (sig_1, sig_2)

   The domain separator is defined as the octets of the ASCII
   representation of the Composite Signature "alg" (algorithm) Header
   Parameter value.

   For JOSE (resp.  COSE), M' is base64url-encoded (resp. binary
   encoded) before signature computations.

3.3.  Encoding Rules

   In each combination, the byte streams of the keys or signatures are
   directly concatenated.

   Signature of the 1st Algorithm || Signature of the 2nd Algorithm

   Since all combinations presented in this document start with the ML-
   DSA algorithm and the key or signature sizes are fixed as defined in
   [FIPS.204], it is unambiguous to encode or decode a composite key or
   signature.

   Table 1 lists sizes of the three parameter sets of the ML-DSA
   algorithm.

Prabel & Sun              Expires 17 April 2025                 [Page 6]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

         +===========+=============+============+================+
         |           | Private Key | Public Key | Signature Size |
         +===========+=============+============+================+
         | ML-DSA-44 | 2560        | 1312       | 2420           |
         +-----------+-------------+------------+----------------+
         | ML-DSA-65 | 4032        | 1952       | 3309           |
         +-----------+-------------+------------+----------------+
         | ML-DSA-87 | 4896        | 2592       | 4627           |
         +-----------+-------------+------------+----------------+

            Table 1: Sizes (in bytes) of keys and signatures of
                                   ML-DSA

4.  Composite Signature Algorithms

   The ML-DSA signature scheme supports three possible parameter sets,
   each of which corresponding to a specific security strength.  See
   [FIPS.204] for more considerations on that matter.

   The hybrid composite schemes are described in more detail in
   [I-D.draft-ietf-lamps-pq-composite-sigs-02].

   The traditional signature algorithm for each combination in Table 2
   and Table 3 was chosen to match the security level of the ML-DSA
   post-quantum component.  More precisely, NIST security levels 1-3 are
   matched with 256-bit curves and NIST security levels 4-5 are matched
   with 384-bit elliptic curves.

4.1.  JOSE algorithms

   The following table defines a list of algorithms associated with
   specific PQ/T combinations to be registered in [IANA.JOSE].

Prabel & Sun              Expires 17 April 2025                 [Page 7]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

    +=============+=========+===================+=========+===========+
    |Name         |First    | Second Algorithm  |Pre-Hash |Description|
    |             |Algorithm|                   |         |           |
    +=============+=========+===================+=========+===========+
    |MLDSA44-ES256|ML-DSA-44| ecdsa-with-SHA256 |id-sha256|Composite  |
    |             |         | with secp256r1    |         |Signature  |
    |             |         |                   |         |with ML-   |
    |             |         |                   |         |DSA-44 and |
    |             |         |                   |         |ECDSA using|
    |             |         |                   |         |P-256 curve|
    |             |         |                   |         |and SHA-256|
    +-------------+---------+-------------------+---------+-----------+
    |MLDSA65-ES512|ML-DSA-65| ecdsa-with-SHA512 |id-sha512|Composite  |
    |             |         | with secp256r1    |         |Signature  |
    |             |         |                   |         |with ML-   |
    |             |         |                   |         |DSA-65 and |
    |             |         |                   |         |ECDSA using|
    |             |         |                   |         |P-256 curve|
    |             |         |                   |         |and SHA-512|
    +-------------+---------+-------------------+---------+-----------+
    |MLDSA87-ES512|ML-DSA-87| ecdsa-with-SHA512 |id-sha512|Composite  |
    |             |         | with secp384r1    |         |Signature  |
    |             |         |                   |         |with ML-   |
    |             |         |                   |         |DSA-87 and |
    |             |         |                   |         |ECDSA using|
    |             |         |                   |         |P-384 curve|
    |             |         |                   |         |and SHA-512|
    +-------------+---------+-------------------+---------+-----------+

          Table 2: JOSE Composite Signature Algorithms for ML-DSA

   Examples can be found in Appendix A.

4.2.  COSE algorithms

   The following table defines a list of algorithms associated with
   specific PQ/T combinations to be registered in [IANA.COSE].

Prabel & Sun              Expires 17 April 2025                 [Page 8]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   +=============+==========+=========+=========+===========+=========+
   |Name         |COSE Value|First    |Second   |Description|         |
   |             |          |Algorithm|Algorithm|           |         |
   +=============+==========+=========+=========+===========+=========+
   |MLDSA44-ES256|TBD       |ML-DSA-44|ecdsa-   |id-sha256  |Composite|
   |             |(request  |         |with-    |           |Signature|
   |             |assignment|         |SHA256   |           |with ML- |
   |             |-51)      |         |with     |           |DSA-44   |
   |             |          |         |secp256r1|           |and ECDSA|
   |             |          |         |         |           |using    |
   |             |          |         |         |           |P-256    |
   |             |          |         |         |           |curve and|
   |             |          |         |         |           |SHA-256  |
   +-------------+----------+---------+---------+-----------+---------+
   |MLDSA65-ES512|TBD       |ML-DSA-65|ecdsa-   |id-sha512  |Composite|
   |             |(request  |         |with-    |           |Signature|
   |             |assignment|         |SHA512   |           |with ML- |
   |             |-52)      |         |with     |           |DSA-65   |
   |             |          |         |secp256r1|           |and ECDSA|
   |             |          |         |         |           |using    |
   |             |          |         |         |           |P-256    |
   |             |          |         |         |           |curve and|
   |             |          |         |         |           |SHA-512  |
   +-------------+----------+---------+---------+-----------+---------+
   |MLDSA87-ES512|TBD       |ML-DSA-87|ecdsa-   |id-sha512  |Composite|
   |             |(request  |         |with-    |           |Signature|
   |             |assignment|         |SHA512   |           |with ML- |
   |             |-53)      |         |with     |           |DSA-87   |
   |             |          |         |secp384r1|           |and ECDSA|
   |             |          |         |         |           |using    |
   |             |          |         |         |           |P-384    |
   |             |          |         |         |           |curve and|
   |             |          |         |         |           |SHA-512  |
   +-------------+----------+---------+---------+-----------+---------+

         Table 3: COSE Composite Signature Algorithms for ML-DSA

   Examples can be found in Appendix A.

5.  Composite Signature Key Types

5.1.  JOSE Key Type

   This document requests the registration of the following key type in
   [IANA.JOSE], for use in the optional JWS Header parameter "jwk".

Prabel & Sun              Expires 17 April 2025                 [Page 9]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   "AKP" stands for "Algorithm Key Pair" and is used in this document,
   as in [I-D.draft-ietf-cose-dilithium-03], to express the ML-DSA
   public and private keys.  When this key type is used, the JSON Web
   Key Parameter "alg" is REQUIRED.

           +========+==========================================+
           | kty    | Description                              |
           +========+==========================================+
           | AKP-EC | JWK key type for composite signature     |
           |        | with ECDSA as the traditional component. |
           +--------+------------------------------------------+

               Table 4: JWK key type for composite algorithm

   Examples can be found in Appendix A.

5.2.  COSE Key type

   This document requests the registration of the following key type in
   [IANA.COSE].

   "AKP" stands for "Algorithm Key Pair" and is used in this document,
   as in [I-D.draft-ietf-cose-dilithium-03], to express the ML-DSA
   public and private keys.  When this key type is used, the COSE Key
   Common Parameter "alg" is REQUIRED.

       +=========+=====+==========================================+
       | Name    | kty | Description                              |
       +=========+=====+==========================================+
       | AKP-EC2 | TBD | COSE key type for composite algorithm    |
       |         |     | with ECDSA as the traditional component. |
       +---------+-----+------------------------------------------+

              Table 5: COSE key type for composite algorithm

   Examples can be found in Appendix A.

6.  Composite Signature Web Key and Key Type Parameters

6.1.  JSON Web Key Parameters

   This document requests IANA to register the entries described in this
   section and summarised in the following Table 7 to the JSON Web Key
   Parameters Registry.

   It also requests to add "AKP-EC" as a usable "kty" value for the
   parameters "crv", "x", "y" and "d".

Prabel & Sun              Expires 17 April 2025                [Page 10]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   +=========+===========+========+===========+==========+=============+
   |Parameter|Parameter  |Used    |Parameter  |Change    |Specification|
   |Name     |Description|with    |Information|Controller|Document(s)  |
   |         |           |"kty"   |Class      |          |             |
   |         |           |Value(s)|           |          |             |
   +=========+===========+========+===========+==========+=============+
   |pub      |Public Key |AKP-EC  |Public     |IETF      |n\a          |
   +---------+-----------+--------+-----------+----------+-------------+
   |priv     |Private Key|AKP-EC  |Private    |IETF      |n\a          |
   +---------+-----------+--------+-----------+----------+-------------+

                  Table 6: JSON AKP-EC Web Key Parameters

6.2.  COSE Key Type Parameters

   This document requests IANA to register the entries described in this
   section and summarised in the following Table 7 to the COSE Key Type
   Parameters Registry.

        +===============+======+=======+===========+==============+
        | Key Type      | Name | Label | CBOR Type | Description  |
        +===============+======+=======+===========+==============+
        | TBD (request  | crv  | -1    | int /     | EC           |
        | assignment 8) |      |       | tstr      | identifier   |
        +---------------+------+-------+-----------+--------------+
        | TBD (request  | x    | -2    | bstr      | x-coordinate |
        | assignment 8) |      |       |           |              |
        +---------------+------+-------+-----------+--------------+
        | TBD (request  | y    | -3    | bstr /    | y-coordinate |
        | assignment 8) |      |       | bool      |              |
        +---------------+------+-------+-----------+--------------+
        | TBD (request  | d    | -4    | bstr      | EC Private   |
        | assignment 8) |      |       |           | key          |
        +---------------+------+-------+-----------+--------------+
        | TBD (request  | pub  | -5    | bstr      | Public Key   |
        | assignment 8) |      |       |           |              |
        +---------------+------+-------+-----------+--------------+
        | TBD (request  | priv | -6    | bstr      | Private Key  |
        | assignment 8) |      |       |           |              |
        +---------------+------+-------+-----------+--------------+

                    Table 7: COSE AKP-EC2 Key Parameters

7.  Security Considerations

   The security considerations of [RFC7515], [RFC7517], [RFC9053] and
   [FIPS.204] also apply to this document.

Prabel & Sun              Expires 17 April 2025                [Page 11]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   All security issues that are pertinent to any cryptographic
   application must be addressed by JWS/JWK agents.  Protecting the
   user's private key and employing countermeasures to various attacks
   constitute a priority.

   For security properties and security issues related to the use of a
   hybrid signature scheme, the user can refer to
   [I-D.draft-ietf-pquip-hybrid-signature-spectrums-00].  For more
   information about hybrid composite signature schemes and the
   different hybrid combinations that appear in this document, the user
   can read [I-D.draft-ietf-lamps-pq-composite-sigs-02].

8.  IANA Considerations

8.1.  JOSE Algorithms

   The following values of the JWS "alg" (algorithm) are requested to be
   added to the "JSON Web Signature and Encryption Algorithms" registry.
   They are represented following the registration template provided in
   [RFC7518].

8.1.1.  MLDSA44-ES256

   *  Algorithm Name: MLDSA44-ES256

   *  Algorithm Description: Composite Signature with ML-DSA-44 and
      ECDSA using P-256 curve and SHA-256

   *  Algorithm Usage Location(s): alg

   *  JOSE Implementation Requirements: Optional

   *  Change Controller: IETF

   *  Specification Document(s): n/a

   *  Algorithm Analysis Documents(s): TBD

8.1.2.  MLDSA65-ES512

   *  Algorithm Name: MLDSA65-ES512

   *  Algorithm Description: Composite Signature with ML-DSA-65 and
      ECDSA using P-256 curve and SHA-512

   *  Algorithm Usage Location(s): alg

   *  JOSE Implementation Requirements: Optional

Prabel & Sun              Expires 17 April 2025                [Page 12]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   *  Change Controller: IETF

   *  Specification Document(s): n/a

   *  Algorithm Analysis Documents(s): TBD

8.1.3.  MLDSA87-ES512

   *  Algorithm Name: MLDSA87-ES512

   *  Algorithm Description: Composite Signature with ML-DSA-87 and
      ECDSA using P-384 curve and SHA-512

   *  Algorithm Usage Location(s): alg

   *  JOSE Implementation Requirements: Optional

   *  Change Controller: IETF

   *  Specification Document(s): n/a

   *  Algorithm Analysis Documents(s): TBD

8.2.  JOSE Key Types

   IANA is requested to add the following entries to the JSON Web Key
   Types Registry.

8.2.1.  AKP-EC

   *  "kty" Parameter Value: AKP-EC

   *  Key Type Description: Composite signature algorithm with ECDSA as
      the traditional component

   *  JOSE Implementation Requirements: Optional

   *  Change Controller: IETF

   *  Specification Document(s): n/a

8.3.  JOSE Web Key Parameters

   IANA is requested to add the following entries to the JSON Web Key
   Parameters Registry.

Prabel & Sun              Expires 17 April 2025                [Page 13]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

8.3.1.  Public Key

   *  Parameter Name: pub

   *  Parameter Description: Public or verification key

   *  Used with "kty" Value(s): AKP-EC

   *  Parameter Information Class: Public

   *  Change Controller: IETF

   *  Specification Document(s): n/a

8.3.2.  Private Key

   *  Parameter Name: priv

   *  Parameter Description: Secret, private or signing key

   *  Used with "kty" Value(s): AKP-EC

   *  Parameter Information Class: Private

   *  Change Controller: IETF

   *  Specification Document(s): n/a

8.3.3.  Others

   The key parameters registered in [IANA.JOSE] for use with the kty
   values "EC" should also be usable with the kty value "AKP-EC" defined
   in this document.

8.4.  COSE Algorithms

   The following values are requested to be added to the "COSE
   Algorithms" registry.  They are represented following the
   registration template provided in [RFC9053], [RFC9054].

8.4.1.  MLDSA44-ES256

   *  Name: MLDSA44-ES256

   *  Value: TBD (request assignment -51)

   *  Description: Composite Signature with ML-DSA-44 and ECDSA using
      P-256 curve and SHA-256

Prabel & Sun              Expires 17 April 2025                [Page 14]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   *  Capabilities: [kty]

   *  Change Controller: IETF

   *  Reference: n/a

   *  Recommended: Yes

8.4.2.  MLDSA65-ES512

   *  Name: MLDSA65-ES512

   *  Value: TBD (request assignment -52)

   *  Description: Composite Signature with ML-DSA-65 and ECDSA using
      P-256 curve and SHA-512

   *  Capabilities: [kty]

   *  Change Controller: IETF

   *  Reference: n/a

   *  Recommended: Yes

8.4.3.  MLDSA87-ES512

   *  Name: MLDSA87-ES512

   *  Value: TBD (request assignment -53)

   *  Description: Composite Signature with ML-DSA-87 and ECDSA using
      P-384 curve and SHA-512

   *  Capabilities: [kty]

   *  Change Controller: IETF

   *  Reference: n/a

   *  Recommended: Yes

8.5.  COSE Key Types

8.5.1.  AKP-EC2

   *  Name: AKP-EC2

Prabel & Sun              Expires 17 April 2025                [Page 15]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   *  Value: TBD (request assignment 8)

   *  Description: COSE Key Type for Composite Signature Algorithm with
      ECDSA as the traditional component

   *  Capabilities: [kty(8)]

   *  Reference: n/a

8.6.  COSE Key Type Parameters

8.6.1.  Public Key

   *  Key Type: TBD

   *  Name: public_key

   *  Label: -1

   *  CBOR Type: bstr

   *  Description: Public key

   *  Reference: n/a

8.6.2.  Private Key

   *  Key Type: TBD

   *  Name: private_key

   *  Label: -2

   *  CBOR Type: bstr

   *  Description: Private key

   *  Reference: n/a

8.6.3.  Others

   The key parameters registered in [IANA.COSE] for use with the kty
   value "EC2" should also be usable with the kty value "AKP-EC2"
   defined in this document.

9.  References

9.1.  Normative References

Prabel & Sun              Expires 17 April 2025                [Page 16]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   [IANA.COSE]
              IANA, "CBOR Object Signing and Encryption (COSE)", n.d.,
              <https://www.iana.org/assignments/cose/cose.xhtml>.

   [IANA.JOSE]
              IANA, "JSON Object Signing and Encryption (JOSE)", n.d.,
              <https://www.iana.org/assignments/jose/jose.xhtml>.

   [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>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7518>.

   [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>.

9.2.  Informative References

   [FIPS.204] National Institute of Standards and Technology (NIST),
              "Module-Lattice-Based Digital Signature Standard", August
              2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.204.pdf>.

   [I-D.draft-ietf-cose-dilithium-03]
              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-03, 2
              June 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-cose-dilithium-03>.

Prabel & Sun              Expires 17 April 2025                [Page 17]
Internet-Draft       JOSE/COSE Composite Signatures         October 2024

   [I-D.draft-ietf-lamps-pq-composite-sigs-02]
              Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
              Fluhrer, "Composite ML-DSA for use in Internet PKI", Work
              in Progress, Internet-Draft, draft-ietf-lamps-pq-
              composite-sigs-02, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              pq-composite-sigs-02>.

   [I-D.draft-ietf-pquip-hybrid-signature-spectrums-00]
              Bindel, N., Hale, B., Connolly, D., and F. D, "Hybrid
              signature spectrums", Work in Progress, Internet-Draft,
              draft-ietf-pquip-hybrid-signature-spectrums-00, 24 May
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              pquip-hybrid-signature-spectrums-00>.

   [I-D.draft-ietf-pquip-pqt-hybrid-terminology-04]
              D, F., P, M., and B. Hale, "Terminology for Post-Quantum
              Traditional Hybrid Schemes", Work in Progress, Internet-
              Draft, draft-ietf-pquip-pqt-hybrid-terminology-04, 10
              September 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-pquip-pqt-hybrid-terminology-04>.

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
              August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

   [RFC9054]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, August
              2022, <https://www.rfc-editor.org/rfc/rfc9054>.

Appendix A.  Examples

   Will be added in later versions.

Authors' Addresses

   Lucas Prabel
   Huawei
   Email: lucas.prabel@huawei.com

   Sun Shuzhou
   Huawei
   Email: sunshuzhou@huawei.com

Prabel & Sun              Expires 17 April 2025                [Page 18]