Non-verifiable claims

[steven-bellock]

CWT/EAT specifies claims that may not be verifiable by a Verifier, but which can provide information for the purposes of debug, audits, logging, and forensics. The OCP EAT profile may specify that these claims be part of the EAT. This issue is to discuss the merits and implementation burden of some of these claims.

[steven-bellock]

From CWT I think the points to discuss are

• sub (Subject)
• cti (CWT ID)
• aud (Audience)

I left out exp, nbf, and iat since the device needs access to some kind of clock, which may or may not be secure and which may or may not be accurate.

From EAT I think the points to discuss are

• ueid (Universal Entity ID)
• oemid (Hardware OEM Identification)
• hwmodel (Hardware Model)
• hwversion (Hardware Version)
• dbgstat (Debug Status)
• uptime (Uptime)
  • May not be accurate.
• bootcount (Boot Count)
  • Requires non-volatile counter.
• bootseed (Boot Seed)
  • May require entropy early in the boot process.
• intuse (Intended Use)

cti is beneficial as it uniquely identifies the EAT, as does bootseed for the boot epoch.

[steven-bellock]

dloas (Digital Letters of Approval) would be the way to directly link the EAT to its corresponding OCP SAFE documents. RFC9711 says

This claim is typically issued by a verifier, not an attester.

but, in theory, it should not be too burdensome for an attester to provide this information.

[fdamato]

I`m also in favor to use DLOAS for SAFE. I would say it is ok to include the following as optional claims:

• sub (Subject)
• cti (CWT ID)
• aud (Audience)

[fdamato]

To be more generic, perhaps we could write some texts that allow the attester to augment the evidence with any non-verifiable claims. For some of those as DLOAS, which are very useful for OCP SAFE, we could say those are recommended (but not mandatory). The intent is that without those claims, the Verifier shall still be able to perform full appraisal policy, therefore still conforming to the "full profile" requirements

[gmandyam]

My take:

The CWT claims (sub, cti, aud) are more useful for passport model, not SPDM responder (which I view as corresponding to background check). Referring to https://datatracker.ietf.org/doc/html/rfc9334#name-topological-patterns, for passport model the verifier provides an attestation result which could include these 3 claims related to the attester. If the the attestation results are in the form of an EAT (e.g. https://datatracker.ietf.org/doc/draft-fv-rats-ear/) then these claims can be provided by the verifier. So if they must be included in the OCP profile then they should be optional.

ueid provides the unique ID for the attester. This should be included in the attestation (i.e. mandatory).

dbgstat should be included as well (mandatory), to allow for a SPDM requestor + verifier to take into account the debug state of the SPDM responder.

oemid/hwmodel/hwversion should be optional. The first 3 may or may not be pre-provisioned in the device - depends on the manufacturer.

intuse should be optional. In fact, if intuse is used it may have to be extended for the SPDM responder case (https://datatracker.ietf.org/doc/html/rfc9711#name-intended-use-registry). For instance, there isn't an existing option for extending a CVM's memory to a device/TDI in the current list of options.

uptime/bootcount should be optional because of the reasons cited by @steven-bellock.

bootseed was originally proposed in the context of PSA token (https://datatracker.ietf.org/doc/html/rfc9783#name-boot-seed) and adopted by EAT. I assume this is of less value in datacenter applications, as the boot cycles are lengthy (i.e. re-boot is a rarer occurrence when compared to consumer devices). I think it can therefore be optional.

[steven-bellock]

In the meeting today Roksana mentioned that some claims, like UEID, might not be appropriate for in-band / guest attestation.

[fdamato]

In the meeting today, we agreed to keep as mandatory claims:

• cti (CWT ID) : Because it determines the uniqueness of the token
• dbgstat (Debug Status): Because it determines the Attester Debug State in an interoperable way

It was also discussed to keep optional but recommended:

• bootseed: It will help the verifier determine all token collected before a boot cycle occurred. However (due to the entropy early in the boot process requirement), the profile can`t be prescriptive and make this claim mandatory

Optional Claims:

• sub (Subject): To Be Determined
• ueid (Universal Entity ID)
• oemid (Hardware OEM Identification)
• hwmodel (Hardware Model)
• hwversion (Hardware Version)
• uptime (Uptime)
• bootcount (Boot Count)
• DLOAS (Digital Letter Of Approval): This would be used to convey Endorsement URI path, such as OCP SAFE
• rim-locators: This would be used to convey Reference Value CoRIM URI path

It was also agreed for the profile to name all the optional NON verifiable claims included 5 integrator-defined claims. The choice will constraint on the token max size, and favor interoperability.