|
Hello,
This is the second time through IETF Last Call for EAT.
The significant difference between draft-ietf-rats-eat-24 and draft-ietf-rats-eat-27 is the removal the normative reference to SUIT
Manifest (and in turn SUIT MTI) so as to not have to wait for publication of the SUIT docs. See diff of manifests section below.
Our thinking is EAT is undiminished by this removal. The normative reference is only for the manifests claims, not for any central part of EAT.
The manifests claim is pluggable via a CDDL socket and CoAP content type. The SUIT Manifest reference is really just a pre-registration of a content type. It is still easy for someone to use SUIT Manifest with EAT. The pre-reg of CoSWID manifest and measurements
content types will still be there.
If the reference were for a core part of EAT, like JWT or COSE, we wouldn’t have made this change.
The reason we put the reference in the document was to help justify and prove out the design of the manifests claim. That is accomplished. If we were thinking more carefully, we would have made the reference informative or removed it to avoid the publication
schedule interlock like we did with UCCS.
The other changes are fixes for typos, changes for the completed IANA assignments, idnits and other that would not trigger this recycle through WGLC and IETF LC.
LL
4.2.15. manifests (Software Manifests) Claim The "manifests" claim contains descriptions of software present on the entity. These manifests are installed on the entity when the software is installed or are created as part of the installation process. Installation is anything that adds software to the entity, possibly factory installation, the user installing elective applications and so on. The defining characteristic of a manifest is that it is created by the software manufacturer. The purpose of this claim is to relay unmodified manifests to the verifier and possibly to the relying party. Some manifests are signed by their software manufacturer independently, and some are not either because they do not support signing or the manufacturer chose not to sign them. For example, a CoSWID might be signed independently before it is included in an EAT. When signed manifests are put into an EAT, the manufacturer's signature SHOULD be included even though an EAT's signature will also cover the manifest. This allows the receiver to directly verify the manufacturer-originated manifest. This claim allows multiple manifest formats. For example, the manifest may be a CBOR-encoded CoSWID, an XML-encoded SWID or other. Identification of the type of manifest is always by a Constrained Application Protocol (CoAP) Content-Format integer [RFC7252]. If there is no CoAP identifier registered for a manifest format, one MUST be registered. This claim MUST be an array of one or more manifests. Each manifest in the claim MUST be an array of two. The first item in the array of two MUST be an integer CoAP Content-Format identifier. The second item is MUST be the actual manifest. In JSON-encoded tokens the manifest, whatever encoding it is, MUST be placed in a text string. When a non-text encoded manifest like a CBOR-encoded CoSWID is put in a JSON-encoded token, the manifest MUST be base-64 encoded. This claim allows for multiple manifests in one token since multiple software packages are likely to be present. The multiple manifests MAY be of different encodings. In some cases EAT submodules may be used instead of the array structure in this claim for multiple manifests. A CoSWID manifest MUST be a payload CoSWID, not an evidence CoSWID. These are defined in [RFC9393].
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
