QUIC Identity Protocol

1.1. Minimal Working Example

The following example demonstrates a complete QUIP flow:¶

Alice (NodeId A) → a.com → b.com → Bob (NodeId B)

1. Identity Setup
   • a.com issues primary attestation binding user@a.com to NodeId A
   • Requires subject signature (proof of possession)

2. Sending a Message
   • Alice signs message with private key A
   • a.com forwards to b.com over QUIC + DANE
   • b.com verifies signature + attestation + policies
   • Bob receives message

3. Accountability
   • If a.com misbehaves, b.com creates signed violation receipt
   • Receipt gossips to federation
   • Automatic throttling after independent witness threshold

1.2. Non-Goals

QUIP does NOT guarantee:¶

• Anonymity (use Tor or similar) — a design choice¶
• Metadata confidentiality — connection patterns are observable¶
• Resistance to global passive adversaries — traffic analysis remains possible¶
• Byzantine consensus — deterministic merge is not Byzantine fault tolerant¶
• Economic Sybil resistance — independent witness definition provides operational heuristic only¶
• Witness collusion resistance — a federation with >=3 colluding witnesses can falsely attest violations; deployments must rely on legal/commercial incentives¶

Note on categorization: The items above mix design choices (anonymity, metadata confidentiality) with explicit security limitations (collusion resistance, Byzantine consensus). All are intentional non-goals of the protocol.¶

3.1. State Definitions

QUIP connections SHALL be in one of the following states:¶

INIT

Initial state before discovery. No messages sent.¶

DISCOVERING

Performing DNS discovery. MAY send DNS queries.¶

CONNECTING

Establishing QUIC connection. MAY send QUIC handshake.¶

HANDSHAKING

Exchanging QUIP handshake. Control stream active; no application streams.¶

SYNCING

Synchronizing gossip state. Accept gossip; MAY defer message delivery.¶

ACTIVE

Normal operation. All streams fully functional.¶

DEGRADED

Operating with reduced capabilities. Rate limits increased; new streams discouraged.¶

REVOKED

Identity or peer revoked. No messages accepted or sent.¶

CLOSED

Connection terminated. No further state transitions.¶

3.2. State Transitions

The following transitions are normative:¶

State transitions not listed above are not permitted and MUST cause a connection error (Section 17.2 code 17: PROTOCOL_VIOLATION).¶

3.3. Protocol Invariants

Implementations MUST enforce:¶

1. Determinism: All state transitions (Section 10) MUST produce identical results across peers¶
2. Signature Coverage: All externally visible objects MUST be signed with domain separation (Section 9.2)¶
3. Identity Continuity: Identity MUST be traceable to a genesis NodeId through a verifiable rotation chain¶
4. Canonical Encoding: All serialized data MUST use QUIP-CBOR (Section 18)¶
5. No Duplicate Keys: CBOR maps MUST NOT contain duplicate keys¶
6. No Indefinite Lengths: Indefinite-length byte strings and text strings are PROHIBITED¶

5.1. NodeId

Every user has a NodeId — an Ed25519 public key (32 bytes). The corresponding private key is never disclosed to any domain or third party. NodeIds are encoded as raw byte strings in CBOR.¶

5.2. Attestations

All attestations are signed CBOR objects.¶

[
  "QUIP-ATTESTATION-SUBJECT-V1",
  type,                    ; string
  subject,                 ; NodeId or address
  issuer,                  ; domain or NodeId
  [notBefore, notAfter]    ; Unix timestamps (seconds)
]

[
  "QUIP-ATTESTATION-ISSUER-V1",
  type,
  subject,
  issuer,
  [notBefore, notAfter],
  subject_signature        ; 64 bytes
]

tagged(65536, [
  "primary_binding",       ; discriminator
  type,
  subject,
  issuer,
  [notBefore, notAfter],
  subject_signature,
  issuer_signature
])

5.3. Key Rotation

tagged(65536, [
  "key_rotation",
  old_NodeId,              ; 32 bytes
  new_NodeId,              ; 32 bytes
  timestamp,               ; Unix milliseconds (int64)
  signature                ; 64 bytes
])

Signature computation:¶

signature = Ed25519_sign(
  old_private_key,
  "QUIP-ROTATION-V1" || QUIP-CBOR([
    "key_rotation",
    old_NodeId,
    new_NodeId,
    timestamp
  ])
)

