Hi Jim,
I hope you are well. Thank you again for the valuable input. Please find my
replies marked with ("--- \n ZA \n---") below. I look forward to your feedback.
Regards,
Zaid
On 1/9/26, 10:44 AM, "James Galvin" <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>> wrote:
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://secure-web.cisco.com/1T2eqz1DF2No6hPq6T17gjlgovezithBIcB2fPck2UAW_6jW0GcZ4M01fIl_7C02rOBKItQMxBx8xlgR_P_e8YkiIyVZK-nV7L1cLEzNPY3ot23j5HWirp8rZj_pJ4gPblx0TpxbkvWExTVmiNcwpyhz-OutUrGfFj4xslDjdUuVcjAB6DZAjsOvyzwglN7bdSb3iqw0CIBjE11eheCFirgBB6b5yMQiVZjGAwPXnXHCN1V9ogBMXjU4l1j35V77Ygc6mgOHLR54ws5fiuKrw9gubbP7eLZak-BeK-u49Ls4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp244%2F>
<https://secure-web.cisco.com/1T2eqz1DF2No6hPq6T17gjlgovezithBIcB2fPck2UAW_6jW0GcZ4M01fIl_7C02rOBKItQMxBx8xlgR_P_e8YkiIyVZK-nV7L1cLEzNPY3ot23j5HWirp8rZj_pJ4gPblx0TpxbkvWExTVmiNcwpyhz-OutUrGfFj4xslDjdUuVcjAB6DZAjsOvyzwglN7bdSb3iqw0CIBjE11eheCFirgBB6b5yMQiVZjGAwPXnXHCN1V9ogBMXjU4l1j35V77Ygc6mgOHLR54ws5fiuKrw9gubbP7eLZak-BeK-u49Ls4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp244%2F>>
<https://secure-web.cisco.com/1T2eqz1DF2No6hPq6T17gjlgovezithBIcB2fPck2UAW_6jW0GcZ4M01fIl_7C02rOBKItQMxBx8xlgR_P_e8YkiIyVZK-nV7L1cLEzNPY3ot23j5HWirp8rZj_pJ4gPblx0TpxbkvWExTVmiNcwpyhz-OutUrGfFj4xslDjdUuVcjAB6DZAjsOvyzwglN7bdSb3iqw0CIBjE11eheCFirgBB6b5yMQiVZjGAwPXnXHCN1V9ogBMXjU4l1j35V77Ygc6mgOHLR54ws5fiuKrw9gubbP7eLZak-BeK-u49Ls4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp244%2F>>
<https://secure-web.cisco.com/1T2eqz1DF2No6hPq6T17gjlgovezithBIcB2fPck2UAW_6jW0GcZ4M01fIl_7C02rOBKItQMxBx8xlgR_P_e8YkiIyVZK-nV7L1cLEzNPY3ot23j5HWirp8rZj_pJ4gPblx0TpxbkvWExTVmiNcwpyhz-OutUrGfFj4xslDjdUuVcjAB6DZAjsOvyzwglN7bdSb3iqw0CIBjE11eheCFirgBB6b5yMQiVZjGAwPXnXHCN1V9ogBMXjU4l1j35V77Ygc6mgOHLR54ws5fiuKrw9gubbP7eLZak-BeK-u49Ls4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp244%2F&gt;>>
.
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.
----
ZA: I found that a common thread in the feedback revolves around the fact EPP
is independent of the EKU/MTLS changes and changing EPP is not an option. I
have added stronger language in the introduction to reflect that. Please see
the text below and let me know if the point is emphasized enough. With respect
to the choosing a "solution", we purposefully focused on presenting feasible
solutions without addressing which solution is "best" because every environment
is different and each of these solutions is a small piece of a bigger puzzle.
The draft aim is to present some options to the current challenge and not
suggest one option over another.
"
Recent changes to policies related to Mutual Transport Layer Security
(mTLS) client certificates are presenting operational challenges for
the Extensible Provisioning Protocol (EPP) client authentication
process. This document describes the changes, the challenges
associated with these changes, and suggested approaches to continue
to implement mTLS authentication in EPP. The solutions addressed are
not focused on changing EPP, they are focused on options to deal
satisfying EPP session establishment requirements with currently
available technologies.
"
----
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.
----
ZA: In order to reduce the perceived uncertainty factor of the wording in the
above-mentioned section, the term " While not a requirement of EPP” was
removed.
The section now reads as follows:
"
Some server implementations of TLS require that a client certificate
include the Extended Key Usage (EKU) extension with the id-kp-
clientAuth key usage purpose (clientAuth EKU), defined in section
4.2.1.13 of RFC 5280 [RFC5280]. Similarly, some client
implementations of TLS require that a server certificate include the
EKU extension with the id-kp-serverAuth key usage purpose (serverAuth
EKU). The clientAuth EKU and the serverAuth EKU are registered with
IANA as described in Section 3.6 of RFC 7299 [RFC7299], for world
wide web (WWW) client applications and world wide web (WWW) server
applications, respectively. There are EKU entries registered for
other protocols or applications, such as email, SCVP and SSH, but
none are registered for EPP.
"
----
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.
-----
ZA: Exactly what evidence would you like to see here? Based on operations data
this is the situation that some registries are dealing with at the moment.
-----
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.
------
ZA: The goal behind having a "Mechanism" sub section is to provide high level
approach to each of the potential solutions. This serves the purpose of
potentially guiding further discussion on approaches the community find most
suitable to deploy and the details associated with such approaches. Section 5
now reads as shows below, and each solution now has a matching potential
implementation approach. Please let me know if that addresses your point.
"
5. Potential Solutions With Implementations Guidance
5.1 Potential Solutions
5.2 Potential Implementations
"
---------
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]> <mailto:[email protected]
> <mailto:[email protected]>> <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>> " <[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>> <mailto:[email protected]
> <mailto:[email protected]> <mailto:[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>
>
> <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>>
>
> <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>>
>
> <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&gt;>>
>
>
> 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>
>
> <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>>
>
> <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>>
>
> <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&gt;>>
>
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
>
>
> _______________________________________________
> I-D-Announce mailing list -- [email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>> <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>> <mailto:[email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>>
>
>
>
> _______________________________________________
> regext mailing list -- [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]> <mailto:[email protected]
> <mailto:[email protected]>>
_______________________________________________
regext 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]
