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

[Muhammad Usama Sardar <[e-mail]>]

Hi Giri, Serhii, and RATS,

On 03.09.26 22:19, Mandyam, Giridhar wrote:
>
> > AMD SEV-SNP - the AMD Secure Processor signs the report itself
>
Did you use the VCEK mode? This shouldn't be surprising then, no?
>
> > so the chain is to silicon and does not pass through the hypervisor. 
> CHIP_ID is present and non-zero.
>
For location, one needs to pin down to the exact one universally unique 
identifier. So is CHIP_ID universally unique for one and only one 
machine? If not, it is practically not so useful as collisions are 
possible. My understanding after reading the spec [1] is that 
universally unique identifier is `hwID` and not `CHIP_ID`. Could you 
confirm?
>
> Per [1], the hypervisor can bind HOST_DATA in the guest report (Sec. 
> 8.19),
>
Isn't the hypervisor untrusted? Why does it put untrusted data into the 
report?From [3] (*emphasis* my own)

    "In the context of confidential computing, *unauthorized entities*
    could include other applications on the host, the host operating
    system and *hypervisor*, system administrators, service providers,
    and the infrastructure owner—or anyone else with physical access to
    the hardware."

> Disclaimer:  RATS Chairs, I am not trying to promote any specific 
> technology.  My intention is to ask for clarifications on a prior 
> posting to the list.
>
I don't think you need this disclaimer. This is incredibly useful 
information to keep the discussion realistic.
>
> Confidential compute security guarantees in my opinion do not require 
> anything like an integrated GNSS engine.  Per [3] from the CCC,
>
> “Confidential Computing is the protection of data in use by performing 
> computation in a hardware-based, attested Trusted Execution Environment.”
>
We refuted these claims in [0], specifically: (*emphasis* my own)

    "As we demonstrate in this work, the factors, such as the endpoint
    identity, administrative control and *location*, are not provided to
    the cloud customer by state-of-the-art attested TLS protocols."

> and
>
> “A Trusted Execution Environment (TEE) is defined by the CCC, 
> following common industry practice, as an environment that provides a 
> level of assurance of the following three properties:
>
> • Data confidentiality: Unauthorized entities cannot view data while 
> it is in use within the TEE.
>
> • Data integrity: Unauthorized entities cannot add, remove, or alter 
> data while it is in use within the TEE.
>
> • Code integrity: Unauthorized entities cannot add, remove, or alter 
> code executing in the TEE.”
>
> That doesn’t mean that physical security is not important, nor that 
> attested geolocation can be leveraged for verifying physical security.
>
There are too many negations in your statement, so I may be 
misunderstanding what you are trying to say. But quoting the very next 
sentence from [3] (*emphasis* my own)

    "In the context of confidential computing, *unauthorized entities*
    could include other applications on the host, the host operating
    system and hypervisor, *system administrators, service providers,
    and the infrastructure owner—or anyone else with physical access to
    the hardware*."

>   I question whether attested physical security is a requirement that 
> can be solved by confidential computing platforms alone.
>
Excellent question. I am looking for an answer too.

[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.
>
> *From:*Serhii Nikolaichuk <[e-mail]>
> *Sent:* Thursday, September 3, 2026 12:24 PM
> *To:* [e-mail]
> *Subject:* [Rats] Re: Adoption call for 
> draft-richardson-rats-geographic-results
>
> [...] AWS Nitro [...]
> L=Seattle,ST=WA,C=US,CN=<...>.zonal.us-east-2.aws.nitro-enclaves
>
What exactly is this location for?
>
> On your question about a chain up to the physical TPM: no,
>
Right, that matches our observation too. There is no chain to the 
physical TPM in any public cloud offerings to our knowledge. Some use vTPM.
>
> and the three
> families differ in how far down they do reach.
>
> AMD SEV-SNP - the AMD Secure Processor signs the report itself, so the 
> chain
> is to silicon and does not pass through the hypervisor. CHIP_ID is present
> and non-zero.
>
Which cloud provider did you use for this experiment? It may vary 
because last time we checked, some cloud providers masked the CHIP_ID.
>
> [...]
> for SEV-SNP there is nothing at all. Two Results carrying the same
> jurisdiction-country, signed by the same Verifier, can therefore rest on
> entirely different things, and a Relying Party reading the Result 
> cannot tell
> which one it received.
>
Again, which cloud provider? Also, to be sure, s/Results/Attestation 
Results?

Best,

-Usama