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

Laurence Lundblade <lgl@island-resort.com> Thu, 25 October 2018 14:11 UTC

Return-Path: <lgl@island-resort.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 DA364128A6E for <eat@ietfa.amsl.com>; Thu, 25 Oct 2018 07:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 iTwNieszXr_H for <eat@ietfa.amsl.com>; Thu, 25 Oct 2018 07:11:32 -0700 (PDT)
Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149BA124408 for <eat@ietf.org>; Thu, 25 Oct 2018 07:11:32 -0700 (PDT)
Received: from 2405-9800-ba10.44.pool1.tls1b-bcr02.myaisfibre.com ([184.22.84.59]) by :SMTPAUTH: with ESMTPSA id FgMAgrVBosYcLFgMCgpFO2; Thu, 25 Oct 2018 07:11:31 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <D7F73FD8.C4179%carl@redhoundsoftware.com>
Date: Thu, 25 Oct 2018 21:11:26 +0700
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <662EFF28-BC29-4C1F-BB00-086D449D6F0A@island-resort.com>
References: <0199DB00-E76E-4664-BE02-E2AF4F4B6AEC@intel.com> <526BB5AC-60A8-4CD3-95F4-39F210E4D2FB@island-resort.com> <D7F73FD8.C4179%carl@redhoundsoftware.com>
To: Carl Wallace <carl@redhoundsoftware.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfBkeRlfSsjm8EfiEIOKctP77cBCDxk3Gy4ZaFM7NFoZQSlBX7eUKccg7QPErWdFWLKLX1X3g44rWexwET4y8ZO6mJ5MzdpSZ1yUJAVNbpo6A95FCszXF bVDpy8JvOVXVNvXAeo0sM3OtGocR+DA6MglweyjhFTeG7UZtrKyRXwkqKTLbiHD3B+RwD8euLNV7nffOqxw56LcNDJyePtkq90LSH7obVvx4nZa9ml9PMgW3 787HvZAag+FFUEbm00USnUSmglgOoV8OP1Akg6PoIiVDhDXIAXPy/UquGHdU+6GIz996J2tpZfhb+2CWoQHI8Irt9Lm/fXrw730DNzVO6Nv/q3cGImFI18Hf CM3eK+b5Kppofh6d4WWfKjogaJUqpwHRnzy546mLWHccEgte+6PKlQBUXr2IKiZPINklO/pMf8KPLMrP7i5MAzgnaEVkMQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/hID1TxbmWeU2lnnf8zv_h4j78aM>
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 14:11:34 -0000

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

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? 

Agreed that we might actually have to do this since there is no CBOR format CSR (yet). 

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? 

I would hope we can avoid CMS and creating ASN.1 syntax for every claim we define.

LL