Is your feature request related to a problem? Please describe.

Yes, the problem is the lack of a standardized, interoperable format for defining and distributing reference values (golden measurements) for remote attestation in cocos-ai.

Currently, attestation policies are often defined using ad-hoc JSON configurations (e.g., attestation_policy.json) or simple lists of PCR values.

• Fragility: Managing raw hash values manually is error-prone.
• Interoperability: There is no standard way to consume endorsements from hardware manufacturers (e.g., Intel, AMD) or software vendors in a uniform way.
• Scalability: As the number of trusted components grows, maintaining a "known good" list becomes complex without a structured manifest format like CoRIM.

Describe the feature you are requesting, as well as the possible use case(s) for it.

I request the integration of CoRIM (Concise Reference Integrity Manifest), an IETF standard (draft), into cocos-ai. CoRIM provides a CBOR-based format for representing reference values and endorsements.

Core Features:

1. CoRIM Support: Ability to parse and validate signed CoRIM manifests.
2. Schema Implementation: Go structs for Corim, Comid (Concise Module Identifier), ReferenceValue, and Endorsement.
3. Policy Engine Integration: Update the Verifier interface to accept CoRIM manifests as the "Source of Truth" for determining if an attestation report is valid.

Use Cases:

• Vendor Endorsements: Automatically ingest golden measurements for CPU firmware (e.g., SEV-SNP TCB versions) published by AMD in a standard format.
• Software Supply Chain: The build pipeline generates a CoRIM manifest containing the measurements of the cocos-ai agent and strict policies. The Manager consumes this manifest to verify deployed instances.
• Cloud Independence: Run confidential workloads on any cloud, using the same CoRIM policy to verify the environment, regardless of the cloud provider's proprietary policy formats.

Indicate the importance of this feature to you.

Must-have

Anything else?

How it fits with EAT (Entity Attestation Token)
EAT and CoRIM are complementary parts of the attestation architecture. They do not clash; they work together as Evidence and Reference Values respectively.

• EAT (Evidence): The "claim" from the TEE. It says "I am running firmware version X". You have already implemented this in pkg/attestation/eat.
• CoRIM (Reference Value): The "rule" from the supply chain/vendor. It says "Trust any TEE running firmware version X".

Verification Flow:

graph LR
    subgraph "Attester (The VM/Enclave)"
      EAT[EAT Token] -- "Evidence: 'My measurement is ABC'" --> Verifier
    end

    subgraph "Supply Chain (Developer/Vendor)"
      CoRIM[CoRIM Manifest] -- "Reference: 'Trusted measurement is ABC'" --> Verifier
    end

    subgraph "Cocos-AI Verifier"
      Verifier[Verification Logic]
      EAT --> Verifier
      CoRIM --> Verifier
      Verifier -- "Match?" --> Result{Trusted?}
    end

Implementation Plan Overview

This feature will incrementally replace the existing ad-hoc policy mechanisms.

1. Data Structures (pkg/attestation/corim)

We need to define the Go structures that map to the CoRIM CBOR schema.

package corim

import "github.com/google/uuid"

// Corim represents the high-level manifest container.
type Corim struct {
	ID           []byte   `cbor:"0,keyasint" json:"id"`
	Tags         []byte   `cbor:"1,keyasint,omitempty" json:"tags,omitempty"`
	DependentRIM []byte   `cbor:"2,keyasint,omitempty" json:"dependent_rim,omitempty"`
	Profile      []byte   `cbor:"3,keyasint,omitempty" json:"profile,omitempty"`
	RimValidity  Validity `cbor:"4,keyasint,omitempty" json:"rim_validity,omitempty"`
	Entities     []Entity `cbor:"5,keyasint,omitempty" json:"entities,omitempty"`
	Measurements []byte   `cbor:"6,keyasint,omitempty" json:"measurements,omitempty"` // payload: CoMID
}

// Comid (Concise Module Identifier) holds the actual reference values.
type Comid struct {
	Language  string      `cbor:"0,keyasint,omitempty" json:"language,omitempty"`
	TagID     []byte      `cbor:"1,keyasint" json:"tag_id"` // UUID
	Entities  []Entity    `cbor:"2,keyasint,omitempty" json:"entities,omitempty"`
	Triples   ReferenceTriples `cbor:"3,keyasint,omitempty" json:"triples,omitempty"`
}

// ReferenceTriple maps an environment to a set of measurements.
type ReferenceTriple struct {
	Environment Environment `cbor:"0,keyasint" json:"environment"`
	Measurements []Measurement `cbor:"1,keyasint" json:"measurements"`
}

type Measurement struct {
    Val    KeyVal `cbor:"0,keyasint" json:"val"`
    Key    KeyVal `cbor:"1,keyasint,omitempty" json:"key,omitempty"`
    RawVal []byte `cbor:"2,keyasint,omitempty" json:"raw_val,omitempty"`
}

2. Parsing Logic

Implement a CBOR parser to read .corim files.

func ParseCorim(data []byte) (*Corim, error) {
    var c Corim
    if err := cbor.Unmarshal(data, &c); err != nil {
        return nil, err
    }
    return &c, nil
}

3. Integration with Verifier (pkg/attestation)

The Verifier interface will be expanded.

type Verifier interface {
    VerifyAttestation(report []byte, teeNonce []byte, vTpmNonce []byte) error
+   VerifyWithCoRIM(report []byte, manifest *corim.Corim) error
    // ...
}

4. Manager Update

The Manager service currently reads attestation_policy.json. We will add support for loading a CoRIM file, parsing it, and passing it to the verifier.

Migration Path:

1. Phase 1: Add CoRIM structures and parser.
2. Phase 2: Add VerifyWithCoRIM to the verifier alongside existing methods.
3. Phase 3: Deprecate the old attestation_policy.json format in favor of CoRIM.