A post-quantum signature does not enter an application ecosystem as mathematics alone. On October 7, an individual Internet-Draft was published to define JOSE and COSE registrations and key representations for SQIsign, an isogeny-based signature scheme being evaluated in NIST’s additional post-quantum signature process.
The proposal is not an IETF standard, does not represent working-group consensus, and concerns an algorithm still under evaluation. It should not be read as a deployment recommendation. It is useful planning material because JSON Object Signing and Encryption and CBOR Object Signing and Encryption sit inside identity, API, device, credential, and software-update workflows. Adding one algorithm affects far more than a cryptographic library.
A registry label reaches many systems
JOSE and COSE use identifiers and structured key representations so producers and consumers can agree on algorithms and material. Once a new identifier appears, token issuers, verifiers, gateways, SDKs, key stores, hardware modules, firmware, test tools, policy engines, and logging systems may all encounter it.
A migration-ready inventory should connect:
- the token or message type, business function, producer, verifier, host, device, and owner;
- algorithm identifier, parameter set, key representation, and specification revision;
- key generation, import, storage, use, backup, rotation, recovery, and destruction;
- libraries, SDKs, gateways, identity providers, APIs, firmware, and partners;
- allowed-algorithm policy, negotiation, fallback, and deprecation controls;
- header, payload, transport, database, QR, broker, and device-size limits;
- parser behavior for unknown, malformed, duplicated, or mismatched fields;
- test vectors, interoperability results, validation status, and negative tests; and
- evidence date, confidence, exception, owner, and review trigger.
Without those relationships, a team may know a library compiles with SQIsign while having no idea whether a signed workflow can use it safely.
Producers and verifiers migrate separately
A central issuer can be upgraded quickly, while verifiers may be spread across microservices, customer environments, mobile releases, embedded devices, or partner networks. Verification support can also arrive before signing infrastructure, validation, or key custody is ready.
Readiness should be recorded separately for producers, verifiers, and key-management systems. During transition, some systems may accept old and new signatures. Policy must define which is preferred, when fallback is allowed, how downgrade is detected, and what evidence permits retirement of the older option.
A percentage of upgraded libraries is not a percentage of protected transactions. Coverage should be measured against actual message paths and relying parties.
Key formats and custody are dependencies
A standardized operation still needs a usable lifecycle. Can the organization generate keys with an approved implementation? Can its key-management service represent them? Can a hardware boundary hold and use them? Can recovery preserve the key, parameters, identifier, policy, and audit history?
Teams should distinguish experimental software support from approved custody. If a production signing service must export a private key because its hardware or remote API lacks the operation, the migration may reduce security. Such gaps should become explicit work items rather than hidden exceptions.
Parser and size behavior are security properties
New identifiers and key structures exercise parsers in ways happy-path tests miss. Verifiers must consistently reject unknown or disallowed algorithms, mismatched key types, invalid lengths, malformed encodings, duplicated fields, and truncated signatures. Permissive fallback can undermine the intended protection.
Teams should measure complete artifacts, including headers, key representations, credential material, encoding overhead, transport framing, and claims. Limits may appear in HTTP infrastructure, databases, message brokers, secure elements, firmware manifests, or logging pipelines even when raw operations succeed.
What organizations should do next
First, discover JOSE and COSE by use case: identity tokens, API messages, device attestation, software updates, digital credentials, and signed records.
Second, map each producer, verifier, key store, parser, and transport. Record versions, policies, owners, dependencies, and evidence separately.
Third, create interoperability and negative-test suites covering identifiers, key formats, malformed inputs, downgrade attempts, rotation, recovery, and representative message sizes.
Finally, monitor the SQIsign evaluation and draft history. Do not describe experimental integration as standards-complete or production-approved support.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect algorithms and protocols to applications, devices, hosts, locations, keys, owners, dependencies, evidence, exceptions, and migration work.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
SQIsign remains under evaluation, and the draft can change, expire, or be replaced. Security analysis, parameters, validation, ecosystem support, and performance may evolve. The immediate action is to map the JOSE and COSE dependency graph, not commit production systems to the proposal.
Source
- COSE and JOSE Registrations for SQIsign, revision 09, IETF Datatracker, October 7, 2026.