Partial profile and `eat_profile`

[steven-bellock]

The OCP EAT profile says

With respect to RFC 9711, it is a partial profile...

while RFC 9711 says

The "eat_profile" claim MUST NOT be used to identify partial profiles.

RFC 9711 describes profiles as

For a "full" profile, the receiver will be able to decode and verify every possible EAT sent when a sender and receiver both adhere to it. For a "partial" profile, there are still some protocol options left undecided.

[steven-bellock]

@gmandyam do you agree that, currently, this profile is "partial" and not "full"?

[fdamato]

I`m a bit skeptical, because while we allowing for option claims, those should not prevent a verifier to perform full appraisal policy. Concise Evidence is where ALL the claims that have to be corroborated against Reference Measurement are

[steven-bellock]

We need to consult with @gmandyam and see. I think the eat_profile claim is valuable, but we also have to honor the EAT specification.

[gmandyam]

Sorry I am late in responding. The distinction between full and partial profiles was originally put in place to differentiate between profiles that could provide assurances of interoperability, versus ones that did not (e.g. profiles that could be extended indefinitely with claims yet to be defined).

a) The guidance in https://datatracker.ietf.org/doc/html/rfc9711#name-full-and-partial-profiles states "Full profiles do not need to require the receiver to fully handle every claim in an EAT from a complying sender." This addresses the issue of optional claims in the OCP EAT profile. As long as the receiver (verifier) does not reject the attestation because optional claims are present then the requirement for full profile is met. I would recommend adding appropriate guidance on optional claims in the 'Scope' section (e.g. "The verifier must accept tokens with optional claims", or removing the optional claims from the profile.

b) Regarding crypto algorithms, once again interop is what is important to distinguish full from partial profiles. If verifiers can support only a subset of what attesters will send then there is no interop. The 'Scope' section as written is accurate in this regard: "With respect to RFC 9711, it is a partial profile, as it allows the integrator to choose the algorithm to use for signing the statement".

Is this the intention though? Will the OCP eventually establish an interop program for their SPDM extensions? If so, it seems to me that a set of common algorithms should be supported by compliant receivers.

c) Side issue (nor directly related to profiles). Continuing with interop, one thing full profiles don't really address is CBOR encoding - see ((https://datatracker.ietf.org/doc/html/rfc8949#section-4.2). Related to my question above in b), if interop testing isn't planned then the encoding doesn't need to be specified. If deterministic encoding is desired then it should be added to the OCP profile.

[fdamato]

Thanks Giri.
a) It should be ok to add a note "The verifier must accept tokens with optional claims"
b) OCP Attestation Specification prescribe a list of algorithms which will be in scope for the profile. So It makes sense to add a section in the profile and mandate algorithms in scope
c) Interoperability is one of the main goals. The profile prescribe the encoding of EAT as CWT, therefore CBOR

[gmandyam]

Interoperability is one of the main goals. The profile prescribe the encoding of EAT as CWT, therefore CBOR

Sorry, I should've been more clear. See https://datatracker.ietf.org/doc/html/rfc9711#name-cbor-preferred-serializatio. The profile 'should' specify if a preferred serialization is required. It is not a MUST requirement, which means that if one follows the RFC 9711 guidance then a full profile can be defined without mentioning serialization. But if that occurs then interop may not be achievable.

I think this is avoided by adding a statement to the effect "Compliant attesters and verifiers MUST conform to the encoding guidance provided in https://datatracker.ietf.org/doc/html/rfc8949#section-4.2.1".

[steven-bellock]

Thanks @gmandyam. From a high level it looks like, with additional text, we will be able to satisfy the criteria for a full profile, although I have a lot of questions still.

[steven-bellock]

• Use of JSON, CBOR, or Both
  • CBOR only.
• CBOR Map and Array Encoding
• CBOR String Encoding
• CBOR Preferred Serialization
• CBOR Tags
  • Yes, the CWT tag should be mandatory. In particular the EAT should be as self-describing as possible. See EAT - Consider requiring the "Self-described CBOR" tag #51.
• COSE/JOSE Protection
  • COSE_Sign1 is required.
  • Can also forbid COSE encryption and MAC of the CWT. Transport encryption can be employed if necessary. This has the side effect of encouraging attestation evidence to not violate privacy considerations.
• COSE/JOSE Algorithms
  • Can leverage the OCP Attestation subset of SPDM algorithms, provided they are recognized by COSE.
• Detached EAT Bundle Support
  • In the spirit of a self-contained object, detached bundles will be forbidden.
• Key Identification
  • Use x.509 certificate chains.
• Endorsement Identification
• Freshness
• Claims Requirements
  • This profiles leverages TCG CoEv, which is something like a new claim.