Rotation validation rules: Receivers MUST reject:¶

• Cyclic chains (NodeId appears twice)¶
• Duplicate NodeIds in the same chain¶
• Chains with non-monotonic timestamps (timestamps must increase)¶
• Multiple successors from the same NodeId unless the previous successor is revoked¶
• Rotations where the old key is already revoked¶
• Chains exceeding maximum depth of 32 (configurable)¶

5.4. Genesis Discovery

The Genesis NodeId is the oldest known NodeId in a rotation chain.¶

First message rule: If a receiver encounters a NodeId with no prior state, and the message is signed by a key that is not clearly the genesis, the sender MUST include the full rotation chain. Failure results in error KEY_ROTATION_CHAIN_MISSING (Section 17.2 code 15).¶

5.5. Identity Trust Modes

The identity_trust_mode bitmask is defined as:¶

Negotiation: The effective trust mode is the bitwise AND of local and remote modes. If the result has no bits set, the connection proceeds with the lowest common mode (SIMPLE) and MUST log a warning.¶

Downgrade behavior: VERIFIED mode MUST NOT downgrade to SIMPLE without explicit operator configuration. Any downgrade MUST be logged.¶

6.1. Server Authentication Modes

6.2. Independent Witness Definition

A witness domain qualifies as independent for violation receipt validation if ALL conditions hold:¶

1. Distinct DNSSEC-signed domain ([RFC4033], [RFC4034], [RFC4035])¶
2. Distinct TLSA record [RFC6698]¶
3. Distinct /24 IPv4 or /48 IPv6 prefix¶

Additional weighting (SHOULD): Implementations SHOULD also consider distinct ASN (Autonomous System Number), distinct DNSSEC KSK (Key Signing Key), historical trust scoring based on past witness accuracy, and observed federation longevity (minimum 30 days active).¶

6.3. DNS Downgrade Protection

After TLS handshake completion, the client MUST verify that the server's presented certificate and DANE TLSA record (if applicable) are consistent with the TXT capabilities advertisement from DNS. Inconsistencies MUST be logged and, in STRICT mode, cause connection termination.¶

6.4. Handshake Transcript Binding

The QUIP handshake MUST be cryptographically bound to the QUIC TLS session using the TLS exporter interface [RFC8446], Section 7.5.¶

Transcript canonicalization:¶

The client and server handshake payloads are embedded as CBOR byte strings containing the exact transmitted bytes:¶

[
  h'<raw client handshake bytes>',
  h'<raw server handshake bytes>'
]

Sequence of operations:¶

1. TLS handshake completes (both peers have established session keys)¶
2. QUIP handshake bytes are transmitted on stream 0 (client first, then server)¶
3. Both peers buffer the exact bytes they send and receive (no re-encoding)¶
4. After both handshake messages have been exchanged, each peer computes:¶

binding = TLS-Exporter("EXPORTER-QUIP-BINDING",
    SHA-256(QUIP-CBOR(handshake_array)), 32)

5. Because both peers use the same TLS session and the same canonicalized handshake array, they derive identical binding values locally¶
6. The binding is used as a local consistency check: each peer can verify that the handshake parameters it is using are consistent with the binding it computed¶
7. No binding value is ever transmitted¶

6.5. Verified Mode Governance

Governance and policy requirements for VERIFIED mode (trust anchor authorization, provider certification criteria, dispute resolution, and antitrust/competition safeguards) are deployment-specific and outside the scope of this document. Implementations in VERIFIED mode MUST rely on local policy to define acceptable trust anchors and certification authorities.¶

7.1. Trust Anchor Format

Trust anchors are distributed as signed CBOR objects:¶

tagged(65536, [
  "trust_anchor",
  anchor_id,               ; string (e.g., "quip-root-v1")
  public_key,              ; 32 bytes (Ed25519)
  valid_from,              ; Unix timestamp (seconds)
  valid_until,             ; Unix timestamp (seconds)
  distribution_point,      ; string URI
  signature                ; 64 bytes (self-signed or cross-signed)
])

7.2. Trust Anchor Distribution

Trust anchors are distributed via:¶

