With my Chair-Hat on, I will start with some observations about this adopted WG 
document.

This document has existed since 2019 with no substantial movement in the past 
few years.

The Call For Adoption thread from 2020 was fairly lack-luster:
https://mailarchive.ietf.org/arch/msg/acme/YSHlwHpNbsdQdMrEO5Vo88aKs7Y/
I also went through the ACME minutes from 2019 - 2020 and I don't see 
significantly more discussion there either (though I may have missed something).

The WG is carrying this milestone:
Jul 2024          End user client and code signing certificates extension 
submitted to IESG or abandoned         draft-ietf-acme-client



Alright, so how do we make progress either towards publication or abandonment?
Let me ask the two questions:


**Rough Consensus Question**: Who has read the draft? How does the WG feel 
about adding ACME Challenge modes for OTP, TOTP, HOTP, Client Cert, and 
WebAuthn that act in place of the usual DNS and HTTP challenge modes? Is this 
considered a friendly change to the ACME protocol?

**Running Code Question**: This document is tagged Standards Track, which 
places a reasonable burden on its maturity and deployability;
"""
Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.
""" [RFC 2026]

I personally believe that changing ACME from requiring in-band-proof-of-control 
to allowing authenticated-with-out-of-band-proof-of-identity is a significant 
behaviour change, so I would like to ask the implementation and operational 
experience question.

Who is committed to implement this? What implementation experience do we have 
with open source ACME clients and commercial ACME servers supporting these new 
authentication challenge types? Is the draft mature and robust in how the new 
mechanisms cover industry needs?
It was mentioned to me privately that several commercial vendors have an 
interest in implementing this draft. I would like to see those vendors to come 
forward on this thread and describe the level of maturity of their 
implementation.

- - -
Mike Ounsworth
Software Security Architect
(pronouns: he/him)





Any email and files/attachments transmitted with it are intended solely for the 
use of the individual or entity to whom they are addressed. If this message has 
been sent to you in error, you must not copy, distribute or disclose of the 
information it contains. Please notify Entrust immediately and delete the 
message from your system.

_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to