It seems to me there was some confusion between what /currently/ exists in security considerations and what /should/ exist there. We were imagining the latter.

On 21.07.25 01:11, Eric Rescorla wrote:


On Sun, Jul 20, 2025 at 3:51 PM Thomas Fossati <thomas.foss...@linaro.org> wrote:

    On Mon, 21 Jul 2025 at 00:12, Eric Rescorla <e...@rtfm.com> wrote:

    This specification must define certain security properties that the
    execution environment may reasonably provide, e.g. the
    non-exportability of key material, the localisation of the TLS
    endpoint within the isolated environment, and the inability to act as
    an oracle, among others.


Yes. The point of this comment in my review is that I do not believe
that the specification does this.

Oh for sure. I don't know where the confusion came in. But the proponents never meant to say that what exists in security considerations in v-02 already does this. It will be heavily revised as we proceed with the draft. We thought we were discussing what /should/ ultimately exist in the security considerations.


    These properties must then be translated by the appraisal policy on
    the RP side into concrete checks against the evidence supplied by the
    attester.
    The TLS protocol is not concerned with how this is realised, as it
    depends on the architecture of the hardware/software execution
    environment and the specific manner in which the TCB security metrics
    are exposed via evidence. I previously referred to this as "RATS
    territory".


Yes, I agree.

Thanks for confirmation.

Usama


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to