+1 From: Ines Robles <[email protected]> Date: Thursday, August 10, 2023 at 1:53 PM To: "lgl securitytheory.com" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Genart last call review of draft-ietf-rats-eat-21 Resent-From: <[email protected]> Resent-To: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, Kathleen Moriarty <[email protected]>, <[email protected]>, <[email protected]>, Nancy Cam-Winget <[email protected]>, <[email protected]> Resent-Date: Thursday, August 10, 2023 at 1:52 PM
Many thanks Laurence for addressing my comments and for the providing clarifications I understand the provided motive to not imply the trust to be static. Perhaps, one way to convey the potentially varying degree of trust dependant on context can be achieved by replacing "wishes" (which is usually attributed to human sentiments) and as well as changing "how much" (which represents in my understanding a quantity value): Thus, instead of: "This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity." how about?: "This claims set is used by a relying party, server or service to determine the applicable trust in the entity." What do you think? Thank you and Best Regards, Ines. On Thu, Aug 10, 2023 at 10:03 PM lgl securitytheory.com<http://securitytheory.com> <[email protected]<mailto:[email protected]>> wrote: The PR to address these is here: https://github.com/ietf-rats-wg/eat/pull/403 Comments below. > On Aug 9, 2023, at 4:47 PM, Ines Robles via Datatracker > <[email protected]<mailto:[email protected]>> wrote: > > Reviewer: Ines Robles > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-rats-eat-21 > Reviewer: Ines Robles > Review Date: 2023-08-09 > IETF LC End Date: 2023-08-09 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This document describes Entity Attestation Token (EAT) that provides an > attested claims set that describes state and characteristics of an entity. > This > claims set is used by a relying party, server, or service to assess the > trustworthiness of the entity. EAT is constructed as a framework for defining > specific attestation tokens for specific use cases. > > The document is well documented, with good set of references. No major issues > found, minor nits found as specified below. > > Major Issues: None > > Minor Issues: None > > Nits: > > - Abstract: What about "...service to determine how much it wishes to trust > the > entity." --> "...service to assess the trustworthiness of the entity." ? I prefer it as is, but am open to the change if there is consensus. I prefer it as is because it I think the existing wording leaves room for the context of the trust. To me your proposed wording seems like trust is determined once for all use cases. I think one might trust the same entity in one context, but not in another. For example, one context might be for transaction in dollars and another might be for authentication to access governmental data. I don’t think trust or trustworthiness is universal (even though lots of engineers, marketing people and such do use the word that way). > > - Section 4.1.17: Maybe "failure, fail to run, ..." --> "failure, fail to run, > among others." ? Changed to "success, failure, fail to run, and absence” because there are only four options. > > - In Section 4.2.14 "(DLOAs))" --> (DLOAs), the same for (Section 4.2.16)) in > Section 6.2.12 Fixed. > > - Section 4.3.3 and Section 7.3.1. "TBD(BUNDLE-Untagged-Message)" --> > TBD602(BUNDLE-Untagged-Message) ? (To be aligned with IANA Section) Fixed. > > - Section 6.2.12: "This document requires an EAT receiver must accept all > claims it does not understand." are there specific security consideration to > follow in this case not mentioned in section 9.1? Reworded to "This document requires an EAT receiver must accept tokens with claims it does not understand” as the existing sentence really didn’t say the right thing. I don’t think there are security concerns here. > > - Section 6.3: It would be nice to have a caption for Table 2. (Same for rest > of the tables) Fixed. > > - Section 7.3.1: "one place that that a CBOR token" --> "one place where a > CBOR > token" ? Fixed. > > - Appendix C.1: "EAT doesn't define a an device implementation and DevID > does." > --> "EAT doesn't define a device implementation, but DevID does." ? Fixed. > > Thanks for this document, Thank you for reviewing. It’s a long document and I know it takes a lot of work. LL > > Ines. > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
