rats

Summary

The RATS working group session focused on updates for several key drafts, including CHArA, Event Stream Subscription, AR4SI, Architecture, DAA, Interaction Models, UCCS, EAT, and RIV. A significant portion of the session was dedicated to discussing a proposed charter update, which generated considerable debate regarding protocol scope and the definition of attestation results. Lawrence presented a taxonomy for EAT and attestation results, prompting a detailed discussion on the roles of verifiers and relying parties, and the spectrum of security strengths and system architectures that attestation results should accommodate. While no major new decisions were made on technical drafts, the charter discussion was deferred to the mailing list for further consensus.

Key Discussion Points

CHArA (Composed Hierarchical Attestation):
- Draft is at version 18, undergoing ISG review.
- Two discusses remain, believed to be minor and addressed; one more ISG vote needed for closure.
- Changes include adding an IMA appendix, reference updates, and XPath syntax tweaks.
- Action requested for Roman to get the discusses addressed before ballot turnover on Wednesday.
Event Stream Subscription:
- Stable, depends on CHArA for progression.
- Aims to provide verifiable fresh evidence streams from TPMs, avoiding challenge-response for PCR changes.
- Expected to proceed to Working Group Last Call (WGLC) after CHArA completes ISG review.
AR4SI (Attestation Results for Secure Interactions):
- Adopted by the working group since IETF 112.
- Now adopted by the Confidential Compute Consortium.
- Text clarifications made on trustworthiness claims values.
- Mailing list discussions compared AR4SI claims with EAT security and software results.
- Trusted Path Routing document aligning but not requesting adoption yet due to lack of market uptake.
- Highlighted design principles for AR (explicit states, clear definitions, extensibility).
- Discussion on a comparison table for executable/filesystem trustworthiness claims vs. EAT software results, emphasizing commonality in claim design.
RATS Architecture:
- Document has no remaining issues (185 resolved pull requests).
- Currently in a "limbo state" of being submitted to ISG.
- Roman (AD) confirmed it's in pub req queue; he will perform an early review and then trigger IETF Last Call and directorate reviews. No further edits by authors until next action from ISG.
DAA (Direct Anonymous Attestation):
- Adopted as a standalone document after splitting from the interaction model draft.
- Next steps include:
  - Fleshing out relationship with RATS endorser.
  - Elaborating on the TCG Privacy CA concept.
  - Correlating with the DICE concept for trust chain consumption.
- Discussion on DAA's applicability beyond TPMs (e.g., FIDO, EAT, KOSE). Clarification needed on use cases for group attestation where individuality is not desired, contrasting privacy (cell phones) with scale (IoT sensors).
Interaction Models:
- Covers challenge/response, subscription, and time-based models.
- C2PA (Coalition for Content Provenance and Authenticity) project is driving the implementation of background check and passport combinations, leading to their inclusion.
- Working group asked to review for maturity and consider early last call or early review.
UCCS (Unprotected Claims in CoAP Security):
- Appendix added to accommodate JSON/CBOR with CDDL (using "feature" and "generic" capabilities).
- Working group discussion initiated on whether to rename to UJCS (Unprotected JSON Claims/CBOR Claims) to reflect JSON support.
- Emphasis on bundling with a prescriptive threat model and security considerations, making it relevant to RATS despite general applicability to CWTS.
EAT (Evidence Attestation Token):
- Dash-12 draft has most items "green" (ready for last call), except for measurements and results.
- Key changes: hardware model claim, boot odometer claim, privacy considerations, IANA section filled.
- Planning for dash-13 includes grouping claims (entity, token metadata, nonce, public keys) and completing CDDL for JSON/CBOR generics.
- Open consensus items: normative dependency on UCCS, the "security level" claim, and its role in attestation results (profile vs. general code, relation to AR4SI).
- Good news: early IANA allocation for EAT claims has been approved.
RIV (Remote Integrity Verification):
- Discuss comments resolved. A few non-blocking comments remain for resolution.
- Expected to go to RFC editor once comments are addressed.
- Follows the background check model; does not explicitly include relying party interaction.
Charter Discussion:
- Proposed rechartering text was presented, expanding the program of work to include "standardized interoperable data formats to securely declare and convey endorsements and reference values" (item 6). Minor cleanup on other items.
- A poll indicated low readership of the proposed text (8 out of 24 participants).
- Discussion on the asymmetry in point 5 of the program of work (protocols for attester-verifier vs. reusing for verifier-relying party). Consensus to clarify that existing protocols should be preferred, but without precluding new ones if justified.
- Lawrence raised concern about ensuring EAT is not implicitly excluded as an attestation results protocol.
- Chairs updated the text live on GitHub to reflect the preference for existing protocols.
Milestones:
- Chairs acknowledged being behind on milestone updates.
- Roman (AD) requested the working group to pipeline work correctly, avoiding starting too many things at once and suggesting "waves or sprints" of related work for productivity.
Taxonomy, EAT, Attestation and Results Taxonomy (Lawrence):
- Scope of Attestation Results: Should support a full range of security strengths (from simple authenticated identity to TPM/TEE based) and system architectures (purpose-built hardware, app-based, hybrid).
- Verifier vs. Relying Party Roles: A key discussion point. Lawrence argued that the verifier's role is device integrity/trustworthiness, while the relying party applies domain-specific policy (e.g., transaction amount, application context). Eric agreed, emphasizing relying party as a role, not physical item. Brendan suggested a multi-stage verification (two verifiers + relying party). Hank stated the verifier is well-defined in the architecture, making policy decisions that the relying party consumes.
- Interaction between Verifier and Relying Party: Suggested JSON + TLS for B2B interactions, without needing extensive new standards.
- Device Identity: Discussion on what constitutes "device identity" (OEM, model, serial number, version) versus "identifier" (UEID, UUIDs, industry-specific). Hank noted CoRIM's extensive list of identifiers.
- "Verified Forwarded Claims": Proposed term for attester claims passed from verifier to relying party, subject to verifier's policy (not a blind "pass-through").

