Re: [Rats] Verifier Input instead of Endorsement?

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 06 July 2020 12:20 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26C23A13E9 for <rats@ietfa.amsl.com>; Mon, 6 Jul 2020 05:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.502
X-Spam-Level:
X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_PRESCRIPTION=2.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb2ntEYo0fs2 for <rats@ietfa.amsl.com>; Mon, 6 Jul 2020 05:19:57 -0700 (PDT)
Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D953A13E7 for <rats@ietf.org>; Mon, 6 Jul 2020 05:19:55 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2F7BwCNFgNf/xmnZsBWCh4BAQsSDECBTIF5gR6BMwqEKJBtJZocgVsNCwEBAQEBAQEBAQYBARgLCgIEAQEChEUCgiYBJDgTAhABAQYBAQEBAQYEAgKGFwglDEMBEAGCfIECAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR4BAQEBAgEBASEECwEFLwcCAgcQCQIRAQMBAQECAiMDAgInHwECBggGAQkDAQUCAQGDIgGCXCAEC4xWmwR2fzOFUYMlgToGgQ4qAYxaDw+BTD+BEScMA4IsLj6CXAEBAoEnAQEHCwEHBEKCaoJgBI8ABwoSDwiCfKFQXCgHgVmBBoEHBAuISIUbhHuFSgUKHYJzNoh6hHUGjX+POIIhnmACBAIJAhWBai83I3BNJE+CaVAXAg2MD4M0AQIGh1eFRHICNQIGAQcBAQMJfIhGhHyBNAGBEAEB
X-IPAS-Result: A2F7BwCNFgNf/xmnZsBWCh4BAQsSDECBTIF5gR6BMwqEKJBtJZocgVsNCwEBAQEBAQEBAQYBARgLCgIEAQEChEUCgiYBJDgTAhABAQYBAQEBAQYEAgKGFwglDEMBEAGCfIECAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR4BAQEBAgEBASEECwEFLwcCAgcQCQIRAQMBAQECAiMDAgInHwECBggGAQkDAQUCAQGDIgGCXCAEC4xWmwR2fzOFUYMlgToGgQ4qAYxaDw+BTD+BEScMA4IsLj6CXAEBAoEnAQEHCwEHBEKCaoJgBI8ABwoSDwiCfKFQXCgHgVmBBoEHBAuISIUbhHuFSgUKHYJzNoh6hHUGjX+POIIhnmACBAIJAhWBai83I3BNJE+CaVAXAg2MD4M0AQIGh1eFRHICNQIGAQcBAQMJfIhGhHyBNAGBEAEB
X-IronPort-AV: E=Sophos;i="5.75,318,1589234400"; d="scan'208";a="22916031"
Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2020 14:19:36 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BZDACNFgNf/1lIDI1WCh4BAQsSDECBTIF5L28DVDAsCoQokG0lmhyBaAsBAwEBAQEBBgEBGAsKAgQBAYRHAoIkAiQ4EwIQAQEFAQEBAgEGBG2FLgglDEMBEAGFGQEBAQECAQEBIQQLAQUvBwICBxAJAhEBAwEBAQICIwMCAicfAQIGCAYBCQMBBQIBAYMiAYJcJAuMVpsEdn8zhVGDJYE6BoEOKgGMWg8PgUw/gREnDAOCLC4+glwBAQKBJwEBBwsBBwRCgmqCYASPAAcKEg8IgnyhUFwoB4FZgQaBBwQLiEiFG4R7hUoFCh2CczaIeoR1Bo1/jziCIZ5gAgQCCQIVgWoiDDcjcE0kT4JpUBcCDYwPgzQBAgaHV4VEQTECNQIGAQcBAQMJfIhGhHyBNAGBEAEB
X-IronPort-AV: E=Sophos;i="5.75,318,1589234400"; d="scan'208";a="85641642"
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2020 14:19:30 +0200
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 066CJT3l019167 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 6 Jul 2020 14:19:29 +0200
Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 6 Jul 2020 14:19:24 +0200
To: Simon Frost <Simon.Frost@arm.com>, Laurence Lundblade <lgl@island-resort.com>
CC: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>, "rats@ietf.org" <rats@ietf.org>
References: <878E068C-DAFD-4441-94F7-BA79CAF7FED6@island-resort.com> <BL0PR2101MB10279501A4ECA5BB7B6AED63A36F0@BL0PR2101MB1027.namprd21.prod.outlook.com> <BF5071AC-0C8D-4B26-8330-8589736B6EF5@island-resort.com> <af8e64b9-41b3-f42a-183d-1c9544fc1d7d@sit.fraunhofer.de> <C4D6DCB6-F0D9-4858-823C-7B045005B48C@island-resort.com> <AM6PR08MB34297526F7AC5A7EEC988A37EF6A0@AM6PR08MB3429.eurprd08.prod.outlook.com> <663F1B08-930B-4D9E-BC80-9D281688B550@island-resort.com> <AM6PR08MB34290D2E1E5A32D61727424CEF690@AM6PR08MB3429.eurprd08.prod.outlook.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <cda68f7e-7581-e976-6056-e77b1ccea351@sit.fraunhofer.de>
Date: Mon, 06 Jul 2020 14:19:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <AM6PR08MB34290D2E1E5A32D61727424CEF690@AM6PR08MB3429.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.206.156.41]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/WeQN8CVuBOP2pBcjJb_HZVHa9Cc>
Subject: Re: [Rats] Verifier Input instead of Endorsement?
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2020 12:20:01 -0000

