Re: [Acme] IETF 107; agenda

Michael Richardson <> Mon, 09 March 2020 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 153263A03FA for <>; Mon, 9 Mar 2020 14:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xe39HHZXmmWt for <>; Mon, 9 Mar 2020 14:46:35 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1EDE3A0765 for <>; Mon, 9 Mar 2020 14:46:34 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 21A453818F; Mon, 9 Mar 2020 17:45:21 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 622409F9; Mon, 9 Mar 2020 17:46:32 -0400 (EDT)
From: Michael Richardson <>
To: "Salz\, Rich" <>
cc: "acme\" <>, Alexey Melnikov <>, Mary Barnes <>
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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-sha256; protocol="application/pgp-signature"
Date: Mon, 09 Mar 2020 17:46:32 -0400
Message-ID: <13284.1583790392@localhost>
Archived-At: <>
Subject: Re: [Acme] IETF 107; agenda
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2020 21:46:45 -0000

Salz, Rich <> wrote:
      > Yaron and I cannot attend and will be remote.  We have volunteers to
      > act as chairs for us (on CC).  Looking at the list below, it seems
      > reasonable to cancel our session.  PLEASE POST IF YOU DISAGREE.  Of
      > course "they" may decide to cancel anyway, but please post your
      > opinion here.

Hi, if you are going to cancel (I would prefer NOT to), then please schedule
    a virtual interim for early April to replace it.

    > draft-ietf-acme-authority-token-04, ACME Challenges Using an Authority Token -and-
    > draft-ietf-acme-authority-token-tnauthlist-05,  TNAuthList profile of ACME Authority Token
    > Any update from the authors?  Is this ready for WGLC?
    > This has never had much in-person discussion, and the domain expertise is in STIR

I have read this document when it came up in STIR, and I don't think that
here is much to say about this.  Is there feedback from implementers? I don't
think that this needs face time to advance.

    > draft-ietf-acme-client-00, ACME End User Client and Code Signing Certificates
    > Any updates?  This was recently adopted by the WG.

no idea.

    > draft-ietf-acme-integrations-00, ACME Integrations
    > Michael Richardson can present.

I was given some slides (wasn't I Owen? Or did you just say that you'd send
some), and the major item was to clarify the changes that were made based
comments.   I think that there isn't much to say.   I have running code that
integrates ACME with a BRSKI Registrar.

    > draft-friel-acme-subdomains-02
    > Michael Richardson can present; this is a topic for WG adoption

At first, I think that we thought that this work required no standard action,
because it was within the server's policy to do this or not.
However, the client may not know the server's policy, and so section 5 adds
the basedomain and implicitSubdomainAuthorization boolean.  If it comes back
false (or missing), then the client knows it has to perform authorizations for
every request (which is what my code above does).

I think that the WG previously expressed interest in adopting it, pending
some changes, and those changes are made.  It may not need actual WG time,
except that having it on a schedule sometimes gets a document read :-)

    > draft-ietf-acme-email-smime-06, Extensions to Automatic Certificate
    > Management Environment for end user S/MIME certificates
    > Any updates?  Ready for WGLC?

    > draft-ietf-acme-star-delegation-03, An ACME Profile for Generating Delegated STAR Certificates
    > Yaron just pushed a new update.  Does this need F2F time?  The main
    > document (draft-ietf-acme-star-11,  Support for Short-Term,
    > Automatically-Renewed (STAR) Certificates in Automated Certificate
    > Management Environment (ACME) is already in IESG review and probably
    > wants this one to be in the same bundle.)

I think both are ready to be adopted.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-