Skip to content

UniKey RFC 4001

Download UniKey RFC 4001: Operational Compliance Checklist

Title: UniKey Operational Compliance Checklist

Status: Stable

Category: Standards Track

Version: 1.0

Date: February 2026

Authors: Swoop Engineering Team

Previously published as: RFC-005 (Swoop Series)

Canonical URL: /rfc-4001

 


Abstract

 

This document provides a normative framework for evaluating the compliance of UniKey implementations. It serves as the primary checklist for acquirers, auditors, and ecosystem partners to ensure that a given system adheres to the core security invariants of the UniKey protocol suite. A system is deemed “UniKey Compliant” only if it satisfies all requirements across Trust Packet construction, DNS discovery, hardened validation, and delegation enforcement.



1. Introduction

To maintain a global decentralized trust fabric, all participants—Issuers, Delegates, and Verifiers—must operate under a unified set of compliance rules. This document consolidates the normative requirements from the 1000, 2000, and 3000 series into a single, auditable checklist.

 

2. Trust Packet Compliance (Ref: RFC 2001)

The core cryptographic container must be evaluated against the following:

  • [ ] Canonicalization: Does the implementation match the unikey-json-v1 lexicographical ordering?
  • [ ] Deterministic Verification: Can the same packet be verified with identical results across different environments?
  • [ ] Replay Protection: Are nonce uniqueness and issued_at/expires_at windows strictly enforced?
  • [ ] Fail-Closed Behavior: Does the system reject the transaction if any single signature or claim is ambiguous?

 

3. Key Discovery & DKIM Profile (Ref: RFC 3002)


Public key discovery must adhere to the hardened DKIM profile:

  • [ ] Pathing: Are keys discovered exclusively via the <selector>._domainkey DNS path?
  • [ ] Tag Filtering: Does the verifier reject records containing disallowed tags (e.g., g=, h=)?
  • [ ] Cryptographic Floor: Are RSA keys < 2048-bit or ECC keys below P-256 automatically rejected?
  • [ ] Revocation: Does the system immediately invalidate trust when a DNS record is nullified (p=)?

 

4. DNS Hardening Requirements (Ref: RFC 3001)


The discovery process must resist network-layer attacks:

  • [ ] N-Resolver Consensus: Does the verifier query $\geq 3$ independent resolvers and require bitwise equality?
  • [ ] TTL Monitoring: Are sudden drops in TTL flagged as suspicious events?
  • [ ] DNSSEC Integration: Is DNSSEC treated as an additive confidence signal rather than a total replacement for multi-path validation?

 

5. Delegation Enforcement (Ref: RFC 1200)


Chained authority must be strictly “caged”:

  • [ ] Hash Chaining: Does every delegated packet correctly reference the parent’s TPH?
  • [ ] Monotonic Scope: Is it mathematically proven that the Delegate’s scope is equal to or smaller than the Issuer’s?
  • [ ] Chain Validity: Does an expired or revoked root packet invalidate all downstream actions?

 

6. Operational & Audit Controls

  • [ ] Incident Response: Is there a documented procedure for key rotation in the event of a suspected TEE/Hardware compromise?
  • [ ] Decision Logging: Are verification failures logged with specific UniKey error codes (e.g., TP-002, DS-001)?
  • [ ] Reproducibility: Can a third-party auditor reproduce a verification decision using only the Trust Packet and historical DNS logs?

 

7. Attestation and Certification


Implementations claiming compliance MAY issue a signed attestation statement:

“This system conforms to the UniKey RFC 4001 Operational Compliance Checklist covering Trust Packet, DKIM/DNS Profile, and Delegation specifications.”

 

8. Non-Compliance and Trust Revocation

The UniKey protocol suite is an “All-or-Nothing” framework. Failure to satisfy any unchecked item in this document constitutes a Trust Violation. Verifiers MUST NOT grant “Partial Trust” to non-compliant implementations.