To: Michael Richardson <mcr+ietf@sandelman.ca>
From: Henri Sirkkavaara <hello@vaara.io>
Message-ID: 
 <jHcEen5I2mG6YKeIbiCZe_xUiwaOO034RZaM7s-G_pXJEyb4HGDzqRXs91iySfuZX7tlcHFTZsN6D_4Xr1IecTKab0OW6TDWuKNsbLao-QI=@vaara.io>
In-Reply-To: <18362.1786822018@obiwan.sandelman.ca>
References: 
 <SN6PR04MB4816FEA3B54F9FB75E2C43BCC6DA2@SN6PR04MB4816.namprd04.prod.outlook.com>
 <CAHu=PL0hbQQJDb__SixNxjCaLnYJtCRxod0xM5tQHb0H71++Rg@mail.gmail.com>
 <CAHxYnaM8hTFrTVOes7oRPB1OfR9z6eEA2G=hfWz+n4hRqUycBQ@mail.gmail.com>
 <x-zrBdw00QYsru0IX_AlJ8MI2O_wo8v7wMAJAgU8LJqO7N2Dy2cmrAKwrpooGMfJDA0mTFHdRI6sqiTitgZPQeh_HiR-t4RdZvk15kUQUG4=@vaara.io>
 <CAHxYnaPsWxeq_0Cf3KSVp-O59dEAtYj1VtBsG2c=+vpt9+w8gQ@mail.gmail.com>
 <giyMaok_sM5hOnLqdAikzspcQdPN4ZXGJYbvdmUWdrz-eZmzSB8NBoWZER70CPIZyvlVp_ayje0OaNDuhcxw-pru7JXD_QFk4DGhecyAWt4=@vaara.io>
 <18362.1786822018@obiwan.sandelman.ca>
Feedback-ID: 189084408:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 4V4JN5SPQ46JU2IFGLATEVMWCKJPUY5G
CC: rats <rats@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BRats=5D_Re=3A_qualifying_=22confidential_computing=22_=28was=3A?=
	=?utf-8?q?_Re=3A_Re=3A_Threat_model_and_properties_for_remote_attestation?=
	=?utf-8?q?=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rats/kgjoJwLS-SaHzrUan1GWTZq03sM>
Date: Wed, 19 Aug 2026 13:55:23 

Michael,

You are right on both counts.

What we emit is not an EAR in the serialization sense. EAR is an EAT token =
serialized as JWT or CWT, and ours is a keyless map. The accurate descripti=
on is an unprotected claims set carrying EAR and AR4SI claims, the JSON ana=
logue of the UCCS construct in RFC 9781. I overstated the conformance by ca=
lling it an EAR, and I will fix the wording in the module and the spec.

Passport is also wrong. In passport the Verifier signs an Attestation Resul=
t and the Attester carries it to the Relying Party, so the RP accepts the V=
erifier's authority. In our flow there is no signed Result to carry. The RP=
 recomputes the record's own signature and the digest binding itself, which=
 makes it its own Verifier over supplied Evidence. That is a third shape, a=
nd I should have described it instead of reaching for the nearest named mod=
el.

The property I was after survives the correction. No assertion in the chain=
 has to be accepted on a signer's authority, because the RP can recompute a=
ll of it. My mistake was claiming a standards-defined object for that prope=
rty.

There are two honest routes from here. Keep it unprotected and stop calling=
 it an EAR, or sign it as a real EAR and keep the digest binding underneath=
, where the signature becomes a convenience rather than the trust root. I a=
m taking the first, because signing reintroduces the assertion I was trying=
 to remove.


On Saturday, August 15th, 2026 at 22:27, Michael Richardson <mcr+ietf@sande=
lman.ca> wrote:

>=20
> Henri Sirkkavaara <hello@vaara.io> wrote:
>     > Our EAR is deliberately not signed. It is the unprotected JSON
>     > serialization, keyless, and it references the signed execution reco=
rd
>     > by digest. So the RP does not check a Verifier signature over the A=
R at
>     > all. It recomputes the record's own signature and the digest bindin=
g,
>     > and the EAR functions as a standards-shaped view of a verdict whose
>     > authority lives one layer down. If someone hands you a modified EAR=
,
>     > nothing about it verifies or fails on its own terms; the question j=
ust
>     > moves to the record it points at, which does carry a signature and =
does
>     > fail.
>=20
> I don't know what this object is, but it does not sound like AR, and I do=
n't think you
> are describing passport model at all.
>=20
>     > That is the security property I am after. Not "the Verifier can be
>     > offline", which Passport already gives you, but "there is no assert=
ion
>     > in the chain that the RP has to accept on someone's authority rathe=
r
>     > than recompute". A signed AR is still an assertion, however good th=
e
>     > signer. Removing the signature from the AR and pushing the binding =
into
>     > a content-addressed reference means the RP's trust anchor is the
>     > evidence rather than the appraiser.
>=20
> That sounds like the pre-9334 model of RPs that are also Verifiers, which
> creates all sorts of hidden cartels, and challenges interoperability.
> That's a fine thing to do if the business relationships =3D> the trust
> relationships work for you.
>=20
> The whole things sounds like it's gonna be privacy violating by default i=
f
> this record of the verdict has to include identifying evidence.  That's n=
ot
> always a concern: for instance I don't expect nuclear fission plants to h=
ave
> privacy, when they present evidence that they were recently inspected.
> (Nor do I expect the inspector to be personally identified, "Qualified
> Agency's Inspector 14" is enough)
>=20
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T consul=
ting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>=20
> **       My working hours and your working hours may be different.       =
  **
> ** Please do not feel obligated to reply outside your normal working hour=
s **
> _______________________________________________
> RATS mailing list -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org
>=20

Henri Sirkkavaara
Vaara -=C2=A0Runtime execution layer for AI agents
Built to see over the noise.
vaara.io
Helsinki, Finland