COSE A. R. Mott Internet-Draft RustyKey® Intended status: Standards Track 4 September 2026 Expires: 8 March 2027 CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for SQIsign draft-mott-cose-sqisign-07 Abstract *NOTE: This document describes a signature scheme based on the SQIsign algorithm currently under evaluation in the 3rd round 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 an unusually compact signature and public key size among candidates of the NIST Post-Quantum Cryptography (PQC) standardization and on-ramp-to-standardization processes. The standardization of SQIsign will be helpful to address current infrastructure bottlenecks, specifically the FIDO2 CTAP2 specification used by many in-service devices. This document clarifies that SQIsign does not expose the auxiliary torsion-point information exploited in the SIDH/SIKE attacks. Consequently, the specific attack techniques of Castryck–Decru do not directly apply. However, the scheme remains subject to ongoing cryptanalysis of isogeny-based constructions. 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 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/. Mott Expires 8 March 2027 [Page 1] Internet-Draft cose-sqisign September 2026 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 8 March 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background and Motivation . . . . . . . . . . . . . . . . 5 1.1.1. Pressing Need: Smaller PQC Signatures . . . . . . . . 5 1.1.2. Pressing Need: Limit or Stop 'Harvest now; decrypt later' Attacks . . . . . . . . . . . . . . . . . . . 7 1.1.3. Unprecedented regulatory urgency: from theoretcial Mott Expires 8 March 2027 [Page 2] Internet-Draft cose-sqisign September 2026 planning to legally binding enforcement . . . . . . . 8 1.1.4. Direct usecase of SQIsign-L1 over existing NIST-approved algorithms: Verifiable Credentials Selective Disclosure Over Optical, BLE and other Constrained-Bandwidth Channels . . . . . . . . . . . 8 1.2. Scope and Status . . . . . . . . . . . . . . . . . . . . 11 1.3. Relationship to Other Work . . . . . . . . . . . . . . . 11 1.4. Constrained Device Applicability . . . . . . . . . . . . 11 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 12 3. Cryptanalytic Resistance: SIDH/SIKE Attacks Do Not Apply . . 12 3.1. SIKE Vulnerability (The "Torsion Point" Attack) of 2022 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Why SQISign appears unaffected by the SIKE Vulnerability . . . . . . . . . . . . . . . . . . . . . . 13 4. SQIsign Algorithm Overview . . . . . . . . . . . . . . . . . 13 4.1. Cryptographic Foundation . . . . . . . . . . . . . . . . 13 4.2. Security Levels . . . . . . . . . . . . . . . . . . . . . 14 4.3. Performance Characteristics . . . . . . . . . . . . . . . 14 4.4. SQIsign Variants and the Post-SIKE Landscape . . . . . . 14 4.4.1. Core SQIsign (Dimension 1) . . . . . . . . . . . . . 15 4.4.2. Multi-dimensional variants . . . . . . . . . . . . . 15 5. COSE Integration . . . . . . . . . . . . . . . . . . . . . . 16 5.1. SQIsign Algorithms . . . . . . . . . . . . . . . . . . . 16 5.2. SQIsign Key Types . . . . . . . . . . . . . . . . . . . . 16 5.3. SQIsign Key Parameters . . . . . . . . . . . . . . . . . 16 5.4. SQIsign-Specific Key Parameters . . . . . . . . . . . . . 17 5.5. COSE Key Format Examples . . . . . . . . . . . . . . . . 17 5.5.1. Public Key (COSE_Key) . . . . . . . . . . . . . . . . 17 5.5.2. Private Key (COSE_Key) . . . . . . . . . . . . . . . 17 5.6. COSE Signature Format . . . . . . . . . . . . . . . . . . 17 5.6.1. Protected Headers . . . . . . . . . . . . . . . . . . 17 5.6.2. Example COSE_Sign1 Structure . . . . . . . . . . . . 18 6. JOSE Integration . . . . . . . . . . . . . . . . . . . . . . 18 6.1. JSON Web Signature (JWS) Algorithm Registration . . . . . 18 6.2. JSON Web Key (JWK) Representation . . . . . . . . . . . . 18 6.2.1. Public Key Parameters . . . . . . . . . . . . . . . . 18 6.2.2. Private Key Parameters . . . . . . . . . . . . . . . 19 6.3. JWK Examples . . . . . . . . . . . . . . . . . . . . . . 19 6.3.1. Public Key (JWK) Example . . . . . . . . . . . . . . 19 6.3.2. Private Key (JWK) Example . . . . . . . . . . . . . . 19 6.4. JWS Compact Serialization . . . . . . . . . . . . . . . . 20 6.4.1. Example JWS Protected Header . . . . . . . . . . . . 20 6.4.2. Complete JWS Example . . . . . . . . . . . . . . . . 20 7. Implementation Considerations . . . . . . . . . . . . . . . . 20 7.1. Signature and Key Generation . . . . . . . . . . . . . . 20 7.2. Randomness Requirements . . . . . . . . . . . . . . . . . 20 7.3. Side-Channel Protections . . . . . . . . . . . . . . . . 20 7.4. Performance Trade-offs . . . . . . . . . . . . . . . . . 21 Mott Expires 8 March 2027 [Page 3] Internet-Draft cose-sqisign September 2026 7.5. Interoperability Testing . . . . . . . . . . . . . . . . 21 7.6. Performance testing under real-world scenarios . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8.1. Algorithm Security . . . . . . . . . . . . . . . . . . . 21 8.2. Quantum Security . . . . . . . . . . . . . . . . . . . . 21 8.3. Cryptanalysis and Algorithm Maturity . . . . . . . . . . 22 8.4. Implementation Security . . . . . . . . . . . . . . . . . 22 8.4.1. Random Number Generation . . . . . . . . . . . . . . 22 8.4.2. Side-Channel Resistance . . . . . . . . . . . . . . . 22 8.4.3. Key Management . . . . . . . . . . . . . . . . . . . 22 8.5. Cryptographic Agility . . . . . . . . . . . . . . . . . . 23 8.6. Constrained Device Specific Risks . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.1. Additions to Existing Registries . . . . . . . . . . . . 23 9.1.1. New COSE Algorithms . . . . . . . . . . . . . . . . . 23 9.1.2. New COSE Key Types . . . . . . . . . . . . . . . . . 24 9.1.3. New COSE Key Type Parameters . . . . . . . . . . . . 24 9.1.4. New JWS Algorithms . . . . . . . . . . . . . . . . . 25 9.1.5. New JSON Web Key Types . . . . . . . . . . . . . . . 25 9.1.6. New JSON Web Key Parameters . . . . . . . . . . . . . 26 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 31 A.1. SQIsign-L1 Test Vectors . . . . . . . . . . . . . . . . . 31 A.1.1. Example 1: Simple Message Signing . . . . . . . . . . 31 A.1.2. COSE_Sign1 Complete Example . . . . . . . . . . . . . 32 A.1.3. JWS Complete Example . . . . . . . . . . . . . . . . 32 A.2. SQIsign-L3 Test Vectors . . . . . . . . . . . . . . . . . 32 A.2.1. Example 1: Simple Message Signing . . . . . . . . . . 32 A.2.2. COSE_Sign1 Complete Example . . . . . . . . . . . . . 33 A.2.3. JWS Complete Example . . . . . . . . . . . . . . . . 33 A.3. SQIsign-L5 Test Vectors . . . . . . . . . . . . . . . . . 33 A.3.1. Example 1: Simple Message Signing . . . . . . . . . . 34 A.3.2. COSE_Sign1 Complete Example . . . . . . . . . . . . . 35 A.3.3. JWS Complete Example . . . . . . . . . . . . . . . . 35 Appendix B. Implementation Status . . . . . . . . . . . . . . . 35 B.1. Open Source Implementations . . . . . . . . . . . . . . . 35 B.1.1. Reference Implementation . . . . . . . . . . . . . . 35 B.1.2. Rust Implementation . . . . . . . . . . . . . . . . . 36 B.2. Commercial Implementations . . . . . . . . . . . . . . . 36 B.3. Interoperability Testing . . . . . . . . . . . . . . . . 36 Appendix C. Design Rationale . . . . . . . . . . . . . . . . . . 36 C.1. Algorithm Identifier Selection . . . . . . . . . . . . . 36 Mott Expires 8 March 2027 [Page 4] Internet-Draft cose-sqisign September 2026 C.2. Key Type Design . . . . . . . . . . . . . . . . . . . . . 36 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 37 D.1. draft-mott-cose-sqisign-07 . . . . . . . . . . . . . . . 37 D.2. draft-mott-cose-sqisign versions prior to -07 . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction This document registers algorithm identifiers and key type parameters for SQIsign in COSE and JOSE. 1.1. Background and Motivation Post-quantum cryptography readiness is critical for constrained devices. As of late 2026, while FIDO2/WebAuthn supports various COSE algorithms, some hardware authenticators 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. Pressing Need: Smaller PQC Signatures FN-DSA (Falcon) and ML-DSA (Dilithium) have larger signatures that may not fit in constrained environments. Depending on authenticator implementation, transport (USB/NFC/BLE), and fragmentation support, many CTAP2 authenticators impose practical limits near 1024 bytes for external key communication — well below CTAP2's own protocol ceiling for message reassembly, commonly cited around 7609 bytes [CTAP2-spec]. Post-quantum signature schemes with larger keys or signatures risk pushing messages toward either limit, stressing constrained authenticators and transports. SQIsign-L1, L3, and L5 signatures remain small enough to fit comfortably within both constraints, and are well suited to highly constrained networks such as 802.15.4. 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 that offers an unusually small signature compared to other PQC signature candidate under NIST evaluation, historically at the cost of the most computationally intensive signing operation of Mott Expires 8 March 2027 [Page 5] Internet-Draft cose-sqisign September 2026 the group. SQIsign is an isogeny-based digital signature scheme participating in NIST's Round 3 [NIST-3rd-round-candidates] Additional Digital Signature Schemes, not yet a NIST standard. Early reference implementations, evaluated prior to browser WebAssembly (WASM) and GPU-compute optimization, reported signing times of seconds, not microseconds even for Level 1 parameters. More recent implementations of actual browser-code variant for WebAuthn PassKey are routinely lss than 1 second [WebAuthn-PQC-Signature-size-constraints]. As a directly reproducible counter-data-point: the authors' own SQIsign-L1 WASM implementation, exercised end-to-end as a JWS signing operation, measures a repeatable average of *350ms* each signature, measured on consumer device [PQC-Testbed-VC-Bench]. A WebGPU- accelerated variant of the same implementation -- which requires crossOriginIsolated:true (i.e., COOP/COEP response headers enabling SharedArrayBuffer, Atomics-synchronized cross-thread WASM linear memory access, and enhanced-precision performance.now()) -- reduces this further to a routine average of *155ms* per signature, on the same hardware and browser. Both figures are independently reproducible against the live implementation at the cited testbed tab which enumerates sample size and full measurement methodology. This measurement reflects a high-end consumer platform and should be read as an upper bound on currently-achievable browser performance, not as representative of lower-end mobile devices, older hardware, or the constrained authenticators and platform modules discussed above. Benchmarks on representative mid-tier and mobile hardware are planned and will be published at [PQC-Testbed-VC-Bench] as they become available. As of this writing, comparable measurements have not been confirmed on Safari, Firefox, or Edge; the WebGPU-accelerated path in particular is expected to vary with each browser's crossOriginIsolated:true enforcement and WebGPU compute-shader support, and should not be assumed portable without independent verification. Speed: even at 350ms (WASM) or 155ms (WASM with WebGPU-acceleration), SQIsign-L1 signing remains slower than ML-DSA signing on comparable hardware. Implementers should treat _both_ the early and current figures as implementation-dependent, not intrinsic to the algorithm, and should expect continued improvement as WASM (nodejs backend and browser frontend) and WebGPU-accelerated (browser-only) implementations mature. Table 1 compares representative parameter sets; note that these schemes are at different stages of standardization and evaluation. Mott Expires 8 March 2027 [Page 6] Internet-Draft cose-sqisign September 2026 +=============+=================+================+==============+ | Algorithm | Public Key Size | Signature Size | PK + Sig | | | | | Fits < 1024? | +=============+=================+================+==============+ | ML-DSA-44 | 1,312 bytes | 2,420 bytes | ❌ (3,732 | | | | | total) | +-------------+-----------------+----------------+--------------+ | ML-DSA-65 | 1,952 bytes | 3,293 bytes | ❌ (5,245 | | | | | total) | +-------------+-----------------+----------------+--------------+ | ML-DSA-87 | 2,592 bytes | 4,595 bytes | ❌ (7,187 | | | | | total) | +-------------+-----------------+----------------+--------------+ | FN-DSA-512 | 897 bytes | 666 bytes | ❌ (1,563 | | | | | total) | +-------------+-----------------+----------------+--------------+ | FN-DSA-1024 | 1,793 bytes | 1,280 bytes | ❌ (3,073 | | | | | total) | +-------------+-----------------+----------------+--------------+ | 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. Pressing Need: 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. 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. Mott Expires 8 March 2027 [Page 7] Internet-Draft cose-sqisign September 2026 1.1.3. Unprecedented regulatory urgency: from theoretcial planning to legally binding enforcement Regulatory urgency for post-quantum migration is not confined to a single jurisdiction. In the United States, Executive Order 14413 [EO14413] directs the continued acceleration of quantum-resistant cryptography adoption across federal systems and critical infrastructure. This order builds on the algorithm guidance established in [CNSA-2] which highlights the necessity to "...effectively deprecate the use of RSA, Diffie-Hellman (DH), and elliptic curve cryptography (ECDH and ECDSA) when mandated.", Page 4. Outside North America, the United Arab Emirates' National Encryption Policy [UAE-NEP] established national requirements for encryption practice and migration planning as post-quantum algorithms mature and become standardized. In the Asia-Pacific region, Singapore's Cyber Security Agency (CSA), in coordination with the Monetary Authority of Singapore (MAS), issued a Quantum-Safe Migration Handbook [SG-CSA-QSMH] that required operators of critical information infrastructure (CII) to submit a full migration plan by March 2027 and complete migration to quantum- resistant encryption by 2031. In Europe the G7 (with CISA) released a call to action [G7-CISA] to governments and organizations to begin their PQC transition as soon as possible to avoid exposure to quantum risks and to provide a level of long-term protection of confidential data. There's now a convergence across independently governed jurisdictions in North America, the Gulf region, and Southeast Asia. Harvest-now- decrypt-later is turning into a matter of near-term operational urgency worldwide rather than a single country's policy position, driving also need for compact, deployable PQC signature schemes such as SQIsign. 1.1.4. Direct usecase of SQIsign-L1 over existing NIST-approved algorithms: Verifiable Credentials Selective Disclosure Over Optical, BLE and other Constrained-Bandwidth Channels 1.1.4.1. Selective-Disclosure Credential Deployments Selective-disclosure credential systems allow a holder to reveal only selected issuer-authenticated claims. The credential format and presentation protocol, rather than the COSE or JOSE signature algorithm alone, determine the resulting privacy properties. Mott Expires 8 March 2027 [Page 8] Internet-Draft cose-sqisign September 2026 For example, an issuer can sign a commitment structure over a set of claims. A holder may disclose a claim together with the information needed to verify that the claim is included in the issuer-signed structure. Depending on the construction, a presentation can include commitment openings, inclusion proofs, issuer identifiers, status information, device authentication, or other protocol-specific data. 1.1.4.2. Linkable claims selective disclosure Re-use of a static issuer-signed credential structure can permit correlation between presentations. Correlation across presentations is required. Example: Hazardous-materials ("hazmat") shipping manifests are re-verified by carriers, first responders, and regulators at multiple points along a transport chain; confirming that each checkpoint is looking at the same declared shipment is necessary for safety and audit purposes. Other linkable examples include origin, materials, environmental performance, and recycling claims. 1.1.4.3. Unlinkable claims selective disclosure Applications requiring presentation unlinkability need a protocol- level construction with an explicit unlinkability definition and threat model. Conventional digital signature schemes, including current PQC signature schemes, do not by themselves provide re- randomizable zero-knowledge presentations of signed claims. Correlation across presentations are not required or wanted. Mobile driving licenses (mDLs) [USDOT49CFR172], as specified in [ISO18013-5], are the clearest example: a holder must not be traceable across unrelated age- or identity-verification events, even by colluding verifiers. Classical algorithms (pre-PQC) like BBS/BBS+ solve this natively and efficiently (by added size in bytes): a single signature supports an unbounded number of statistically independent, re-randomizable zero- knowledge proofs over the same underlying claims. It is unsuitable for PQC deployment, however, for a reason distinct from unlinkability itself: BBS/BBS+ security rests on pairing-friendly elliptic curves. Elliptic curves are broken by Shor's algorithm, so _unforgeability_ -- not merely unlinkability -- collapses against a quantum adversary. BBS/BBS+ is therefore excluded from consideration entirely, not merely deprioritized. Some designs may issue multiple independently usable issuer- authenticated artifacts to a holder, for example the new Digital Product Passport [DPP]. In such designs, compact signatures can reduce issuance bandwidth, holder storage, and presentation size. Mott Expires 8 March 2027 [Page 9] Internet-Draft cose-sqisign September 2026 The benefit is especially relevant where credentials are transferred using constrained channels, such as QR codes, NFC, BLE, or low- bandwidth networks. Under this pattern, per-presentation cost scales as: cost = (claims revealed) x (batch depth) x (signature size) This multiplication is tractable at any scale only with a small per- signature size. Table 2 summarizes which combination of approach and algorithm remains viable as claim count grows: +=============+=======================+=============================+ | Disclosure | Viable algorithm(s) | Constraint | | mode | | | +=============+=======================+=============================+ | Linkable | FN-DSA, ML-DSA, or | Signature cost paid | | (any claim | SQIsign, any level | once; size doesn't | | count) | | scale with claims | +-------------+-----------------------+-----------------------------+ | Unlinkable, | ML-DSA-/FN-DSA-class, | Tractable only while | | small claim | or SQIsign-L1 | claims x batch depth | | count | | stays small | +-------------+-----------------------+-----------------------------+ | Unlinkable, | *SQIsign-L1* | ML-DSA-/FN-DSA-class | | large claim | | signature sizes make | | count | | claims x batch depth x | | | | sig-size prohibitive; | | | | SQIsign-L1's ECDSA/ | | | | EdDSA-class size is | | | | the only presently | | | | known PQC-safe option | | | | that stays affordable | +-------------+-----------------------+-----------------------------+ Table 2 This document does not define a selective-disclosure credential format, unlinkability mechanism, commitment scheme, revocation mechanism, or presentation protocol. Such mechanisms are application- and ecosystem-specific, and nothing in this section shall diminish the applicability of FN-DSA or ML-DSA for linkable SD, or wherever NFC, fast-BLE, or other non-optical transports are available. Mott Expires 8 March 2027 [Page 10] Internet-Draft cose-sqisign September 2026 1.2. Scope and Status This document specifies interoperable COSE and JOSE representations for a defined version of SQIsign. It does not make an independent determination of the cryptographic suitability of SQIsign. This document is published on the *Standards* track rather than Informational Track. *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. If a WG wishes to pursue this as Standards Track, the document’s best support is a stable, precise, interoperable encoding specification supported by: 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 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: * *QR code printers, any display screen, scanners* especially mobile consumer-grade * *IoT sensors* with limited flash memory * *Firmware updates* over low-bandwidth networks (LoRaWAN, NB-IoT) Mott Expires 8 March 2027 [Page 11] Internet-Draft cose-sqisign September 2026 * *Embedded certificates* burned into the OS, or added to the secure enclave of a constrained device * *Blockchain and DLT* where transaction size affects gas fees * *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 [RFC8949] * *ECDH*: Elliptic Curve Diffie-Hellman * *IANA*: Internet Assigned Numbers Authority 3. Cryptanalytic Resistance: SIDH/SIKE Attacks Do Not Apply 3.1. SIKE Vulnerability (The "Torsion Point" Attack) of 2022 SIKE (Supersingular Isogeny Key Encapsulation) was a key exchange, more specifically, a Key Encapsulation Mechanism (KEM). In the SIKE protocol, users had to share more than just the target elliptic curve. To make the math work for key exchange, they shared the images of specific points (called torsion points) under the secret isogeny. * The Info: If the secret isogeny is 𝜙, SIKE gave away 𝜙(𝑃) and 𝜙(𝑄) for specific basis points 𝑃 and 𝑄. Mott Expires 8 March 2027 [Page 12] Internet-Draft cose-sqisign September 2026 * The Break: In 2022, Castryck and Decru showed that this auxiliary information allowed an attacker to allowed an attacker to construct a higher-dimensional abelian variety linking the public data. In this setting, the secret isogeny can be recovered efficiently using techniques based on Kani’s results on isogenies between products of elliptic curves. * The Oversight: For years, cryptanalysts thought this extra info was harmless. Related techniques existed in the algebraic geometry literature but had not previously been applied in this cryptographic context. 3.2. Why SQISign appears unaffected by the SIKE Vulnerability * SQIsign is a signature scheme in which the prover demonstrates knowledge of an isogeny through a zero-knowledge protocol. Unlike SIDH/SIKE, it does not publish images of torsion basis points under secret isogenies. * Castryck–Decru attack relies critically on this auxiliary torsion- point information to construct additional structure (e.g., via abelian surfaces) that enables efficient recovery of the secret isogeny. * SQIsign does not provide such auxiliary data, so these techniques do not directly apply. Attacks would instead need to solve instances of the isogeny path problem or related problems in the endomorphism ring, for which no comparable shortcut is currently known. 4. SQIsign Algorithm Overview 4.1. Cryptographic Foundation SQIsign is based on the hardness of finding isogenies between supersingular elliptic curves over finite fields. The security assumption relies primarily on the difficulty of the *Isogeny Path Problem* Unlike lattice-based schemes, isogeny-based cryptography offers: * *Smaller key and signature sizes* * *Algebraic structure* based on elliptic curve isogenies * *Different security assumptions* (diversification from lattice- based schemes) Mott Expires 8 March 2027 [Page 13] Internet-Draft cose-sqisign September 2026 4.2. Security Levels SQIsign is defined with three parameter sets corresponding to NIST security levels: +===============+=======+========+===========+==================+ | Parameter Set | NIST | Public | Signature | Quantum Security | | | Level | Key | | (estimated) | +===============+=======+========+===========+==================+ | SQIsign-L1 | I | 65 | 148 bytes | ~128 bits | | | | bytes | | | +---------------+-------+--------+-----------+------------------+ | SQIsign-L3 | III | 97 | 224 bytes | ~192 bits | | | | bytes | | | +---------------+-------+--------+-----------+------------------+ | SQIsign-L5 | V | 129 | 292 bytes | ~256 bits | | | | bytes | | | +---------------+-------+--------+-----------+------------------+ Table 3 4.3. Performance Characteristics * *Signing*: Computationally intensive relative to lattice schemes in unoptimized reference code; substantially faster in optimized WASM/WebGPU browser implementations (see [PQC-Testbed-VC-Bench]). * *Verification*: Moderate computational cost * *Key Generation*: Intensive computation required * *Size*: Exceptional efficiency: substantially smaller than many lattice-based alternatives at comparable security levels *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.4. SQIsign Variants and the Post-SIKE Landscape While the SQIsign team initially focused on improving the core algorithm, the 2022 SIKE vulnerability catalyzed broader research into higher-dimensional algebraic geometry, particularly investigating improvements to key and signature generation speed—widely viewed as implementation bottlenecks. Mott Expires 8 March 2027 [Page 14] Internet-Draft cose-sqisign September 2026 This interest has sparked an evolution of SQIsign variants, all still based on the baseline algorithm currently competing in NIST's Round 3. Remarkably, two independent groups published dimension-2 variants on the same day (May 13, 2024), with a third appearing the following day—demonstrating the rapid, simultaneous evolution of the field following the 2022 SIKE breakthrough. Given this dynamic environment, readers interested in SQIsign's future will benefit from this summary, which we intend to update with each revision of this standards-track submission. The key takeaway is that researchers have repurposed the higher- dimensional techniques from the SIKE cryptanalysis to optimize SQIsign variants with faster signing and potentially smaller sizes, while each group attempts to maintain equivalent post-quantum security levels. Variants can be classified primarily by the geometric dimensions they employ: 4.4.1. Core SQIsign (Dimension 1) The baseline algorithm currently competing in NIST's Round 3. The SQIsign team, in cooperation with IBM researchers, actively maintains and tunes this version. Recent updates focus on reducing memory footprints and accelerating core algebraic operations for practical implementation. However, NIST's current process permits only minor "tweaks" rather than substantial algorithmic changes. 4.4.2. Multi-dimensional variants * SQIsignHD [SQIsignHD] dramatically shrunk signature sizes, simplified verification. * SQIsign2D-West [SQIsign2D-West] prioritized a rigorous security proof over raw speed. * SQIsign2D-East [SQIsign2D-East] fast 2D verification using a generalized random isogeny algorithm. * SQIPrime [SQIPrime]: Offers two sub-variants with different dimension trade-offs: - SQIPrime2D: Uses only dimension 2 non-smooth challenge isogenies, avoiding the dimension 4 computations required by SQIsignHD. More efficient while remaining highly compact compared to non-isogeny PQC schemes. Mott Expires 8 March 2027 [Page 15] Internet-Draft cose-sqisign September 2026 - SQIPrime4D: Uses dimension 4 isogenies for response representation, prioritizing maximum compactness at the cost of exponentially higher runtime. Despite the paper's title, this sub-variant represents the authors' exploration before settling on the 2D approach. 5. COSE Integration This section defines the identifiers for SQIsign in COSE [RFC9053]. This section defines identifiers and parameters for representing SQIsign keys and signatures in COSE [RFC9052], including a new COSE key type, key-type-specific key parameters, and algorithm identifiers to be registered in the IANA "COSE Algorithms" registry [RFC9053]. 5.1. SQIsign Algorithms This document defines the following COSE algorithm identifiers. Values are suggested for early allocation and are subject to confirmation by IANA (see IANA Considerations). +============+=======================================+=============+ | Name | Description | Value (TBD) | +============+=======================================+=============+ | SQIsign-L1 | SQIsign, NIST PQC Security Category 1 | -61 | +------------+---------------------------------------+-------------+ | SQIsign-L3 | SQIsign, NIST PQC Security Category 3 | -62 | +------------+---------------------------------------+-------------+ | SQIsign-L5 | SQIsign, NIST PQC Security Category 5 | -63 | +------------+---------------------------------------+-------------+ Table 4 5.2. SQIsign Key Types A new COSE key type is defined for SQIsign, with the name "SQIsign" and value TBD-KTY, to be assigned from the IANA "COSE Key Types" registry. 5.3. SQIsign Key Parameters SQIsign keys use the COSE_Key common parameters defined in Section 7.1 of [RFC9052], with the following specific assignments: * The 'kty' parameter (1) MUST be TBD-KTY (*). * The 'alg' parameter (3) MUST be -61 (SQIsign-L1), -62 (SQIsign- L3), or -63 (SQIsign-L5). Mott Expires 8 March 2027 [Page 16] Internet-Draft cose-sqisign September 2026 (*) [RFC Editor Note: Please replace TBD-KTY with the next available positive integer integer assigned by IANA in the COSE Key Types registry, and remove this note.] 5.4. SQIsign-Specific Key Parameters The following key-type-specific parameters are defined for kty = SQIsign. As with other key types (e.g., OKP), these labels are scoped to kty = SQIsign and do not collide with parameters of other key types. | Key Parameter | Label | CBOR Type | Description | |---------------|-------|-----------|-------------| | pub | -1 | bstr | SQIsign public key | | priv | -2 | bstr | *SQIsign private key (sensitive) | *MUST NOT appear in a public COSE_Key and MUST be handled as sensitive key material 5.5. COSE Key Format Examples Examples use CBOR diagnostic notation (Section 8 of [RFC8949]). TBD- KTY denotes the value to be assigned to the SQIsign key type by IANA. Key material is truncated for readability. 5.5.1. Public Key (COSE_Key) cbor-diag { 1: TBD-KTY, / kty: SQIsign / 3: -61, / alg: SQIsign-L1 / -1: h'[PUBLIC_KEY]' / pub: SQIsign public key bytes / } 5.5.2. Private Key (COSE_Key) cbor-diag { 1: TBD-KTY, / 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 / } 5.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. 5.6.1. Protected Headers The protected header MUST include: Mott Expires 8 March 2027 [Page 17] Internet-Draft cose-sqisign September 2026 cbor-diag { 1: -61 / alg: SQIsign-L1, -62 for L3, -63 for L5 / } 5.6.2. Example COSE_Sign1 Structure cbor-diag 18( / COSE_Sign1 tag / [ h'A10139003C', / protected: {"alg": -61} / {}, / unprotected / h'546869732069732074686520636F6E74656E742E', / payload / h'[SQISIGN_SIGNATURE_BYTES]' / signature / ] ) 6. JOSE Integration 6.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]: +================+==============+=============================+ | 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 6.2. JSON Web Key (JWK) Representation SQIsign keys are represented in JWK [RFC7517] format as follows: 6.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) | Mott Expires 8 March 2027 [Page 18] Internet-Draft cose-sqisign September 2026 +-----------+--------+-------------------------------+ | use | string | Public key use: "sig" | | | | (optional) | +-----------+--------+-------------------------------+ | key_ops | array | Key operations: [verify] | | | | (optional) | +-----------+--------+-------------------------------+ Table 6 6.2.2. Private Key Parameters Private keys include all public key parameters plus: +===========+========+===============================+ | Parameter | Type | Description | +===========+========+===============================+ | priv | string | Base64url-encoded private key | +-----------+--------+-------------------------------+ Table 7 6.3. JWK Examples 6.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"] } 6.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"] } Mott Expires 8 March 2027 [Page 19] Internet-Draft cose-sqisign September 2026 6.4. JWS Compact Serialization A JWS using SQIsign follows the standard compact serialization: BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature) 6.4.1. Example JWS Protected Header json { "alg": "SQIsign-L1", "typ": "JWT" } Base64url-encoded: eyJhbGciOiJTUUlzaWduLUwxIiwidHlwIjoiSldUIn0 6.4.2. Complete JWS Example eyJhbGciOiJTUUlzaWduLUwxIiwidHlwIjoiSldUIn0 . [BASE64URL_PAYLOAD] . [BASE64URL_SQISIGN_SIGNATURE] 7. Implementation Considerations 7.1. Signature and Key Generation Implementations MUST follow the SQIsign specification [SQIsign-Spec] for: * Key pair generation * Signature generation * Signature verification 7.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. 7.3. Side-Channel Protections Implementations SHOULD implement protections against: * Timing attacks * Power analysis * Fault injection attacks Mott Expires 8 March 2027 [Page 20] Internet-Draft cose-sqisign September 2026 Particularly for constrained devices deployed in physically accessible environments. 7.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 7.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.6. Performance testing under real-world scenarios * public metrics, interoperability and performance testing of the proposed WASM versions can be evaluated on a live testbed [PQC-Testbed]. 8. Security Considerations 8.1. Algorithm Security The security of SQIsign relies primarily on the hardness of finding isogenies between supersingular elliptic curves. These assumptions are *different from lattice-based schemes*, providing cryptographic diversity in the post-quantum landscape. 8.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. Mott Expires 8 March 2027 [Page 21] Internet-Draft cose-sqisign September 2026 8.3. Cryptanalysis and Algorithm Maturity As of this writing, SQIsign is undergoing active cryptanalytic review: * *NIST Round 3 evaluation*: [NIST-3rd-round-candidates] * *Academic research*: Ongoing analysis of isogeny-based cryptography * *Known attacks*: No attacks are currently known that recover private keys for the standardized parameter sets within their claimed security levels. However, the scheme and its underlying assumptions remain under active study. *Implementers are advised*: - Monitor NIST announcements and updates - Follow academic literature on isogeny cryptanalysis - Be prepared to deprecate or update as cryptanalysis evolves 8.4. Implementation Security 8.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. 8.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 8.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 Mott Expires 8 March 2027 [Page 22] Internet-Draft cose-sqisign September 2026 8.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 8.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 * *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 9. IANA Considerations 9.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]. 9.1.1. New COSE Algorithms IANA is requested to register the following entries in the "COSE Algorithms" registry: Mott Expires 8 March 2027 [Page 23] Internet-Draft cose-sqisign September 2026 +==========+=====+===========+==============+======+========+=====+ |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 9.1.2. New COSE Key Types IANA is requested to register the following entry in the "COSE Key Types" registry: +=======+==========+=============+==============+======+==========+ |Name | Value | Description | Capabilities |Change| Ref | | | | | |Cont | | +=======+==========+=============+==============+======+==========+ |SQIsign| *TBD-KTY | SQIsign pub | sign, verify |IETF | THIS-RFC | | | | key | | | | +-------+----------+-------------+--------------+------+----------+ Table 9 * [RFC Editor Note: Please replace TBD-KTY with the next available positive integer assigned by IANA in the COSE Key Types registry.] 9.1.3. New COSE Key Type Parameters IANA is requested to register the following entries in the "COSE Key Type Parameters" registry: Mott Expires 8 March 2027 [Page 24] Internet-Draft cose-sqisign September 2026 +==========+======+=======+======+=============+========+===========+ | Key Type | Name | Label | CBOR | Desc | Change | Reference | | | | | Type | | Cont | | +==========+======+=======+======+=============+========+===========+ | *TBD-KTY | pub | -1 | bstr | SQIsign | IETF | THIS-RFC | | | | | | Public key | | | +----------+------+-------+------+-------------+--------+-----------+ | *TBD-KTY | priv | -2 | bstr | SQIsign | IETF | THIS-RFC | | | | | | Private | | | | | | | | key | | | +----------+------+-------+------+-------------+--------+-----------+ Table 10 * [RFC Editor Note: Please replace TBD-KTY with the numeric value assigned in the COSE Key Types registry above.] 9.1.4. New JWS Algorithms IANA is requested to register the following entries in the "JSON Web Signature and Encryption Algorithms" registry: +============+==========+==========+======+==========+=============+ | 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 9.1.5. New JSON Web Key Types IANA is requested to register the following entry in the "JSON Web Key Types" registry: Mott Expires 8 March 2027 [Page 25] Internet-Draft cose-sqisign September 2026 +===================+====================+=============+===========+ | "kty" Param Value | Key Type Desc | Change Cont | Reference | +===================+====================+=============+===========+ | SQIsign | SQIsign public key | IETF | THIS-RFC | +-------------------+--------------------+-------------+-----------+ Table 12 9.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 10. Acknowledgments The authors would like to thank: * Luca De Feo for reviewing draft-00 and providing valuable feedback. Any remaining errors are solely the responsibility of the authors. * The SQIsign design team for groundbreaking work on isogeny-based signatures. * The W3C Verifiable Credentials and WebAuthn Working Groups, whose specifications this document builds on. * 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. Mott Expires 8 March 2027 [Page 26] Internet-Draft cose-sqisign September 2026 * Aerospace and constrained-telemetry engineers/contractors who suggested the idea for [PQC-Testbed] and in later versions [PQC-Testbed-VC-Bench], together a public testbed for testing, evaluating, and critiquing working WASM and WebGPU-accelerated implementations of all three SQIsign security levels. * Early implementers, those who found bugs in our code and kindly pointed us to them, and others who provided valuable feedback. This work builds upon the template established by [I-D.ietf-cose-falcon] and similar PQC integration efforts. 11. References This document has a normative reference to [RFC9053] and [RFC9054], both currently at Informational status, which is a lower maturity level than required for normative references from a Standards Track document. This is a conscious choice by the authors; see [RFC3967] and [RFC4897] for background on this practice. 11.1. Normative References _Populated automatically from metadata_ 11.2. Informative References _Populated automatically from metadata_ 12. References 12.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, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Mott Expires 8 March 2027 [Page 27] Internet-Draft cose-sqisign September 2026 [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [RFC9054] Schaad, J., "CBOR Object Signing and Encryption (COSE): Hash Algorithms", RFC 9054, DOI 10.17487/RFC9054, August 2022, . 12.2. Informative References [CNSA-2] National Security Agency, "Commercial National Security Algorithm Suite 2.0", May 2025, . [CTAP2-spec] Fido Alliance, "Client to Authenticator Protocol (CTAP) Section 8.1.4 Message and packet structure", February 2018, . [DPP] European Commission, Directorate-General for Internal Market, Industry, "Digital Product Passport (DPP)", September 2026, . [EO14413] US Executive Office of the President, "Executive Order 14413: Ushering in the next frontier of quantum", June 2026, . [G7-CISA] Agence nationale de la sécurité des systèmes d'information, "Preparing for the Post-Quantum Era: A Call to Action", September 2026, . Mott Expires 8 March 2027 [Page 28] Internet-Draft cose-sqisign September 2026 [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, . [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, . [ISO18013-5] ISO, "Personal identification — ISO-compliant Mobile Driving License", August 2026, . [NIST-3rd-round-candidates] NIST, "Nine Candidates Advance to the Third Round of the Additional Digital Signatures for the PQC Standardization Process", May 2026, . [PQC-Testbed] RustyKey®, "PQC RustyKey® Testbed", September 2026, . [PQC-Testbed-VC-Bench] RustyKey®, "PQC RustyKey® Testbed — Verifiable Credentials Tab: SQIsign-L1 WASM and WebGPU-Accelerated JWS Signing Benchmarks", Measured on MacBook Pro, Apple M4 Max, 128GB RAM, macOS 26.6.2, Chrome 152.0.7977.65 (arm64), September 2026, . [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, January 2005, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . Mott Expires 8 March 2027 [Page 29] Internet-Draft cose-sqisign September 2026 [RFC4897] Klensin, J. and S. Hartman, "Handling Normative References to Standards-Track Documents", BCP 97, RFC 4897, DOI 10.17487/RFC4897, June 2007, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [SG-CSA-QSMH] Cyber Security Agency of Singapore (CSA), "Quantum-Safe Migration Handbook and Quantum Readiness Index", September 2026, . [SQIPrime] Max Duparc, Tako Boris Fouotsa, "SQIPrime: A dimension 2 variant of SQISignHD with non-smooth challenge isogenies", May 2024, . [SQIsign2D-East] Kohei Nakagawa, Hiroshi Onuki, "SQIsign2D-East: A New Signature Scheme Using 2-dimensional Isogenies", May 2024, . [SQIsign2D-West] Andrea Basso, Luca De Feo, Pierrick Dartois, Antonin Leroux, Luciano Maino, Giacomo Pope, Damien Robert, Benjamin Wesolowski, "SQIsign2D-West: The Fast, the Small, and the Safer", May 2024, . [SQIsign-Analysis] IACR ePrint Archive, ""SQIsign: Compact Post-Quantum Signatures from Quaternions and Isogenies"", January 2021, . [SQIsign-Spec] SQIsign team, "Algorithm specifications andsupporting documentation Version 2.0.1", July 2025, . [SQIsignHD] Pierrick Dartois, Antonin Leroux, Damien Robert, Benjamin Wesolowski, "SQISignHD: New Dimensions in Cryptography", May 2023, . Mott Expires 8 March 2027 [Page 30] Internet-Draft cose-sqisign September 2026 [UAE-NEP] United Arab Emirates Government, Cyber Security Council, "The National Cyber Security Policy for Artificial Intelligence", July 2026, . [USDOT49CFR172] U.S. Department of Transportation, "Hazmat Transportation Requirements", September 2018, . [WebAuthn-PQC-Signature-size-constraints] University of Quantum Science, "WebAuthn PQC Signature size constraints", September 2026, . Appendix A. Test Vectors Vectors use NIST KAT count = 0 from upstream SQIsign response files (PQCsignKAT_*_SQIsign_lvl*.rsp). The same 32-byte message appears at each security level so implementers can compare keys and signatures. Algorithm identifiers -61, -62, and -63 map to SQIsign-L1, SQIsign- L3, and SQIsign-L5 respectively. 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 8 March 2027 [Page 31] Internet-Draft cose-sqisign September 2026 a44840267471d86eff3447018adb0a6551ee8322ab30010202 Signature (Base64url): hCKGUfJxsPOfLxny6HGPMe0zZayeXLMDr-Zj0M_BHw \ RV2JGwymx- ZT-bomZ3MLt3vv4bGjGChAQoSvj9e6rMAQAB2XS1ymcf9lcI2LRipahK \ FEPum1_tchh2fJ2Fzu0E2wppovbsO-g1s7JiS5oN9og3rQC8rMJ9HsgGpEhAJnRx2G \ 7_NEcBitsKZVHugyKrMAECAg A.1.2. COSE_Sign1 Complete Example cbor-diag 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 A.2.1. Example 1: Simple Message Signing The following test vector exhibits a SQIsign Level III signature over a short message (NIST KAT count = 0; COSE/JOSE algorithm -62). Message (hex): D81C4D8D734FCBFBEADE3D3F8A039FAA2A2C9957E835AD55B22E75BF \ 57BB556AC8 Message (ASCII): MsO=?*,W5U.uWUj Public Key (hex): C32377D6F6D70729884A7F6877EF4791E35D21F751A3E96DE23F9 \ A7A3C01BCD8A5F146DC19E4E2AC63007457F97D8A40EE84AEE7564CA9A7FBE6200FD3E5 \ E55901BFC60EB25C50D39F5C91C96510556BAA22028DF76360841721A601D65E8D0F06 Public Key (Base64url): wyN31vbXBymISn9od-9HkeNdIfdRo-lt4j- aejwBvNil8Ub \ cGeTirGMAdFf5fYpA7oSu51ZMqaf75iAP0-XlWQG_xg6yXFDTn1yRyWUQVWuqIgKN92NghB \ chpgHWXo0PBg Mott Expires 8 March 2027 [Page 32] Internet-Draft cose-sqisign September 2026 Signature (hex): 0868CFBF275B8E7B19BF597D658D62CC913B9B2933E30A297288FB \ E687F6F6B8AC8AF7AA007F191386BB1A203CDDBC2BDB42792D05DA69A4507073D12B0BD \ C47E2B36BC4BA45C68791918281E578F2DC14294504726DCD4CA4C4565FBB89A1280004 \ 8C7B84746A2CBD8247248E248B70B51AE91994957857692A028D8F5CABABFC91E4BF1C5 \ D350219A0189C57DE4A7710D29E0364C79B2188449EC0397359430D594C7B5980CC6755 \ 1933A902D3C11F0FBD6DC39711D3E1F501159EE7FB85CE81B4CE24E1016006567DF4693 \ 15D513E73F69F6301664E6449AF9DCEB4000D15 Signature (Base64url): CGjPvydbjnsZv1l9ZY1izJE7mykz4wopcoj75of29risiveq \ AH8ZE4a7GiA83bwr20J5LQXaaaRQcHPRKwvcR- Kza8S6RcaHkZGCgeV48twUKUUEcm3NTKT \ EVl- 7iaEoAASMe4R0aiy9gkckjiSLcLUa6RmUlXhXaSoCjY9cq6v8keS_HF01AhmgGJxX3k \ p3ENKeA2THmyGIRJ7AOXNZQw1ZTHtZgMxnVRkzqQLTwR8PvW3DlxHT4fUBFZ7n- 4XOgbTOJ \ OEBYAZWffRpMV1RPnP2n2MBZk5kSa-dzrQADRU A.2.2. COSE_Sign1 Complete Example cbor-diag 18( [ h'a10139003d', / protected: {"alg": -62} / {}, / unprotected / h'd81c4d8d734fcbfbeade3d3f8a039faa2a2c995 \ 7e835ad55b22e75bf57bb556ac8', / payload / h'0868cfbf275b8e7b19bf597d658d62cc913b9b2 \ 933e30a297288fbe687f6f6b8ac8af7aa007f191386bb1a203cddbc2bdb42792 \ d05da69a4507073d12b0bdc47e2b36bc4ba45c68791918281e578f2dc1429450 \ 4726dcd4ca4c4565fbb89a12800048c7b84746a2cbd8247248e248b70b51ae91 \ 994957857692a028d8f5cababfc91e4bf1c5d350219a0189c57de4a7710d29e0 \ 364c79b2188449ec0397359430d594c7b5980cc67551933a902d3c11f0fbd6dc \ 39711d3e1f501159ee7fb85ce81b4ce24e1016006567df469315d513e73f69f6 \ 301664e6449af9dceb4000d15', / signature / ] ) A.2.3. JWS Complete Example eyJhbGciOiJTUUlzaWduLUwzIiwidHlwIjoiSldUIn0 . 2BxNjXNPy_vq3j0_igOfqiosmVfoNa1Vsi51v1e7VWrI . CGjPvydbjnsZv1l9ZY1izJE7mykz4wopcoj75of29risiveqAH8ZE4a7GiA83bwr20J5LQXa \ aaRQcHPRKwvcR-Kza8S6RcaHkZGCgeV48twUKUUEcm3NTKTEVl- 7iaEoAASMe4R0aiy9gkck \ jiSLcLUa6RmUlXhXaSoCjY9cq6v8keS_HF01AhmgGJxX3kp3ENKeA2THmyGIRJ7AOXNZQw1Z \ THtZgMxnVRkzqQLTwR8PvW3DlxHT4fUBFZ7n- 4XOgbTOJOEBYAZWffRpMV1RPnP2n2MBZk5k \ Sa-dzrQADRU A.3. SQIsign-L5 Test Vectors Mott Expires 8 March 2027 [Page 33] Internet-Draft cose-sqisign September 2026 A.3.1. Example 1: Simple Message Signing The following test vector exhibits a SQIsign Level V signature over a short message (NIST KAT count = 0; COSE/JOSE algorithm -63). Message (hex): D81C4D8D734FCBFBEADE3D3F8A039FAA2A2C9957E835AD55B22E75BF \ 57BB556AC8 Message (ASCII): MsO=?*,W5U.uWUj Public Key (hex): 86FFA3B0F73D55A64D13C6F89F28D75FD17C5E2368E1D451127C1 \ 6D1A97CDB440E20333A233AD2F8E4D70187C8AE31602049ADE949A87F95E79DA4C456F5 \ D400B2485A96D04708A2F30046812B8D65A3BFBFDED0DD6563462F9E2BCE760CD753CAE \ 8471BEC7049EF28FFEFE859C15DAC49DB959AEE99842D97A380A70DD7330106 Public Key (Base64url): hv- jsPc9VaZNE8b4nyjXX9F8XiNo4dRREnwW0al820QOIDM \ 6IzrS- OTXAYfIrjFgIEmt6Umof5XnnaTEVvXUALJIWpbQRwii8wBGgSuNZaO_v97Q3WVjRi \ - eK852DNdTyuhHG-xwSe8o_-_oWcFdrEnblZrumYQtl6OApw3XMwEG Signature (hex): 6B8EF5D7689A1EA1CFCE9C6F7495E309E9D1D1B03E61CD97088E67 \ 9C4901D0B6B6D38217F4AED6C44949B41F9AF80B43E84D0C91BDB1D00E06957BEBF30A5 \ 8012AD01E52CF7906CE197AD06696F7FCF756908EA980549E7C215D089BDE7117799F62 \ 8817A1B9C8FB7FEBFF7E9D9B776142460CFAAFC97D48A57E09E0DA378401000229CC8E1 \ B94E1F2F8AFDC42066BEACE076E3E70DD01F90C4D01DAC17BEC58743532848D438A87A5 \ 74D9DB940C17236AE3566281E27A99EFE5EE26E05B88A1D610A80B3AF38267D845C7FE3 \ 30F199B43794A9B2E14846924127366B8F6A1F0F24D3C4B54D79DBB61B098BF32D98EA8 \ 819F7BE4A5FFBA29E88B1A996C6CDFD32B048BC2ACFFA28870181447FCC8B6F97B63C47 \ CB013C6F3D84CBD07619A5C355B000911 Signature (Base64url): a47112iaHqHPzpxvdJXjCenR0bA-Yc2XCI5nnEkB0La204IX \ 9K7WxElJtB- a-AtD6E0Mkb2x0A4GlXvr8wpYASrQHlLPeQbOGXrQZpb3_PdWkI6pgFSefCF \ dCJvecRd5n2KIF6G5yPt_6_9-nZt3YUJGDPqvyX1IpX4J4No3hAEAAinMjhuU4fL4r9xCBm \ vqzgduPnDdAfkMTQHawXvsWHQ1MoSNQ4qHpXTZ25QMFyNq41ZigeJ6me_l7ibgW4ih1hCoC \ zrzgmfYRcf- Mw8Zm0N5SpsuFIRpJBJzZrj2ofDyTTxLVNedu2GwmL8y2Y6ogZ975KX_uino \ ixqZbGzf0ysEi8Ks_6KIcBgUR_zItvl7Y8R8sBPG89hMvQdhmlw1WwAJEQ Mott Expires 8 March 2027 [Page 34] Internet-Draft cose-sqisign September 2026 A.3.2. COSE_Sign1 Complete Example cbor-diag 18( [ h'a10139003e', / protected: {"alg": -63} / {}, / unprotected / h'd81c4d8d734fcbfbeade3d3f8a039faa2a2c995 \ 7e835ad55b22e75bf57bb556ac8', / payload / h'6b8ef5d7689a1ea1cfce9c6f7495e309e9d1d1b \ 03e61cd97088e679c4901d0b6b6d38217f4aed6c44949b41f9af80b43e84d0c9 \ 1bdb1d00e06957bebf30a58012ad01e52cf7906ce197ad06696f7fcf756908ea \ 980549e7c215d089bde7117799f628817a1b9c8fb7febff7e9d9b776142460cf \ aafc97d48a57e09e0da378401000229cc8e1b94e1f2f8afdc42066beace076e3 \ e70dd01f90c4d01dac17bec58743532848d438a87a574d9db940c17236ae3566 \ 281e27a99efe5ee26e05b88a1d610a80b3af38267d845c7fe330f199b43794a9 \ b2e14846924127366b8f6a1f0f24d3c4b54d79dbb61b098bf32d98ea8819f7be \ 4a5ffba29e88b1a996c6cdfd32b048bc2acffa28870181447fcc8b6f97b63c47 \ cb013c6f3d84cbd07619a5c355b000911', / signature / ] ) A.3.3. JWS Complete Example eyJhbGciOiJTUUlzaWduLUw1IiwidHlwIjoiSldUIn0 . 2BxNjXNPy_vq3j0_igOfqiosmVfoNa1Vsi51v1e7VWrI . a47112iaHqHPzpxvdJXjCenR0bA-Yc2XCI5nnEkB0La204IX9K7WxElJtB- a-AtD6E0Mkb2x \ 0A4GlXvr8wpYASrQHlLPeQbOGXrQZpb3_PdWkI6pgFSefCFdCJvecRd5n2KIF6G5yPt_6_9- \ nZt3YUJGDPqvyX1IpX4J4No3hAEAAinMjhuU4fL4r9xCBmvqzgduPnDdAfkMTQHawXvsWHQ1 \ MoSNQ4qHpXTZ25QMFyNq41ZigeJ6me_l7ibgW4ih1hCoCzrzgmfYRcf- Mw8Zm0N5SpsuFIRp \ JBJzZrj2ofDyTTxLVNedu2GwmL8y2Y6ogZ975KX_uinoixqZbGzf0ysEi8Ks_6KIcBgUR_zI \ tvl7Y8R8sBPG89hMvQdhmlw1WwAJEQ 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 * *Language*: C * *License*: MIT Mott Expires 8 March 2027 [Page 35] Internet-Draft cose-sqisign September 2026 * *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 Standards Action range (-255 to -1) per RFC 9053 * Sequential for the three parameter sets * Not conflicting with existing registrations (verified against IANA COSE registry) * Consistent with the approach used for other PQC algorithms C.2. Key Type Design The SQIsign key type is intentionally simple: * Only two parameters (pub, priv) following minimalist design Mott Expires 8 March 2027 [Page 36] Internet-Draft cose-sqisign September 2026 * 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-07 * Added Section motivating SQIsign adoption via real-world VC selective-disclosure deployments (linkable: hazmat manifest unlinkable: mDL) constrained to consumer-device-readable QR codes, citing testbed comparison against FN-DSA-512. * In response to some direct feedback, removed "...back-of-envelope extrapolations, vaguely sourced statistics, some without an immutable or obvious authoritative citation than any reader may, or WG will try to follow". * Added international regulatory context to existing sections citing new country-level policy directives to support claims of cross- jurisdictional urgency and avoid single-country framing. D.2. draft-mott-cose-sqisign versions prior to -07 * added section "SQIsign Variants and the Post-SIKE Landscape" * Incorporated technical corrections and feedback from Luca De Feo * Updated the Abstract and Introduction to utilize more neutral, objective language * Removed vendor-specific branding in favor of generic cryptographic terminology * fixed various formatting issues * Added SQIsign-L3 and SQIsign-L5 COSE_Sign1 and JWS test vectors (algorithms -62 and -63) * Documented NIST KAT count = 0 byte values for cross-implementation checks Mott Expires 8 March 2027 [Page 37] Internet-Draft cose-sqisign September 2026 * added informational resource for interactive working code public testbed * updated after SQISign advances to NIST round 3 with 8 other candidates Author's Address Antony R. Mott RustyKey® United States of America Email: antony@rustykey.io Mott Expires 8 March 2027 [Page 38]