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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 926423A17A1; Sun, 5 Sep 2021 06:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zor24k63xoZ9; Sun, 5 Sep 2021 06:41:56 -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 2EC073A17A0; Sun, 5 Sep 2021 06:41:55 -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 EAF2F4217E5; Sun, 5 Sep 2021 15:41:51 +0200 (CEST)
To: Dan Harkins <>, Michael Richardson <>, Eliot Lear <>, 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:41:51 +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: <>
Content-Type: multipart/alternative; boundary="------------4F7D45371B5DB1921EE71214"
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:42:03 -0000

On 03.09.21 19:35, Dan Harkins wrote:
> 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.
I'd say it does not matter whether one calls this 'override' or 'augment'.
The point is that the contents of the cert template in the CSR are
modified (regardless in which way, by changing or adding values).

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

I answered this point in the email just sent.

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


BTW, the use of the challengePassword in EST (and SCEP) is another
weakness - this way the proof-of-orgin crucially depends on its value
not leaking.
The design would have been much more robust if MAC-based protection had
been used instead, as offered, among others, by CMP.

> 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?
I agree there is not much lost - as I wrote before, the RA needs to be
trusted by the CA anyway.

Yet note that using PKCS#10 (as done by EST and SCEP), an on-behalf CSR
is not possible simply because the CSR is required to be self-signed,
which cannot be done by the RA not having the private key of the EE.

> 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.
I don't agree this is elegant. It requires a secondary protocol between
RA and CA just because EST (at least in its current form) is too limited.
In my view it is more straightforward and future-proof to correct the
EST CSRattrs mechanism and/or to use an existing more capable protocol
between RA and CA.