On Tue, Apr 23, 2019, at 05:02, Rubens Kuhl wrote: > Certificates can be made as secure as one wants to. The two most common > ways in the EPP ecosystem are: > 1) Accept certificates from a number of established CAs, but tag an > specific certificate as being authorised. So the authorisation does not > rely only on the CN, but CN+specific public key. > 2) Run your own private CA. This is what we do in both .br and our gTLD > back-end, where we tailor the CN to be the registrar ID. BTW, it would > be nice if ICANN run a CA that identified gTLD registrars in the gTLD > space... but until they do, we have our own.
3) the registry accepts any certificate, even self-signed ones. It is maybe not common, but as secure as the previous ones: the registry whitelists certificates in advance and out of band, and they are associated specifically per registrar. Hence the certificate content, and specifically the issuer part does not matter a lot. In that case it leaves the registrar free to organize itself how he wants, either by generating a local self-signed certificate (one for all, one per registry but key for all or one per registry with separate key), or using one from a well-known CA. If all registries start to maintain their own PKI then again it is a maintenance nightmare for registrars (those connecting to multiple registries). I am not sure a new CA would help tremendously here. At least it just adds an additional case for all registrars not dealing with only one gTLD (because even if it exists I doubt that one could mandate all gTLD registries to accept this CA and only this CA as it is a matter of trust and transitive trust, so why should any gTLD registry trust unconditionnaly this new CA?) -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
