Mike Ounsworth <[email protected]> wrote: > A number of the ACME-related discussions today have had me wondering if > people are trying to evolve ACME to encroach into the functionality space > of EST, and if in fact the right answer to a lot of these usecases is > "Don't use ACME, use EST instead". EST is an HTTP-over-TLS enrollment > protocol that uses TLS client-auth as the fundamental auth mechanism. So > you already have 1/3 of Kathleen's draft as core functionality of EST. You > could add all the OTP stuff by using psk or pake TLS mode. And there's > independent work on attested-tls that would do the webauthn-auth and rats > stuff.
I think that this is a really good point.
I've implemented both in recent years.
I've also implemented Registrars that are EST servers and ACME clients, with
DNS-01 challenges.. draft-ietf-acme-integrations is in MISSREF.
EST isn't any more ASN.1 intense than ACME, although fullcmc can involve
more, but simpleenroll does not. I have implemented all of EST in
RubyOnRails, on top of ruby-openssl.
The only hassle was that the *ruby-openssl* layer was intolerant of OIDs
which OpenSSL didn't know about. That's a bug in that layer, which I fixed.
That is, I did almost no ASN.1 work in ruby.
{That is, until csr-attributes, which isn't necessary for many uses}
I think that ACME is attractive because:
1. Seems to have less ASN.1 than, say, CMP.
2. Has more JSON (which people love)
3. Client-AUTH/MTLS does not trivially get through TLS-load balancers and
frameworks. Trivially. RFC9440 helps. Getting TLS client certificates
through some frameworks, when TLS 1.3 is used, has challenges. But,
doable.
So... ACME does object security, so appears easier to deploy.
I don't know what happens in "managed" environments, where there is a
forced TLS proxy. I imagine that mTLS does not work.
4. EST has no obvious WG. Yes, it's LAMPS now, but it's also busy.
5. yes, EST can do HTTP-level authentication rather than certificate-based
authentication.... this seems less useful. IDevID on devices, and
renewals-with-old-credential motivates mTLS.
I think that Attested-TLS is the wrong direction for adding remote
attestation to EST; I think it might bring unwanted complexity to Attested-TLS.
I could be wrong.
> On Tue, 22 Jul 2025 at 08:20, Mike Ounsworth <[email protected]>
> wrote:
>> I want to say on the list (no-hat), that during today's meeting someone
(Q
>> I believe) pointed out that draft-acme-device-attest also defines a
>> WebAuthn Challenge, and draft-liu-acme-rats does something similar.
>>
>> I believe that these are using WebAuthn for very different purposes:
>>
>> As I understand these drafts, draft-device-attest as using the WebAuthn
to
>> validate control of the requested identifiers. For example, I want a cert
>> with a device serial number in it, and the WebAuthn provides
>> proof-of-control of the device with that serial number.
>>
>> Whereas draft-acme-client is serving usecases like: I go to my CA's web
>> interface and tee up a code-signing cert for "DN=Mike Software Corp,
inc".
>> There's no identity there that can be automatably verified. So instead,
>> draft-acme-client wants the user to be able to set up an MFA ({email /
SMS}
>> OTP, {T/H}OTP, Client Cert, WebAuthn) so that we can strongly link an
ACME
>> request to some setup done previously in, for example, a web browser.
Here
>> we are using WebAuthn as an MFA authentication, not as a
>> proof-of-ownership-of-requested-identifier. In other words, I think it's
>> clear enough that the "pkp-01" challenge type that draft-acme-client is
>> registering is WebAuthn for authentication whereas "device-attest-01"
that
>> draft-acme-device-attest is WebAuthn for proof-of-ownership.
>>
>> So I don't see a conflict between these two drafts; nor do I think these
>> two drafts should attempt to merge.
>>
>> On Tue, 22 Jul 2025 at 04:06, Kathleen Moriarty <
>> [email protected]> wrote:
>>
>>> Hi Mike,
>>>
>>> Thank you for your review!
>>>
>>> I am hoping we get some additional feedback in the session on who will
>>> use this draft. Anecdotally, a few have expressed interest in
>>> this extension for their use cases.
>>>
>>> On Mon, Jul 21, 2025 at 1:01 PM Mike Ounsworth <Mike.Ounsworth=
>>> [email protected]> wrote:
>>>
>>>> Hi ACME!
>>>>
>>>>
>>>>
>>>> I provide this review as an individual, with my Chair-Hat off. I will
>>>> start a separate thread to provide some Chair's questions / comments
on how
>>>> to progress this adopted draft.
>>>>
>>>>
>>>>
>>>> Document / version reviewed: draft-ietf-acme-client-13
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The goal of this document seems to be to extend ACME to support cert
>>>> enrollments where control of the requested identifiers cannot be
verified
>>>> in an automated way in-band in the ACME protocol; particularly, this
seems
>>>> to be in support of issuing certs to cloud workloads and is a
>>>> building-block for the WIMSE WG. Specifically, this draft adds
>>>> authentication challenges to ACME: OTP, Client Cert, and WebAuthn.
>>>>
>>>
>>> Yes, so you have initial authentication to set up the ACME certificate
>>> management and I have heard the WebAuthn and PKI would be useful. I'm
not
>>> certain about the OTP as things have changed since 2019.
>>>
>>>
>>>>
>>>>
>>>> I think this is a reasonable goal, but I don’t think the current draft
>>>> articulates this particularly well; it took me until Section 7 to
realize
>>>> that’s what it’s doing.
>>>>
>>>> So, I suggest that this draft re-brand itself to make the core content
>>>> clearer.
>>>>
>>>>
>>>>
>>>> I would change the title to “ACME Client Authentication Challenges”, or
>>>> something similar.
>>>>
>>> I am fine with this change.
>>>
>>>>
>>>>
>>>> I suggest the abstract be changed
>>>>
>>>> OLD:
>>>>
>>>> Abstract
>>>>
>>>>
>>>>
>>>> Automated Certificate Management Environment (ACME) core protocol
>>>> addresses the use case of web server certificates for TLS. This
document
>>>> extends the ACME protocol to support service account authentication
>>>> credentials, micro-service accounts credentials, device client, code
>>>> signing, document signing certificates and keys.
>>>>
>>>>
>>>>
>>>> NEW:
>>>>
>>>> Abstract
>>>>
>>>>
>>>>
>>>> Automated Certificate Management Environment (ACME) core protocol
>>>> addresses certificate issuance use cases where identity proofing can be
>>>> performed inline, for example verifying
>>>>
>>>
>>> Did you mean online instead of inline?
>>>
>>>
>>>> control of a DNS record or HTTP endpoint. In cases where identity
>>>> proofing is performed out-of-band, then the ACME protocol merely needs
to
>>>> authenticate the certificate requester. This document extends the ACME
>>>> protocol to add OTP, PKI and WebAuthn based authentication Challenges
that
>>>> give a CA greater flexibility in how it authenticates the ACME client.
>>>>
>>>>
>>>>
>>>> I would suggest re-structuring the Intro to start by cleanly defining
>>>> the terms “identity proofing” and “authentication”; explaining that the
>>>> Challenge types in RFC8555 only address inline and automatable identity
>>>> proofing; this draft extends ACME to cover certificate issuance cases
that
>>>> cannot do inline identity proofing by adding Authentication Challenge
types
>>>> so that an ACME Server can authenticate this request against the same
>>>> entity who had previously performed identity proofing via some other
means.
>>>>
>>>
>>> I can scope down the text. Identity proofing does not occur with all
>>> credential types, it depends on the account type and the policy
surrounding
>>> it. Identity proofing may be off-line (in person checking of physical
>>> credentials such as a license) or on-line. I'll think about how to write
>>> this concisely.
>>>
>>>
>>>>
>>>> I would remove the entire sections on Code Signing and Document Signing
>>>> since I think that’s a distraction from the core of the draft – I would
>>>> turn them into a passing “Motivating use cases” paragraph in the
Intro. The
>>>> CSR discussion in these sections is confusing; it says “CSR MUST be
set to
>>>> the correct values for the CA”, but my understanding of RFC8555 –
>>>> particularly the /new-order – is that the CSR is only a container for
the
>>>> public key, and all the actual metadata (requested identifiers,
requested
>>>> cert lifetime) go in the JSON body of the /new-order, so I’m not sure
what
>>>> “correct values” the CSR is supposed to contain? I also worry that
some of
>>>> the normative stuff in the Code Signing and Document Signing sections
could
>>>> come into conflict with CA/B Forum or ETSI requirements for Code
Signing
>>>> and Document Signing certs, so maybe best to just not go there and
focus
>>>> this draft on the OTP, Client Cert, and WebAuthn authentication
mechanisms
>>>> that it’s adding.
>>>>
>>>
>>> Do we have additional input on this before I remove sections as the
>>> document signing section was just requested by another reviewer? It
doesn't
>>> matter to me as the challenge types are distinct from the certificate
types
>>> requested using the ACME protocol.
>>>
>>>
>>>>
>>>>
>>>> I think the draft’s Introduction and Security Considerations needs some
>>>> discussion that this draft changes the philosophical nature of the ACME
>>>> protocol – whereas the Challenge types in RFC8555 are all focused on
>>>> establishing proof-of-control of a reachable identifier (DNS Name or
email
>>>> address), this draft moves all of that out-of-band and actually brings
the
>>>> ACME protocol closer to existing PKI enrollment protocols in terms of
>>>> functionality offered (CMP, EST, CSR-pasted-into-webpage, etc).
>>>>
>>>
>>> I'd like some more input here as I think this boils down to recent views
>>> on ACME versus the initial work in 2018/2019. These added controls,
>>> especially when policy ties it to an in-person identity proofing to
receive
>>> the initial credentials make it a bit stronger. I'm happy to make
changes
>>> and will do the next iteration quickly (this week) with agreement.
>>>
>>> Thank you very much for your review and comments!
>>> Kathleen
>>>
>>>>
>>>>
>>>>
>>>>
>>>> [PS: I'm fighting with the IETF mail server and multiple personal email
>>>> addresses; so apologies if this sends twice]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---
>>>> Mike Ounsworth
>>>> Software Security Architect, Entrust
>>>>
>>>>
>>>> *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]
>>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>> _______________________________________________
>>> Acme mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>>
>>
> ----------------------------------------------------
> Alternatives:
> ----------------------------------------------------
> _______________________________________________
> Acme mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
