CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for SQIsign
draft-mott-cose-sqisign-00
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) | |
|---|---|---|---|
| Author | Antony R. Mott | ||
| Last updated | 2026-04-23 | ||
| 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-mott-cose-sqisign-00
COSE A. R. Mott
Internet-Draft RustyKey
Intended status: Standards Track 23 April 2026
Expires: 25 October 2026
CBOR Object Signing and Encryption (COSE) and JSON Object Signing and
Encryption (JOSE) Registrations for SQIsign
draft-mott-cose-sqisign-00
Abstract
*NOTE: This document describes a signature scheme based on an
algorithm currently under evaluation in the NIST Post-Quantum
Cryptography standardization process. Be aware that the underlying
primitive may change as a result of that process.*
This document specifies the algorithm encodings and representations
for the SQIsign digital signature scheme within the CBOR Object
Signing and Encryption (COSE) and JSON Object Signing and Encryption
(JOSE) frameworks.
SQIsign is an isogeny-based post-quantum signature scheme that
provides the most compact signature and public key sizes of any
candidate in the NIST Post-Quantum Cryptography (PQC) standardization
and on-ramp-to-standardization processes.
The standardization of SQIsign is critical to addressing immediate
infrastructure bottlenecks, specifically the FIDO2 CTAP2
specification used by an estimated 6.25 billion in-service devices
and browser installations. CTAP2 enforces a 1024-byte default limit
for external key communication. Most standardized post-quantum
signatures exceed this limit, so cannot easily be deployed in these
ecosystems without prohibitive protocol renegotiation, complex
message fragmentation or hardware replacement. SQIsign-L1 signatures
are small enough to enable delivery over highly constrained networks
like 802.15.4 with minimal fragmentation.
This document clarifies that SQIsign's security relies on the general
supersingular isogeny problem and is fundamentally unaffected by the
torsion-point attacks that deprecated the SIDH/SIKE key exchange. By
establishing stable COSE and JOSE identifiers, this document ensures
the interoperability required for the seamless integration of post-
quantum security into high-density, bandwidth-constrained, and
legacy-compatible hardware environments.
About This Document
Mott Expires 25 October 2026 [Page 1]
Internet-Draft cose-sqisign April 2026
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-mott-cose-sqisign/.
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/https://github.com/antonymott/quantum-resistant-
rustykey.
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 25 October 2026.
Copyright Notice
Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
Mott Expires 25 October 2026 [Page 2]
Internet-Draft cose-sqisign April 2026
1.1. Background and Motivation . . . . . . . . . . . . . . . . 5
1.1.1. Urgent Need for Smaller PQC Signatures . . . . . . . 5
1.1.2. Estimated Constrained Device Footprint . . . . . . . 6
1.1.3. Urgency: Limit or Stop 'Harvest now; decrypt later'
Attacks . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Scope and Status . . . . . . . . . . . . . . . . . . . . 8
1.3. Relationship to Other Work . . . . . . . . . . . . . . . 8
1.4. Constrained Device Applicability . . . . . . . . . . . . 8
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 9
3. SQIsign Algorithm Overview . . . . . . . . . . . . . . . . . 9
3.1. Cryptographic Foundation . . . . . . . . . . . . . . . . 9
3.2. Security Levels . . . . . . . . . . . . . . . . . . . . . 10
3.3. Performance Characteristics . . . . . . . . . . . . . . . 10
4. COSE Integration . . . . . . . . . . . . . . . . . . . . . . 10
4.1. SQIsign Algorithms . . . . . . . . . . . . . . . . . . . 10
4.2. SQIsign Key Types . . . . . . . . . . . . . . . . . . . . 11
4.3. SQIsign Key Parameters . . . . . . . . . . . . . . . . . 11
4.4. SQIsign-Specific Key Parameters . . . . . . . . . . . . . 11
4.5. COSE Key Format Examples . . . . . . . . . . . . . . . . 11
4.5.1. Public Key (COSE_Key) . . . . . . . . . . . . . . . . 11
4.5.2. Private Key (COSE_Key) . . . . . . . . . . . . . . . 12
4.6. COSE Signature Format . . . . . . . . . . . . . . . . . . 12
4.6.1. Protected Headers . . . . . . . . . . . . . . . . . . 12
4.6.2. Example COSE_Sign1 Structure . . . . . . . . . . . . 12
5. JOSE Integration . . . . . . . . . . . . . . . . . . . . . . 12
5.1. JSON Web Signature (JWS) Algorithm Registration . . . . . 12
5.2. JSON Web Key (JWK) Representation . . . . . . . . . . . . 13
5.2.1. Public Key Parameters . . . . . . . . . . . . . . . . 13
5.2.2. Private Key Parameters . . . . . . . . . . . . . . . 13
5.3. JWK Examples . . . . . . . . . . . . . . . . . . . . . . 14
5.3.1. Public Key (JWK) Example . . . . . . . . . . . . . . 14
5.3.2. Private Key (JWK) Example . . . . . . . . . . . . . . 14
5.4. JWS Compact Serialization . . . . . . . . . . . . . . . . 14
5.4.1. Example JWS Protected Header . . . . . . . . . . . . 14
5.4.2. Complete JWS Example . . . . . . . . . . . . . . . . 15
6. Implementation Considerations . . . . . . . . . . . . . . . . 15
6.1. Signature and Key Generation . . . . . . . . . . . . . . 15
6.2. Randomness Requirements . . . . . . . . . . . . . . . . . 15
6.3. Side-Channel Protections . . . . . . . . . . . . . . . . 15
6.4. Performance Trade-offs . . . . . . . . . . . . . . . . . 15
6.5. Interoperability Testing . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Algorithm Security . . . . . . . . . . . . . . . . . . . 16
7.2. Quantum Security . . . . . . . . . . . . . . . . . . . . 16
7.3. Current Cryptanalysis Status . . . . . . . . . . . . . . 16
7.4. Implementation Security . . . . . . . . . . . . . . . . . 17
7.4.1. Random Number Generation . . . . . . . . . . . . . . 17
7.4.2. Side-Channel Resistance . . . . . . . . . . . . . . . 17
Mott Expires 25 October 2026 [Page 3]
Internet-Draft cose-sqisign April 2026
7.4.3. Key Management . . . . . . . . . . . . . . . . . . . 17
7.5. Cryptographic Agility . . . . . . . . . . . . . . . . . . 17
7.6. Constrained Device Specific Risks . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. Additions to Existing Registries . . . . . . . . . . . . 18
8.1.1. New COSE Algorithms . . . . . . . . . . . . . . . . . 18
8.1.2. New COSE Key Types . . . . . . . . . . . . . . . . . 18
8.1.3. New COSE Key Type Parameters . . . . . . . . . . . . 19
8.1.4. New JWS Algorithms . . . . . . . . . . . . . . . . . 19
8.1.5. New JSON Web Key Types . . . . . . . . . . . . . . . 20
8.1.6. New JSON Web Key Parameters . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 23
A.1. SQIsign-L1 Test Vectors . . . . . . . . . . . . . . . . . 23
A.1.1. Example 1: Simple Message Signing . . . . . . . . . . 23
A.1.2. COSE_Sign1 Complete Example . . . . . . . . . . . . . 24
A.1.3. JWS Complete Example . . . . . . . . . . . . . . . . 24
A.2. SQIsign-L3 Test Vectors . . . . . . . . . . . . . . . . . 24
A.3. SQIsign-L5 Test Vectors . . . . . . . . . . . . . . . . . 24
Appendix B. Implementation Status . . . . . . . . . . . . . . . 24
B.1. Open Source Implementations . . . . . . . . . . . . . . . 24
B.1.1. Reference Implementation . . . . . . . . . . . . . . 24
B.1.2. Rust Implementation . . . . . . . . . . . . . . . . . 25
B.2. Commercial Implementations . . . . . . . . . . . . . . . 25
B.3. Interoperability Testing . . . . . . . . . . . . . . . . 25
Appendix C. Design Rationale . . . . . . . . . . . . . . . . . . 25
C.1. Algorithm Identifier Selection . . . . . . . . . . . . . 25
C.2. Key Type Design . . . . . . . . . . . . . . . . . . . . . 26
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 26
D.1. draft-mott-cose-sqisign-00 . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
This document registers algorithm identifiers and key type parameters
for SQIsign in COSE and JOSE.
Mott Expires 25 October 2026 [Page 4]
Internet-Draft cose-sqisign April 2026
1.1. Background and Motivation
Post-quantum cryptography readiness is critical for constrained
devices. As of 2026, while FIDO2/WebAuthn supports various COSE
algorithms, hardware authenticators (like YubiKeys) and platform
authenticators (like TPMs) have strict memory/storage constraints,
effectively limiting public keys to 1024 bytes or less, hindering the
adoption of large-key post-quantum algorithms.
1.1.1. Urgent Need for Smaller PQC Signatures
FN-DSA (Falcon) and ML-DSA (Dilithium) have larger signatures that
may not fit in constrained environments.
The fundamental differences between ML-DSA, FN-DSA, and SQIsign lie
in their underlying hard mathematical problems, implementation
complexity, and performance trade-offs.
Falcon (NIST secondary) uses NTRU lattices to achieve very small
signatures and fast verification, but requires complex floating-point
math. Dilithium (NIST primary) is a balanced, high-efficiency
lattice scheme using Module-LWE/SIS, easy to implement.
SQIsign [SQIsign-Spec] [SQIsign-Analysis] is a non-lattice, isogeny-
based scheme (Short Quaternion and Isogeny Signature) that offers the
smallest signature sizes but suffers from significantly slower
signature generation where even vI may take seconds to minutes, or
longer with WASM implementations for browsers of particular relevance
to signatures required for WebAuthn PassKeys
[WebAuthn-PQC-Signature-size-constraints]. SQIsign is an isogeny-
based digital signature scheme participating in NIST's Round 2
Additional Digital Signature Schemes, not yet a NIST standard
[NIST-Finalized-Standards].
Speed: SQIsign is significantly slower at signing (roughly 100x to
1000x) compared to ML-DSA, though the math is changing fast and
variants improve this.
Mott Expires 25 October 2026 [Page 5]
Internet-Draft cose-sqisign April 2026
+=============+=================+================+==============+
| Algorithm | Public Key Size | Signature Size | PK + Sig |
| | | | Fits < 1024? |
+=============+=================+================+==============+
| ML-DSA-44 | 1,312 bytes | 2,420 bytes | ❌ |
+-------------+-----------------+----------------+--------------+
| ML-DSA-65 | 1,952 bytes | 3,293 bytes | ❌ |
+-------------+-----------------+----------------+--------------+
| ML-DSA-87 | 2,592 bytes | 4,595 bytes | ❌ |
+-------------+-----------------+----------------+--------------+
| FN-DSA-512 | 897 bytes | 666 bytes | ❌ (1,563 |
| | | | total) |
+-------------+-----------------+----------------+--------------+
| FN-DSA-1024 | 1,793 bytes | 1,280 bytes | ❌ |
+-------------+-----------------+----------------+--------------+
| SQIsign-L1 | 65 bytes | 148 bytes | ✅ (213 |
| | | | total) |
+-------------+-----------------+----------------+--------------+
| SQIsign-L3 | 97 bytes | 224 bytes | ✅ (321 |
| | | | total) |
+-------------+-----------------+----------------+--------------+
| SQIsign-L5 | 129 bytes | 292 bytes | ✅ (421 |
| | | | total) |
+-------------+-----------------+----------------+--------------+
Table 1
1.1.2. Estimated Constrained Device Footprint
The total addressable market for SQIsign in constrained devices is
estimated at ~6.25 billion units.
1.1.2.1. Device Category Breakdown
1.1.2.1.1. Legacy Hardware Security Keys: ~120 - 150 million
* YubiKeys in Service: Based on Yubico’s historical growth and
preliminary 2026 financial estimates, there are approximately 80
million legacy YubiKeys in active circulation (Series 5 and
older). While firmware 5.7+ introduced some PQC readiness, older
keys cannot be updated to increase buffer sizes - Other Vendors:
Competitors (Google Titan, Feitian, Thales) contribute another
40–50 million active legacy keys
Mott Expires 25 October 2026 [Page 6]
Internet-Draft cose-sqisign April 2026
1.1.2.1.2. Constrained TPMs and Platform Modules: ~1.1 billion
Trusted Platform Modules (TPMs) are integrated into PCs and servers,
but their WebAuthn implementation often inherits protocol-level
constraints. Estimated ~2.5 billion active chips worldwide.
Constrained Subset: We estimate ~1.1 billion of these are in older
Windows 10/11 or Linux machines where the OS "virtual authenticator"
or TPM driver still enforces the 1024-byte message default to
maintain backward compatibility with external CTAP1/2 tools.
1.1.2.1.3. Browser and Software Implementations: ~5 billion
This category refers to the "User-Agent" layer that mediates between
the web and the hardware. Global Browser Agents: There are over 5
billion active browser instances across mobile and desktop (Chrome,
Safari, Edge, Firefox). Legacy Protocols: Even on modern hardware,
browsers often use the FIDO2 CTAP2 specification which, unless
explicitly negotiated for larger messages, maintains a 1024-byte
default for external key communication.
1.1.2.1.4. Critical Infrastructure: ~300 Million includes Energy
(electric, nuclear, oil, gas), Water & Wastewater,
Transportation Systems, Communications, Government,
Emergency Services, Healthcare and Financial Services
Industrial/Government: Agencies like the U.S. Department of Defense
rely on high-security FIPS-certified keys that are notoriously slow
to upgrade. We estimate ~50 million "frozen" government keys. IoT
Security: Of the 21.9 billion connected IoT devices in 2026, only a
fraction use WebAuthn. However, for those that do (smart locks,
secure gateways), approximately 250 million are estimated to use
older, non-upgradable secure elements limited to 1024-byte payloads.
Recent government-level initiatives highlight the necessity to
"...effectively deprecate the use of RSA, Diffie-Hellman (DH), and
elliptic curve cryptography (ECDH and ECDSA) when mandated."
[CNSA-2], Page 4.
1.1.3. Urgency: Limit or Stop 'Harvest now; decrypt later' Attacks
Adversaries are collecting encrypted data today to decrypt when
quantum computers become available. The transition to post-quantum
cryptography (PQC) is critical for ensuring long-term security of
digital communications against adversaries equipped with large-scale
quantum computers. The National Institute of Standards and
Technology (NIST) has been leading standardization efforts, having
selected initial PQC algorithms and continuing to evaluate additional
candidates.
Mott Expires 25 October 2026 [Page 7]
Internet-Draft cose-sqisign April 2026
CBOR Object Signing and Encryption (COSE) [RFC9052] is specifically
designed for constrained node networks and IoT environments where
bandwidth, storage, and computational resources are limited. The
compact nature of SQIsign makes it an ideal candidate for COSE
deployments.
1.2. Scope and Status
This document is published on the *Standards* track rather than
Informational Track for the following reasons:
1. *Algorithm Maturity*: SQIsign is currently undergoing evaluation
in NIST's on-ramp process
2. *Continued Cryptanalysis*: The algorithm has active ongoing
review by the cryptographic research community, including the
IRTF CFRG
3. *High anticipated demand*: This specification enables
experimentation and early deployment to gather implementation
experience
*This document does not represent Working Group consensus on
algorithm innovation.* The COSE and JOSE working groups focus on
algorithm _integration_ and _encoding_, not cryptographic algorithm
design. The cryptographic properties of SQIsign are being evaluated
through NIST's process and academic peer review.
1.3. Relationship to Other Work
This document follows the precedent established by
[I-D.ietf-cose-falcon] and [I-D.ietf-cose-dilithium] for integrating
NIST PQC candidate algorithms into COSE and JOSE. The structure and
approach are intentionally aligned to provide consistency across
post-quantum signature scheme integrations.
1.4. Constrained Device Applicability
SQIsign is particularly attractive for:
* *IoT sensors* with limited flash memory
* *Firmware updates* over low-bandwidth networks (LoRaWAN, NB-IoT)
* *Embedded certificates* in constrained devices
* *Blockchain and DLT* where transaction size affects fees
Mott Expires 25 October 2026 [Page 8]
Internet-Draft cose-sqisign April 2026
* *Satellite communications* with bandwidth constraints
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 uses the following terms:
* *PQC*: Post-Quantum Cryptography
* *COSE*: CBOR Object Signing and Encryption
* *JOSE*: JSON Object Signing and Encryption
* *JWS*: JSON Web Signature
* *JWK*: JSON Web Key
* *CBOR*: Concise Binary Object Representation [RFC7049]
* *ECDH*: Elliptic Curve Diffie-Hellman
* *IANA*: Internet Assigned Numbers Authority
3. SQIsign Algorithm Overview
3.1. Cryptographic Foundation
SQIsign is based on the hardness of finding isogenies between
supersingular elliptic curves over finite fields. The security
assumption relies on:
1. The difficulty of the *Isogeny Path Problem*
2. The quaternion-based key generation providing computational
hardness equivalent to quantum-resistant assumptions
Unlike lattice-based schemes, isogeny-based cryptography offers:
* *Smaller key and signature sizes*
* *Algebraic structure* based on elliptic curve isogenies
Mott Expires 25 October 2026 [Page 9]
Internet-Draft cose-sqisign April 2026
* *Different security assumptions* (diversification from lattice-
based schemes)
3.2. Security Levels
SQIsign is defined with three parameter sets corresponding to NIST
security levels:
+===============+============+============+===========+===========+
| Parameter Set | NIST Level | Public Key | Signature | Classical |
| | | | | Sec |
+===============+============+============+===========+===========+
| SQIsign-L1 | I | 65 bytes | 148 bytes | ~128 bits |
+---------------+------------+------------+-----------+-----------+
| SQIsign-L3 | III | 97 bytes | 224 bytes | ~192 bits |
+---------------+------------+------------+-----------+-----------+
| SQIsign-L5 | V | 129 bytes | 292 bytes | ~256 bits |
+---------------+------------+------------+-----------+-----------+
Table 2
3.3. Performance Characteristics
* *Signing*: Computationally intensive (slower than lattice schemes)
* *Verification*: Moderate computational cost
* *Key Generation*: Intensive computation required
* *Size*: Exceptional efficiency (10 - 20x smaller than lattice
alternatives)
*Recommended Use Cases:* - Sign-once, verify-many scenarios
(firmware, certificates) - Bandwidth-constrained environments -
Storage-limited devices - Applications where signature/key size
dominates performance considerations
4. COSE Integration
This section defines the identifiers for SQIsign in COSE [RFC8152].
4.1. SQIsign Algorithms
The algorithms defined in this document are:
* SQIsign-L1: SQIsign NIST Level I (suggested value -61)
* SQIsign-L3: SQIsign NIST Level III (suggested value -62)
Mott Expires 25 October 2026 [Page 10]
Internet-Draft cose-sqisign April 2026
* SQIsign-L5: SQIsign NIST Level V (suggested value -63)
4.2. SQIsign Key Types
A new key type is defined for SQIsign with the name "SQIsign".
4.3. SQIsign Key Parameters
SQIsign keys use the following COSE Key common parameters:
+===============+============+===========+==========================+
| Key Parameter | COSE Label | CBOR Type | Description |
+===============+============+===========+==========================+
| kty | 1 | int | Key type: IETF |
| | | | (SQIsign) |
+---------------+------------+-----------+--------------------------+
| kid | 2 | bstr | Key ID (optional) |
+---------------+------------+-----------+--------------------------+
| alg | 3 | int | Algorithm identifier |
| | | | (-61, -62, or -63) |
+---------------+------------+-----------+--------------------------+
| key_ops | 4 | array | Key operations |
| | | | (sign, verify) |
+---------------+------------+-----------+--------------------------+
Table 3
4.4. SQIsign-Specific Key Parameters
+===============+=======+===========+====================+
| Key Parameter | Label | CBOR Type | Description |
+===============+=======+===========+====================+
| pub | -1 | bstr | SQIsign public key |
+---------------+-------+-----------+--------------------+
| priv | -2 | bstr | SQIsign private |
| | | | key (sensitive) |
+---------------+-------+-----------+--------------------+
Table 4
4.5. COSE Key Format Examples
4.5.1. Public Key (COSE_Key)
cbor { 1: IETF, / kty: SQIsign / 3: -61, / alg: SQIsign-L1 / -1:
h'[PUBLIC_KEY]' / pub: SQIsign public key bytes / }
Mott Expires 25 October 2026 [Page 11]
Internet-Draft cose-sqisign April 2026
4.5.2. Private Key (COSE_Key)
cbor { 1: IETF, / kty: SQIsign / 3: -61, / alg: SQIsign-L1 / -1:
h'[PUBLIC_KEY]', / pub: SQIsign public key bytes / -2:
h'[PRIVATE_KEY]' / priv: SQIsign private key bytes / }
4.6. COSE Signature Format
SQIsign signatures in COSE follow the standard COSE_Sign1 structure
[RFC9052]:
COSE_Sign1 = [ protected: bstr .cbor header_map, unprotected:
header_map, payload: bstr / nil, signature: bstr ]
The signature field contains the raw SQIsign signature bytes.
4.6.1. Protected Headers
The protected header MUST include:
cbor { 1: -61 / alg: SQIsign-L1, -62 for L3, -63 for L5 / }
4.6.2. Example COSE_Sign1 Structure
cbor 18( / COSE_Sign1 tag / [ h'A10139003C', / protected: {"alg":
-61} / {}, / unprotected /
h'546869732069732074686520636F6E74656E742E', / payload /
h'[SQISIGN_SIGNATURE_BYTES]' / signature / ] )
5. JOSE Integration
5.1. JSON Web Signature (JWS) Algorithm Registration
The following algorithm identifiers are registered for use in the JWS
"alg" header parameter for JSON Web Signatures [RFC7515]:
Mott Expires 25 October 2026 [Page 12]
Internet-Draft cose-sqisign April 2026
+================+==============+=============================+
| Algorithm Name | Description | Implementation Requirements |
+================+==============+=============================+
| SQIsign-L1 | SQIsign NIST | Optional |
| | Level I | |
+----------------+--------------+-----------------------------+
| SQIsign-L3 | SQIsign NIST | Optional |
| | Level III | |
+----------------+--------------+-----------------------------+
| SQIsign-L5 | SQIsign NIST | Optional |
| | Level V | |
+----------------+--------------+-----------------------------+
Table 5
5.2. JSON Web Key (JWK) Representation
SQIsign keys are represented in JWK [RFC7517] format as follows:
5.2.1. Public Key Parameters
+===========+========+===============================+
| Parameter | Type | Description |
+===========+========+===============================+
| kty | string | Key type: "SQIsign" |
+-----------+--------+-------------------------------+
| alg | string | Algorithm: "SQIsign-L1", |
| | | "SQIsign-L3", or "SQIsign-L5" |
+-----------+--------+-------------------------------+
| pub | string | Base64url-encoded public key |
+-----------+--------+-------------------------------+
| kid | string | Key ID (optional) |
+-----------+--------+-------------------------------+
| use | string | Public key use: "sig" |
| | | (optional) |
+-----------+--------+-------------------------------+
| key_ops | array | Key operations: [verify] |
| | | (optional) |
+-----------+--------+-------------------------------+
Table 6
5.2.2. Private Key Parameters
Private keys include all public key parameters plus:
Mott Expires 25 October 2026 [Page 13]
Internet-Draft cose-sqisign April 2026
+===========+========+===============================+
| Parameter | Type | Description |
+===========+========+===============================+
| priv | string | Base64url-encoded private key |
+-----------+--------+-------------------------------+
Table 7
5.3. JWK Examples
5.3.1. Public Key (JWK) Example
json { "kty": "SQIsign", "alg": "SQIsign-L1", "pub":
"KxtQx8s8RcBEU67wr57K37fdPEztN4M8NUC_\ 5xZuqgMwkaeJhM94YHi_-
2UsQllbnmm-W4XFSLm2hUwiMylrAh0", "kid": "2027-01-device-key", "use":
"sig", "key_ops": ["verify"] }
5.3.2. Private Key (JWK) Example
json { "kty": "SQIsign", "alg": "SQIsign-L1", "pub":
"KxtQx8s8RcBEU67wr57K37fdPEztN4M8NUC_\ 5xZuqgMwkaeJhM94YHi_-
2UsQllbnmm-W4XFSLm2hUwiMylrAh0", "priv":
"KxtQx8s8RcBEU67wr57K37fdPEztN4M8NUC_5xZuqgMwkaeJhM94YHi_\ -
2UsQllbnmm-W4XFSLm2hUwiMylrAh1VwP9vNkBZH0Bjj2wc-\
p7sUgQAAAAAAAAAAAAAAAAAAN68tviJbcCpQ84fh-4IJB4-\
____________________P38m3fKOhfhMspQU9GmA4CD5___\
_______________________________________________\
___________wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\ AAAAAAA5cP9aha40v-
8mFd_bdAgpR93Ug2iPhu4_NxG97C7\ 8wBvVMGOrQTCli7NxrR2KlPZR1AC5VddGf4p-
ZjCzrWfAJv\ xhEh4uOKXq1MmuS9TwZGuz1YIYMIguu1wqjdmfaQAfOmK2g\
WWO3vcld5s7GR2AcrTv65ocK_pVUWY8eJDcQA", "kid": "2027-01-device-key",
"use": "sig", "key_ops": ["sign"] }
5.4. JWS Compact Serialization
A JWS using SQIsign follows the standard compact serialization:
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS
Payload) || '.' || BASE64URL(JWS Signature)
5.4.1. Example JWS Protected Header
json { "alg": "SQIsign-L1", "typ": "JWT" }
Base64url-encoded: eyJhbGciOiJTUUlzaWduLUwxIiwidHlwIjoiSldUIn0
Mott Expires 25 October 2026 [Page 14]
Internet-Draft cose-sqisign April 2026
5.4.2. Complete JWS Example
eyJhbGciOiJTUUlzaWduLUwxIiwidHlwIjoiSldUIn0 . [BASE64URL_PAYLOAD] .
[BASE64URL_SQISIGN_SIGNATURE]
6. Implementation Considerations
6.1. Signature and Key Generation
Implementations MUST follow the SQIsign specification [SQIsign-Spec]
for:
* Key pair generation
* Signature generation
* Signature verification
6.2. Randomness Requirements
SQIsign signature generation requires high-quality randomness.
Implementations MUST use a cryptographically secure random number
generator (CSRNG) compliant with [RFC4086] or equivalent.
6.3. Side-Channel Protections
Implementations SHOULD implement protections against:
* Timing attacks
* Power analysis
* Fault injection attacks
Particularly for constrained devices deployed in physically
accessible environments.
6.4. Performance Trade-offs
Implementers should be aware:
* *Signing is computationally expensive*: Consider pre-signing or
batch operations
* *Verification is moderate*: Suitable for resource-constrained
verifiers
* *Size is exceptional*: Minimizes bandwidth and storage
Mott Expires 25 October 2026 [Page 15]
Internet-Draft cose-sqisign April 2026
6.5. Interoperability Testing
Early implementations SHOULD participate in interoperability testing
to ensure:
* Consistent signature generation and verification
* Proper encoding in COSE and JOSE formats
* Cross-platform compatibility
7. Security Considerations
7.1. Algorithm Security
The security of SQIsign relies on:
1. The hardness of finding isogenies between supersingular elliptic
curves
2. The computational difficulty of solving quaternion-based problems
These assumptions are *different from lattice-based schemes*,
providing cryptographic diversity in the post-quantum landscape.
7.2. Quantum Security
SQIsign is designed to resist attacks by large-scale quantum
computers. The three parameter sets provide security equivalent to
AES-128, AES-192, and AES-256 against both classical and quantum
adversaries.
7.3. Current Cryptanalysis Status
As of this writing, SQIsign is undergoing active cryptanalytic
review:
* *NIST Round 2 evaluation*: [NIST-Finalized-Standards]
* *Academic research*: Ongoing analysis of isogeny-based
cryptography
* *Known attacks*: No practical breaks of the security assumptions
*Implementers are advised*: - Monitor NIST announcements and updates
- Follow academic literature on isogeny cryptanalysis - Be prepared
to deprecate or update as cryptanalysis evolves
Mott Expires 25 October 2026 [Page 16]
Internet-Draft cose-sqisign April 2026
7.4. Implementation Security
7.4.1. Random Number Generation
Poor randomness can completely compromise SQIsign security.
Implementations MUST use robust CSRNGs, especially on constrained
devices with limited entropy sources.
7.4.2. Side-Channel Resistance
Constrained devices may be physically accessible to attackers.
Implementations SHOULD:
* Use constant-time algorithms where possible
* Implement countermeasures against DPA/SPA
* Consider fault attack mitigations
7.4.3. Key Management
* Private keys MUST be protected with appropriate access controls
* Consider hardware security modules (HSMs) or secure elements for
key storage
* Implement key rotation policies appropriate to the deployment
7.5. Cryptographic Agility
Organizations deploying SQIsign SHOULD:
* Maintain hybrid deployments with classical algorithms during
transition
* Plan for algorithm migration if cryptanalysis reveals weaknesses
* Monitor NIST and IRTF guidance on PQC deployment
7.6. Constrained Device Specific Risks
IoT devices face unique challenges:
* *Physical access*: Devices may be deployed in hostile environments
* *Limited update capability*: Firmware updates may be infrequent or
impossible
Mott Expires 25 October 2026 [Page 17]
Internet-Draft cose-sqisign April 2026
* *Long deployment lifetimes*: Devices may operate for 10+ years
Design systems with: - Defense in depth (multiple security layers) -
Remote update capability when possible - Graceful degradation if
algorithm is compromised
8. IANA Considerations
8.1. Additions to Existing Registries
IANA is requested to add the following entries to the COSE and JOSE
registries. The following completed registration actions are
provided as described in [RFC9053] and [RFC9054].
8.1.1. New COSE Algorithms
IANA is requested to register the following entries in the "COSE
Algorithms" registry:
+==========+=====+===========+==============+======+========+=====+
|Name |Value|Description| Capabilities |Change|Ref |Rec'd|
| | | | |Cont | | |
+==========+=====+===========+==============+======+========+=====+
|SQIsign-L1|-61 |SQIsign | kty |IETF |THIS-RFC|No |
| | |NIST L I | | | | |
+----------+-----+-----------+--------------+------+--------+-----+
|SQIsign-L3|-62 |SQIsign | kty |IETF |THIS-RFC|No |
| | |NIST L III | | | | |
+----------+-----+-----------+--------------+------+--------+-----+
|SQIsign-L5|-63 |SQIsign | kty |IETF |THIS-RFC|No |
| | |NIST L V | | | | |
+----------+-----+-----------+--------------+------+--------+-----+
Table 8
8.1.2. New COSE Key Types
IANA is requested to register the following entry in the "COSE Key
Types" registry:
Mott Expires 25 October 2026 [Page 18]
Internet-Draft cose-sqisign April 2026
+=========+=======+=============+==============+========+==========+
| Name | Value | Description | Capabilities | Change | Ref |
| | | | | Cont | |
+=========+=======+=============+==============+========+==========+
| SQIsign | IETF | SQIsign pub | sign, verify | IETF | THIS-RFC |
| | | key | | | |
+---------+-------+-------------+--------------+--------+----------+
Table 9
8.1.3. New COSE Key Type Parameters
IANA is requested to register the following entries in the "COSE Key
Type Parameters" registry:
+==========+======+=======+======+=========+========+===========+
| Key Type | Name | Label | CBOR | Desc | Change | Reference |
| | | | Type | | Cont | |
+==========+======+=======+======+=========+========+===========+
| SQIsign | pub | -1 | bstr | Public | IETF | THIS-RFC |
| | | | | key | | |
+----------+------+-------+------+---------+--------+-----------+
| SQIsign | priv | -2 | bstr | Private | IETF | THIS-RFC |
| | | | | key | | |
+----------+------+-------+------+---------+--------+-----------+
Table 10
8.1.4. New JWS Algorithms
IANA is requested to register the following entries in the "JSON Web
Signature and Encryption Algorithms" registry:
Mott Expires 25 October 2026 [Page 19]
Internet-Draft cose-sqisign April 2026
+============+==========+==========+======+==========+=============+
| Algorithm | Desc | Impl Req |Change| Ref | Recommended |
| Name | | |Cont | | |
+============+==========+==========+======+==========+=============+
| SQIsign-L1 | SQIsign | Optional |IETF | THIS-RFC | No |
| | NIST L I | | | | |
+------------+----------+----------+------+----------+-------------+
| SQIsign-L3 | SQIsign | Optional |IETF | THIS-RFC | No |
| | NIST L | | | | |
| | III | | | | |
+------------+----------+----------+------+----------+-------------+
| SQIsign-L5 | SQIsign | Optional |IETF | THIS-RFC | No |
| | NIST L V | | | | |
+------------+----------+----------+------+----------+-------------+
Table 11
8.1.5. New JSON Web Key Types
IANA is requested to register the following entry in the "JSON Web
Key Types" registry:
+===================+====================+=============+===========+
| "kty" Param Value | Key Type Desc | Change Cont | Reference |
+===================+====================+=============+===========+
| SQIsign | SQIsign public key | IETF | THIS-RFC |
+-------------------+--------------------+-------------+-----------+
Table 12
8.1.6. New JSON Web Key Parameters
IANA is requested to register the following entries in the "JSON Web
Key Parameters" registry:
+============+=========+=====================+========+===========+
| Param Name | Desc | Used with "kty" Val | Change | Reference |
| | | | Cont | |
+============+=========+=====================+========+===========+
| pub | Public | SQIsign | IETF | THIS-RFC |
| | key | | | |
+------------+---------+---------------------+--------+-----------+
| priv | Private | SQIsign | IETF | THIS-RFC |
| | key | | | |
+------------+---------+---------------------+--------+-----------+
Table 13
Mott Expires 25 October 2026 [Page 20]
Internet-Draft cose-sqisign April 2026
9. Acknowledgments
The authors would like to thank:
* The SQIsign design team (De Feo, Kohel, Leroux, Petit, Wesolowski)
for their groundbreaking work on isogeny-based signatures
* The NIST PQC team for managing the standardization process
* The COSE and JOSE working groups for guidance on integration
* The IRTF Crypto Forum Research Group for ongoing cryptanalytic
review
* Early implementers who provide valuable feedback
This work builds upon the template established by
[I-D.ietf-cose-falcon] and similar PQC integration efforts.
10. References
10.1. Normative References
_Populated automatically from metadata_
10.2. Informative References
_Populated automatically from metadata_
11. References
11.1. Normative References
[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>.
Mott Expires 25 October 2026 [Page 21]
Internet-Draft cose-sqisign April 2026
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/rfc/rfc8152>.
[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>.
[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>.
[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>.
11.2. Informative References
[CNSA-2] National Security Agency, "Commercial National Security
Algorithm Suite 2.0", May 2025,
<https://media.defense.gov/2025/May/30/ 2003728741/-1/-
1/0/CSA_CNSA_2.0_ALGORITHMS.PDF>.
[I-D.ietf-cose-dilithium]
Prorock, M. and O. Steele, "ML-DSA for JOSE and COSE",
Work in Progress, Internet-Draft, draft-ietf-cose-
dilithium-11, 15 November 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
dilithium-11>.
[I-D.ietf-cose-falcon]
Prorock, M., Steele, O., and H. Tschofenig, "FN-DSA for
JOSE and COSE", Work in Progress, Internet-Draft, draft-
ietf-cose-falcon-04, 15 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
falcon-04>.
[NIST-Finalized-Standards]
NIST, ""NIST Releases First 3 Finalized Post-Quantum
Encryption Standards"", August 2024,
<https://www.nist.gov/news-events/news/2024/08/ nist-
releases-first-3-finalized-post-quantum-encryption-
standards>.
Mott Expires 25 October 2026 [Page 22]
Internet-Draft cose-sqisign April 2026
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/rfc/rfc7049>.
[SQIsign-Analysis]
IACR ePrint Archive, ""SQIsign: Compact Post-Quantum
Signatures from Quaternions and Isogenies"", January 2021,
<https://eprint.iacr.org/2020/1240>.
[SQIsign-Spec]
De Feo, L., Kohel, D., Leroux, A., Petit, C., and B.
Wesolowski, "SQIsign: Compact Post-Quantum Signatures from
Quaternions and Isogenies (Round 2)", February 2025,
<https://sqisign.org/spec/sqisign-20250205.pdf>.
[WebAuthn-PQC-Signature-size-constraints]
University of Quantum Science, "WebAuthn PQC Signature
size constraints", April 2026,
<https://www.npmjs.com/package/quantum-resistant-
rustykey>.
Appendix A. Test Vectors
A.1. SQIsign-L1 Test Vectors
A.1.1. Example 1: Simple Message Signing
The following test vector exhibits a SQIsign Level I signature over a
short message.
Message (hex): d81c4d8d734fcbfbeade3d3f8a039faa2a2c9957e835ad55b2 \
2e75bf57bb556ac8 Message (ASCII): MsO=?*,W5U.uWUj
Public Key (hex): 07CCD21425136F6E865E497D2D4D208F0054AD81372066E \
817480787AAF7B2029550C89E892D618CE3230F23510BFBE68FCCDDAEA51DB1436 \
B462ADFAF008A010B Public Key (Base64url):
B8zSFCUTb26GXkl9LU0gjwBUrYE3IGboF0gHh6r3s \
gKVUMieiS1hjOMjDyNRC_vmj8zdrqUdsUNrRirfrwCKAQs
Signature (hex): 84228651f271b0f39f2f19f2e8718f31ed3365ac9e5cb303 \
afe663d0cfc11f0455d891b0ca6c7e653f9ba2667730bb77befe1b1a3182840428 \
4af8fd7baacc010001d974b5ca671ff65708d8b462a5a84a1443ee9b5fed721876 \
7c9d85ceed04db0a69a2f6ec3be835b3b2624b9a0df68837ad00bcacc27d1ec806 \
Mott Expires 25 October 2026 [Page 23]
Internet-Draft cose-sqisign April 2026
a44840267471d86eff3447018adb0a6551ee8322ab30010202 Signature
(Base64url): hCKGUfJxsPOfLxny6HGPMe0zZayeXLMDr-Zj0M_BHw \ RV2JGwymx-
ZT-bomZ3MLt3vv4bGjGChAQoSvj9e6rMAQAB2XS1ymcf9lcI2LRipahK \
FEPum1_tchh2fJ2Fzu0E2wppovbsO-g1s7JiS5oN9og3rQC8rMJ9HsgGpEhAJnRx2G \
7_NEcBitsKZVHugyKrMAECAg
A.1.2. COSE_Sign1 Complete Example
cbor 18( [ h'a10139003c', / protected: {"alg": -61} / {}, /
unprotected /
h'd81c4d8d734fcbfbeade3d3f8a039faa2a2c9957e835ad55b22e75bf57bb \
556ac8', / payload /
h'84228651f271b0f39f2f19f2e8718f31ed3365ac9e5cb303afe663d0cfc1 \
1f0455d891b0ca6c7e653f9ba2667730bb77befe1b1a31828404284af8fd7b \
aacc010001d974b5ca671ff65708d8b462a5a84a1443ee9b5fed7218767c9d \
85ceed04db0a69a2f6ec3be835b3b2624b9a0df68837ad00bcacc27d1ec806 \
a44840267471d86eff3447018adb0a6551ee8322ab30010202' ] )
A.1.3. JWS Complete Example
eyJhbGciOiJTUUlzaWduLUwxIiwidHlwIjoiSldUIn0 .
2BxNjXNPy_vq3j0_igOfqiosmVfoNa1Vsi51v1e7VWrI .
hCKGUfJxsPOfLxny6HGPMe0zZayeXLMDr-Zj0M_BHwRV2JGwymx-ZT-bomZ3MLt3vv \
4bGjGChAQoSvj9e6rMAQAB2XS1ymcf9lcI2LRipahKFEPum1_tchh2fJ2Fzu0E2wpp \
ovbsO-g1s7JiS5oN9og3rQC8rMJ9HsgGpEhAJnRx2G7_NEcBitsKZVHugyKrMAECAg
A.2. SQIsign-L3 Test Vectors
[PLACEHOLDER FOR L3 TEST VECTORS]
A.3. SQIsign-L5 Test Vectors
[PLACEHOLDER FOR L5 TEST VECTORS]
Appendix B. Implementation Status
[RFC Editor: Please remove this section before publication]
This section records the status of known implementations at the time
of writing.
B.1. Open Source Implementations
B.1.1. Reference Implementation
* *Organization*: SQIsign team
* *Repository*: https://github.com/SQISign/the-sqisign
Mott Expires 25 October 2026 [Page 24]
Internet-Draft cose-sqisign April 2026
* *Language*: C
* *License*: MIT
* *Status*: Active development
* *COSE/JOSE Support*: Not yet integrated
B.1.2. Rust Implementation
* *Organization*: IETF - Community implementation
* *Repository*: IETF
* *Language*: Rust
* *License*: IETF
* *COSE Support*: Planned
* *Status*: Development
B.2. Commercial Implementations
[RFC EDITOR: To be populated as vendors implement]
B.3. Interoperability Testing
* *Test Suite Location*: IETF
* *Participating Organizations*: IETF
Appendix C. Design Rationale
C.1. Algorithm Identifier Selection
The requested algorithm identifiers (-61, -62, -63) are:
* In the range designated for experimental/informational use
* Sequential for the three parameter sets
* Not conflicting with existing registrations
* Consistent with the approach used for other PQC algorithms
Mott Expires 25 October 2026 [Page 25]
Internet-Draft cose-sqisign April 2026
C.2. Key Type Design
The SQIsign key type is intentionally simple:
* Only two parameters (pub, priv) following minimalist design
* Binary encoding (bstr) for efficiency
* No algorithm-specific encoding—raw bytes from SQIsign spec
This approach: - Minimizes CBOR encoding overhead (critical for
constrained devices) - Simplifies implementation - Provides future
flexibility for parameter set evolution
Appendix D. Change Log
[RFC Editor Note:** Please remove this section before publication]
D.1. draft-mott-cose-sqisign-00
* Initial version
* Algorithm registrations for SQIsign-L1, L3, L5
* COSE and JOSE integration specifications
* Security considerations for constrained devices
Author's Address
Antony R. Mott
RustyKey
Email: antony@rustykey.io
Mott Expires 25 October 2026 [Page 26]