Revocation

Revocation allows you to invalidate warrants before their natural expiration. This is essential for handling compromised agents, changed permissions, or emergency access removal.

Enforcement Protocol→

Why Revocation?

Even with short-lived warrants, you may need to revoke access immediately:

An agent is compromised
An employee leaves the company
A permission was granted in error
A security incident requires lockdown

How Revocation Works

Tenuo uses a Signed Revocation List (SRL) approach:

┌─────────────┐      ┌──────────────┐      ┌─────────────┐
│   Admin     │      │ Tenuo Cloud  │      │ Authorizer  │
└──────┬──────┘      └──────┬───────┘      └──────┬──────┘
       │                    │                     │
       │ Add Revocation     │                     │
       │───────────────────>│                     │
       │                    │                     │
       │ Regenerate SRL     │                     │
       │───────────────────>│                     │
       │                    │                     │
       │                    │   Fetch SRL         │
       │                    │<────────────────────│
       │                    │                     │
       │                    │   Signed List       │
       │                    │────────────────────>│
       │                    │                     │
       │                    │                     │  Check warrant
       │                    │                     │  against list

Admin creates a revocation for a warrant ID
Admin regenerates the SRL
Authorizers fetch the new SRL
Authorizers check warrants against the list

The Signed Revocation List (SRL)

The SRL is a cryptographically signed document containing:

{
  "version": 42,
  "issued_at": "2024-01-15T10:00:00Z",
  "expires_at": "2024-01-15T11:00:00Z",
  "revoked_ids": [
    "tnu_wrt_abc123",
    "tnu_wrt_def456",
    "tnu_wrt_ghi789"
  ],
  "signature": "base64-encoded-ed25519-signature"
}

Why Signed?

The signature ensures:

The SRL came from Tenuo Cloud (not an attacker)
The SRL hasn't been modified
Authorizers can trust the revocation data

SRL Versioning

Each SRL has a version number. Authorizers only accept SRLs with a version greater than or equal to their current version, preventing replay attacks with old lists.

Revocation Scope

Individual Warrant

Revoke a specific warrant by its ID. Only this warrant is invalid.

Transitive Revocation

Revoking a parent warrant revokes all children:

tnu_wrt_parent (revoked)
    │
    ├── tnu_wrt_child1 ← Invalid
    │
    └── tnu_wrt_child2 ← Invalid
            │
            └── tnu_wrt_grandchild ← Invalid

Key Revocation

Revoking an issuer key revokes all warrants signed by that key.

Key Management→

Authorizer Behavior

Authorizers check the SRL before allowing any action:

def authorize(warrant, action):
    # 1. Check SRL
    if warrant.id in current_srl.revoked_ids:
        return DENIED("warrant revoked")
    
    # 2. Check expiration
    if warrant.expires_at < now():
        return DENIED("warrant expired")
    
    # 3. Verify signature
    if not verify(warrant):
        return DENIED("invalid signature")
    
    # 4. Check action is allowed
    if action not in warrant.actions:
        return DENIED("action not permitted")
    
    return ALLOWED()

SRL Caching

Authorizers cache the SRL to avoid fetching it on every request:

Setting	Typical Value
Cache TTL	5-60 seconds
Refresh interval	30 seconds
Max staleness	5 minutes

There may be a short delay (seconds to minutes) between regenerating the SRL and all authorizers enforcing the revocation.

Best Practices

Use short expiration times

Short-lived warrants (minutes to hours) reduce the need for revocation.

Monitor SRL fetch errors

If authorizers can't fetch the SRL, they may fail open or closed depending on configuration.

Document revocation reasons

Always provide clear reasons for audit trail.

Test revocation flow

Regularly test that revocations actually take effect in your authorizers.