From: Serhii Nikolaichuk <nikolaichuk.s.f@gmail.com>
In-Reply-To: <3581559.1788540145@dyas>
References: <3581559.1788540145@dyas>
MIME-Version: 1.0
Date: Sun, 6 Sep 2026 20:41:32 -0700
Message-ID: 
 <CADj3X6sOeikanxToAfUXxGND9F393cZ6=KX9M=AGx1q9WH2XUw@mail.gmail.com>
To: rats@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f9e708065adc64e2"
Message-ID-Hash: QK63DYPIJHWUI7YWR7MVORMVM4ENUT7H
Precedence: list
Subject: =?utf-8?q?=5BRats=5D_Re=3A_Adoption_call_for_draft-richardson-rats-geographi?=
	=?utf-8?q?c-results?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rats/VFlPYmcCWfoHyuuVElaYFeVHqa8>

--000000000000f9e708065adc64e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Michael,

You asked whether a Relying Party should care what a geographic Result rest=
s
on. My answer is: not every one will, and that is exactly why the Result ha=
s
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 Relyin=
g
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 2=
6
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-west=
4
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 onl=
y
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 <mcr+ietf@sandelman.ca>
wrote:

>
> Serhii Nikolaichuk <nikolaichuk.s.f@gmail.com> 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=3D77af59e854502979.us-east-2.aws.nitro-enclaves
>     > L=3DSeattle,ST=3DWA,C=3DUS,CN=3D<...>.zonal.us-east-2.aws.nitro-enc=
laves
>     > CN=3Di-<instance>.us-east-2.aws.nitro-enclaves,L=3DSeattle,ST=3DWa
> shington,C=3DUS
>
> That's a good point, nut it's an assertion, probably really an endorsemen=
t.
>
>     > 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 alongsid=
e
> 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=
 =E2=80=94
>     > 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 =E2=80=94 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 detaile=
d
> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -=3D IPv6 IoT consulting =3D-                      *I*LIKE*TRAINS*
>
>
>
>

--000000000000f9e708065adc64e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><body><div dir=3D"auto">Michael,<br><br>You asked whether a Relying P=
arty should care what a geographic Result rests<br>on. My answer is: not ev=
ery one will, and that is exactly why the Result has<br>to carry it.<br><br=
>RFC 9334 gives the Relying Party its own layer for this - the Appraisal<br=
>Policy for Attestation Results, &quot;a set of rules that direct how a Rel=
ying<br>Party uses the Attestation Results&quot;. Whether to care is a deci=
sion that<br>policy makes, per Relying Party, per use. A Result format that=
 omits the<br>basis does not leave the decision open. It makes it, once, fo=
r every Relying<br>Party, and the answer it makes is &quot;no&quot;.<br><br=
>The reason I think some will want to say &quot;yes&quot; is no longer a hy=
pothesis.<br>I built a minimal Verifier against the Section 4 CDDL and ran =
it over the 26<br>artifacts, with one policy for all three families: verify=
 the artifact<br>against its public root, then take jurisdiction-country fr=
om a signed field<br>if one exists, otherwise from the unsigned capture met=
adata. All 26 verify -<br>twelve Nitro documents to the AWS Nitro Root G1, =
ten SEV-SNP reports to<br>VCEKs fetched from AMD&#39;s KDS, four Azure toke=
ns to the MAA JWKS - and every<br>Result it emits validates against the CDD=
L. Two of those Results are the<br>point. An Azure token from westeurope an=
d a SEV-SNP report from europe-west4<br>both yield jurisdiction-country &qu=
ot;NL&quot; - the encoded claim is the same four<br>bytes, 00 62 4e 4c, in =
each. The first rests on a signed field, the MAA<br>issuer. The second rest=
s on nothing signed at all - the zone came from a<br>text file next to the =
report - and because that file was more specific than<br>the issuer host, i=
t is the SEV-SNP Result that also carries a city. The<br>Result with less b=
ehind it is the more detailed one. The Verifier did not<br>get less trustwo=
rthy between the two. Its input did. Without a basis, the<br>Relying Party =
cannot separate &quot;I trust this Verifier&quot; from &quot;this Verifier<=
br>had something to work with&quot; - and those are different questions wit=
h<br>different consequences when a regulator asks the second one.<br><br>On=
 the privacy point you raised earlier, I think it runs the other way. A<br>=
