[EAT] some sample attesations

"Smith, Ned" <ned.smith@intel.com> Fri, 07 September 2018 00:38 UTC

Return-Path: <ned.smith@intel.com>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B13130EC7 for <eat@ietfa.amsl.com>; Thu, 6 Sep 2018 17:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 MLJQLlU0iShi for <eat@ietfa.amsl.com>; Thu, 6 Sep 2018 17:38:21 -0700 (PDT)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 4233912F295 for <eat@ietf.org>; Thu, 6 Sep 2018 17:38:21 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2018 17:38:19 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.53,340,1531810800"; d="scan'208,217"; a="87887744"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga001.fm.intel.com with ESMTP; 06 Sep 2018 17:38:18 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.80]) by ORSMSX110.amr.corp.intel.com ([169.254.10.41]) with mapi id 14.03.0319.002; Thu, 6 Sep 2018 17:38:18 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: "eat@ietf.org" <eat@ietf.org>
Thread-Topic: [EAT] some sample attesations
Thread-Index: AQHURkMSKwUoup/xSUSxlRl3mPGlWQ==
Date: Fri, 07 Sep 2018 00:38:18 +0000
Message-ID: <69CAE3B5-0522-45D0-B488-4DE82A454144@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-originating-ip: [10.252.200.249]
Content-Type: multipart/alternative; boundary="_000_69CAE3B5052245D0B4884DE82A454144intelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/otBc6rAO7EVqQCHvnkau4bwnoBU>
Subject: [EAT] some sample attesations
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Sep 2018 00:38:23 -0000

It may be useful to distinguish between key attestation (the environment that protects keys during storage and/or use) and environment attestation where other trust relevant code could execute. It is often the case that trusted code is needed beyond crypto algorithms. For example, boot code, SW update and distributed consensus code might be relevant for ‘trusted environments’ where attestation evidence might be presented and checked in a timely way.

I’m not suggesting key attestation is less important code, only that it doesn’t end here. Nevertheless, starting here might make sense.
-Ned

|I've been working with key attestations for the past few months targeting
|a few different platforms in support of certificate issuance. I posted a
|collection of attestation artifacts, corresponding X.509 certificates and
|trust anchors for use in verifying the attestations here:
|https://github.com/Purebred/SampleAttestations. In most cases, the
|attestations were encoded as attributes in SCEP requests.