Re: [Acme] Survey of draft-07 implementations

Daniel McCarney <cpu@letsencrypt.org> Thu, 02 November 2017 14:07 UTC

Return-Path: <dmccarney@letsencrypt.org>
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 49C6413F87F for <acme@ietfa.amsl.com>; Thu, 2 Nov 2017 07:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
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 NUEfe_3jiGFo for <acme@ietfa.amsl.com>; Thu, 2 Nov 2017 07:07:00 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB39813F723 for <acme@ietf.org>; Thu, 2 Nov 2017 07:06:59 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id b186so14210089iof.8 for <acme@ietf.org>; Thu, 02 Nov 2017 07:06:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UFwICP6NMELx4GctohnzuKXUCxVMV0PUk1a80FN7aMQ=; b=c9ohmnzg+eFjguKDkxfuBgmeiGoi2yOs5aHM/QOPQM1Um0yIMVqzIy0uyswvayXTUT Var6roilhKPfRjyze61FH0ZnxjeaJl+/lL8pZhMKpYwQtCymhsj9+GstmXb3WN2aczRl wXzbVPa37nI3dURr5M9RG5PygDtl6/mhrseyo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=UFwICP6NMELx4GctohnzuKXUCxVMV0PUk1a80FN7aMQ=; b=s/Y61atRDGgj6evjRAy2+iYHnIBoM1nL3Yb4+5PRX5AmEY29ak8FGgLaJJeybqHN6V 00J2sM6/jX6t/csIGlf/F7YeLSNIXrEZS+pgHfkTf7GUfSFhqkQmVDX9ZRccptQsO/b9 njNdYM7SqBuatFIPItKUCzsmtTV/ogciM0mgBndJtcImMd86t32Zkb0ugpoLQd2egOfQ HarcpkeBRQO1Tlm3ntiYzyT4cZEg4LNPQ74U5oB+6/C8JIipSNqqfJZ8ePSEqh0Kl7SM 2fYx3Jy49RzEoOsA0ElR2TOeF4oPp3KstneZTRmhOhsgfsiIWrhZQpHjlPQF+dIDZu43 pF0g==
X-Gm-Message-State: AMCzsaUstUf3FWXQUCbyO1TTV9klx3ldw2OjtlVOInDitt/KP8lgahIg fNpK8qhfLOumqzfCkV8U7fAu+KKZuWnfdB8echj3NA==
X-Google-Smtp-Source: ABhQp+SLQG+NwycE6oQzU6uuKIZVoA3JRD1Kzm2kur6V48GFnX2ekok75JhSaxKfbUSbGi9F9/0VdVcZP2ZEjZzHrpo=
X-Received: by 10.107.43.75 with SMTP id r72mr4612323ior.31.1509631619199; Thu, 02 Nov 2017 07:06:59 -0700 (PDT)
MIME-Version: 1.0
Reply-To: cpu@letsencrypt.org
Received: by 10.107.88.21 with HTTP; Thu, 2 Nov 2017 07:06:58 -0700 (PDT)
In-Reply-To: <CAJ=cBg16mwR-+K1AOQwLRjwYgDOFY2-EcXmrZSkyqGNUNFHDXw@mail.gmail.com>
References: <CAKnbcLgmmH3aM=Ko2qCvHQLAdo0jw+dumYj4kRxBOkjwm+UOhg@mail.gmail.com> <e81bedc777c340f58c1f43205129a6f2@Buyp-gvk-ex01.intra.buypass.no> <CAJ=cBg16mwR-+K1AOQwLRjwYgDOFY2-EcXmrZSkyqGNUNFHDXw@mail.gmail.com>
From: Daniel McCarney <cpu@letsencrypt.org>
Date: Thu, 02 Nov 2017 10:06:58 -0400
Message-ID: <CAKnbcLheRH0CdihWH331qLPUuWKUDqEyEBj3UDkrKnStJS0dbA@mail.gmail.com>
To: Clint Wilson <clint.t.wilson@gmail.com>
Cc: Mads Egil Henriksveen <Mads.Henriksveen@buypass.no>, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="001a113949f0679330055d00802c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/plkSOjgMR1qAQVOxFmfuCT7VRX0>
Subject: Re: [Acme] Survey of draft-07 implementations
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 02 Nov 2017 14:07:02 -0000

So far it sounds like there are no implementations of the OOB challenge
type. Given the feedback from Clint about the external account binding
feature being sufficient for their needs so far is there a strong reason to
include OOB challenges at all?

If I remember the discussion right this challenge type was added
specifically to facilitate non-ACME "legacy" CAs. So far a call for
implementations has heard from two such CAs and neither have implemented
OOB challenges or have a fixed schedule for when they might.
Perhaps it would be better to remove OOB challenges from the specification
and treat it as follow-up work once there are implementations and CAs
expressing interest in deploying them? I think this would be preferable to
finalizing the standardization of a mechanism that no one has implemented
("Rough consensus and running code"...).

