Speaking as participant: I have a few comments I would like to make about this document.
First, as a top-level comment, I would like to see this document adopted by the working group and then to move forward as a clarification to the EPP specification, perhaps as a BCP. I see this as a similar situation to the clarification offered regarding the <delete> transform in what became BCP 244 <https://datatracker.ietf.org/doc/bcp244/> . The abstract suggests that the document describes the state of the mTLS client authentication mechanism in EPP. I do have a few comments about the details of what is in the document noted below, but I think this document and the understanding of the EPP specification would be improved if this document explicitly said something to the effect that the EPP protocol doesn’t care about the extensions of the certificate and thus EPP is not itself impacted by the changing policy of the Certificate Authorities (CAs). Thus, it is explicitly server policy that defines the certificate requirements and it is the responsibility of EPP servers and clients to take care to track changes in CA policies. I believe this is important because if the document is going to describe several possible “solutions” to the changing CA policies, it needs to state a basis for why any one of several solutions is valid as opposed to choosing exactly one. And just to be clear about my position, I’m not opposed to choosing one solution, if the working group wants to have that discussion. I do have an opinion about which “solution” to choose. However, my starting position is that choosing “a solution” is changing EPP and I do not support that. As I see it, EPP doesn’t currently care and we should just clarify that, similar to how we clarified the <delete> transform. To be fair, the document seems to suggest this so my comment here is meant to reflect an editorial exercise of being explicit. If this were a working group document, hence the adoption request above, this is what I would propose. Aside from that, here’s a few more explicit points for your consideration. 1. In Section 3, the opening phrase of the second paragraph is the key point: “While not a requirement of EPP”. I would suggest expanding on the fact that EPP does not care about extensions, i.e., it is server policy. The rest of that paragraph is noting a change in CA policies; that is background. 2. In Section 4, shouldn’t the current state be about the fact that since EPP never had extension requirements, EPP server implementations have made their own choices based on local implementation needs? The observation is that a common choice in local implementation needs may not be available in the future because of the changing CA policies. The statement “In practice, EPP clients and EPP servers use EKU extensions intended for world wide web applications because those certificates have been easy to acquire from popular CAs.” seems like an overstatement to me because it suggests, at least to me, that local EPP implementations made choices based on WWW applications. While that may be true, absent any actual evidence it doesn’t strike me as a relevant technical comment. 3. In Section 5, I’m confused about the distinction and relationship between “solutions” and “mechanisms”. I believe the overall issue here is about the certificate used and its implementation requirements. So the three “solutions” seem reasonable at face value. Specifically, a.) continuing using certificates from CAs; b.) EPP server issues its own certificates; c.) self-signed certificates. However, I don’t fully understand Section 5.1.1, “solution a”. If the point of the solution is to continue using existing CA services, the disadvantage is generally the fact that the EPP server and client may be impacted by CA policy changes. The client EKU extension is a current example, but this description seems to focus only on that and again links the issue to WWW applications. It doesn’t address future concerns. In addition, Section 5.2.1 is confusing because it’s a “mechanism” that is inconsistent with “solution a”. The “solution” says to continue to use existing CAs and then process the clientAuth EKU. But “mechanism 5.2.1” says use existing CAs with certificates that don’t use the clientAuth EKU. Wouldn’t that be a “solution” not a “mechanism”? The other mechanisms seem like implementation details to me, i.e., local implementation choices. Since EPP never made a specific choice about certificates, I’m not sure these details are necessary. I suppose they are informative but as long as the document is not proposing a single solution, I’m concerned the “mechanisms” are distracting from the key point that EPP implementations that have local needs for certificate requirements should take care to track CA policy changes, if appropriate. Thanks, Jim On 2 Dec 2025, at 14:39, AlBanna, Zaid wrote: > Hello, > > I hope all is well. > > I submitted the draft below. Kindly review and comment. Thanks in advance. > > Zaid > > On 12/2/25, 2:38 PM, "[email protected] > <mailto:[email protected]> " <[email protected] > <mailto:[email protected]>> wrote: > > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > Internet-Draft draft-albanna-regext-eku-mtls-in-epp-00.txt is now available. > > > Title: Extended Key Usage and Mutual TLS in EPP > Authors: Zaid AlBanna > James Gould > Scott Hollenbeck > Name: draft-albanna-regext-eku-mtls-in-epp-00.txt > Pages: 10 > Dates: 2025-12-02 > > > Abstract: > > > This document describes the state of the Mutual Transport Layer > Security (mTLS) client authentication mechanism in the Extensible > Provisioning Protocol (EPP) with respect to a recent change in the > client certificates published by some Certificate Authorities (CAs). > The issue is described and options are presented to address the > operational impact of the change. > > > The IETF datatracker status page for this Internet-Draft is: > https://secure-web.cisco.com/1Fn_sSTgAN6EuQflfKpRjHFhw3wsTeC356PoUVEOpwaMY9oCq_eagfdAoUCHhJr_WkhlIONa_P9A9f8YNlSkk26keIBnPuHI6ITsU1Z7e-6ZZ7Uu-5UcOuXqHPntJC4Rk4_3jVRzOX1NPr2sUXK9lvTw_drYvwpGNNIC66Vp7VrwvIOLP67_Gp3KJZRql0Iy7tG_stcIXpZd6tJqlLV_dNgvWFWJVJHvCbY0-sCFZcUJm16RFmyNG6DHaRryO_Z6vQSVJ597OfG0PjiT9HNH4WRKsOLBAZoz3gAaiITx1ct8/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-albanna-regext-eku-mtls-in-epp%2F > > <https://secure-web.cisco.com/1Fn_sSTgAN6EuQflfKpRjHFhw3wsTeC356PoUVEOpwaMY9oCq_eagfdAoUCHhJr_WkhlIONa_P9A9f8YNlSkk26keIBnPuHI6ITsU1Z7e-6ZZ7Uu-5UcOuXqHPntJC4Rk4_3jVRzOX1NPr2sUXK9lvTw_drYvwpGNNIC66Vp7VrwvIOLP67_Gp3KJZRql0Iy7tG_stcIXpZd6tJqlLV_dNgvWFWJVJHvCbY0-sCFZcUJm16RFmyNG6DHaRryO_Z6vQSVJ597OfG0PjiT9HNH4WRKsOLBAZoz3gAaiITx1ct8/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-albanna-regext-eku-mtls-in-epp%2F> > > > There is also an HTMLized version available at: > https://secure-web.cisco.com/1hrVLgccmsfDoRVjEuc2vUUFcDLH5ZocmaNdNwovEFYadG96W1RfoE2pXpO_D66vcXfvw5mkcTt1OaGb6pIpLjIbbE68aJ7iMupC468jxBGBVPqYzcnKO1ZVs4nwGEXd2ftM3OwiqLh_BcnD5oymsLF6K1zlZtvluw5_aJZl_dSoDBoFK06pcfqwfR4Q2wfKfrXYsLBiRYI3tLPSpdBmYwsQ4Wmb9wPMQO7TzQ-gVtgosW8QXbxppcMXeT1KGBwxiSWih821eADy5ghFeVS_0_yhXQhkVqCXUubnP7iiSVAc/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-albanna-regext-eku-mtls-in-epp-00 > > <https://secure-web.cisco.com/1hrVLgccmsfDoRVjEuc2vUUFcDLH5ZocmaNdNwovEFYadG96W1RfoE2pXpO_D66vcXfvw5mkcTt1OaGb6pIpLjIbbE68aJ7iMupC468jxBGBVPqYzcnKO1ZVs4nwGEXd2ftM3OwiqLh_BcnD5oymsLF6K1zlZtvluw5_aJZl_dSoDBoFK06pcfqwfR4Q2wfKfrXYsLBiRYI3tLPSpdBmYwsQ4Wmb9wPMQO7TzQ-gVtgosW8QXbxppcMXeT1KGBwxiSWih821eADy5ghFeVS_0_yhXQhkVqCXUubnP7iiSVAc/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-albanna-regext-eku-mtls-in-epp-00> > > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > > > _______________________________________________ > I-D-Announce mailing list -- [email protected] > <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
