5.5 KiB
Here’s a clean v0.1 draft for ASL-AUTH, scoped to your system’s offline signing, domain authority, and certificate handling. This layer manages trust, domain ownership, and PER signing, while staying independent of storage or execution specifics.
ASL-AUTH v0.1 – Authentication, Trust, and Domain Authority
1. Purpose
ASL-AUTH specifies domain authority, identity, and offline trust management for ASL-based systems.
Responsibilities:
- Define Domain Authority (DA) manifest
- Manage PER signing
- Support offline root certificates
- Enable foreign-domain trust pinning
- Integrate with host (
ASL-HOST) and store (ASL-STORE(-INDEX))
It does not define:
- Storage encoding (ASL-STORE handles this)
- Artifact semantics (ASL-CORE)
- Execution semantics (PEL/TGK)
2. Core Concepts
| Term | Definition |
|---|---|
| Domain | Logical namespace with a unique ID and authority |
| Domain Authority (DA) | Offline certificate defining domain ownership and signing root |
| PER | PEL Execution Receipt; may be signed to certify artifact provenance |
| Offline Root | Trusted certificate created and signed offline; used to bootstrap trust |
| Foreign-Domain Trust Pin | Local configuration specifying which external domains to trust |
| Policy Hash | Digest summarizing signing, visibility, and federation rules |
3. Domain Authority Manifest
-
Each domain must provide a manifest containing:
- Domain ID (unique)
- Root public key(s)
- Offline root certificate fingerprint(s)
- Allowed publishing targets
- Trust policies
-
Manifest may be signed by offline root or higher-level authority.
-
Minimal format (example JSON):
{
"domain_id": "uuid-xxxx-xxxx",
"roots": ["fingerprint1", "fingerprint2"],
"allowed_publish_targets": ["domain-a", "domain-b"],
"policy_hash": "sha256:..."
}
4. PER Signature Layout
Each signed PER contains:
| Field | Description |
|---|---|
canonical_id |
Unique identifier of PER artifact |
snapshot_id |
Snapshot the PER is bound to |
domain_id |
Signing domain |
signer_id |
Identity of signing authority |
logseq |
Monotonic sequence number for deterministic ordering |
signature |
Cryptographic signature over canonical PER data + policy hash |
policy_hash |
Digest of policy applied during signing |
- Signatures can use Ed25519, ECDSA, or RSA as required by domain policy.
5. Offline Roots & Trust
- Offline roots provide immutable, verifiable trust anchors.
- Recommended minimum: 2 roots per domain (primary + backup)
- Host machine signs DA manifest using offline root before deploying store.
- Offline roots are never exposed to runtime environment.
6. Foreign-Domain Trust Pinning
-
Pin trusted external domains locally to control which published artifacts can be imported.
-
Configuration includes:
- Domain ID
- Allowed snapshot ranges
- Policy hash for verification
-
Enforces read-only, immutable cross-domain references.
7. Certificate & Signing Workflow
-
Generate offline root (offline machine, e.g., Debian VM)
-
Mint domain authority certificates
-
Create policy hash for signing rules
-
Deploy manifest + roots to ASL-HOST
-
At runtime:
- Sign PERs with domain authority key
- Verify foreign-domain pins before accepting imported artifacts
8. Policy Hash Contents
-
Includes hash of:
- Permitted snapshot range
- Allowed publishing domains
- Signing algorithm
- Domain-specific constraints
-
Ensures deterministic, verifiable policy at PER level
9. Integration with Other Layers
| Layer | Role with ASL-AUTH |
|---|---|
| ASL-HOST | Provides identity and secure key storage |
| ASL-STORE(-INDEX) | Provides artifact storage; PER signing hooks |
| PEL / TGK | Generates PERs for deterministic execution |
| Federation Layer | Enforces trust of foreign domains |
10. Security Considerations
- Offline roots must remain offline and physically protected
- Signing keys should be rotated with policy update
- Foreign-domain trust must be explicitly pinned
- Policy hash ensures tamper detection and auditability
11. Summary
ASL-AUTH v0.1:
- Defines domain ownership and trust
- Enables deterministic PER signing
- Supports offline root certificates
- Provides foreign-domain trust pinning
- Integrates cleanly with ASL-HOST, ASL-STORE, and PEL/TGK layers
I can now draft a practical “Rescue Node ASL Deployment” diagram, showing:
- Personal domain
- Common domain / Unity tree
- Foreign-domain trust pins
- How ASL-HOST + ASL-AUTH + ASL-STORE are instantiated This would give a concrete picture for your old laptop recovery workflow.
Do you want me to do that next?