Internet-Draft JOSE/COSE Composite Signatures October 2024
Prabel & Sun Expires 17 April 2025 [Page]
Workgroup:
JOSE
Internet-Draft:
draft-prabel-jose-pq-composite-sigs-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
L. Prabel
Huawei
S. Sun
Huawei

PQ/T Hybrid Composite Signatures for JOSE and COSE

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

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.

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.

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

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;

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

Table 1: Sizes (in bytes) of keys and signatures of ML-DSA
  Private Key Public Key Signature Size
ML-DSA-44 2560 1312 2420
ML-DSA-65 4032 1952 3309
ML-DSA-87 4896 2592 4627

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

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

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

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

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

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

Table 4: JWK key type for composite algorithm
kty Description
AKP-EC JWK key type for composite signature with ECDSA as the traditional component.

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.

Table 5: COSE key type for composite algorithm
Name kty Description
AKP-EC2 TBD COSE key type for composite algorithm with ECDSA as the traditional component.

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

Table 6: JSON AKP-EC Web Key Parameters
Parameter Name Parameter Description Used with "kty" Value(s) Parameter Information Class Change Controller Specification Document(s)
pub Public Key AKP-EC Public IETF n\a
priv Private Key AKP-EC Private IETF n\a

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.

Table 7: COSE AKP-EC2 Key Parameters
Key Type Name Label CBOR Type Description
TBD (request assignment 8) crv -1 int / tstr EC identifier
TBD (request assignment 8) x -2 bstr x-coordinate
TBD (request assignment 8) y -3 bstr / bool y-coordinate
TBD (request assignment 8) d -4 bstr EC Private key
TBD (request assignment 8) pub -5 bstr Public Key
TBD (request assignment 8) priv -6 bstr Private Key

7. Security Considerations

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

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

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

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

  • 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

  • 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

[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, , <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, , <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517]
Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7518]
Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, , <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, , <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", , <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, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-03>.
[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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9054]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, , <https://www.rfc-editor.org/rfc/rfc9054>.

Appendix A. Examples

Will be added in later versions.

Authors' Addresses

Lucas Prabel
Huawei
Sun Shuzhou
Huawei