Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

[Giridhar Mandyam <[e-mail]>]

Thanks Eric and Ned.  I believe we are getting closer to a resolution, and I think that the source of varied opinions on the use of sec level is based on a difference in terminology between the ARM/RISC-V and TPM (x86) worlds.  

Note that other SDO's such as FIDO which make use of remote attestation don't even use the term endorsement except in the context of TPM (specifically EK in https://www.w3.org/TR/webauthn-2/#sctn-defined-attestation-formats).  In-band transmission of cert-chains (e.g. x5c in https://www.w3.org/TR/webauthn-2/#sctn-packed-attestation) may constitute an endorsement, but I personally did not make such a correspondence until endorsement was defined in the RATS arch. doc, but the FIDO specs pre-dated the RATS work.

Let me see if I can summarize what is being suggested, and see if there is agreement.

a) Sec level is an endorsement.  The claim name and standard text should need to be modified to indicate this clearly.

b) Sec level can be sent in the context of the attestation token.  Note that this is important, as with some EAT deployments that I have worked on there is no easy way for a verifier to obtain the endorsement other than in-band.  Moreover, data efficiency is important (particularly for power-limited attesters) and therefore one-shot attestation and verification is a requirement (i.e. it should not take 2 separate token transmissions for the verifier to obtain the endorsement from the device).

Now to where there may be a difference in understanding:

> There is also the issue of ensuring that an indirectly provided Endorser claim is legitimately bound to the exact type of Attester making parallel EAT 
claims.  So both sets of signed Evidence would need to include information that can be assessed to evaluate whether the relationship between the two signed blobs is legitimate.

I think the sec level claim can be signed along with other attestation evidence claims by the attestation keypair.  It does not need to be signed separately and with a manufacturer keypair.  This is because the manufacturer in all likelihood is the CA, and therefore the cert chain that corresponds to the attestation keypair is already signed using the manufacturer root.  In other words, the relationship requirement as stated above should be met.  If an RP requires a 3rd-party endorsement for the level of security assurance provided by the entity, then they can ignore this claim as part of their appraisal policy.    

I would also note that by signing with the attestation keypair that anti-replay protection is possible (which may be important for endorsements depending on appraisal policy).  I don't see a similar protection in https://trustedcomputinggroup.org/wp-content/uploads/IWG_Platform_Certificate_Profile_v1p1_r19_pub_fixed.pdfm but it might be there.

-Giri



-----Original Message-----
From: Eric Voit (evoit) <[e-mail]> 
Sent: Friday, June 3, 2022 2:37 PM
To: Giridhar Mandyam <[e-mail]>; Smith, Ned <[e-mail]>
Cc: [e-mail]
Subject: RE: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

> From: Giridhar Mandyam, June 3, 2022 4:56 PM
~
> So does this mean that security level as an EAT would be OK if conveyed as a
> X.509 and signed by a manufacturer key that is distinct from the attestation 
> key?

As this is just an indirect way of getting the information from an endorser, 
this would be fine.   I would prefer the more accurate name of 
"endorsed-security-level" to make it completely clear to a Relying Party that 
such a claim cannot come from Attesters or Verifiers.

> Note that  the EAT attestation key itself can be signed by the manufacturer
> already (see https://datatracker.ietf.org/doc/html/draft-ietf-cose-x509-08).

There is also the issue of ensuring that an indirectly provided Endorser claim 
is legitimately bound to the exact type of Attester making parallel EAT 
claims.  So both sets of signed Evidence would need to include information 
that can be assessed to evaluate whether the relationship between the two 
signed blobs is legitimate.

Eric