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]
>
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
