Re: [Teep] Protocol issue #213: full EAT CDDL example in TEEP Protocol

Hi,

This is a note for the people who were not at the hackathon at ietf114.

> I am, however, not convinced that hash-entries is needed, since it seems to
> me that that is what EAT's "Software Version Claim" (sw-version-type)
> is designed to solve.
>
> If that is not sufficient for some reason, then in my view either we should
> provide feedback on that part of the EAT spec, or propose an additional EAT
> claim.  However, my personal opinion is that the current EAT claim
> should be sufficient.

The discussion at the hackathon moved to
https://github.com/ietf-teep/teep-protocol/issues/221 and we decided
to use the manifests claim for the purpose.

Akira

On Fri, Jul 8, 2022 at 10:09 AM Dave Thaler
<dthaler=40microsoft.com@dmarc.ietf.org> wrote:
>
> https://github.com/ietf-teep/teep-protocol/issues/213 proposes changing the attestation-payload format to include a type.   I explained in the thread about issue #214 how I think the attestation-payload-format field should be used instead, with the fix in PR #216.
>
> However, issue 213 also proposes another change that I'd like to discuss here:
>
> > Add hash-entries in teep-evidence
> > As discussed at Reliably getting TEE properties #189, Verifiers in the back of TAM
> > or TAM would require the system information and the hash values of TEE-OS or
> > equivalent software to verify it.
> > We add the hash-entries in TEEP's EAT sample to convey such software's
> > information in evidence.
> > [...]
> > teep-evidence = {
> >   ? ueid-label => ueid-type,
> >   ? oemid => oemid-pen / oemid-ieee / oemid-random,
> >   ? class-identifier => RFC4122_UUID,
> >   ? hardware-model-label => hardware-model-type,
> >   ? hardware-version-label => hardware-version-type,
> >   ? sw-name-label => tstr,
> >   ? sw-version-label => sw-version-type,
> >   ? nonce-label => nonce-type / [ 2 * nonce-type ],
> >   ? hash-entries => [ + hash-entry ] ; hash value of TEE or device
> > }
>
> I am, however, not convinced that hash-entries is needed, since it seems to
> me that that is what EAT's "Software Version Claim" (sw-version-type)
> is designed to solve.
>
> If that is not sufficient for some reason, then in my view either we should
> provide feedback on that part of the EAT spec, or propose an additional EAT
> claim.  However, my personal opinion is that the current EAT claim
> should be sufficient.
>
> Dave
>
> _______________________________________________
> TEEP mailing list
> TEEP@ietf.org
> https://www.ietf.org/mailman/listinfo/teep