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 <[email protected]>
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 <
> [email protected]> 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:[email protected]] *On Behalf Of *Daniel
>> McCarney
>> *Sent:* fredag 20. oktober 2017 22:36
>> *To:* IETF ACME <[email protected]>
>> *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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme