[Rats] using symmetric keys in an Endorsement/Verifier flow

Michael Richardson <mcr@sandelman.ca> Fri, 05 February 2021 21:39 UTC

Return-Path: <mcr@sandelman.ca>
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 92CDE3A0B9B for <rats@ietfa.amsl.com>; Fri, 5 Feb 2021 13:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 R0V3j93-4BBl for <rats@ietfa.amsl.com>; Fri, 5 Feb 2021 13:39:35 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9533A0CF8 for <rats@ietf.org>; Fri, 5 Feb 2021 13:39:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5A8FC3899E for <rats@ietf.org>; Fri, 5 Feb 2021 16:42:00 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AEUyDHUO_hJn for <rats@ietf.org>; Fri, 5 Feb 2021 16:41:59 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DFB4038999 for <rats@ietf.org>; Fri, 5 Feb 2021 16:41:59 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6E9DB430 for <rats@ietf.org>; Fri, 5 Feb 2021 16:38:59 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: rats@ietf.org
In-Reply-To: <31999.1612560697@localhost>
References: <31999.1612560697@localhost>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 05 Feb 2021 16:38:59 -0500
Message-ID: <1568.1612561139@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/d1iJn43H1fRtnWmCvKDE7l4ar3E>
Subject: [Rats] using symmetric keys in an Endorsement/Verifier flow
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: Fri, 05 Feb 2021 21:39:38 -0000

In https://github.com/ietf-rats-wg/architecture/issues/162 it was argued that
we needed to be clear that:

  "Endorsements should have confidentiality protection when carrying
  symmetric verification keys. "

but, many of the Architecture Design Team didn't feel that the architecture
was intended to provide any kind of specification on Endorsements.
Within the dataflow diagram:
  https://www.ietf.org/archive/id/draft-ietf-rats-architecture-09.html#dataflow
  (attached below, for those who use a fixed-width font)
That only the "Evidence" and "Attestation Results", which are between
solid-lined entities was really in scope.  That the rest was for future
documents.

We felt that this requirement went into the Design Requirements which the
IETF usually tries to stay out of, sticking to Functional Requirements.
Further, we felt that the Functional Requirements in the RATS Architecture
should not even cover Endorsements.
At least, not in this edition of the document.

The recommendation is that those who need to do Endorsements with symmetric
verifification keys should write another document in which this topic would
get adequately dealt with.



  ************   *************    ************    *****************
  * Endorser *   * Reference *    * Verifier *    * Relying Party *
  ************   * Value     *    *  Owner   *    *  Owner        *
     |           * Provider  *    ************    *****************
     |           *************          |                 |
     |                  |               |                 |
     |Endorsements      |Reference      |Appraisal        |Appraisal
     |                  |Values         |Policy           |Policy for
     |                  |               |for              |Attestation
     .-----------.      |               |Evidence         |Results
                 |      |               |                 |
                 |      |               |                 |
                 v      v               v                 |
               .---------------------------.              |
        .----->|          Verifier         |------.       |
        |      '---------------------------'      |       |
        |                                         |       |
        |                              Attestation|       |
        |                              Results    |       |
        | Evidence                                |       |
        |                                         |       |
        |                                         v       v
  .----------.                                .---------------.
  | Attester |                                | Relying Party |
  '----------'                                '---------------'