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

Michael Richardson <> Fri, 03 September 2021 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 400B53A2C12; Fri, 3 Sep 2021 13:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ogK8T-2JTsz; Fri, 3 Sep 2021 13:08:43 -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 15B203A2C14; Fri, 3 Sep 2021 13:08:42 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26A3A393B3; Fri, 3 Sep 2021 16:14:46 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id Nnp6POt7lswt; Fri, 3 Sep 2021 16:14:40 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id AC4F1393B2; Fri, 3 Sep 2021 16:14:40 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id EA5C9AC; Fri, 3 Sep 2021 16:08:33 -0400 (EDT)
From: Michael Richardson <>
In-Reply-To: <>
References: <26149.1630260692@localhost> <> <13498.1630308106@localhost> <> <> <> <> <> <> <1351.1630688419@localhost> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 03 Sep 2021 16:08:33 -0400
Message-ID: <18736.1630699713@localhost>
Archived-At: <>
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 20:08:50 -0000

{Trimming massive CC to just lists}

Dan Harkins <> wrote:
    >> 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?

In the ACME/RFC8555 case, it seems to me that the CA could provide a challengePassword.
I don't believe that this occurs today, but it seems like we ought to
anticipate this as a future event.

    >> 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 agree.  I'd like to see a RA->CA protocol that augments rather than replaces.
I agree that this takes time, but

Michael Richardson <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide