[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 | '----------' '---------------'
- [Rats] how does the Verifier work Michael Richardson
- [Rats] using symmetric keys in an Endorsement/Ver… Michael Richardson
- Re: [Rats] how does the Verifier work Henk Birkholz
- Re: [Rats] using symmetric keys in an Endorsement… Smith, Ned
- Re: [Rats] using symmetric keys in an Endorsement… Laurence Lundblade
- Re: [Rats] how does the Verifier work Simon Frost
- Re: [Rats] using symmetric keys in an Endorsement… Russ Housley