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

David von Oheimb <> Sun, 05 September 2021 13:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 862233A1658; Sun, 5 Sep 2021 06:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1cKesDvllsRC; Sun, 5 Sep 2021 06:09:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80FF33A1656; Sun, 5 Sep 2021 06:09:18 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6C0034217B9; Sun, 5 Sep 2021 15:09:14 +0200 (CEST)
To: Michael Richardson <>, Eliot Lear <>, Dan Harkins <>, Owen Friel <>, Peter van der Stok <>, max pritikin <>, Toerless Eckert <>, Esko Dijk <>,, Thomas Werner <>,
References: <26149.1630260692@localhost> <> <13498.1630308106@localhost> <> <> <> <> <> <> <1351.1630688419@localhost>
From: David von Oheimb <>
Message-ID: <>
Date: Sun, 5 Sep 2021 15:09:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <1351.1630688419@localhost>
Content-Type: multipart/alternative; boundary="------------156F33D36BDB6F2C645283E8"
Content-Language: en-US
Archived-At: <>
X-Mailman-Approved-At: Sun, 05 Sep 2021 06:52:04 -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: Sun, 05 Sep 2021 13:09:26 -0000

On 03.09.21 19:00, 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.
CMP does not offer a direct/explicit "override" mechanism for CSRs, but
it is foreseen that an RA checks a CSR and then modifies it, using the
RAVerified option instead of the typical signature-based PoP.
This is one of the use cases we describe in more detail in our new
Lightweight CMP profile - see
BTW, CMP also offers a variety of further forms of PoP, for keys that do
not have the capability for signing - see

With EST this is not possible simply because it uses the rather limited
PKCS#10 format, which requires self-signature, which is not possible at
the RA (even for keys that can be used for signing) because it does not
have the needed private key. In other words, PKCS#10 and thus EST does
not support on-behalf CSRs.

> While I would also prefer to enhance the RA/CA protocol, I'm not entirely keen on mechanisms that break the original PoP.
Yeah, I also prefer avoiding this - as long as the overhead to the EEs
is bearable.

For cases where the PoP is broken by an intermediate entity, CMP cert
request message may contain the original (unmodified) CSR for reference
purposes - see

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

Good to have this option then in the future.