Re: [lamps] [Anima] RFC8994/8995 requirements for CSRattr

Dan Harkins <dharkins@lounge.org> Fri, 03 September 2021 17:35 UTC

Return-Path: <dharkins@lounge.org>
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 9760A3A261F; Fri, 3 Sep 2021 10:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EgbRWGaqtRQo; Fri, 3 Sep 2021 10:35:36 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 14D143A265E; Fri, 3 Sep 2021 10:35:33 -0700 (PDT)
Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QYV15R7DCV81Z@wwwlocal.goatley.com>; Fri, 03 Sep 2021 12:35:32 -0500 (CDT)
Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QYV007DOCNZ5Y@trixy.bergandi.net>; Fri, 03 Sep 2021 10:31:12 -0700 (PDT)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 03 Sep 2021 10:31:12 -0700
Date: Fri, 03 Sep 2021 10:35:30 -0700
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <1351.1630688419@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Eliot Lear <lear@lear.ch>, David von Oheimb <nl0@von-Oheimb.de>, 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
Message-id: <299c0161-f991-134c-1891-182687fb6659@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-language: en-US
Content-transfer-encoding: 8BIT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local)
References: <26149.1630260692@localhost> <1dec22e1-3856-4df7-21d6-4ad6c94e0ee2@lounge.org> <13498.1630308106@localhost> <0a744c63-464b-9801-2a46-9853af1efb0c@lounge.org> <479b3595-cb44-8ece-aa80-4f30a2cdafce@lear.ch> <285e354a-8b5f-7ab4-0e03-20d06328d897@von-Oheimb.de> <da2ce36c-3756-f4c0-7907-a5976d492a82@lear.ch> <ce27e660-6636-b44b-9599-954e9f1ec085@von-Oheimb.de> <d7377093-54c0-3577-f42d-5d410d307eaf@lear.ch> <1351.1630688419@localhost>
X-PMAS-Software: PreciseMail V3.3 [210903] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/HJOhJ9CdsNIl5K8U9XdO9k4S6pQ>
X-Mailman-Approved-At: Fri, 03 Sep 2021 11:28:48 -0700
Subject: Re: [lamps] [Anima] 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: Fri, 03 Sep 2021 17:35:41 -0000

   Hello,

On 9/3/21 10:00 AM, Michael Richardson wrote:
> I'm unclear if CMP allows for a standardized way to override the CSR
> contents, or if it simply provides more authority for the RA to create a new
> CSR of its own.

   Well not really override, more like augment. As I understand it, the 
device
in this case does not know the subjectAltName that the RA wants to be 
included
in the CSR so it's unlikely that the CSR would have a subjectAltName 
(assuming
the RA didn't ask for one in the CSRAttrs) that would need to be 
overridden.

   But I'm not clear about what CMP allows either so there's that.

> While I would also prefer to enhance the RA/CA protocol, I'm not entirely
> keen on mechanisms that break the original PoP.

   Agreed, but keep in mind that the CA has no idea whether the 
challengePassword
field is correct or not so the assurance that the CA has that it is 
really this
device that produced the CSR is through the RA vouching for it. The RA 
does the
due diligence that the CA requires to issue a certificate. That being 
the case,
how much is lost through the RA vouching for the entire thing?

> Anyway, we are going to enhance the CSRattr description to support all the requirements.

   Indeed. So it's probably moot anyway.

   I really think the more elegant solution would be the RA augmenting 
the CSR with
a little bit of goo. But that requires CAs to understand augmented CSRs 
that have
goo and there are practical considerations to rolling out a solution 
here that compel
the use of CSRAttrs.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius