Re: [Rats] Verifier Input instead of Endorsement?

Laurence Lundblade <lgl@island-resort.com> Thu, 02 July 2020 01:47 UTC

Return-Path: <lgl@island-resort.com>
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 32D3D3A00D4 for <rats@ietfa.amsl.com>; Wed, 1 Jul 2020 18:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 r8DpQj9MKz72 for <rats@ietfa.amsl.com>; Wed, 1 Jul 2020 18:47:01 -0700 (PDT)
Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) (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 E41803A00C0 for <rats@ietf.org>; Wed, 1 Jul 2020 18:47:00 -0700 (PDT)
Received: from laurences-mbp.lan ([70.58.199.219]) by :SMTPAUTH: with ESMTPA id qoJWj7b33DyEmqoJXj2Drm; Wed, 01 Jul 2020 18:47:00 -0700
X-CMAE-Analysis: v=2.3 cv=eJhtc0h1 c=1 sm=1 tr=0 a=vYbQBYz1awqCo8DrEKtgEg==:117 a=vYbQBYz1awqCo8DrEKtgEg==:17 a=48vgC7mUAAAA:8 a=UqCG9HQmAAAA:8 a=0XtbOteLAAAA:20 a=yMhMjlubAAAA:8 a=nhax6yrGChlR8yjs6GoA:9 a=V_w1Tvb4zRYNsRtr:21 a=PBrlvudrAtikZzIC:21 a=QEXdDO2ut3YA:10 a=Y4PmCYCavZXmDW7C0XwA:9 a=ZLSKgxAP4Q7gr4ke:21 a=zhLiSB_xLkdP1u6m:21 a=Ulv5cNiY3Pm2CtrA:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <BF5071AC-0C8D-4B26-8330-8589736B6EF5@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF924F25-2A80-40C9-99C0-70C74E02844B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 1 Jul 2020 18:46:58 -0700
In-Reply-To: <BL0PR2101MB10279501A4ECA5BB7B6AED63A36F0@BL0PR2101MB1027.namprd21.prod.outlook.com>
Cc: "rats@ietf.org" <rats@ietf.org>
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
References: <878E068C-DAFD-4441-94F7-BA79CAF7FED6@island-resort.com> <BL0PR2101MB10279501A4ECA5BB7B6AED63A36F0@BL0PR2101MB1027.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-CMAE-Envelope: MS4wfC4snNh4rnrGrdhDelfa1TG/LAhFLcx7Y7tITbC8nxTggj+8aYzPnNBAgYPnzXxDE6Sc4xMkWxdU3YG81qSigNG3G9HcEO1skXn4sUuCdxEBgzkFDUNd p0pqbv+hFf5QqOB8GKHnVUoWVtzot4TjGb20iN04+FKkwuZvYyl453NOOsOkulwd4rTqZ9AYI47A4oa5mjNMVUMpNbK5Ux/CxOultRtNZFX89W4PnSqjgcJ0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/LjO-KkNZ6UzElgRWyxfJHslgS7U>
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: Thu, 02 Jul 2020 01:47:03 -0000

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> 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> On Behalf Of Laurence Lundblade
> Sent: Monday, June 29, 2020 11:34 AM
> To: 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
> https://www.ietf.org/mailman/listinfo/rats