Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 08 June 2021 20:15 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0153A3C67 for <acme@ietfa.amsl.com>; Tue, 8 Jun 2021 13:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 rDSR3qPzfl1B for <acme@ietfa.amsl.com>; Tue, 8 Jun 2021 13:15:39 -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 A1E513A3C6A for <acme@ietf.org>; Tue, 8 Jun 2021 13:15:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CC4C838CCA; Tue, 8 Jun 2021 16:16:22 -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 xYwHOPEXPIDI; Tue, 8 Jun 2021 16:16:18 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 99DEF38CC0; Tue, 8 Jun 2021 16:16:18 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A1B3675B; Tue, 8 Jun 2021 16:15:33 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Owen Friel (ofriel)" <ofriel=40cisco.com@dmarc.ietf.org>, Deb Cooley <debcooley1@gmail.com>, "acme@ietf.org" <acme@ietf.org>, "Cooley, Dorothy E" <decoole@nsa.gov>
In-Reply-To: <MW3PR11MB4746D8B59EBD417CBAB690F5DB379@MW3PR11MB4746.namprd11.prod.outlook.com>
References: <CAGgd1Od3apxOznaSdBqg-y+Ut=amR3jPrzBdOXfzPV=AHq6Rww@mail.gmail.com> <MW3PR11MB4746D8B59EBD417CBAB690F5DB379@MW3PR11MB4746.namprd11.prod.outlook.com>
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: Tue, 08 Jun 2021 16:15:33 -0400
Message-ID: <21679.1623183333@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/62xjF3_G7uMvLbKuvTE8U10kJBs>
Subject: Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2021 20:15:46 -0000

Owen Friel \(ofriel\) <ofriel=40cisco.com@dmarc.ietf.org> wrote:
    deb> Again architecture:  If the EST Server sits in front of a large
    deb> organization, then domain validation is more interesting, and the
    deb> Get /csrattrs may or may not be able to recommend a SAN, right?  I
    deb> can see that policy oids could be provided, if that is a thing in
    deb> these systems.  [we use policy oids in US DOD, but that is possibly
    deb> uncommon elsewhere.]

    ofriel> That is also a fair point, for complex deployments its not clear
    ofriel> what policy the EST server may want to apply before assigning a
    ofriel> SAN. The text in section 3 currently states:

    “EST servers could use this mechanism to tell the client  what fields to
    include in the CSR Subject and Subject Alternative  Name fields”

    ofriel> We could beef up that statement and explicitly state that the
    ofriel> policy by which the EST determines the SAN to specify is
    ofriel> explicitly out of scope. And also note that policy OIDs could be
    ofriel> provided.

I would love to hear from operators and designers of CAs about how a
RA can communicate to the CA about things it doesn't like, or wishes to add,
to a certificate request.

The CSR is immutable, being signed by the EE requesting.
ACME doesn't provide any out-of-CSR mechanism, nor does CMC or CMP (correct
me if I'm wrong here!)...  Max and I talked a lot about this when design RFC8995,
and we had to conclude that it was simply non-standard.

In the case of ACP (RFC8994) use of BRSKI, like the Ford Model-T, the CSR may
contain anything the Pledge wants to put in, it will get an otherName
containing the encoded ACP IPv6 ULA.

In implementing, I also realized that the GET /csrattrs is pseudo-idempotent.
When first called, it needs to allocate an IPv6 ULA for that node, and it
needs to store it, such that whenever the same IDevID does the GET, it gets
the same answer.  It's uncomfortable having to change database state on a
GET, but at least the result is cachable!

In the ACME integrations, we haven't said how the RA will decide what dNSName
SAN will be returned, but the same property will apply.  The RA needs to
collect a CSR that it can pass along up ACME, and for which is can do dns-01
challenges.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide