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. > [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 :) Cheers, -- Mark Nottingham https://mnot.net/ _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
