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

Carl Wallace <carl@redhoundsoftware.com> Tue, 23 October 2018 17:31 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 1AC26127B92 for <eat@ietfa.amsl.com>; Tue, 23 Oct 2018 10:31:43 -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=ham 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 PJZbUaUo53NR for <eat@ietfa.amsl.com>; Tue, 23 Oct 2018 10:31:41 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 DE258124C04 for <eat@ietf.org>; Tue, 23 Oct 2018 10:31:40 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id z2-v6so2481072qts.1 for <eat@ietf.org>; Tue, 23 Oct 2018 10:31:40 -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=Wm94JiG0vXiZ0RTGcMXG3tyulW37xTYpvUTmiPYMJVc=; b=bhTC2BDaW9xjJAJBf/UNP8ZUAL6HXgAhpuN0uie6CH4Sz7tGqiuRDtlnR7lcKCD8gK l04UmP2gsuhN1xNM/bGkY1bdQqkI7ydADcrT/1OYX8pI1jaUloqURGLf04YSbhJYT1mW KmxmBpjpTwMoozKFabyOX32noUH0x4V6PeQZQ=
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=Wm94JiG0vXiZ0RTGcMXG3tyulW37xTYpvUTmiPYMJVc=; b=eADeAfcLXKihD6o8TXt834JPJYy0vmDoxAVNj1edSNWUiYbyMOZTTvgSN41hzFVoZl xShEMi4+pi+WQSDwToqRz2xZXciNKbgEdm3bWZEdLLP4T1IfHXNm8mnLQmAWYgVeAQ/l PlEaYCgqJk5C97AfMkd+sem7jGLm5RFDsr3sGGzHN/yP8u7tvMjS2McoE+Ox0lPlQAqO j4BcsvobhxIIQA5qDuYEdDxFA96sF4igbnsnverA/5qe+bDP3U9rgiOTdjD+p0QQAiAn x7A5PTDaJHHdmELlK61fCYQTLaHESjAyNT/8I88tsoRhtcWzfj7qmKGPOQDZThj1qqUa nrYA==
X-Gm-Message-State: ABuFfojyCKp6OIgVZWCB9YTY6/k7jepGfzWT2LurFS3eQZrCc6X2i/lR o6CX1YJfIJurdAarnSKBbWWRQg==
X-Google-Smtp-Source: ACcGV60vVyQAvH6d3P79bceUdXBgkEisVX5EECJB6Cn28NRAQqg1VS7B6cEszErcAhzrAI3m3TWZQg==
X-Received: by 2002:a0c:d1d5:: with SMTP id k21mr25207176qvh.156.1540315899866; Tue, 23 Oct 2018 10:31:39 -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 c85-v6sm1152433qke.89.2018.10.23.10.31.35 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 23 Oct 2018 10:31:39 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Tue, 23 Oct 2018 13:31:28 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>, "eat@ietf.org" <eat@ietf.org>
Message-ID: <D7F4D296.C3CF7%carl@redhoundsoftware.com>
Thread-Topic: [Rats] [EAT] Attestation BoF charter updates?
References: <D7F4B1E4.C3BF8%carl@redhoundsoftware.com> <D0C08E47-DBB6-4AAD-95EF-F952155D3152@qti.qualcomm.com>
In-Reply-To: <D0C08E47-DBB6-4AAD-95EF-F952155D3152@qti.qualcomm.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3623146297_17402904"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/LAzGjs0bqt7o6LeWQNtQCjlx5ps>
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 17:31:43 -0000

From:  Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>;
Date:  Tuesday, October 23, 2018 at 1:10 PM
>> On 23 Oct 2018, at 16:14, Carl Wallace <carl@redhoundsoftware.com>; wrote:
>>> <snip>
>>> 
>>> Work Items
>>> 
>>> ----------
>>> 
>>> The Working Group will develop specifications supporting the creation of
>>> interoperable remote attestation procedures for entities which incorporate
>>> Roots of Trust. The main deliverables are as follows.
>>> 
>>> - Produce a requirements document establishing a common vocabulary for
>>> remote
>>>   attestation, identifying mechanisms which will be supported for
>>> establishing
>>>   trust between an entity and a remote party, and enumerating sample
>>> use-cases
>>>   for remote attestation.
>>> 
>>> - Produce specification text defining interoperable cross-platform claims
>>> which
>>>   provide information about an entity in support of the required use-cases,
>>> and
>>>   extending the set of claims defined in RFC7519 and RFC8392. The
>>> specification
>>>   will describe the syntax for each claim in at least the following formats:
>>>     - CBOR [RFC7049]
>>>     - JSON [RFC7159]
>>>     - YANG [RFC6020]
>> 
>> [CW] ASN.1 is already player for a number of attestation formats. Any reason
>> to exclude it?
> 
> None I can technically justify. It seems sensible to have ASN.1 in scope, at
> least in terms of defining the syntax of claims in ASN.1. I am less sure
> whether it makes sense to define signing procedures for ASN1. (since these are
> presumably defined elsewhere), but I could be persuaded (e.g. by the statement
> "no they aren't defined elsewhere - at least not for this important
> use-case").
[CW] I'd not discount CMS not because there aren't mechanisms elsewhere, but
because it's already used in some attestation contexts.
> 
>>> - Produce specification text defining procedures and corresponding
>>> architectures
>>>   supporting verification of claims within an attestation based on measured
>>> file
>>>   execution procedures and supporting:
>>>     - Explicit attestation wherein a set of claims is transported in the
>>> attestation;
>>>     - Implicit attestation wherein a set of claims is implied by possession
>>> of a secret.
>>> 
>>> - Produce specification text defining procedures and corresponding
>>> architectures
>>>   supporting verification of claims encapsulated in:
>>> 
>>>     - CBOR Web Token structures [RFC8392]
>>>     - JSON Web Token structures [RFC7519]
>> 
>> [CW] As noted before, I'd like to see binding to certificate enrollment
>> protocols included here as well. This is something we are doing today,
>> without standards grounding (as illustrated in pile of attestations shared
>> via Github a few weeks back).
> 
> 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.
[CW] My goal is to present an attestation to a CA before a certificate is
issued so the provenance of the key can be confirmed to inform issuance
decisions. I currently do include self-signed X.509 certificates as claims
in attestations, which may be what you meant.
> <snip>
>