Ballot for charter-ietf-rats
Yes
No Objection
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
I don't have a strong feeling on whether or not the use cases document needs to be published, but I agree that the question should be considered. >4. Standardize interoperable protocols to securely convey assertions/claims. Is plural intended here?
I am balloting "yes", but have a few minor comments. These need not block external review, but might should be considered prior to approval: - "The WG will also evaluate prior work such as NEA and proprietary attestation technologies." Since I assume the group plans to create standards track specifications, there is a good chance any given "proprietary" technology will have restrictions that prevent its use. It might be worth adding a few words about any such proprietary standard being sufficiently open for IETF purposes. (I'm specifically not thinking about patents so much as license restrictions on the specifications themselves.) (nit): I find the repeated use of "assertions/claims" a bit jarring. Are they assertions? Claims? Both? Please consider whether item 1 under "Program of work" needs to be published as RFCs or can be published via some alternative channel (e.g. Working Group wiki).
The charter contents look generally good to me, although I have some copy-editing suggestions to make. I also agree with Ben that the charter needs to be clear about whether the referenced support documents are intended for publication as RFCs. One substantive comment first: > The architecture may include a system security model > for the signing key material and involve at least the system component, system > component provider, and the relying authority. It's not clear to me whether this is intended to include/leverage an existing PKI, establish a new PKI, or use some other scheme to establish trusted roots. It seems that some of these options could end up being rather far ranging. I don't feel strongly about what the correct answer is, but I think we want the charter to make it clear whether such potentially broad tasks are in scope for the working group, or if the models to be considered should be more constrained. --------------------------------------------------------------------------- The introduction of the charter is a bit jarring in the way that it jumps in without first giving an indication of the technology field being dealt with. Starting with an introductory sentence -- or even a clause -- indicating that the working group is dealing with component attribute attestation would help. --------------------------------------------------------------------------- > To improve the confidence in a system component's trustworthiness a relying > party may require evidence about: Nit: "...trustworthiness, a relying..." --------------------------------------------------------------------------- > While domain-specific attestation mechanisms such as Trusted Computing Group > (TCG) Trusted Platform Module (TPM)/Trusted Software Stack (TSS), Fast > Identity Online (FIDO) Alliance attestation and Android Keystore attestation Consider an Oxford comma before "and Android". --------------------------------------------------------------------------- > While a relying party may use > reference values to assess the assertions/claims the procedures for this > activity are out of scope for this WG. Nit: "...claims, the procedures..." --------------------------------------------------------------------------- > The working group will cooperate and coordinate with other IETF WG such as > TEEP, SUIT and SACM as appropriate. Consider an Oxford comma before "and SACM". --------------------------------------------------------------------------- > 3. Standardize data models that implements and secures the defined information Nit: "...models that implement and secure..." or "...a data model that implements and secures..."
Thanks for addressing my concerns.
Hello, I mostly have questions for clarifications. Thank you. Relying parties require evidence about the trustworthiness of remote system components [RFC4949] they interact with. Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components by creating and processing attestation evidence. I'm not a native English reader, but this sentence gives me the impression that the relying parties will create the attestation evidence. Is that the case? My limited understanding of the topic makes me think that the remote system will create the attestation and the relying parties will process it. While a relying party may use reference values to assess the assertions/claims the procedures for this activity are out of scope for this WG. I can understand why, but I would also see some value in having a document which would cover this. About the "proprietary attestation technologies", are these publicly available/accessible? (similar to Ben's question) The architecture may include a system security model for the signing key material and involve at least the system component, system component provider, and the relying authority. Does that imply new work or is it just about reusing what may already exist? But I see Adam had a similar question.
Regarding use cases, I would actually rather prefer that the core use cases are already defined at charter time (in the charter). I'm not sure it that is possible for this group but it can be good start with one or two use cases that are mentioned in the charter and then update the charter if there is a real need to include more use cases in future.