Re: [Rats] Verifier Input instead of Endorsement?

[Laurence Lundblade <[e-mail]>]

Hi Simon,

Appreciate you jumping in here. 

> On Jul 3, 2020, at 2:28 AM, Simon Frost <[e-mail]> wrote:
> 
> I’ve just tried to catch up on the thinking on this via this thread and github#94 and realise that the conversation has become highly detailed and that some very precise definitions are emerging for concepts that originally were quite general (e.g. endorsement). Perhaps there’s a risk that the architecture may be overly constraining as a result.

I am after greater generality (and clarity) than I think we have now with Endorsements. Endorsements are (in my understanding) a somewhat specific representation of data and protocol. 

I am giving a lot of examples to try to communicate clearly, no to specify anything.

I would like the list-of-four in the document because I think it is highly informative (even Henk’s thinks they are so), but not as a prescription or requirement. 


>  
> Trying to avoid using any term that may now be overloaded…
> It seems that the important information to capture is that the Verifier is a means of providing transitive trust between the relying party and a potentially complex Supply Chain from which the attesting endpoint originated. The RP to Verifier relationship must be securable and trustworthy in some achievable way such that an RP can trust the attestation results received. Similarly that creates an expectation that the Verifier has established securable & trustworthy relationships with the supply chain in order to receive appropriate proofs / testimonies of items that the Verifier can identify within the attestation evidence. The Verifier to Supply Chain relationships aren’t just technical, they require contractual relationships as well which can bring a strong influence into the details of how the information gets to the Verifier.  If we have the relationships sketched out and an exploration of the types of information that may be required, is it necessary to go into further detail?

I think this is a possible approach. To take this, I think Endorsements have to be either removed or redefined in some very general way to side-step the ideas people have about them.

LL



>  
> Thanks
> Simon
>  
> From: Laurence Lundblade <[e-mail] <mailto:[e-mail]>> 
> Sent: 02 July 2020 18:52
> To: Henk Birkholz <[e-mail] <mailto:[e-mail]>>
> Cc: Dave Thaler <dthaler=[e-mail] <mailto:dthaler=[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Rats] Verifier Input instead of Endorsement?
>  
>  
> On Jul 2, 2020, at 6:31 AM, Henk Birkholz <[e-mail] <mailto:[e-mail]>> wrote:
>  
> 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
>  
> The problem with Endorser is that they produce Endorsements and I think there are problems with Endorsements:
>  - In Berlin you told me they don’t have keys in them. So then how do keys get into the Verifier?
>  - Endorsements seem to be small signed documents of attributes so they’re not so good for:
>      - Representing a database of millions of keys
>      - Representing HTTP access to a manufacturers database of known-good/reference values
>      - One-time physical / ceremonial transfer of a root key
> - Endorsements seem like a somewhat narrowed, specific way of providing verifier input
> - Endorsements imply signing as the security mechanism, which is too narrow.
>      
> Maybe we can find a term other than manufacturer?  What I want to avoid is the general use of the term Endorsement for the above reasons. Using the term Endorsement to me is like using the protocol-specific term EAT instead of conceptual term Attestation Evidence. Use of the term Endorser implies Endorsement, but maybe it is OK if we don’t use the term Endorsement.
> 
> 
> * 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)
>  
> Maybe the non-specificity of “Verifier Input” seems useful? It allows the list of four (keys, ref values, static claims, policy) to be used and for them to be variable. It is just a grouping.
>  
> Maybe we can find a better term? Here’s a few:
>    Verifier Criteria
>    Verifier Data
>    Attester Verification Criteria
>    Attester Trust Materials
>  
> 
> 
> * 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
>  
> I’d prefer the list of four to be explicit architecture, not just an example.
> 
> 
> 
> 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.
>  
> We should assume our audience knows little to nothing about TCG work (like me) and little about attestation, so I’d prefer they not be details, but rather up front and clear.
> 
> 
> 
> 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"?
>  
> Let me try again:
> - The Verifier must always establish the authenticity of the Manufacturer
> - All input from the Manufacturer must be integrity protected
> - The Verifier must always establish the authenticity of the Verifier Owner
> - All input from the Verifier Owner must be integrity protected
> - In some cases the Manufacturer may wish to establish the authenticity of the Verifier before giving inputs
> - In some cases the Owner may wish to establish the authenticity of the Verifier before giving inputs
> - In some cases confidentiality of the inputs is required
>  
> LL
>  
> 
> 
> 
> 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]> <mailto: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]> <mailto:[e-mail] <mailto:[e-mail]>>>*On Behalf Of*Laurence Lundblade
> *Sent:*Monday, June 29, 2020 11:34 AM
> *To:*[e-mail] <mailto:[e-mail]> <mailto:[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 <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 <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 <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]> <mailto:[e-mail] <mailto:[e-mail]>>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>