From nobody Tue Dec 7 13:51:45 2021 Return-Path: X-Original-To: rats@ietfa.amsl.com Delivered-To: rats@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377513A0E98 for ; Tue, 7 Dec 2021 13:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHMgVQbeGmk8 for ; Tue, 7 Dec 2021 13:51:38 -0800 (PST) Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98683A0E9A for ; Tue, 7 Dec 2021 13:51:38 -0800 (PST) Received: from [192.168.1.7] ([75.80.148.243]) by :SMTPAUTH: with ESMTPA id uiN7mmmR3GWO8uiN7m4a1B; Tue, 07 Dec 2021 14:51:38 -0700 X-CMAE-Analysis: v=2.4 cv=KrWIZUaN c=1 sm=1 tr=0 ts=61afd76a a=VPU1mRQhDhA4uSX60JRRww==:117 a=VPU1mRQhDhA4uSX60JRRww==:17 a=IkcTkHD0fZMA:10 a=7CQSdrXTAAAA:8 a=bdzn421bSdgKicsT3UsA:9 a=QEXdDO2ut3YA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 X-SECURESERVER-ACCT: lgl@island-resort.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Laurence Lundblade In-Reply-To: Date: Tue, 7 Dec 2021 13:51:37 -0800 Cc: "rats@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.104.17) X-CMAE-Envelope: MS4xfJU5qfn7PgqTnpJpaAty8LDGJqy7+mMreWsl5e20yEey8cAeoqtbI8dRHZJJOHtt0l1AsGUcjtVf1k+ZtLHmh2FKZg41QGZeDc5X4WC5HdxZZHJD40kB M1gEd54KaQ22UMC66bHg9RCNM+RkPJpuBc3MELuf2m7uF5X+grfxTstVyjn7Wn4RILdBH1nPK9wB6B1NANYm1O1i0aekSOEAh1a08cn8NnazNS+V6mKuTl4w Archived-At: Subject: Re: [Rats] EAT Review Comments X-BeenThere: rats@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Remote ATtestation procedureS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 21:51:44 -0000 First of all, I really appreciate the thorough reading. This is probably = the first deep substantive set of comments ever made on EAT. > On Dec 7, 2021, at 3:49 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > As promised, here are some high-level review comments, which are most = important to us: >=20 > - The document would benefit from a normative language. Think in the = following way: What does a party creating a claim and a party verifying = the claim have to do in order to ensure interoperability. Use SHOULDs = and MAYs when you can give the reader a decision path. >=20 > - Don't put comments into the CDDL since the same text is already in = the draft. You are essentially putting the text in the document twice. = This will reduce the size of the document. >=20 > - Normative vs. informative references: If you need to read a = specification as a developer in order to implement a listed claim then = this reference is normative. For example, the location claim cannot be = implemented without having to open the W3C geolocation API. Hence, that = reference becomes normative. >=20 > - Aim for consistent use of terminology. An example is the use of = "entity", "entity/device", "device/entity", "entity/client device", = "device entity", "entity or submod", "entity (typically a device)". In = Section 1.4 you seem to suggest that "entity" is the right term. But = throughout the text you mix the terms. The EAT draft should adopt the = terminology established in the architecture doc, which would be = "attester" rather than "entity". Section 2 should import the vocabulary = from the architecture document **by reference** and establish the = aliasing "attester" =3D "entity" (and maybe =3D "device") by saying = something along these lines: "attester and entity are used = interchangeably in this document=E2=80=9D. Agree about most of the above and will work through it. >=20 > - The spec is long and there is a lot of feature creep. This makes it = appear very complex. I believe there are two reasons for this, namely = (a) there is suddenly a lot of architectural discussion in this = document. This is unnecessary given that there is a separate = architecture document. There is no need to repeat the content here as = well. Do you expect a reader to go through the architecture document = before reading this document? OK. I will work to remove some of this. A few hints and examples of what to remove would be helpful. =20 I already made one pass at removing text from EAT that was covered in = RATS architecture. (EAT -01 actually predates RATS architecture, so = there was lots of stuff to remove). > (b) There are claims in this specification that may sound good but I = wonder whether they are ready for prime time already. This document does = not need to collect all claims that relate to attestation. Most likely = there is not much experience implementing some of these claims either, = which reduces the quality of the specification. Sometimes less is just = more. Definitely agree that less can be more. Top of my list of claims to remove are uptime and boot seed. The other claims have a strong purpose in my mind. They are necessary to = describe the device and the attestation results. - Maybe the DLOA=E2=80=99s claim could be removed, but I think it is = important for RP=E2=80=99s to be able to know about certification status = in attestation results. - The description of SW manifests and measurements is a bit difficult, = but I=E2=80=99ve tried make use of the best things out there and be = flexible / pluggable since it is a moving target. - The set of UEID/SUEID, HW OEM ID, HW Class and HW Version is what is = necessary to identify HW. There is similar reasoning for the other claims.=20 Which claims would you remove? >=20 > - Unprotected CWT Claims Sets (UCCS): I see UCCS as an architectural = aspect. Normally, the implications for the EAT spec should be quite = small. The purpose of the EAT spec is to define claims that go into a = CWT. EAT does not mandate a specific way to protect the claims (digital = signature, MAC, encryption, etc.) then UCCS has not much implication = besides a short mention in the security consideration section. Given = that UCCS is a separate working group document we would remove Section 4 = along with any reference to UJCS. There=E2=80=99s strong logic here: =E2=80=94 RATS architecture explicitly calls out composite attestation =E2=80=94 A submodule can be a nested EAT to implement composite = attestation =E2=80=94 A nested EAT can be a CWT, UCCS or DEB =E2=80=94 The CDDL that specifies a nested EAT submodule thus must = mention UCCS So a UCCS is a claim that goes into a CWT. I think UCCS, particularly = CDDL for UCCS, must be included because of this. We decided a long time ago that EAT would support JSON in a normative = way. The logic continues: =E2=80=94 An EAT can be a JWT =E2=80=94 EAT specifies claims that go into a JWT (and a CWT) =E2=80=94 A submodule can be an nested EAT =E2=80=94 A submodule can then be a JWT in a CWT or a CWT in a JWT If we stay with the idea that EAT has normative support for JSON, then I = believe the above logic holds and specification of the above is = necessary. I don=E2=80=99t think we realized the implications of EAT formally = supporting JSON/JWT in a normative way a few years back. I certainly = didn=E2=80=99t. Trying to write and validate the CDDL for both JSON and = CBOR, JWT and CWT brought it to light. Maybe it=E2=80=99s too much? What = do people think about completely removing normative JSON support from = EAT? Now on to UJCS. The decision on it can be separate from the above = logical conclusion, partly because JWT has the (awkward) null algorithm = mode. My main logic about UJCS is: =E2=80=94 JSON is far more popular than CBOR =E2=80=94 If there is reason to specify UCCS, then there is more reason = to specify UJCS =E2=80=94 This also lines up with EAT being used for attestation = results, which are likely to be JSON. Maybe UJCS can be removed from EAT, but it seems like it should then = exist somewhere else. There is still a logic and power in bringing all this highly related = stuff (CWT, JWT, UCCS and UJCS) together especially when you try to = write CDDL for it where individual claims can be JSON or CBOR and = individual tokens can be JSON or CBOR. This goes back to composite = devices described in RATS architecture. LL