Decisions and Action Items

CHArA: Roman (AD) to contact Rob Wilton to re-evaluate his discuss comments, aiming for resolution before Wednesday's ballot turnover.
RATS Architecture: Roman (AD) to perform an early review and then trigger the IETF Last Call and directorate reviews after IETF week.
Charter Discussion: Chairs to conduct another poll and call for support on the mailing list for the proposed rechartering text, which was updated during the session to clarify the preference for reusing existing protocols.
Milestones: Working group to review and update milestones to reflect current draft status and consider Roman's advice on pipelining work.

Next Steps

CHArA: Address remaining ISG discusses for publication.
Event Stream Subscription: Await CHArA publication, then proceed to WGLC.
AR4SI: Continue internal development and mailing list discussions.
RATS Architecture: Await AD review and IETF Last Call.
DAA: Authors to continue fleshing out relationships with endorsers, Privacy CA, and DICE, and consider broader applicability.
Interaction Models: Working group review, consider early last call.
UCCS: Working group discussion on renaming to UJCS and formalizing JSON/CBOR support.
EAT: Complete CDDL, group claims in dash-13, resolve consensus items (UCCS dependency, security level, AR role).
RIV: Address remaining minor comments for RFC editor submission.
Charter: Further discussion and poll on the mailing list.
Taxonomy & Roles: Continue discussions on the mailing list regarding verifier/relying party roles and the scope of attestation results and device identity.

Session Date/Time: 23 Mar 2022 12:00

rats

Summary

The rats working group session addressed three main topics: the relationship and dependencies between the EAT (Evidence Attestation Token) and UCCS (Unsigned CBOR/JSON Claim Set) documents, the relevance of private key extractability in attestation for cloud environments, and the proposal for CoRIM (Concise Reference Integrity Manifests). A key decision was made regarding the EAT/UCCS dependency, guiding EAT authors to move normative UCCS content to informative references. Discussions on private key extractability indicated a preference for handling this in dedicated profiles rather than EAT itself. The CoRIM presentation received positive feedback, with a plan to revisit adoption once the working group's charter is updated.

Key Discussion Points

EAT and UCCS Relationship
- Presentation by Gidi (EAT Editors):
  - UCCS is scoped to attestation, covering both unsigned CBOR and JSON claim sets.
  - UCCS does not normatively require a mutually authenticated secure transport; EAT is silent on transport requirements.
  - EAT has a normative dependency on UCCS's definition and a stable CDDL description.
  - Editors' Recommendation: EAT to provide the CDDL description for unsigned claim sets (for CWT and JWT) and incorporate the CBOR/JSON tag. The current UCCS document would refocus on security considerations for unsigned claims, potentially moving to an informational track and covering attestation results beyond just evidence.
  - Rationale: EAT needs a stable CDDL, UCCS security considerations are evolving and complex, and to avoid holding up EAT's progress.
- Discussion:
  - Dave Taylor: Asked if UCCS could apply to attestation results (beyond evidence), suggesting an amendment to UCCS introduction for broader applicability. Gidi confirmed this could be considered.
  - Roman: Clarified if UCCS security considerations would be normative or informative. Gidi stated they would be informative due to the evolving nature of use cases.
  - Kathleen (Chair): Expressed concern about timeline impacts if UCCS content were folded into EAT. Gidi clarified only the CDDL description would be incorporated, not the entire UCCS document.
  - Carsten: Raised a fundamental concern about EAT potentially pulling CWT's general-purpose nature into the RATS scope, advocating for clean separation between CWT as a basic mechanism and EAT extensions. Noted practical problems with section 8 of EAT.
  - Hank: Emphasized that UCCS is for CWT within an attestation context (RATS charter), stressing the importance of context for its safe use. Reaffirmed UCCS is dangerous without prescribed usage and threat models.
