AEON GP Encryption v1

Convention identifier: aeon.gp.encryption.v1

Status

Draft interoperability convention

1. Purpose

aeon.gp.encryption.v1 defines a minimal structure for representing encrypted AEON payloads inside aeon:envelope.

It allows AEON documents to carry confidential data while preserving the deterministic document model.

This convention is designed to work with:

• aeon.gp.security.v1
• aeon.gp.integrity.v1
• aeon.gp.signature.v1

2. Scope

aeon.gp.encryption.v1 defines:

• where encrypted content lives
• how ciphertext is represented
• how recipient keys are identified
• minimal encryption metadata

It does not define:

• key exchange protocols
• trust models
• certificate infrastructure
• algorithm approval policies

3. Encryption Model

Encryption replaces the plaintext body with ciphertext while preserving the AEON document structure.

The envelope carries:

• encryption algorithm
• recipient key identifier
• encrypted payload bytes

The decrypted payload must resolve to a valid AEON document body.

4. Envelope Placement

Encryption is declared inside the envelope:

Only one encryption section is allowed per envelope unless another convention explicitly defines multiple encryption layers.

5. Encryption Entry Structure

Required fields

Minimal form:

6. Field Definitions

6.1 alg

Encryption algorithm identifier.

Example:

Other possible values:

• aes-256-gcm
• chacha20-poly1305

The convention does not restrict allowed algorithms.

Profiles may.

6.2 kid

Recipient key identifier.

Example:

This identifies the key used to decrypt the ciphertext.

The identifier format is intentionally flexible.

Possible examples:

6.3 ciphertext

Encrypted payload.

Example:

This field contains the encrypted AEON payload bytes.

The exact encoding is determined by AEON binary literal rules.

7. Optional Fields

Optional metadata may appear if required by the encryption algorithm.

Example:

These fields are algorithm dependent.

8. Encryption Scope

Encryption covers the document body.

The envelope itself remains visible so processors know how to decrypt the document.

Conceptually:

9. Combined Signing and Encryption

Documents may combine encryption with signatures.

Example workflow:

1. encrypt payload
2. compute integrity hash
3. sign hash

Example:

This allows recipients to verify authenticity after decryption.

10. Verification / Decryption Flow

A processor decrypting a document should:

1. parse AEON document
2. locate aeon:envelope.encryption
3. resolve recipient key using kid
4. decrypt ciphertext
5. reconstruct the AEON body
6. optionally verify integrity and signatures

11. Failure Conditions

Decryption must fail if:

• alg is missing
• kid cannot be resolved
• ciphertext cannot be decrypted
• authentication tag fails
• payload cannot be parsed as AEON

Decryption failure is not a syntax error; it is a processor-level security failure.

12. Example Encrypted Document

In this case the body is encrypted and only recoverable after decryption.

13. Relationship to Other Conventions

aeon.gp.encryption.v1 works with:

• aeon.gp.security.v1
• aeon.gp.integrity.v1
• aeon.gp.signature.v1

Encryption may appear alongside integrity and signatures.

14. One-Line Definition

aeon.gp.encryption.v1 defines a minimal encryption envelope for AEON documents in which the document body is represented as ciphertext inside aeon:envelope.encryption.

15. Minimal Encryption Envelope