Hi all,

quick comment below

On 06.07.20 13:55, Simon Frost wrote:
> Hi Laurence,
> 
>> 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 agree with your aim. I’m suggesting that we relax that definition to 
> allow ‘Endorsements’ to cover all the categories of data originating 
> from the supply chain that the Verifier may need to consult. I’m not 
> aware that Endorsement has a specific industry definition. (I’m aware of 
> Endorsement Certificates for TPMs, but that’s a more specialised term). 
> I’m happy to have a definition pointed out or equally if Endorsement 
> just has excessive connotations for the WG then the architecture can 
> adopt another, descriptive, term. I agree that more information would 
> then be needed and your 4 categories could form the basis of a set of 
> examples for types of data in that category.
> 
> As you say on a separate reply:
> 
>> Well, first, I thought we agreed that the arcs above Verifier were out of scope for the architecture…
> 
> I remember having a discussion locally when the WG charter was defined 
> in which we agreed that keeping it out of scope was exactly the correct 
> approach, just because there were so many ways in which the 
> relationships may need to be satisfied.

In fact we agreed on "out-of-scope" for the first phase of the charter 
in order to acknowledge the fact that this is part of the "Attestation 
Provisioning Workflow" (an old term that we used to use to draw the 
demarcation line for the RATS WG phasing).

Viele Grüße,

Henk

> 
> HTH
> 
> Simon
> 
> *From:*Laurence Lundblade <lgl@island-resort.com>
> *Sent:* 04 July 2020 18:23
> *To:* Simon Frost <Simon.Frost@arm.com>
> *Cc:* Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; Dave Thaler 
> <dthaler=40microsoft.com@dmarc.ietf.org>; rats@ietf.org
> *Subject:* Re: [Rats] Verifier Input instead of Endorsement?
> 
> Hi Simon,
> 
> Appreciate you jumping in here.
> 
> 
> 
>     On Jul 3, 2020, at 2:28 AM, Simon Frost <Simon.Frost@arm.com
>     <mailto:Simon.Frost@arm.com>> 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 riskthat 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 <lgl@island-resort.com
>     <mailto:lgl@island-resort.com>>
>     *Sent:*02 July 2020 18:52
>     *To:*Henk Birkholz <henk.birkholz@sit.fraunhofer.de
>     <mailto:henk.birkholz@sit.fraunhofer.de>>
>     *Cc:*Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org
>     <mailto:dthaler=40microsoft.com@dmarc.ietf.org>>;rats@ietf.org
>     <mailto:rats@ietf.org>
>     *Subject:*Re: [Rats] Verifier Input instead of Endorsement?
> 
>         On Jul 2, 2020, at 6:31 AM, Henk Birkholz
>         <henk.birkholz@sit.fraunhofer.de
>         <mailto:henk.birkholz@sit.fraunhofer.de>> 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=40microsoft.com@dmarc.ietf.org
>                 <mailto:dthaler=40microsoft.com@dmarc.ietf.org><mailto:dthaler=40microsoft.com@dmarc.ietf.org>>
>                 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 <rats-bounces@ietf.org
>                 <mailto:rats-bounces@ietf.org><mailto:rats-bounces@ietf.org>>*On
>                 Behalf Of*Laurence Lundblade
>                 *Sent:*Monday, June 29, 2020 11:34 AM
>                 *To:*rats@ietf.org
>                 <mailto:rats@ietf.org><mailto:rats@ietf.org>
>                 *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
>                 RATS@ietf.org <mailto:RATS@ietf.org><mailto:RATS@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/rats
> 
>             _______________________________________________
>             RATS mailing list
>             RATS@ietf.org <mailto:RATS@ietf.org>
>             https://www.ietf.org/mailman/listinfo/rats
> 
> 
>         _______________________________________________
>         RATS mailing list
>         RATS@ietf.org <mailto:RATS@ietf.org>
>         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
>     RATS@ietf.org <mailto:RATS@ietf.org>
>     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.