Outside: Trust Model
SunLionet uses offline distribution of signed bundles rather than a central fetch API. This shifts trust to explicit key management and fail-closed verification.
Actors
- Outside operator: curates seed profiles and produces bundles
- Inside device: imports bundles and applies them to the local secure store
- Transport: any channel capable of delivering text or a file (messengers, removable media, QR, local sharing)
Trust Anchors
Inside must be configured with a set of trusted Ed25519 signer public keys. A bundle is accepted only if:
- its signature verifies under one of the trusted public keys
- its header and payload validations pass
No network lookup or “key server” is required.
What the Signature Means
The Ed25519 signature authenticates:
- the entire bundle header (except the signature field itself)
- the ciphertext bytes (encrypted payload, or plaintext payload if
cipher="none")
This provides integrity and origin authentication. It does not provide confidentiality unless the payload is encrypted for a recipient.
Recipient Encryption
If cipher="age-x25519", the payload is encrypted for a specific age X25519 recipient public key.
Inside must possess the matching age identity (private key) to decrypt the payload. Verification checks that:
recipient_key_id matches the identity’s recipient fingerprint- decryption succeeds
Fail-Closed Rules
Bundles are rejected if any trust-critical condition fails:
- invalid signature
- unknown cipher
- missing or inconsistent issuer metadata
- expired bundle
- malformed or non-canonical payload
- invalid profiles or missing required templates
- duplicates (IDs or endpoints) inside the payload
Transport Is Not Trusted
The delivery channel is assumed to be:
- observable
- delayable
- modifiable
- sometimes unavailable
Therefore:
- integrity is provided by the signature
- confidentiality (if required) is provided by age encryption
- replay value is reduced by short bundle expirations