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

[Henri Sirkkavaara <[e-mail]>]

Michael,

I answered your first point and went straight past the other two. Correcting that.

You had already named the shape and I called it a third one. It is the pre-9334 model of a Relying Party that is also its own Verifier, which is your label and the accurate one. The cost you attach to it is real. An RP that appraises for itself does not interoperate with one that does not, and the trust relationship has to exist beforehand for that to be tolerable. In our deployments the relying party is the accountable party and wanted to stop depending on an appraiser, so the business relationship carries it. You identified that as the condition before I did, and I should have said yes to it instead of coining a term.

On privacy, the record does not carry evidence. It carries a digest. evidenceRef.digest pins the normalized evidence and the envelope commits to it under signature, so whether anything identifying exists in the artifact is an operator decision about what goes into the evidence in the first place. The format does not require identifying material and a careless deployment can still put it there.

Your inspector example is the right test. A record can commit to the fact that an action was appraised under a named policy at a stated time with a stated result, with nobody named in it. Qualified Agency's Inspector 14 is the same construction: the verdict is checkable and the identity stays out of the artifact.

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

On Monday, August 17th, 2026 at 14:44, Henri Sirkkavaara <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
> 
> >
> > Henri Sirkkavaara <[e-mail]> 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 <[e-mail]>   . 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >
> 
> Henri Sirkkavaara
> Vaara - Runtime execution layer for AI agents
> Built to see over the noise.
> vaara.io
> Helsinki, Finland