[Rats] Re: qualifying "confidential computing" (was: Re: Re: Threat model and properties for remote attestation)

Henri Sirkkavaara <hello@vaara.io> Wed, 19 August 2026 13:55 UTC

Return-Path: <hello@vaara.io>
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 2532412C42D08 for <rats@mail2.ietf.org>; Wed, 19 Aug 2026 06:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787147723; bh=I4uT32EVyk0yKnAYwlnSKbBu5Pm6PQ+BIlqSrDH8zbU=; h=Date:To:From:Cc:Subject:In-Reply-To:References; b=WKp9vVnjGT1/ruE2O/n9gEoV8bnLUvYn1OW6JSBiHWK0fxufjAhpZ+4cY7j/fBsWd kd/9FkbvR2b2T/M6Ito3Qqpws6BP8i4d36R7TKed9oUFQz1kH5WW4XmeYrfrxIqKvC tZMpr0uKl2MJwQT3hy6KLHD4jPYgg429JdOF0Iyw=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=vaara.io
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 OElRGJIFFt4y for <rats@mail2.ietf.org>; Wed, 19 Aug 2026 06:55:22 -0700 (PDT)
Received: from mail-4323.protonmail.ch (mail-4323.protonmail.ch [185.70.43.23]) (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 48CC612C42D03 for <rats@ietf.org>; Wed, 19 Aug 2026 06:55:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vaara.io; s=protonmail; t=1787147721; x=1787406921; bh=00C/5hqzw7+78OvsUIQWYBWx7tq4AcT4nlpW8So1eJo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=dic58UNAcIuZ1ntFm4BXstgEspetBaueqpNwziCiJVurT8ycTLRopbiGAUi2bex2s Jyj8NqPI5XWv9cW4OHaZOSpaa/FKAK/Gc/fu9L6XKCgOpLaVS6v/tnc5zSaM4i9B7A DJ2v43blhPmXCeIA3yuNZCVBzr9gvZF6s5faFbTZH+xQFq91YyRW2uf1IzQogRbZlw jkvhDwuY9hvryDVN6+X8uQXEpXY03T4IIUvCPUbgy3xCSrPUvtPeMph6qnvPpZvv/A unP2UalVglmmW0GXeZFro9ur+TbHl1+yMr2bNpajeespaUYf+5WkG+7GC2bwRIVkzL FnwUoQMgbIn4A==
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
X-Pm-Message-ID: ec6063ff485dbff3fc7847e4d2de84ecab85210b
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 4V4JN5SPQ46JU2IFGLATEVMWCKJPUY5G
X-Message-ID-Hash: 4V4JN5SPQ46JU2IFGLATEVMWCKJPUY5G
X-MailFrom: hello@vaara.io
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
CC: rats <rats@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Rats] Re: qualifying "confidential computing" (was: Re: Re: Threat model and properties for remote attestation)
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/kgjoJwLS-SaHzrUan1GWTZq03sM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>
Date: Wed, 19 Aug 2026 13:55:23 -0000
X-Original-Date: Mon, 17 Aug 2026 11:44:27 +0000

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 description is an unprotected claims set carrying EAR and AR4SI claims, the JSON analogue of the UCCS construct in RFC 9781. I overstated the conformance by calling 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 Result and the Attester carries it to the Relying Party, so the RP accepts the Verifier'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, and I should have described it instead of reaching for the nearest named model.

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 all of it. My mistake was claiming a standards-defined object for that property.

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 am 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@sandelman.ca> wrote:

> 
> 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 record
>     > by digest. So the RP does not check a Verifier signature over the AR at
>     > all. It recomputes the record's own signature and the digest binding,
>     > 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 just
>     > moves to the record it points at, which does carry a signature and does
>     > fail.
> 
> I don't know what this object is, but it does not sound like AR, and I don't think you
> are describing passport model at all.
> 
>     > That is the security property I am after. Not "the Verifier can be
>     > offline", which Passport already gives you, but "there is no assertion
>     > in the chain that the RP has to accept on someone's authority rather
>     > than recompute". A signed AR is still an assertion, however good the
>     > 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.
> 
> 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 => the trust
> relationships work for you.
> 
> The whole things sounds like it's gonna be privacy violating by default if
> this record of the verdict has to include identifying evidence.  That's not
> always a concern: for instance I don't expect nuclear fission plants to have
> 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)
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> **       My working hours and your working hours may be different.         **
> ** Please do not feel obligated to reply outside your normal working hours **
> _______________________________________________
> RATS mailing list -- rats@ietf.org
> To unsubscribe send an email to rats-leave@ietf.org
> 

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