Re: [Rats] Verifier Input instead of Endorsement?

[Henk Birkholz <[e-mail]>]

Hi Laurence,

while I think that I understand where you are coming from here, I have 
to say that I also think that:

* "manufacturer(s)" is a too arbitrarily restricting term, which is why 
we agreed on endorser
* every arrow is of course "input/output", but we are not calling 
evidence "Attester Output". So, Verifier Input is in contrast a too 
ambiguous category (it does not add any semantics to the arrow)
* the itemized list that starts with key material provides a very 
intuitive example and maybe we could use that kind of list as a more 
prominent example in the arch I-D

The question, if reference values are endorsements or appraisal policies 
or a third item is... probably okay and I am interested in an answer - 
but that is a detail, I think. As long as they are also mentioned, I can 
follow all three lines of thought.

Also, I am in strong doubt that the following statement is always 
correct: "The transfer of all these inputs to the Verifier does need to 
be secured.". I am confused by the exceptions that follow that statement 
which basically say, I think: in some cases they have to be secured. 
Maybe we mean different things by "secured"?

Viele Grüße,

Henk

On 02.07.20 03:46, Laurence Lundblade wrote:
> 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] 
>> <mailto: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] <mailto:[e-mail]>>*On 
>> Behalf Of*Laurence Lundblade
>> *Sent:*Monday, June 29, 2020 11:34 AM
>> *To:*[e-mail] <mailto:[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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>