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

Dan Harkins <> Fri, 03 September 2021 17:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9760A3A261F; Fri, 3 Sep 2021 10:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EgbRWGaqtRQo; Fri, 3 Sep 2021 10:35:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14D143A265E; Fri, 3 Sep 2021 10:35:33 -0700 (PDT)
Received: from ( []) by (PMDF V6.8 #2433) with ESMTP id <>; Fri, 03 Sep 2021 12:35:32 -0500 (CDT)
Received: from blockhead.local ([]) by (PMDF V6.7-x01 #2433) with ESMTPSA id <>; Fri, 03 Sep 2021 10:31:12 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by ([]) (PreciseMail V3.3); Fri, 03 Sep 2021 10:31:12 -0700
Date: Fri, 03 Sep 2021 10:35:30 -0700
From: Dan Harkins <>
In-reply-to: <1351.1630688419@localhost>
To: Michael Richardson <>, Eliot Lear <>, David von Oheimb <>, Owen Friel <>, Peter van der Stok <>, max pritikin <>, Toerless Eckert <>, Esko Dijk <>,, Thomas Werner <>,
Message-id: <>
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 (, send-ip=
X-PMAS-External-Auth: [] (EHLO blockhead.local)
References: <26149.1630260692@localhost> <> <13498.1630308106@localhost> <> <> <> <> <> <> <1351.1630688419@localhost>
X-PMAS-Software: PreciseMail V3.3 [210903] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
X-Mailman-Approved-At: Fri, 03 Sep 2021 11:28:48 -0700
Subject: Re: [lamps] [Anima] RFC8994/8995 requirements for CSRattr
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Sep 2021 17:35:41 -0000


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 
in this case does not know the subjectAltName that the RA wants to be 
in the CSR so it's unlikely that the CSR would have a subjectAltName 
the RA didn't ask for one in the CSRAttrs) that would need to be 

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



"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