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