The. Certificate problem can be dealt with as elsewhere: switch to DANE and
stop accepting CA certs.
-Bill
> On Mar 20, 2024, at 5:33 AM, Francisco Obispo <fobi...@tucows.com> wrote:
>
> This is a neat idea,
>
> Is there a reasoning or use case for such need?
>
> One of the challenges that I see, is that knowing the server address is one
> thing, but generally clients (registrars) keep the connections open for a
> long period of time, so the need to reduce the connection speed may not be a
> big advantage in practice. (if this is the argument)
>
> Additionally to connect to an EPP server you will need some sort of client
> credentials and a form of client certificate pinning which is usually
> negotiated and exchanged out-of-band.
>
> I am curious to understand the reasoning behind this need
>
> Best regards,
>
> Francisco
>
>> On 19 Mar 2024, at 19:11, Hollenbeck, Scott wrote:
>>
>> As noted during this morning’s regext session, we need to consider how a
>> client can discover the transport services provided by an EPP server.
>> Opportunistic probing is one method, another is server capability
>> publication using something like an SVCB record that’s published in a DNS
>> zone maintained by the EPP server operator. Perhaps something like this:
>>
>> epp.example.net. 7200 IN SVCB 3 epp.example.net. (
>>
>> alpn="bar" port="700" transport="tcp")
>>
>> There is no “transport” SvcParamKey currently registered with IANA, but
>> that’s easy to do. I think there’s a draft here that needs to be written.
>>
>> Scott
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
