Subject: [Rats] Re: qualifying "confidential computing" (was: Re: Re: Threat model and properties for remote attestation)
From: Henri Sirkkavaara <[email-masked]>
To: Michael Richardson <[email-masked]>
Cc: rats <[email-masked]>
Date: Wed, 19 Aug 2026 13:55:23
List-Id: Remote ATtestation procedureS <rats.ietf.org>

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 <[email-masked]> wrote:

> 
> Henri Sirkkavaara <[email-masked]> 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 <[email-masked]>   . 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 -- [email-masked]
> To unsubscribe send an email to [email-masked]
> 

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