(As an aside: Have any ACME **clients** implemented External Account
Binding or OOB challenges? Server support is only 1/2 of the battle)

- Daniel / cpu

On Sat, Oct 21, 2017 at 4:15 PM, Clint Wilson <clint.t.wilson@gmail.com>
wrote:

> Hi team!
>
> DigiCert has implemented a proof of concept ACME server using ACME
> draft-07. We utilize External Account Binding, but not Out-of-Band
> Challenges nor Pre-Authorization, though both are of potential interest to
> us in the future. We currently handle both of those by way of the External
> Account Binding, which provides the full context of a customer account, and
> therefore has the support of Pre-Authorization functions and our
> Support/Validation teams to assist with Out-of-Band Challenges. Our
> interest in ACME would be the potential complete automation of those steps,
> but given the available workaround, we opted to not focus on supporting
> that yet.
>
> Cheers!
> -Clint
>
>
> On Sat, Oct 21, 2017 at 12:56 AM Mads Egil Henriksveen <
> Mads.Henriksveen@buypass.no> wrote:
>
>> Hi
>>
>>
>>
>> Buypass has implemented an ACME server based on ACME draft-07 which use
>> order based issuance, this version is currently available in a test
>> environment only. We are also running a constrained pilot in our production
>> environment (supporting CertBot) and this will be upgraded to the ACME
>> draft-07 version shortly.
>>
>>
>>
>> We have included support for Pre-Authorization, but we are not using
>> neither External Account Binding nor the Out-of-Band Challenge in our
>> current version. However, we are considering to use the Out-of-Band
>> Challenge type and possibly also External Account Binding in a next phase
>> where the idea is to exploit how the ACME protocol may be used to support
>> issuance and administration of other types of TLS certificates than DV.
>>
>>
>>
>> Regards
>>
>> Mads
>>
>>
>>
>> *From:* Acme [mailto:acme-bounces@ietf.org] *On Behalf Of *Daniel
>> McCarney
>> *Sent:* fredag 20. oktober 2017 22:36
>> *To:* IETF ACME <acme@ietf.org>
>> *Subject:* [Acme] Survey of draft-07 implementations
>>
>>
>>
>> Hi folks,
>>
>>
>>
>> As the WG approaches last-call on ACME draft-07[0] I wanted to get a
>> sense of which portions of the spec have been implemented and which haven't.
>>
>>
>>
>> In particular I'd like to hear if anyone has implemented:
>>
>> * External Account Binding (Section 7.3.5)
>>
>> * Pre-Authorization for Order based issuance (Section 7.4.1)
>>
>> * The Out-of-Band Challenge type (Section 8.6)
>>
>>
>>
>> Let's Encrypt has made good progress on draft-07 server implementation
>> but has no plans to implement the above three features. It would be nice to
>> hear someone has running code for these protions of spec.
>>
>>
>>
>> Ignoring the above three items Let's Encrypt has implemented the core
>> portions of draft-07 in Pebble[1]. It's presently using the pro-active
>> issuance method described in draft-07. It does not support key change or
>> revocation but is ready to be used by clients. There is an integration test
>> client[2] based on Certbot's ACME python module and ACME4j has an
>> experimental branch[3] capable of issuing certificates from Pebble.
>>
>>
>>
>> Let's Encrypt has also made significant progress implementing draft-07 in
>> Boulder[4], the production Let's Encrypt CA software, but it is not yet
>> ready for use by clients. This implementation does include key change and
>> revocation but does **not** use pro-active issuance. I began a separate
>> thread[5] for the order finalization approach that we have started to
>> implement for Boulder. Pebble will be updated to use this issuance approach
>> in place of pro-active issuance shortly.
>>
>>
>>
>> Are there any other servers or clients out there that are speaking
>> draft-07 ACME and using order based issuance?
>>
>>
>>
>> - Daniel / cpu
>>
>>
>>
>> [0]: https://tools.ietf.org/html/draft-ietf-acme-acme-07
>>
>> [1]: https://github.com/letsencrypt/pebble
>>
>> [2]: https://github.com/letsencrypt/boulder/blob/
>> e2cc6fbe682dd5d49da32c2357838b0cc831f10f/test/chisel2.py
>>
>> [3]: https://github.com/shred/acme4j/tree/draft
>>
>> [4]: https://github.com/letsencrypt/boulder
>>
>> [5]: https://mailarchive.ietf.org/arch/msg/acme/
>> DIjJEB06J5cFyuOlGPVcY2I51vg
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>