1. Hardcoded — Implementations MAY ship with a set of trusted roots¶
2. DNS-based — _quip._trust.root.domain TXT records containing anchor hashes¶
3. Transparency log — Optional certificate transparency-style log¶

7.3. Attestation Provider Certificate

tagged(65536, [
  "attestation_provider",
  provider_NodeId,         ; 32 bytes
  domain,                  ; string
  issuer,                  ; NodeId or anchor_id of issuer
  issued_at,               ; Unix timestamp (seconds)
  expires_at,              ; Unix timestamp (seconds, max 90 days)
  capabilities,            ; array of strings
  signature                ; 64 bytes (by issuer)
])

7.4. Certificate Path Validation

When receiving a provider certificate chain, peers MUST perform the following validation:¶

Path building order:¶

1. Start from the end-entity (provider) certificate¶
2. Chain to issuer using issuer field (NodeId or anchor_id)¶
3. Continue until reaching a known trust anchor¶
4. Maximum chain depth: 8¶

Trust anchor matching: Trust anchors are identified by anchor_id string. Implementations MUST support exact string matching. Wildcard matching is NOT permitted.¶

Signature validation: All signatures MUST use Ed25519 [RFC8032]. Future versions may negotiate additional algorithms.¶

Expiry precedence: Certificates with expires_at in the past MUST be rejected. Trust anchors with valid_until in the past SHOULD be rejected (grace window of 24 hours permitted for rollover).¶

Rollover handling: Trust anchors SHOULD have overlapping validity windows during rollover. During overlap, either anchor is considered valid. After old anchor expires, it MUST NOT be accepted.¶

Cross-signing: Cross-signed certificates are permitted if they chain to a trust anchor. Maximum chain depth applies to the merged path.¶

Revocation check: Before accepting a certificate, check revocation status per Section 7.5. Revoked certificates MUST be rejected regardless of validity period.¶

7.5. Provider Revocation Freshness

Peers MUST enforce freshness limits on provider revocation lists:¶

7.6. DNS Trust Anchor Bootstrapping

DNS-distributed trust anchors are advisory until chained to an existing trusted anchor or implementation trust store. Implementations MUST validate the DNSSEC chain for any DNS-discovered anchor. The first anchor in a deployment MAY be installed out-of-band (e.g., via package management, configuration file, or hardcoding). Once an anchor is trusted, it may be used to validate subsequent anchor updates.¶

8.1. Connection Establishment

QUIC connection with ALPN "quip". The first client-initiated bidirectional stream opened after QUIC connection establishment (stream ID 0) is designated the QUIP Control Stream. The second client-initiated bidirectional stream (stream ID 4) is designated the QUIP Gossip Stream.¶

All control messages (errors, rate advisories) are sent as CBOR arrays on the Control Stream.¶

Handshake sequencing: No application streams (streams other than the Control and Gossip streams) SHALL be processed until the QUIP handshake completes and transcript binding verification succeeds. The Control Stream and Gossip Stream MAY be used during handshake.¶

Phase 0: DNS Discovery¶

Query _quip._udp.domain.example SRV and TXT:¶

_quip._udp.domain.example. TXT
    "v=2; profiles=basic,documents; trust=compat; quic=:443"

Phase 1: QUIP Handshake (Control Stream)¶

Client sends:¶

[
  2,                    ; version
  0b111,                ; profiles bitmask
  "compat",             ; server_trust_mode
  0b01,                 ; identity_trust_mode (VERIFIED)
  {                     ; capabilities
    0: true,            ; datagram_support
    1: ["opus", "vp9"], ; media_codecs
    2: 4096             ; max_message_size
  },
  ["revocations/#"],    ; subscriptions
  {                     ; vector_clocks
    "revocation_list": {"a.com": 42}
  }
]

Server responds with identical structure.¶

Both peers compute active_profiles = local.profiles & remote.profiles. If zero, send error (Section 9.3) and close.¶

8.2. Wire Format

+------------------+----------------------------------+
| varint length    | QUIP-CBOR object                 |
+------------------+----------------------------------+

The CBOR object MUST be a single complete top-level item with no trailing bytes.¶

8.3. Stream Semantics

8.4. Bootstrap Discovery

Priority order:¶

