Return-Path: X-Original-To: rats@mail2.ietf.org Delivered-To: rats@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8FE78122C0F1B for ; Mon, 3 Aug 2026 08:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785772293; bh=y1pK8wfKOqvSZ4/DSaKgpOpHvtsuS05jJBwagVD8RCg=; h=From:Subject:Date:To; b=wbJi5otR+Un+yRmoSsnXB/XDLjD2i1hlVndUg5XZBJL5CqYKm3/t16EwNg4/fjQnC suwYFAQA7L8ssnUTfQGs/gtwPenSxD37Mm6R4bjHPiBu6hUUSP0M97j9j0OpVgIUru /jsIbnDQiIzMi+VjpcDlnxMkQC7IPUXuEhYa6mV4= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_SBL_CSS=3.335, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=yuthent.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDOqn0BYuvsm for ; Mon, 3 Aug 2026 08:51:33 -0700 (PDT) Received: from out-05.pe-bsn.jellyfish.systems (out-05.pe-bsn.jellyfish.systems [66.29.159.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id DD05C122C0F11 for ; Mon, 3 Aug 2026 08:51:32 -0700 (PDT) Received: from MTA-10-1.privateemail.com (unknown [10.50.14.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by BSN-01.privateemail.com (Postfix) with ESMTPS id 4hDLkg2QQJz3hhTB for ; Mon, 3 Aug 2026 11:51:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yuthent.com; s=default; t=1785772283; bh=y1pK8wfKOqvSZ4/DSaKgpOpHvtsuS05jJBwagVD8RCg=; h=From:Subject:Date:To:From; b=WQKddA1NXLBUAXwZYgiaKHozX0sz4rPKpDPpV36aX08HtLxhdSNAi5MuKPWWYeeK8 0HXj2GqdtTxqeRrUeNNP2NcoHAb4NHMLEPxN/4S+iBCttDoEQPS3fDCaVh/FLCjebq kgYuUircc/fC7Jg7XEY34tXW38btCHeHVMyCPXgRKld9QnpQn6233BcHT2aytUS7mW MrqAJFaSWviN+8tBYJDYT+BZxkNCPdSi66mNjnIqR/WpzX6LLfIly3xIkduw/79E7Z CPLkLs8tcGms99Do0Um+Fc01NDC/45N0jW47uyb0Ued4U45ZxEjBVrzZuWoYCbPiMz XjVNGvysP1zVg== Received: from mail.privateemail.com (K8S-PROD-WORKER-03 [79.177.159.53]) by mta-10.privateemail.com (Postfix) with ESMTPA id 4hDLkf5rV0z3hhTD for ; Mon, 3 Aug 2026 11:51:22 -0400 (EDT) From: Mohamad Khalil Yossif Content-Type: multipart/alternative; boundary="Apple-Mail=_B0808EE9-A5CF-4F5E-B58C-DF1B80EEA134" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Message-Id: <07D403F3-5F1F-45C3-BA63-9321DD2B92CA@yuthent.com> Date: Mon, 3 Aug 2026 18:51:10 +0300 To: rats@ietf.org X-Mailer: Apple Mail (2.3864.600.51.1.1) Message-ID-Hash: 3BDDS3ZSOT4XXGEL66OXFY7RGPJSMXHS X-Message-ID-Hash: 3BDDS3ZSOT4XXGEL66OXFY7RGPJSMXHS X-MailFrom: mohamad@yuthent.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BRats=5D_Re=3A_Foundational_document_about_TEE_capabilities?= List-Id: Remote ATtestation procedureS Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_B0808EE9-A5CF-4F5E-B58C-DF1B80EEA134 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > Ionut, all, > > On your question - no, I think you have the context right, and I want > to add one thing from having tried to write the assumption down. > > You put the example as "Can this key be extracted from the TEE?" The > form I needed was adjacent: was the signing operation gated by a > contemporaneous user-verification event. Different property, same > structure, and it failed in the same place - not because the answer > was unknown, but because it was two answers. > > What I could not write was a fact. What I could write was a rule for > determining which answer applies: > > Where the platform attestation conveys the property, a Verifier > MUST cross-check the claim against it and MUST NOT accept the claim > as self-asserted when the cross-check was available. > > Where the attestation surface does not convey it, the Verifier MUST > NOT treat the property as attested. > > That rule needs no SDO to have defined what a TEE guarantees. It > needs only that a Verifier can tell, from the attestation in front of > it, whether the property is carried. Everything downstream follows > from that determination rather than from the guarantee itself. > > Which is why I read Jeremy's point as narrower than a veto. The > security-level claim failed because it tried to agree on what the > levels contain. What I needed was not the contents - it was the > ability to distinguish a claim that has been checked against > something from one that has not. That distinction is protocol-level, > it does not require agreement on any TEE's actual guarantees, and it > is the part that is missing today. > > So on your two-level framing: I would put it slightly differently. > The SDO documents define what the guarantees are. What is missing is > not a layer above those - it is a vocabulary for the case where the > document exists and the attestation surface still does not carry the > field the protocol needs. That case is common, and today every > protocol author solves it privately and inconsistently. > > The concrete failure mode, since it is the reason I care: both > branches produce a token that passes signature verification and looks > identical on the wire. A relying party that cannot tell which branch > it is on has no way to know it is relying on a documented trust > assumption rather than on verification. It is not that the assumption > is unacceptable - it is that it is invisible. > > Ned's reputation point and Michael's public-norms point are, I think, > the same observation from two directions. Reputation is a reasonable > fallback. Being unable to tell that you are on the reputation branch > is not. > > Whether that belongs in SEAT, in a RATS document, or nowhere, I do > not have a view worth much - I have written one profile, not a > standard. But if it is written anywhere, my suggestion is that it > carry the determination procedure rather than the guarantees. > > Separately, and still open from my thread here last week, since it is > the same kind of question and this list is where it belongs. > > Thomas Fossati's review sent me back to Section 4.2.1.1, and I think > I may have the wrong claim rather than the wrong derivation. The value > my profile puts in ueid is re-derived when the device identifier is > regenerated - a factory reset, or on iOS the loss of the Keychain > entry. Section 4.2.1.1 says a UEID is permanent and MUST NOT change > for a given entity. Section 4.2.2 describes a value that MAY change on > entity life-cycle events, gives factory reset as an example, and lets > a profile specify the triggering events and carry a label. > > Read that way, a per-deployment value that changes on a life-cycle > event is an SUEID and not a UEID. I did not see it when I wrote the > profile. > > I have a revision built and held on that question. If the permanence > requirement is meant to bite here, I would rather move the claim once, > deliberately, than ship a revision that corrects a derivation and > leaves the claim selection wrong. A one-line view from anyone who was > in the room for 4.2.1 and 4.2.2 would settle it. > > Mohamad Khalil-Yossif > > draft-yossif-psea > https://datatracker.ietf.org/doc/draft-yossif-psea/ > draft-yossif-agent-mandate-problem > https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/ > draft-yossif-enrollment-problem > https://datatracker.ietf.org/doc/draft-yossif-enrollment-problem/ --Apple-Mail=_B0808EE9-A5CF-4F5E-B58C-DF1B80EEA134 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Ionut, all,

On your question - no, I think you have the context = right, and I want
to add one thing from having tried to write the = assumption down.

You put the example as "Can this key be = extracted from the TEE?" The
form I needed was adjacent: was the = signing operation gated by a
contemporaneous user-verification event. = Different property, same
structure, and it failed in the same place - = not because the answer
was unknown, but because it was two = answers.

What I could not write was a fact. What I could write = was a rule for
determining which answer applies:

  Where the platform = attestation conveys the property, a Verifier
  MUST cross-check the claim = against it and MUST NOT accept the claim
  as self-asserted when the = cross-check was available.

  Where the attestation = surface does not convey it, the Verifier MUST
  NOT treat the property as = attested.

That rule needs no SDO to have defined what a TEE = guarantees. It
needs only that a Verifier can tell, from the = attestation in front of
it, whether the property is carried. = Everything downstream follows
from that determination rather than = from the guarantee itself.

Which is why I read Jeremy's point as = narrower than a veto. The
security-level claim failed because it = tried to agree on what the
levels contain. What I needed was not the = contents - it was the
ability to distinguish a claim that has been = checked against
something from one that has not. That distinction is = protocol-level,
it does not require agreement on any TEE's actual = guarantees, and it
is the part that is missing today.

So on = your two-level framing: I would put it slightly differently.
The SDO = documents define what the guarantees are. What is missing is
not a = layer above those - it is a vocabulary for the case where = the
document exists and the attestation surface still does not carry = the
field the protocol needs. That case is common, and today = every
protocol author solves it privately and = inconsistently.

The concrete failure mode, since it is the reason = I care: both
branches produce a token that passes signature = verification and looks
identical on the wire. A relying party that = cannot tell which branch
it is on has no way to know it is relying on = a documented trust
assumption rather than on verification. It is not = that the assumption
is unacceptable - it is that it is = invisible.

Ned's reputation point and Michael's public-norms = point are, I think,
the same observation from two directions. = Reputation is a reasonable
fallback. Being unable to tell that you = are on the reputation branch
is not.

Whether that belongs in = SEAT, in a RATS document, or nowhere, I do
not have a view worth much = - I have written one profile, not a
standard. But if it is written = anywhere, my suggestion is that it
carry the determination procedure = rather than the guarantees.

Separately, and still open from my = thread here last week, since it is
the same kind of question and this = list is where it belongs.

Thomas Fossati's review sent me back to = Section 4.2.1.1, and I think
I may have the wrong claim rather than = the wrong derivation. The value
my profile puts in ueid is re-derived = when the device identifier is
regenerated - a factory reset, or on = iOS the loss of the Keychain
entry. Section 4.2.1.1 says a UEID is = permanent and MUST NOT change
for a given entity. Section 4.2.2 = describes a value that MAY change on
entity life-cycle events, gives = factory reset as an example, and lets
a profile specify the = triggering events and carry a label.

Read that way, a = per-deployment value that changes on a life-cycle
event is an SUEID = and not a UEID. I did not see it when I wrote the
profile.

I = have a revision built and held on that question. If the = permanence
requirement is meant to bite here, I would rather move the = claim once,
deliberately, than ship a revision that corrects a = derivation and
leaves the claim selection wrong. A one-line view from = anyone who was
in the room for 4.2.1 and 4.2.2 would settle = it.

Mohamad Khalil-Yossif

  draft-yossif-psea
  = https://datatracker.ietf.org/doc/draft-yossif-psea/
  = draft-yossif-agent-mandate-problem
  = https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
  = draft-yossif-enrollment-problem
  = https://datatracker.ietf.org/doc/draft-yossif-enrollment-problem/



= --Apple-Mail=_B0808EE9-A5CF-4F5E-B58C-DF1B80EEA134--