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

Carl Wallace <> Tue, 23 October 2018 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46B2A130E92 for <>; Tue, 23 Oct 2018 12:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ubCKKB6XFWMf for <>; Tue, 23 Oct 2018 12:04:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95A99130E1D for <>; Tue, 23 Oct 2018 12:04:55 -0700 (PDT)
Received: by with SMTP id p6-v6so1580572qkg.1 for <>; Tue, 23 Oct 2018 12:04:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=+Ulzq+b0I5iR6URsMhzKL1T+D7yY3RFLRXHZJsnkGfs=; b=dxPSFb9DURn0Z63Yg7hRZy160Wq/VNvf//YvfaK5ccj5YzqctYKlPmCKYYiqa5kyQp Y7ZpTc0W2lGm0CvqCeQRxTO/t354oWJahRD3zPKd63Gpgu7ZZxZCKA1J5x30/X3/JZNJ SvHiqk4tIqC7tgKfH9DV0+OpwSfmUC/Kc7+nc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=+Ulzq+b0I5iR6URsMhzKL1T+D7yY3RFLRXHZJsnkGfs=; b=FlfWFzUhiTBpwJfc4yDZzl4b+4AWbXxX6CfwGLxxRpsf8+KCD3XoKbnHFmCVd8pZn4 g+ssEL+PU2ddU6Hf4HyLAkDPAwKkCvbhhWaVG8vSf/0YZ0b/s5e6thlOVjiHianmXMkG vx0glRmqNocafE/UhygnH/TS+xYi7D5U9tS2eALyPYnDtLeOi5H2K/bzsTqpUH3zsZRX V6OAAq95lP+d4F8AwvrJMLXhpxBqK5ToUjhyir9wFao5eJWTJWBOFATYqR7Qq4lsidND MNf2Z1lGN+jAki+2M7JY101epECVHkQFZJC4ghdtuw62qcR8OMLEHkwCbRT73UDx3o0T CI1g==
X-Gm-Message-State: ABuFfoiPzloakGJyyvQN3i5wd9H2wqigvlVFARctQW1pWSO3tRWpb8Tr FFmwtnCxiCPg6+vF6I/ObOmqmA==
X-Google-Smtp-Source: ACcGV62bav63S9rizgNCbPUPvLrBA8AhW8+ay+uP533QAnImxicR3yv6JyZGwqUer9K43UHri4CwzQ==
X-Received: by 2002:a37:9a55:: with SMTP id c82-v6mr46970010qke.153.1540321494449; Tue, 23 Oct 2018 12:04:54 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id q51-v6sm2919982qtq.6.2018. (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 23 Oct 2018 12:04:53 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Tue, 23 Oct 2018 15:04:43 -0400
From: Carl Wallace <>
To: "Smith, Ned" <>, Jeremy O'Donoghue <>
CC: Michael Richardson <>, "" <>, "" <>
Message-ID: <>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
References: <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3623151892_17738363"
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:04:59 -0000


From:  "Smith, Ned" <>
Date:  Tuesday, October 23, 2018 at 2:49 PM
To:  Carl Wallace <>om>, Jeremy O'Donoghue
Cc:  Michael Richardson <>ca>, ""
<>rg>, "" <>
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:
> <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.

[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.