1. DNS SRV + TXT (MUST)¶
2. QUIC Well-Known: ["WELL_KNOWN", "/peer"] on Control Stream (MUST)¶
3. Cached endpoints (SHOULD)¶
4. HTTPS fallback (OPTIONAL, DEPRECATED)¶

The full bootstrap handshake (GOSSIP_BOOTSTRAP exchange) is defined in Section 10.¶

9.1. Envelope Structure

The signed payload is a CBOR array, not a map:¶

[
  "message",
  payload,              ; application CBOR
  NodeId,               ; 32 bytes
  sequence,             ; 64-bit uint (max 2^62-1)
  timestamp,            ; 64-bit Unix milliseconds
  message_id            ; 32 bytes (SHA-256)
]

The wire representation is:¶

tagged(65536, [
  "message",
  payload,
  NodeId,
  sequence,
  timestamp,
  message_id,
  signature            ; 64 bytes
])

9.2. Signature Computation (Domain Separation)

All signatures in QUIP use standard Ed25519 [RFC8032] without pre-hashing, with explicit domain separation strings prepended to the message.¶

signature = Ed25519_sign(
  private_key,
  domain_separator || QUIP-CBOR(signed_payload_array)
)

9.3. Error Messages

Errors are sent as CBOR arrays on the Control Stream:¶

["ERROR", error_code, message_id, error_text]

Where error_code is a uint (Section 17.2), message_id is 32 bytes (may be null for handshake errors), and error_text is a human-readable string.¶

9.4. Rate Advisory Messages

Rate advisories are sent as CBOR arrays on the Control Stream:¶

["RATE_ADVISORY", limit_type, current_rate, allowed_rate]

The limit_type field is a string matching the resource type being rate-limited (e.g., "message", "gossip", "datagram").¶

9.5. Sequence Validation Rules

Sequence numbers are scoped to (genesis_NodeId, discriminator) where discriminator is the string from the signed payload array (e.g., "message", "document", "gossip").¶

Rules:¶

• Sequence numbers MUST be strictly increasing per scope¶
• Gaps MAY be buffered up to a limit of 256 missing entries¶
• Out-of-order delivery is permitted, but sequence validation applies on receive¶
• Duplicates with the same message_id are rejected¶
• Retransmissions MUST reuse the identical message_id¶

9.6. Message ID Construction

message_id = SHA-256("QUIP-MESSAGE-ID-V1" || QUIP-CBOR([
  genesis_NodeId,
  NodeId,
  discriminator,
  sequence,
  timestamp
]))

9.7. Timestamp Validation

Timestamps are advisory only. Sequence numbers dominate ordering.¶

• Soft window (MUST accept): ±300,000 ms (5 minutes)¶
• Hard window (MAY accept): ±3,600,000 ms (1 hour) with warning¶
• Outside hard window: MUST reject¶

Implementations MUST NOT use timestamps for causality determination.¶

10.1. Vector Clocks

Map from issuer → counter.¶

Issuer canonical forms: Domain: text string (major type 3). NodeId: byte string, 32 bytes (major type 2). Mixed representations for the same issuer are PROHIBITED.¶

Maximum vector clock entries: 1024. Entries beyond this limit SHOULD be pruned (oldest issuers first).¶

10.2. Gossip Message Format

The signed payload is a CBOR array:¶

[
  "gossip",
  resource_type,         ; "attestations" | "revocations" | "violations"
  resource_id,           ; string or bytes
  vector_clock,          ; map {issuer: counter}
  payload,               ; signed resource object
  ttl,                   ; uint (3-7)
  sender_NodeId          ; 32 bytes
]

The wire representation is:¶

tagged(65536, [
  "gossip",
  resource_type,
  resource_id,
  vector_clock,
  payload,
  ttl,
  sender_NodeId,
  signature
])

10.3. Resource Authority Model

10.4. Anti-Entropy Protocol

SYNC request:¶

["SYNC", resource_type, resource_id, their_clock]

SYNC response:¶

{
  "clock": merged_clock,
  "deltas": [payload1, payload2, ...],
  "next_token": continuation_token,  ; optional
  "complete": true|false
}

10.5. Conflict Resolution

When updates are concurrent (neither vector clock dominates the other), the deterministic merge order is:¶

