[Rats] Re: Open Architectural Issues

[Mike Ounsworth <[e-mail]>]

Hannes,

 

Are you suggesting that perhaps RATS should specify the full API between an
RFC 9334 Relying Party and Verifier? If you are not suggesting this, then I
will.

 

I know that the IETF traditionally defines wire protocols and not abstract
APIs, but I believe the issue that Hannes is alluding to that came up in the
CSR Attest design team is that the current state is that each Verifier will
be some proprietary piece of software which presents its own proprietary C++
DLL API, or CLI or REST API, or morse-code-over-ftp interface, or whatever.
>From the perspective of an RP, figuring out how to integrate with a dozen
Verifiers from a dozen vendors might actually be more work than just looking
at their data blob and writing your own Verifier. So in this case, I think
that if IETF defined a Verifier API, it would greatly help overall adoption
in the kinds of large-scale deployments Hannes is referring to where an RP
needs to plug in dozens of Verifiers.

 

 

In my opinion, CMW and EAT are half-way to a "Verifier API" in that they
(somewhat) specify the data that will be passed in (Evidence, Endorsements,
Reference Values), and passed out (Attestation Results). But it could go all
the way and define an actual API - I'm imagining a document that defines two
APIs: one for statically-linked libraries, and one REST-over-HTTP, that
fully exercise all functionality of a Verifier under RFC 9334. 

---

Mike Ounsworth

 

From: Tschofenig, Hannes <hannes.tschofenig=[e-mail]> 
Sent: Wednesday, September 18, 2024 6:28 AM
To: rats <[e-mail]>
Subject: [EXTERNAL] [Rats] Open Architectural Issues

 

Hi all, I was wondering whether we could use the virtual interim meeting to
discuss an important architectural issue that surfaced with the work on the
attested CSR draft. Here is the issue: How should we deploy remote
attestation on a larger



Hi all,

 

I was wondering whether we could use the virtual interim meeting to discuss
an important architectural issue that surfaced with the work on the attested
CSR draft.

 

Here is the issue: How should we deploy remote attestation on a larger
scale? In particular, the RATS architecture assumes that the task of
verifying attestation evidence is outsourced to the Verifier. Now, the
question is: how does the Verifier get the necessary endorsements, reference
values, trust anchors and appraisal policies? 

 

Of course, all these questions are easy to answer for deployments where one
company operates all entities. That is, however, rarely the case. 

 

If the Verifier is tiredly integrated with the relying party, then the
relying party owner needs to collect the required information. This is
relatively easy if the relying party is also the owner or manufacturer of
the device(s) since it knows what hardware and software the devices are
supposed to be using.

 

For a more flexible deployment, the story gets complicated. We can see an
example deployment with the FIDO meta-data service. It makes several
assumptions that may not easily be generalizable. For example, it assumes
that all vendors of FIDO authenticators share their endorsements, reference
values, and trust anchors with the FIDO Alliance and that they are
subsequently shared (for free) with everyone. The FIDO meta-data service is
also not involved in any real-time interactions.

 

The FIDO Alliance model is a model where the relying party is co-located
with the verifier. The FIDO Alliance is, in the end, only a convenient way
for the relying parties to get access to the necessary information to
operate the verifier. 

 

So, if you are planning to deploy remote attestation, it would be
interesting to know what deployment model you are interested in. Afterall,
we want to ensure that the standards match the expected deployment.

 

Ciao
Hannes