IETF Logo Mail Archive

Re: [EAT] [Rats] Attestation BoF charter updates?

"Smith, Ned" <ned.smith@intel.com> Tue, 23 October 2018 18:49 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 B3C3C130EEC; Tue, 23 Oct 2018 11:49:16 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 CkRhho8OD3FX; Tue, 23 Oct 2018 11:49:14 -0700 (PDT)
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (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 7C31B130E1D; Tue, 23 Oct 2018 11:49:14 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 11:49:14 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.54,417,1534834800"; d="scan'208,217"; a="80335590"
Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by fmsmga007.fm.intel.com with ESMTP; 23 Oct 2018 11:49:14 -0700
Received: from orsmsx116.amr.corp.intel.com (10.22.240.14) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 23 Oct 2018 11:49:13 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.251]) by ORSMSX116.amr.corp.intel.com ([169.254.7.58]) with mapi id 14.03.0319.002; Tue, 23 Oct 2018 11:49:13 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Carl Wallace <carl@redhoundsoftware.com>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "eat@ietf.org" <eat@ietf.org>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUavNRF3KZGpU4TEGGfYgrNJhz76UtFauAgAB27AD//5+qAA==
Date: Tue, 23 Oct 2018 18:49:12 +0000
Message-ID: <FFA0BB14-48AB-45CE-8D7A-53D43821FC7D@intel.com>
References: <D7F4B1E4.C3BF8%carl@redhoundsoftware.com> <D0C08E47-DBB6-4AAD-95EF-F952155D3152@qti.qualcomm.com> <581DD29C-85D9-4BD8-A0EE-41761ED773B4@intel.com> <D7F4D350.C3CFF%carl@redhoundsoftware.com>
In-Reply-To: <D7F4D350.C3CFF%carl@redhoundsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [10.24.14.158]
Content-Type: multipart/alternative; boundary="_000_FFA0BB1448AB45CE8D7A53D43821FC7Dintelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/y4x8EjyuZFkbcDbesI4q-ubk16E>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
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: Tue, 23 Oct 2018 18:49:17 -0000


On 10/23/18, 10:34 AM, "EAT on behalf of Carl Wallace" <eat-bounces@ietf.org<mailto:eat-bounces@ietf.org> on behalf of carl@redhoundsoftware.com<mailto:carl@redhoundsoftware.com>> wrote:

<snip>

It would be interesting to understand your thinking a bit further. At one level it is fairly straightforward to define a claim whose value contains an X.509 certificate, but I suspect that binding may imply more than that.
[nms] It is also reasonable to consider an X.509 certificate as being an object that contains a set of claims (rather than the other way around).
[cw] Not if the goal is to prevent issuance of a certificate because provenance of a key cannot be confirmed. Having a self-issued cert contain claims is fine, but this does not obviate the need to bind to issuance protocols to inform CA issuance.
[nms] I wasn’t asserting that a certificate would be self-issued. This is why I think it makes sense to talk about a claimant. SP800-164 refers to this as either a ‘device owner’ or ‘information owner’. I’m OK with these terms too. The expectation is the device owner during manufacturing  (aka mfg’r) will know which trust relevant claims can be asserted. They could assert them by issuing a certificate containing the claims. The verifier/relying party trusts the mfg’r to be an authoritative source regarding how a device (but more precisely, how the root-of-trust) was made. If a key is created during mfg time and the mfg issues evidence (aka a certificate) of that, then it serves as provenance as long as the verifier / relying party trusts the manufacturer to correctly embed the key. Confirmation can be achieved via manual inspection of the manufacturing process. Nevertheless, the verifier is trusting the mfg to a certain degree.

                This thread is about formats (X.509/ASN.1, CBOR etc…). The semantics of what a signature means is (should be) common across all the formats IMO. If self-signed claims are invalid, then they should be invalid for any encoding whether it is ASN.1, CBOR or something else. If they are valid for something else, then the signature should be valid for alternative formats too.
<snip>

v2.23.0 | Report a Bug | By Email