Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section

Carl Wallace <carl@redhoundsoftware.com> Thu, 25 October 2018 15:06 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 ACFC0127133 for <eat@ietfa.amsl.com>; Thu, 25 Oct 2018 08:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7V6jO-YbHn5M for <eat@ietfa.amsl.com>; Thu, 25 Oct 2018 08:06:45 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 BE50C130E6A for <eat@ietf.org>; Thu, 25 Oct 2018 08:06:44 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id b22-v6so1199442qtr.11 for <eat@ietf.org>; Thu, 25 Oct 2018 08:06:44 -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:content-transfer-encoding; bh=119jJuIvtLEeN6N1h3NpaRls5guOJXN8BizxuHS9JBk=; b=RuOljfFV9kGcA5uXARH30jYOLy/bJNU1V0ZYayJE5fUZ2gSkMpzBYYEM2zpFybvXeM VrIuTjSRsv5m9Dr2ZcaEPULlkPcYcmjX+h1IGi0kw4+gUMgwBQPYIJ06T/NHTunA7K1q WqL5Uta6yAuZ+9JYRY3a8IAf2w6Dga+CSd9TE=
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 :content-transfer-encoding; bh=119jJuIvtLEeN6N1h3NpaRls5guOJXN8BizxuHS9JBk=; b=rzQZdPBmWvyVyGq4TLoFkQtSCkg9pMts5C9U2WMcEaVuz8WatW4yzR/E0u2as+Uunc Qo3ED7t9WyoGQ2COvqk6aeknN2SDLQeiNa3Zv0+r5QHr+q7f+CO3BQHJSz6Y4WM0oGMM HXO/NvNpCZXtp1yNWxmc97rlEYs2RvCa4xibB2Dsh+3DgGmnQF59i1F4j4MSKE1yNqDG qFoPTex5DRX1Nza+wc9FfZrZkfuxN3rUAtOaywxfCTWlWpDlQetOF56abjPcxoRpgJTr jmXdwe81WvN1YUTl+gWmlllU4Zhfzkw6uYyVv5530KT+HNl81EILi4y0J+EeL139PwKY 9Qpg==
X-Gm-Message-State: AGRZ1gLYac3y7qA7QT+A2F067qk5mX1ASL8SpKP0EcYxl7bA5EZ84PNk /25q4j82Oi1NvEaY98b5B5l8yA==
X-Google-Smtp-Source: AJdET5c8iCmecjgX+CvgjdWuEV52Z0eVxA5BppcWf3tNnYhmpJlnmE/5XEbD+4cxBzu+IoIbiJLE4g==
X-Received: by 2002:a0c:9311:: with SMTP id d17mr1962188qvd.54.1540480003701; Thu, 25 Oct 2018 08:06:43 -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 h49-v6sm6349731qth.32.2018.10.25.08.06.37 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 25 Oct 2018 08:06:42 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Thu, 25 Oct 2018 11:06:31 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Laurence Lundblade <lgl@island-resort.com>
CC: "Smith, Ned" <ned.smith@intel.com>, "Eric Voit (evoit)" <evoit@cisco.com>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, "eat@ietf.org" <eat@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <D7F74EE1.C41A5%carl@redhoundsoftware.com>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section
References: <0199DB00-E76E-4664-BE02-E2AF4F4B6AEC@intel.com> <526BB5AC-60A8-4CD3-95F4-39F210E4D2FB@island-resort.com> <D7F73FD8.C4179%carl@redhoundsoftware.com> <662EFF28-BC29-4C1F-BB00-086D449D6F0A@island-resort.com>
In-Reply-To: <662EFF28-BC29-4C1F-BB00-086D449D6F0A@island-resort.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/AKfYhKLogUqxKkVTpW2-qmM1-wQ>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section
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: Thu, 25 Oct 2018 15:06:48 -0000


On 10/25/18, 10:11 AM, "Laurence Lundblade" <lgl@island-resort.com>; wrote:

>
>> On Oct 25, 2018, at 8:47 PM, Carl Wallace <carl@redhoundsoftware.com>;
>>wrote:
>> 
>> 
>> On 10/25/18, 9:15 AM, "RATS on behalf of Laurence Lundblade"
>> <rats-bounces@ietf.org on behalf of lgl@island-resort.com>; wrote:
>> 
>>> <snip>
>>> 
>>> So I am making some argument against ASN.1 and anything beyond JSON and
>>> CBOR.  The more formats there are the more work the relying parties
>>>will
>>> have to do and of course some won’t implement all the formats and then
>>> we’ll have less interop.
>> 
>> [CW] At least where the claims are related to cryptographic keys, ASN.1
>>is
>> likely unavoidable as it's part of the environment. Avoiding it is not
>> likely to help interop.
>
>
>For an attestation in the vein of EAT you have a series of claims that
>are signed. The sane thing to do is pick one format and apply it all the
>way through. The claims are in JOSE format and you sign with JWT. The
>claims are in CBOR and you sign with COSE. The claims are ASN.1 and you
>sign in CMS.
[CW] It may shake out such that the claims I care about could be ASN.1
from top to bottom but I doubt it. Mixing formats doesn't seem like a
problem. Base64 encodings of DER encoded structures are quite common in
XML and JSON, for example. Including COSE or JOSE structure as an
attribute in an ASN.1 structure seems fine too.
> 
>
>It would be possible to have something like a PKCS10 CSR stuffed into a
>CBOR byte string in a CBOR/COSE format attestation, but the overall
>format of the attestation is CBOR/COSE. Maybe this is what you are after?

[CW] Not exactly. The CSR would contain a mix of data that is originated
by/protected by a hardware component and data that is external (e.g.,
challenge password). It's not clear to me orchestrating including the P10
in the attestation is the right path. Including a signed claim about key
provenance in a standard cert request seems sufficient and easy enough.
>
>Agreed that we might actually have to do this since there is no CBOR
>format CSR (yet).

[CW] Not sure why that would be required. There was earlier mention of not
boiling the ocean, trying to recast everything as CBOR doesn't seem wise.
> 
>
>I can also see having to use X.509 for establishing trust in signing keys
>since there is no CBOR format for certificates (yet). Jim Schaad was
>working on extensions to COSE for this.
>
>Any other examples?

[CW] I shared a pile of examples via GitHub some weeks back -
https://github.com/Purebred/SampleAttestations. I will add Pixel 3
artifacts soon. I am not suggesting these as a basis for standardization,
but as illustrative of how attestations are used in certificate requests
in some environments. At present, w.r.t. demonstrating key provenance, we
are using:
	- Android attestations (X.509 certificates that chain to a specific root
represented as a certs-only SignedData),
	- Yubikey attestations (X.509 certificates that chain to a specific
rootrepresented as a certs-only SignedData) and
	- Surface Pro TPM attestations (CMC requests that wrap a mix of TCG and
Microsoft structures).

[CW] Each of these is attached to a SCEP request as an attribute. The
attestations are verified and the public key from the attestation is
compared to the public key in the SCEP request. We have another variant
that does use CBOR for some claims. In that case the Google attestation
certificate is included in the CBOR similar to your description above but
the CBOR layer isn't demonstrating key provenance in this case. SCEP, CMC
and EST all use similar attributes. It is not unlikely that a single spec
defining one or more attributes to convey attestations could be shared by
all three. 
> 
>
>I would hope we can avoid CMS and creating ASN.1 syntax for every claim
>we define.

[CW] I can't imagine this would be necessary.
>
>LL
>
>