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

"Smith, Ned" <> Tue, 23 October 2018 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3B61130E5C; Tue, 23 Oct 2018 12:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0lkD-4zQkRzQ; Tue, 23 Oct 2018 12:55:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75256130E1B; Tue, 23 Oct 2018 12:55:29 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 12:55:28 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.54,417,1534834800"; d="scan'208,217"; a="84994731"
Received: from ([]) by with ESMTP; 23 Oct 2018 12:55:28 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 23 Oct 2018 12:55:27 -0700
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Tue, 23 Oct 2018 12:55:27 -0700
From: "Smith, Ned" <>
To: Carl Wallace <>, Jeremy O'Donoghue <>
CC: Michael Richardson <>, "" <>, "" <>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
Thread-Index: AQHUavNRF3KZGpU4TEGGfYgrNJhz76UtFauAgAB27AD//5+qAIAAebSA//+YzgA=
Date: Tue, 23 Oct 2018 19:55:26 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_FCF1711D49364D35A75D84B88C076151intelcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Oct 2018 19:55:32 -0000

On 10/23/18, 12:04 PM, "Carl Wallace" <<>> wrote:


From: "Smith, Ned" <<>>
Date: Tuesday, October 23, 2018 at 2:49 PM
To: Carl Wallace <<>>, Jeremy O'Donoghue <<>>
Cc: Michael Richardson <<>>, "<>" <<>>, "<>" <<>>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?

On 10/23/18, 10:34 AM, "EAT on behalf of Carl Wallace" <<> on behalf of<>> wrote:


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.

[CW] You are referring to a certificate issued to the device by the manufacturer. I am referring to certifying keys generated by a hardware crypto module on the device once it is in the hands of a user.  I don't disagree the verifier must trust the manufacturer when verifying the attestation, I am suggesting that the verifier is a CA who will have plucked an attestation from a certificate management message and will, amongst other checks that need to be standardized, confirm the public key in the certificate request corresponds to a claim in the attestation.
[nms] Right. In order for the CA (verifier) to distinguish the certifying key is an ‘attestable key’ vs. a traditional CSR. The CA should look for a signature from the mfg cert over the CSR (certificate management message?) containing the generated public key. I’m still not seeing where there is a self-signed (issued) certificate in the equation.