[Rats] Verifier Input instead of Endorsement?

Laurence Lundblade <lgl@island-resort.com> Mon, 29 June 2020 18:34 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 10CFF3A0C70 for <rats@ietfa.amsl.com>; Mon, 29 Jun 2020 11:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 C-V1FSQDG5B1 for <rats@ietfa.amsl.com>; Mon, 29 Jun 2020 11:34:30 -0700 (PDT)
Received: from p3plsmtpa08-03.prod.phx3.secureserver.net (p3plsmtpa08-03.prod.phx3.secureserver.net [173.201.193.104]) (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 00ED73A0C10 for <rats@ietf.org>; Mon, 29 Jun 2020 11:34:24 -0700 (PDT)
Received: from laurences-mbp.lan ([70.58.199.219]) by :SMTPAUTH: with ESMTPA id pybnjO3vldxNlpybojVbPG; Mon, 29 Jun 2020 11:34:24 -0700
X-CMAE-Analysis: v=2.3 cv=XPZOtjpE c=1 sm=1 tr=0 a=vYbQBYz1awqCo8DrEKtgEg==:117 a=vYbQBYz1awqCo8DrEKtgEg==:17 a=0XtbOteLAAAA:20 a=hBRnNPMDZ0kWKaiq3xkA:9 a=IKBfvZNoeQbITef-:21 a=c7KaBhLyqnBG7McE:21 a=QEXdDO2ut3YA:10 a=xbhRuRAyewH50itxapoA:9 a=Kdi9RpkxgjNDbNfE:21 a=85O3ZxjNsr-8Ey1T:21 a=PVKONA2Qxgr9af6a:21 a=_W_S_7VecoQA:10 a=WQnItmPV2fbdzLaCP6-h:22 a=pHzHmUro8NiASowvMSCR:22 a=Ew2E2A-JSTLzCXPT_086:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D001EE9C-4296-4B01-BFFD-181981872EED"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <878E068C-DAFD-4441-94F7-BA79CAF7FED6@island-resort.com>
Date: Mon, 29 Jun 2020 11:34:23 -0700
To: rats@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-CMAE-Envelope: MS4wfCANtWMDbzckuUQHW/QMbxbLctPfhsLGLzdTHtx2a0F7qGZD1R4OnSPctnXWrA8TT29wCdh8ZXgE+9TphBjNMO/0C76qG/whoD+uymlGlcvYCd4op4mL 4hRJ1lqnRP0Rsm0so/TLDYSVck1EicotHtCrhs6hzRCH4Z86yDVlJ8nK
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/iokP8oZ6VMuPt2PI6WCXyhCmQHE>
Subject: [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, 29 Jun 2020 18:34:39 -0000

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://github.com/ietf-rats-wg/architecture/pull/94>  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://github.com/ietf-rats-wg/architecture/pull/94> and issue <https://github.com/ietf-rats-wg/architecture/issues/65> 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