Dean and Justin, thank you for your comments. I am adding the ACME list as the document is in that WG.
On Tue, Jun 10, 2025 at 1:36 PM Dean H. Saxe <[email protected]> wrote: > Kathleen, > > Thank you for giving me the opportunity to review the draft. I broadly > agree with Justin’s comments. I’d like to offer some feedback on the draft > to help move this work forward. > Much appreciated! > > - > > Section 2 discusses client certificate automation and identity > proofing. I find this to be confusing, since the certificates represent a > device identity and not a human that can be identity proofed. Can you > clarify your thinking on identity proofing for this use case? Does the > FIDO > Device Onboarding protocol > <https://fidoalliance.org/specifications/download-iot-specifications/> > sufficiently address issuing client certificates to IoT devices? I was > surprised to see the identity proofing concerns are not included in Section > 3 which discusses end user client certificates. > > Thank you for pointing this work out. The identity proofing section is included to point out that this is disjoint from what is in the specification and can be a part of the Certificate Authority's processes to obtain a CSR. The crux of this is to establish multiple challenge types that can be used potentially by a user or automated, that enable automation of a certificate and key pair from a CA. In reviewing the standard for device onboarding, the intent and protocols are different. This draft enables an ACME client to use a WebAuthn credential as the challenge type to get/update a certificate and associated key pair of a specified type (can be specified in the CSR). The identity proofing can happen if the CA policy requires this step and it would be done to have th WebAuthn credentials issued. Once they have been issued, the challenge can be accomplished with the WebAuthn credentials to interact with the CA using the ACME protocol for certificate management automation. Does this help clarify the differences well enough and is additional text needed in the draft? > - > > Section 3 describes the potential to use an OAuth bearer token to > “prove” ownership of the email address. This approach may lead to > unanticipated outcomes since these tokens are generally not bound to the > device they were issued to. > > Yes, you are right and I removed this text. It's not defined as a challenge type in this draft and I believe was proposed as a possibility in the past, so it was mentioned in that context. It's not helpful text, so it will be removed in the next revision. Thank you! It may be desirable to have OpenIDConnect, which would use OAuth after authentication to the authorization server occured. If it is helpful to add this in, it would be another challenge type in the draft and I believe this is used in practice to obtain PKI issued credentials in an automated way (maybe not with ACME yet though). > - > > Section 3 also discusses the use of knowledge based authentication, > which has been discouraged by NIST since 2017. I would discourage its use > in this protocol. > > Also removed, thank you for calling this out! > > - > > Also in Section 3, the use of FIDO credentials is discussed. For > clarity, the credentials should be referred to as FIDO credentials or > passkeys. CTAP is irrelevant in this context, since it is used to > communicate between a hardware security key and the browser. FIDO > credentials require user interaction for their use, so automation with a > FIDO credential is unlikely without allowing for user interaction to > complete a request. This may result in a timeout before the request > completes. Similar issues may occur with OTPs or other mechanisms that > depend on user interaction. > > This is helpful information and context, thank you. Is it okay to also refer to WebAuthn? My working draft has the following replacement and please let me know if this works or if you have a specific suggestion: o FIDO Credentials/WebAuthn/Passkeys, and Adding information that user interaction is required will be helpful and I can do that. For code signing certificates, a team may want that level of security around obtaining the new certificate and key pair or other mostly automated certificate management options. Once the PKI certificate and key pairs are issued through ACME, the use of those keys can be fully automated. When DigiCert reviewed this draft a few years ago, they affirmed that they had a process in place following this pattern. > > - > > Section 7 correctly identifies that passkeys need to be preregistered > with the ACME service since they are origin bound. Alternatively federated > authentication with appropriate claims (e.g. amr claims of hwk) should > be used to demonstrate that the user authenticated with an appropriately > strong mechanism at the IdP prior to federation to the RP, the ACME > service. > > Should a federated mechanism be added to the draft as another challenge type? I am assuming you are referring to OpenIDConnect, which uses OAuth (signed) with appropriate claims from the authentication server. Any authentication type could be used to authenticate to the authorization server that could issue OAuth tokens with the correct claims and signature for use with the ACME challenge/response. > > - > > I recommend separating the concerns regarding identity > proofing/verification and authentication in the draft. As written, it > creates confusion between these two distinct operations. In addition, I > would consider how the authentication or federation event communicates any > ID Proofing data to the ACME server. > > Hmm, I read it as the identity proofing is out-of-scope, to be defined by the CA who will accept the challenge types that are added. It sounds like some updates would be helpful to clarify, much appreciated! If you are reading it differently, could you please point out text changes that would help to ensure that point is clear? The identity proofing was only added to clarify for those not in the identity space that this can be separate. Nothing is defined/required by the specification in terms of ACME for identity proofing in this draft. It only adds 3 challenge types (maybe 4 if we add in OpenIDConnect). Text suggestions are welcome! I can post an updated draft so you see the updates. Thank you very much for your thorough review! Best regards, Kathleen > I hope you find these comments helpful. If you have any questions, please > let me know > > Thank you, > > -dhs > > On Fri, 30 May 2025 14:34:36 GMT Kathleen Moriarty wrote: > > Justin, > > > Thank you, agreed and that was the intent of the draft. Also, an objective > was to have this draft go through in ACME while it was still a working > group as to get adequate reviews. Processes to integrate this work into > patterns to accomplish the bridge can follow (or be outside of IETF > standards) if the challenge types are in the protocol as registered so they > can be integrated into supporting libraries. > > > Please send reviews to the ACME list and/or statements of interest if you > think it's done (or your comments were covered by someone else). > > > Thank you! > > Kathleen > > > On Fri, May 30, 2025 at 9:36 AM Justin Richer <[email protected]> wrote: > > Kathleen, thanks for sharing this. In my opinion, this has the potential > to be an important bridge between the human-identity and machine-identity > worlds, especially as most of what happens in WIMSE space is going to be > on-behalf-of some real person in some way. The workloads that need to pick > up and do the actual work kicked off by this authentication step will > eventually need to tie back to some form of initiating call. > > > — Justin > > > On May 29, 2025, at 12:47 PM, Kathleen Moriarty < > [email protected]> wrote: > > > Greetings! > > I hope you are all well! At a previous meeting, I mentioned the draft > below that adds challenge types to ACME including WebAuthn/FIDO, PKI, and > OTP. This could be applicable to workload certificates and associated key > pairs and may be of interest. The CSR to request a certificate contains the > certificate type and is separate from the challenge type used to > authenticate the request. Hence the document just adds challenge types. > > > Review is requested and if you support the work and do not have feedback, > it would be important to also note that on the ACME list. If you have > feedback, please post that to the ACME list. > > > Thank you, > > Kathleen > > ---------- Forwarded message --------- > From: <[email protected]> > Date: Wed, May 28, 2025 at 10:06 AM > Subject: [Acme] I-D Action: draft-ietf-acme-client-10.txt > To: <[email protected]> > Cc: <[email protected]> > > > > Internet-Draft draft-ietf-acme-client-10.txt is now available. It is a work > item of the Automated Certificate Management Environment (ACME) WG of the > IETF. > > Title: ACME End User Client and Code Signing Certificates > Author: Kathleen M. Moriarty > Name: draft-ietf-acme-client-10.txt > Pages: 16 > Dates: 2025-05-28 > > 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, and code signing certificates and keys. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-client/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-acme-client-10 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-client-10 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > -- > > > Best regards, > > Kathleen > > -- > Wimse mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > > -- > > > Best regards, > > Kathleen > > -- Best regards, Kathleen
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
