Last Call Review of draft-ietf-rats-eat-13
review-ietf-rats-eat-13-iotdir-lc-lear-2022-06-05-00
review-ietf-rats-eat-13-iotdir-lc-lear-2022-06-05-00
Major: The most major problem with the document is this: 7. Profiles This EAT specification does not gaurantee that implementations of it will interoperate. The variability in this specification is necessary to accommodate the widely varying use cases. An EAT profile narrows the specification for a specific use case. An ideal EAT profile will guarantee interoperability. This is quite counter-cultural to the IETF. You start with the smallest set of functionality and then expand outward to cover different use cases that make use of different extensions. I'm not saying that profiles would not be necessary, but that some additional thought be given to extension mechanisms. This statement in particular is quite disturbing. In some cases CDDL may be created that replaces CDDL in this or other document to express some profile requirements. Not only is this counter-cultural, but it would require an Updates: header on any such profile, and would further just be plain out confusing. In short, the profile mechanism is harmful to the very concept of interoperability. Section 4.1: The nonce MUST have 64 bits of entropy as fewer bits are unlikely to be secure. A maximum nonce size is set to limit the memory required for an implementation. There are two sides to this equation: the generator of the nonce and the consumer. How is the generator supposed to know how much memory the consumer has? Section 4.2.1: UEIDs are variable length. All implementations MUST be able to receive UEIDs that are 33 bytes long (1 type byte and 256 bits). No UEID longer than 33 bytes SHOULD be sent. 256/8 = 8. 8+1 = 9. I don't understand the parenthetical. Between Section 4.2.1 and 4.2.2 there is a particular use case I would like to understand: If a system integrator resells a bunch of components that have been tied together, what guidance is given as to which [S]UEID should be exposed and for what purpose? Does the consumer consume a full array of each of these things? What's the intent? Section 4.2.6: Please do not use a free-form text field for the software. That makes comparisons and authorities quite difficult. In fact between this section and section 4.2.7, you may wish to consider using Package URLs. Section 4.2.8: As a whole this section is a bit too talkative. Also, there are many claims programs, and so I question the value its value. If it is seen as important, then some qualitative statement about specific certifications seems more appropriate. In general the CDDL for uints in particular requires .size values. Otherwise you are just asking for random failures based on the limits of varying tests. 4.2.15 DLOA This claim is typically issued by a Verifier, not an Attester. When this claim is issued by a Verifier, it MUST be because the entity has received the certification in the DLOA. Unclear antedent. Perhaps you mean: This claim is typically issued by a Verifier, not an Attester. Verifiers MUST NOT issue this claim unless they have received the the certification in the DLOA. Same issue with multiple DLOAs. Also, is it possible that DLOAs will be produced in JSON at some point in the future? If so, why not allow for that by not mentioning XML, and simply requirng observance of HTTP Content-type semantics? Section 4.2.16 Can a software manifest be an SPDX or CycloneDX document or a pointer to same? There's a WHOLE lot of the former out there, and the latter is growing in popularity. If this is the case, let's define appropriate types now. If there is no CoAP identifier registered for the manifest format, one should be registered, perhaps in the experimental or first-come-first-served range. This sentence seems redundant, and the policy aspects opens this work up to the peril of a policy change for the IANA registry. Section 9 The IANA will not know what to do with this section as most of it is not directed to them. Much of it might be better suited as a standalone document. But it does raise the question of whether or not some sort of subregistry should be formed for new claims, where an appropriate evaluation could be managed through the IANA process (pick your favorite). How that would be accomplished I leave to you. Minor: Introduction: It is the use of this key material that make the claims set "attested" rather than just some parameters sent to the relying party by the device. No. Attestation is a claim of validity. It is perfectly possible, and probably likely that many claims will be attested and not used. EAT is focused on authenticating, identifying and characterizing implementations where implementations are devices, chips, hardware, software and such. This is distinct from protocols like TLS [RFC8446] that authenticate and identify servers and services. It is equally distinct from protocols like SASL [RFC4422] that authenticate and identify persons. This paragraph is not well written. EAT is an object that asserts the validity of a remote attestation claim object. Appendix B: UUIDs seem to have been designed for scenarios where the implementor does not have full control over the environment and uniqueness has to be constructed from identifiers at hand. I don't see the value of any of this commentary. Either you know or you don't know. There is no need for conjecture in such a document. Is Section 4.4 somehow misplaced? I'm not quite convinced what value it is adding in that section, or what is intended to be specified. Section 6: There is not yet any standard format(s) for an Endorsement. One format that may be used for an Endorsement is an X.509 certificate. Endorsement data like Reference Values and implied claims can be carried in X.509 v3 extensions. Define Endorsements or don't define Endorsements. Don't half-define Endorsements. Just note that there is future work to be done somewhere. Nits: Abstract: To a large degree, all this document does is extend CWT and JWT. This statement is just inaccurate and would add nothing in any case. Suggest you remove. The document uses the term "entity" to refer to the target of the attestation token. Target or object? A target implies something at which one aims. An object is the entity upon which a subject acts through a verb. The claims defined in this document are claims about an entity. Or more simply," the claims defined in this document describe an entity." An entity is never a server or a service. Neither server nor service is defined. Don't go there. All claims in an EAT MUST use the same encoding except where explicitly allowed. That's better said, "... except where otherwise explicitly stated." Every instance of "CBOR encoded" or "JSON encoded" should be hyphenated. Personal preference nit: The English language requires capitalization only of proper nouns, acroynms, and the first letter of the first word of a sentence. Legal documentation makes use of capitals so as to indicate a very specific meaning to phrase in what is generally highly convoluted language. If you believe that your work is so convoluted that you need to use capitals, my suggestion is that you rewrite your work. Otherwise, maybe use lower case letters. Section 4.1: In CBOR, the nonce is a byte string and every bit in the byte string contributes to entropy. This statement is a bit odd. Can you show me a nonce in which some bit does NOT contribute to entropy? 4.2.18 {#swevidence} should not appear in the text. Section 4.3.2 If you are going to use the term "epoch" you have to describe when that epoch begins. That has to be commonly understood between the parties.