Re: [lamps] RFC8994/8995 requirements for CSRattr

Eliot Lear <lear@lear.ch> Mon, 30 August 2021 07:41 UTC

Return-Path: <lear@lear.ch>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B0C3A188B; Mon, 30 Aug 2021 00:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level:
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 VKzz8bccR3fU; Mon, 30 Aug 2021 00:41:16 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 919F73A189B; Mon, 30 Aug 2021 00:41:12 -0700 (PDT)
Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:fd91:725d:1a4b:4b31]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17U7ekPb073213 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 30 Aug 2021 09:40:46 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1630309246; bh=Ul5awECVJffl/3VwXwNOw7F+dQmLyygxa+SZZs6PXLs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=m47i0kI5CU43ytGwZjuQCgRwwimVtUDvLlEA3AXSga0bEeacDGpvUEd57KtHiTWQ8 Y6hKXiBr3v0pg0WR/XjQJvFFHMKXnaoWviBjoRi6fWoDfojuhCBuAZOsJvrqwOzZA1 gb0SPTqnnwCoOk9eEYG/h5qaUl1sfthZ/GeqDiFc=
To: Dan Harkins <dharkins@lounge.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Owen Friel <ofriel@cisco.com>, Peter van der Stok <stokcons@bbhmail.nl>, max pritikin <pritikin@cisco.com>, Toerless Eckert <tte@cs.fau.de>, Esko Dijk <esko.dijk@iotconsultancy.nl>, spasm@ietf.org, Thomas Werner <thomas-werner@siemens.com>, anima@ietf.org
References: <26149.1630260692@localhost> <1dec22e1-3856-4df7-21d6-4ad6c94e0ee2@lounge.org> <13498.1630308106@localhost> <0a744c63-464b-9801-2a46-9853af1efb0c@lounge.org>
From: Eliot Lear <lear@lear.ch>
Message-ID: <479b3595-cb44-8ece-aa80-4f30a2cdafce@lear.ch>
Date: Mon, 30 Aug 2021 09:40:46 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <0a744c63-464b-9801-2a46-9853af1efb0c@lounge.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="h9a1rfzA5Jb4bdhOjPAApA1lR7FZnjiMf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/v8ujINJ02tZReS5OSmst1j5bD_Q>
X-Mailman-Approved-At: Mon, 30 Aug 2021 08:12:53 -0700
Subject: Re: [lamps] RFC8994/8995 requirements for CSRattr
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Aug 2021 07:41:32 -0000

I would suggest that it helps in these cases to back up to the scenarios 
we care to address, and the likelihood of success.  In some cases, it 
will be possible to coordinate development with the endpoints and 
sometimes with the CAs.  The CAs may not be strongly motivated to 
standardize an out-of-band/underlay RA/CA interface**- some already have 
proprietary versions, and may like that with the hope of locking in the 
endpoints along the way.

Eliot