SPECIFICATION · AXIA.TRUST.V1

Cryptographic Profile

Normative cryptographic primitives and operational rules for the Axia trust infrastructure.

1. Conventions

The keywords MUST, MUST NOT, SHOULD, SHOULD NOT and MAY in this document are to be interpreted as described in RFC 2119.

2. Hash Function

2.1 Algorithm

Implementations MUST use SHA-256 (FIPS 180-4) for all content addressing. Hashes MUST be encoded as 64-character lowercase hexadecimal.

2.2 Locality

Content hashing MUST be performed client-side. Raw bytes MUST NOT be transmitted to Axia infrastructure.

3. Digital Signatures

3.1 Algorithm

Signatures MUST use Ed25519 as defined in RFC 8032. Signatures MUST be encoded as base64url without padding.

3.2 Key identifiers

Each signing key MUST have a stable key_id and MUST be published at /.well-known/axia-keys. Rotated keys SHOULD remain published as historical for as long as their signed entries exist.

3.3 Canonicalization

The signed payload MUST be the lowercase hexadecimal SHA-256 digest of the content. Implementations MUST NOT sign metadata that is not byte-stable.

4. Merkle Transparency Log

4.1 Construction

The transparency log MUST be an append-only Merkle tree following the architectural pattern of RFC 6962. Leaves MUST be the SHA-256 hash of the canonical signed entry.

4.2 Checkpoints

Signed checkpoints MUST be produced at most every 50 entries or every 10 minutes (whichever comes first). Checkpoints MUST include tree_size, root_hash, signed_at and an Ed25519 signature.

4.3 Inclusion proofs

Implementations MUST expose minimal inclusion proofs at /log/proof/:hash. Verifiers SHOULD independently recompute the audit path against a known checkpoint.

5. Timestamping

Implementations MAY attach RFC 3161 timestamp tokens or eIDAS-qualified timestamps to signed entries. When present, timestamps MUST be preserved for the life of the entry.

6. Key Rotation & Revocation

Active keys MUST be discoverable at /.well-known/axia-keys. Compromised keys MUST be marked inactive and an identity_revoked event MUST be appended. Existing signed entries remain cryptographically verifiable but inherit revoked status from the revocation point onward.