Reviewer: Eliot Lear
Review result: Not Ready
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