three-way class - Evidence, Endorsement, Attestation Result - says nothing<=
br>about which receiver, which endorser, or which region string. It leaks l=
ess<br>than the CN already in every Nitro certificate. A method registry, b=
y<br>contrast, names the technique. If leaking the underlying evidence is t=
he<br>concern, the coarse class is the safer of the two, not the more dange=
rous.<br><br>Which is also my answer to &quot;if a verifier has evaluated e=
vidence, then what<br>kind? GNSS? NTP? TPM?&quot; That is precisely what yo=
ur registry is for, and the<br>two compose rather than compete: the class s=
ays what kind of artifact the<br>conclusion rests on, the registry entry sa=
ys which method produced it when<br>there is one to name. The class can alw=
ays be populated. The registry entry<br>cannot - for SEV-SNP today there is=
 no method, only an unsigned input, and<br>that case needs an honest way to=
 be written down rather than omitted.<br><br>I will note that Joel Hillier =
reached the same place independently this<br>week on draft-ietf-rats-multi-=
verifier: the smallest change that closes<br>most of what he found is &quot=
;a requirement that an Attestation Result, partial<br>or aggregated, names =
the ground it stands on&quot;. Two documents, two authors,<br>same shape.<b=
r><br>You wrote in the Introduction that the exact method &quot;may be of i=
nterest only<br>during forensic audits&quot;. I agree, and that is the case=
 the class serves: it<br>is the minimum breadcrumb that lets a forensic que=
stion be asked at all,<br>without putting the answer on the wire up front.<=
br><br>On the field&#39;s name and encoding I have no position and will fol=
low you.<br><br>Serhii Nikolaichuk<br>Austin, Texas<br></div></body></html>=
<br><div class=3D"gmail_extra"><div>On Fri, Sep 04, 2026 11:51 AM, Michael =
Richardson &lt;<a href=3D"mailto:mcr%2Bietf@sandelman.ca">mcr+ietf@sandelma=
n.ca</a>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Serhii Nikolaichuk &lt;<a href=3D"mailto:nikolaichuk.s.f@gmail.com" target=
=3D"_blank">nikolaichuk.s.f@gmail.com</a>&gt; wrote:<br>
=C2=A0 =C2=A0 &gt; First, a correction to my own message of 29 August in th=
is thread. I<br>
=C2=A0 =C2=A0 &gt; wrote that I had searched every signed artifact for anyt=
hing locational<br>
=C2=A0 =C2=A0 &gt; and that there was nothing in any of them. That is wrong=
 for AWS<br>
