Discuss mailing list

[Amunak <amunak AT amunak.net>]

Dne 09.01.2017 v 2:59 opennic AT ned-ludd.com napsal(a):
Hello,

As one who was once heavily involved with the internal CA for a major banking institution I have to weigh in here.

On Mon, 9 Jan 2017, Jonah Aragon wrote:

1. Root CA is created and the key is kept completely offline.

This is standard practice for CAs.  Additionally, the machine used to generate Intermediate Issuer keys is kept offline as well: no network connection at all.  When new certificates are issued, all root CA stakeholders must be physically present to enter their portion of the key passphrase.

CA certificates are granted for every TLD operator, to give them the
ability to grant certificates to their users for each domain registered.

The trick here will be to restrict them to issuing certs for just their own TLD.  I don't believe such a restriction exists for certs.  The only mechanism I can suggest is an active, post-hoc revocation of any inappropriately issued certs.  This brings with it a whole separate management issue.


There is an extension that can restrict certificates to a certain TLD. It's not supported in all clients (some don't  validate against it) but it should still be used.

The actual solution should be (in my opinion) to not give full access to the private key for intermediate certs to the TLD operators but rather only provide them with an API to generate/sign certs that would:

1) enforce generating only for the correct TLD
2) log and publicly show all requests so that anyone can audit them and make sure that (for example) a certificate wasn't signed if noone requested it

The Root CA public certificate is available on the website for download and installation into users' systems. Once that certificate is installed, all certificates created by the Root and Intermediates will show as trusted in users' browsers.

Often the intermediate will have to be explicitly trusted as well, unless the certs are provided in a chain file.

This is the responsibility of the server operators - just like with "regular" CAs and certificates you need a chain file they'll have to use a chain file for certificates issued for OpenNIC TLDs so this is a non-issue.

2. Root CA is created and the key is kept completely offline. A single
Intermediate "live" certificate is granted for use by every OpenNIC domain.
TLD operators will be able to use an API system to give certificates to
their users, but all certificates will come from that single source.

A common, credential-based system poses its own risks.  I would not recommend exposing any parts of the issuing mechanisms to unauthorised use by providing them online.  Since we can assume OpenNIC users have a certain level of technical skill we could oblige them to provide TLD issuers with CSRs and get the issuer to follow a more or less manual process.  Given the likely low volume of certificates this should not be an onerous task.

While I agree that we should want everyone to use CSRs and just have the requests signed and certificates generated all this can be automated so that the process is easy and auditable.


Regards,


Amunak