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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 03 September 2021 20:08 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 400B53A2C12; Fri, 3 Sep 2021 13:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ogK8T-2JTsz; Fri, 3 Sep 2021 13:08:43 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B203A2C14; Fri, 3 Sep 2021 13:08:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 26A3A393B3; Fri, 3 Sep 2021 16:14:46 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Nnp6POt7lswt; Fri, 3 Sep 2021 16:14:40 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AC4F1393B2; Fri, 3 Sep 2021 16:14:40 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EA5C9AC; Fri, 3 Sep 2021 16:08:33 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: spasm@ietf.org, anima@ietf.org
In-Reply-To: <299c0161-f991-134c-1891-182687fb6659@lounge.org>
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> <299c0161-f991-134c-1891-182687fb6659@lounge.org>
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: <https://mailarchive.ietf.org/arch/msg/spasm/91jVU-gPb1DHd0NMl07i0hKLcuM>
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 20:08:50 -0000

{Trimming massive CC to just lists}

Dan Harkins <dharkins@lounge.org> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide