Re: [Rats] Verifier Input instead of Endorsement?

[Dave Thaler <[e-mail]>]

I don’t like the term “Verifier Input” since “Appraisal Policy for Evidence” is also Verifier Input, so I would find it confusing.
I think that the rules for what to put in Attestation Results (bullet 3), as well as “known-good/reference values” if such exist
(and there can be valid policies where they may not exist, or rather where the policies use more complex rules than
a simple test for equality against a constant) are conceptually part of Appraisal Policy.

I do agree that Appraisal Policy can be conveyed to the Verifier in many different ways, and may be composed
of different things from different sources.

Dave

From: RATS <[e-mail]> On Behalf Of Laurence Lundblade
Sent: Monday, June 29, 2020 11:34 AM
To: [e-mail]
Subject: [Rats] Verifier Input instead of Endorsement?

Stepping back a bit on the definition of an Endorsement, I think the four inputs to a Verifier are these:
  - Key material for verifying trust in the Attester
  - Known-good/Reference values for comparison with claims
  - Static implicit claims that are passed to RP's via Attestation Results
  - Appraisal Policy

These can and will be conveyed to the Verifier in many different ways:
  - X.509 certs with extensions
  - Signed documents
  - HTTP queries against the Attester/device manufacturer
  - Remote SQL or some other sort of database access to manufacturer(s)
  - Data storage like flash drives the are hand carried into the Verifier's site
  - One-time special file transfers
  - Ceremonial procedures with M out of N people physical present approving transfer

It seems like shoe-horning all of the above (except policy) into an Endorsement, like I’ve tried to do<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0>  is too much. I tried this shoe-horning because I think the architecture document needs to cover all this and Endorsements was what was in it. A typical Endorsement seems to be just the first two mentioned, X.509 and signed documents expanding its definition to include database access is a stretch.

Rather than defining Endorsement, I’d like to define Verifier Input:

          *******************   ************     ****************
          * Manufacturer(s) *   * Verifier *     * Relying Party*
          *******************   *  Owner   *     *  Owner       *
                       |        ************     ****************
                       |              |                 |
         Verifier Input|              |                 |
                       |              |Appraisal        |
                       |              |Policy           |
                       |              |for              | Appraisal
                       |              |Evidence         | Policy for
                       |              |                 | Attestation
                       |              |                 |  Result
                       v              v                 |
                     .-----------------.                |
              .----->|     Verifier    |------.         |
              |      '-----------------'      |         |
              |                               |         |
              |                    Attestation|         |
              |                    Results    |         |
              | Evidence                      |         |
              |                               |         |
              |                               v         v
        .----------.                      .-----------------.
        | Attester |                      | Relying Party   |
        '----------'                      '————————‘


Endorsements must still be mentioned, but as one form of Verifier input just like EAT is one form of Attestation Evidence.

Verifier Input would be defined as:
  - Key material for verifying trust in the Attester
  - Known-good/Reference values for comparison with claims
  - Static implicit claims that are passed to RP's via Attestation Results

To do this, I’d replace the current PR<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fpull%2F94&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986365098&sdata=2NktPX%2B3LJXjMEjEFoM8kpUIy6yOxte%2BuhFYr1ETN4g%3D&reserved=0> and issue<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Farchitecture%2Fissues%2F65&data=02%7C01%7Cdthaler%40microsoft.com%7Cf15ace6e8b4b447eebc008d81c5b1f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290524986375092&sdata=GfM5qElO4teNdjfABlmVayeGXuYHWBDqHTVtpeeew7g%3D&reserved=0> I have on Endorsements with a new PR. It will be a fair bit of work, so I want to see if there is some consensus first.

LL