1. Causal check: If one clock has all issuers with counters >= the other clock, that clock wins (causal dominance)¶
2. If concurrent: Lexicographic comparison of sorted (issuer, counter) tuples as QUIP-CBOR¶
3. If equal: Higher NodeId (bytewise) of the signer of the update payload¶
4. If equal: Smaller SHA-256 of the update payload¶

10.6. Gossip TTL

• Default: 5¶
• Range: 3-7¶
• Decrement before re-gossip; TTL=0 not re-gossiped¶

11.1. Sequence Numbers

Every reliable message carries a sequence number per (sender, resource_type).¶

• 64-bit unsigned integer¶
• Maximum permitted value: 2^62 - 1 (approximately 4.6e18)¶
• Implementations MUST trigger a key rotation warning when the sequence number reaches 2^61 (50% of max)¶
• If a sender approaches 2^62 - 1, they MUST rotate their NodeId (Section 5.3) before the next increment¶
• Overflow beyond 2^62 - 1 is a provable violation (Section 17.2 code 16)¶

11.2. Violation Receipts

When a peer detects a violation (e.g., sequence gap, rate exceedance), it creates a signed violation receipt and gossips it.¶

Validation requirement: A violation receipt is considered valid only if corroborated by at least 3 independent witnesses as defined in Section 6.2. If fewer than 3 qualified domains exist in the federation, the threshold equals the number of domains.¶

Receipt signature:¶

signature = Ed25519_sign(
  private_key,
  "QUIP-VIOLATION-V1" || QUIP-CBOR(violation_data)
)

15.1. Threat Model Summary

QUIP defends against: domain impersonation (via subject signatures), replay attacks (via message_id cache), BGP hijacking (via DANE binding), DNS poisoning (via DNSSEC), split-brain/fork (via deterministic merge), gossip amplification (via TTL and rate limits), Sybil witnesses (via independent witness definition — raises operational cost of Sybil-style witness fabrication).¶

QUIP does NOT defend against: anonymity attacks, metadata confidentiality, global passive adversaries, Byzantine consensus, economic Sybil resistance, or witness collusion (relies on legal/commercial incentives).¶

15.2. Replay Attacks

Domain separation (Section 9.2) prevents cross-context replay. The message_id cache provides per-message protection.¶

15.3. Downgrade Attacks

DNS downgrade protection (Section 6.3) and handshake transcript binding (Section 6.4) prevent silent capability stripping. STRICT mode refuses downgrades.¶

15.4. Canonicalization Attacks

QUIP-CBOR (Section 18) eliminates encoding ambiguity. Duplicate keys and indefinite lengths are rejected. QUIP-CBOR is defined as an application profile of [RFC8949].¶

17.1. ALPN Protocol ID Registration

IANA is requested to register the following ALPN protocol ID:¶

Protocol:

QUIP¶

ID:

"quip"¶

Reference:

This document¶

17.2. QUIP Error Codes Registry

IANA is requested to create a registry titled "QUIP Error Codes" with the following initial contents:¶

Registration policy: IETF Review for codes 0-127. Codes 128-255 are reserved for application-specific extensions. Error code 0 is reserved and MUST NOT be used.¶

17.3. CBOR Tag 65536 Registration

IANA is requested to register the following CBOR tag in the CBOR Tags registry [RFC9277]:¶

Tag Number:

65536¶

Data Item:

CBOR array¶

Semantic:

Container for QUIP protocol messages. The first element of the array is a string discriminator indicating the message type (e.g., "message", "gossip", "document", "key_rotation", "primary_binding").¶

Point of Contact:

Junior Joseph Mututi <jjmututicloud@gmail.com>¶

Fragment Identifier:

N/A¶

Reference:

This document¶

18.1. Encoding Rules

Prohibited constructs: duplicate map keys, indefinite-length items, floating point values, non-minimal UTF-8, CBOR simple values other than false/true/null.¶

19.1. State Persistence

Implementations MUST persist vector clocks for all tracked resources, sequence number state per (genesis_NodeId, discriminator), revocation state for known peers, and peer relationship state. Replay cache persistence is OPTIONAL.¶

19.2. Sequence State Loss Recovery

If sequence state is lost after restart, the implementation MUST log a critical error, rotate the NodeId (Section 5.3) to start a new sequence space, and NOT reuse prior sequence numbers.¶