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

[Serhii Nikolaichuk <[e-mail]>]

Michael,

You asked whether a Relying Party should care what a geographic Result rests
on. My answer is: not every one will, and that is exactly why the Result has
to carry it.

RFC 9334 gives the Relying Party its own layer for this - the Appraisal
Policy for Attestation Results, "a set of rules that direct how a Relying
Party uses the Attestation Results". Whether to care is a decision that
policy makes, per Relying Party, per use. A Result format that omits the
basis does not leave the decision open. It makes it, once, for every Relying
Party, and the answer it makes is "no".

The reason I think some will want to say "yes" is no longer a hypothesis.
I built a minimal Verifier against the Section 4 CDDL and ran it over the 26
artifacts, with one policy for all three families: verify the artifact
against its public root, then take jurisdiction-country from a signed field
if one exists, otherwise from the unsigned capture metadata. All 26 verify -
twelve Nitro documents to the AWS Nitro Root G1, ten SEV-SNP reports to
VCEKs fetched from AMD's KDS, four Azure tokens to the MAA JWKS - and every
Result it emits validates against the CDDL. Two of those Results are the
point. An Azure token from westeurope and a SEV-SNP report from europe-west4
both yield jurisdiction-country "NL" - the encoded claim is the same four
bytes, 00 62 4e 4c, in each. The first rests on a signed field, the MAA
issuer. The second rests on nothing signed at all - the zone came from a
text file next to the report - and because that file was more specific than
the issuer host, it is the SEV-SNP Result that also carries a city. The
Result with less behind it is the more detailed one. The Verifier did not
get less trustworthy between the two. Its input did. Without a basis, the
Relying Party cannot separate "I trust this Verifier" from "this Verifier
had something to work with" - and those are different questions with
different consequences when a regulator asks the second one.

On the privacy point you raised earlier, I think it runs the other way. A
three-way class - Evidence, Endorsement, Attestation Result - says nothing
about which receiver, which endorser, or which region string. It leaks less
than the CN already in every Nitro certificate. A method registry, by
contrast, names the technique. If leaking the underlying evidence is the
concern, the coarse class is the safer of the two, not the more dangerous.

Which is also my answer to "if a verifier has evaluated evidence, then what
kind? GNSS? NTP? TPM?" That is precisely what your registry is for, and the
two compose rather than compete: the class says what kind of artifact the
conclusion rests on, the registry entry says which method produced it when
there is one to name. The class can always be populated. The registry entry
cannot - for SEV-SNP today there is no method, only an unsigned input, and
that case needs an honest way to be written down rather than omitted.

I will note that Joel Hillier reached the same place independently this
week on draft-ietf-rats-multi-verifier: the smallest change that closes
most of what he found is "a requirement that an Attestation Result, partial
or aggregated, names the ground it stands on". Two documents, two authors,
same shape.

You wrote in the Introduction that the exact method "may be of interest only
during forensic audits". I agree, and that is the case the class serves: it
is the minimum breadcrumb that lets a forensic question be asked at all,
without putting the answer on the wire up front.

On the field's name and encoding I have no position and will follow you.

Serhii Nikolaichuk
Austin, Texas

On Fri, Sep 04, 2026 11:51 AM, Michael Richardson <[e-mail]>
wrote:

>
> Serhii Nikolaichuk <[e-mail]> wrote:
>     > First, a correction to my own message of 29 August in this thread. I
>     > wrote that I had searched every signed artifact for anything
> locational
>     > and that there was nothing in any of them. That is wrong for AWS
>
> Ah.
>
>     > CN=77af59e854502979.us-east-2.aws.nitro-enclaves
>     > L=Seattle,ST=WA,C=US,CN=<...>.zonal.us-east-2.aws.nitro-enclaves
>     > CN=i-<instance>.us-east-2.aws.nitro-enclaves,L=Seattle,ST=Wa
> shington,C=US
>
> That's a good point, nut it's an assertion, probably really an endorsement.
>
>     > On your question about a chain up to the physical TPM: no, and the
>     > three families differ in how far down they do reach.
>
> Yes.  I think that this is a problem that needs solving.
> I have some notions as to how to do this while also supporting (and
> auditing)
> things like live migrations.
>
>     > 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.
>
> Should it care?
>
>     > On basis versus provenance: I have no attachment to my name for the
>     > field, my spelling, or my encoding, and I will follow you as editor
> and
>     > the WG. One substantive point for keeping some coarse axis alongside
> a
>     > method registry.  Your registry text admits "only documents that
>     > actually standardize ways to calculate geographic results".
>     > For SEV-SNP
>     > today there is no such document to name, because there is no method —
>     > whatever a Verifier concludes rests on an input that arrived
>     > unsigned. Under a registry-only field that case is either omitted,
>     > which is indistinguishable from "not stated", or given a fabricated
>     > entry.
>
> That seems like an endorsement :-)
> I guess that the provendance for endorsements should be set to the
> geographic
> results RFC :-)
>
>     > Two defects in what I sent, for the record. My PR text called
> Evidence,
>     > Endorsement and Attestation Result "roles"; they are artifacts, RFC
>     > 9334 Section 4.2 — the roles are in 4.1. And geo-basis-ref carried a
>     > verifier-id, which duplicates ear_verifier_id, already mandatory in
>     > every EAR. Both should go.
>
> Yes, I didn't really object to the notion that distinguishing between
> Evidence, Endorsement and AR was wrong, but rather that it wasn't detailed
> enough.  If a verifier has evaluated evidence, then what kind?  GNSS? NTP?
> TPM EK with implicit chain up to physical TPM?
>
>     > One mechanical item: the -03 posted yesterday still has
>     > grc.hallway-number and grc.room-number both at label 10, lines 328
> and
>     > 329 of the .txt. main fixed that shortly afterwards, so a -04 would
>     > carry it.
>
> Yes...  I know.  I'll update it again in a few days.
> I just wanted to make sure that there were no missing edits between
> laptop/desktop.  (The rebase was not simple.)
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
>