Hi Mark,
thanks a lot for your comments.
My comments below prefixed with [ML2].
Il 13/10/2026 09:42, Mark Nottingham ha scritto:
Hi Mario,
On 9 Oct 2026, at 12:11 am, Mario Loffredo <[email protected]> wrote:
NEW
If an HTTP request cannot be delivered to or accepted for EPP processing, the
EoH server or an HTTP intermediary can return any status code applicable under
HTTP. Examples include malformed HTTP requests, unsupported media types,
request-size limits, rate limits, overload conditions, and gateway failures.
Such a response represents an HTTP-layer outcome and is not an EPP response.
EoH clients MUST be prepared to receive any HTTP status code.
An EoH server MUST NOT return a 3xx (Redirection) response to an EoH request.
Although an HTTP intermediary might generate such a response, an EoH client
MUST NOT follow it. The client MUST treat the response as an HTTP-layer failure
and MUST abandon the EoH connection establishment attempt or drop the
established EoH connection, as applicable. If the request carries an EPP
command, the outcome of that command MUST be treated as indeterminate.
Clients MUST process unrecognized status codes according to the status-code
class semantics defined in Section 15 of [RFC9110]. If a client does not
receive a valid EPP response, it has not received an authoritative EPP command
result. The client MUST process any HTTP response according to its status-code
semantics. If the request might have reached the EPP processing layer but no
valid EPP response is received, the outcome of the EPP command is indeterminate.
I suspect that the requirement on the server is SHOULD NOT -- in cases where
generic HTTP infrastructure is in place (e.g., load balancers, libraries, WAFs,
etc.) it's going to be impossible to guarantee that they won't generate a
redirect. Remember, in HTTP a server is not just your box, it's anything that
offers a server interface, including intermediaries.
[ML2] OK. We'll use "SHOULD NOT".
[ML] .it EPP server uses a certificate that has been issued for the server host but I guess that a
certificate issued for the host subdomain can be used too e.g. "*.nic.example" if
"epp.nic.example" is the server host.
Therefore, we would add the following sentence to Section 9:
The EoH client MUST verify the server identity against the host component of the EoH server URL in accordance with
Section 4.3.4 of [RFC9110]. This verification can include wildcard matching when permitted by the applicable service
identity verification rules. For example, a certificate containing the DNS-ID "*.nic.example" matches the
host "epp.nic.example", but does not match "nic.example" or "test.epp.nic.example".
Moreover, given that RFC 9110 refers to RFC 6125—which is now obsolete—it might
also be appropriate to directly reference RFC 9525 for the updated matching
rules as follows:
EoH clients MUST verify the server identity as specified in Section 4.3.4 of
[RFC9110], using the service identity verification procedures defined in
[RFC9525].
Does it work for you (including the reference to RFC9525) or do you recommend
using a dedicated certificate for the server host ?
That's up to you and the security reviewers :)
[ML] I suspected as much, but I didn't know—and still don't—whether
requesting a dedicated certificate for the server host is an unnecessary
security measure. :-(
We'll discuss what is most apropriate and applicable.
Thank you very much for the comprehensive review of this document.
Cheers,
Mario
Cheers,
--
Mark Nottingham https://mnot.net/
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
