[Rats] draft-aegisfs-secdispatch-rats-01 — RATS EAT Integration in AegisFS Secure File Runtime

[sripad karthik <[e-mail]>]

Dear RATS Chairs and Working Group,

I am writing to introduce a new Internet draft that integrates the
IETF RATS architecture (RFC 9334) as a mandatory attestation step
within a programmable secure file runtime:

Title: AegisFS: AI-Driven Programmable Secure File Runtime and
Intelligent Workspace Architecture with Octal OpCode
Processing and Policy-Driven Language Architecture

Draft: draft-aegisfs-secdispatch-rats-01

URL: https://datatracker.ietf.org/doc/draft-aegisfs-secdispatch-rats/

GitHub: https://github.com/sripad2020/AeGisFS

PyPI: https://pypi.org/project/aegisfs/


== RATS Relevance ==

AegisFS integrates RATS EAT (RFC 9334) as Step 02 of its mandatory
25-step operational lifecycle pipeline (Section 9 and Section 28).
No file operation proceeds without a valid, verifier-issued
attestation result.

The implementation follows the RATS passport model:

Attester:
- Collects platform claims: firmware version, secure boot state,
TPM/TEE presence, OS integrity hash, and runtime environment.
- Signs an EAT (Entity Attestation Token) containing a
verifier-issued nonce (for replay attack prevention).
- Returns the signed EAT to the verifier.

Verifier:
- Issues a fresh nonce per attestation session.
- Validates the EAT signature against the attester's known key.
- Checks nonce freshness to prevent replay.
- Compares platform claims against an endorsement model.
- Produces an Attestation Result with a Trust Level:
UNTRUSTED / BASIC / TRUSTED / VERIFIED_HARDWARE
- Only TRUSTED and VERIFIED_HARDWARE results allow the pipeline
progression. UNTRUSTED results immediately DENY the operation.

Relying Party (AegisFS Runtime):
- Consumes the Attestation Result.
- Enforces policy based on trust level (Section 9).
- Records the attestation result in the audit chain (Section 25).


== Alignment with RFC 9334 ==

RFC 9334 Concept | AegisFS Implementation
  --------------------------|------------------------------------------
Attester                  | aegisfs.rats.RATSAttester
Verifier                  | aegisfs.rats.RATSVerifier
Relying Party             | aegisfs.runtime (Step 02 enforcement)
EAT (Entity Att. Token) | JSON claims dict with ECDSA-P256 signature
Nonce                     | Verifier-issued per-session UUID
Endorsement               | Platform endorsement model dict
Attestation Result | TrustLevel enum + claims dict
Conveyance Channel | In-process (extensible to remote TLS)


== Open Questions for RATS WG ==

1. EAT Serialization: The current implementation uses a JSON.
representation of EAT claims. Should a future revision adopt
CBOR-encoded CWT (RFC 8392) for alignment with the RATS EAT
specification (draft-ietf-rats-eat)?

2. Remote Verifier: The current implementation is an in-process
verifier suitable for prototyping. What is the recommended
conveyance channel model for a production filesystem integration?

3. Hardware Binding: The draft describes TPM/TEE integration in
Section 9. Guidance from the RATS WG on the preferred binding
A mechanism for filesystem-layer attesters would be appreciated.


== Implementation Status ==

A reference Python implementation of the RATS integration is
available in the open-source aegisfs package (v0.2.0):

https://github.com/sripad2020/AeGisFS (see aegisfs/rats.py)
https://pypi.org/project/aegisfs/

pip install "aegisfs[all]"

The RATS engine is covered by the test suite in tests/test_upgrades. py.


I look forward to the working group's feedback on the RATS.
architecture alignment and the open questions above.

Thank you.

Best regards,
Sripad
AegisFS Project
[e-mail]
https://github.com/sripad2020/AeGisFS
https://www.linkedin.com/in/sripadrh/