Hi Mark,
thanks a lot for your further review.
Please our comments embedded below prefixed with [ML].
Il 08/10/2026 06:51, Mark Nottingham via Datatracker ha scritto:
Document: draft-ietf-regext-epp-https
Title: Extensible Provisioning Protocol (EPP) Transport over HTTPS
Reviewer: Mark Nottingham
Review result: Ready with Nits
# Comments
## Consider specifying redirect handling for EPP requests
Section 4 says clients “MUST process any HTTP response according to its
status-code semantics,” but does not say whether to follow redirects or under
what conditions. RFC 9110 permits automatic redirects; depending on the status
code, a client may change POST to GET or resend the POST to the redirect
target. That can break EPP processing or expose command content and session
credentials. RFC 9205 specifically recommends that applications define redirect
handling.
[ML] Redirect never occurs in practice but we can simply state that it's
not supported by this mapping.
We can then change Section 3 and Section 4 as follows:
*Section 3*
OLD
When the URL does not specify a port, the default HTTPS port 443 is
used. There is no server discovery mechanism defined for EoH. The server
URL for EoH is made available out-of-band by the server to the clients.
NEW
When the URL does not specify a port, the default HTTPS port 443 is
used. There is no server discovery mechanism defined for EoH. The server
URL for EoH is made available out-of-band by the server to the clients.
*HTTP redirection is not supported by this mapping. The EoH server URL
identifies the endpoint with which the EPP connection is established and
is made available to the client out-of-band. An EoH connection or
session cannot be transferred to another HTTP target by means of an HTTP
redirect. This preserves the property of the EPP-over-TCP mapping
[RFC5734] that an EPP session is bound to a single client-server
connection.*
*
*
*Section 4*
OLD
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.
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.
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.
Does it work for you ?
## Consider requiring verification of the HTTPS server identity
Section 9 requires HTTPS to protect credentials and the session identifier, but
does not explicitly require clients to verify that the certificate matches the
server URL. RFC 9110 already defines that requirement, but RFC 9205 recommends
that an application using HTTPS state it explicitly. Naming RFC 9110 4.3.4
would make clear that encryption without server authentication is insufficient.
[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 ?
# Nits
* The greeting response example in section 4.1 omits X-Content-Type-Options:
nosniff, which section 3 requires.
[ML] Good catch. We'll fix it.
Best,
Mario
--
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]
