Re: [Rats] Verifier Input instead of Endorsement?

[Laurence Lundblade <[e-mail]>]

Here’s rough proposed text and diagram. Not sure where it would go in the doc yet.

LL

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

Conceptually there are four main inputs to the Verifier aside from the Attestation Evidence. They are:

   - Key material for verifying trust in the Attester
   - Known-good/reference values for comparison with Claims in the Attestation Evidence
   - Static implicit claims for the particular Attester that are pass to the Relying Party in Attestation Results
   - Policy Configuration

Any of these four can come from either the Manufacturer as Manufacturer Verifier Input or from the Verifier Owner as Owner Verifier Input. They key material usually always comes from the manufacturer and the policy from the Verifier Owner, but there is no strict requirement for this. The known-good/reference values and static implicit claims often come from either or both. 

There is no strict separation between Manufacturer and Verifier Owner. They could be the same. There could also be 3rd party intermediaries between the Manufacturer and the Verifier.

An Endorsement is one established format for some of these inputs. It usually comes from an Endorser that is usually the Manufacturer. It is usually a signed document. Alternatively, the Verifier may perform queries against a database, perhaps one maintained by a Manufacturer, to get inputs. Alternatively, the root key of a key hierarchy may be transferred in a one-time physical ceremony. This architecture sets no protocol or procedure for this input.

The transfer of all these inputs to the Verifier does need to be secured. For all cases, authenticity of the Manufacturer and Verifier Owner and their inputs are required. Without authentic inputs, the Verifier will not do its job correctly. In some cases confidentiality of the inputs is required. Finally, in some cases the Manufacturer and Verifier Owner will authenticate the Verifier.

This architecture sets no requirement for a particular protocol or security mechanism. For example, TLS could be used, but it is not the only protocol that could be used,




> On Jun 29, 2020, at 8:56 PM, Dave Thaler <dthaler=[e-mail]> wrote:
> 
> 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
>  
>  
>  
>  
>  
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats