Re: [Anima] [lamps] [Acme] Long-lived certificates, but frequently renewed certificates

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 20 March 2021 17:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FDF3A2703; Sat, 20 Mar 2021 10:39:22 -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 F6nYIxLu4xjs; Sat, 20 Mar 2021 10:39:20 -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 0AC6D3A2701; Sat, 20 Mar 2021 10:39:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F124389AA; Sat, 20 Mar 2021 13:45:00 -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 U0B0fh2nRKws; Sat, 20 Mar 2021 13:44:59 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D26EF389A1; Sat, 20 Mar 2021 13:44:59 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B4F3F240; Sat, 20 Mar 2021 13:39:17 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: John Gardiner Myers <jgmyers=40proofpoint.com@dmarc.ietf.org>
cc: spasm@ietf.org, acme@ietf.org, anima@ietf.org
In-Reply-To: <55529652-7455-8bfb-6436-7b269be4a421@proofpoint.com>
References: <20210318130241.A6B44389A8@tuna.sandelman.ca> <22886.1616091336@localhost> <55529652-7455-8bfb-6436-7b269be4a421@proofpoint.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: Sat, 20 Mar 2021 13:39:17 -0400
Message-ID: <31484.1616261957@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/R6Z10FUmLkBIVq4OT0y5kdnjFvs>
Subject: Re: [Anima] [lamps] [Acme] Long-lived certificates, but frequently renewed certificates
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Mar 2021 17:39:23 -0000

John Gardiner Myers <jgmyers=40proofpoint.com@dmarc.ietf.org> wrote:
    > On 3/18/21 11:15 AM, Michael Richardson wrote:
    >> As far as I know, the only signal for when to renew is notAfter.
    >> Generally, one should renew sometimes after the half-way point.
    >> (LetsEncrypt policy of 90 days, but discouraged to renew until 60 days)
    >>
    >> It seems that a CA ought to be able to express some other kind of renewal
    >> period directly.   Is there any work in this area?

    > I would frame this in terms of impending revocation. Consider the case, as
    > has happened in the past, where a CA discovers that there is a problem with
    > some or all of the previously issued certificates requiring the CA to revoke
    > said certificates within a few days. How can the ACME client managing renewal
    > learn from the CA of the need to renew prior to the revocation, so to avoid a
    > service interruption?

Would this signal occur at the time of issuance, or are you thinking that it
would occur some time into the validity period?

    > I believe this problem is within the scope of  the ACME WG's charter, but
    > would require someone with CA experience to propose an ACME extension.

In the environments I are talking about, if ACME is involved, it is because
we have a Registrar managing the enrollment (and having access to do the
DNS-01 updates), as described in acme-integrations.

In some cases, the Registrar and the device might communicate using
   https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/
and so the Registrar can effectively (and asynchronously) push a new
certificate to devices.
In other cases, the Registrar is passive, and so we need to get the devices
to in effect, poll the Registrar frequently enough to be effective, but no so
frequently as to be annoying.  We do not have, in RFC7030 or est-coaps, any
kind of clear "go away for a week" message.

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