Hi Mario,

Response inline.

On 31 Mar 2022, at 13:03, Mario Loffredo wrote:

Hi Francisco,

appreciated but:

1) The ssl variables in NGINX are different.


Yes, they usually are :-)


2) Even supposing to extract CN or SAN, as it seems one should do in NGINX via a regular expression, it doesn't necessarily correspond to the registrar username to access the EPP server.

Well, whichever method is used, it is important to tie the SSL client to the `clID` otherwise an authorized client could try to login with a separate account, so it serves the purpose of a multi-factor authentication:

* IP address whitelist
* SSL client certificate pinning
* clID/password combination

3) I repeat: why should I complicate a solution to come to another that I consider less efficient?

Those methods described above, happen at different layers in the stack, it is not complicated, this is exactly how we operate today (at least Tucows Registry), SSL certificates are checked to ensure they belong to the clID.

IMO a new transport for EPP should at least offer the same safeguards.


Thanks again for the example that maybe will be useful in the future :-)


N/P, this is very similar to how IP access works at the HTTP level using the `X-Forwarded-For` header or similar approach to signal the application information about the client.


Francisco
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext

Reply via email to