IETF Logo Mail Archive

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

Carl Wallace <carl@redhoundsoftware.com> Thu, 25 October 2018 14:43 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 28347130E5A for <eat@ietfa.amsl.com>; Thu, 25 Oct 2018 07:43:41 -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=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 mOxXjRzi7HPJ for <eat@ietfa.amsl.com>; Thu, 25 Oct 2018 07:43:38 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 259C3130E67 for <eat@ietf.org>; Thu, 25 Oct 2018 07:43:38 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id g13-v6so5841915qke.8 for <eat@ietf.org>; Thu, 25 Oct 2018 07:43:37 -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=fHvbesJK9fkxR8lEwdidWbI5dn8DyrWjc4MoomrInbc=; b=P6wp8/ukH6MGqCF8Z56+vHgmIzGVbDwjqXqVlQ6o1ekKVHmvIUDutuVfRGxwQtpYpI 7jXXdBEDv3rNasb0dMtDr59HkAro25KkrOVsfBxW/pagMUfTU6ffBx3NtusdwdmSppnn hSDlYbktwDiAx5tbK2oauqhD49TqLmaHKDVYc=
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=fHvbesJK9fkxR8lEwdidWbI5dn8DyrWjc4MoomrInbc=; b=meG340AnJovS384crEtPm/0fQIcdgzt/cnARWEoc4NZFo2RCYj8MEanz1JQ+ar4hOq k65siYjWJL3rj9K4WypWs7OEgx2qchgGza30ssGfBuHHkmikGpauq7xwHXF1NnNCJ26R wxyNH7nNbXkpxACUoejWshV8lBSUxFr9buYU/j7oEM0nk0C53DhpSZ9HsTtPf8a0u2jQ Yq5GjaCINhYmJKuQCHY18Zrw9Bx88ByyKuf3ouGxd7EvmreRxADrP67c50SBFOyDnPGI XGrbeLh/1w7EKju750UN21TJa3XIEEQzVnz+yMalDscDfQN7LFNGaOQ7AyPfE+jnHztw 321g==
X-Gm-Message-State: AGRZ1gIndtCBXmIaYIRwcsNiUnZV9fdxzF5XNtM9kt5Jtk9kB7m6/EZG AtpDhQ6RCrIkyoWGhrtPAb4B/w==
X-Google-Smtp-Source: AJdET5eAvR3W5cMV7fd9ynHiGOk/wViHvofs6McJWP6d9YfdRfSISWfBLw/UoxcfYAUTMLsJ8Xmn8g==
X-Received: by 2002:a37:1fc8:: with SMTP id n69mr1718519qkh.175.1540478616750; Thu, 25 Oct 2018 07:43:36 -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 s21-v6sm6441640qth.11.2018.10.25.07.43.32 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 25 Oct 2018 07:43:36 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Thu, 25 Oct 2018 10:43:27 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Marcus Streets <Marcus.Streets@arm.com>, Laurence Lundblade <lgl@island-resort.com>, "Smith, Ned" <ned.smith@intel.com>
CC: "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: <D7F74E2C.C419F%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> <AM0PR08MB3265E49DC63AE37B63FF52088CF70@AM0PR08MB3265.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB3265E49DC63AE37B63FF52088CF70@AM0PR08MB3265.eurprd08.prod.outlook.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/zfE71Je_yIl-tbxLzyzO-KOW64M>
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:43:41 -0000

The point is not an alternative certificate format, but to define the
binding between of an attestation with a certificate request.

On 10/25/18, 10:35 AM, "Marcus Streets" <Marcus.Streets@arm.com> wrote:

>That is an argument for never fixing anything.
>
>We can define a CBOR format for certificates and recommend people use it.
>If that creates a need, service providers will offer to sell certificates
>in the correct format.
>
>
>
>-----Original Message-----
>From: EAT <eat-bounces@ietf.org> On Behalf Of Carl Wallace
>Sent: Thursday, October 25, 2018 2:47 PM
>To: Laurence Lundblade <lgl@island-resort.com>; Smith, Ned
><ned.smith@intel.com>
>Cc: Eric Voit (evoit) <evoit@cisco.com>; Jeremy O'Donoghue
><jodonogh@qti.qualcomm.com>; eat@ietf.org; Michael Richardson
><mcr+ietf@sandelman.ca>; rats@ietf.org; Henk Birkholz
><henk.birkholz@sit.fraunhofer.de>
>Subject: Re: [EAT] [Rats] Attestation BoF charter updates? - Program of
>Work section
>
>
>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.
>
>
>_______________________________________________
>EAT mailing list
>EAT@ietf.org
>https://www.ietf.org/mailman/listinfo/eat
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person, use it for any purpose, or store or copy
>the information in any medium. Thank you.

v2.23.0 | Report a Bug | By Email