<br>
Ah.<br>
<br>
=C2=A0 =C2=A0 &gt; CN=3D77af59e854502979.us-east-2.<wbr>aws.nitro-enclaves<=
br>
=C2=A0 =C2=A0 &gt; L=3DSeattle,ST=3DWA,C=3DUS,CN=3D&lt;...&gt;.<wbr>zonal.u=
s-east-2.aws.nitro-encl<wbr>aves<br>
=C2=A0 =C2=A0 &gt; CN=3Di-&lt;instance&gt;.us-east-2.aws.<wbr>nitro-enclave=
s,L=3DSeattle,ST=3DWa<wbr>shington,C=3DUS<br>
<br>
That&#39;s a good point, nut it&#39;s an assertion, probably really an endo=
rsement.<br>
<br>
=C2=A0 =C2=A0 &gt; On your question about a chain up to the physical TPM: n=
o, and the<br>
=C2=A0 =C2=A0 &gt; three families differ in how far down they do reach.<br>
<br>
Yes.=C2=A0 I think that this is a problem that needs solving.<br>
I have some notions as to how to do this while also supporting (and auditin=
g)<br>
things like live migrations.<br>
<br>
=C2=A0 =C2=A0 &gt; Results carrying the same jurisdiction-country, signed b=
y the same<br>
=C2=A0 =C2=A0 &gt; Verifier, can therefore rest on entirely different thing=
s, and a<br>
=C2=A0 =C2=A0 &gt; Relying Party reading the Result cannot tell which one i=
t received.<br>
<br>
Should it care?<br>
<br>
=C2=A0 =C2=A0 &gt; On basis versus provenance: I have no attachment to my n=
ame for the<br>
=C2=A0 =C2=A0 &gt; field, my spelling, or my encoding, and I will follow yo=
u as editor and<br>
=C2=A0 =C2=A0 &gt; the WG. One substantive point for keeping some coarse ax=
is alongside a<br>
=C2=A0 =C2=A0 &gt; method registry.=C2=A0 Your registry text admits &quot;o=
nly documents that<br>
=C2=A0 =C2=A0 &gt; actually standardize ways to calculate geographic result=
s&quot;.<br>
=C2=A0 =C2=A0 &gt; For SEV-SNP<br>
=C2=A0 =C2=A0 &gt; today there is no such document to name, because there i=
s no method =E2=80=94<br>
=C2=A0 =C2=A0 &gt; whatever a Verifier concludes rests on an input that arr=
ived<br>
=C2=A0 =C2=A0 &gt; unsigned. Under a registry-only field that case is eithe=
r omitted,<br>
=C2=A0 =C2=A0 &gt; which is indistinguishable from &quot;not stated&quot;, =
or given a fabricated<br>
=C2=A0 =C2=A0 &gt; entry.<br>
<br>
That seems like an endorsement :-)<br>
I guess that the provendance for endorsements should be set to the geograph=
ic<br>
results RFC :-)<br>
<br>
=C2=A0 =C2=A0 &gt; Two defects in what I sent, for the record. My PR text c=
alled Evidence,<br>
=C2=A0 =C2=A0 &gt; Endorsement and Attestation Result &quot;roles&quot;; th=
ey are artifacts, RFC<br>
=C2=A0 =C2=A0 &gt; 9334 Section 4.2 =E2=80=94 the roles are in 4.1. And geo=
-basis-ref carried a<br>
=C2=A0 =C2=A0 &gt; verifier-id, which duplicates ear_verifier_id, already m=
andatory in<br>
=C2=A0 =C2=A0 &gt; every EAR. Both should go.<br>
<br>
Yes, I didn&#39;t really object to the notion that distinguishing between<b=
r>
Evidence, Endorsement and AR was wrong, but rather that it wasn&#39;t detai=
led<br>
enough.=C2=A0 If a verifier has evaluated evidence, then what kind?=C2=A0 G=
NSS? NTP?<br>
TPM EK with implicit chain up to physical TPM?<br>
<br>
=C2=A0 =C2=A0 &gt; One mechanical item: the -03 posted yesterday still has<=
br>
=C2=A0 =C2=A0 &gt; grc.hallway-number and grc.room-number both at label 10,=
 lines 328 and<br>
=C2=A0 =C2=A0 &gt; 329 of the .txt. main fixed that shortly afterwards, so =
a -04 would<br>
=C2=A0 =C2=A0 &gt; carry it.<br>
<br>
Yes...=C2=A0 I know.=C2=A0 I&#39;ll update it again in a few days.<br>
I just wanted to make sure that there were no missing edits between<br>
laptop/desktop.=C2=A0 (The rebase was not simple.)<br>
<br>
--<br>
Michael Richardson &lt;<a href=3D"mailto:mcr%2BIETF@sandelman.ca" target=3D=
"_blank">mcr+IETF@sandelman.ca</a>&gt;, Sandelman Software Works<br>
=C2=A0-=3D IPv6 IoT consulting =3D-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *I*LIKE*TRAINS*<br>
<br>
<br>
<br>
</blockquote></div></div>

--000000000000f9e708065adc64e2--