IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 19 August 2026 15:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 5B34912C53BE9 for <rats@mail2.ietf.org>; Wed, 19 Aug 2026 08:55:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787154921; bh=XiL4qYyY9RdcMRCypAPoLDT6tF/VB547/U5ts1wqWJY=; h=From:To:Subject:In-Reply-To:References:Date; b=g4gbZavAZEhD794ddoZiPG/W2JVJiz1FEhJpzE2VBwW5PEPvaGv7wq8mU5sdUlYVO VW11n+jx0pQff5XoiW63kB6ImfmBI55Fx3avyXY40OD0h32JjrVQ01Qxbt/20vx1xb LFAim0nOIlpZf0xLrlO+gpARvZZNK1T4bTPtyOI4=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=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=sandelman.ca
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 I7kNbH87x-tZ for <rats@mail2.ietf.org>; Wed, 19 Aug 2026 08:55:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (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 CC43F12C53BE1 for <rats@ietf.org>; Wed, 19 Aug 2026 08:55:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1917C18011; Wed, 19 Aug 2026 11:55:14 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavis, port 10024) with LMTP id ueylCOBrYszU; Wed, 19 Aug 2026 11:55:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1787154912; bh=TfIZpmWTUroMeqAZhLWzcFTVW+YHNX24/UJIEItpcmI=; h=From:To:Subject:In-Reply-To:References:Date:From; b=aKi2jkds2eomyPAdPV0581STJvOuQnZcN0KQaYvnidAEIlGcm8xsOKwdxAuzNmWyw KxNzhWAtEn8ac7HKc2szldy/a1rJ0PxeAad7H9YrRzdDccbfFGrP0WU0DcGlktOHaH PoOkwFjaQgPzH/CoyJnEFJtjpQE3Fo6E0A1sllU5QlJMLKooZuB9UAG4qkMgHFBtjl WuXzHwF1arF6+Ck8OaNKGPkAWFobcG2SBe34biw1cfkNbTi3Pg15XtP8khbJuXlVJd 3b0xdiNav2Teq3txpZmlNU+m+94t4CgtK0IafwTUQj/SQBZvrYD3sUNnx4Pc8VlnWI suT1l7nfYzIgQ==
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 058831800F; Wed, 19 Aug 2026 11:55:12 -0400 (EDT)
Received: from obiwan.sandelman.ca (obiwan.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0171C182; Wed, 19 Aug 2026 11:55:12 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Henri Sirkkavaara <hello@vaara.io>, rats <rats@ietf.org>
In-Reply-To: <jHcEen5I2mG6YKeIbiCZe_xUiwaOO034RZaM7s-G_pXJEyb4HGDzqRXs91iySfuZX7tlcHFTZsN6D_4Xr1IecTKab0OW6TDWuKNsbLao-QI=@vaara.io>
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> <jHcEen5I2mG6YKeIbiCZe_xUiwaOO034RZaM7s-G_pXJEyb4HGDzqRXs91iySfuZX7tlcHFTZsN6D_4Xr1IecTKab0OW6TDWuKNsbLao-QI=@vaara.io>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; Emacs 30.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 19 Aug 2026 11:55:11 -0400
Message-ID: <4634.1787154911@obiwan.sandelman.ca>
Message-ID-Hash: U7V7KTHF5D23XVYUAMGJ2AGDQBPTZHFO
X-Message-ID-Hash: U7V7KTHF5D23XVYUAMGJ2AGDQBPTZHFO
X-MailFrom: mcr+ietf@sandelman.ca
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: [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/tBdHoeo5yz4k3vSfYjOc_ojXK9U>
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>

Henri Sirkkavaara <hello@vaara.io> wrote:
    > 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.

1) That's an RP with a co-located Verifier.
2) That's what we had pre-9334, and it encourages monopolies.

    > 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.

It sounds like UCCS, but it also sounds like everything that people were
worried that UCCS would be applied to insecurely.

It doesn't sound like remote attestation at all to me.


--
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 **

v2.46.0 | Report a Bug | By Email | System Status