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

[Serhii Nikolaichuk <[e-mail]>]

Michael,

Two orthogonal claims is exactly where I land as well, so rather than
describe them I put them in: PR #6 against main
(
https://www.google.com/url?q=https://github.com/mcr/geographicresult/pull/6&source=gmail&ust=1788964486324000&sa=E)
It carries grm.basis
with three values - evidence, endorsement, attestation-result, the
artifact classes of RFC 9334 Section 4.2, as a group-to-choice - and a
label for claim-uuid, which on main is referenced in the map but never
defined, so the CDDL block does not currently parse; the state-exclave
label has the same problem, and both are fixed in the PR. The registry
text from #4 is untouched and applies on top. And you are right that this
is per Result, not per Verifier - the moment XYZ has more than one method,
"trust XYZ" in the Appraisal Policy is not enough on its own.

I also re-ran the Verifier with the two claims in place. All 26
signatures verify as before; the Verifier now emits a geographic result
only where it has any locational input at all, 19 of the 26, and all 19
validate against the new CDDL, while a map carrying basis 3, basis as
text, or a 15-byte uuid is rejected. For the seven SEV-SNP reports that
carry nothing it emits no result, which I think is the only honest
answer when there is nothing to rest on. The two NL results are the
worked examples in the appendix - 25 and 36 bytes, same four bytes of
jurisdiction, different class.

The two-layer case you describe is, I think, the strongest argument for
keeping the class per hop rather than trying to flatten it. When a GAR is
consumed as an Endorsement by the Attester's normal Verifier, that
Verifier's own Result says basis = endorsement, and the GAR it consumed
carries its own basis one hop away. The claim-uuid is what joins the two
hops: a Relying Party that does not care stops at the first class, and an
auditor who does follows the uuid to the GAR and reads what that one rested
on. Nothing about the method travels on the wire unless someone asks. That
is the forensic breadcrumb in one field plus one link, and it is why I
would keep claim-uuid mandatory whenever the Result is meant to be
consumed by another Verifier.

GAR reads well to me - it is one letter from EAR, which is where these
claims live anyway.

Labels in the PR are 13 and 14 only because 0-12 are taken; I hold no
position on them and will save my 38 emails for the bikeshed.

Serhii

On Tue, Sep 08, 2026 05:45 AM, Michael Richardson <[e-mail]>
wrote:

>
> Serhii Nikolaichuk <[e-mail]> wrote:
>     > 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.
>
> I agree that it's reasonable.
> However, I also think that a lot also depends upon how the geographic
> verifier comes to be trusted by the RP.   In the cases where the geographic
> attestation result (`GAR`?) is an _endorsement_ that the Attester provides
> to
> it's "normal" Verifier, then there can even be two layers of
> intermediation.
>
>     > 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
>
> yes, exactly.  Part of that has to be: "and trust XYZ for geographic
> results", and to first order, the human that wrote the Appraisal Policy
> looked up how XYZ works, but it's also possible that XYZ has multiple
> methods.
>
>     > 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.
>
> Yes, fair enough.
>
>     > 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.
>
> So, your idea is that it's enough to say where the result entered, but not
> helpful to say how.  I understand better now, and I think you have a point.
> I was going to say that our claim field might either a method or an origin.
> but then you say:
>
>     > 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.
>
> And I think you are saying that actually we need to (orthogonal) claims.
>
>     > 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.
>
> and that's another reason to have a claim-uuid, as the audit process can
> ask
> the creator of the GAR about that specific entity.
>
>     > On the field's name and encoding I have no position and will follow
>     > you.
>
> Queue WG for 38-email long bikeshed!
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
>