[gtld-tech] URS, PGP or S/MIME
gustavo.lozano at icann.org
Thu Sep 5 21:58:13 UTC 2013
The second version of the URS High Level Technical Requirements defines S/MIME as the authentication and non-repudiation mechanism for the interaction between URS providers and Registries, and for the communication between URS providers and Registrars.
Several emails to the list and private messages suggest that PGP should be used instead of S/MIME. We believe that either PGP or S/MIME could be used.
The PGP solution that we envision would be like this:
* ICANN gathers the valid PGP keys from Registries and URS providers.
* ICANN maintains and publishes a keyring of URS providers PGP keys and a keyring of Registry Operators PGP keys. Each keyring would be signed with ICANN's PGP key and published on an HTTPS site.
* Registry Operator/Registrar downloads the keyring of URS providers PGP keys frequently (every 12 hours appears to be appropriate considering the 24 hour windows to URS lock a DN and the potential revocation of a compromised key).
* URS provider downloads the keyring of Registry Operators frequently.
* ICANN provides a list of "TLD, PGP key id" to URS providers (we could use the comment field of the PGP key to identify the TLD(s), but a simple CSV file appears easier).
The S/MIME solution that we envision would be like this:
* ICANN provides a list of "TLD, authorized email address" to URS providers.
* ICANN provides a list of "URS provider, authorized email address" to Registry Operators/Registrars.
* Registry Operators and URS providers obtain certificates from public CAs (the list of well-known root CAs in different software products and libraries do the rest).
ICANN can accommodate either the PGP or the S/MIME solution. However, we believe we should only do one to avoid unnecessary complication.
The question is:
* What is your preference?
For version three of the URS technical requirements, we will define whatever the majority believes is the best approach.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gtld-tech