Attestation for Cloud (Private Key Extractability)
- Presentation by Gidi:
  - Highlighted an emerging issue: cloud synchronization of private keys, particularly for authentication credentials (e.g., FIDO).
  - Noted that FIDO authenticators may not have the architectural separation between attester and target environment assumed by the current RATS architecture, as keys might be extractable.
  - Question to WG: Should attestation evidence (specifically EAT) address whether private key material (especially attestation keys) is extractable?
  - Proposed Ways Forward:
    1. Define relevant evidence entry claims in EAT (if of general interest).
    2. Leave the issue to a profile for FIDO-compliant authenticators.
    3. Do nothing, let the Relying Party (RP) determine appraisal via implicit evidence or other means.
- Discussion:
  - Hank: Expressed concern about key extractability, stating it's dangerous without trustworthy endorsements.
  - Dave Taylor: Favored leaving the issue to a specific profile (option 2).
  - Lawrence: Differentiated between FIDO authentication keys (FIDO's concern) and attestation keys (relevant to RATS), suggesting export of attestation keys is a major issue for this group.
  - Tony Natoli: Recommended doing nothing in this space, letting FIDO or profile creators handle it.
  - Chair Guidance: Gidi to post on the mailing list to solicit interest and further discussion for solutions outside the EAT core document.
CoRIM (Concise Reference Integrity Manifests)
- Presentation by Thomas:
  - Goal: Provide a standard information and data model for supply chain actors (OEMs, ISVs, etc.) to describe an attester to a verifier, enabling evidence appraisal. Aims to reduce fragmentation and lower barriers to entry.
  - Scope: Focuses on endorsement and reference values flowing into the verifier (as per RATS architecture diagram). CoRIM defines payloads, not transport.
  - Design Principles: Describes attesters using simple "triples" (subject-verb-object), serialized in CBOR (concise), and signed with COSE. Extensible set of triples.
  - Status: Information model stable (TCG DICE working group consensus), data model maintained in GitHub (CDDL, examples), and a software implementation exists (Golang library, CLI).
  - Question: Once the proposed new RATS charter (which includes CoRIM scope) is in place, would CoRIM be considered for adoption?
- Discussion:
  - Dave Taylor: Supported CoRIM's appropriateness for RATS if the charter passes. Highlighted its primary value for defining reference values due to the need for sets of values and verbs. Suggested potentially scoping the work to focus on the "reference value provider" line.
  - Hank: Agreed endorsements can exist independently, but reference values need pointers to endorsers. Believes CoRIM can accommodate the separation between endorsers and reference value providers. Mentioned a corresponding profile, the PSA endorsement token, is already being developed.
  - Lawrence: Noted the need for reference values to correlate with measurements in evidence and confirmed CoRIM (which contains CoMID schema) is compatible with EAT's plug-in formats for measurements.
  - Chair Guidance: Adoption cannot happen before charter update. Chairs will solicit review feedback from the working group on the mailing list after the charter is updated, before a formal call for adoption. Acknowledged previous interest from the mailing list.

Decisions and Action Items

EAT and UCCS Circular Dependency:
- Decision: The working group expressed consensus (via poll) that normative content regarding UCCS should be removed from the EAT specification and changed to be informative. This guidance is intended to accelerate EAT's progress towards RFC publication.
- Action Item: EAT authors are directed to revise the EAT draft to move normative UCCS-related content to informative references. The chairs will further clarify on the mailing list the specific handling of the UCCS CDDL (e.g., if EAT should define its own, reference CWT's, or use an informative reference to UCCS).
Attestation for Cloud (Private Key Extractability):
- Decision: The working group did not express interest in incorporating private key extractability claims directly into the EAT core document at this time.
- Action Item: Gidi to post on the mailing list to gauge further interest for addressing private key extractability in a dedicated profile or solution outside of EAT core.
CoRIM (Concise Reference Integrity Manifests):
- Decision: The document cannot be adopted at this time as its scope is not yet covered by the current RATS charter. Positive interest was noted from the group.
- Action Item: Thomas (CoRIM author) to await the update of the RATS working group charter. Once the charter update is complete, the chairs will solicit review and feedback on the CoRIM draft from the working group on the mailing list, prior to a formal call for adoption.

Next Steps

EAT authors to update the EAT draft as per the guidance regarding UCCS dependencies. Chairs will provide further clarification on CDDL handling for EAT via the mailing list.
Gidi to post on the mailing list seeking further interest and direction for addressing private key extractability in cloud environments.
The working group awaits the charter update, after which the CoRIM document will be subject to a review and feedback period on the mailing list before a call for adoption.