IETF Logo Mail Archive

Re: [Rats] name of identity key

"Smith, Ned" <ned.smith@intel.com> Mon, 02 December 2019 20:00 UTC

Return-Path: <ned.smith@intel.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 3889012003F for <rats@ietfa.amsl.com>; Mon, 2 Dec 2019 12:00:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HOsd0NEQ6VYR for <rats@ietfa.amsl.com>; Mon, 2 Dec 2019 11:59:59 -0800 (PST)
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 9329A120018 for <rats@ietf.org>; Mon, 2 Dec 2019 11:59:59 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2019 11:59:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,270,1571727600"; d="scan'208";a="235604270"
Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by fmsmga004.fm.intel.com with ESMTP; 02 Dec 2019 11:59:56 -0800
Received: from orsmsx161.amr.corp.intel.com (10.22.240.84) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 2 Dec 2019 11:59:55 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX161.amr.corp.intel.com ([169.254.4.96]) with mapi id 14.03.0439.000; Mon, 2 Dec 2019 11:59:56 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
CC: Guy Fedorkow <gfedorkow@juniper.net>, "pritikin@cisco.com" <pritikin@cisco.com>, Jessica Fitzgerald-McKay <jmfmckay@gmail.com>, Henk Berkholz <henk.birkholz@sit.fraunhofer.de>, William Bellingrath <wbellingrath@juniper.net>
Thread-Topic: name of identity key
Thread-Index: AdWg4nF8kDHIJtSESNGSE2qU3LjHXACxnocAABHLSQAAVuhUAAAEzmSAACg1IIAA0tI4gA==
Date: Mon, 02 Dec 2019 19:59:55 +0000
Message-ID: <C4E5F9D5-3E15-4366-8848-199D4E50A334@intel.com>
References: <BYAPR05MB4248D3AE10BAA7E74D588E76BA490@BYAPR05MB4248.namprd05.prod.outlook.com> <32083.1574668598@dooku.sandelman.ca> <1E5F7794-BA58-4D6D-928A-4B0E9C227B69@intel.com> <11202.1574848474@dooku.sandelman.ca> <A52561C0-95BD-4D16-98B9-25A375C41F16@intel.com> <16604.1574925807@dooku.sandelman.ca>
In-Reply-To: <16604.1574925807@dooku.sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [10.24.10.58]
Content-Type: text/plain; charset="utf-8"
Content-ID: <09D6B79558528443BDFB357683BBADF6@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/LM1Kfnq0RjXE_3IARoB9sI8Box4>
Subject: Re: [Rats] name of identity key
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, 02 Dec 2019 20:00:01 -0000


On 11/27/19, 11:37 PM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:

        nms> Maybe it makes sense to talk about how the keys are used rather than trying to name them?
    
    Well, I think that having it named "the key we use for Onboarding" is the
    same as saying, "Onboarding Key", right?
[nms] Right. I thought you were looking for names such as "IDevID". It could be the IDevID is the onboarding key or that the attestation key is the onboarding key. Somehow the onboarding protocol selects which key is used if both are available.
    
    I don't know how the manufacturing process that involves a TPM with a TPM
    attestation key works.  I just know that when doing BRSKI, that there were
    issues with being confused between various TPM keys, and we originally wrote
    text saying that the device Serial Number might be in weird places.  We later
    ripped that text out, as time had changed things, and I'm worried that this
    issue is not really dead.
[nms] There is still a possibility for a bootstrapping sequence post factory shipment where "the onboarding key" doesn't yet exist. Therefore, pre-onboarding is required to provision the onboarding key. This may be what you describe as "the device Serial Number might be in weird places".

v2.23.0 | Report a Bug | By Email