Re: [Teep] Zaheduzzaman Sarker's No Objection on draft-ietf-teep-otrp-over-http-14: (with COMMENT)

[Zaheduzzaman Sarker <[e-mail]>]

On 2023-03-25, 12:12, "Dave Thaler" <[e-mail]> wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for working on this specification. I haven't find any TSV related issues
> in this specification in my review.
>
> I have comments/questions that I believe would improve the document if
> addressed -
>
> # it says -
>
>    and a "Trusted Application Manager (TAM)" on the server side) SHOULD
>    themselves run inside a TEE
>
>   why is it necessary to use normative language here? is this something this
>   spec describing first for the TEEP architecture? It is however not the
>   intention of this specification to define TAM placement, or?

Changed to "might or might not":

   To be secure against malware, a TEEP implementation (referred to as a
   TEEP "Agent" on the client side SHOULD run inside a TEE, and a
   "Trusted Application Manager (TAM)" on the server side) might or
   might not run inside a TEE.

Hmm, this does not really address the question. This specification is not about giving recommendation on where the Agent should run, is it? I didn’t find any such assumption imposed or required for the rest of the specification to be realized, have I missed anything?  If we think this is a nice thing to say, then I would suggest rewriting as

To be secure against malware, a TEEP implementation (referred to as a
   TEEP "Agent" on the client side is expected to run inside a TEE, and a
   "Trusted Application Manager (TAM)" on the server side) might or
   might not run inside a TEE.


> # it says -
>
>      Since POST responses without explicit freshness information are
>      uncacheable (see Section 9.3.3 of [RFC9110]), no Cache-Control header is
>      needed.
>
>   Should this not say -
>
>      Since POST responses without explicit freshness information are
>      uncacheable (see Section 9.3.3 of [RFC9110]), hence Cache-Control
> header
>      MUST NOT be used.
>
>   I.e. use normative language to avoid the use of that particular header? also
>   explains if a Cache-Control header would generate error.

Updated.

Thanks.

//Zahed