Markdown Version | Session Recording
Session Date/Time: 12 Dec 2022 15:00
RATS
Summary
The RATS Working Group met to review outstanding issues and blockers for the Entity Attestation Token (EAT) draft (draft-ietf-rats-eat) and discuss its readiness for IESG review. Most open issues were discussed and dispositioned as "won't fix," with some clarifications to be added in GitHub comments or notes for other documents. A general sense of those present indicated that the upcoming draft-ietf-rats-eat-19, which will incorporate minor fixes and editorial changes, would be a reasonable candidate for IESG review following its publication and subsequent review on the mailing list. One remaining technical issue regarding the iat claim's CDDL definition will be resolved offline.
Key Discussion Points
-
Note Takers: Carl and Hank volunteered to take notes.
-
Boilerplate: The chairs presented the IETF Note Well, session recording, and general meeting conduct.
-
Draft 18 Changes: Lawrence shared an update on changes introduced in draft-ietf-rats-eat-18:
secbookclaim renamed tooem-bootand described as OEM authorized boot.- The term
attestationsin the attestation results claim was changed toevidenceandattestation-results. - Clarifications were added to the privacy considerations section regarding freshness and replay protection.
- Numerous minor typographic and wording fixes based on review comments (especially from Hannes Tschofenig's GitHub PRs) will be merged into draft-19.
-
Issue 10: Yang objects for claims:
- The issue requested guidance on creating Yang objects for claims.
- Discussion affirmed that the document focuses on CBOR and JSON encoding, and adding Yang would be out of scope.
- Decision: Close as "won't fix."
-
Issue 11: Reordering sections in the EAT document:
- The request was to move claim definitions later in the document.
- The current order aligns with JWT and CWT documents, where claim definitions are presented early.
- Decision: Close as "won't fix."
-
Issue 1 (Part 1): SUEID labels assignment:
- The issue asked how SUEID labels are assigned.
- The document already states that their assignment is intentionally left open, allowing profiles to define specific assignment methods or requirements.
- Decision: Close as "won't fix," with a clarifying comment to be added in the GitHub issue that profiles can constrain this.
-
Issue 1 (Part 2): UEID and SUEID can be the same:
- The issue asked if the UEID and SUEID can be the same.
- The current rules for UEID and SUEID imply they can be the same initially but might diverge due to lifecycle events, as SUEID can change while UEID cannot. No explicit statement is deemed necessary.
- Decision: Close as "won't fix," with a clarifying comment to be added in the GitHub issue that profiles can constrain this relationship.
-
Issue 2: Measurement Results Claim removal:
- The request was to remove the
measurement-resultsclaim due to its general nature making interpretation difficult for a relying party (RP). - Discussion highlighted that
measurement-resultsrepresents measurement results, not attestation results, and can be part of evidence or attestation results. It includes a simple pass/fail option, and RPs always need to understand the verifier's policy to interpret any claim. The document already explains its generality. - A participant suggested discussing the relationship between this claim and trustworthiness vectors in the AR4SI document.
- Decision: Close as "won't fix." A note will be added to the GitHub issue linking to the AR4SI repo for further discussion.
- The request was to remove the
-
Issue 6: Endorsements & Verification Keys specification:
- This issue (filed against draft-13) evolved into a request for detailed specification of methods for verification keys and endorsement identification.
- The normative section was moved to appendix F, which now provides examples (e.g., using UEID, X.509 certificates, COSE kid).
- It was noted that key and endorsement identification vary greatly by use case and are best addressed by profiles or separate documents, similar to COSE's approach.
- Decision: Close as "won't fix."
-
Other Recent Issues/PRs: A few very recent, minor issues and PRs (e.g., cddl formatting, wording) were acknowledged but deemed not to require meeting discussion and would be addressed in draft-19.
-
Readiness for IESG Review:
- A poll was conducted to gauge familiarity with draft-18: 5 out of 8 participants indicated they had read it thoroughly.
- A poll was conducted to get a sense of whether draft-19 (expected to contain mostly minor wording and editorial changes) would be suitable for IESG submission: A strong majority (7 in favor, 1 abstention) indicated it would be a reasonable candidate.
- It was noted that IESG review would likely lead to several further drafts.
-
Issue 343: IAT definition (cddl for time):
- This issue concerns the
iatclaim's CDDL definition. CDDL generally allowstimeto be an integer or float, but the EAT draft proposes disallowing floats in prose. - A participant argued against changing the CDDL to restrict
iatto integers when reusingiatfrom CWT/JWT RFCs, which allow both, suggesting it might break reuse principles. The current proposal in a PR is to enforce integer-only via prose, while CDDL still allows floats. - Decision: Due to time constraints, this issue will be resolved offline on the mailing list, with the goal of reaching a resolution before draft-19 publication.
- This issue concerns the
Decisions and Action Items
- Issue 10 (Yang objects for claims): Closed as "won't fix."
- Issue 11 (Section reordering): Closed as "won't fix."
- Issue 1 (SUEID labels assignment): Closed as "won't fix." A comment will be added to the GitHub issue clarifying that profiles define specific assignment methods.
- Issue 1 (UEID and SUEID can be the same): Closed as "won't fix." A comment will be added to the GitHub issue clarifying that profiles can constrain this relationship.
- Issue 2 (Measurement Results Claim removal): Closed as "won't fix." A note will be added to the GitHub issue indicating that discussion on the claim's relationship to trustworthiness vectors should occur in the AR4SI document.
- Issue 6 (Endorsements & Verification Keys specification): Closed as "won't fix."
- Chairs/Authors: Generate draft-ietf-rats-eat-19, incorporating recent minor fixes, editorial changes, and potentially the resolution for Issue 343.
- Working Group: Review draft-ietf-rats-eat-19 once published, and discuss readiness for submission to IESG on the mailing list.
- Issue 343 (IAT definition): To be resolved offline on the mailing list, aiming for a resolution before draft-19 publication.
- Carl: Add four proposed options for Issue 343 to the GitHub repo to facilitate offline discussion.
- Gary: Create an issue in the AR4SI repo to discuss the "measurement-results" claim and its relationship to trustworthiness vectors.
Next Steps
- The chairs and authors will continue work on draft-ietf-rats-eat-19, aiming for publication before the holidays.
- The working group will address Issue 343 (IAT definition) offline via the mailing list.
- Following the publication of draft-ietf-rats-eat-19, the working group will conduct a final review to confirm readiness for IESG submission.
- An issue will be opened in the AR4SI repository to discuss the
measurement-resultsclaim.