IETF Logo Mail Archive

Re: [Last-Call] [Teep] Artart last call review of draft-ietf-teep-architecture-16

Carl Wallace <carl@redhoundsoftware.com> Mon, 11 April 2022 13:08 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E970E3A0F05 for <last-call@ietfa.amsl.com>; Mon, 11 Apr 2022 06:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 MOzuzOWpz3td for <last-call@ietfa.amsl.com>; Mon, 11 Apr 2022 06:08:41 -0700 (PDT)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 E3DE13A0F09 for <last-call@ietf.org>; Mon, 11 Apr 2022 06:08:40 -0700 (PDT)
Received: by mail-qv1-xf2a.google.com with SMTP id b17so13130983qvf.12 for <last-call@ietf.org>; Mon, 11 Apr 2022 06:08: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=1pfATqe9yeyvdq+dp6vySUHQmIYQiKxaJ335CRwSoY0=; b=TCDBiMlkgiQ2eSCwGnDU19ZK9QVIrW4O5YLCphMgqjncZPjYz5Ohe9ngdhqvoXZazq e4NwID2+YBGQzV8AEDAxI8UB+lKhrkBO+0PahSH969GeudAOvjW2f0FEZAGDifvzHA8U cxxi8WcgNQg/JLv5LKmyiOxMyFxgDfk55krDQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=1pfATqe9yeyvdq+dp6vySUHQmIYQiKxaJ335CRwSoY0=; b=Qb8bIlNSrZjqfVjypUI7KDsbovPwiNswICzkJ1nB6GoerT6LkbFgkHy/H0Dpgda/YR qU8TXg8E1aLjiBy1//e+uq5IbepIsywsSjjOHZztC4v1woa/qcQIK9r4+Fyr6rp7IQk/ u33pEw6+85wUEqeD76HoYWYNI6t3htk50y9o1eTIchAN4mKFrcQpwKSWV0ZLNwe0WrPf noF0pPaGivWvPtsiY4SqpbdoL1z5qof9EIsxkS9I117Q4z3GdfOG5M19qJh5njonTbNU +YrHXdBNJ2WSYUyVbEEx093wD7T1Pot9jq336fwrDpq7KzpVDH8r603HfIH9DL254eSs DKRg==
X-Gm-Message-State: AOAM531/S/TyUSMKwOTOJFdO/zXqviNhp73svfs2bNkvD42PtdI83ZcM Ge1OA5+gXAJhC+6r0Gf+FOlIWw==
X-Google-Smtp-Source: ABdhPJyhPwfgpmcWdNKmFsDZzoci4ej85pjMu3Mdozbc30YlO7GK0LMAwnz5lifC0lJu45FMXY/THA==
X-Received: by 2002:a05:6214:2aa9:b0:443:d8d3:5b77 with SMTP id js9-20020a0562142aa900b00443d8d35b77mr26947501qvb.85.1649682518863; Mon, 11 Apr 2022 06:08:38 -0700 (PDT)
Received: from [192.168.2.16] (pool-173-66-88-168.washdc.fios.verizon.net. [173.66.88.168]) by smtp.gmail.com with ESMTPSA id h8-20020ac87d48000000b002e1c6faae9csm25539674qtb.28.2022.04.11.06.08.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Apr 2022 06:08:38 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.59.22031300
Date: Mon, 11 Apr 2022 09:08:37 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Mingliang Pei <mingliang.pei=40broadcom.com@dmarc.ietf.org>, Russ Housley <housley@vigilsec.com>
CC: "art@ietf.org" <art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "teep@ietf.org" <teep@ietf.org>, "draft-ietf-teep-architecture.all@ietf.org" <draft-ietf-teep-architecture.all@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Message-ID: <05D72290-98A8-4DA9-9E90-88AC12E76D63@redhoundsoftware.com>
Thread-Topic: [Teep] [Last-Call] Artart last call review of draft-ietf-teep-architecture-16
References: <164850526406.21554.6982960206540476351@ietfa.amsl.com> <DBBPR08MB5915B3398715EE22DF06BEBFFA1E9@DBBPR08MB5915.eurprd08.prod.outlook.com> <CABDGos6QOEabsz1YfQ_X2uQkQm+9L1WdynksTsTD+T26y_UNXQ@mail.gmail.com> <F88F6DC2-B2AE-45AF-B68E-1A1C75C575EA@vigilsec.com> <CABDGos4QOf+GS5JFbK50D6PORFb=UqpfAzjxSp5xcQLCSoub6Q@mail.gmail.com> <CABDGos5fBpe8eLNB1xtZM_qo4gxkUQMBiFNqFh=ag+tvW2gOkw@mail.gmail.com>
In-Reply-To: <CABDGos5fBpe8eLNB1xtZM_qo4gxkUQMBiFNqFh=ag+tvW2gOkw@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3732512918_1867013320"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/awlhQcWZpBBGRbTPG7DaZUVR8V4>
Subject: Re: [Last-Call] [Teep] Artart last call review of draft-ietf-teep-architecture-16
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2022 13:08:47 -0000

 

From: TEEP <teep-bounces@ietf.org> on behalf of Mingliang Pei <mingliang.pei=40broadcom.com@dmarc.ietf.org>
Date: Thursday, April 7, 2022 at 8:40 PM
To: Russ Housley <housley@vigilsec.com>
Cc: Mingliang Pei <mingliang.pei=40broadcom.com@dmarc.ietf.org>rg>, "art@ietf.org" <art@ietf.org>rg>, "last-call@ietf.org" <last-call@ietf.org>rg>, "teep@ietf.org" <teep@ietf.org>rg>, "draft-ietf-teep-architecture.all@ietf.org" <draft-ietf-teep-architecture.all@ietf.org>rg>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Subject: Re: [Teep] [Last-Call] Artart last call review of draft-ietf-teep-architecture-16

 

See PR: https://github.com/ietf-teep/architecture/pull/236, thanks, Ming

 

[CW] Is it a certainty that constraints will not be needed for trust anchors? The trust anchor definition references “associated data”, which would be used constrain use of the trust anchor. An option other than certificate or public key may would be needed if constraints may be defined (because constraints can’t be added to the certificate without breaking the signature and a raw public key has no means to express constraints). Perhaps, "The Trust Anchor may be a certificate, a raw public key or other structure, as appropriate." might be better to leave open the possibility of constraining a trust anchor. RFC5914 defines syntax that allows for associated data to be packaged alongside a public key or a certificate, as an example of an alternative.

 

<snip>

v2.8.7 | Report a Bug | By Email