[Rats] Re: Adoption call for draft-richardson-rats-geographic-results

[Serhii Nikolaichuk <[e-mail]>]

Usama, Giri,

Thank you both; three things, then I stop taking the list's time.

Giri, on CHIP_ID: that settles it from the source, and the artifacts
agree: in every VCEK-signed report I hold (16 boots on 15 VMs, Google
and Azure) the KDS certificate fetched with the report's CHIP_ID as
hwID carries that value and verifies the signature; under AWS shared
tenancy the field is zeros and the VLEK certificate has no hwID at
all. Your last sentence is a draft item and I am taking it: a zeroed
CHIP_ID is an appraisal-policy input, not an error, and it means the
Result cannot rest on chip identity, so its basis is the provider's.

Usama, on the chained pair: agreed. The VLEK half is a provider key
domain, so the construction joins two identities, it does not take
the CSP out of the trust set; that is the draft's point, not an
exception to it.

On the binder: you are right and I had it too easy. What my runs
bound is a public key generated in the guest, and a key is not a
session. Rather than argue it I measured it this afternoon on one
Google SEV-SNP VM: a TLS 1.3 server in the guest takes the client's
nonce and requests two reports per session, REPORT_DATA = SHA-512(nonce
|| the session's RFC 9266 exporter value) and REPORT_DATA =
SHA-512(nonce || SPKI of its TLS key), and signs the nonce with that
key. The client derives its own exporter and checks both. Direct: both
accept. Through a relay on my machine that holds the guest's TLS key
(your leaked-key attacker) and terminates the client's session: the
key binder accepts, every check passes, peer key equals the attested
SPKI, signature valid, report genuine; the exporter binder rejects,
client exporter 72b395fe..., guest exporter 361367e7.... Same chip,
same REPORT_ID, equally genuine reports; only the shared-secret
binding sees the relay. Files under gcp-cvm/exporter/runs in [3],
write-up in PROTOCOLS.md.

The paragraph for Security Considerations now says exactly that:
bind the Evidence to a value derived from the session's shared secret,
the TLS exporter of RFC 9266, and a public key alone does not
correlate the Evidence with the session, citing [0]. Michael, the two
subsections (relayed Results; masked platform identities, with Giri's
point) are one small PR against main whenever you want them.

And thank you for the support and the suggestion about the author
block; the list was the better forum for the measurements, and I am
glad they were useful.

Serhii Nikolaichuk
Austin, Texas (basis = endorsement, signer = the author; the trust
anchor is available on request, one coffee in Austin)

[0]
https://www.google.com/url?q=https://doi.org/10.1145/3779208.3785387&source=gmail&ust=1789236126832000&sa=E
[3]
https://www.google.com/url?q=https://github.com/nikolaichuk7/geoar-verifier&source=gmail&ust=1789236126832000&sa=E

On Fri, Sep 11, 2026 12:18 PM, Muhammad Usama Sardar <
[e-mail]> wrote:

> Hi RATS,
>
> TL;DR: This draft will reduce the severity of the diversion attacks
> presented in ID-Crisis [0] from anywhere in the world to (at least) a
> specific region, so this draft must be adopted to protect the RATS
> ecosystem. Special thanks to Serhii and Giri for real-world experiments and
> incredibly useful information. They have convinced me that we are going in
> the right direction. Serhii has made important contributions -- I suggest
> that the adopted version already include him as co-author and the security
> considerations paragraph below.
>
> ===
>
> Hi Serhii,
> On 11.09.26 16:06, Serhii Nikolaichuk wrote:
>
> [...] So your understanding holds: on the three public platforms I can
> reach, one guest cannot obtain both signatures, and the wall is a
> per-guest launch flag set by the hypervisor, not a firmware limit.
>
> Thanks very much for the confirmation.
>
>
> What I tested as the way to have both. [...]
>
> Thanks, this is an interesting idea, but IIUC not quite confidential
> computing, because you need to trust the CSP.
>
> #1, REPORT_DATA. [...] No provider puts a location, or anything else, into
> this field.
>
> Thanks.
>
> #2 is for Giri; [...] For the
> location question I still think uniqueness is necessary but not
> decisive: a unique chip identity lets an operator's inventory map a
> chip to a rack, but the map is an operator statement, an Endorsement,
> and a collision would make the inventory ambiguous, not the class
> wrong.
>
> I agree operator has to be trusted. That's also our point in ID-Crisis [0]
> (cf. Sec. 1 in particular paragraph just before Sec. 1.1).
>
> Diversion. Agreed that a report proves nothing about the channel it
> arrived over; my probes bind a nonce, not a session, and say so. The
> remedy is the usual one and it is already in the same runs: a report
> with REPORT_DATA = SHA-512(nonce || SubjectPublicKeyInfo of an
> ephemeral Ed25519 key generated in the guest),
>
> I'm afraid it is much more subtle than that (cf. binder#6 in Table 2,
> corresponding result in Table 6 and Sec. 7.1 for the attack in [4]).
>
> a geographic Attestation Result states where the
> Attester's platform was found, not where the Relying Party's peer is;
> an Attester elsewhere can relay a genuine result obtained in the
> attested place; Relying Parties should therefore require the Evidence
> behind the result to be bound to the session in which the result is
> used, and Verifiers should carry that binding into the result.
>
> Good starting point, thanks a lot. Keep up the good work.
>
> Serhii Nikolaichuk
> Austin, Texas (basis = endorsement, signer = the author)
>
> Error 404: public part of signing key not found in my trust anchor store.
> This location is still a self-attestation for me. 🙂
>
> Best regards,
>
> -Usama
>
> [0] https://doi.org/10.1145/3779208.3785387
>>
>> [1] SEV Secure Nested Paging Firmware ABI Specification.  Rev. 1.59.
>> August 2026.  https://docs.amd.com/v/u/en-US/56860_PUB_SEV_SNP.
>>
>> [2] https://www.rfc-editor.org/info/rfc9711/#section-4.2.10.
>>
>> [3] The Confidential Computing Consortium.  “A Technical Analysis of
>> Confidential Computing”.  V. 1.3.  November 2022.
>> https://confidentialcomputing.io/wp-content/uploads/sites/10
>> /2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-
>> v1.3_unlocked.pdf.
>>
>> [4] https://www.researchgate.net/publication/398839141_
> Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS
>