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

Carl Wallace <carl@redhoundsoftware.com> Tue, 23 October 2018 19:04 UTC

Return-Path: <carl@redhoundsoftware.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 46B2A130E92 for <eat@ietfa.amsl.com>; Tue, 23 Oct 2018 12:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
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 ubCKKB6XFWMf for <eat@ietfa.amsl.com>; Tue, 23 Oct 2018 12:04:55 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A99130E1D for <eat@ietf.org>; Tue, 23 Oct 2018 12:04:55 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id p6-v6so1580572qkg.1 for <eat@ietf.org>; Tue, 23 Oct 2018 12:04:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; 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; d=1e100.net; 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 [192.168.2.27] (pool-108-28-91-61.washdc.fios.verizon.net. [108.28.91.61]) by smtp.googlemail.com with ESMTPSA id q51-v6sm2919982qtq.6.2018.10.23.12.04.50 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 23 Oct 2018 12:04:53 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Tue, 23 Oct 2018 15:04:43 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: "Smith, Ned" <ned.smith@intel.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>
Message-ID: <D7F4E84F.C3D97%carl@redhoundsoftware.com>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates?
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> <FFA0BB14-48AB-45CE-8D7A-53D43821FC7D@intel.com>
In-Reply-To: <FFA0BB14-48AB-45CE-8D7A-53D43821FC7D@intel.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3623151892_17738363"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/X4dwWlG3nc-_omGH3jksfqb57tI>
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 19:04:59 -0000

Inline..

From:  "Smith, Ned" <ned.smith@intel.com>;
Date:  Tuesday, October 23, 2018 at 2:49 PM
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>;
Subject:  Re: [EAT] [Rats]    Attestation BoF charter updates?

>  
>  
> 
> On 10/23/18, 10:34 AM, "EAT on behalf of Carl Wallace" <eat-bounces@ietf.org
> on behalf of 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.

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