[Rats] Re: reworking draft-ietf-rats-ar4si (and EAR)

["[e-mail]" <[e-mail]>]

(not as chair)

 

On 11/27/25, 7:18 PM, "Michael Richardson" <[e-mail]> wrote:

 

When we wrote RFC9334 I think that we were trying to bring a diverse set of
existing and predicted/desired Remote Attestation architectures into a
smaller number of abstract patterns with some terminology that could be
mapped.   Yes, "xkcd 927" https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxkcd.com%2F927%2F&data=05%7C02%7C%7C299a845a67fa44af5cde08de2e1c0df1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638998895203981170%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aGAu1cyOsxPAPBJm4Qjan402L%2BSNS90a5eSWJANZhZU%3D&reserved=0" rel="nofollow">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxkcd.com%2F927%2F&data=05%7C02%7C%7C299a845a67fa44af5cde08de2e1c0df1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638998895203981170%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aGAu1cyOsxPAPBJm4Qjan402L%2BSNS90a5eSWJANZhZU%3D&reserved=0.
But, also, "Embrace and Extend"   (but, not extinguish!)
Also thus Figure 9, with 4+1 inputs and 4+1 outputs.
(And we are seeing this via "CSR-attestation" and pkix-evidence
documents. That's good.)

I felt sure that we (the IETF/RATS) would produce one or more protocols that
would be the extend part.  I view much of AR4SI with EAR as being that.
But, it seems like we are shy of actually doing that.

I point to RFC761: it defines the TCP header, and the concept of the window
but is almost completely mute about congestion control.  The word
"congestion" occurs only twice, and no algorithm is provided!!!
RFC896,2001(1997!), 2309,2581,2914,... tell one how to actually *do* TCP.
This is the model we want.   Okay, it's messy.  But, it survived over 40+ years.
I think that EAR should be our RFC761 (structures, meanings of bits).
I think that AR4SI should *A* "congestion control" document equivalent.

I’m not sure I get the analogy, but I think I get the idea.

I think it should stop trying to be general purpose, and instead it should be

It = AR4SI?

opinionated.   It should not cover every possible combination.
9334 did that already.  We need to do the opposite here.

It should be give three or four important use cases ("applicability") ONLY.
More can be added via new documents.
{I also note that TCP (congestion control) has had many updates often relating to
high bandwidth*delay situations, like window-scaling to deal with specific
situations like satellite links, etc.. }

Probably that means:
1. desktop/device trustworthiness for use with enterprise environments.
2. end-user desktop/mobile trustworthiness for use in Internet cases.
3. (critical) infrastructure uses cases like routers, power stations, traffic
   control systrems.
4. virtualized workload situations including VMs, containers (whether TEE or not)

Some of these categories can be pretty big, and we should take only **small bites**
Take *only* what you can eat right now ("running code"), and come back for
more, is what my mom probably told me at some point.

Within these categories I do *not* want to do Background Check *or* Passport mode.
PICK ONE.  Get the interactions right for that.  That means *A* freshness choice.
That might mean PKIX vs JWT vs CWT vs C509 for identities.

Perhaps this sounds like I'm asking to throw away this document and start
over.  Yes. No.  The text is all there, it's just not in the right order.
Like, section 2.3.1 "Design Principles" is well designed text, and the
reasoning is sane.

I would create a ToC like this:

   1.  Introduction
     1.1.  Requirements Notation
     1.2.  Terminology
   2.  Targetted Use Cases
     2.1.1 Enterprise Desktops
     2.1.1 Enterprise mobile devices
     2.2.1 Consumer Desktops
     2.2.2 Consumer mobile devices
     2.3.1 ISP critical infrastructure
     2.4.1 Virtualized Workloads

   3. Design Principles
      [numbers from section 2.3 go to EAR, but principles remain here]

   4. Common Prerequistes
      Much of section 2.2 (Non-repudiable Verifier Identity), but be SPECIFIC.
      I don't want stuff like:
        "When provided during this exchange, the identity may be communicated
        either implicitly or explicitly."

   5. Per-Use case

     I want it to say (a), "When working with ISP critical infrastructure, the
          use of vendor-specific background check verifiers requires that the
          Verifier's AR are directly tied to the Evidence provided by the Attester.
          The Evidence must therefore never be encrypted, and this is not a
          problem in closed ISP environments"

     Or (b): "When working with consumer mobile devices, the RP will often be
          interested in what jurisdiction the device currently is in, and possibly
          whether or not the end-user is of age.   However, the details of
          this are private to the device.  This is best done as a passport
          check, with an Attestation Result that makes use of Selective
          Disclosure mechanisms."

The use of SD / encryption as well as whether audit level information of Verifier’s internal state (which is supported by EAR) would be tied to an appropriate use case. Possibly, EAR profiles would need to be use case specific?

My goal is not to design any single interaction here, but very small classes
of specific ones.

For example, when selling to US Gov, it is common to have FIPS certifications and to know at what level a system was certified. However, AR4SI doesn’t comprehend FIPS claims and it isn’t a substitute for FIPS either. Hence, a use case context that requires FIPS as attestation results might need to be included with an AR4SI claim

 

. The same goes for whether a specific trust vector makes sense for a given use case. For example, in a web deployment context, instance identity might not be necessary or might be forbidden by privacy law.

 

But I’m not clear on how you plan to proceed with AR4SI on a small bytes first approach that is use case specific and still have it make progress toward RFC status as the next nibble will update it before it makes it all the way through the IETF process. (chair hat on) Is this a recipe for an eternally unfinished draft?

This requires that we make the engineering tradeoffs, and that we leave
as few options as possible for later on.  Yes, this is harder to do than
abstract frameworks because it requires that we involve people writing code,
systems and dealing real constraints.    We **already** did the abstractions.

{For instance, I suspect that (b) might be right for SEAT access to age-restricted
content.}

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide